GitHub 现在让一个模型专门盯另一个模型了：AI 写代码最危险的时刻，终于有人开始认真防了
这两年 AI 编程工具最容易让人上头的地方，往往不是它写得有多快，而是它经常写得太像对的了。
计划看起来很顺。
代码看起来很干净。
测试甚至也能跑绿。
但很多开发者真正被坑的时候，恰恰就发生在这种时刻：它不是完全不会，而是会在一个看上去很合理的方向上，自信地一路错下去。
所以我看 GitHub 这次给 Copilot CLI 加的 Rubber Duck 时，第一反应不是“哦，又多了个新 feature”，而是：
终于有人开始认真把‘AI 也需要代码复查’这件事，做成产品能力了。
这次到底更新了什么
GitHub 在 Copilot CLI 里上线了一个实验功能，名字叫 Rubber Duck。
它的核心思路很简单，但很值得玩味：
- 你先让一个主 Agent 干活
- 然后在关键节点
- 再叫来一个来自另一模型家族的模型
- 专门挑刺、提疑点、找边界问题
按 GitHub 的说法，当 Claude 家族模型作为主 orchestrator 时，Rubber Duck 会用 GPT-5.4 来做独立复查。这个复查不会每一步都跳出来打断你，而是集中在几个最容易把错误放大的时刻：
- 计划刚写完之后
- 复杂实现完成之后
- 测试写完、但还没正式执行之前
你也可以手动让它下场，随时要求它批改当前方案。
这个设计我挺认同。因为很多问题不是出在“最后一行代码写错了”，而是第一步路子就歪了。
为什么这事比看起来更重要
现在很多 AI coding 工具都已经会：
- 拆任务
- 改多文件
- 跑命令
- 写测试
- 做长流程迭代
问题也正因此变了。
以前大家担心的是“它会不会写”；现在越来越多时候，真正要命的是：
它会写，而且写得很顺，但你没那么容易及时发现它顺着错路越跑越远。
GitHub 这次其实是在承认一个很现实的行业事实：
AI 编程最大的风险，很多时候不是低级错误，而是高完成度的误判。
这和传统 lint、静态检查不是一回事。
因为 Rubber Duck 盯的不是单纯格式问题，而是更偏工程判断的问题：
- 这个计划是不是一开始就搭歪了
- 这段实现有没有遗漏跨文件依赖
- 测试看起来全绿，是不是只是把错误一起合理化了
- 有没有边界条件、假设前提、架构冲突被主 Agent 忽略了
说白了，它想补的不是“写代码能力”，而是“怀疑自己能力”。
最关键的，不是第二个模型，而是‘不同脑回路’
GitHub 这次最有意思的地方，不只是多加了一个 reviewer，而是它强调这个 reviewer 来自另一模型家族。
这背后的逻辑其实很朴素：
如果一个模型审自己的作业，它再怎么反思，也很可能还困在同一套训练偏好、同一类盲点里。
而换一个模型家族，就相当于换一种“看问题的习惯”。
GitHub 公布的评估里提到，Claude Sonnet 4.6 搭配 Rubber Duck（GPT-5.4）后，在 SWE-Bench Pro 这类困难任务上，弥补了 Sonnet 单独使用到 Opus 单独使用之间 74.7% 的性能差距。而且越是跨多个文件、步骤很长、容易中途跑偏的任务，帮助越明显。
我觉得这里最值钱的信号，不是某个百分比本身，而是它说明了一件事：
第二意见不只是安慰剂，它开始有可量化的工程收益。
它真正打到的，是 AI 编程里最危险的三个时刻
我特别认同 GitHub 选择的三个复查节点，因为它们几乎就是 AI 编程最容易出事的三个位置。
1. 计划阶段
很多错误一开始就种下了。
你让 Agent 改一个复杂模块，如果它最初的拆法就不对，后面写得越快，返工往往越狠。计划阶段多一个不同视角来挑刺，往往比最后再补救便宜得多。
2. 实现阶段
复杂实现最怕什么？
不是语法炸了，而是它把局部写顺了，却把跨文件状态、旧逻辑兼容、数据流边界给漏了。GitHub 举的例子里，就包括 Redis key 改写后，另外三个文件还在继续读旧值，结果整个确认流程会在上线后静悄悄地断掉。
这种问题最烦，因为本地 demo 看着很可能还是能跑。
3. 测试阶段
这一点我觉得尤其关键。
很多开发者现在已经感受到：Agent 不只是会写代码，它也会写测试；更麻烦的是，它有时还会把原本该守住的边界一起改掉，让测试继续绿。
所以“测试写完、但还没执行”这个检查点特别聪明。
它防的不是测试挂，而是测试本身已经被写偏了，你却正准备把这种错误进一步强化。
这其实是在把 code review 往前挪
我会把 Rubber Duck 理解成一种更前置的 review。
传统工程里，review 往往发生在代码差不多成形之后；但到了 agent 时代，这个时机可能已经有点晚了。因为一个 Agent 能在很短时间里连写计划、实现、测试、提交，错误传播速度比以前快得多。
所以更合理的做法，不是继续等到最后看 diff 才惊呼“这方向不对”，而是把 review 往前挪到：
- 计划刚成形时
- 复杂实现刚落地时
- 测试准备自证正确时
Rubber Duck 的意义，恰恰就在这里。
它不是让 AI 多说几句话，而是在尝试把“复核”也变成自动化工作流的一部分。
但先别吹成‘AI 会自己互相监管，一切稳了’
这个方向我挺看好，但我也不打算吹得太满。
因为第二个模型不代表真理，只代表另一个视角。它能减少盲点，不代表能消灭盲点。
而且这类机制后面肯定还会遇到几个现实问题：
- 两个模型都错了怎么办
- reviewer 太频繁，会不会把流程变得啰嗦
- reviewer 太保守，会不会拖慢执行效率
- 用户怎么知道哪些 critique 值得信，哪些只是噪声
- 复杂项目里，第二意见是补充判断，还是会制造更多分歧
这些问题都是真问题。
所以我更愿意把它看成：AI 编程工具终于开始承认，“会写”不够，“会复核”才是下一阶段的门槛。
这不是终局，但方向确实比单纯卷生成能力靠谱得多。
对开发者来说，这条更新真正值得抄什么
如果你不是 Copilot CLI 用户，这条新闻也不是只能看个热闹。
它至少提醒了几件很现实的事：
1. 别再把单模型输出当最终答案
以后越复杂、越长流程、越跨文件的任务，越应该默认需要第二意见。
2. review 不该只看最后 diff
计划、实现和测试这三个阶段，都应该有不同形式的复核，而不是最后一次性押注。
3. AI 编程的竞争重点变了
下一轮真正值钱的能力，可能不是谁一次写得更猛，而是谁更能把怀疑、纠偏、复查和交接做进流程。
4. 人类的角色也会跟着变
人类不必盯每一行代码，但更应该盯：
- 问题有没有被问对
- 复核点有没有放对位置
- 哪些风险需要人工兜底
我的判断
如果要我用一句话概括这次更新，我会这么说：
GitHub 这次真正放出的，不只是一个‘第二模型’功能，而是一种很关键的产品判断：AI 编程工具最该补的，已经不是继续自信地多写一点，而是学会在关键时刻先怀疑一下自己。
这件事听起来没有“全自动写完整个项目”那么热血。
但它更成熟，也更接近真实工程。
毕竟开发现场里，最贵的从来不是多写几百行代码。
而是别让一条看起来很顺的错路，一路通到生产环境。