问题不在 AI 写的代码，而在没人再了解系统架构和设计意图
文章摘要
这是数据工程作者 Simon Späti 公开”第二大脑”笔记库里的一篇短笔记，原标题是《问题不在 AI 代码，而在于再也没人知道任何事》，HN 上的标题被改成了现在这个更具体的说法。笔记创建于 2026 年 9 月 26 日，之后又修改过几次，作者自己标注为”生长中”的状态：写得比较粗，有不少要点和空白，观点也会更新。全文不到一千词，更像是一组观察和引用的串联。
核心论点。 作者说，就算我们认定手写代码已死、所有代码库都由 AI 生成，他依然觉得更大的问题是个人乃至整个团队对系统架构、对”当初为什么这么选”的意图一无所知。他在一次讨论里写过：AI 写出的代码大概是”平均水平”（取决于任务和规模），如果你的代码库原本低于平均，AI 很容易把它拉到平均。所以问题不在 AI 的代码，而在于”没人知道任何事，每个人都只是去问 Claude，最后根本没有任何计划”。
快节奏公司的现状。 作者引用了一条在网上流传的推文，称它很好地概括了快节奏创业公司、或者中层大力推行 AI 的大公司的现状。发推者说自己入职一家大公司半个月，”这里没人知道任何事”：规格说明、代码、测试、PRD、工单、工单的处理结果、报告，全都由 Claude Code 生成。团队里没人喜欢这样，但被逼着尽可能多地交付；高层反复说”推代码已经不是瓶颈了，为什么还这么慢？”。人们每天工作十二三个小时，”只是为了按回车”，没人读任何东西。从 L1 到 L7 的工程师都在做同一件事：和 Claude 对话。没有成就感，没人在真正解决 bug，”实际上已经没人在思考了”。他说如果至少给时间看看代码、搞清楚东西往哪儿走，他也不介意，但目标只有一个：交付，不管发生什么。作者还引用了 Matthew Mullins 的一句话：我们现在面临 COBOL 程序员退出劳动力市场的问题，而智能体编程会把这个问题带到每一种编程语言。
产品经理能造出任何东西了吗？ 有人认为好的产品经理现在可以自己造出想要的东西、找到市场、做得好看。作者引用 Sean Behan 的话：”我一直很佩服那些不会写代码、却能管理团队得到想要的软件的产品人，知道自己想要什么一直是最难的部分。”但作者也提醒，如果你不懂编程，很可能会为产品打下一个很糟、很难维护的地基；虽然 AI 在这方面也在进步，尤其当你频繁迭代时，但选错语言或心智模型，一开始就错了。无论是编程还是设计产品，懂基础都有帮助；好的 PM 不仅知道需要什么，还理解系统和架构设计。
数据工程会不一样吗？ Hoyt Emerson 认为数据人不同，他们从第一天起就必须了解产品和业务的方方面面，AI 只是消除了摩擦。作者同意前 AI 时代成长起来的数据人确实必须了解很多（或者去找领域专家），但 AI 让这些知识变得”看似多余”。所以今天入行的人，或者作者自己如果现在在一个新领域靠提示词起步，就会缺失这部分知识。
终极 Boss 仍然是维护。 系统思维、架构思维、拥有意图和设计感，都能让人成为更好的软件工程师。手写代码也许已死，但它确实有帮助，而”品味”（taste）在 AI 时代比以往更重要。终极 Boss 过去是、将来也永远是可维护性：生成一条数据管道、一个应用或一张 BI 看板越容易，你要维护的东西就越多；如果没人懂任何东西，维护会变得非常困难。
AI 不能自己驾驶自己。 作者说 AI 不能给自己写提示词，这清楚说明仍需要人来引导和编排，这也是为什么意图、品味、设计和架构在今天都是”杀手级特性”。一旦这些缺失，更糟的是基础本身流失了，就非常危险。他提到读到一种观点：这是自作自受，如果我们还在招初级工程师，问题就不会发生，但他觉得事情没那么简单。笔记最后引用 Harry Dry 的话”伟大的点子与其说关乎创造力，不如说关乎信念……没有能生成信念的 AI 提示词”，并链接到作者关于”人读的东西应由人来写”等相关笔记。
HN 评论精华
本帖 388 分、约 240 条评论。原文篇幅很短，讨论的展开远超文章本身，主要沿着几条线：AI 让组织里的决策链条变得无人负责；”写代码是理解系统的必经之路”与”读 AI 代码也能理解”之争；以及相当多人认为”这在 AI 之前就存在”。
得票最高的是 zero_shift 的一段追溯。 他周末试图追溯公司里一个决定的来龙去脉：代码是 Claude 根据提示词写的；提示词对应的工单是 Atlassian 的 AI 集成生成的；Atlassian 消化的是 AI 写的文档；文档来自他”90% 确定完全由 Claude 撰写”的战略备忘录；战略是管理层在高管的催促下选定的；而高管现在主要也用 AI 写的备忘录沟通，引用的是科技网红、市场形势和客户期待。那到底是谁做了这个决定？他们做这个功能，不是因为想要，而是因为觉得别人期待他们做。再往上追，投资者和客户的期待又来自对技术一知半解的炒作和反馈循环。他的结论是：”这个生态里没有任何人真正在掌控。”没有人围绕真实、具体的目标行动，一切都建立在投机和对未来的焦虑上，”讽刺的是，这很像我们本来要避免的那种’未对齐’的超级智能”。
这条评论引出大量回应。RGS1811 给这种现象起名叫”承诺洗白”（commitment laundering）：人们传递没人真正读过、想过的 AI 产物，凭空编出来的假设和附带承诺不断累积，看起来来历清楚，却没人说得清在做什么、为什么。saltcured 补充说与之配套的还有责任洗白和功劳洗白。perrygeo 则更犬儒：”这可能才是管理者和投资人爱 AI 的真正原因，它稀释了责任，’哎呀是 AI 搞砸了’是糟糕管理的绝佳借口。”ashleyn 说他认识的业内人觉得工作”太轻松了”，只需当 Claude 的”肉身代理”领工资，AI 写的问题就用 AI 答回去，bug 来了把 Jira 链接丢给 Claude；大家一边预言自己必然被裁，一边激进投资，像是”在被赶走之前尽量从墙里多扯点铜线”。mhurron 说他们公司领导明确表态：任何没有 AI 参与的流程都应视为有问题，”即使它运转正常，只要 100% 是人做的，就是坏的”，你应该处在一旦失去 AI 工具就无法继续工作的状态。也有人泼冷水，danielmarkbruce 和 tarsinge 都说很多公司在 AI 之前就是这样：高层听委员会的，委员会听咨询公司的，咨询公司推荐别人在做的和 Gartner 说的，”AI 只是让它变得明显了”；ryaniscool 不同意，说他拒绝相信大多数公司的大多数人都在装懂，这是为了套用”人类也这样”的经典反驳而刻意夸大。
“代码是错误的抽象层”之争。 bengold14 说 LLM”已经解决了编码”，但没解决系统、协作和维护，代码是我们工作的错误抽象层（他顺带推广了自己的项目）。verdverm 质疑”解决了编码”到底什么意思，照这么说岂不是也”解决了写作”；glimshe 说这种话是为了显得聪明，说”降低了编码成本”就太无聊了。yetanotherjosh 给出了一个较有说服力的定义：如果你能写出很好的 PRD、精细的技术规格、有力的测试用例，再配上能互相交叉检验的对抗式代码审查，顶尖智能体可以自主写出达到或超过多数人类团队水平的代码，”我称之为解决了，但前提是满足这些上下文要求，而这一层仍然很难”。jplusequalt 讲了一个反例：他们团队花两周追查 TensorFlow Lite 为什么生成无意义的 OpenCL 内核，最后发现是 LLVM 在他们平台的 RISC-V 汇编里有 bug，靠翻汇编、十六进制转储和源码才找到，如果代码是错误的抽象层，这种问题怎么办？
写代码才能理解系统吗？ glouwbug 的评论很有共鸣：写东西时你会通过重构和重写不断修正理解，直到内化；内化之后你才能在关键的停机时刻推理它、沟通它，”真不敢相信我们完全忘了四年前世界就是这么运作的”。vividfrier 讲了一个对比鲜明的经历：过去团队接手一个系统，他和一位优秀工程师一起重构，最终成了这个系统的专家；最近又从别的团队接手一个系统，请求做知识交接，对方回答”现在还做这个吗？问 Claude 就行”。几个月过去，功能也上线了，他依然不知道它怎么运作，”AI 是我们这个行业遇到的最糟糕的事”。vld_chk 七月底换了工作，头四周觉得 AI 带来了自由，入职从没这么轻松；两个月后开始反噬，”我还是什么都不知道”，因为 AI 替他读代码、替他写代码，他把这当成了自己的理解，现在只好强迫自己限制 AI、自己读一点写一点。enraged_camel 则认为理解现在是自顶向下形成的，可以从外部一层层剥开 AI 做的功能，就像读教科书，只要投入时间同样有效，但问题是投入了时间就不再省时间了；wholinator2 反驳说读教科书和自己做题效果并不一样。cmrdporcupine 觉得走到”人放弃作者身份”这一步并非必然，早期 Copilot 那种补全模式让人始终在驾驶座上，他很喜欢，只是后来行业全面转向了”你去做吧”的聊天循环。
simonw（Simon Willison）的观点比较平衡：如果不理解系统怎么运作，你对它做出好决策的能力会迅速退化。不需要审每一行代码，但必须能描述系统怎么工作、高层结构是什么，当过技术负责人或工程经理的经验在这里很有帮助。curt15 问：当技术负责人不再靠成千上万小时内化代码来成长，未来的技术负责人怎么避免变成”从小用计算器、一直没搞懂分数”的人？simonw 说他希望”孩子们会没事的”，学习的路径都还在，我们从没拥有过这么丰富的学习工具，有心的人会成长，偷懒的人会更容易伤到自己。
“这在 AI 之前就存在”。 behnamoh 说在 Google 这样的大公司，真正知道自己在做什么的人一直不多；madspindel 的公司有好几个二十多年的老系统，800 万行代码，用他不懂的语言、甚至他不会说的自然语言写成，他们正是靠 AI 才弄懂它们怎么运作；chasd00 说现实中本来就没有一个人对系统有端到端的心智模型。zzzeek 认为那条推文描述的不过是创业公司一贯的样子：”创业公司什么时候不烂过？”briandw 问：有谁能从机器码到晶体管讲清楚一颗 Ryzen 处理器怎么工作吗？ttul 拿汇编到 C 的转变类比，ab71e5 立刻指出关键区别：过去不必看汇编，是因为编译器的输出保证符合规则，LLM 没有这种保证。
还有几个现实的视角。 Paul-E 指出很多公司出现了”问责与权限错位”：AI 改动不经审查、不经你同意就快速合并，你怎么可能对理解系统负责？他建议和老板谈清楚你到底对什么负责。malfist 说”负责任的人在回路中”听起来不错，但 99% 时间不响的警报不会有人认真看，而且他们公司刚把每个职级每年预期交付的功能数翻倍，CEO 要求”每个季度交付过去十年的成果”。MomsAVoxell 来自安全关键、需要认证的行业，说那里任何代码都必须经过人工审查，所以影响不大；nicoburns 回应说问题恰恰在于很多公司借 AI 把审查流程拿掉了。andy_ppp 则觉得负面情绪难以理解，他说自己的交付速度大约是以前的 10 倍，在糟糕的遗留代码上做大范围改动也很轻松；sdevonoes 回复：明年你可能失业，或者工资减半，或者被要求 10 倍产出而发疯。tangled 用长跑的”负分段”作比：如果竞争对手把 Claude 的输出直接推上生产，第一年他们会领先，但只要你撑到第二、三年……chasd00 提醒，到那时你可能落后得更多。
另有一个小插曲：chinathrow 一打开博客看到”AI 生成的模板”就离开了，作者 zazuke 本人回复说这个站点用 Quartz 搭建，早在 AI 出现前就是这个配色和风格，代码也在 GitHub 上公开；chinathrow 道歉说是米色背景加亮绿色”最近更新”标签触发了他”这是 Claude 做的模板”的直觉，作者表示会去掉那个绿点。