MONTHLY IMPROVEMENT REVIEW
逐月评估：本月要完善什么（LifeOS / Obsidian）
2026-01-17 · Zon（个人 LifeOS） · 每月 60–90 分钟
目标：每月只做 1 个系统改进，让下月更可重复、更少摩擦。
要点速览
- 只选 1 个改进点：从“最大摩擦 / 最大杠杆”出发，不做清单式大修。
- 把改进写成实验：假设 → 行为 → 验收指标（30 天可计数）→ 回滚条件（失败就撤）。
- 三张记分牌：Outputs（交付/发布/训练）· Habits（节奏）· System（数据完整度/自动化稳定性）。
- 优先级顺序：字段/命名一致性 → 模板与复用 → 自动化；避免“为了完善而完善”。
关键洞见
- 你已经有周/月回顾与脚本化看板；下一个台阶是让它们每月稳定产出“清晰的下一步”。
- 月度评估要分开看：结果（发生了什么）与 系统（是否让结果更容易发生）。
- 所有洞见依赖数据体检：缺记录会让你对“健康/发布/学习”产生误判，先补齐关键字段，而不是补全文。
- 无法在 30 天内验证的改动，会变成无限维护；把目标写小、写硬（可计数/可回滚）。
- 系统的 KPI 不是“笔记变多”，而是“减少下一步行动的阻力”。
步骤指南（新手友好）
60 分钟月度完善评估（建议每月 1 日固定执行）
| Step | Timebox | 做什么 | 产出（必须落成文字） |
|---|---|---|---|
| 1) 数据体检 | 10 min | 检查本月日记/周回顾/关键字段是否缺失；优先补齐“能影响判断”的最小信息。 | 缺口清单（≤5 条）+ 本月数据可信度（High/Med/Low） |
| 2) 结果回放 | 15 min | 扫一遍本月周/月回顾：3 个亮点、3 个拖累（用事实/次数描述）。 | Wins 3 条 + Drags 3 条 |
| 3) 找瓶颈 | 15 min | 把拖累归因到一个“关键变量”（crux）：精力、节奏、流程、数据口径、分发、环境。 | 本月最大瓶颈（只写 1 条） |
| 4) 设计实验 | 10 min | 为瓶颈选 1 个小改动：可计数、可回滚、能在 30 天内验证。 | 实验卡（假设/改变/验收/回滚） |
| 5) 落地 | 10 min | 把实验写入下月日历与模板；提前安排第一次执行（例如第 1 周）。 | 下月第 1 周日历安排 + One next action |
实验卡（把“完善”写成可验证的小改动）
- 假设：（为什么这个改动会带来结果/减少摩擦？）
- 改变：（你下月具体怎么做？最好可写成一条固定流程/模板/日历事件）
- 验收：（30 天内可计数：次数/比例/耗时；例：月度回顾耗时 ≤ 60 分钟）
- 回滚：（若没效果，下月立刻撤回到上月做法，避免“无限维护”）
SVG 图解
专家视角（best minds）
W. Edwards Deming（PDCA / 持续改进）
- Thesis：改进来自“过程 + 反馈”，不是来自感觉。
- Arguments：每月只做一个可验证的小改动，并把它变成流程，才能累积复利。
- Limits：过度量化会忽略情绪与创造性；用少量指标服务于判断即可。
- Quote：paraphrase（无网无法核验原话）
David Allen（GTD / Review）
- Thesis：复盘的价值是回到清晰的下一步动作。
- Arguments：月度评估必须落到一个“下月实验 + 下一个动作”，否则复盘只是写作。
- Limits：系统会变成项目；所以实验卡要小、要硬、要能撤。
- Quote：paraphrase（无网无法核验原话）
Tiago Forte（Second Brain / 可复用资产）
- Thesis：知识系统的衡量标准是“能否被复用，推动表达/交付”。
- Arguments：把模板、栏目、看板当作“可复用组件”，每月只打磨一个组件，让交付变更容易。
- Limits：如果没有明确的项目/表达目标，整理会变成无止境的收藏。
- Quote：paraphrase（无网无法核验原话）
Andy Grove（OKR / 关键变量）
- Thesis：只盯一个关键变量（crux），其余都是噪声。
- Arguments：月度评估最重要的产出不是“总结”，而是对下月关键变量的承诺与验收。
- Limits：单一变量会遮蔽系统性问题；因此需要先做“数据体检”确保判断可靠。
- Quote：paraphrase（无网无法核验原话）
方案
| Option | Best for | Upside | Downside | Key risk | First step |
|---|---|---|---|---|---|
| A：Lite（20 分钟） | 忙、但不想断掉月度节律 | 保住反馈回路，避免“越久不复盘越不敢看” | 诊断不深 | 只写感受，没有改动 | 填三张记分牌 + 选 1 条实验卡 |
| B：Standard（60 分钟） | 常规月份（推荐默认） | 有证据、有诊断、有实验，下月可验证 | 需要固定时间 | 过度分析，迟迟不落地 | 按“60 分钟流程表”走完，并把实验写进日历 |
| C：Upgrade（2–3 小时） | 系统摩擦显著上升/季度级调整 | 能做一次结构化清理（命名/字段/模板/自动化） | 容易占用创造时间 | 把“整理”当成产出 | 先写清楚本次升级的验收标准（例如：看板稳定 + 月回顾耗时下降） |
证据与置信度
| Claim | Evidence | Confidence | Source |
|---|---|---|---|
| 你已有月度回顾体系与目录结构。 | README 明确包含 00-LifeOS/Monthly-Reviews 与月度仪表盘。 |
High | README.md |
| 月度回顾包含可被“脚本/看板”消费的字段。 | frontmatter 中有 summary、goals_progress、reflection 等。 |
High | 00-LifeOS/Monthly-Reviews/2025年11月月度回顾.md |
| 关键风险是“口径/命名不统一 → 聚合不稳定”。 | review-system 报告已指出月度周详情聚合不稳定等断点。 | High | docs/review-system/index.html |
| 你有自动生成月度回顾的入口。 | 交互脚本内有月度回顾路径与内容模板。 | High | views/todo/interactive/controls.js |
下一步
- 在当月月度回顾末尾新增：系统改进（下月实验），只写 1 条实验卡。
- 建一个“系统改进 Backlog”笔记（任何想改的点先记这里，下月只挑 1 条）。
- 下月第一周做一次 10 分钟数据体检：缺失的日记/周回顾只补关键字段，别补全文。
- 对齐字段与命名：确保
summary/highlights/evaluation/goals_progress/reflection在模板与看板里口径一致。
细节（可选）
每月“数据体检”清单（10 分钟）
- 日记：本月缺失天数是多少？缺失是否集中在高压周？
- 周回顾：是否每周都有？命名是否可被月度聚合脚本匹配？
- 月回顾字段：frontmatter 与正文关键段落是否齐全（避免看板读不到）。
- 健康/发布记录：是否存在“做了但没记”导致复盘误判？
常见可改进点（高 ROI → 低 ROI）
- 口径统一：命名、字段、标签先统一，聚合与自动化才稳定。
- 模板复用：把高频写作（周/月回顾、发布文案）固化为模板，降低摩擦。
- 减少切换：把“看板入口”固定到一个页面，避免每次找文件。
- 自动化只做一步：先手动跑通两周，再自动化最痛的一步。
- 美化最后做：排版/样式属于低 ROI，除非它显著提升你打开的频率。
来源
收尾总结
你的系统已经够强；下一个阶段不是“再加功能”，而是“每月让它更可重复”。
- 先做 10 分钟数据体检，避免复盘误判。
- 把“完善”写成实验卡，只选 1 条，下月验证。
- 能减少摩擦/提高交付的改动才算完成；否则撤回。
一个下一步动作
在下一份月度回顾末尾新增“系统改进（下月实验）”，只写 1 条，并在日历里预约下月 1 日 60 分钟验证。
“Make the next month repeatable.”
— (principle)