人生管理系统 PRD v1

返回“人生管理体系”文件夹

人生管理系统 PRD v1

版本：0.1
阶段：MVP 方案
决策依据：《人生管理系统：需求澄清与初步方案》

1. 一页式产品定义

产品愿景

建立一个能够使用很多年的个人系统：先以极低成本留下真实记录，再逐步把记录转化为行动、知识、原则、能力证据和可公开作品。

第一阶段唯一目标

让持续记录成为稳定习惯。

规划、知识沉淀、人生时间线、技能图谱和电子简历都建立在记录之上。MVP 不以功能数量为成功标准，而以低能量时是否仍能留下一条记录为标准。

核心用户

当前只服务一个用户，即系统的创建者本人。使用环境：

• 公司电脑：工作日高频捕获、日计划、日记和工作日志；
• 宿舍电脑：周末集中复盘、整理、沉淀和发布；
• 不考虑手机；
• 当月活跃数据保存在私有 Git 仓库中的 Markdown 文件；
• 完整长期数据保存在宿舍电脑的 Obsidian 主库中。

核心问题

1. 现有规划流程依赖较高的情绪和能量，通常只能维持半个月。
2. 完美主义和“欠下很多事情”的感觉会放大任务规模，最终转化为逃避和刷手机。
3. 记录、规划、整理、分类同时发生，启动成本过高。
4. 年、月、周、日计划之间存在重复维护，没有自动传导。
5. 工作日产生的材料与宿舍端整理、公开展示之间尚未形成可靠闭环。

产品策略

系统采用两个工作流，而不是立即开发两个软件模式：

工作流	场景	目标	首选工具
捕获模式	公司或其他电脑	快速记录和执行当天工作	VS Code + Markdown + Git
整理模式	宿舍电脑	周复盘、知识沉淀、公开发布	Obsidian + Git + 辅助脚本/Agent

核心价值主张

• 打开文件后，1 分钟内就能完成最低记录；
• 状态较好时，可以自然升级为日计划和时间块；
• 工作过程可以保留“我如何思考、如何与 AI 协作”的完整日志；
• 每月可以回看原则与观点的版本变化；
• 私人内容只有经过人工确认才会进入电子简历；
• 中断后不补债，只从今天重新开始。

MVP 范围

MVP 包含：

• 作为活跃同步仓的私有 life-vault 仓库；
• 作为长期主库的宿舍 Obsidian 本地目录；
• 每日日记、工作日志、日计划；
• 年度方向、月度检查点、项目、周复盘；
• 基于日期和标签的检索；
• 一键或近似一键的安全同步；
• Obsidian 将 life-vault 直接作为 Vault 打开；
• 人工选择公开内容并发布到电子简历仓库；
• 睡眠、运动、情绪和财务的轻量记录；
• 观点/原则的版本记录。

MVP 不包含：

• Electron/Vue 客户端；
• 自动知识图谱；
• 自动改写或移动全部笔记；
• 自动发布所有日记和工作日志；
• 复杂技能树；
• 手机端；
• WPS 历史数据迁移；
• 自主运行、无需确认的 Agent。

2. 关键产品决策

2.1 第一期不开发 Electron

Electron 当前没有解决一个已经被验证、且现有工具无法解决的问题。相反，它会增加：

• UI、编辑器、Git、文件监控和冲突处理的开发成本；
• 公司电脑安装和升级成本；
• 软件“不够顺手”导致系统整体弃用的风险；
• 为开发管理工具而挤占真正记录和行动的时间。

第一期使用 VS Code 和 Obsidian。四周后只对实际出现且高频的阻力做产品化。如果打开当天文件、创建模板、同步或发布仍然明显麻烦，再选择脚本、VS Code 扩展、Obsidian 插件或 Electron。

2.2 采用“活跃同步仓 + 长期主库”的双层存储

life-vault 不承担一生全部文件的云端保存，而是公司电脑与宿舍电脑之间的活跃同步仓。它只保存：

• 当前年度、月份和星期需要查看的方向、项目与复盘；
• 当月的日记和工作日志；
• 当前需要处理的 Inbox；
• 当前有效的原则和时间线索引。

宿舍电脑另设完整的 Obsidian 主库，保存历月日记、工作日志、知识、技能证据、作品和历史资料。

月末归档时，先把本月内容导入长期主库并验证，再从 life-vault 移除已经不需要在工作日查看的旧日志。life-vault 是传输和工作层，宿舍主库才是长期事实来源。

这个架构减少 Git 仓库体积和公司端无关信息，同时带来一个新要求：宿舍长期主库必须有独立备份，不能只保存在单块硬盘上。

2.3 主模式和副模式保留为概念，不做成程序开关

• “副模式”改称捕获模式：快速、克制、只处理今天。
• “主模式”改称整理模式：回顾、提炼、发布。

它们共享同一份数据，只是入口、模板和允许执行的操作不同。

2.4 每日计划采用能量自适应，而不是固定复杂度

系统不能假设每天都有能力完成 30 分钟晨间规划。每天打开时只需先选择状态：

• low：勾选状态，写一句话，即可结束；
• medium：写一个关键结果和可选任务；
• high：增加时间块、估时和复盘。

精确时间块仍然保留，因为它在高能量或高压状态下有效；但它不是每天的必填项。

2.5 所有公开动作都需要人工确认

虽然当前主观意愿是“都可以公开”，日记和工作日志仍可能在未来包含姓名、公司信息、密钥、路径、内部项目或情绪化内容。产品规则保持：

默认私密，明确选择，预览差异，人工确认，随后发布。

这是系统安全边界，不依赖当下是否认为内容敏感。

3. 信息架构

life-vault/                            # GitHub 私有仓库：活跃同步层
├─ 00_Inbox/                         # 无法判断放哪里时先放这里
├─ 10_Journal/
│  └─ 2026/
│     └─ 07/
│        ├─ 2026-07-25-daily.md      # 日记 + 日计划
│        └─ 2026-07-25-worklog.md    # 工作思维与 AI 协作日志
├─ 20_Action/
│  ├─ Directions/                    # 年度方向
│  ├─ Projects/                      # 有明确结果的项目
│  └─ Reviews/
│     ├─ Weekly/
│     └─ Monthly/
├─ 40_Self/
│  ├─ Principles/                    # 长期原则和版本演变
│  └─ Timeline/                      # 月度/年度人生时间线
└─ Templates/

宿舍长期主库的结构不受 life-vault 限制，可以包含完整的 Knowledge、Skills、Archive、Publish 和历年日志。第一阶段不自动创建或迁移长期主库，避免在记录习惯尚未验证前过度设计。

为什么日记和工作日志分开

两者的目的明确不同：

• 日记记录当天发生的事情、情绪和个人想法；
• 工作日志保留解决问题时的思维展开、AI 对话摘要、实验结果和下一步。

这两类内容可以通过同一天日期和项目链接相互关联，但不合并成一个超长文件。

为什么按天拆文件

• 符合第一期“按时间查找”的习惯；
• 两台电脑修改不同日期文件时冲突更少；
• 单篇更容易标记标签和发布状态；
• 日后生成月度回顾与时间线更简单。

4. 关键用户流程

4.1 公司电脑：工作日捕获流程

开机
  → 同步 life-vault
  → 打开今天的 daily 文件
  → 选择能量状态
  → low：一句话后结束
  → medium/high：写今天的关键结果
  → 工作时持续追加 worklog
  → 下班前补一行“实际进展/下一步”
  → 自动或一键提交并推送

目标耗时：

• 最小晨间记录：不超过 1 分钟；
• 普通日计划：不超过 15 分钟；
• 下班收尾：不超过 3 分钟；
• 工作日志属于工作过程，不单独计算维护时间。

4.2 宿舍电脑：周末整理流程

同步 life-vault
  → 将当月新增内容导入宿舍 Obsidian 主库
  → 浏览本周 daily 和 worklog
  → 生成周复盘草稿
  → 人工确认行动、知识、原则和时间线
  → 选择公开候选
  → 预览电子简历变更
  → 人工确认发布
  → 推送两个仓库

周末整理设置 2 小时上限，建议拆为：

• 20 分钟：回看本周记录；
• 20 分钟：周复盘；
• 30 分钟：提炼知识和原则；
• 30 分钟：整理公开候选；
• 20 分钟：机动或直接结束。

没有值得沉淀或发布的内容时，可以跳过对应步骤。

4.3 中断恢复流程

无论中断一天还是数周：

1. 创建今天的文件；
2. 写一句“我从今天重新开始”或当前状态；
3. 不补历史记录；
4. 不处理所谓欠账；
5. 本周复盘时再决定是否恢复项目。

5. 规划模型

层级

年度方向（为什么）
  → 月度检查点（本月是否仍朝该方向前进）
    → 项目（需要获得什么结果）
      → 下一步行动（现在能做什么）

周计划是项目下一步的选择，日计划是当天承载能力的选择。任务通过链接引用，不在年、月、周、日文件之间反复抄写。

月目标提前完成后的处理

你的近期低动力与“月目标提前完成大半后失去方向”有关。因此月计划必须包含：

• 完成线：做到什么就算本月成功；
• 加分线：状态好时可以继续推进什么；
• 维护线：目标完成后仍需维持的最小生活/工作动作；
• 停止线：哪些事情本月明确不做。

达到完成线后，系统默认进入维护或恢复状态，不自动制造更多债务。是否开启加分目标，由月度检查点主动决定。

处理完美主义

任务必须写成可结束的下一步，避免使用“完善、全面、一次性解决”等无边界描述。例如：

不推荐：完善 PLC 通讯模块
推荐：在临时页面完成一次 Mock 连接并记录结果

每天最多选择一个关键结果。未完成任务不自动累计为“欠账”，而是在下次选择时重新评估：继续、拆小、延期或放弃。

6. Markdown 数据规范

通用元数据

所有正式文件使用 YAML Front Matter。MVP 只强制少数字段：

---
title: 2026-07-25 日记
date: 2026-07-25
type: daily
tags: [日记]
publish: false
---

字段约定：

字段	必填	示例	说明
title	是	2026-07-25 日记	可读标题
date	是	2026-07-25	内容所属日期
type	是	daily	内容类型
tags	是	[日记, 睡眠]	第一阶段主要检索方式
publish	是	false	只有人工改为 true 才可发布
project	否	[[工艺参数一键切换]]	所属项目
created	否	ISO 时间	自动化阶段加入
updated	否	ISO 时间	自动化阶段加入

type 第一阶段限制为：

• daily
• worklog
• project
• weekly-review
• monthly-review
• knowledge
• principle
• timeline

标签使用少量稳定的中文词，不提前建设庞大标签体系。

7. MVP 模板

7.1 每日日记与计划模板

---
title:  日记
date: 
type: daily
tags: [日记]
publish: false
---

# 

## 最小记录（必填区）

- 当前状态：[ ] low [ ] medium [ ] high
- 此刻一句话：

<!-- 写完以上两项即可关闭，不算失败。 -->

## 今天的关键结果（可选）

- [ ]

## 维护动作（可选）

- [ ] 睡眠
- [ ] 运动

## 时间块（仅高能量或紧急时使用）

- 08:30-09:00：

## 实际发生与想法

-

## 下班/睡前收尾

- 今天实际推进：
- 明确的下一步：
- 情绪：
- 睡眠：
- 运动：
- 娱乐时长：

7.2 工作日志模板

---
title:  工作日志
date: 
type: worklog
tags: [工作日志]
publish: false
---

#  工作日志

##  / 

### me（min）

- 当前事实：
- 判断：
- 下一步实验：
- 完成标准：

### AI（min）

- 产出：
- 文件/链接：
- 需要验证：

### 结果

- 结果：
- 没有效果的尝试：
- 下一步：

日志不要求每次完整填写所有字段。保留你现在的 me → codex → ... 形式，模板只帮助在必要时补充“事实、验证和下一步”，使它更适合复盘。

7.3 周复盘模板

---
title: -W 周复盘
date: 
type: weekly-review
tags: [复盘]
publish: false
---

# 本周复盘

## 本周留下了什么记录？

-

## 完成与证据

-

## 哪些事情反复阻塞？

-

## 睡眠、运动与情绪

-

## 值得沉淀

- [ ] 知识：
- [ ] 原则：
- [ ] 时间线：
- [ ] 公开候选：

## 下周只推进什么？

- 唯一关键结果：
- 低能量时的最小动作：
- 明确不做：

7.4 项目模板

---
title: 项目名称
date: 
type: project
tags: [项目]
publish: false
status: active
---

# 项目名称

## 预期结果

## 为什么做

## 完成标准

## 当前状态

## 下一步行动

- [ ]

## 过程记录

## 成果与证据

## 结束决定

- [ ] 完成
- [ ] 暂停
- [ ] 放弃

7.5 原则/观点模板

---
title: 原则名称
date: 
type: principle
tags: [原则]
publish: false
status: active
---

# 当前表述

## 为什么相信它

## 适用边界

## 反例

## 版本记录

###  / v1

- 新表述：
- 变化原因：
- 来源记录：

原则文件不覆盖旧结论，通过版本记录呈现观点如何演化。每月复盘只选择少量相关原则回看，不要求把所有原则读一遍。

8. Git 同步与冲突方案

身份验证

“不登录 GitHub 网页”不等于不需要身份验证。公司电脑要推送私有仓库，必须保存某种凭据。建议使用：

• 仅对 life-vault 有访问权的 SSH Deploy Key，并允许写入；或
• 仅授予该仓库权限的细粒度访问令牌。

不建议在公司电脑保存拥有全部个人 GitHub 仓库权限的通用凭据。

同步原则

1. 开始使用前同步；
2. 结束使用后提交并推送；
3. 每天使用独立文件，减少两台电脑编辑同一文件；
4. 自动化遇到冲突必须停止并提示，不能自动选择一方覆盖；
5. 未提交内容存在时，不直接执行可能覆盖文件的操作；
6. 自动提交信息应清楚标记设备和时间。

一键同步预期行为

检查仓库
  → 有本地改动：先创建临时提交
  → 拉取远端更新并 rebase
  → 有冲突：停止并显示冲突文件
  → 无冲突：推送
  → 显示成功、提交编号和时间

第一期先用 PowerShell 脚本实现，不为同步功能开发 Electron。脚本需要单独测试断网、远端领先、本地未提交和冲突四种场景。

9. 安全发布方案

发布边界

私有仓库是内容源，当前 hejiahua007.github.io 是公开目标仓库。发布必须是单向、显式的。

候选内容同时满足以下条件才允许进入预览：

1. 文件已在宿舍长期主库中被明确选为发布候选；
2. Front Matter 包含 publish: true；
3. 文件类型在允许列表；
4. 不含明显的密钥、令牌或私有路径；
5. 用户在变更预览中确认。

发布流程

选择内容
  → 在宿舍长期主库中创建公开副本并人工编辑
  → 脱敏检查
  → 转换为 Jekyll 文章/数据
  → 显示新增、修改、删除清单
  → 人工确认
  → 写入电子简历仓库
  → 提交并推送

第一期不自动发布原始日记或完整工作日志。建议先生成公开副本，因为公开叙事与私人原始记录的结构、上下文和风险不同。

若未来确实要公开每日内容，也应按单篇启用，而不是全局默认公开。

10. Agent 设计边界

第一阶段 Agent 只生成提案，不直接改动正式知识：

• 汇总一周记录；
• 推荐值得提炼的知识、原则和时间线事件；
• 生成公开稿草稿；
• 标记可能的隐私或公司信息；
• 建议下一步行动；
• 显示建议将修改的文件和差异；
• 用户确认后执行。

需要禁止：

• 未确认时移动或删除原始记录；
• 静默覆盖原则旧版本；
• 自行把 publish 改为 true；
• 跳过人工确认直接推送公开仓库。

11. 分阶段路线图

阶段 0：基础搭建（1～2 天）

• 新建私有 life-vault；
• 创建精简目录和可调整模板；
• 用模板批量生成当月日记与工作日志文件；
• 两台电脑配置最小权限的 Git 身份验证；
• 明确宿舍长期主库的位置和备份方式；
• 创建桌面或开机入口，能快速打开当天文件。

验收：

• 两台电脑都能完成一次拉取、编辑、提交、推送；
• 宿舍端 Obsidian 能看到公司端新增文件；
• 未开发 Electron。

阶段 1：只验证持续记录（4 周）

• 每天只要求状态 + 一句话；
• 有精力时才增加日计划、时间块和工作日志；
• 每周做一次简短复盘；
• 不构建复杂 Agent；
• 不迁移旧 WPS 数据。

验收：

• 四周中至少三周，每周有五天记录；
• 低能量日记录耗时不超过 1 分钟；
• 中断后能直接从当天恢复；
• 日常操作未频繁出现 Git 冲突。

阶段 2：同步与发布自动化（2～3 周）

• 实现并验证一键同步脚本；
• 实现公开候选检查和预览；
• 人工确认后更新电子简历；
• 阶段性手动更新作品列表。

验收：

• 四类同步异常都有明确提示；
• 没有 publish: true 的内容无法发布；
• 发布前可以看到文件差异；
• 完成至少两次真实周发布。

阶段 3：辅助整理 Agent（稳定使用后）

• 周复盘草稿；
• 知识、原则和时间线提炼建议；
• 公开稿草稿与脱敏检查；
• 所有改动先展示 diff。

验收：

• Agent 实际减少周末整理时间；
• 建议可追溯到源记录；
• 不发生未经确认的删除、覆盖或发布。

阶段 4：决定是否开发专用软件

只有满足以下条件才评估 Electron/Vue：

• 已连续使用至少 8 周；
• 已记录现有工具中反复出现的具体痛点；
• 痛点每周出现多次；
• 脚本、模板、快捷方式或 Obsidian 插件不能合理解决；
• 专用界面带来的时间收益大于维护软件的成本。

届时根据痛点选择技术，不预设一定是 Electron。

12. MVP 评估指标

北极星指标

每周完成最小记录的天数。

首阶段目标：每周至少 5 天。

辅助指标

• 最小记录平均耗时；
• 每周开始过记录但完全没写的次数；
• 一周内有工作日志的天数；
• 周复盘耗时；
• Git 同步失败或冲突次数；
• 从记录中提炼出的知识/原则/时间线数量；
• 公开候选经人工否决的比例；
• 中断后恢复所需天数。

指标用于改进系统，不用于制造新的自我评价压力。单周失败不补记，也不清零长期进度。

13. 尚需通过使用验证的假设

以下问题不需要现在继续讨论，应通过四周 MVP 得到证据：

1. 每天两个文件（日记、工作日志）是否太重；
2. 公司电脑使用 VS Code 是否足够顺手；
3. 开机自动打开能否显著提升最低记录率；
4. 15 分钟晨间计划是否适合普通状态；
5. 周末 2 小时整理是否可持续；
6. 哪些字段和标签真正被用于检索；
7. 哪些发布内容对电子简历访问者有价值；
8. Agent 最值得优先减少哪一步的耗时；
9. 是否真的需要 Electron。

14. 下一步实施清单

进入开发前，按顺序完成：

• 新建或指定私有 life-vault 仓库；
• 确认公司电脑使用 SSH Deploy Key 还是细粒度令牌；
• 按本文创建目录和模板；
• 批量创建当月日记和工作日志；
• 确定宿舍长期 Obsidian 主库路径与备份方式；
• 确定公司电脑的“打开今天文件”方式；
• 运行四周记录实验；
• 记录实际摩擦，不在实验中途扩建系统；
• 四周后复盘并决定同步脚本和发布脚本的详细需求。

第一步不是写 Electron，而是让明天的第一条记录能够在一分钟内完成。