Annual-Reviews 体系体检：改进点 × 可视化 × 价值信号
2026-01-31 · Zon · Personal · 00-LifeOS/Annual-Reviews
针对 00-LifeOS/Annual-Reviews 的结构、指标与看板提案（E→M→D）
你已经拥有一套高质量的 E→M→D 年度复盘系统与多年度数据看板；下一步关键是把“基线→增量”“决策→执行”“证据→对外输出”三条链路做成可视化闭环。
TL;DR
你这套 Annual-Reviews 已经从“模板复盘”升级为“证据驱动复盘”（E→M→D），并且拥有可运行的数据看板。 下一阶段的瓶颈不在“记录”，而在 基线可计算、决策可追踪、输出可复利 三件事的闭环。
- 把基线表结构化：让 Year Δ（增量）自动出现在看板里，而不是年底手算。
- 把决策变成对象：Continue/Stop/Bets 写进 machine-readable 字段，并在季度复盘自动对账。
- 把分享传播做成流水线：从“证据抽样”直接产出“可发布资产清单”（每月 1 个作品）。
- 把系统负债可视化：open tasks 不只是数量，还要看“年龄分布/长期未动的尾巴”。
- 把主题信号变成栏目：用高频主题（Workflow/自动化/AI 应用/健康工程化）定义内容主轴。
现状
- Annual-Reviews 使用说明（入口）
- 年度基线表（年初/年末，用于算增量）
- LifeOS 多年度统计看板（year/range/search + recap）
- 年度复盘工作台（证据 → 意义 → 决策，可编辑保存）
- 逐年总结（把叙事连起来）
- 项目组合复盘面板（主线项目梳理）
当前最强的设计选择（值得保留）
- 用 证据链 抵抗“记忆偏差”（而不是靠感觉写年终总结）。
- 用 E→M→D 强制把“总结”落成“决策”。
- 用 零依赖 HTML 看板 降低打开与分享成本。
数据来源：lifeos-stats-data.js
（generatedAt: 2026-01-17T13:54:03.925Z）
价值信号
- AI应用导航站 16
- Workflow 15
- 日程规划/GAP GOAL 7
- 独立开发产品 6
- 用户体验地图 6
- 域名 5
- notion 5
- 找工作诉求（before） 4
把这些“反复出现的主题”固定为内容栏目/产品方向，能显著降低选题与输出摩擦。
| Signal | 说明 | 可转化的价值 |
|---|---|---|
| 创造 + 工具 + 学习显著偏高 | 你在“把系统做出来”的阶段投入很多 | 下一步应把系统转成可展示资产（作品/报告/产品）并形成复利 |
| 分享传播相对偏低 | 不是没做事，而是“做了没包装/没发布” | 建立分享流水线：证据抽样 → 资产清单 → 发布节奏 |
| open tasks 信号很高 | 长期“进行中”会把能量锁死在未完结 | 把系统负债做成看板指标：总量 + 年龄分布 + WIP 上限 |
改进点
你已有 年度基线表，但它目前更像“人工表格”。
- 痛点：看板无法自动算增量（Year Δ）。
- 建议：给每年加一段 machine-readable（YAML/JSON）基线数据。
你已有 Continue/Stop/Bets 的结构（工作台也支持）。
- 痛点：季度/半年复盘时很难自动对账“做没做”。
- 建议：把 Bets 写成对象（指标/阈值/截止日/第一步）。
证据链越强，越应该被转成对外资产。
- 痛点：分享传播维度偏低，影响复利。
- 建议：每月从证据中固定产出 1 个可展示作品（网页/报告/文章）。
判定标准（避免“模板越做越大”）
- 任何新增字段必须满足：能被看板读取 或 能带来稳定输出。
- 任何新增看板视图必须回答一个明确问题（例如“我今年的增量是什么？”）。
- 每个年度最终只保留：10–20 条证据 + 4 类价值提炼 + 3 类决策。
可视化
- Baseline Δ：年初 vs 年末（健康/作品/收入/受众/系统负债）。
- Decision Tracker：Bets 的指标、截止日、完成度（季度自动对账）。
- Share Pipeline：证据 → 资产清单 → 发布（每月固定产出）。
- System Debt：open tasks 总量 + 年龄分布 + WIP 上限。
- Theme Trend：每年 Top 主题/实体，小倍数对比。
- Project → Artifact Map：主线项目到作品/报告的映射，识别“只做不出”。
路线
| Phase | 要做什么 | 产物 |
|---|---|---|
| 0–2 小时 |
|
一页基线 + 一页证据候选清单 |
| 1–2 周 |
|
可被脚本读取的 baseline + bets |
| 1 个季度 |
|
年度复盘从“总结”升级为“增长系统” |
今晚先做最小闭环：补齐 2026 年初基线 → 运行一次 node ./generate-lifeos-stats.mjs →
在工作台里把 Bets 写成“可验证”的 3 条。
Expert Views
- 你的系统已经很强在 Capture/Organize；下一步要把 Express 工程化：从证据直接产出可发布资产。
- 把“年度复盘”当成可复用的 中间成品（intermediate packets）：每月/每季沉淀，年底只是汇总。
- open loops 会消耗注意力：把 open tasks 变成“下一步动作 + 关闭条件”。
- 你已经有 Weekly/Monthly/Annual 结构：加一个 WIP 上限 能立刻降低系统噪声。
- Bets 必须可验证：每条 Bet 绑定 1–2 个指标（阈值 + 截止日）。
- 年度只抓 3 个 Key Results：健康能量、对外作品、增长（受众/收入）。
- 让图表回答问题：同一尺度、可对比、小倍数（按年并排）。
- 把“证据”贴近数据点：图表旁边放可回链条目，降低质疑成本。
Details (Optional)
- 扩展清单（数据结构 / 视图清单 / 脚本优化点）：report-20260131-235917-details.html
Closing Summary
你现在的优势是“证据链 + 系统构建能力”；真正的增量来自把它们变成 可展示资产 与 可度量结果。 把基线结构化、把决策追踪化、把分享流水线化，年度复盘会从“复盘”升级为“增长系统”。
One next action：补齐 2026 年初基线 → 跑一次数据生成 → 在看板落一个 Baseline Δ 视图（哪怕是最简表格版）。
Sources
- Annual-Reviews 使用说明 (../00-LifeOS/Annual-Reviews/README.md)
- 年度基线表 (../00-LifeOS/Annual-Reviews/年度基线表.md)
- 年度回顾看板模板 (../00-LifeOS/Annual-Reviews/年度回顾看板.md)
- 2025 年度复盘（证据→意义→决策） (../00-LifeOS/Annual-Reviews/2025年度复盘（证据→意义→决策）.md)
- 逐年总结（基于实际记录） (../00-LifeOS/Annual-Reviews/逐年总结（基于实际记录）.md)
- 年度复盘工作台（HTML） (../00-LifeOS/Annual-Reviews/年度复盘-工作台.html)
- LifeOS 多年度统计看板（HTML） (../00-LifeOS/Annual-Reviews/2025-12-26-LifeOS多年度统计看板/index.html)
- lifeos-stats-data.js（数据快照） (../00-LifeOS/Annual-Reviews/2025-12-26-LifeOS多年度统计看板/lifeos-stats-data.js)
- 开源调研与最佳实践 (../00-LifeOS/Annual-Reviews/年度复盘-开源调研与最佳实践.md)
- 项目组合复盘（2025-12-10） (../00-LifeOS/Annual-Reviews/2025-12-10-项目组合复盘/README.md)