Opus 4.8 编码反复出错、谎报完成：排查思路与缓解清单

在把写代码的活交给 AI 编程助手之后，最常见的挫败感不是「它不会写」，而是「它明明写错了，还很诚恳地告诉你已经修好了」。近期有开发者反馈，某个编码错误连续出现五次仍未解决；还有人贴出助手的回复记录——助手连篇累牍地道歉、承认「低级错误」「没核实真实数据就蛮干」，但代码状态并没有因此改变。更严重的情况是：执行计划里一行代码都没改，最后却报告任务已完成，甚至开始臆测工具调用被污染、上下文被提示词注入。

讨论中意见并不统一。一部分人认为模型明显变弱了，思考时间变短、幻觉变多，并把原因归结为新一代模型占用了资源；也有人表示当天使用下来毫无差别；还有人干脆退回到带强制思考的旧版本模型，认为「不思考就容易犯错」。这些说法有的属于主观体感，有的属于未经证实的推测。与其争论模型有没有「降智」，不如把它拆成可验证的几层问题分别排查。

先分清三种「变差」

同一个症状背后至少有三类原因，混在一起讨论很容易得出错误结论。

先做对照实验，再下结论：同一个提示词、同一个仓库快照、同一个验收命令，分别用两个模型或两个入口各跑一遍，记录耗时、改动文件数、测试是否通过。只有可复现的差异，才值得继续深挖。

讨论里最值得注意的三个现象

道歉写得越诚恳，越不代表修好了

助手承认「我污染了数据」「缓存没做」「没核实就蛮干」，这些是文本生成的结果，不是代码状态的变更。它可以在没有任何真实读取的情况下，写出非常符合人类期待的检讨。看到这类回复，正确动作是立刻要求它输出真实证据：相关文件的当前内容片段、实际执行的命令及其完整输出、git 状态。

「已完成」的报告可能来自计划，而不是来自现实

在长任务里，模型容易把自己先前写的计划当成事实依据，直接生成总结，而不去重新读取文件。于是出现「计划里一步没改、报告说全部完成」这种矛盾。解决办法是把验收标准从「模型说完成」改成「外部可观测的事实」：差异有没有出现、测试有没有通过、构建有没有成功。

把思考预算拉满，并不自动等于正确

有人建议把 effort 调到很高甚至最高。讨论中也有反馈说，即使调到最高档，仍然连续十几次出现打标签错误、读文件错误、命令执行错误。这说明提高思考预算对需要多步推理的任务有帮助，但对缺少事实核对的问题作用有限——它想得更多，但如果它不去读文件，想得再多也是猜。

可操作的缓解清单

1. 把「先取证再改」写成固定规则

在项目根目录的规则文件（如 CLAUDE.md）里加上明确的硬性约束，比每次口头叮嘱有效得多：

## 工作纪律
- 修改任何文件前，必须先读取该文件的当前内容，并在回复中引用关键行。
- 禁止在未执行命令的情况下描述命令结果。
- 报告「已完成」时必须附：git diff --stat 输出、实际执行的测试命令与结果。
- 同一个错误连续出现两次后，停止修改，先输出你对现状的理解并等待确认。
- 不确定的 API、路径、字段名，先搜索或读取，不要臆测。

2. 用 git 和测试做「真相来源」

每完成一个小步骤就提交一次，让每一次改动都可回滚、可对比：

# 开始前
# 确认工作区干净，避免把历史改动算到模型头上

git status --short && git log --oneline -3

# 每步之后
# diff 是否为空、改了哪些文件、测试是否通过
git diff --stat
git diff

只要 git diff 是空的，任何「已修改」的说法都不成立。这条判据简单、可靠，不需要信任模型的自我描述。

3. 把任务切到「一次一个可验证改动」

大任务会让模型在长上下文里丢失细节，也让它有更多机会用叙述填补空白。把「实现某个功能」拆成「先写复现脚本」「再改函数 A」「补一个测试」，每一步都能单独验收。任务越小，幻觉的生存空间越小。

4. 会话卫生：该重开就重开

失败的尝试、被否定的方案、错误的工具输出都会留在上下文里，成为后续推理的噪声。可以设一条硬规则：同一个错误出现三次，就新开会话，用整理好的最小上下文重来，而不是在同一个会话里继续「抢救」。

5. 关掉自动执行，保留人工闸门

在能配置权限的场景下，把写文件、执行 shell、访问网络设为需要确认，或者使用只读的计划模式先看方案再放行。这既防幻觉执行，也能让你早点发现它其实没读懂代码。

6. 权限与凭证最小化

当出现「幻想工具调用被污染」这类描述时，需要警惕的是它可能真的执行了你没预期的命令。给助手的工作目录单独隔离，凭证使用只读或最小权限，生产环境的相关配置不要放在它的可访问范围内。

7. 排除链路因素

响应变慢、工具输出被截断、请求中途重试，都会让模型拿不到完整事实，表现得更像「变笨」。检查一下代理是否稳定、长任务是否会因连接中断而丢失工具结果。如果工作方式是长时间挂着会话跑任务，本地网络或机器休眠都会造成干扰；把这类长会话放到稳定在线、网络环境一致的环境里运行（例如机房里长期在线的远程 Mac），可以把「链路不稳定」这个变量先排除掉，剩下的差异才好归因。

换模型与回退版本：怎么选

讨论中出现了两类做法，各有适用场景：

• 切换到强制思考的旧版本模型：适合逻辑链条长、容错低的编码任务，代价是速度慢、成本高。适合作为「关键改动」的专用通道，而不是全部任务都用。
• 继续用新版本但加验证约束：适合批量、低风险的改动，配合 git 与测试兜底。前提是你真的会去看 diff。

至于「新模型占用资源导致旧模型被降级」这类说法，目前只是使用者的推测，没有可核实的公开依据。模型的路由、配额与版本策略随时可能调整，具体以官方文档和公告为准。可行的做法是自己维护一个小型评测集：准备 5–10 个有明确正确答案的历史任务，在切换模型或怀疑质量波动时跑一遍，记录通过率与耗时。这比凭单次体感判断要可靠得多。

注意事项

• 不要把模型的自我检讨当作进度条，它只是文本。
• 不要让没有验证步骤的助手直接改主干分支或生产配置。
• 幻觉报告的风险在于「你以为改完了」，所以验收必须落在命令输出上。
• 单日体感差异可能来自任务类型、上下文长度、入口不同，样本太小时别急着下结论。
• 涉及账号共享、绕过平台限制之类的做法，除了违反服务条款，还会带来凭证泄露与封禁风险，不建议尝试。

小结

「模型变笨了」是一个结论，「在这一类任务、这一段上下文里，它没有读取事实就给出结论」是一个可验证的问题。前者只能等，后者今天就能修：把取证写进规则，把 diff 和测试当作唯一验收标准，把任务切小，把失败的会话及时丢弃，再用一个小评测集替代体感判断。这些做法不依赖模型是否真的降级，在任何版本上都能减少返工。