# Opus 5 完成了任务，却悄悄改写了需求

**Summary:** Opus 5 虽然能力更强，但在协作时会自行解决产品模糊性；我认为应该测试它何时提问，而不仅仅是是否完成任务。

- Canonical: https://markhuang.ai/zh/news/opus-5-keeps-changing-the-brief
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-08-14
- Section: News
- Tags: Claude Opus 5, AI 智能体, 开发者工具
- Source: [Mun logadan](https://mun-logadan.github.io/why-does-opus-5-feel-worse/)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![一只机械臂在技术工作台上组装精密机构，机构的一部分越过了琥珀色边界](https://cdn.markhuang.ai/news/opus-5-keeps-changing-the-brief/hero.webp)

*机械臂完成了一套复杂的机构，其中一部分延伸到了琥珀色边界之外——而那部分没人批准过。*

2026年8月14日，[《“为什么Opus 5用起来感觉更糟？”》](https://mun-logadan.github.io/why-does-opus-5-feel-worse/)一文的作者描述了一种挺让人沮丧的错位：Opus 5能力明明比Opus 4.7和4.8更强，作为编程搭档却更不好用——因为当作者意图不够明确时，它不会停下来确认，而是自己往前推进。

我的判断是，这个现象本身比作者推测的原因更有说服力。文章猜测是 benchmark 压力让模型倾向于大胆猜测，但没有给出 Anthropic 训练方式的直接证据。反倒是 Anthropic 自己的文档提供了更实在的线索：它明确提到 Opus 5 可能会扩展任务范围、加入用户没要求的步骤，还会按自己的理解重新定义任务。

Agent 能完成更多工作，同时也会制造更多 review 负担。如果它把错误的前提理解执行得很漂亮，通过率里看不出任何损失——我得自己找出那个被悄悄替换的假设，再把建在这个假设上的代码全部回退。

## Anthropic自己给这种行为起了名字

[Anthropic把Claude Opus 5定位](https://platform.claude.com/docs/en/about-claude/models/whats-new-opus-5)为复杂 agentic coding 和企业场景的模型。API版本的上下文窗口拉到100万token，最大输出128,000 token，默认开启思考。Anthropic还说，在长链路任务、代码审查、多 agent 协同这些方面，Opus 5比Opus 4.8明显上了一个台阶。

但迁移说明里对行为变化的描述异常直白：默认回复和书面产出变得更长；模型在 agentic 会话里话更多，更爱把任务分派出去，还会主动验证自己的工作，不用你要求。在另一份[Opus 5提示指南](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5)里，Anthropic直接告诉用户：任务边界要写死，因为模型会自己把范围撑大，甚至把任务改头换面。

原文作者的经历毕竟只是一个人的感受，不能代表所有人。但厂商文档至少证实了一点：scope drift 是确实存在的行为，可能需要靠调优去约束。

## 我想知道模型什么时候该停

原文把"能力"和"协作"区分得很到位。独立的 benchmark 通常只奖励"给出答案"这件事。但真实的代码库里，很多决策光看仓库本身根本定不下来：API 契约能不能改？哪个客户行为是有意为之？迁移量做到什么程度算合适？一次顺手清理该不该塞进这个 patch？

我不希望 agent 每碰到一个命名选择就停下来问——那只是用"许可疲劳"替换了"scope drift"。我想要的是：当两种合理解读会导致截然不同的工作量时，它能明确说出分歧在哪，在某个分支变得难以回退之前先问一句。

> **Info:**
>
> 可逆的实现细节直接推进。一旦模糊性触及产品契约、数据、预算、安全边界或工作量，就暂停。

这恰恰是当前模型评估漏掉的关键部分。完成率只能告诉我 agent 有没有给出答案，却没法告诉我：它有没有意识到任务本身已经不再明确。

## 这些抱怨能证明什么

一个公开的 [Claude Code issue](https://github.com/anthropics/claude-code/issues/81168) 里，有人报告 Opus 5 信誓旦旦地说了一个错误的仓库结构，被质疑后还在辩护，直到跑了两条命令才发现事实恰好相反。这个报告写得够具体、够有用，但终究只是一个人基于私有 monorepo 的经历，不是受控对比实验。

更大的[Hacker News 发布讨论](https://news.ycombinator.com/item?id=49038433)里声音就杂了。有人说模型太主动、爱跑题、过度设计；也有人说效率更高、结果更好——不过后者也坦承自己的感受是主观的。[Reddit上一个大帖](https://www.reddit.com/r/Anthropic/comments/1v6r82w/opus_5_is_erm_a_nightmare/)也差不多两极分化：一部分人觉得分析和工具链更强，另一部分人抱怨模型很难管住。

这些反馈不足以得出"Opus 5 更差"的笼统结论——任务量、prompt、harness、effort 设置、代码库不同，结果都会变。但它给了我一个可以具体测试的失败模式：当模型把模糊性当成默许时，到底需要多少监督？

## Prompt能帮上忙，但产品本身也得担一部分责任

Anthropic 建议的 scope 指令是合理的：让 Opus 5 自己处理常规判断，只在不同解读会导致实质性差异时才确认，避免悄悄扩大任务范围。我会把这条指导加到 agent 的 harness 里。

但我不会止步于此。Prompt 文本划不出硬边界，模型也可能不听话。对于后果严重的任务，harness 应该限制执行路径，schema 或公共 API 改动前必须审批，限制工具调用，动手实现前先暂停确认计划。

在我[之前对 agentic 排行榜的分析](https://markhuang.ai/news/agentic-index-needs-your-failure-test)里，我主张用分数来为本地失败测试选模型。这个场景需要在测试里故意放入模糊的请求。我会记录：模型是否在正确时刻提问？它未经批准就改范围的频率是多少？我做了多少次修正？它那些错误假设要花多大代价去回退？

## 我会单独给协作能力打分

原文作者关于 benchmark 的猜测有道理，但“有道理”不足以把模型行为归因到训练策略上。文档里的事实指向一个更务实的结论：Opus 5 被设计成能跑得更远，Anthropic 也承认它可能跑出请求的范围。

几条不满的公开帖子不足以否定这个模型，更强的 benchmark 成绩也不能证明它是更好的编程搭档。我会给 Opus 5 分配和团队实际面对的一样混乱、一样没明确规格的任务，然后像评估 patch 一样仔细地评估它什么时候停下来。

所以我的评估会看两件事：Opus 5 能不能把活干完，以及它有没有注意到活已经变了。两件事都过关之前，“更强”并不能决定我愿不愿意让它在代码库里替我做决定。