AI 让实现变便宜，但判断依然昂贵：火箭工程的启示

一篇在技术社区广泛讨论的工程师随笔提出一个反直觉观点：常被引用的「AI 让软件变便宜」这一说法，在大多数关键环节上并不成立。AI 真正压低成本的只是「实现」这一步——把一个决策转译成可工作的代码。而围绕实现的一切：定义系统该做什么、设计组件如何衔接、划定安全边界、判断产出是否真的可用，仍在按原来的价格收费。

实现变便宜，判断没变

文章认为，智能体已经可以快速写出实现、反复改写、生成多个备选方案再全部推翻，成本都不高。但品味、判断力和经验，仍按原价出售。

更棘手的是产出与评估之间的速度差：智能体生成代码的速度远快于人类真正审阅的速度。大部分产物看似合理却平庸；有些暗中出错；有些解决了局部问题，却悄悄破坏了整体系统。偶尔也会冒出一段比人类自己写得更漂亮的实现——前提是人们停止把每一个生成物都当成等待终审的成品。

火箭的两种范式

作者把目光投向一个意想不到的领域：火箭发动机。他援引纪录片《Cosmodrome》，对比了美苏两套工程组织建立信任的方式。

• 阿波罗式：把钱和工业实力砸进「飞行前的确定性」。建模、评审、文档、零部件鉴定、静态点火、集成测试、任务演练——几乎所有资源都用来确保飞行时尽可能不出错。土星五号每一级都经过地面静试后才运到肯尼迪航天中心，Apollo 4 才首次进行完整的「全弹」飞行试验。
• 发动机车间式：资源有限，靠的是与硬件的直接接触。建造、点火、检查、修改、再点火。少模拟，多试车；没人去「读」焊缝，而是去「压」焊缝。N1 的 NK-15 发动机在室压和比冲上都明显优于土星五号的 F-1。

苏联方案的边界

苏联工程师造出了出色的零部件，却没有为整个系统提供廉价的失败路径。N1 一级捆绑了 30 台 NK-15，组合复杂度极高，但整套 Block A 从未在地面进行过静态点火。四次发射全部失败，登月计划随之终结。契尔托克（Boris Chertok）在《Rockets and People》中形容每次发射都是「不带扫雷器走进雷场」——单台发动机的可靠性，无法推导出整个一级捆绑系统的可靠性。

对软件工程的启示

文章强调，两种路径的对照并不是评判谁更鲁莽。关键差别在于：阿波罗把资源转化为飞行前信心；发动机车间把反复接触硬件转化为知识。阿波罗能负担一个让失败变得不太可能发生的制度；发动机车间则让失败变得频繁、便宜且有信息量。

文章据此类比当下的 AI 编程：更好的模型会提高「信号 / 垃圾」的比例，但同时也会让代码总产量暴涨。把 AI 输出塞进为单件精心打造而设计的评审流程，相当于「在阿波罗的流程上装一门 slop 大炮」，再指望人类跟上节奏。工程师应当借鉴发动机车间的态度——生成、点火、炸掉、丢弃、再来一次——并以更严格的契约来约束每一次试车。在下一篇中，作者将进一步讨论这一思路如何落地为具体的工程实践。