AI来临后，《人月神话》为何更显正确

这两天我去翻了下 Claude 的公开状态页面和 issue 列表，看完后的感觉并不是幸灾乐祸，也不是简单得出“AI 还是不行”的结论。

我脑子里真正浮现出来的，反而是《人月神话》中的那句经典判断，而且放到今天看似乎更贴切了： > There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity. 用更直白的话说就是： 别把银弹当真。 不存在某一种单独的技术，也不存在某一种单独的管理手段，能够在十年之内，自动让软件开发的生产率、可靠性和简洁性同时提升一个数量级。 重点不在于只提升某个方面。 而是在三件事上一起跃升。 这句话厉害的地方恰恰就在这里。 因为在现实中，很多技术都能优化局部，但极少有技术能把整体一并改善。 某个工具让你写代码更快，这并不少见。 某个工具让你做原型更迅速，这也很正常。 某个工具让你检索资料、补齐模板、完成重构初稿更省劲，这当然算进步。 但问题在于： 写得更快，并不代表系统会更稳定。 代码变多，也不代表架构会更简单。 局部效率提升了，也不等于整个工程就更好了。 这正是今天很多关于 AI 的讨论里，最容易被忽略的一层。 一、写代码和做工程，本来就不是同一件事 如今很多人一聊 AI，聊着聊着就默认把两件事混为一谈： 一件是写代码。 另一件是搭建可靠的软件系统。 但二者其实完全不在同一个难度层面上。 写代码，很多时候解决的是“局部实现”问题。 而做工程，面对的却是“整体系统”问题。 系统能不能稳定运行？ 出了故障能不能快速定位？ 依赖挂掉时有没有隔离措施？ 发布出错后能不能及时回滚？ 边界场景有没有提前考虑？ 链路变长后还能不能观测？ 业务变化之后结构还能不能继续支撑？ 这些才是工程真正困难的地方。 它们通常不会出现在 demo 里，不会出现在第一次跑通时，也不会体现在某段代码“看起来写得挺漂亮”上。 它们只会在真实世界里暴露出来。 而真实世界有一个特点： 它永远比你的 prompt 更脏，比你的示例更乱，比你的 happy path 更不讲道理。 所以我一直觉得，一个人如果真的做过线上系统，真的扛过故障，真的被稳定性、可观测性、依赖风险、回滚失败、边界场景反复教育过，就不会轻易把“代码生成能力”当成“工程能力”。 因为你会明白，真正难的从来不是把代码写出来。 真正难的是：让系统长期、稳定、可控地活下去。 二、Claude 的状态，恰好印证了这一点 这次我去看 Claude 的公开状态页和 issue 列表，并不是为了挑毛病，也不是想证明谁不行。 恰恰相反，我认为这些公开信息非常有意义。 因为它们让我们看到一件极其真实的事： 即便是最领先的 AI 公司，也一样绕不过软件工程的基本约束。 模型能力很强，不代表服务天然就稳定。 产品热度很高，不代表系统天然就可靠。 生成效果很惊艳，不代表线上质量就会自动达标。 一家 AI 公司当然可以非常擅长做模型。 但只要它提供的是线上产品，它就同样得面对这些老问题： - 可用性 - 稳定性 - 故障恢复 - 系统集成 - 权限与认证 - 客户端兼容 - 依赖链故障 - 版本发布风险 - 历史包袱 - 运维复杂性 这些问题不会因为“已经到了 AI 时代”就突然消失。 也不会因为“模型更聪明了”就自动被处理掉。 所以当我一边看到有人高谈“AI 将取代软件工程师”，另一边又看到公开服务质量和问题列表持续提醒大家工程现实的时候，我并不觉得这只是单纯的讽刺。 我更觉得，这是一个非常鲜活的提醒： 软件工程最坚硬的部分，从来不是生成代码，而是承担结果。 代码写出来，只是起点。 它如何上线，如何观测，如何恢复，如何维护，如何与其他系统共存，如何在真实用户面前不掉链子，这才是后面更漫长的路。 而这一部分，今天并没有因为 AI 的出现，就突然变得容易。 三、AI 很强，但强不意味着无所不能 说到这里，很多人容易误解，仿佛只要强调这些，就是在反对 AI。 并不是。 我一直都认为，AI 很有价值，而且应该主动去用。 现在谁不用 AI，谁就等于主动放弃杠杆。 它确实能够提升效率。 能帮你起草代码，生成测试，补全文档，解释陌生模块，对比不同方案，快速搭建框架，完成一些过去很费时间的初始工作。 这不是错觉，而是真实存在的价值。 问题不在于 AI 有没有价值。 问题在于：你如何理解它。 如果你把它当成工具，它会是一个好工具。 如果你把它当成银弹，它大概率会反过来伤到你。 因为 AI 本质上更像什么？ 更像一个放大器。 更像一个加速器。 更像一个杠杆。 你原本思路清晰，它会帮你更快推进。 你原本边界明确，它会帮你更快展开。 你原本判断力足够强，它会让你的吞吐更高。 但反过来说，如果你本来抽象就混乱，边界就模糊，约束就没想清楚，架构也不稳定，那 AI 同样会帮你更快地产出一大堆“局部看起来没问题、整体却越来越失控”的东西。 这才是真正危险的地方。 很多人以为 AI 最大的问题是“它会写错”。 其实未必。 它更大的风险可能是： 它会让你沿着错误的方向跑得特别快。 过去你能力有限，写得慢，很多问题还来不及大量堆积。 现在 AI 帮你提速了，你反而更容易在短时间里制造出规模更大、耦合更深、维护更痛苦的复杂性。 所以真正成熟的态度，从来不是“要不要用 AI”，而是： 你有没有能力驾驭 AI 带来的速度。 四、真正该守住的，不是保守，而是工程纪律 我现在越来越确定，AI 时代最重要的一件事，不是学几个 prompt 技巧，也不是比谁更快吐出代码。 更重要的是，不要把那些本来就正确的工程原则丢掉。 比如： 代码来得更快了，评审反而要更仔细。 实现变得更轻松了，边界反而要想得更明白。 方案看起来更多了，判断反而要更克制。 产出节奏加快了，质量标准反而不能降低。 为什么？ 因为速度本身不会自动带来秩序。 很多时候，速度只会更快地放大混乱。 这也正是为什么，我越来越反感一种很轻飘的说法： 仿佛 AI 一出现，软件工程的核心矛盾就已经解决了。 并没有。 软件工程的核心矛盾，依旧还在那里。 需求还是会变化。 约束还是会冲突。 系统还是可能失控。 依赖还是会出问题。 线上还是会出现你预料不到的边界情况。 团队还是得面对维护、交接、治理、演进、回归成本。 这些东西，不会因为你现在可以“一句话生成一段代码”就自动消失。 所以我越来越觉得，《人月神话》里的这句话，在今天反而更值得被一遍遍拿出来重读。 它不是在泼冷水。 它是在帮人保持清醒。 五、我对 AI 的态度，其实很直接 总结一下，我的看法一直都很明确： 第一，要积极使用 AI。 因为它的确是杠杆，的确能带来真实的生产力。 第二，不要神化 AI。 它是强大的工具，不是银弹；是放大器，不是替代品。 第三，关键判断不能外包。 架构边界、异常处理、可靠性设计、上线风险、长期维护责任，这些今天依然要靠工程判断。 第四，质量标准不能因为生成速度提高就下降。 代码来得更快，不代表可以更随意。恰恰相反，越快越需要纪律。 说到底，我并不怀疑 AI 会深刻改变软件开发。 它当然会，而且已经在改变。 但我同样不相信，AI 会让软件工程一下子从困难问题变成简单问题。 因为软件工程里最难的部分，从来都不是“怎么写出这一段代码”，而是： 怎么让一个系统在真实世界里长期、稳定、简单、可控地运行。 这一点，几十年前如此。 今天依然如此。 所以，《人月神话》并没有过时。 恰恰相反，在 AI 时代，它反而显得更正确。 因为直到今天，最值得警惕的，依然不是技术还不够强。 而是人们一看到新技术变强，就又忍不住开始相信： 这一次，银弹真的出现了。