有两个数字放在一起时会显得矛盾。
一个是基准分数：主流编码基准上，前沿模型的通过率在两年里从不足两成涨到八成以上，部分受限测试更高。另一个来自 Anthropic 2026 年的趋势报告：工程师在约 60% 的工作中使用 AI，但报告称能够「完全委托」的任务只占 0% 至 20%。
生成能力的曲线很陡，委托比例的曲线很平。如果模型真的能解决八成的编码任务，为什么工程师只肯完全交出去两成以内？
常见的解释是「模型还不够可靠」。本文提出另一种解释：判断模型是否可靠的手段本身已经失效。基准、人的感知、自动化测试——这三层验证手段正在同时出问题，而它们恰好是行业用来回答「AI 编码行不行」的全部依据。
一、基准层：分数已经不可比了
1.1 污染的直接证据
SWE-bench Verified 是过去两年最被广泛引用的编码基准。2025 年的一项分析（《The SWE-Bench Illusion》，arXiv:2506.12286）测得：模型在被要求复现该基准中的标准答案函数时，最高可达约 35% 的连续 5-gram 准确率，而对照组仅约 18%——差值指向模型在训练过程中记住了基准内容本身。
该数据集的维护方已停止用它做评测，公开给出的理由有两条：模型记忆与数据污染，以及对其中失败样本的审计发现，至少 59.4% 的题目测试本身有缺陷——会拒绝功能正确的提交。
记忆污染的后果不是分数偏高一点，而是分数失去意义：一个记住了答案的模型和一个能解决问题的模型，在被污染的基准上得分相同。
1.2 换一份基准，同一批模型的分数塌了
Scale AI 的 SEAL 实验室构建了 SWE-bench Pro 作为抗污染的替代：1,865 个任务，取自 41 个活跃维护的仓库，覆盖 Python、JavaScript、TypeScript、Go 四种语言；相比之下，Verified 是 500 个纯 Python 任务，来自 12 个仓库。值得一提的是，这份基准在自己的局限性一节里主动写明了语言覆盖不足——Java、C++、Rust 均缺席。一份公开承认自身边界的基准，比一份不承认的更可用。需要说明：下表的分数出自论文当期的运行设置（单任务最多 50 轮），与该基准现行排行榜的设置（部分较新模型放宽到 250 轮）不是同一批运行，不能直接与榜单数字比较。
同一批模型换到 Pro 上，分数出现了数倍的落差。而更能说明问题的，是 Pro 自身公开子集与商业子集之间的差异（同一 reasoning 档位内比较）：
| 模型 | 公开子集 | 商业子集 | 相对降幅 |
|---|---|---|---|
| 前沿模型甲 | 22.7% | 17.8% | −21.6% |
| 前沿模型乙 | 23.3% | 15.7% | −32.6% |
两个模型在从未见过的代码库上分别掉了两成和三成。需要承认另一种解释：两个子集的难度与领域分布本来就可能不同，这一点无法排除。但降幅的方向与污染假说一致，且幅度因模型而异——无论归因于哪一种，得到的结论相同：公开基准上的分数之间无法横向比较。
1.3 一个必须正面处理的反驳
商业子集上的通过率（15%–18%）与本文开头提到的完全委托率（0%–20%）几乎重合。按最省事的解释，二者重合说明模型的真实能力就是这么多，本文开头那个悖论根本不存在，也就不需要验证成本这套框架。
这个解释本文无法证伪，而且它确实解释了比例。但它解释不了另一件事：为什么被委托出去的恰好是那一类任务。工程师并非随机地交出两成，而是系统性地交出容易核对的那两成——5.4 节按验证成本给出这一分层。能力不足论解释得了数量，解释不了选择。
本文采用验证成本框架，理由仅在于它同时解释了这两者。这不构成对能力不足论的否定，两种机制可以同时起作用。
1.4 同一个基准名下的数字相差五倍
公开可查的 SWE-bench Pro 分数区间从 15% 上下到 80% 上下不等。但这两端根本不是同一回事：下端出自论文当期的商业子集、单任务 50 轮设置；上端是厂商自报，且对应模型已从活跃榜下架。两者中间还夹着基准方自己的标准化榜单——所有模型走同一套脚手架，头名明显低于厂商自报值。模型版本、数据集划分、脚手架配置、统计时点，四个变量同时在动。
这不是某一方报错了数据，而是「SWE-bench Pro 得分」这个说法本身已经不足以定位一个数字。引用时若不同时给出模型版本、数据集划分与脚手架配置，这个数字不具备任何可比性。
1.5 一个结构性困境
基准污染不是可以靠「换一份新基准」永久解决的。任何公开基准一旦成为业界标准，就会进入训练数据；进入训练数据之后，它就开始失效。抗污染设计能延长有效期，但延长不等于免疫——一份基准越被广泛引用，进入训练数据的概率越高。
二、感知层：人判断不了自己是否更快
基准不可靠时，退一步依赖使用者的直接经验是否可行。METR 的一项随机对照试验给出了否定的答案。
试验设计：16 名有经验的开源开发者，246 个真实任务，任务来自平均超过一百万行代码的成熟仓库。每个任务随机分配到「允许使用 AI」或「不允许使用 AI」两种条件。
| 指标 | 结果 |
|---|---|
| 实际完成时间变化 | 使用 AI 时慢 19% |
| 开发者事后的自我估计 | 认为 AI 让自己快了 20% |
| 两者方向 | 相反 |
该结果的限定条件如下：试验在 2025 年 2 月至 6 月进行，使用的是当时的工具与模型；样本为 16 名开发者、246 个任务、成熟的大型开源仓库。METR 自己现在将该结果标注为历史数据，说明它不一定反映当前的工具与工作流。
带上这些限定之后，这项研究给出的结论是：在效率维度上，开发者对自身变化的判断与实际测量方向相反。同时要说明它的边界——该研究测的是耗时，不是产出正确性，「人对 AI 产出质量的判断是否同样不可靠」缺少同级证据，本文不据此外推。至于这一偏差是否随工具成熟而收敛，目前没有公开的重复实验；在出现反证之前不宜假设它已消失。
这一点直接影响企业的决策方式。绝大多数企业评估 AI 工具效果的方法是问使用者——满意度调查、内部访谈、试用反馈。这些方法收集的正是被这项研究证明不可靠的那一类判断——使用者对自身效率变化的估计。
三、测试层：同源污染
第三层验证是自动化测试。当代码由 AI 生成时，测试通常也由 AI 生成——这是效率上的自然选择，也是问题所在。
实现与测试若出自同一个模型、同一段上下文、同一组假设，那么二者会共享同样的理解偏差。测试通过所证明的是「实现与作者的理解一致」，而当作者的理解本身有误时，这个一致性恰恰保证了错误不会被发现。
我们在一次编排层重构中直接观察到了这一现象。被审查的模块负责从用户的自然语言中解析出后续动作要用的参数。我们引入另一家厂商的模型作为独立评审方，不提供设计意图，只给脱敏代码，要求对每个缺陷给出可复现的输入。
| 验证方式 | 发现的可复现缺陷 | 说明 |
|---|---|---|
| 同源单元测试 | 0 | 三轮评审期间始终全部通过 |
| 异源模型盲审（三轮） | 9 | 每个均附带可复现输入 |
九个缺陷中有一类特别典型：校验逻辑检查用户输入里是否出现过某个选项名，出现即视为用户要启用它。测试覆盖了「用户提到了」和「用户没提」两种情况，均通过。评审方给出的反例是「先别开这个」这类说法——选项名出现了，极性是否定的，校验照样判定为启用。
写测试的人和写实现的人对「出现即选中」这个前提共享同一个盲区，因此测试不可能覆盖到它。
四、三层同时失效意味着什么
三层并列如下：
| 验证层 | 失效机制 | 后果 |
|---|---|---|
| 基准 | 训练污染 + 口径不统一 | 分数不可比，无法作为选型依据 |
| 人的感知（效率维度） | 自我效率判断与实测反向 | 以主观提速感为依据的评估不可用 |
| 自动化测试 | 实现与测试同源 | 对同类假设错误系统性免疫 |
三层各自都已失效，因此不存在可以兜底的那一层：基准不准时不能靠人的感觉纠正，人的感觉不准时不能靠测试兜底，因为测试有它自己的盲区。失效机制互不相同，意味着修好其中一层不会顺带修好另外两层。
4.1 生成侧与验证侧的剪刀差
过去两年，生成一行代码的成本大幅下降。同期，验证一行代码是否正确的成本也在下降——自动化评审是其中一条路径——但下降幅度远小于生成侧，它仍然受限于人读代码的速度、测试设计的质量，以及问题域本身的可判定性。
两条曲线的斜率差，产生的结果是：系统的吞吐量瓶颈从生成侧转移到了验证侧。这为本文开头的悖论提供了一个更省的解释：不必假设模型只能解决两成任务，只需假设只有两成任务的验证成本低到可以让人放心完全委托。
五、可行的做法
以下是我们目前采用的策略。它们不解决验证危机，只是在当前条件下把验证成本压到可承受的范围。
5.1 验证方与实现方异源
让不同厂商的模型来审查实现，且不告知设计意图。异源的目的是换一组不同的先验假设，而非换一个更强的模型——同一家的更强模型仍可能共享同类盲区。
行业侧的相关实践：Cognition 报告其代码评审 Agent 在完全干净的上下文下工作，平均每个 PR 发现 2 个缺陷，其中约 58% 为严重级别。上下文干净是这一效果的前提——评审方知道得越多，越容易接受实现方的假设。
5.2 让 AI 判定，不要让 AI 打分
把审查工作交给模型之前，需要先承认一件事：模型作为评判者本身带有系统性偏差。这一领域已有较多研究，三类偏差被反复确认。
| 偏差类型 | 表现 | 已知量化结果 |
|---|---|---|
| 位置偏见 | 成对比较时压倒性地偏好排在前面的选项 | 普遍存在，模型间稳健性差异很大 |
| 冗长偏好 | 倾向对更长的回答给出更高评分 | 存在性被多项研究确认，但强度按模型族分裂：部分模型族明显偏好长回答，另一些接近中性甚至反向偏好短回答 |
| 自我偏好 | 对自己或同族模型的输出给出更高评价 | 跨模型族普遍存在 |
冗长偏好这一项需要特别说明：它的存在性有多项研究支持，但强度并不统一——按模型族分裂，有的明显偏好长回答，有的接近中性甚至反向。这意味着「用模型打分等于在测量长度」不能一概而论；同时也意味着，在没有专门测过的情况下无法预知手上这个评判模型偏向哪一边。
自我偏好正是「异源」这一条要解决的问题——换一家厂商的模型可以避开它。但位置偏见与冗长偏好不因换家而消失，它们是评分这个动作本身的属性。
由此得到一条实操判据：区分「判定」与「打分」。
| 任务形式 | 输出 | 可否独立核验 | 受偏差影响 |
|---|---|---|---|
| 打分 | 「这段代码质量 8 分」 | 否 | 严重 |
| 判定 | 「输入 X 会触发这条分支」 | 是——跑一遍即可 | 轻微 |
判定之所以可靠，原因不在模型本身，而在于判定的产出可以脱离模型被检验：给出的输入要么复现出问题，要么复现不出来，这一步由机器执行，与模型的偏好无关。
这也是我们的评审为什么不接受「此处可能存在风险」这类意见——它无法被独立核验，因而无法与模型的偏差区分开。三轮评审的产出是九个可复现的输入，而不是九个评分。
同理，用单一模型的评分作为质量门槛（例如「让模型打分，达到 9 分才发布」）不成立：分数会在多轮之间漂移，且可能受长度等表面特征影响，影响方向因模型而异。若必须使用分数，最低要求是多家模型独立打分取一致部分，并且把分数当作筛选信号而非验收标准。
5.3 变异测试：验证测试本身
在信任一组测试之前，先证明它有能力失败。做法是主动在实现中注入缺陷，观察测试是否转红。全绿的测试集在注入缺陷后仍然全绿，说明它没有覆盖到该路径。
这一步的成本很低，但它是唯一能直接回答「这些测试有没有用」的方法。我们在删除死代码、修改校验逻辑等场景下把它作为固定动作。
5.4 按可验证性对任务分层
| 验证成本 | 任务示例 | 建议的委托程度 |
|---|---|---|
| 机器可判 | 编译、类型检查、单测、格式规范 | 可完全委托 |
| 人读可判，有客观标准 | 是否符合既有架构约定、接口契约 | 委托后必须复核 |
| 无客观标准 | 产品判断、口径定义、审美 | 不委托，AI 仅作为草稿工具 |
5.5 验证器先于规模
在扩大 AI 产出规模之前，先确认该领域存在低成本的自动验证手段。不存在的话，产出规模的上限等于人工复核的上限，此时增加生成侧投入不产生额外产能。
六、这对企业选型意味着什么
几条实际建议。
第一，不要用基准分数作为采购依据。分数不可比，且与你的代码库的相关性未知。可行的替代是用自己代码库中的真实任务做小规模对照测试——样本量不用大，但必须是自己的代码。
第二，不要用试用者的主观反馈作为效果评估的主要依据。改用可测量的产出指标：交付的功能数、缺陷逃逸率、返工比例。这些指标不完美，但至少不受自我感知偏差影响。
第三，把验证能力当作基础设施投入，而不是项目成本。测试体系、评审流程、异源审查机制——这些投入的回报体现在它们决定了 AI 产能的天花板。在验证能力不变的前提下采购更强的模型，收益会迅速衰减。
第四，团队能力建设的重心要跟着移动。当生成不再是瓶颈，团队里最稀缺的能力变成了「设计出能让错误暴露的验证」——写得出会失败的测试、设计得了对照实验、判断得清什么样的证据算数。这类能力过去被归为测试岗的职责，现在它决定整个团队能以多快的速度安全交付。Anthropic 报告中「从实现者转向编排者」的角色描述，隐含的正是这一要求：编排者的核心工作不是写，是判断写出来的东西对不对。
七、局限与未解决的问题
- METR 的研究样本为 16 名开发者、246 个任务，且使用的是 2025 年上半年的工具，METR 自身已将其标注为历史结果。本文引用它是为了说明「自我感知不可靠」这一机制，而非其具体数值在今天仍然成立。
- 我们自身的实践观察为单个项目、三轮评审、九个缺陷，样本量不足以支撑普遍性结论。
- 本文未对验证成本本身做任何测量。「瓶颈已转移到验证侧」是对现有公开数据的一种解释，不是实测结论；能力不足论可以解释同一批数据的一部分。
- 本文未讨论的一个重要方向是形式化验证。对于可以形式化描述的属性，验证成本可以趋近于零，但目前该方法的适用范围仍然很窄。
- 基准污染问题目前没有结构性解法。私有测试集可以延缓，但无法解决「一旦成为标准就会被污染」这一循环。
八、结论
AI 编码的瓶颈已经从生成侧转移到验证侧。这一转移为基准分数与实际委托率之间的背离提供了一种解释：可被低成本验证的任务，恰好就是被完全委托出去的那一批。
用来判断 AI 是否可靠的三层手段正在同时失效，且失效机制彼此独立，无法相互兜底。基准被训练污染且口径混乱；人对自身效率的判断被实测证明与事实反向；自动化测试在与实现同源时对同类假设错误系统性免疫。
对企业而言，这意味着投入方向需要调整：在验证能力构成瓶颈的前提下，继续在生成侧加大投入的边际收益递减。这个判断给出一个可检验的预测：在缺少低成本自动验证手段的领域，模型能力的进一步提升不会带来委托比例的相应上升。如果未来出现相反的观测，本文的框架就需要修正。
参考来源
- METR，《Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity》（2025-07）：16 名开发者、246 个任务的随机对照试验，实测慢 19% 与自评快 20%。
- Anthropic，《2026 Agentic Coding Trends Report》：约 60% 的工作使用 AI、0%–20% 完全委托，及工程师倾向委托易核对任务的观察。
- Scale AI SEAL，SWE-bench Pro：1,865 任务 / 41 仓库、覆盖四种语言的抗污染基准，含公开子集与商业子集的分数对比，及其局限性一节对语言覆盖不足的说明。
- 《The SWE-Bench Illusion》（arXiv:2506.12286）：SWE-bench Verified 的记忆污染测量，含 35% 与对照组 18% 的对比。
- 该基准维护方停止评测的公开说明：含数据污染与 59.4% 题目测试有缺陷两条理由。
- Cognition，《Multi-Agents: What's Actually Working》：干净上下文的评审 Agent，每 PR 平均 2 个缺陷、约 58% 严重级。
- LLM-as-a-Judge 偏差研究（含 Self-Preference Bias in LLM-as-a-Judge, arXiv:2410.21819；Justice or Prejudice? Quantifying Biases in LLM-as-a-Judge, arXiv:2410.02736）：位置偏见、冗长偏好、自我偏好三类偏差及其量化。