写代码的代码

这里有个数字，应该会重新校准你对编码智能体的看法。Anthropic 现在说，合入它自己系统的代码中有超过 80% 是 Claude 写的——而在 Claude Code 于 2025 年初发布之前，这个数字还只是个位数。打造模型的那家公 司，用这个模型打造了自己大部分的软件。

而 6 月 5 日，它发布了一份关于递归自我改进的报告 ——一种帮忙打造下一代、更强 AI 的 AI——把这个想法从思想实验的范畴，推进到一张带有阶段和安全检查点的 路线图里。Axios 把这条警告 说得很直白：AI 很快就能帮忙打造自己的继任者。

你可以把它当成一个吓人的标题。我更愿意抓住那个已经为真、也已经有用的部分。

80% 才是真正的故事

先把曲线的远端忘掉一秒。地面上的事实是：一家前沿实验室——拥有最多上下文、押注最高、对糊弄活儿最没 耐心的那群人——把自己绝大部分的代码都通过一个智能体发了出去。这不是演示。这是在最懂这个模型的地方， 一种生产实践。

它告诉你，问题不再是智能体能不能写代码。它能。问题是这件事对你的工作落在哪儿产生了什么影响。

当智能体写代码时，评审就成了工作本身

如果 80% 的代码是生成的，那么你 100% 的杠杆就移到了两个地方：你要求了什么，以及**你怎么检查回来 的东西。**瓶颈不再是敲字，而是变成了规格说明和验证。

这就是我相当长一段时间以来的整个工作模式。我不用手写代码；我指挥智能体，把架构、规格和质量底线攥在 自己手里。而让它行得通的，不是某个聪明的提示词——而是我不会因为输出看起来对就信它。我会去验证它。 智能体出代码越快，整个系统就越依赖于末端那道检查的强度。

这就是为什么 eval 思维不再是锦上添花。当一个人慢慢地写下每一行时，书写本身就是评审。当智能体在几秒 内写完时，评审就必须是刻意的、独立的、可度量的——否则你只是在高速合入看起来很像样的代码。

「自我改进」应该改变你哪些习惯

不必等递归自我改进落地，这个教训才会咬人。智能体已经好到能生成远超你肉眼能扫完的量。所以：

• **把规格说明当成你为之流汗的那件作品。**智能体会忠实地照你真正说出口的去做。规格含糊，代码就会 自信地出错。你的精确度就是产品。
• **在「生成」和「合入」之间放一道可度量的检查。**测试、eval、一个负责评审的第二个智能体——某个在代码 落地之前能给出一个数字、而不是一种感觉的东西。
• **盯住速率，而不只是产出。**如果生成速度在涨，而你的验证还停留在手动，这道差距就是纯粹的风险。让检查 随着书写一起扩展。

实验室正在把书写它们继任者的活儿自动化。无法被自动化掉的那份人类工作，是决定应该造什么，并证明造出 来的东西是对的。

底线

Anthropic 用 Claude 写了 80% 的代码，这不是关于未来的警告——而是对当下的描述。智能体已经在写代码了。 递归自我改进只是把同一个旋钮往同一个方向又拧远了一点。

**随着书写被自动化，你的杠杆会坍缩到规格说明和检查这两处。**为规格流汗，在合入之前放一道可度量的关卡， 让验证扩展得和生成一样快。写代码的代码，仍然需要一个能证明它是对的人。