audit-choices

审计决策

面对一个不错的决策，Agent 会忠实地实现它；凡是任务未明确说明的地方，Agent 都会自行决定——而且不会告知你，diff 也不会标出这些决定。审查数千行改动无法规模化，而且这种审查检查的是执行情况，而执行可能本来就没问题。可规模化的审计对象是决策：列出实施者自行作出的每一项决定，评判这份清单，并记录评判结果。

这关乎架构，而非错误。实现可以运行得完美无缺，却仍建立在用户从未作出的决定之上——数据结构、存储位置、依赖项、API 契约、以速度换内存的权衡——而这些决定对未来的工作都至关重要。用户需要了解它们，不是因为它们有错，而是因为现在需要由用户承担后果。

这纯粹是决策审计——不涉及修改代码，并且可以随时调用。任务是追溯：遍历本次会话中采取的每一步，以及每个子 Agent 采取的每一步（正在执行任务的实施者会追踪自己的步骤；否则就根据其报告、对话记录和 diff 进行还原），找出所有代表用户作出、但原始规范或提示词中没有说明的决定。这些决定的记录清单将取代代码，成为用户审查工作的依据——这正是整个审计的目的。根据评判结果采取行动（重做不合理的选择、落实暂定决定）由调用方负责：如果是在工作流运行中调用，就由实施工作流负责；如果用户阅读报告后调用，就由用户负责。

两种调用方式，相同的审计：

• 由工作流调用（逐轮或逐个切片）：审计该轮，将条目追加到清单中，然后返回；工作流在交还结果时呈现累积的清单。
• 由用户直接调用：审计眼前的全部工作内容（会话、分支或指定的变更），并立即呈现报告。只提供建议，不作任何修改。

工作流

1. 询问并追溯。 实现者报告完成后，询问：“在处理这项工作时，你做了哪些自己并不确定的选择？请全部列出。”——但要把自我报告视为起点，而非边界：Agent 往往会少报。自己追溯整个过程——会话中的步骤、子 Agent 的报告、差异、提交记录——并收集所有不在原始规范或提示词中、却已体现在工作里的决策。审查各个架构类别，而不只是可疑的修复：数据形态和格式、存储与命名方案、API 契约及其错误处理行为、新增的依赖、并发与性能权衡、范围的解释，以及未来代码会仿效的模式。审计自己的会话时，也要用同样的方法追溯自己的步骤。计划明确授权实现者自行决定的事项属于自由裁量，不是审计项。

2. 根据证据逐项分类。 是计划强制要求的，还是自行决定的？自行决定的事项需要仔细审查：这是通用方案，还是针对某个失败案例量身修补？每项选择的结论为：合理、不合理或需要用户决定——结论旁还要标注置信度：审计者有多确信用户会做出同样的选择。置信度用于排列报告顺序。只有确实只能由用户决定的事项（偏好、产品方向、外部成本）才标为需要用户决定；每个此类条目都要记录一个可逆的建议临时方案，让无需监督的调用者无需等待即可继续。审计绝不会阻塞运行：每个条目都是交由他人采取行动或审查的判断，而不是会让流程停下的问题。

3. 说明应更正的决策，不要勾勒补丁。 对于每项不合理的选择，条目要指出应从何种决策重新开始工作——也就是必须普遍满足的属性——而不是在现有基础上叠加一处编辑。基于错误决策打补丁只会保留原决策；审查清单后，由调用者决定是否重做。

4. 将每项选择都记入下方的审查清单，并将影响重大的合理选择提炼到计划交接内容中，让后续阶段把它们作为既定前提继承，而不是重新决策。

5. 按结论分组、按置信度排序后呈现审查清单。 审计的交付成果是审查清单，要交给下一位采取行动的人——运行中途交给调用工作流，运行结束时交给用户。每组结论对应一类行动：需要用户决定（连同临时方案作出决定）、不合理（根据更正后的决策重做）、合理（确认：用户现在认可并负责的架构）；每组内部的选择按置信度从低到高排序。审查清单较长时，报告开头要列出总体置信度最低的两三项，不论它们属于哪一组，作为“优先审查这些事项”的提示。合理的选择也不能略过。只有微不足道的自由裁量（内部命名、外观上的选择）才能合并成一行计数。

   默认情况下就要把每项写得让 5 岁孩子也能理解，不必等人要求。 读者没有参与整个会话：每个条目都要采用 eli5 的表达方式——用一个具体情境从头到尾讲清楚（触发事件、当前工作如何处理、未采用的替代方案会如何处理）；首次出现的每个专业术语都要解释；如果选择涉及控制流、顺序或时机，还要在决策层面写出伪代码。“受门控的请求会被丢弃，而不是延后”是标题，不是一个完整条目。如果压缩后的条目让用户不得不问“这项能解释一下吗？”，就说明它不合格；审查清单必须不依赖差异、规范或会话记录也能独立理解。

决策记录

一个专用文件，在每轮工作结束后仍会保留：与计划放在一起的 choices.md（当某个规格负责这项工作时，放在 specs/<feature>/choices.md）。每项经审查的决策各记一条：

• 时间 — 决策在哪一轮或哪个提交中落定。
• 决策 — 一行标题，随后用 ELI5 场景说明：触发事件、当前工作如何处理、尚未实现的替代方案会如何处理，并在原处解释专业术语。
• 缺口 — 计划中哪些内容没有明确说明，因而迫使人做出这项决策。
• 影响范围 — 这项决策会限制或促成哪些未来工作；用户为什么需要知道它的存在。
• 判定 — 合理 / 不合理 / 需要用户决定，并用一句话说明原因。若判定为不合理：写明从何种修正后的决策重新开始。若需要用户决定：写明建议暂行的决定以及如何撤销。
• 信心 — 审查者有多确定用户会做出同样的决定（低 / 中 / 高）。按等级递增排列报告。

记录规则：

• 已记录的决策即为定案：已写入记录（或已纳入计划）的决策，对后续轮次而言都是既定事实——不得重复列出，也不得重新决定。
• 记录是衡量计划质量的信号。如果条目集中在某个切片或领域，说明该处的计划含糊不清——应重新切分，或将该部分退回规格阶段，而不是永远对同一类决策进行分流。
• ELI5 必须在每次改写中保留。 上述条目格式——标题加上逐步展开的场景，并在原处解释术语——是存储格式，而非用于润色的展示格式。合并条目、整合条目、收尾时重新审查，或将条目复制到最终记录时，每条保留下来的记录都必须保留（或补回）完整场景。已知的失效模式正是这种压缩：收尾改写时把已记录条目缩成标题，导致读者不得不追问记录内容——“检查点按邮箱顺序加载行，并在较晚的引用具有更早的 createdAt 时拒绝该列表”看起来像是定案，但只有展开说明的版本（两个会话、每个会话各自的序号无法比较、共享的插入时间时钟）才能让读者真正判断这项决策。即使所有事实都还在，删掉场景的整合也算失败；保留了场景，却依赖构建过程中发明的标签（“重试封套”“证据接缝”）且未在使用处解释，也同样算失败。

规则

• “能运行”不是对决策的判定。 常见问题是偶然修复：扩大缓冲区、延长超时，或添加特例，其幅度碰巧足以覆盖失败输入，而根本原因仍未解决。要问是什么属性能保证修复普遍有效；如果答案是“这个案例通过了”，那么即使代码检查全绿，这项决策仍不合理。
• 宣告成功的时刻风险最高——恰恰在实现者最有信心时，那些未经审视的决策即将合并。绝不能因为结果看起来干净就跳过审查。
• 在非简单工作中，列表为空是警示，而不是通过。深入追问：任务中有哪些内容没有明确说明？一定有人填补了这些缺口。
• 审查不修改代码、测试或构建状态。发现不合理的决策就是交付内容，而不是修复它的许可——记录修正后的决策，并让代码树保持审查时的原样，使记录与代码树对调用者正在决定的事项保持一致。收集证据完全可以：阅读任何内容、运行现有测试、编写临时探针——但交接前必须移除所有探针。

完成

当本轮中的每个自拟选择都有一条带有判定结果的记录，每条不可靠的记录都注明了应从哪个更正后的决策重新开始，每条需要用户确认的记录都有一个可撤销的临时决定，并且台账已按判定结果分组、每组内按置信度从低到高排序，呈交给下一位处理者，且每条记录都能让人无需追问便看懂；同时，代码树保持原样时，审计才算完成。交接时如果展示的是差异而非这些选择，或者在审计期间应用了任何“修复”，都不算完成。