登月软件总负责人 一段话 一段人类算力史

10 月初的一条讣闻让全球科技圈重新审视算力史。这位软件总负责人是阿波罗 11 号登月任务里飞行软件的总负责人。她带领的团队写出了人类第一次把宇航员送上月球的代码。最近几年她多次被引用，但这次她走了，留下的不是代码而是一段对现代 AI 的预言。 这位总负责人的核心贡献不是写代码，而是定义了「软件工程」这个职业。在她之前，程序员是「操作员」或「计算机使用者」，没有独立的工程概念；她提出「软件工程」是工程学的一个分支，要按工程方法管理代码、测试、版本。这套方法后来被 NASA、其他政府机构、整个工业界沿用，是现代软件工程的方法论起源。

她的另一个重要贡献是「容错设计」。阿波罗 11 号登月舱在最后阶段出现 1202 程序警报，原因是雷达数据灌进了计算机。这个团队设计的软件在关键时刻「识别问题、清理次要任务、保证主任务继续执行」，让宇航员在 30 万公里之外安全降落。这套「运行时容错」思路，后来被现代分布式系统、AI 系统、操作系统广泛沿用。

把视角拉远到今天，这位总负责人留下的「软件工程」框架正在被 AI 重塑。AI 写代码的兴起让「程序员」的定义在变化：从「写代码的人」变成「管理 AI 写代码的人」。AI 模型在大量工程任务上比人写得快，但「理解问题、定义边界、验证结果」这 3 件事，依然需要人来主导。 对国内的软件工程师来说，这位软件总负责人的工程方法论有几个可以直接借鉴的点：把软件当工程而不是工艺；测试和验证是工程的一部分，不是「最后才做」的事；运行时容错是工程的核心能力，不只是「写正确代码」；团队管理需要清晰的「角色定义」而不是模糊的「互相帮忙」。

对做 AI 工具的创业者来说，这种工程思维有一个直接启示：未来 3 年 AI 写代码的「能力」会进一步提升，但「AI 写的代码如何被验证、如何被集成到生产环境」是新问题。把验证和集成做成产品，比让 AI 写更快更长的代码更值钱。 对普通用户来说，这个故事提醒一件事：技术工具再先进，背后依然是工程师的判断和选择。AI 时代也一样，AI 给出建议、用户做决定；用户不懂判断时，找到一个能「帮你判断」的人比找到一个「能给你答案」的工具更值。 把这些贡献放到今天看，Hamilton 的工程思维依然领先她的时代 50 年。AI 写代码让「写」的门槛下降，但「管理 AI 写的代码」和「让系统在极端情况下不出错」的能力，价值越来越大。 把这位总负责人的工程哲学落到今天，AI 时代最稀缺的不是会写代码的人，是能设计工程方法、能把「AI 写的代码」管理得可靠的人。这条思路对所有工程师都适用。 把这位总负责人的工作方式翻译成今天的工程语言：她要面对的是「系统会出错」而不是「代码能跑」，每一行代码都要预设好错误出现后的处置路径。

创业找资源，上乌鸦部落。