用 Plan Mode 写出可执行的任务契约

复杂任务最常见的失败不是“模型不会写代码”，而是开始执行前没有统一目标。Plan Mode 让模型先调查和设计，再提交计划给用户审阅；真正可靠的计划还需要一份任务契约。

Plan Mode 能做什么

DeepSeek Harness 会把 Plan Mode 记录为每个 Agent 的协作状态。进入后，模型应当以调查和规划为主，并通过稳定的 exit_plan_mode 提交计划。用户可以批准，也可以选择继续规划并附上反馈。

Plan Mode 是软引导，不是安全边界。它不会代替沙箱与审批：如果你必须保证不写文件，应同时使用只读沙箱和合适的批准策略。

四段式任务契约

在任务开头固定写四部分：

目标：为登录接口增加速率限制。
范围：只修改 src/auth 与对应测试；不改变公共响应结构。
验收：新增测试覆盖阈值和窗口重置；现有测试通过；给出变更文件清单。
回滚：不执行数据库迁移；若必须改 Schema，停止并说明方案。

• 目标描述最终状态，不是“研究一下”。
• 范围列出允许和禁止触碰的区域。
• 验收要求可观察证据，而不是“看起来没问题”。
• 回滚提前定义高风险分支的停止条件。

规划提示模板

进入 Plan Mode。先读取最少必要文件，回答：
1. 当前行为由哪些入口、配置和测试决定？
2. 最小改动方案是什么？有哪些替代方案？
3. 每一步改哪些文件，如何验证？
4. 哪些假设尚未证实，哪些操作需要批准？
不要修改文件。提交计划后等待我审阅。

一个好计划应包含文件级影响、步骤依赖和验证命令，但不应把尚未确认的猜测写成事实。

审阅计划的五项检查

1. 证据：结论是否来自实际读取的代码或文档？
2. 覆盖：测试、文档、配置和兼容性是否被考虑？
3. 粒度：每一步是否小到可以独立验证？
4. 边界：是否出现任务范围外的重构或依赖升级？
5. 停止条件：遇到迁移、破坏性操作或未知凭据时会不会暂停？

不满意时，用“继续规划”给出具体反馈，例如：“保留现有 API，不引入新依赖；补充失败回滚和 Windows 验证。”

从计划切换到执行

批准后，让 Agent 按步骤推进，并在每一步结束时输出：

已完成：
证据：
与计划的偏差：
下一步：

如果调查发现原假设错误，不要默默改变目标；应更新计划并重新确认。

练习

选择一个只有文档或测试改动的小 Issue：

1. 先用原始一句话请求生成计划。
2. 再加入四段式契约重新规划。
3. 比较读取文件数、计划中的验证证据和范围外步骤。
4. 只批准第二份计划中的第一步，检查能否独立验收。

完成标准不是 Agent 写了多少内容，而是你能在执行前回答“它准备改哪里、为什么、怎样证明完成、何时停止”。

下一篇学习建立反馈闭环与独立复核。