AI 自己造 AI，程序员真正要害怕的不是失业

AI 自己造 AI，程序员真正要害怕的不是失业

大家好，我是唐斩。

今天这篇来自 Anthropic Institute，标题叫《When AI builds itself》。它讲的是 recursive self-improvement，也就是 AI 系统有没有可能自己设计、训练、改进下一代 AI。

我的判断先放前面：这篇值得程序员认真看，但别只盯着“AI 自我改进”这个大词。

更现实的变化已经发生了：AI 正在拿走工程和研究里的执行层。写代码、跑实验、修 bug、做批量清理、复现实验，这些过去需要人一点点推进的事，正在变成智能体可以长时间接手的任务。

对程序员来说，真正的压力不是“明天就失业”。真正的压力是：你如果还只把 AI 当补全工具，工作方式会落后一代。

核心论点

核心论点

1. 这篇文章真正说了什么

Anthropic 给了一个很清楚的时间线。

2021 到 2023 年，人类还在像普通科技公司一样写代码、写文档、训练模型。2023 到 2025 年，Chatbot 开始帮人写小段代码。2025 到 2026 年，编码智能体能自己写文件、改文件。到今天，智能体已经能运行代码，也能把几个小时的工作委派给其他智能体。

这不是普通的“模型更聪明了”。它描述的是 AI 开发流程的闭环正在被一点点补上。

Anthropic 披露了几个数字：

2. 截至 2026 年 5 月，合并进 Anthropic 代码库的代码中，超过 80% 可归因于 Claude。
3. 2026 年第二季度，典型工程师每天合并的代码量约为 2024 年的 8 倍。
4. 在一个固定目标的优化实验里，Claude 从 2025 年 5 月约 3 倍加速，到了 2026 年 4 月约 52 倍。
5. 在一些开放式研究判断场景里，模型越来越能提出比人类当时选择更好的下一步。

但 Anthropic 没把话说满。它明确承认，完整递归自我改进还没有发生，也不必然发生。今天 AI 和未来“自己设计继任者”的 AI 之间，还隔着一个关键差距：目标选择和研究判断。

这也是我觉得这篇文章有价值的地方。它不是单纯喊口号，而是把一个阶段讲清楚了：执行已经开始自动化，判断还在人类手里。

2. 对程序员的影响，不是写不写代码

很多人看到 80%、8 倍、52 倍，会立刻把问题翻译成：程序员是不是没用了？

我觉得这个问法太粗。

更该问的是：程序员把时间花在哪里，才算有杠杆？

如果 AI 能写大量代码，人类继续拼手速就没意义了。你每天多敲 300 行，和一个能并行跑任务、查上下文、改文件、跑测试的 Agent 比，优势很弱。

但这不等于程序员没价值。价值会换位置。

人类瓶颈迁移

人类瓶颈迁移

以前你的价值在“我能实现”。现在你的价值越来越多在：

2. 我知道什么问题值得做。
3. 我能把模糊目标拆成可交给 Agent 的任务。
4. 我能设计验证器，判断结果是不是对。
5. 我能看出代码短期能跑、长期会不会把系统拖坏。
6. 我能决定哪些速度值得追，哪些速度会制造债务。

这也是为什么我一直说，AI 编程的核心不是提示词，而是工作流。

提示词解决的是一句话怎么问。工作流解决的是：上下文怎么给，任务怎么拆，结果怎么验，失败怎么回滚，多个 Agent 怎么协作，最后谁负责。

3. 递归自我改进先别神化，它现在更像组织加速器

“AI 自己造 AI”听起来很科幻，但落到今天，最值得普通开发者观察的不是终局，而是中间态。

中间态是什么？

人类还在定方向，AI 已经承担大部分执行。人类不再亲手做所有实验，而是管理一组可以跑实验、写代码、修 bug、生成工具的执行系统。

这会带来一个很直接的结果：组织能力被重新定价。

Anthropic 在文中提到一个关键点：当代码生成变快，人类 code review 会成为新瓶颈。这就是 Amdahl 定律在组织里的版本。

一个环节提速 10 倍，整个系统不一定提速 10 倍。你会撞到下一个没有提速的环节。

AI 研发闭环

AI 研发闭环

对公司是这样，对个人也是这样。

如果你的 AI 写代码能力提上来了，但测试体系、需求澄清、代码审查、部署回滚、线上观测没跟上，你得到的不是生产力，而是更快地产生不确定性。

所以我不建议把这篇读成“快去用某个模型”。我建议读成一个提醒：以后开发者的竞争，不只是模型用得多，而是谁能把 AI 速度接进自己的工程闭环。

4. 普通开发者现在能不能用？

能，但不要照搬 Anthropic 的数字。

Anthropic 有自己的研究团队、内部工具、代码库、权限系统和模型资源。普通团队不能看到 8 倍，就预期自己下周也能 8 倍。

普通开发者更应该从小闭环开始。

第一，把任务写成 Agent 能接的工单。

不要只说“优化一下这个模块”。要写清楚目标、输入文件、验收标准、不能动的边界、测试命令、失败时怎么停止。

第二，把验证器补上。

能用单元测试就写单元测试，能用脚本检查就写脚本检查，能用截图回归就做截图回归。没有验证器，Agent 生成越快，你越难知道自己拿到的是结果还是幻觉。

第三，把 review 从“看代码”改成“看风险”。

AI 很擅长堆实现，但它不一定知道你的系统历史、业务优先级和长期维护成本。人类 review 的重点应该前移到边界、状态、权限、数据迁移、失败恢复这些地方。

第四，保留方向感。

Anthropic 文中反复提到，今天人类的比较优势仍然在大局、研究品味和问题选择。这个判断对普通开发者也成立。你越依赖 AI 执行，越不能放弃自己判断什么值得做。

开发者行动框架

开发者行动框架

5. 坑在哪里

第一，别把代码行数当生产力。

Anthropic 自己也提醒，代码行数会高估真实生产力。AI 可以让你合并更多代码，也可以让你合并更多以后要维护的复杂性。

第二，别让 review 变成形式主义。

当 Agent 一次提交几百行、几千行，人类如果只是扫一眼，审查就失效了。你需要更强的自动检查、更小的任务边界和更清楚的变更说明。

第三，别把“会执行”误读成“会负责”。

Agent 能跑任务，不代表它理解组织后果。线上事故、用户损失、安全风险，最后仍然落在人类和组织身上。

第四，别忽略协作成本的变化。

以前你请同事帮忙，会产生讨论、互相理解和团队记忆。现在很多小忙可以交给 AI，效率更高，但团队共同上下文可能变薄。这个变化不一定坏，但需要有意识地管理。

6. 我的建议

这篇我会谨慎推荐。

推荐给三类人：

2. 正在用 Claude Code、Codex、Cursor 或其他 Agent 工具写代码的人。
3. 团队里已经出现“AI 生成很多代码，但 review 跟不上”的技术负责人。
4. 关注 AI 编程长期趋势，但不想只看模型发布新闻的开发者。

不推荐的读法是：看完以后焦虑，或者直接喊“程序员完了”。

我的读法更简单：执行层正在被自动化，判断层会变得更贵。

所以从今天开始，程序员要练的不是“怎么让 AI 写更多代码”，而是“怎么让 AI 写出的东西进入一个可靠闭环”。

你要有任务拆解能力，要有上下文工程能力，要有验证器，要有 review 标准，也要有说“不做这个”的判断。

AI 自己造 AI 也许还没到。

但 AI 帮你造更多软件，这件事已经到了。

来源：Anthropic Institute · When AI builds itself