四套日志方案，同一把尺子横评，结论偏得有点狠：三套早该扔。最后那套能活下来，不是因为它新，而是它终于把“记录”和“索引”分开了。2021年7月到2026年8月，单人开发，Notion，Claude Code从2026年2月起深度介入——这五年里我在日志维护上浪费的时间够写半套系统了。
先交代条件，不然后面全是裸结论。这四套方案只服务一个目标：下周的我能找回三周前的决策，下个月的我能看出这个月到底干了什么。不是团队知识库，不是给上级看的周报，不是审计留痕。如果你读这篇的场景是团队协作或者合规审计，别照搬我的结论，约束不一样。五个维度：可检索性、维护省心度、上下文恢复速度、保真度、持久化能力。
| 维度 | 方案一：月度结构化模板（2021-2025） | 方案二：月度滚动页（2026.2-4） | 方案三：每日一页+机器维护（2026.5） | 方案四：最终系统（2026.7起） |
|---|---|---|---|---|
| 可检索性 | 2 | 1 | 4 | 5 |
| 维护省心度 | 2 | 5 | 4 | 3 |
| 上下文恢复速度 | 2 | 1 | 4 | 5 |
| 保真度 | 3 | 2 | 3 | 4 |
| 持久化能力 | 3 | 1 | 3 | 5 |
评分逻辑里争议最大的就是保真度。我的定义是：日志在多大程度上反映你真实的工作内容，而不是你希望自己当时干了什么。方案二给2分，不是因为它记得少——恰好相反，它记得最多——是因为它把Claude Code的输出整段倒进去。机器说了九段话，我只敲了一行半截想法，页面看着丰满，实际我在给机器当速记员。方案一的保真度给3分，是因为那个“行动项、学习、代码片段”的模板我从2021年复制到2025年，几乎没填过。空栏目不是记录，是自我欺骗的骨架。
为了把这四套方案的真实差异摊开，我把2026年3月某一天的日志按四套格式分别重写。几个符号可能记岔了，但格式差异是准的，空栏目和整段粘贴都真实存在过。
# 方案一：月度模板（2023年风格）
3月14日
- fix: payments表索引调整
分支: feat/payment-index
行动项：
学习：
代码片段：
# 方案二：月度滚动页（2026年3月）
3月14日
claude --resume 关于seed数据怎么改
（粘贴约八千字符的Claude Code输出）
claude --resume 还没想清楚外键约束要不要加
（再粘贴约五千字符，其中两段是报错堆栈）
# 方案三：每日一页+机器摘要（2026年6月）
# 2026-06-12
> 🤖 会话摘要：完成order_spec.rb重写，spec套件从64秒降到2.5秒。
> PR #231，提交SHA a3f2c...
（个人笔记留白，一个字没有）
# 方案四：最终系统（2026年7月）
# 2026-07-15
> resume: claude --resume 2026-07-15-order-schema
> 机器摘要：会议记录修正——两个种子数据假设被推翻……
我的碎片：
- 红/绿状态别用对象，用标量。
- 最后一个块：明天继续schema迁移。
方案二在2026年4月死了，死法很典型：月度页面涨到75,000字符。当时有演示截止日期压着，Claude Code的输出一个接一个粘进去，每天的内容不是写的，是批量倾倒的。演示结束回头看，页面废了——我要找一条三周前的决策，翻了二十分钟没找到，最后放弃，凭记忆硬写。75,000字符什么概念？Notion那个月度页在浏览器里打开都卡，Ctrl+F定位到的关键词有几十个，每一个都指向一堆机器废话。检索灾难的本质不是数据太少，是数据太多且没有索引，多了比少了更糟。
那是我第一次对日志系统失去信心。前四年花在维护模板上的时间，比不上那二十分钟的挫败感。后来重读六个月日志，发现了从来没注意过的东西：一个孤立的GPS坐标，一张没有说明的截图，还有一个不应该明文存着的凭据。它们都静静躺在Claude Code输出的转储段落里，像没盖盖子的化粪池。日志系统如果连“别把凭据写进去”都守不住，就不是系统，是垃圾场。
方案三是过渡产物，2026年5月的每日一页加机器维护。要先说迁移的瑕疵：我是批量执行的，五月初两周的每日页面其实是在同一天晚上从月度滚动页里生成的，不是真正每天书写。那两周的“每日记录”是伪造的。当时给自己的理由是演示太紧，但事实是，我在制造日志的伪史。这个瑕疵记到现在，因为横评里最该警惕的就是伪历史——哪怕是你自己造的。
但方案三有实打实的进步。机器自动追加结构化摘要后，PR链接、工单ID、提交SHA、性能数据进来了。spec文件从64秒降到2.5秒这个数据，就是机器摘要自动带进去的。机器摘要比人肉记录强在哪？它不带情绪，也不带会议里的社交压力。7月10日我自己的笔记还在纠结“用对象显示红绿状态”的表层，同页的机器摘要已经纠正了会议里两个被种子数据推翻的假设。不是机器更聪明，是机器只记录数据变化，不记录人当时怎么想。人的笔记最容易记下“我以为”，机器记的是“它发生了”。
代价不是技术上的，是认知上的。机器摘要最大的问题不是记错，是制造完成感幻觉。你看着日志页里机器自动追加的一串PR、SHA、性能数据，觉得自己被记录得很好，于是不再逼自己把问题想清楚。7月28日我在日志里写：过多的浅层工作是不是导致了“大脑毛躁”而没有具体产出。我的判断是——不是“是不是”，是“就是”。那段时间每天跟Claude Code滚十个会话，日志自动追加十条摘要，看起来很忙，但真正能指认成决策的东西没几条。机器帮你把上下文存起来，不等于你思考过。它甚至让你更不思考，因为思考的紧迫感被“反正机器记着”消解了。日志的价值从来不在记录，在你为了记录而强迫自己做的那次压缩。
这就是为什么我最终在方案三里又加了一层。七月初开始，给自己定了一条：机器摘要照收，但个人碎片必须手写，并且只写两样——问题和指针。问题是你还没想通但必须想通的事，指针是claude --resume加一个能重新拉起上下文的关键词。听起来没什么，实际是承认了一个硬事实：日志不是上下文的容器，是上下文的索引。上下文寿命很短，不需要整个存进去，只需要一个能重新拉起的把手。
我还开始在文档里加一行说明：截至2026-07-13的时间点快照，实时工作副本维护在Claude Code中。这个动作不是多余，它把日志的边界画出来了。日志是快照，不是上下文。上下文活在Claude Code里，日志只留索引。把这两者混在一起，就是方案二那个75,000字符页面的死因。
场景化选型，三个场景。
| 你的场景 | 选哪套 | 原因 |
|---|---|---|
| 单人高频率跟AI协作，痛点是找回旧决策 | 方案四 | 机器维护格式，人只写碎片和问题，末尾resume指针接住次日 |
| 需要周报、季度自评、素材汇总 | 方案一但删掉模板 | 月模板不是不能用，是那三个空栏目从没被填过，删了才不骗自己 |
| 团队环境，日志可能被审计或同事接手 | 不用机器自动追加 | 机器摘要的失真风险在单人场景可容忍，在审计场景就是事故 |
没推荐方案二，不是它没用。它在2026年2月到4月帮我扛过演示压力，倒进去那一刻省了时间。但那是应急操作，压力下的缓存溢出，当长期系统是耍流氓。方案一我用了四年，在Claude Code进入之前是对的，当AI开始高频参与工作流，人工填模板的成本被抬到不可持续。约束变了，方案自然废了，不是方案一开始就错。
能留下来的规则只有一条：日志只记索引，不记内容。内容让机器去结构，碎片让机器去兜底，你要做的只有两件事——写下一个能让未来的你重新拉起上下文的问题，删掉所有你半年后不会再看第二眼的文字。75,000字符的教训就是：记录越容易，找回越难。日志变成内存转储的那一刻，它就已经不是日志了。