吞噬自身的蛇:Claude Code源码揭示了人工智能工程文化的真相

2025 年 12 月 27 日，Anthropic 的首席工程师 Boris Cherny 在 X 上写道：“在过去的 30 天里，我为 Claude Code 所做的所有贡献，100%都是由 Claude Code 自己生成的。”共 259 个拉取请求，497 次提交，新增 40,000 行代码，浏览量达 130 万次。科技界对此表示赞赏。

三个月后，一起包装失误导致 512,000 行代码被公之于众。漏洞难免会发生，企业也能从中恢复。但漏洞本身并非最值得关注的事情。

代码就是故事。

为付费客户提供了 64,464 行核心 TypeScript 代码。有一个函数长达 3,167 行。在一家致力于开发全球最先进语言模型的公司里，用于情感分析的正则表达式。有个已知漏洞每天会导致 250,000 次 API 调用，虽然已在注释中记录，但该漏洞仍被保留了下来。

Anthropic 针对此次泄露事件作出了回应。原因是包装错误，属于人为失误。没有人被解雇。他们从未对相关代码作出过回应——因为泄露是意外，而发布代码则是经过刻意选择的。

无人竞得的拍卖会

要了解发生了什么，你需要看着数字不断上升。

2025 年 3 月。首席执行官达里奥·阿莫代在外交关系委员会上表示：“再过 3 到 6 个月，人工智能就会编写 90%的代码。”

2025 年 5 月。Boris Cherny 在 Latent Space 播客中表示：“总体而言，可能有 80-90%的代码是由 Claude 生成的。”

2025 年 9 月。阿莫代伊再次发表意见，这次持谨慎态度：“在 Anthropic 编写的代码中，有 70%、80%或 90%是由 Claude 生成的。”注意这个比例范围——70%并不等于 90%。但记者们却只报道了 90%这一数字。

2025 年 10 月。阿莫代在 Dreamforce 大会上与马克·贝尼奥夫对话：“我曾预言，六个月内 90%的代码将由人工智能模型编写。现在这一预言完全成真了。”当贝尼奥夫进一步追问时，阿莫代予以纠正：“并非所有情况都是如此。”

2025 年 12 月。切尔尼的推文。千真万确。

2026 年 2 月。思科 AI 峰会上，CPO 迈克·克里格表示：“就 Anthropic 目前的大多数产品而言，这一比例实际上达到了 100%。”

2026 年 3 月 7 日。切尔尼再次确认：“Claude Code 完全是由 Claude Code 自己编写的。”

2026 年 3 月 31 日。源代码地图被泄露了。

每隔两到三个月，这个数字就会像拍卖中的竞价大战一样急剧上升——而竞价者同时又是拍卖师。Later，LessWrong 网站称这些说法“具有误导性/夸大其词”，并指出这些指标从未被明确定义。是指 90%的代码行被编写了吗？90%的工程工作量了吗？还是 90%的字符被输入了吗？其中的区别至关重要。但 Anthropic 始终没有予以澄清。这种模糊性恰恰是他们的意图所在。

在实际操作中究竟是什么样子

该数值达到了 100%。随后，源代码被泄露了。从此，任何人都能看到 100%究竟产生了什么结果。

一个名为 print.ts 的文件中包含了一个函数，该函数长达 3,167 行，拥有 486 个分支点和 12 层嵌套结构。一位 HN 评论者详细列举了该函数中包含的功能：代理运行循环、SIGINT 信号处理、速率限制、AWS 认证、MCP 生命周期管理、插件加载、通过 while(true) 循环进行的团队负责人轮询、模型切换以及中断后的恢复机制。他认为：这些功能应该拆分成 8 到 10 个独立的模块。没人反对这一观点。

QueryEngine.ts 运行了 46,000 行代码。 Tool.ts 达到了 29,000 行。 commands.ts 达到了 25,000 行。入口点 main.tsx 的大小为 785 KB。

但传播最迅速的细节其实是正则表达式。在 userPromptKeywords.ts 这家拥有世界上最先进语言模型的公司里，他们是通过正则表达式来检测用户的沮丧情绪的： /\b(wtf|shit|fuck|horrible|awful|terrible)\b/i

用于情感分析的模式匹配技术。在一家大型语言模型公司里。一位 HN 论坛的评论者说出了大家都会引用的话：这就好比一家货运公司用马来运输零件。支持者则认为，正则表达式比进行推理计算更快、更经济。他们说得对。但这不过是工程文化使然罢了——便宜总比正确更重要，快速总比优质更重要，能上线就行。

该代码在正式环境中起什么作用

结构糟糕是一回事。你可以说这是风格问题。但泄露的源代码也展示了当这类代码在大规模环境中运行时会发生什么。

泄露的源代码中包含了一条 autoCompact.ts 的评论，后来成了一个象征性的语句：“共有 1,279 次会话中出现了 50 次及以上的连续失败情况（最多数达 3,272 次），导致全球范围内每天约有 25 万次 API 调用被浪费。”

解决方案只有三行代码：设置最大失败阈值，然后禁用该会话的压缩功能。仅仅三行代码，就避免了每天四十万次不必要的 API 调用。显然有人知道这个问题，还写了注释来记录它。但最终，该代码还是被发布了。

内存消耗情况也类似。社区测试结果显示，7 个 Claude Code 进程共消耗了 5.3GB 的 RAM。GitHub 上的反馈则更为严重：在一台 18GB 内存的机器上，有个进程的峰值内存占用达到了 36.5GB；另一个进程在 5 分钟内就将堆内存占用提升到了 93GB。

该问题追踪系统本身也是自动化运行的。由 Claude Sonnet 驱动的重复内容检测机器人会处理每一个新问题。定期检查机器人会在问题出现 14 天后将其标记为“已过时”，并在 14 天后自动关闭该问题。锁定机器人会在问题关闭 7 天后阻止用户对其发表评论。据分析，26,792 个已关闭问题中，有 49%到 71%是由机器人处理的。问题#38335 获得了 201 个赞成票，但团队方面没有给出任何回复。该问题被标记为“无效”。

“加快速度，而非增加流程”

有记录在案的漏洞、不必要的 API 调用、用户提交的 issue 被机器人直接关闭……这些在数据泄露之前就已存在。数据泄露只是证实了：这是一种刻意为之的行为，而非疏忽所致。而当数据泄露发生后，相关回应进一步证明了这一点的故意性。

切尔尼承认了人为失误：“我们的部署流程中有一些手动操作环节，我们没有正确执行其中的一个步骤。”他接着说：“和其他任何情况一样，解决这个问题的反直觉做法是想办法提高效率，而不是增加更多流程。在这种情况下，应该增加自动化处理，并让 Claude 来检查结果。”

这并非某一个人的观点，而是整个团队的理念。正如 HN 论坛上的一位评论者所说：“Claude Code 团队的理念是：对人工智能生成的代码进行代码审查毫无意义。只需更新需求文档，再重新生成代码即可。”

再读一遍。对于包含 3,167 行代码的函数、用于情感分析的正则表达式，以及那些基本集成测试就能发现的漏洞，正确的应对方式不是增加测试、进行代码审查或完善流程，而是加快速度、重新生成代码，然后让 Claude 来检查自己的工作。

这就是衔尾蛇。一条咬着自己尾巴的蛇。人工智能编写代码，人工智能审查代码，人工智能监控部署过程。当系统出错时，解决办法还是人工智能。这个循环永远没有终止条件。

正如我在《质量崩塌》一文中所述，我们在软件工程领域已将灾难性后果视为常态。那篇文章揭示了整个行业的普遍模式：产品发布时就有缺陷，稍后再修复，或者用更高级的硬件来解决问题。Claude Code 已不再是这种模式的典型例子，而是这种模式的“标本”。

这种哲学的界限在哪里？

如果他们采用“不进行审查，直接重新生成”的方式来构建产品，那么就有一个显而易见的问题：那些看不见的代码怎么办？

工程文化不是可以随意切换的。那个在编写 print.ts 代码时使用了 12 层嵌套结构的团队，在编写模型训练代码时并不会突然变得有条不紊。还是同一批人，同样的流程，同样的代码审查机制——或者说是缺乏代码审查。

他们为泄漏事件找了借口，也解释了包装错误的原因。但对于代码问题，他们却拒不解释。这种沉默已经说明了一切。在他们看来，质量没问题。他们就是故意这么做的。

有间接迹象表明问题更为严重。一个月内发生了 8 次服务中断。源代码映射信息泄露了两次（第一次在 2025 年初被悄悄修复）。在与源代码泄露同一天，Axios 所依赖的某个组件也因供应链攻击而遭到破坏。实际上，这只是一个 API 的命令行接口封装工具，却竟然依赖于 74 个 npm 包。

以下是使其能够暂时维持下去的机制：当拥有数十亿的收入和几乎无限的计算资源时，人们会选择用更多资源来“养肥”技术债务，而不是去解决它。某个功能有 3,167 行代码？不用重构，再增加点内存就行了。autoCompact 功能出现了错误，导致 250,000 次 API 调用失败？没关系，利润可以弥补这部分损失。模型性能下降了？那就增加 GPU 计算时间来训练吧。

只要资金源源不断，这种模式就能运转下去。Anthropic 是一家发展速度远超其工程能力提升速度的初创企业。AI 编写代码、AI 进行检测、AI 再做修改的循环，掩盖了其内在缺陷。但计算成本正在上升，收入周期也在发生变化。那些用资源暂时掩盖起来的技术债务，最终会变成无法摆脱的债务陷阱。

令人不适的真相

销售 AI 编程工具的公司，根本无法用自己的工具打造出优质的产品。人们关注的始终是那些百分比数字，而非产品本身。80%、90%、95%、100%……直到源代码真正发挥作用，才没人去追问所谓的 100%到底意味着什么。

AI 只会放大已有的东西。良好的纪律会带来卓越的成果；而没有纪律则会在机器运算的速度下演变成“技术债务”。Anthropic 已经选择了方向：更快地前进。让 Claude 去检验自己。而当系统出错时，就更快速地修正。

如果这就是推动我们行业前进的公司所制定的新质量标准，那我不确定自己是否愿意跟随行业的这个发展方向。

我的祖父是一名电气工程师。他告诉我：要么把事情做好，要么干脆别做。这是简单的原则。在 13 年的时间里，它一直指导着我组建团队、发布软件以及评估各个项目。质量不是一种附加功能，而是最基本的要求。

那种质量已经过时了。质量如今已成了过时的概念。没人需要它，没人愿意为此付费，也没人会去衡量它。现在的衡量标准是速度、代码生成的比例，以及你能多快交付一个包含 3,167 行代码、每天需要调用 25 万次 API 的函数，并宣称该函数是 100%由人工智能编写的。

我正在认真考虑转向安全领域。数据泄露、供应链攻击，以及像草稿一样的代码，这些都已成了新常态。总得有人来收拾那些编写糟糕代码的人留下的烂摊子。这可是个有发展前景的行业。

或者，我可能会成为一名电工。这是我祖父的行当。至少，只要线路连接正确，就不会出问题。没人会搞出那种会破坏接地保护功能的临时解决方案。也沒有机器人会在 60 天后自动关闭检查报告。

有一件事我很确定：我不想朝着这个行业目前的方向发展。如果在那家打造未来的公司里，“100%人工智能编写”的代码就是包含 3,167 行代码、486 个分支点的程序，那么未来需要的是更出色的工程水平——而不是更快的开发速度。是更出色而已。

我曾是 Anthropic 的忠实粉丝。曾经是。

‘码字派’译自：

https://techtrenches.dev/p/the-snake-that-ate-itself-what-claude

评论：

海森堡：我在软件行业工作了 21 年，参与过几家软件初创公司的运营。以我的经验来看，这篇文章所提到的态度和文化并不新鲜。

我合作过的所有 CEO、CTO 以及大多数项目经理，都抱有这种态度：无视技术债务，交付质量较低的代码。Anthropic 存在这种文化并不让我意外，而且我相当确信，其他任何人工智能公司也是如此。

令整个行业以及客户都更加头疼的是，这种做法如今已经实现了自动化。

过去那种“输入垃圾，输出垃圾”的情况，现在会变成频繁出现的“冲马桶，水又流出来了”的局面。

Dhaneor Briano：我只是一个业余的编程爱好者而已。多年来，我一直努力遵循所有关于编写优质、整洁代码的建议。但这反而让我头疼不已，也增加了代码的复杂性。现在我才发现，无论是专业人士还是编程助手，根本都不在乎这些。

这篇文章也打破了我认为 Claude Code 是专业级产品的幻想。我使用的是 opencode 和 pi。但我一直怀疑，比起 Anthropic 那些高薪人才打造的成熟产品，它们的表现是否逊色。

但这更坚定了我的怀疑：美国人唯一真正擅长的事情就是讲故事。几乎所有美国制造的产品，最后都不过是被过度宣传的垃圾罢了。