规划与任务分解怎样测

用户只说 “修复失败测试”。Agent 还没有运行测试，也没有读错误输出，先写下三步。

优化认证模块
重构登录流程
更新全部测试

这份计划很整齐，也已经把任务带偏。一个失败测试被扩成整个认证模块，修改依据还没有出现，验证和失败处理也没有位置。

计划写得长、分点清楚，只能说明它会生成计划文本。评测更该看这份计划有没有管住后面的行动。

先查计划约束了什么

计划至少要守住目标。用户要求修一个失败测试，探索范围可以扩大，修改范围需要证据。尚未定位原因时，把 “重构登录流程” 写成既定动作，会把假设伪装成决定。

计划还要安排取证和验证。Claude Code 官方给出的代码修复路径会先运行测试、读取错误和源码，修改以后再跑测试。复杂任务也建议先探索代码库，再进入实现。具体顺序可以变化，证据先于高风险修改，验证晚于实际改动，这两条关系很难省。

遇到写入、删除、发送、部署和权限变更，计划中还要留下审批、回滚或停止位置。若当前权限不足，下一步可以申请明确授权，也可以结束并说明缺口。偷偷换工具达到同一动作，不应算灵活。

用依赖关系接纳多条路径

同一段代码可以先读测试，也可以先读实现。几个互不依赖的只读搜索，交换顺序通常没有影响。逐字比对一份 golden plan，会把这些合理差异当成错误。

可以把评测标准写成部分顺序。

复现失败  发生在修改之前
相关证据  发生在结论之前
代码修改  发生在重新验证之前
人工审批  发生在高风险执行之前
验证通过  发生在宣布完成之前

再补两类约束。must_have 写必须出现的动作或证据，forbidden 写不能发生的行为。登录用例里，必须有失败输出、最小修改和测试结果；没有证据就改遍认证目录，可以列为禁止行为。

计划成本也要算进去。一个改文案的任务被拆成十几步，Agent 会把大部分时间花在维护清单。多文件修改只写 “完成并验证”，又看不出探索、执行和测试的边界。评测需要同时抓遗漏与过度规划。

新证据出现时要允许改计划

计划无法提前知道所有工具返回。第一次测试显示问题在 session，原计划却假设 token 过期。此时改计划很正常。继续修改 token 文件，只因为它写在第一版清单里，才是规划失败。

测试里可以故意安排一次反转。让错误日志推翻初始假设，让必要工具返回权限不足，或者让用户中途缩小目标。Agent 应该更新假设、步骤与验证点，并说明哪条新证据触发了变化。

相应的 Trace 需要版本关系。

plan.id
plan.version
plan.goal
plan.assumptions
plan.steps
plan.dependencies
plan.verification_points
plan.risk_points
plan.revision_reason
plan.linked_tool_calls

revision_reason 要指向真实 observation。linked_tool_calls 用来核对它后来有没有执行自己承诺的关键动作。只有一段计划文字，没有版本和动作关联，测试者只能评价文笔。

怎样给规划打分

目标理解、关键步骤、依赖顺序、工具准备、验证、适应变化、成本与安全可以分开记录。评分时先用规则检查确定关系，再把开放部分交给 rubric。比如 “测试发生在修改后” 适合规则判断，“探索范围是否已经过大” 可能需要结合任务规模评审。

样本也要有差异。简单任务用来抓过度规划，模糊任务观察它会先查证还是直接改，多文件任务检查依赖关系，有副作用的任务检查审批和回滚。再安排一次工具结果反转，看看第二版计划有没有实际变化。

开头那份三步计划缺少的内容已经很清楚。它没有复现，没有证据，没有验证，还擅自扩大了目标。把三句话扩成十句话也救不了它。先运行失败测试，读清错误，再决定修改范围，会短很多，也会可靠很多。