我们正在进入的危险状态：没人真正理解的系统
"
"一个没人真正理解，但大家都还能继续往上写代码的系统。"
这句话来自一位硅谷资深工程师的深夜推文。它精准地描述了一个正在蔓延的现象——我们正在构建的东西，已经没有人能完整地理解了。
而最危险的是：它还在正常运转。
一个真实的故事
2024年，某大型互联网公司的支付系统出了一次事故。
排查过程中，团队发现一个核心模块已经运行了7年。最初写它的工程师早已离职，文档是3年前更新的，测试覆盖率不到30%。没人敢动它，因为它「一直好好的」。
这次故障的原因：一个时间戳格式的微妙变化，在不同的时区条件下触发了边界异常。
团队花了3天才定位到问题。
这3天里，他们反复说的一句话是：「这段代码到底在干什么？」
抽象的诅咒
现代软件开发的本质是一层层抽象。
- 你用 React 写前端，不需要理解 Virtual DOM 的 diff 算法
- 你用 Kubernetes 部署服务，不需要理解容器的 cgroup 和 namespace
- 你调一个 REST API，不需要知道底层走的是 TCP 还是 QUIC
- 你用 AI 生成代码，不需要理解 Transformer 的注意力机制
抽象是进步的标志。 每一层抽象都让更多人能参与建设，让复杂系统变得可用。
但抽象也是一个诅咒——它让我们习惯了「不理解也能工作」。
当每一层都只需要理解上一层的接口时，整个系统就变成了一个巨大的黑箱。每个人都在自己的层里忙碌，但没有任何人能看到全貌。
AI 让这个趋势加速了
现在，AI 编程工具正在把这个问题推到一个新高度。
以前，你至少需要读懂代码才能修改它。现在，你可以让 AI 直接生成补丁，提交 PR，通过 CI，合并部署——全程不需要真正理解这段代码的含义。
这不是科幻。这正在发生。
AI 生成的代码往往能通过测试、能跑起来、能解决问题。但它也常常包含一些微妙的「不合理」——没有被测试覆盖的边界情况、与业务语义不一致的命名、看似正确但逻辑上冗余的分支。
这些东西不会在第一天暴露。它们会像定时炸弹一样，埋在代码库的深处。
等到下一个工程师（或者下一个 AI）来修改这段代码时，没人知道哪些是刻意的设计，哪些是随机的产物。
最可怕的不是崩溃
你可能会说：「代码能跑就行啊，管它理不理解？」
问题是——系统不只是代码。
系统是代码、是配置、是环境变量、是第三方依赖、是运维人员的肌肉记忆、是团队成员脑子里的隐性知识。
当这些东西散落在各处，没有人能把它们串起来时，系统就进入了一种「薛定谔的稳定」状态：
- 它看起来是稳定的
- 没人知道它为什么稳定
- 任何改动都可能让它不稳定
- 一旦不稳定，没人知道怎么修
这不是崩溃，这是脆弱。一个脆弱的系统和一个健康的系统的区别，不在于它是否在运行，而在于——如果出了问题，需要多久才能恢复？
三种危险信号
你的系统可能已经进入这个危险状态了吗？看看有没有这些信号：
信号 1：「不要动那个模块」
如果团队里有任何一个模块被标记为「不要碰」或「谁写的谁来改」——恭喜，你已经有了一个无人理解的子系统。
信号 2：AI 生成的代码直接进入生产环境
如果团队的流程允许 AI 生成的代码在没有深度人工审查的情况下直接合并部署——你的代码库正在快速积累不可控的复杂性。
信号 3：新人无法在三个月内独立修复核心模块的 bug
如果一个有经验的工程师加入团队后，需要超过三个月才能独立修复核心模块的问题——说明系统的认知负担已经超出了人类的承载能力。
我们能做什么？
这不是一篇悲观的文章。这是一个预警。
我们正在构建的东西，规模和速度都超过了以往任何时代。但我们也需要正视一个事实：人类的理解能力是有上限的。
这里有几件事，值得每个团队现在就开始做：
1. 强制知识轮转
不要让任何模块只有一个人理解。建立「结对维护」制度——每个核心模块至少有两个人能读懂并修改它。
2. 把「为什么」写进代码注释
代码告诉你「做什么」，注释应该告诉你「为什么」。特别是那些看起来奇怪的决策——为什么用这个算法？为什么不用更简单的方案？这些上下文比代码本身更珍贵。
3. 定期进行「理解度测试」
每隔一段时间，随机选一个核心模块，让团队里不熟悉它的人尝试解释它的逻辑。如果解释不清楚，说明这块代码需要更好的文档和更清晰的结构。
4. 对 AI 生成的代码设置更高的审查标准
AI 生成的代码应该接受比人类代码更严格的审查，而不是更宽松的。因为 AI 不会为自己写的代码负责，但你会。
5. 保留「从头重建」的能力
最危险的状态是：系统太复杂以至于无法从头重建。定期评估：如果需要，我们能用现有团队在6个月内重建核心系统吗？如果不能，你的系统已经过于脆弱了。
写在最后
软件工程正在经历一场深刻的变革。AI 让我们能以前所未有的速度构建系统，但也正在以前所未有的速度制造我们无法理解的复杂性。
这不是 AI 的错，也不是任何个人的错。这是我们整个行业在追求效率的过程中，不经意间付出的代价。
但我们可以选择现在开始重视这件事。
在你的下一个项目里，试试看：不只是让代码跑起来，而是让团队里的每个人都能理解它为什么跑起来。
因为在软件的世界里，你不能维护你不理解的东西。 而每一个不被理解的系统，最终都会变成一个定时炸弹。
只是没人知道它什么时候会响。
如果你觉得这篇文章有启发，欢迎转发给你身边正在「往上写代码」的朋友们。