「问题不是 AI 写的代码，而是没人懂系统了」：一篇刷屏笔记的核验与解读
一句话结论：AI 生成代码的质量不是真问题——真问题是当团队所有环节（规格、代码、测试、文档）都由 LLM 产出且无人通读时，组织层面的系统理解会归零，而可维护性这个「最终 Boss」不会消失。
- 原文核心命题：AI 生成的代码大概率达到平均水平，真正的问题是「没人知道任何事了」——规格、代码、测试、PRD 全由 Claude 产出，无人通读，团队失去系统架构与设计意图的掌控。
- 五个子论点：快速创业公司的现状（12 小时工作只为按回车）；数据工程师的例外论（AI 只是去掉摩擦）；会提需求的产品经理现在能造任何东西（但选错地基难挽回）；最终 Boss 永远是可维护性；AI 无法自我驱动——意图、品味、设计、架构才是今天的杀手锏。
- 核验结果：ssp.sh 原文可达、引文完整（一手核验通过）；所引 X 帖与 HN 讨论链接在本网络不可达（000），未独立核验，文中如实标注。
- 我的补充判断：这套风险在「强监管、长生命周期」的系统里最致命——代码只是载体，可审计的知识链才是交付物；越快的生成速度越要求显式的架构决策记录（ADR）。
1 · 文献与作者
Simon Späti 是数据工程社区的活跃作者，ssp.sh/brain 是他的个人数字花园（digital garden）——特点是持续增量更新：这篇文章 09-26 发布（370 词），09-29 又增补了 515 词，处于活跃演化状态。09-28 前后它登上 Hacker News 讨论。文章结构是「核心命题 + 引用推文 + 分节评论」的观点集，不是实证研究——它的价值在判断与框架，而非数据，这也决定了后文核验的方式。
2 · 核心论点：问题不是代码，是知识真空
Späti 的出发点是社区里流行的那句话——「写代码已死（is writing code dead），AI 生成全部代码库」。他的回应是：即便如此，更大的问题是人或整个团队对系统架构、对设计意图「不再知道任何事」。他引用了一条自己参与的讨论：
「我认为 AI 写的大概是平均水平的代码（取决于任务和规模）。如果你的代码库低于平均，AI 能轻松把它拉到平均。至少我在这里观察到的就是这样。对我来说，问题不是 AI 代码，而是没人知道任何事了，所有人都只是问 Claude。最终你连计划都没有。」
注意这个论证的巧妙之处：它接受了「AI 代码质量达标」这个对 AI 最有利的假设，然后把问题挪到另一个层面——质量可以达标，理解无法代持。
3 · 五个子论点（双语对照 + 解读）
3.1 快速创业公司的现状
原文引用了 X 用户 @v0xium 的一条高热吐槽（入职大厂半个月的工程师自述）：
「工程现状糟透了。规格、代码、测试、PRD、工单、工单的解决记录、报告——一切都出自 Claude Code。……从 L1 到 L7 每个工程师都在做同一件事：和 Claude 谈。没有胜利的感觉。没有人在解决 bug。实际上，没有人在思考。所有事都由 LLM 完成。」「高层多次说：推代码不是瓶颈，那我们为什么慢？人们每天工作 12-13 小时，只是为了按回车。」
解读：这段话里最值得注意的不是抱怨，而是那个管理层的反问——「推代码不是瓶颈」在生成速度被 AI 拉满之后恰恰变成了假命题：当生成不再是瓶颈，瓶颈会迁移到别处（理解、验证、架构决策），而组织如果还在用「吞吐量」考核，就会把团队锁死在按回车上。
3.2 数据工程师是例外吗？
@HoytEmerson 的观点：「数据人不一样。我们从第一天起就必须了解产品和业务的一切。AI 只是替我们去掉了摩擦。」Späti 认同前半句——AI 时代之前的数据工程师确实必须懂全部业务（或拉上领域专家）才能弄清楚问题；但他紧接着提出警示：AI 让这种知识「看起来」过时了。今天才入行的人、包括他自己如果今天用提示词在一个新领域开工，那种知识就真的缺失了。「看似过时」与「真过时」的差距，就是未来事故的埋点。
3.3 产品经理现在能造任何东西？
@bseanvt 的观点：「我一直欣赏那种不会写代码、但能管理团队做出想要的软件的产品人。知道自己要什么，一直是最难的部分。」Späti 的延伸：好的 PM 现在确实可以自己造任何东西、找市场、把它做好看。但反转也在：不会代码的人，大概率会为产品打下一个很难维护的糟糕地基——虽然 AI 在迭代中也在变好，但如果你选错了语言、选错了心智模型，从第一行起就错了。结论：基础仍然是加分项，无论是对编程、对产品设计，还是对「既懂需求又懂系统与架构设计的好 PM」。
解读：这一条对「全民 vibe coding」叙事是最有分量的制衡——AI 拉平的是「把想法变成代码」的成本，没有拉平「判断这个地基能不能撑住三年」的成本。
3.4 最终 Boss 仍然是可维护性
这是全文的题眼。Späti：系统思维、架构、意图与设计，这些都让你成为更好的工程师。如今「手写代码可能已死，但它肯定有帮助」，「品味（taste）比以往任何时候都重要」。但最终 Boss 是、也永远是可维护性：生成一条快速流水线、一个应用、一个 BI 看板越容易，你要维护的就越多。而如果没人懂任何事，那会变得非常难。
3.5 AI 无法自我驱动
最后一条回应「为什么还需要人」：AI 不能给自己写提示词。Lambert 式的表述是：意图、品味、设计、架构，就是当今世界的杀手级功能。但一旦这些东西缺席——甚至更糟，基础性的东西丢了——就真的危险了。他还提到一个反驳：「这是自找的问题，如果还在招初级工程师，问题就不会发生」——但事情没那么简单（初级工程师的 培养/成本/产出结构 在 AI 时代本身就是被重构的变量）。
4 · 核查与验证
| 核查项 | 方法 | 结果 |
|---|---|---|
| ssp.sh 原文可达性 | 直接抓取（本机网络） | 200 通过，全文 7,155 字符，引文完整 |
| 文内引文与原文一致性 | 对照抓取正文 | 通过：各推文引文均完整收录于原文 |
| 发布/更新时间 | 页面元数据 | 09-26 发布（370 词）→ 09-29 更新（+515 词），活跃演化中 |
| Hacker News 讨论链接 | 直接访问 | 本网络不可达（000），未独立核验 |
| X 帖文（@v0xium / @HoytEmerson / @bseanvt） | 直接访问 | 本网络不可达（000），未独立核验；引文以作者转载为准 |
| 观点层声明 | 体裁判断 | 全文为观点集（opinion aggregation），无实证数据断言；事实层风险低，观点层请自行评判 |
5 · 我的解读：为什么这件事在强监管行业是十倍严重
「没人懂系统」在互联网创业公司里表现为债务（技术债），在医疗器械这类强监管、长生命周期行业里则直接撞上合规墙：设计 history、风险管理文档、可追溯性本身就是交付物的一部分。AI 可以帮你生成 design control 文档，但审计师问「为什么这么设计」时，答案必须来自人的判断链，而不是「Claude 说」。
三个可落地的动作：① 架构决策记录（ADR）显式化——AI 时代每个关键选型多写一段「为什么」，这是唯一不会随人员流动丢失的知识载体；② 保留「通读税」——团队固定投入一定比例的时间只读不产，把「无人通读」当成和「编译失败」同级的故障；③ 初级岗位不能取消——Späti 引用的反驳其实点破了要害：不招初级，三年后就没有「中层」，组织级知识断层是复利的。
一句话收束：AI 把「写」的成本打到接近零之后，「懂」成了新的稀缺品——而稀缺品的定价权，属于现在还在坚持弄懂系统的那批人和团队。
REF · 参考来源
原始文献
- Simon Späti, The Problem is not the AI Code, but Nobody Knows Anything Anymore, ssp.sh/brain, 2026-09-26 发布 / 09-29 更新（本文核验版本）
- Simon Späti, Writing Code by Hand Might Be Dead, but it Certainly Helps, ssp.sh/brain, 2026-09-24/25
- Hacker News 讨论串: item 49880312
文内引用帖
延伸阅读（同站）
- Simon Späti, Having Taste (with AI)
- Simon Späti, If Consumed by a Human, Should Be Written by Human
- Simon Späti, What I Learned Writing with AI
对本文有疑问、想交流技术方案或合作，扫码加我微信，备注来意通过更快。