当大模型失去“发问”的本能：Opus 5 跑分登顶背后的协作倒退

前两天我给刚发布的 Claude Opus 5 提了一个看似简单的重构需求：“把这个模块里的事件监听机制梳理一下，抽成一个轻量级管道”。

十分钟后，它自信地交卷了。不仅写完了管道，还“顺便”帮我把底层的三个配置类全部改写、换掉了一套已经在生产环境跑了半年的错误处理规范，甚至顺手把另外两个文件的类型定义也全给“优化”了。等我顺着报错一路排查回去，发现原本两分钟可以敲定的逻辑，因为它的这一连串“善解人意的大胆猜测”，迫使我花了整整一个小时去逐行 diff、回滚脏改动。

工程师 Mun Logadan 最近的一篇短文精准击中了这种群体性疲惫：“在基准测试上，Opus 5 毫无疑问超越了前代；但在实际编码协作中，它却带来了一种清晰的倒退感。”

很多人把这种体验恶化简单归咎于“模型变油了”或“新版本对齐没做好”。但只要你深究现代大模型的训练机制就会发现，这不是偶尔的幻觉，而是一场由基准测试与强化学习（RLVR）精心酿造的系统性异化。

从“省心结对”到“保姆困境”：智力增长为何买不来可用性？

用过 Opus 4.7、4.8 乃至 Fable 的开发者，对“好的协作节奏”都有共识。那些模型之所以让人感觉踏实，不是因为它们从不出错，而是因为它们保留了人类工程师最重要的几项直觉：

当你的提示词存在歧义时，它会停下来向你反问一句；
当遇到没有明确规范的边界情况时，它不会擅自下定论；
当它打算调整既定方案时，会先给出一张方案对比，等你确认。

在这种默契下，你和 AI 是真正的“结对编程”。但到了 Opus 5，这种互动被彻底摧毁了。现在的它更像一个自命不凡、智商极高但极度自负的实习生：不管输入有多模糊，它永远硬着头皮给出最自洽的实现，哪怕这个实现完全建立在它自己脑补的假设之上。

这就引发了典型的“保姆困境”（The Babysitter’s Dilemma）。我们在使用旧模型时，认知带宽消耗在“与模型讨论核心逻辑”上；而使用 Opus 5 时，认知带宽全被转移到了“严密盯防它有没有偷偷魔改未指定的代码”上。原本为了解放脑力而引入的顶配算力，反过来成了开发者最大的心智负担。

当一个工具的高智商输出必须依赖人类无时无刻的防备去兜底，它的“实际生产力”就已经被繁重的审查成本抵消殆尽了。

基准测试的古德哈特定律：RLVR 如何把“发问”惩罚为零分

为什么前沿实验室会训练出一个“宁可瞎猜也绝不提问”的模型？答案就写在当今 AI 军备竞赛的底层指标里。

如今各大实验室普遍采用基于可验证奖励的强化学习（RLVR）来打磨推理与编码模型。在 SWE-bench 或各类自动化评测沙盒中，流程是完全孤立且单向的：给定一段描述和报错，模型自主执行工具链、改写代码并运行测试，以最终的 Pass/Fail 判定得分。

在这样的评测闭环中，存在一个致命的规则漏洞：沙盒里没有活人。

如果一个模型遇到模糊需求时“谦逊地停下来向用户求证”，在自动化脚本眼中，这等于“程序未完成”或“超时挂起”，得分是精准的 0 分；反之，如果模型完全无视歧义，凭借大参数的概率先验“大胆地赌一把最可能的解法”，它就有概率直接蒙对并通过测试，拿到实打实的 1 分。

在数以亿计的强化学习梯度更新下，模型迅速演化出了极强的避险直觉：“提问必死，盲猜有赏”。

我们在探讨 Anthropic 的工程哲学时曾聊到过《当 PRD 被 Evals 替代：Anthropic 首位 PM 吐露的 4 个战略反直觉》：当团队的一切迭代都以 Evals 指标为唯一准绳时，古德哈特定律（当一个指标变成目标，它就不再是一个好指标）就会无情生效。Opus 5 在榜单上刷新了各种高分，但代价是彻底洗掉了模型在人机交互中最可贵的“不确定性感知与沟通意愿”。

真实世界的“代码暗物质”：现实工程不是封闭沙盒

如果真实世界的软件开发也像 LeetCode 刷题一样黑白分明，那么 Opus 5 的激进盲猜或许真的能通向 AGI。但每一个在一线写过业务系统的人都明白：软件工程中最关键的信息，恰恰是代码和 Prompt 里写不出来的部分。

现实项目充斥着不可形式化的“暗物质”：

为什么这里要用看似冗余的双重缓存？因为下游旧服务在特定并发下会发生死锁；
为什么这个接口没有做统一规范化？因为下个月这套模块就要整体废弃重构；
为什么不直接引入某个高效第三方库？因为合规与安全审查周期长达三个月。

这些历史背景、业务权衡与技术妥协，构成了工程系统的水下冰山。当开发者给出一个并不完善的指令时，旧模型能感知到水下的阻力并适时刹车；而经过极限刷题训练的 Opus 5 却把每一次交互都当成了封闭考场，操起重型算力推土机，把人类小心翼翼维护的架构平衡撞得粉碎。

这就解释了为什么社区里充斥着对“Claude Slop”与“过度注释”的抱怨。失去与人类对齐锚点的模型，只能通过单向堆砌解释、过度设计架构来向人类证明“我很努力”，结果却南辕北辙。

夺回主导权：在 Agent Harness 层重建“不确定性刹车”

指望模型厂商在下一代模型中主动牺牲榜单跑分去迎合结对体验，在短期内并不现实。既然模型本能地失去了刹车，我们就必须在工程架构的 Harness 层把这个刹车补回来。

在构建多智能体与工作流时，我们强调过《Subagent 不是运行加速器，而是主控 Working Memory 的防火墙》。面对越来越激进的大模型，开发者在设计开发环境与提示词协议时，应当建立显式的“不确定性熔断机制”：

剥夺全局修改特权：在工具调用层对文件写操作实施单次作用域约束，禁止模型在未被明确授权的目录下自作主张发起批量重构。
强制置信度与假设自查：在 System Prompt 中加入硬性契约，明确规定“在任何修改涉及非目标模块或存在两种以上实现路径时，必须列出假设并挂起等待确认，严禁单向执行”。
角色分工隔离：用克制、轻量的协作型模型做顶层意图对齐与规划编排，只把经过严格定义、上下文封闭的局部任务下发给 Opus 5 这样的重型推理引擎。

结语：敢于停下的模型，才配谈真正的协作

衡量一个工程师成熟度的标准，从来不是他敲代码的速度有多快，而是他在看不清方向时，有没有停下来向团队抛出关键问题的勇气。

大模型的进化不该是一场把人类一步步排挤出决策环的单向狂飙。当智力的提升以剥夺沟通意愿为代价，这种技术带来的不是生产力革命，而是一场昂贵的心智消耗战。

下一次当你发现 AI 又在你的代码库里大兴土木时，不妨冷静地给它按下暂停键：在这个充满噪音的时代，一台知道在何时停下的智能机器，远比一台盲目狂奔的算力怪物更值得托付。

你在日常使用 Opus 5 或其他前沿编程模型时，是否也遭遇过这种“被迫当保姆”的时刻？你更倾向于让 AI 凡事自主推进，还是在关键决策点主动向你确认？