问题不在 AI 代码，在没人懂架构

一个常见的辩护是：AI 写的代码也就是平均水平，如果你原来的代码比平均还差，它还帮你提升了。

这话可能没错，但它回答的不是关键问题。关键问题是：半年后系统出故障，你们团队里有没有人说得清它是怎么搭起来的。

一、发生了什么

数据工程师 Simon Späti 在个人笔记站写了这篇文章，9 月 26 日发布，10 月 3 日更新，大约 950 词。文章由 ThePrimeagen 的一段视频引发，但他把话题从「AI 会不会写代码」推到了「团队还知不知道自己在维护什么」。

他引了一位刚入职大公司的人的描述：需求文档、代码、测试、工单、工单的处理结果、汇报，全部由编码 agent 产出；没人读，也没人改；管理层认为提交代码不是瓶颈，于是大家每天工作十二三个小时，主要动作是按下回车。

又引了一位同行的类比：COBOL 程序员退休带来的维护危机，编码 agent 会把它带到每一种语言上。

他自己的判断是：如果团队选错了语言、选错了心智模型，AI 只会让这个错误的起点更快落地。产品经理现在可以自己做出一个能上线的东西，但「知道自己要什么」本来就是最难的部分，而「知道怎么搭」仍然需要基本功。

文末他给了一个排序：意图、品味、设计、架构，是今天最稀缺的东西；维护是永远的最后关卡。生成越容易，需要维护的东西越多。而如果没人懂，维护就会变得非常难。

文章也收了一个反例。一位数据工程从业者说，做数据的人从第一天起就得懂业务，AI 对他们只是减少了摩擦，不是替代了理解。Späti 同意一半：在 AI 之前入行的人，确实被迫补过这课；但今天才入行的人，如果一开始就靠提示词干活，这段知识就跳过了。同一个岗位，两代人的底子不一样。

二、跟你有什么关系

写代码的。 你的价值不再是产出速度，而是能不能在评审时说清「为什么不是另一种做法」。这句话 AI 替不了。

带团队的。 你可以要求 agent 提 PR，但不能让团队失去画架构图的能力。没有人能画出数据怎么流、边界在哪，故障就只能靠重启解决。

做产品的。 能生成不等于能负责。选错技术栈的代价，不会因为代码是 AI 写的而变小。

三、怎么判断你的项目有没有这个问题

1. 做一次「关掉 AI」的架构问答。 随便点一个模块，问负责人：它为什么存在、依赖谁、坏了会影响什么。答不上来，说明知识已经不在团队里。
2. 看 PR 的描述是谁写的。 如果描述只复述了改动，没有说明取舍，那它没有传递意图。评审通过不等于理解发生。
3. 数一数「没人敢动」的模块。 AI 生成得快，这类模块会增加。列出来，安排人读懂，比继续加功能优先。
4. 把维护成本算进立项。 一个新管线、一个新看板上线很容易，但它每年要人修。生成之前先问：谁负责它三年。
5. 保留一条人工设计的路径。 关键模块的接口、数据模型、错误处理策略，由人先定，再让 AI 填实现。顺序反了，后面很难纠。

四、三个别信的说法

「代码能跑，说明设计没问题。」 能跑只说明当前路径通。架构问题通常在流量、并发、故障和人员变动时才暴露。AI 很擅长让一条 happy path 跑通。

「补文档就行了。」 文档是结果，不是理解。团队没有参与设计过程，写出来的文档也只是对代码的事后描述，遇到取舍问题仍然答不上来。

「AI 会自己在多轮修改中保持架构一致。」 它只能看到你给它的上下文。跨模块的约束、三年前的一个决定、某个客户的特殊要求，没写进上下文就不存在。一致性得有人守。

五、一句话结论

AI 能把代码补到平均线，但补不上「这个系统为什么长这样」；后者没人知道时，快出来的每一行都在增加未来的维护债。

信息来源

• The Problem is not the AI Code, but Nobody Knows Anything Anymore，Simon Späti，2026 年 9 月 26 日发布、10 月 3 日更新

功能与价格以官方公告为准。本文写于 2026 年 10 月 19 日。