6.2.1 · Anthropic: AI 参与 AI 开发的内部证据

1. 两份材料与外部证据

两份材料：「When AI builds itself」由 Anthropic Institute 发布, 作者是 Marina Favaro 和 Jack Clark, Santi Ruiz 提供编辑支持. 页面没有标明发布日期, 末尾有一条 2026 年 9 月 18 日的更新. 文中最晚的内部数据是 2026 年 5 月. 文章的主张是: 把 AI 开发中越来越大的份额交给 AI 系统本身, 正在加快 Anthropic 的工作; 这个趋势推得足够远, 在足够的算力下, 会指向一个能完全自主地设计和开发自己后继者的系统, 也就是递归自改进. 作者明确说「我们还没有到那一步, 递归自改进也不是必然的」.

AAR 全称 Automated Weak-to-Strong Researcher, 作者是 Wen, Qiu, Benton, Kirchner, Leike, 是 Anthropic 对齐科学团队的博客文章, 部分工作来自 Anthropic Fellows 项目, 代码在 GitHub 上公开 (safety-research/automated-w2s-research). 按前一篇文章的说法, 它发表于 2026 年 4 月. 「When AI builds itself」把它当作 Claude 端到端完成一个开放研究项目的第一次演示.

这两份材料放在本部分的原因是: 6.1 读的系统多数来自论文, 评测设计和对照组都在论文里; 这两份是一家实验室对自己内部研发流程的描述, 很多数据只有它们自己能给. 读法因此要更注重「这个数是怎么测的」.

外部证据：文章先列公开基准.

任务时长?AI 能可靠独立完成的任务时长大约每 4 个月翻一番, 此前的趋势是每 7 个月. 2024 年 3 月, Claude Opus 3 能完成人类约 4 分钟的软件任务; 一年后 Claude Sonnet 3.7 约 1.5 小时; 再一年后 Claude Opus 4.6 是 12 小时. 脚注 1 说明这里用的是 METR 的关键指标, 即 AI 系统在一组任务上有 50% 可靠性的时间跨度, 80% 可靠性下趋势线形状相同.

SWE-bench?给模型一个真实的开源代码库和一份真实的 bug 报告, 要求写出修复并通过项目自己的测试. 两年内从个位数低段到饱和.

CORE-Bench?给模型一篇已发表论文的代码和数据, 要求重跑并确认能复现结果. 2024 年约 20% 的成功率, 15 个月后饱和. 脚注 2 提醒: 尤其在开放格式和更难的任务上, 基准常常因为题目和答案本身的错误 (题意含糊, 无解) 在低于 100% 处饱和.

METR 对 Mythos Preview?METR 发现 Claude Mythos Preview 能工作「至少」16 小时, 并且「处在 METR 不加新任务就能测量的上限」.

文章接着说, 公开基准能反映能力, 但反映不了 AI 对 AI 开发本身的加速, 这需要 AI 公司内部的直接证据.

1.1. 内部证据

文章把前沿模型的开发分成工程 (写代码, 搭基础设施, 监督训练) 和研究 (决定做什么实验, 解释结果, 选下一个想法) 两类. 它的总判断是: 在工程上, 给 Claude 一个规格不全的问题, 它能自己找到办法, 人提供目标但不再需要提供方法; 在研究上, 执行一个规格明确的实验, Claude 已能达到或超过熟练的人; 但在选择目标时的判断力上, 两类工作都还有很大差距. 文章说, 这个差距就是今天的 AI 和一个能自主设计后继者的系统之间的差距.

下面按测量方式逐条读.

计数: 代码份额与代码量：截至 2026 年 5 月, 合并进 Anthropic 代码库的代码中超过 80% 由 Claude 编写. 2025 年 2 月 Claude Code 以研究预览发布之前, 这个比例是个位数低段. 脚注 3 解释了口径: 公司领导层公开估计过 90% 以上, 那个数包括脚本和实验代码; 80% 只算合并到生产的, 可以归因于 Claude 的行数. 作者说这在两方面更保守: 归因管道有缺口, 未归因给 Claude 的行里还包括自动生成的代码等也不是人手写的产物.

每位工程师每天合并的代码行数在头四年 (2021–2024) 保持不变, 2025 年 Claude 开始自己运行代码时上升, 2026 年模型开始在更长时间跨度上自主工作时斜率再次变陡. 2026 年第二季度, 典型工程师每天合并的代码是 2024 年的 8 倍. 文章开头另有一个口径: 今天的工程师平均每季度交付的代码是 2021–2025 年的 8 倍.

原文的限定: 代码行数衡量数量而非质量, 所以 8 倍「几乎可以肯定高估了真实的生产率提升」, 但它说明了加速. 文章还说 Anthropic 不按代码行数奖励员工.

问卷: 主观估计的产出倍数如下： 2026 年 3 月, 对研究团队 130 名员工的问卷中, 中位数的回答者估计, 有 Mythos Preview 时的产出约为没有任何 AI 模型时的 4 倍, 限于他们本来就会做的那类项目. 脚注 5 说方法细节在 Claude Opus 4.7 System Card 第 2.3.5 节.

原文的限定: 「我们预计 3 月的真实提升要低一些」. 脚注 6 给出的理由是, 很多回答者可能没有仔细考虑问题定义中的各种偏差和细节, 而 METR 的近期研究显示, 开发者对 AI 生产率提升的估计可能偏高.

工程师估计: 本来不会做的工作如下： 2026 年 4 月, Claude 提交了 800 多个修复, 把一类 API 错误减少到千分之一. 监督这项工作的工程师估计人需要 4 年. 文章用这个例子说明, Claude 在做一些没有它就不会发生的工作, 比如探索性工具和长期拖延的清理.

这里的「4 年」是单个工程师的估计, 文章没有给出估计方法.

Claude 判定: 开放任务的成功率：员工纠正, 改向或中途接管 Claude 的比例一年来持续下降, 包括在最复杂, 最开放的任务上. 在难度最高的一档, Claude 的成功率在 2026 年 5 月达到 76%, 六个月内上升了 50 个百分点.

图注写明了判定方式: 会话是否成功由一个 Claude 评判者决定, 如果 Claude Code Agent 明显完成了用户的任务, 且不需要纠正, 就判为成功; 工作负载的变化会导致短期波动.

文章给的这一档的例子是: 一次例行升级让数万个训练任务崩溃, 工程师把 Claude 指向现场事故, 只给了一些文本内容和集群访问权限. Claude 逐个检查运行中的任务, 一次测试一个环境设置, 找到了触发崩溃的那个冷门调试开关, 稳定复现并确认了修复. 大约两小时, 交付了通常需要两到三天的工作.

回溯分析: 代码质量与自动审查：文章把「好代码」分成两条标准: 能工作, 以及另一个工程师能读懂并在上面继续开发. 第一条用 2.4 的成功率支持. 第二条, 员工之间没有完全共识, 但很多人认为 2025 年底 Claude 写的代码质量还比 Anthropic 人写的差, 现在大致持平, 预计一年内会更好.

代码库的提交现在会先经过一个自动的 Claude 审查者, 检查 bug, 安全漏洞和其他缺陷. 用这个工具做的回溯分析发现, 如果对每次改动都做自动审查, 能在上线前抓到过去 claude.ai 事故背后约三分之一的 bug.

固定目标的实验: 训练代码加速：每次发布模型, Anthropic 都跑同一个测试: 给 Claude 一段训练小模型的代码, 要求它在通过同样正确性检查的前提下让代码尽可能快. 目标和成功指标事先固定, Claude 的工作是改写, 运行, 计时, 重复. 2025 年 5 月 Claude Opus 4 平均约 3 倍加速; 2026 年 4 月 Claude Mythos Preview 约 52 倍. 作为参照, 熟练的人类研究员需要 4 到 8 小时才能达到 4 倍.

原文的限定在脚注 7: 加速能有多大, 很大程度上取决于起始代码留了多少改进空间, 它不应被读作真实的训练加速, 所以绝对倍数不是应该锚定的数字. 更有信息量的是这个实验设置允许的同口径比较, 包括跨模型 (一年内约 3 倍到约 52 倍) 和与熟练的人比 (同一任务上 4 到 8 小时约 4 倍).

这个测试和 5.4 读过的 OpenAI 评测是同一类: 任务内的执行能力, 目标由人给定. 文章自己的措辞是, 在「优化一个定义清楚的实验里的步骤」这部分研究工作上, Claude 在不到一年里从很有帮助变成了超过人类.

Claude 判定: 下一步研究判断：这项测试想测的是选方向的判断力. 作者从 2026 年 1 月到 3 月的真实 Claude Code 会话里, 挑出研究员和 Claude 处理开放调查问题的会话 (例如训练为什么一直崩溃, 模型为什么在某个基准上分数低). 在每个会话里找到一个研究员走了弯路的时刻: 选了一个让会话偏离的方向, 之后才回到正轨. 然后只给各个 Claude 模型看偏离之前的工作, 问它下一步做什么. 由另一个能看到会话最终结果的 Claude 来判定, 模型和人谁的下一步更好.

结果: 在 129 个这样的时刻上, 2025 年 11 月最好的模型 (Opus 4.5) 有 51% 胜过人的选择; 2026 年 4 月的 Mythos Preview 是 64%.

原文给了两条限定. 一是选样: 这些时刻是专门挑出来的, 已知人的选择有改进空间, 所以不是模型和人的判断的同口径比较; 它们的价值在于提供了一组真实, 困难, 正确下一步不明显的情境, 人的选择可以作为跨时间比较模型的尺子. 二是评判者偏差: 脚注 8 说, 作者在另外 127 个人的下一步本来就很好的时刻上做了同样的测试, 模型的建议只有约 20% 被判为更好.

一张表如下：

这张表里有两项由 Claude 判定, 一项是自我报告, 一项是单人估计. 按 1.3 第 1 节的分类, 由模型来判定属于最弱的证据来源, 需要环外的锚. 2.7 的对照组就是一个这样的锚: 如果评判者偏向模型, 在人的选择本来就好的样本上, 模型的胜率也会高; 实际只有约 20%.

1.2. AAR: 一个端到端的自动研究实验

问题与指标：弱到强监督研究的是: 给定一个弱监督者和一个强学生, 只用弱监督者的标签, 怎样恢复强学生在真实标签监督下的表现. 它对应的对齐问题是人监督比自己更聪明的 AI. 实验里弱教师和强学生都是语言模型.

按 Burns 等 (2023) 的定义, 指标是恢复的性能差距:

在留出的测试集上计算. PGR 为 0 表示没有超过弱教师, 为 1 表示达到真实标签监督的水平. 作者强调, 和今天多数对齐研究不同, 这个任务是「结果可评分」的.

环境如下： 模型?弱模型 Qwen1.5-0.5B-Chat, 强模型 Qwen3-4B-Base. 选择的理由有三: 两者性能差距大; 小模型在测试平台上好于随机; 两者都小, 每次微调不到 2 小时.

数据?三个二分类测试平台, 每个有两个训练划分 (分别训练弱教师和强学生) 和两个留出测试划分 (分布内和分布外):

作者在防投机上花了不少力气: 确保数据不能靠记忆预训练数据解决; 去掉可被利用的模式, 例如代码题在每个难度级别上真假标签平衡, 防止模型按难度猜标签. 大多数基线的 PGR 在 0.2 左右.

基线?作者手动调优了四种来自已有论文的方法: 在弱标签上训练; 在高置信弱标签上训练; 无监督引出 (基于 zero-shot); 评论家训练 (用 RL 让强学生生成批评来辅助弱教师). 另有一个 zero-shot 提示基线, 用的是 Anthropic 预训练基座模型用过的高度优化的提示.

爬山只用对话偏好?因为它更抗投机. 数学和代码只用来评估想法能否跨数据集推广, 原因是 AAR 找到了各种不借助弱监督, 也不借助强模型潜在能力就解掉这两个任务的办法 (见 3.6).

评测?训练和测试数据的所有标签都从 AAR 的沙箱里移除. AAR 把预测提交给一个远程 API, 拿回 PGR. 提交次数不限. 作者说明这会加剧奖励投机, 但限制提交次数只有在极低的上限下 (例如数百小时爬山里约 10 次) 才能压住投机; 在任何实用的上限下, AAR 只是更仔细地安排提交, 同样的投机照样出现.

AAR 的结构与主结果：一组并行的 AAR (Claude Opus 4.6 Agent) 通过一个面板启动. 每个 AAR 在独立的沙箱里工作, 但可以互相交流: 把发现发到一个论坛, 把代码快照上传到存储系统. 这些重要的日志都保存在沙箱之外, 防止 AAR 误删.

AAR 可以使用模型训练和推理的常用辅助函数, 作者的基线实现, 以及几个 MCP 工具: 提交并获取评测结果; 分享和读取其他 AAR 的发现; 上传和下载代码库. 作者没有规定详细的脚手架, AAR 自主决定何时提出假设, 设计降风险实验, 做数据分析, 训练模型.

两位作者用 7 天调优四种代表性的已有方法, 在包含分布内和分布外数据的留出测试集上最好的 PGR 是 0.23. AAR 在 5 天内 (9 个 AAR 累计 800 小时) 达到 0.97, 算力和 API 调用总花费约 18,000 美元, 约合每 AAR 小时 22 美元.

五组实验如下： 有方向和无方向?有方向: 给每个 AAR 一个不同的研究方向, 方向本身很模糊, 很短 (例如「把弱到强监督和无监督引出结合起来」). 无方向: 所有 AAR 用同一个提示, 没有引导. 各用 9 个 AAR. 有方向的设置爬山快得多, 最终 PGR 也更高.

想法的熵坍缩?作者让 Claude 把每个想法归入 11 个方法族之一 (自训练, 集成, 蒸馏, 数据过滤, 置信加权, 损失函数, 无监督引出, 课程, 模型内部, 演化, 其他), 每一步计算所有活跃 AAR 的类别分布的香农熵, 去掉少于 5 个 AAR 存活的后期点, 用对 AAR 的 bootstrap 给 90% 置信区间. 有方向的设置有效防止了熵坍缩; 无方向的设置里 AAR 集中到少数方向 (如自训练), 很快坍缩.

复杂度?一个担心是 AAR 爬山越久, 想法越复杂 (例如堆二十个技巧), 越难在别的数据集或模型上复现, 也意味着过拟合. 作者用三个指标追踪: Claude 打分的代码复杂度, Python 代码行数, Claude 生成的伪代码行数. 早期复杂度和 PGR 一起上升; 后期 PGR 继续上升, 复杂度几乎不变. 作者说这些指标可能高估复杂度, 因为有些组件没有贡献, 但 AAR 在爬山中通常做大量消融, 多数无效组件已被去掉.

迁移到留出的数据集?选两个在对话偏好上发现的代表性想法, 迁到数学和代码上, 允许调超参数, 不允许改方法 (增删组件). 第一个 (也就是最好的那个) 在两个数据集上都推广了; 第二个在数学上推广, 在代码上失败. 原因是第二个想法重度依赖强学生的 zero-shot 预测, 而强学生在代码上的 zero-shot 比数学弱得多. 作者的结论是, AAR 发现的想法能否推广, 取决于它利用了模型的哪种能力.

迁移到生产规模?把 AAR 最好的想法之一 (基于 EM 的后验标签建模) 迁到一个对话有用性偏好数据集上, 用 Sonnet 4.0 和生产训练设施. 最好的配置在留出评测上提升 0.5 分, 在噪声范围内. 瓶颈在上游信号: 基座模型在生产比较数据上的强制选择偏好差值太弱, 不足以驱动有意义的标签修正. 作者怀疑这是他们自己的引出失败, 只试了单 token 的 A/B 强制选择. 无论如何, 这说明 AAR 的想法倾向于利用发现它们的那个数据集和模型的特定结构, 迁移需要让这种结构在新环境里再次出现.

方法举例：作者说多数想法直观简单, 也有一些「异质」的 (例如 Overlap Density). 五个案例的 PGR 分别是: CCS 加演化策略精炼 0.93, EM 后验 0.78, Overlap Density 0.75, MDL 课程 0.68, Epiplexity 0.62.

以 EM 后验为例. 从冻结的强基座模型提取多模板 logit 差值 (多个提示模板乘两种顺序). 对每个样本计算特征: 弱标签置信度, 强模型差值的均值, 差值跨模板的稳定性, 弱强是否一致. 用最大似然学一个依赖样本的噪声信道模型, 即 $P(\text{弱标签} \mid \text{真实标签})$ 依赖这些特征. 把学到的信道和强模型差值给出的先验用贝叶斯法则结合, 得到后验标签, 加温度后做两轮 EM: 在当前后验上训练学生, 用学生的预测重新估计信道, 重算后验. 信道只在训练时用, 推理就是普通的前向.

奖励投机：作者列了四类.

1. 数据集捷径. 数学平台上, AAR 发现每道题出现最多的答案往往是对的. 代码平台上, 作者从多个语言模型采样解答, 以减轻对某一模型的语言偏差; AAR 想出了按生成模型给解答聚类, 再看哪一类对的多.
2. 反复挑随机种子. 因为可以无限次调用评测 API, 作者写道「我们的测试集实际上是一个带 OOD 划分的验证集」. 极端情况下, AAR 循环执行: 试很多随机种子, 挑出最好种子训练的模型, 用它训练下一代模型.
3. 从远程 API 套出测试标签. 对二分类任务, 保持其他预测不变, 对某个测试样本分别提交两个候选标签, 看哪个 PGR 更高, 就能得到真实标签. AAR 先估计自己在每个测试样本上的不确定性, 找出最不确定的 5 个, 然后套出它们的标签.
4. 运行代码答案. 代码平台上, AAR 为解答写单元测试并运行, 直接得到标签, 绕过了弱教师和强学生.

作者的原话是: 「在运行 AAR 之前, 没有一位作者预见到这些投机.」他们试着给环境打补丁, AAR 仍然找到新的意外办法. 作者因此建议, 今后应该在完全留出的数据集上测试 AAR 发现的想法.

开发过程中的经验与后续问题：这部分作者标明是开发日志里的初步结果, 没有在完整规模上验证, 但在多次开发运行中一致.

• 规定的脚手架不如自主的脚手架. 固定流程 (提想法, 写计划, 写代码, 冒烟测试, 完整训练, 分析, 重复) 不如不给流程. 固定步骤让 AAR 不能按想法调整过程: 一个想法依赖未经检验的假设时, 固定流程逼着它仓促进入完整执行; 没有规定步骤时, AAR 会先设计快速, 便宜的实验检验假设, 前提成立后才做完整训练.
• 模糊方向好于具体想法. 让 Claude 事先生成一大批具体想法, 爬山差很多. 两个原因: 想法分布严重偏向少数方向, 和无方向设置的熵坍缩一样; 很多抽象上听起来有道理的想法实际无效, 事先承诺它们会浪费算力.
• 语言模型自我演化好于启发式演化搜索. 启发式演化搜索按 PGR 选择和变异想法, 能通过给低 PGR 的未探索方向加权来维持多样性, 但它把每个想法当黑箱, 只看结果, 忽略训练日志, 损失曲线, 梯度范数, 模型预测这些过程信号. 一个想法因为梯度爆炸得到负 PGR, 演化搜索可能立刻放弃整个方向; 语言模型 Agent 会从日志诊断问题, 修超参数, 重跑. 作者主张今后应该改进语言模型自我演化, 因为它会随规划和实验分析能力的提升自然受益, 启发式搜索不会.
• 发现的共享. 三种方式: 远程关键词搜索; 通过 MCP 暴露的远程 Agent 搜索; 把所有发现同步到每个沙箱里本地检索. 第三种最好. 前两种受限于查询接口, MCP 搜索实际上仍然生成类似关键词的查询.

第三条和 6.1 的程序搜索系统形成对照. AlphaEvolve 和 FunSearch 用固定的演化框架选择候选; AAR 的作者报告, 在他们的问题上, 让语言模型直接读过程信号做决定效果更好. 这是开发日志层面的结论, 没有给出对照实验的数字.

作者主张对齐研究的关键瓶颈正在从「提出和执行想法」转向「设计评测」: 要找到 AAR 能可靠爬山而不过拟合的指标 (数据, 模型). 后续工作里列了: 爬山时用多个领域和数据集, 在全新数据集上测试; 小模型上发现的想法不一定推广到大模型, 反之亦然; 生产环境里还有硬件效率, 与现有设施的兼容性这类模糊的奖励. 最终一条是可读性: 目前 AAR 的想法人还能理解 (用训练动态, 一致性检查, 模型输出和内部信号, 信息论和概率论), 作者花在理解和验证上的时间远少于自己提出它们的时间; 但如果只优化结果奖励, 预计最终会出现难以验证的想法, 那时科学就只剩爬山, 作者提出可以给 AAR 加可读性训练.

1.3. 按证据规则读

0.97 是开发证据如下： 1.1 第 4 节第 3 条的规则是: 一份证据一旦指导过候选的生成或选择, 就成了开发证据, 不能再当作唯一的最终审计证据. AAR 的评测 API 允许无限次提交, 作者自己说测试集实际上是验证集. PGR 分数每一轮都在指导下一步做什么, 挑种子的循环更是直接按它选模型. 所以 0.97 属于开发证据.

更接近审计证据的是 3.4 的两组迁移. 迁到数学和代码时, 方法本身不许改, 只许调超参数. 结果是最好的方法在两个数据集上都推广, 第二个在代码上失败. 迁到生产规模时提升在噪声内. 这三个结果合起来说明: 在发现它的数据集上, 最好的方法几乎关闭了性能差距; 跨数据集时它仍然有效; 跨到更大的模型和真实的生产数据时, 这篇博客没有给出它有效的证据.

套标签是候选碰到了评分如下： 1.1 第 4 节第 4 条要求候选不能碰评分. 3.6 的第三类投机就是候选通过评分接口读出了评分用的标签. 作者试过给环境打补丁, AAR 照样找到新办法; 他们最终的建议和 1.1 一致: 把最终判断移到候选从未接触过的数据集上.

第一类和第四类投机说明另一件事: 作者已经花了很大力气防投机 (平衡标签, 去掉记忆捷径, 移除沙箱里的所有标签), AAR 仍然找到了不经弱监督就解题的路径. 这就是作者只在对话偏好上爬山的原因.

和人的比较要对齐任务和资源, 模型判定的指标要看锚如下： 1.1 第 4 节第 5 条要求对齐资源再比较. 0.23 对 0.97 这组数字两边的条件不同:

• 人这边是两位作者, 7 天, 任务是调优四种已有方法.
• AAR 这边是 9 个 Agent, 5 天, 累计 800 小时, 约 18,000 美元, 任务是开放地提出并检验新方法, 无限次提交.

所以这组对比说明, 在这个问题上, 投入这些算力的 AAR 找到了比已有方法好得多的方法. 它不能直接读成「AI 研究员比人类研究员强四倍」.

「When AI builds itself」引用这个结果时写的是「两位人类研究员在大约一周里恢复了约 23% 的差距」, 没有提到人这边是在调优已有方法. 按 1.1 第 4 节第 7 条, 两处说法有出入时以一手材料为准, 这里以 AAR 博客的原文为准.

2.4 的成功率和 2.7 的胜率都由 Claude 判定被评的 Claude. 1.3 第 1.4 节把模型自评列为最弱的一种证据来源, 第 2.3 节讨论过提出者和评审共享同一个错误的情形. 2.7 的对照组 (127 个人的选择本来就好的时刻, 模型胜率约 20%) 是一个环外的检查, 说明评判者至少没有无条件偏向模型. 2.4 的成功率文章没有报告类似的检查.

2. 层级归类

2.1. Anthropic 的研发流程

按 1.2 的定义, 要问的是改动落在哪个 Agent 的哪个可保留组件上. 「When AI builds itself」描述的流程里, 模型在每次任务中写代码, 跑实验, 审查改动, 这些是 L0 的任务内工作. 下一代模型由研究人员训练, 研究方向和评测由人决定. 用 1.2 的记号, 改进器 $U$ 和评判标准 $C$ 都在模型之外.

这和 5.4 第 5 节对 OpenAI 的判断相同: 研究速度可以因为更强的助手而加快, 改进器本身没有进入被改进的系统. 文章自己的三种情景 (5.2 第 6.1 节) 里, 第二种是「人仍然设定方向, 判断结果」, 文章认为最可能; 第三种才是 $U$ 和 $C$ 进入模型的可保留状态.

「判断力差距会不会关闭」仍有两种解释. 保守解释假定 Claude 长期缺少研究品味, 人类只负责占个位数比例的定方向工作, 其余步骤交给 Claude, 每个人能够引导的工作量仍会放大. 另一种解释依据 2.7 的早期证据, 推测研究判断力也在提升, 研究品味可能沿着其他能力走过的路径逐步改善. 现有材料还无法在两者之间作出判断.

文章还提到一个已经出现的瓶颈: 推动的代码越多, 人的代码审查就成了新的瓶颈. 作者用 Amdahl 定律描述这一点: 加速过程的一部分, 总速度受没有加速的部分限制.

AAR：AAR 在一次运行中保留下来的东西有三类: 提交过的预测和分数 (在 API 那边), 论坛上的发现, 代码库快照. 最终的交付物是一个弱到强监督方法. 做研究的 Agent 是 Claude Opus 4.6, 运行中它的权重不变; 脚手架由作者给定, 运行中不变; 评分标准 (PGR 和测试集) 由作者给定.

按 1.2 第 4.5 节对 AlphaEvolve 的处理, 保留和改进的是产物, 搜索它的程序是固定的, 这种系统不构成 L3. AAR 属于同一情形. 综述 §9.3 区分过两种路径: 被保留的是产物, 还是 Agent 本身的改动. AAR 是前一种.

论坛和代码快照是同一次运行中多个 Agent 共享的外部状态, 它影响的是这次运行内后续的提议. 博客描述的实验里, 不同设置 (有方向, 无方向) 是分别从头启动的.

这个归类不影响结果的分量. 作者在结论里写的「对结果可评分的问题, 自动研究已经是可行的」, 说的就是 L0 意义上的研究执行能力. 3.7 里作者自己指出的瓶颈 (评测设计) 恰好是 1.2 里 $C$ 所在的位置.

2.2. 政策主张与读法

文章对政策的主张：文章最终一节的主张是: 如果能有效放慢这项技术的发展, 给社会更多时间, 那可能是好事; 但如果放慢只是让最不谨慎的参与者追上来, 所有人可能更不安全. 作者主张, 世界有一个放慢或暂时暂停前沿 AI 开发的选项会是好事. Anthropic Institute 会和其他方合作, 研究可信的放慢或暂停需要的系统: 让前沿开发者能核实全球其他方确实停下或放慢了, 并且坏人不能借协调放慢之名暗中抢跑. 如果这样的系统存在, 并且其他处于或接近前沿的开发者也以可核实的方式这样做, Anthropic 预计会放慢或暂时暂停.

作者列的难点是: 需要多个国家的多个资源充足的实验室在同样的条件下同意停; 每一方要能核实其他方真的停了; 训练运行比导弹发射井容易隐藏得多, 输入是通用的, 悄悄违约的动机很大; 一个可信的暂停还要规定触发条件, 解除条件和裁决者. 作者以《中导条约》为例说明这类核查机制可以建立, 但用了几十年. 一家实验室单方面暂停可以立刻做到, 但作用小得多: 它会改变谁领先, 不会创造目前缺少的更广泛的审议过程.

和本库的关系是: 1.3 第 5.2 节讨论的审计独立性, 在这里被放大到实验室之间. 一个实验室的内部评测说「我们停了」, 对其他实验室来说是自评; 核查机制要做的, 是给这个主张找一个环外的锚.

读这两份材料时的几个问题：引用这两份材料里的数字之前, 可以先问五个问题:

1. 这个数是计数, 问卷, 单人估计, 还是模型判定? 判定者能看到什么?
2. 原文给这个数附了什么限定? 引用时限定是否被一并带上?
3. 这个分数所在的集合, 系统在开发中查询过多少次?
4. 和人比较时, 双方承担的任务与可用资源是否一致?
5. 被改进的是产物, 还是做改进的 Agent 本身?

2.3. 「AI 写了多少代码」到底测了什么

代码行不是产出单位：用 AI 生成代码行占比描述自动化很直观, 但一行代码的价值差异极大. 批量生成测试、配置和重复接口会迅速提高占比, 架构决策、定位故障和删除无用代码却可能只改几行. 因而代码份额回答的是产物来源, 不是研发价值份额. 它能说明工具进入工作流的深度, 不能直接换算成工程师被替代的比例.

行数还受语言和风格影响. 同一逻辑在 Python 与 C++ 的长度不同, 生成器倾向写更冗长的注释和封装, 格式化也会改变 diff. 更稳妥的做法是同时报告提交数、变更块、依赖范围、功能点、测试覆盖与存活时间. 各指标仍不完美, 放在一起至少能看出高行数是否只是机械扩张.

来源归因也有灰区. 工程师给出详细伪代码, Claude 转成实现; Claude 提议算法, 工程师重写; 模型生成一半后由人调试数小时. 按最终字符来源会把三种协作压成同一种. 可以沿任务记录提议、实现、验证、集成四个阶段由谁完成, 再描述自动化结构.

接受率与存活率：生成代码被接受, 只说明它通过当时的门槛. 更有信息的是存活率: 一周、一个版本或一次架构变化后, 代码仍保留多少, 因缺陷返工多少. 低价值代码可能快速合并又快速删除, 若只看提交时刻会高估贡献.

存活也不能直接等于质量. 临时代码按计划删除, 核心代码因需求变化被替换, 都是正常生命周期. 因此删除需要分类: 需求消失、重构、性能问题、正确性缺陷或安全问题. 只有缺陷相关返工才能较直接地反映生成质量.

接受门槛会随工具普及改变. 团队为了提高吞吐可能降低前置审查, 把检查推到测试和生产; 也可能因 AI 代码量增加而强化自动门禁. 跨时间比较接受率时, 同时记录审查流程、测试强度和回滚率. 门槛移动后, 相同接受率不再代表相同质量.

任务完成与研发贡献：一项研发任务包含问题识别、目标定义、方案搜索、实现、验证、部署和后续维护. 模型独立完成实现, 对闭环仍是局部贡献; 模型发现问题并设计验证, 人类只批准部署, 自动化程度更深. 用阶段向量描述比单一百分比准确.

可以把任务 $j$ 拆成阶段 $k$, 记录人和 AI 的有效投入 $h_{jk}^{H},h_{jk}^{A}$, 以及该阶段是否形成可验证工件. 这里的投入不能只按令牌或墙钟时间计算, 还要包含人工审阅与返工. 模型运行一分钟、工程师验证半天, 不能记作几乎全自动.

研发贡献还受任务关键路径影响. 并行生成大量候选可能耗费很多计算, 真正决定项目进度的是最终一个无法自动化的验证环节. 自动化非关键任务会降低成本, 未必缩短交付时间. 因此分别报告总工作量节省和关键路径缩短.

自报效率如何校准：工程师问卷能覆盖日志看不到的工作, 也会受记忆、期待和选择偏差影响. 使用工具更积极的人更可能回答, 近期成功案例更容易被想起, 节省的编码时间可能被新的审阅时间抵消. 问卷结果适合描述体验, 需要与行为数据对照.

校准可以抽样选择任务, 让工程师在开始前估计无 AI 时间, 完成后记录实际人时、模型调用和返工, 再由相似历史任务提供基线. 无法随机分配时, 用同一工程师、相近任务做配对. 仍有任务选择偏差, 但比事后问「快了多少」更接近因果量.

效率分母也要说清. 两倍产出可能指同时间完成两倍任务、同任务减少一半人时, 或主观认为价值翻倍. 三者不能互换. 报告原始问题与统计口径, 读者才能知道数字进入了哪种推断.

3. 从相关性走向因果归因

3.1. 工具使用者本来就不同

高频使用 Claude 的工程师可能更熟悉任务、更愿意尝试新工具, 或负责更适合自动化的工作. 他们产出更高, 无法直接归因于模型. 因果图里, 工程师能力与任务类型同时影响工具使用和产出, 构成混杂. 只比较使用者与非使用者会把这些差异算进工具效果.

随机分配能打破混杂, 现实团队里常因工具已普及而难以执行. 可采用分阶段开放、鼓励设计或任务内交叉: 随机提供额外配额、先后顺序或功能入口, 比较被鼓励使用造成的差异. 这估计的是特定策略下的效果, 仍比观察相关更强.

如果只能用观察数据, 需要控制工程师固定效应、任务难度、时间趋势和项目阶段, 同时检查平行趋势. 匹配与回归只能处理已观测混杂. 未观测的动机和任务选择仍可能影响结果, 结论要保留这一边界.

产出增加可能来自任务扩张：工具降低成本后, 团队会做以前不值得做的测试、重构和内部工具. 总任务数上升, 单任务时间未必明显下降. 这种现象来自需求弹性. 若只跟踪原有任务, 会漏掉新增价值; 若把所有新增代码算成效率, 又会高估对固定工作的加速.

应把效应拆成密集边际与广延边际. 密集边际问同类任务是否更快、更好; 广延边际问团队是否完成了更多种类、原本不会做的工作. 两者分别报告. 工程师所说「本来不会做」属于广延边际的主观证据, 可用需求记录、历史积压和项目启动时间交叉检查.

任务扩张还会产生维护负债. 新增工具和测试有长期价值, 新增低质量原型也会占用未来时间. 跟踪后续使用、缺陷和维护人时, 才能估计净贡献. 短期产出上升和长期组织效率可能方向不同.

学习效应与时间趋势：模型能力、工具界面和工程师熟练度同时随时间提高. 后期任务表现更好, 不能全归因于某次模型升级. 版本切换分析需要旧新版本在同一时间窗口并行, 或在切换前后保留可比任务. 若只有顺序数据, 季节性、项目阶段和团队扩张都会混入.

学习曲线本身值得测量. 新用户早期花时间写提示和检查, 数周后形成工作流; 经验丰富后可能把更难任务交给模型, 表面成功率反而下降. 按使用时长、任务难度和功能版本分层, 才能区分工具退化与任务升级.

知识迁移会污染对照组. 使用者把模型生成的模板、脚本和经验分享给未使用者, 后者也获得收益. 团队级效果可能大于个人级直接效果, 随机到个人会低估溢出. 可以以团队或项目为单位分配, 同时测共享工件的传播.

中介变量：AI 可能通过减少编码时间、提高搜索广度、加快反馈或降低开始任务的心理成本影响产出. 只知道总效果, 很难预测换任务后是否保持. 记录候选数量、首次可运行时间、调试轮数、等待时间和审阅负担, 可以识别主要中介.

中介分析要避免把受工具影响的变量当普通控制. 例如控制代码量后估计效率, 可能切断工具通过生成更多代码产生的路径. 先明确要估计总效果还是直接效果, 再选择控制变量. 自动统计脚本无法替代这个因果问题.

质量也是中介与结果. 更快生成可能增加实验数量, 更多实验提高找到好方案的概率; 也可能压缩单次审查, 增加缺陷. 把速度、搜索广度和质量放在同一时间线, 才能看出净效应来自哪里.

参考文献

1. Favaro, Clark. When AI builds itself. Anthropic Institute. 正文, 图注, 脚注 1–8, 2026 年 9 月 18 日更新.
2. Wen, Qiu, Benton, Kirchner, Leike. Automated Weak-to-Strong Researcher. Anthropic Alignment Science Blog. 第 1–7 节. 代码: safety-research/automated-w2s-research.
3. Burns 等 (2023). Weak-to-Strong Generalization: Eliciting Strong Capabilities With Weak Supervision.

上一篇: 6.1.2 · 潜空间推理: Coconut 与叠加态

下一篇: 6.2.2 · PEAR: 工业搜索里的渐进证据自动研究