编码模型为什么成了 AI 能力的试金石
在各种 AI 能力的评测里，编码是少有的”没法糊弄”的领域。这就是为什么从 2025 年到 2026 年，各家都把 coding benchmark 当作旗舰模型的核心战场。
编码测的是综合能力
一个看似简单的改 bug 任务，实际上同时考察了：理解需求（读代码、读 issue）、规划（先改哪里）、执行（精确的文本编辑）、验证（跑测试）和韧性（测试挂了怎么办）。任何一环掉链子，任务就失败。
对比之下，聊天评测很容易”看起来不错”——语言流畅、姿态自信，就能骗过人类评估者。代码要么能跑，要么不能，反馈信号是二元的。这也是为什么编码能力的进步，往往比通用能力的进步更容易被真实感知。
从补全到委托
过去两年编码工具的形态经历了三次跳变：
- 补全：模型猜你下一行要写什么；
- 对话：你描述，模型给方案，你贴回代码；
- 委托：你给一个任务，模型自己读代码库、改代码、跑测试、提交结果。
第三种形态在 2026 年成了主流，也彻底改变了”用 AI 写代码”的含义。工程师的角色从”写代码的人”变成”定义任务和验收结果的人”。这个转变比想象中难受——委托的前提是信任，而建立信任需要很长时间的磨合。
依然存在的鸿沟
委托式编码在大代码库、遗留系统和模糊需求上依然力不从心。模型能处理”加一个功能”，但在”为什么这个五年前的模块这样设计”这类需要历史语境的问题上，还是经常给出自信的错误答案。
我的观察是：越是资深的工程师，越不容易被 AI 编码工具替代，反而越容易把它用好——因为他们知道该委托什么、验收什么。工具放大的，始终是使用者的判断力。