起点：一份"还不错"的日总结
每个用 AI 的人都让它帮忙写过日总结。
"帮我总结一下今天干了什么。"
AI 会输出一份看起来还不错的东西：今天开了 3 个会、写了 xxx 代码、处理了 yyy 问题。格式整齐、措辞专业、逻辑通顺。
但用了两周后我发现——这东西除了让我当天看一眼舒服，后续什么用都没有。 没法查询、没法聚合、没法驱动任何下游流程。它是一个孤岛。
于是我开始改造它。改了 5 个版本，每一版都是被一个真实问题逼出来的。
45 天后，它从一份 20 行的文字摘要，变成了一个有 11 步强制 checklist、6 种证据源、自动触发 3 个下游流程的数据管道入口。
V1：裸文本日记（Day 1-3）
4 月 13 号，工作台诞生日。第一份日总结长这样：
# 日总结 — 2026-04-13 (周一)
## 工时分布
| 项目 | 工时(h) | 证据 | 备注 |
| 工作台搭建 | 9.5 | git 44 commits | 全天主力 |
| 1:1 | 0.5 | 日历 | 某某某 |
| 周会 | 1.0 | 日历 | ABO 周会 |
## 当日事件
- 建了 40 个人的档案
- 注册了 12 个项目
- 写了 3 个技能...问题：看着挺好。但数字从哪来？AI 说"9.5 小时"——怎么验证？日历说有 7 个会，我实际参加了几个？全凭 AI 猜。
V2：证据分级系统（Day 5）
到第 5 天，我发现工时统计一直不靠谱。AI 会把日历上所有会议都算成"参加了"，但实际很多我没去。
逼出来的解法：引入 6 级证据标准。
| 级别 | 名称 | 含义 | 可信度 |
|---|---|---|---|
| E1 | git 时间戳 | commit 精确时间 | ⭐⭐⭐ 铁证 |
| E2 | 消息记录 | 群聊/私聊时间线 | ⭐⭐⭐ 铁证 |
| E3 | 日历确认 | 有 VC 记录证明参会 | ⭐⭐⭐ 铁证 |
| E4 | 文档痕迹 | 文件修改时间 | ⭐⭐ 间接 |
| E5 | 推算 | 根据上下文推理 | ⭐ 需确认 |
| E6 | 日历未确认 | 仅有日历事件 | ⚠️ 不可信 |
V2 之后的日总结：
| 项目 | 工时(h) | 证据 | 备注 |
| 工作台 | 7.5 | E1 (24 commits) | D8迁移+chat系统 |
| 某项目 | 0 | ⚠️E6未确认 | 日历有但无参会证据 |
| 某周会 | 1.0 | E3 (calendar-confirmed) | 用户确认参加 |进步：现在每个工时数都有证据等级。标 E6 的就是"我不确定你去了"。用户看到 ⚠️ 就知道要人工确认。
但新问题出现了：确认流程是口头的——AI 问一句"你参加了吗"，用户答了，但答案没有持久化。下次新会话又得重复。
V3：流程 Checklist（Day 25）
到 5 月初，日总结已经从"随手写"变成了有固定步骤的流程。但步骤是隐含在 AI 的"脑子里"的——有时候做了 A 步跳过了 B 步，没有地方追踪。
逼出来的解法：显式 checklist。
## 🧾 总结过程 Checklist
| Step | 状态 | 证据/说明 |
| 0 时间范围确认 | ✅ | 用户确认 2026-05-07 周四 |
| 0.1 vc confirm | ✅ | 4 confirmed + 1 has-vc |
| 0.2 daily-notes 往返 | ✅ | 补录消费完成 |
| 0.4 +daily-snapshot | ✅ | repo-snapshot 已生成 |
| 0.5 +discover-conversations | ✅ | 18 chats 发现 |
| 0.6 +collect-conversations | ✅ | 295 msgs 采集 |
| 0.V 机器核验 | ✅ | verify_daily.py exit=0 |每个 Step 有编号、有预期产物、有通过条件。AI 不能跳步骤——checklist 在最终产物里可见，哪步没做一目了然。
V4：数据管道化（Day 30）
Checklist 解决了"步骤不跳"的问题，但每一步还是手动触发的——AI 先做 snapshot，再做 conversation discovery，再做 collect...
逼出来的解法：把每一步变成有确定性输入输出的数据管道。
核心变化：
- repo-snapshot：一个 Python 脚本扫描所有活跃仓库，生成标准化 YAML（commits 数、文件变更、作者分布）
- conversation-discovery：调飞书 API 获取当日有新消息的群/人列表
- collect-conversations：增量采集消息原文
每一步产出一个文件，下一步读取上一步的产出。AI 在中间做的事变得越来越少——它更像是管道的"调度器"，而不是"生成器"。
V4 的 frontmatter：
---
type: summary
date: '2026-05-28'
repo_snapshot: summaries/snapshots/repo-snapshot-2026-05-28.yaml
conversation_discovery: summaries/snapshots/conversation-discovery-2026-05-28.yaml
evidence_sources: [repo-snapshot, conversation-discovery, comms/signals]
total_hours: 13.5
meetings_attended: 8
commits_total: 46
signals_extracted: 19
---注意 repo_snapshot 和 conversation_discovery 字段——它们指向可追溯的数据文件。日总结不再是"AI 生成的文本"，而是"有数据支撑的结构化产物"。
V5：机器验证 + 下游触发（Day 45）
最后一个版本解决了终极问题：怎么知道日总结本身是对的？
即使有了 checklist + 数据管道，AI 还是可能输出不一致的内容——比如说"今天 8 场会议"但表格里只列了 7 场；或者 frontmatter 写 commits_total: 46 但正文说"30 个 commit"。
逼出来的解法：verify_daily.py — 一个 Python 脚本，在日总结生成后、commit 前自动运行。
它检查什么：
- V1: frontmatter 计数 vs 正文数字一致
- V2: 引用的 snapshot 文件存在
- V3: 工时总和 = TIMESHEET 表各行之和
- V4: 所有 vc-confirmed 会议在正文有对应行
- V5: 无 orphan 引用（文件路径不存在）
退出码=0 才允许 commit。 不是 warning——是 hard fail。
从"日总结"到"系统入口"
V5 之后，daily summary 不再只是"回顾今天"——它变成了多个下游流程的触发器：
一份日总结生成后：
- action-hub 消费其中的 actions（待办分级）
- team-pulse 消费团队互动信号
- project-tracker 消费关键决策
- timesheet-submitter 消费工时表自动填报
- weekly summary 把 5 份 daily 聚合成周报
日总结不是终点——是每日数据的结晶点，是下游所有流程的入口。
5 个版本的对比
| 维度 | V1 | V2 | V3 | V4 | V5 |
|---|---|---|---|---|---|
| 结构 | 纯文本 | 证据分级 | +Checklist | +数据管道 | +机器验证 |
| 信息源 | AI 猜测 | E1-E6 分级 | 同左 | 自动采集 | 自动采集 |
| 验证 | 无 | 人工标注 | 人工查 checklist | 管道产物可追溯 | 脚本强制 |
| 下游 | 无 | 无 | 无 | 初步 | 5 条管道 |
| 字符数 | ~800 | ~1500 | ~2500 | ~4000 | ~5000 |
| 人工参与 | 几乎零 | 确认参会 | 确认+查漏 | 确认 | 确认(最少) |
什么在驱动迭代？
回看这 5 个版本，迭代不是"我计划好要做 5 版"——而是每次被一个真实的痛点逼着往前走一步：
- V1→V2：工时统计不靠谱 → 证据分级
- V2→V3：步骤会被跳过 → 显式 checklist
- V3→V4：每步手动太慢 → 自动化管道
- V4→V5：产出可能不一致 → 机器验证
- V5→下游：日总结孤岛 → 触发管道
每一步的共同模式：发现一个"我以为 AI 做了但实际没做"的缺口 → 用结构化约束填补。
你能复用什么
如果你也让 AI 写日总结：
- 给工时标证据等级 — "AI 说 9 小时"毫无意义；"git 证明 7.5h + 日历确认 1h"才可信
- 写一个 checklist — 哪怕只有 3 步，也比"AI 自己决定"好
- 让日总结产出结构化数据 — frontmatter 里的数字比正文的叙述更有用
- 把验证脚本化 — 一个 20 行的 Python 脚本比"我眼睛看"可靠 10 倍
最重要的认知转变：日总结不是给你"看"的——是给系统"用"的。 当你把它当成数据管道的入口而不是文本产物，设计决策就完全不同了。
45 天，5 个版本。每一版都比上一版多一点"不信任 AI 的自觉"，多一点"用机器验证替代人工假设"。这可能是和 AI 协作最重要的心智模型：把 AI 当成需要流程管理的初级员工，而不是可以全权委托的高级顾问。