AI能写更多研发代码，并不自动等于AI已经能独立升级自己。Anthropic最新内部曲线显示，Claude Code在多类任务上的成功率集中到约九成，这是很强的生产力信号；但要证明“递归自我改进”，还需看到目标选择、实验设计、训练、验证和安全决策形成可靠闭环。
最新数据说了什么
Anthropic于9月18日更新研究文章《When AI builds itself》。图表覆盖2025年8月至2026年9月，按琐碎、常规、重大与开放式问题划分Claude Code会话。到2026年9月，四类任务的成功率约为88%至92%；开放式任务从约26%升至91%，提升最明显。
一手来源是Anthropic Institute原文。原文对“成功”的定义是：由Claude裁判判断任务明显完成，且无需用户纠正。作者同时提醒，工作负载变化会导致短期波动。文章还披露，超过80%的合并到生产的代码行可归因于Claude，但归因管线存在缺口，且该比例包含脚本和实验代码。
这些数字值得重视，也必须放在来源边界内：它们来自模型开发者的内部生产环境，没有公开完整任务集、逐条判定与独立复现。内部数据能证明一种组织实践已经大规模发生，不能直接证明所有团队、代码库和模型都达到相同水平。
三个概念需要分开
第一是代码生产率：AI让工程师更快生成、修改和检查代码。第二是AI辅助模型研发：AI参与数据处理、实验基础设施、评测或训练代码。第三才是递归自我改进：系统通过改进研发过程，产出更强的后继系统，后继系统又进一步加速同一循环。
生活类比是优秀学徒帮助制造更好的工具。学徒能加工大量零件，不代表他能独立决定造什么工具、证明新工具更安全，并为下一代工厂负责。类比的边界在于，软件和模型可以快速复制，一次改进的扩散速度远快于实体工厂，所以验证和权限失误也会被迅速放大。
flowchart LR
A[人类设定研究目标] --> B[AI生成代码与实验方案]
B --> C[运行训练或评测]
C --> D[独立验证结果]
D --> E{能力与安全都改善?}
E -- 否 --> F[回滚并分析失败]
F --> A
E -- 是 --> G[发布后继系统]
G --> H[后继系统参与下一轮研发]
H --> A
真正的关键在D和E。能提交代码，只证明执行环节更自动；若评测由同系列模型完成、研究目标仍由人设定、训练资源与上线权限仍由人掌握，就不能把整个闭环描述成自主递归。
这会怎样改变软件团队
当写代码变快，瓶颈会向问题定义、评审、测试、部署和事故响应移动。一个工程师可以同时发起更多修改，代码评审者却不会自动增加。若团队仍用“提交行数”衡量效率，就可能把更高吞吐误当成更高价值，最后得到更大的验证队列和更多隐藏回归。
具体场景是训练集群升级：AI可以并行查看日志、尝试环境变量、复现崩溃并生成修复。它能把两三天排障缩短到数小时，但生产变更仍应要求可重复复现、受控权限、回滚路径和人类批准。成功案例最值得复制的是实验纪律，不是“把集群权限交给模型”。
四个证据风险
第一，裁判同源偏差。Claude判断Claude是否成功，可能偏好相似表达或遗漏隐性错误。第二，任务构成漂移。曲线上升可能同时受到模型变强、工具改善和任务分配变化影响。第三，成功率不等于业务价值；修复一个排版问题与避免一次训练事故权重不同。第四，代码归因不等于因果生产率，AI生成行数多，不代表交付时间、缺陷率和维护成本同步改善。
文章也引用研究提醒，开发者对AI提效的主观估计可能高于客观测量。更可靠的团队评估应同时记录完成时间、返工、线上缺陷、回滚、评审负荷和长期维护成本，并保留无AI或不同工具的对照期。
我的判断与行动建议
AI编程正在把“能不能写”变成次要问题，把“谁定义成功、谁验证、谁承担后果”推到中心。 这轮变化可能显著加速AI研发，但目前公开证据更支持“强力人机研发循环”，而非完全自主的递归自我改进。
团队现在可以做三件事：把AI改动按风险分级；高风险变更要求独立测试与非同源评审；用交付周期和事故率替代代码行数做核心指标。研究机构还应公开任务抽样、判定一致性、失败类型和外部审计，否则最漂亮的增长曲线仍难跨组织比较。
对个人开发者而言，最稳妥的进步不是把Agent权限一次开满，而是逐步扩大“可验证任务”的范围：先让它修测试明确的小问题，再处理带回滚方案的模块变更，最后才接触生产诊断。能力增长越快，权限升级越应依赖证据而非新鲜感。
你会用什么外部证据，判断AI编程能力提升是真进步而不是评测口径变化？
关注「蜗牛聊AI」，一起看懂技术变化背后的真正机会。
本文首发于 java4u.cn，转载请注明出处。
