AI 写出的代码往往能跑、能过测试，但围绕它的讨论正在从「代码对不对」转向一个更棘手的问题：还有没有人真正理解这套系统。
发生了什么
一篇题为《The problem is not the AI code, but nobody knows anything anymore》的文章在 Hacker News 上获得大量关注，进入热榜。文章的核心论点并不复杂：当越来越多的代码由模型生成并被直接合入代码库，问题不在于这些代码有 bug，而在于团队逐渐失去了对代码库的整体认知——没人能完整说清某个模块为什么这样写、边界条件从何而来、当初的取舍是什么。讨论区的共鸣点也集中在这里：代码通过了评审和测试，但「理解」这一层被跳过了。
为什么重要
软件工程长期依赖一个隐含前提：写代码的人理解自己写的东西，评审的人理解被合入的东西。测试和类型系统能覆盖一部分正确性，但覆盖不了意图、上下文和演化历史。AI 生成代码把这个前提打破了——产出速度远快于人类消化速度，代码库以团队无法同步理解的速度膨胀。
这不是新问题。遗留系统、外包代码、人员流动都曾造成「没人懂这块」的局面。区别在于规模和速率：过去这种理解断层是缓慢积累的，现在它可以在几个迭代周期内形成。当系统出故障时，排查依赖的是对系统的心理模型，而这个模型正在被稀释。
影响与看点
对开发者的直接影响是角色重心的迁移：写代码的比重下降，读代码、验证假设、维护心智模型的比重上升。评审环节会变得更关键，但传统的「看 diff」评审在面对大段生成代码时效率存疑。
对团队而言，值得关注的是几类应对思路：把「解释为什么」变成硬性交付物，而不只是提交代码；对关键路径保留人工重写或深度走查；在文档和架构决策记录上投入更多，而不是更少。工具层面，代码理解、依赖分析和变更影响评估类工具的价值会被重新定价。
一个值得留意的判断是：AI 降低的是「产出代码」的成本，但没有降低「拥有一个系统」的成本。后者需要的是理解、责任和长期维护意愿，这些恰恰是当前工作流里最容易被省略的部分。真正的问题或许不是 AI 会不会写错代码，而是当没人再需要读懂代码时，组织是否还具备修复它的能力。
