Claude Code 使用 Opus 5：长任务、调试与代码审查实战（2026）

先选对任务：Opus 5 不是默认替代所有模型

Anthropic 对 Opus 5 的重点描述是长时间、多步骤工作，以及更强的自我验证。它特别适合难调试问题、跨模块修改、复杂代码审查和开放式工程任务。官方能力说明见 Working with Claude Opus 5。

第一步：把需求写成可验收的任务

不要只说“修一下订单问题”。更有效的任务说明应包含四部分：

目标：修复重复回调导致订单状态回退的问题。
现状：已支付订单偶尔从 completed 变回 pending。
约束：不要改变支付签名算法，不要修改无关页面。
验收：补充回归测试；重复、乱序回调均保持 completed；现有测试通过。

验收条件越明确，Opus 5 越能主动检查自己的工作。长提示词本身不是目标，关键是把不可破坏的行为写出来。

第二步：先探索，暂时不要改代码

面对陌生或大型代码库，可以先给出下面的探索指令：

先不要修改文件。请定位这个行为的入口、调用链、状态存储、并发边界和现有测试。
列出你实际读取过的关键文件，说明最可能的根因和仍需验证的假设。
最后给出最小改动方案、风险和验证命令。

这一阶段的产物不是“听起来合理的解释”，而是文件、函数、数据流和可验证假设。模型如果没有找到测试或关键状态写入点，就不应该立刻进入实施。

第三步：要求按风险组织计划

一个可执行计划至少要回答：

• 哪些文件必须修改，哪些文件明确不动。
• 旧数据、旧接口和并发请求是否兼容。
• 每一步完成后运行什么检查。
• 失败时如何回滚，是否需要数据库备份。
• 哪些假设尚未确认，需要先做实验。

对支付、认证、权限和数据迁移，先让 Opus 5挑战计划本身：“找出这个方案最可能造成线上事故的三个位置，并给出更小的实现范围。”这通常比直接要求“写得更完善”更有效。

第四步：分阶段实施并保留检查点

1. 先添加能够复现问题的测试或诊断信息。
2. 运行测试，确认修改前确实失败。
3. 只修改解决根因所需的最小代码。
4. 运行相关测试、类型检查和构建。
5. 检查差异，确认没有无关格式化和配置变化。
6. 更新剩余计划，再进入下一阶段。

长任务中，每个检查点应留下“完成了什么、验证结果、剩余风险、下一步”。即使会话压缩或中断，模型也能从明确状态继续，而不是重新猜测上下文。

第五步：把代码审查当成独立任务

完成实现后，不要只问“有没有问题”。可以使用下面的审查指令：

请以代码审查者身份重新检查当前差异，不要继续扩展功能。
优先寻找行为回归、竞态、权限绕过、数据丢失、错误处理缺口和缺失测试。
每个发现给出文件与行号、触发条件、影响和最小修复建议。
如果没有发现，也要说明尚未覆盖的风险和未运行的测试。

最好让审查阶段重新读取需求和差异，而不是完全依赖模型刚才的实现记忆。开发与审查使用不同会话时，独立性通常更好。

Opus 5 和 Sonnet 5 的组合工作流

• Sonnet 5：搜索文件、整理日志、补常规测试、执行明确的小修改。
• Opus 5：判断根因、审查架构、处理复杂实现、最终代码审查。
• 再回 Sonnet 5：根据已经确认的方案完成重复性收尾和文档。

这种分层用法比全程使用最高 Effort 更容易控制用量。关于三款 Claude 5 模型的完整选择，可以查看 Claude 5 模型选择指南。

长任务常见失败方式

• 任务边界无限扩大：修 bug 逐渐变成重构整个模块。
• 只相信测试通过：测试本身没有覆盖用户实际流程。
• 没有查看差异：混入无关格式化、配置或生成文件。
• 并行任务修改同一文件：造成冲突或互相覆盖假设。
• 把模型总结当验证：没有实际运行命令、浏览页面或检查产物。

一套可以长期复用的结束标准

Claude Code 任务只有在“需求逐项满足、相关测试通过、生产构建通过、差异已审查、未完成项已明确”后才算结束。Opus 5 更擅长主动验证，但工程责任仍在使用者：模型报告成功，不等于线上行为已经被真实验证。