TL;DR：模型能力越强，授权给它的风险和不确定性也被放大——更强的模型意味着更难预测的行为、更高的单次成本和更深的信任依赖。一问一答讨论为什么“换更强的模型”不总是安全答案。

模型跑分提高，和它更适合一起工作，并不是同一件事。

一个编码 Agent 可以更快定位错误、完成更长的任务，也可能在需求有歧义时替人选定方向。它交付得更快了，人却不敢离开屏幕：每隔几分钟就要检查它是否扩大范围、改变计划，或把某个未写出的假设当成事实。

视频版（B站） ｜ 音频版（4 分 05 秒）｜ Spotify 订阅 ｜ 偏好阅读？文字版就在下方

原文到底在抱怨什么

Mun Logadan 并没有说 Opus 5 能力倒退。相反，他认为它比 Opus 4.7、4.8 更有能力，benchmark 表现也很强。让他不舒服的是协作方式：

• 意图不清楚时，不太愿意停下来询问；
• 信息缺失时，会自行补充假设；
• 已有计划存在多种解释时，可能不经确认就重新理解或修改。

这会产生一种反直觉的体验：模型更能完成任务，人却需要更仔细地看守它。这里的证据只是个人观察。它能说明一种真实存在的使用问题，不能证明所有用户都会遇到，也不能据此给 Opus 5 的整体能力下结论。

官方叙事和个人体验为什么会冲突

Anthropic 在 2026 年 7 月 24 日发布 Opus 5 时，把它描述为更主动、更适合长时间多步骤工作的模型。官方公布了 Frontier-Bench、CursorBench、OSWorld 等结果，并列出大量早期客户反馈，其中一些特别称赞它会验证工作、发现隐患，或只在需要人类判断时把人拉回来。

这些材料证明了 Anthropic 想优化的方向，也提供了具体使用案例，但仍主要来自厂商评测和早期客户引述，并不是独立的用户体验研究。个人文章关注的又是另一种场景：任务文本没有写全，隐性业务约束很多，选错方向的代价高。

同一种“主动性”，在两类任务里可能得到相反评价：

• 任务自包含、结果可自动检查时，主动补步骤能节省时间；
• 任务依赖未写出的组织背景时，主动补假设可能扩大风险。

所以争议不一定是谁对谁错。双方测量的对象不同：一个更接近“模型能否完成”，另一个更接近“人是否放心让它完成”。

隐藏上下文才是现实工作的难点

“重构登录模块”看起来是一句完整需求，实际可能牵涉旧客户端兼容、审计要求、埋点协议、上线窗口和客户承诺。这些信息可能散落在代码、文档、工单和人的记忆里，不会自动进入提示词。

模型可以写出结构漂亮、测试全绿的新实现，却仍然删掉某个不能改变的旧行为。问题不一定是它不会写代码，而是它不知道自己缺少了哪些背景。

现实任务还经常没有唯一正确答案。两个方案都能运行，但预算、团队经验、发布节奏或维护责任会改变选择。Agent 如果继续执行，就相当于替项目负责人做了技术之外的取舍。

benchmark 的解释为什么只能当作线索

原文猜测，强调 benchmark 的训练环境可能鼓励模型在歧义面前大胆选择答案，因为一项设计良好的评测通常会提供足够信息，并保证存在可以评分的结果。模型如果反问任务设计者，反而无法得分。

这个解释有启发，但没有证据证明 Opus 5 的具体协作行为由某种 benchmark 或训练方式造成。官方发布材料也没有提供能支持这条因果链的数据。

现有证据只能说明，单独测任务成功率可能遗漏“何时需要人类输入”这项能力。真实工作既要看模型能不能解题，也要看它能否发现题面之外的关键决定。

多问问题也不是答案

让 Agent 每做一步都询问，同样会让自动化失去意义。更实用的做法是同时判断三个因素：

1. 歧义：目标是否有多种合理解释；
2. 后果：选错会影响多少用户、数据或外部系统；
3. 可恢复性：操作能否低成本撤回和验证。

这是文章中的编辑性框架，不是对 Opus 5 或其他模型的实验结果。

边界清楚、风险低、容易撤回的操作，可以直接完成并留下记录。信息不全但后果较轻时，可以声明假设，只做一个可回退的小步骤。动作虽然明确，但涉及发布、删除、付款或数据迁移时，应先取得审批。歧义和后果都很高时，Agent 应停止并请人决定方向。

问题是否有价值，要看它能不能改变方案或风险，而不是看数量。

注意力也应该计入生产力

Hacker News 讨论后来扩展到模型的固定写作句式、冗长注释和无关改动。有人认为这些问题严重消耗注意力，也有人觉得影响有限。这些都属于社区观察，不是统一实验结果。

但它们提醒了一个容易漏掉的成本：任务完成之后，人还要花多久才能信任结果。一个模型单次成功率更高，如果每次都要清理无关修改、核对隐藏假设和恢复越界操作，整体生产力未必同步提高。

团队可以记录这些指标：

• 人工持续盯守的时间；
• 审查和返工耗时；
• 偏离计划的次数；
• 越权或不可逆操作的次数；
• 出错后恢复到安全状态所需的时间；
• 因为信任不足而无法开放的工具和权限。

能力决定 Agent 能做多复杂的任务，协作成本决定团队愿意给它多大的行动范围。

怎样设计更合适的审批点

团队不必把所有背景写成一份无限增长的规则文件。固定约束适合写进项目说明，动态取舍则需要运行时判断：

1. 明确只读目录、允许的工具和必须审批的外部写入；
2. 要求 Agent 在高风险任务开始前复述目标、假设和不可改变的约束；
3. 把大任务拆成可检查、可撤回的阶段，每阶段提供真实读回证据；
4. 偏离已批准计划前，说明原因和影响并重新请求授权；
5. 对发布、删除、迁移、付款和凭据操作设置明确审批点；
6. 记录人类介入的位置，持续调整哪些步骤可以自动化。

规则文件能保护已经知道的边界，审批机制负责处理还没写进规则的新情况。两者缺一不可。

评测“知道何时问”可以怎么做

如果只给模型材料齐全、答案明确的任务，就很难观察它怎样处理现实中的不完整信息。更贴近协作的 Eval 可以故意留下关键歧义：

• 提供两个都能运行、但业务含义不同的方案；
• 隐去一个会改变设计的权限或兼容约束；
• 混合可撤回操作与不可逆操作；
• 在执行中途加入与原计划冲突的新证据。

评价时不应只数模型问了多少问题，还要看它是否发现真正会改变结果的歧义，是否区分可逆与不可逆操作，是否在偏离计划前请求授权，以及人类总共花了多少时间介入。

这套指标仍是一种编辑性建议，不是现成的行业标准。它至少把“感觉更累”转换成了可以记录和比较的协作成本。

收看本期节目

音频：在线播放或下载 ｜ 播客主页：听懂 AI

原始资料与延伸阅读

本文由《听懂 AI》第 006 期整理而成。节目主要讨论 Mun Logadan 于 2026 年 8 月 14 日发布的个人文章《Why does Opus 5 feel worse to work with?》，并补充 Anthropic 的 Opus 5 发布说明和 Hacker News 社区讨论。原文描述的是作者及同事的使用感受，不是模型对照实验；关于训练和 benchmark 的解释也被作者明确标为推测。

1. Mun Logadan，2026-08-14：Why does Opus 5 feel worse to work with?——个人及同事的协作体验；关于训练与 benchmark 的解释由作者标为推测。
2. Anthropic，2026-07-24：Introducing Claude Opus 5——官方发布说明、厂商评测和早期客户案例，不应视为独立用户研究。
3. Hacker News：Why does Opus 5 feel worse to work with?——社区对自主性、写作风格、注释和审核成本的讨论；评论只代表参与者观察。

资料说明：本文没有证明 Opus 5 比旧模型更难协作，也没有把作者的训练猜测当作事实。关于审批矩阵、协作成本和 Eval 的部分，是基于原文问题做出的编辑性整理与实践建议。