一次典型的浪费
上周我在终端里和 AI 助手花了四十分钟讨论博客发布系统的重构。我们聊清楚了目标——把 Hugo 静态生成换成自动化流水线，支持一键发布到多个平台；聊清楚了架构——用 GitHub Actions 做 CI，本地用脚本触发，模板渲染交给 Jinja2；甚至拆出了十个执行步骤，标注了依赖关系和每一步的验收标准。
聊完之后我去做别的事了。第二天再打开终端，新会话，AI 对昨天的一切一无所知。我又花了二十分钟重新解释上下文，还遗漏了两个昨天讨论过的关键决策。
四十分钟的好工作，只留下我脑子里模糊的记忆。这记忆还不可靠。
这不是偶然。只要你在终端里和 AI 做过任何稍有深度的规划工作，你一定经历过这种浪费。对话线程是临时的——会话结束，上下文蒸发。好的想法、已形成的结构、中间决策，全部消失。
核心矛盾：规划工作产出的是持久价值，但承载它的对话线程却是易失的。
什么是 durable plan
我想解决这个矛盾。答案是：把临时线程中产生的规划内容，转化为一个持久的、可恢复的计划对象——我把它叫做 durable plan。
durable plan 本质上就是一个文件。它存在于磁盘上，不依赖任何会话的生命周期。它记录的是规划的结构化产出：目标、步骤、依赖、验收条件、当前进度。下一次开新会话时，AI 可以直接读取这个文件，从上次的进度接续，而不是从零开始。
关键不在于"保存"本身——任何会话工具都有导出功能。关键在于何时保存、保存什么、如何让这个过程不依赖人的自觉性。
三次尝试，三次教训
尝试一：手动保存对话摘要
最直觉的方案：每次聊到有价值的内容，手动让 AI 写一段摘要保存到文件。
我试了一周。结果是：十次里有八次我懒得说"保存一下"。人在思考的时候不想被流程打断，尤其是在终端这种沉浸式环境里。手动保存的要求本质上是在对抗人的工作惯性——而人的惰性总是赢。
失败原因：把持续性负担放在了用户身上。
尝试二：会话结束时自动保存摘要
既然手动不行，那就自动化。我写了个 hook：每次会话结束时，自动生成对话摘要写入文件。
摘要确实生成了。但质量一塌糊涂。一次四十分钟的规划会话，摘要变成了这样：
"讨论了博客系统的重构，涉及 CI/CD、模板渲染、多平台发布等多个方面，下一步需要进一步明确具体实施方案。"
这不叫摘要，这叫废话。问题出在哪里？四十分钟的对话里，只有大约三成内容是真正的规划产出——目标声明、步骤分解、依赖关系、验收条件。剩下七成是探索性的讨论、走弯路、纠正误解、闲聊。自动摘要把这两类内容等权混在一起，信噪比极低。
更糟的是，每次新会话打开这些摘要，AI 要先从一堆噪声中提取有用的结构信息，效率比直接重新讨论好不了多少。
失败原因：保存了太多不该保存的东西，信噪比太低。
尝试三（最终方案）：识别规划信号，结构化保存
前两次的教训指向同一个方向：不要事后保存整个对话，而要在对话过程中识别规划类内容，只保存结构化的规划产出。
这就是"全线程触发句规范化计划"的核心思路。
具体来说，我在 AI 助手的系统指令中加入了一套规划信号识别规则。当对话中出现以下模式时，AI 自动将相关内容结构化为 durable plan 并写入文件：
- 目标声明：用户说"我要重构 X"或"目标是实现 Y"
- 步骤分解：对话中出现"第一步…第二步…"或"先做 A 再做 B"
- 依赖关系：提到"C 依赖 B 完成"或"A 和 B 可以并行"
- 验收条件：定义"完成后应该能…"或"判断成功的标准是…"
- 风险识别：提到"最大的风险是…"或"需要注意的是…"
当这些信号出现时，AI 不是事后总结，而是实时地将结构化内容追加到计划文件中。计划文件是增量构建的——每出现一个新的规划信号，就多一段结构化内容。最终产出的不是一篇叙事性摘要，而是一份结构清晰的计划文档。
回到博客重构的例子。那次四十分钟的对话中，AI 会在以下时刻自动写入：
- 用户说"我要重构博客发布系统"→ 写入目标声明
- 我们讨论用 GitHub Actions + Jinja2 的架构 → 写入技术方案
- 我们拆出十个步骤 → 写入步骤分解和依赖图
- 我们讨论每步的验收标准 → 写入验收条件
- 用户说"第三步可能有缓存问题"→ 写入风险项
最终产出的计划文件大概是这样：
# 博客发布系统重构计划
## 目标
替换 Hugo 静态生成，建立自动化发布流水线
## 架构决策
- CI: GitHub Actions
- 模板: Jinja2
- 触发: 本地脚本
## 步骤
1. [ ] 搭建 GitHub Actions 基础框架
2. [ ] 实现 Jinja2 模板渲染管线
3. [ ] 风险: 本地缓存可能导致旧模板 → 验收: 清缓存后重新生成
...
这改变了什么
最直观的变化：新会话开始时，说一句"加载博客重构计划"，AI 直接读取文件，从上次停下的地方继续。不需要二十分钟的上下文重建。
更深层的改变：对话的产出不再绑定于对话本身。四十分钟的讨论不再是"聊完了就没了"，它变成了一个可以迭代、可以恢复、可以传递给其他 Agent 执行的计划对象。
在多 Agent 协作场景下，这个价值更大。一个会话产出的计划，可以被另一个 Agent 直接读取并执行。规划者和执行者通过 durable plan 这个中间产物连接，不需要共享会话上下文。
下次我会怎么做
如果让我现在重新设计这个能力，我会做三件事：
第一，把规划信号的识别做更细。 目前只覆盖了五种基本信号，实际工作中有更多隐性的规划行为。比如用户反复追问"那如果 X 失败了怎么办"，这本质上是风险分析；用户在两个方案之间来回比较，这是方案选型。这些都应该被识别并结构化写入计划。
第二，给计划文件加进度追踪。 目前计划是纯 Markdown，进度用 checkbox 标记。但真正好用的话，应该有一个轻量的状态机制——每个步骤标记 pending/in-progress/done/blocked，加上完成时间和阻塞原因。这样新会话加载计划时，一眼就知道该从哪里继续。
第三，支持计划的合并和分支。 有时候一个计划在执行过程中会被推翻或修正。当前的做法是直接编辑文件，但没有版本对比。应该让计划本身有版本历史，新会话可以看到"上次计划在步骤 4 被修正了，原因是…"，而不是只看到修正后的最终状态。
说到底，durable plan 解决的不是"保存"的问题，而是让对话中的规划产出脱离对话的生命周期独立存在。当思考的产物不再随会话消失，每一次深度对话都变成了一种投资——它的回报在未来的每一次会话中被持续兑现。