把长任务交给 Claude Opus 5.5：从交代任务到验收结果的四步

很多人用 AI 写代码的方式，是被上一代模型训练出来的：把任务切成一小步一小步，每完成一段就问「继续吗」，再补一句「请仔细思考」。

这套做法在旧模型上是有效的——不切碎，它就会跑偏；不催，它就想得不够深。

但 Opus 5.5 更能持续执行之后，这套做法反而成了拖累：本可以连贯完成的工作被你人为切断，你花在「盯进度」上的时间比模型干活的时间还多。

Anthropic 的使用指南讲了三个变化，对应三个用法调整。下面按一次任务的实际顺序讲。

一、开场：一次讲清三件事

旧做法：先给一个模糊目标，看它做出什么再逐步纠偏。

新做法：在单条消息里把整项任务说完，并且明确三件事——

• 做什么：完整的任务目标，不要分批发。
• 完成线（Done means）：什么情况算做完。比如「所有接口都换成新客户端、旧客户端已删除、测试全部通过」。
• 停顿条件（Stop and ask me only if）：什么情况必须停下来问你。比如「只有测试失败时才问我」。

为什么有效：早期测试者反馈，在少有人工干预的情况下，它可以连续运行编程任务数小时。你给的终点线越清楚，它越能自主排错直到达成；反过来，终点线模糊，它就会在半路不断试探你的意图。

一个可直接用的模板：

把支付相关接口从旧客户端迁移到新客户端。

完成标准：所有接口都使用新客户端，旧客户端已删除，测试全部通过。

只有在测试失败时才停下来问我。

二、删掉「请仔细思考」

这条听起来反直觉，但确实要删。

Opus 5.5 在每次回复前已经内置了深度思考，并且会自行评估这次需要多少计算量。你再加一句「仔细思考」，不会让它更聪明，只会让提示词变长、缓存更容易失效。

同样该删的还有：

• 「一步一步地思考」
• 「请确保你的答案准确」
• 「再检查一遍你的工作」

这些在旧模型上是有用的安慰剂，在新模型上是纯粹的噪声。

真正该加的是具体约束，比如：

• 「不要修改 tests 目录下的文件」
• 「如果涉及删除数据，先停下来问我」
• 「改动超过 200 行时先汇报方案」

三、长任务：用两个文件管住进度

如果你用 Claude Code 跑长任务，有两个文件值得固定下来。

CLAUDE.md——写停顿规则。哪些操作必须确认、哪些目录不能碰、测试没过怎么处理。这个文件每次会话都会被读取，等于给模型一份长期有效的行为准则。

TASKS.md——保存进度。把任务拆成清单，让模型边做边更新状态。这样即使会话中断，重开时也能接上，而不是从头再来。

为什么需要这两件事：模型能连续跑几小时，不代表你应该让它无人值守跑几小时。越是能跑久，越要把「什么时候必须停」和「做到哪了」这两件事显式化。

四、跨服务任务：分派子代理，但要核证据

如果任务涉及多个服务、多个代码库，可以让主 Agent 派子代理并行处理。

但有两条纪律：

• 子代理的汇报不等于完成。它可能只跑了一半就汇报「已处理」。要对照任务清单逐项核。
• 证据要能追溯。让它给出具体文件、具体行号、具体命令输出，而不是一句「已修复」。

五、验收：顺序很关键

任务结束时，不要先通读改动摘要。正确的顺序是：

1. 先看它需要你做什么。长任务结束时，它会说明做了什么、发现了什么、还需要你处理什么。第一眼先找这部分，确认没有阻塞项。

2. 再查代码和文档。确认改动范围、是否有不该动的文件被改。

3. 最后查未证实的结论。凡是它说「应该是」「可能是」的地方，都要你自己验一遍。

为什么这个顺序重要：如果你先读改动摘要，会误以为任务已经完成，然后跳过它真正需要你决策的部分。等第二天发现卡点，上下文已经丢了。

六、哪些操作必须保留人工确认

「放手让它跑」是有边界的。以下几类操作，无论模型多可靠，都要保留停顿规则和权限确认：

• 删除数据
• 强制推送（force push）
• 修改仓库外的文件
• 涉及支付、权限、生产配置的改动

判断标准很简单：这个操作撤销不了，就要有确认。

七、模型切换时怎么回切

使用中可能会触发模型自动切换（比如负载或额度原因）。遇到这种情况，按你所用的界面手动回切即可，不要继续用被切换后的模型跑完整个任务——不同模型的行为差异会累积成结果差异。

八、收尾：给自己留一份核对清单

每次长任务结束，花两分钟过一遍：

• 完成线是否真的达成了（对照你开场写的标准）
• 测试是否真的跑过（不是它说跑了就算）
• 有没有超出范围的改动
• 有没有需要你决策但被它自行决定的事

这四件事做完再提交。模型的效率提升，不应该以你的核查时间消失为代价。