LIFEOS · WEEKLY REVIEWS
Weekly Reviews：改进点 × 可视化 × 价值信号
2026-02-01 00:18 · Zon（自己） · 00-LifeOS/Weekly-Reviews
把周回顾从“写完”升级到“可量化可复用”
基于周回顾库的结构与评分表，给出三层升级：数据卫生（可解析/可汇总）→ 可视化看板（趋势/缺口）→ 反馈回路（DoD/Stop doing/证据链）。
auditobsidianweekly-reviewdataviewjsdashboardevidence
TL;DR
- 你已经有一套结构化周回顾（五大目标 + 评分表 + 反思），可视化的前提基本齐了。
- 最大改进点是“可汇总性”：评分/证据/下周动作目前更偏自然语言与表格，跨周汇总成本高。
- 从样本均值看：创造丰盈最高（≈8.00），分享传播最低（≈5.88）。把 share/health 当作系统优先级更划算。
- 一个关键风险：做了但没记录会让复盘被“证据缺失”误导（你在 2025-12-29 周回顾里已经点到）。
One next action：打开
Weekly Review Dashboard.md 看最近 12 周趋势；然后把“评分写入 frontmatter（机器可读）”加进模板。现状快照
WEEKLY NOTES
21
DATE RANGE
2025-08-11 → 2026-01-04
MISSING WEEKS
0
AVG CREATE
8.00
AVG SHARE
5.88
AVG HEALTH
6.17
AVG LEARN
6.75
AVG TOOLS
7.11
Data Quality
- 周回顾覆盖：
2025-08-11 → 2026-01-04（共 21 份）。 - 缺失周起始日：0（无）。
- 建议长期保持：frontmatter YAML 必须可解析（否则 Dataview 聚合会漏数）。
High-Leverage Upgrades
- 评分入 frontmatter：跨周趋势图立刻稳定。
- 下周 3 个最小交付：把复盘变成推进器（并写死到日程）。
- Stop doing：减少“多线程产物扩散”的隐性成本。
- 证据链：每个目标至少 1 条可点击证据（链接/页面/脚本/发布）。
图解
优化清单（按投入产出排序）
15 分钟/周（最小闭环）
- 写完 DoD 5 项：概览一句话 + 五大目标进展 + 亮点 3 条 + 评分表 + 下周 3 个最小交付。
- 给每个“亮点”补 1 个证据链接（哪怕只是 Obsidian 内部页面）。
- 补 1 行健康记录：做了什么 + 时长/次数（避免“做了但没进系统”）。
60 分钟/周（系统升级）
- 把 5 个评分写进 frontmatter（机器可读）。
- 把 share 的“发布节律”做成硬约束：每周至少 2 次可复用模板的发布。
- 把“Stop doing”写成 1 条（本周最该停的事情）。
- 用看板巡检：是否缺评分/缺下周动作/缺证据。
推荐的 frontmatter schema（示例）
---
start_date: 2026-02-02
end_date: 2026-02-08
type: weekly_review
tags: [WeeklyReview, 2026年, 6周]
week: 6
year: 2026
score:
health: 7
create: 8
share: 6
learn: 7
tools: 8
kpi:
exercise_sessions: 3
deep_work_hours: 12
posts_published: 2
---要点：把“评分/关键 KPI”放到 frontmatter，正文仍然保留叙事与证据链接。
可视化怎么落地（Obsidian）
已落地（本次新增）
- 看板页：
00-LifeOS/Weekly-Reviews/Weekly Review Dashboard.md - DataviewJS 视图：
views/reviews/weekly-dashboard.js（解析评分表并画均分条形图）
打开看板页即可看到：最近 N 周列表 + 均分条形图 + 缺失周提示。
下一步建议的 3 张图
- 评分趋势（折线/小多图）：每个目标一条线（需要 frontmatter.score）。
- 节律热力图：运动/发布/深度工作是否达标（需要 kpi 字段或统一记录格式）。
- 证据链索引：每周“亮点”对应的链接清单（让成果可复用）。
依赖说明（你现在已经具备的）
- 周回顾里已经在用：
views/reviews/week-diary.js（从 DailyRecord 聚合每日总结）。 - 月度汇总里已经在用：
views/reviews/month-weeks.js（按元数据聚合周回顾）。 - 示例周回顾（证据链思路写得很清楚）：
2025-12-29周回顾.md - 模板入口：
Weekly Review Template.md
Best Minds 视角（模拟）
David Allen（GTD · Weekly Review）
周回顾的目标不是写得好，而是让系统“可信”。关键问题：我是否完整掌握了承诺清单，并明确下一步动作？
- 把“下周 3 个最小交付”当成 weekly review 的硬输出。
- 消灭空白占位；没有证据就补 1 行记录。
Tiago Forte（Building a Second Brain）
复盘的价值在于把经历变成可复用资产。关键问题：本周产出能否被下周的我快速复用？
- 每个“亮点”必须对应一个可点击的产物（页面/脚本/发布）。
- 把多线程扩散收敛到“入口页”。
Cal Newport（Deep Work）
用周回顾对抗伪生产力。关键问题：我是否用时间/注意力换到了高价值产出？
- 加入 1–2 个领先指标（例如 deep work hours）。
- 用 Stop doing 减少上下文切换。
Deming / Dalio（持续改进）
周回顾是 PDCA：计划→执行→检查→调整。关键问题：本周最大的系统性痛点是什么？我做了什么机制修复？
- 每周写 1 条“原则/机制修复”。
- 让复盘产出“下一次更容易做到”的系统改动。
三种升级路径
| Option | Best for | Upside | Downside | First step |
|---|---|---|---|---|
| A · 保持叙事 | 只想更顺手 | 模板统一 + 下周 3 交付 + 证据链，立刻提升复盘质量 | 趋势分析仍然靠人工 | 把 DoD/Stop doing 固化到模板 |
| B · 数据优先 | 想要可视化与趋势 | 评分/KPI 入 frontmatter → 看板与图表稳定、可自动化 | 需要一点点结构化输入成本 | 新增 frontmatter.score（5 个分数） |
| C · 自动化闭环 | 长期维护、减少手填 | 自动拉取发布/运动/提交等数据，周回顾更像“仪表盘” | 需要维护脚本/数据源 | 先挑 1 个 KPI（例如运动次数）做到自动统计 |
证据与可信度
| Claim | Evidence | Confidence |
|---|---|---|
| 周回顾库覆盖了一个连续区间 | 2025-08-11 → 2026-01-04（本地扫描 21 份） | High |
| 平均评分：创造丰盈最高、分享传播最低 | 从评分表提取（create≈8.00, share≈5.88；解析覆盖见图） | Med（依赖评分表可解析） |
| “做了但没记录”会误导复盘 | 样本中已有明确自述：周回顾误判来自证据缺失（见 2025-12-29 周回顾） | High |
Next Steps（建议顺序）
- 用看板巡检最近 12 周：哪些周缺“下周 3 交付/证据/评分”。
- 把
frontmatter.score写进模板（以后每周多写 30 秒，换来长期可视化）。 - 下周只抓 1 个系统性修复：share 节律 or health 节律（二选一）。
- 把本周 3 个最小交付写死到日程（不要只写在周回顾里）。
Sources（Local）
Closing Summary
最关键的升级不是写更长，而是把周回顾做成“可汇总的系统”。
- 把评分/关键 KPI 写进 frontmatter（机器可读）。
- 每周只承诺 3 个最小交付（并写死到日程）。
- 每个目标至少 1 条证据链接，让复盘不靠记忆。
One next action
现在就打开 Weekly Review Dashboard，检查最近 12 周的趋势，然后更新模板的 frontmatter（新增 score 字段）。
把结论变成第一步。
— Closing Summary · Weekly Reviews