2026年9月30日，那位在阿波罗11号登月最危急时刻拯救了整个人类航天史的女人玛格丽特·汉密尔顿（Margaret Hamilton），在美国马萨诸塞州剑桥市平静离世，享年90岁。
 
登月舱离月面只剩几千米，机舱里的计算机却连续跳出1201和1202报警。对飞行员来说，这不是普通提示，而是必须马上判断的险情。2026年9月30日，阿波罗计划软件工程师玛格丽特·汉密尔顿在马萨诸塞州剑桥市离世，享年90岁。她参与设计的系统，正是在那次登月过程中经受住了考验。
 
时间回到1969年，阿波罗11号开始降落。机载计算机一度承受了超出预期的工作负荷，雷达相关任务带来额外数据，系统发出报警。登月舱还在下降，地面团队必须判断，计算机究竟是彻底失控，还是仍能继续完成关键任务。
 
这时候起作用的，不只是某个程序员写下的一行代码，而是一套事先设计好的处理规则。系统会按照任务轻重安排工作，优先保障飞行控制和导航，把不那么紧急的任务暂时放到一边。换句话说，机器没有因为忙不过来就把所有事情一股脑停掉。
 
这套安排给了地面团队继续降落的信心。飞行控制团队作出继续执行的判断，登月舱最终安全落在月面。把这段经历说成一位工程师单枪匹马救下整场任务，当然过于简单，但汉密尔顿和团队参与构建的软件，确实在关键时刻发挥了作用。
 
当时的计算机并不强大。阿波罗导航计算机的运行内存约4KB，存储程序的只读内存约72KB。如今一张高清图片，体积就可能远超这台机器能使用的内存；可登月导航、姿态控制等任务，都要在有限空间里安排妥当。
 
更难想象的是，部分程序存放在一种叫绳索内存的装置里。工作人员把细铜线穿过磁环，靠穿线方式表示不同信息。程序一旦写入，想修改就没那么轻松，不能像今天这样快速改几行代码、重新运行测试。
 
汉密尔顿的团队面对的，正是这样的硬件条件。他们要把软件写得精简，还得考虑设备出错、任务挤在一起时该怎么办。她曾站在高高一摞程序打印纸旁，那张照片后来成了科技史上的经典画面。照片里的纸堆不只是代码数量的展示，也提醒人们，登月不仅靠火箭和发动机，程序同样要经得住极限考验。
 
当时的软件常被一些工程师看作硬件的附属品，好像机器造好了，再补上几段指令就行。汉密尔顿参与推动的工作改变了这种看法，她和团队把软件当作需要设计、测试、管理的工程对象，也让软件工程逐渐成为一个清晰的领域。
 
这套思路并不意味着软件从此不会出错。1997年，美国火星探路者在火星表面工作时，曾因不同优先级任务之间的调度问题发生系统重启，工程人员后来通过调整软件解决了问题。它和阿波罗11号形成一个很直观的对照，任务优先级能救急，但规则如果没设计周全，同样可能引发故障。
 
1996年，欧洲阿丽亚娜5号火箭首飞失败，事故与惯性导航软件中的数值转换错误有关。两件事说明，软件可以在关键时刻托住任务，也可能因为一个没有处理好的边界情况，把风险带到整套系统里。写代码不只是让机器完成正常流程，更要预想它何时会忙不过来、数据超出范围时会发生什么。
 
汉密尔顿也会亲自参与模拟测试。她曾在模拟登月舱中操作控制面板，观察系统如何回应。她还注意到女儿玩耍时误触设备，进而想到怎样减少误操作带来的影响。这个细节很朴素，却和航天软件的核心要求相通，系统不能只适应理想状态，还得考虑真实的人会怎样使用它。
 
2016年，时任美国总统奥巴马向她颁发总统自由勋章。乐高的NASA女性系列也把她做成积木人偶，旁边放着代表程序纸带的小积木。对许多程序员来说，这个形象有点像桌边的提醒，别只盯着功能能不能跑，还要看看出错时系统能不能稳住。
 
从4KB内存到今天动辄数TB的计算能力，硬件已经天差地别。可软件的难题并没有随之消失，程序越大、连接越多，系统越需要合理安排资源，并为意外留出余地。50多年前，汉密尔顿和团队在极小的空间里做到了这一点。
 
手机应用占用几GB，偶尔还是会卡顿，这和登月计算机当然不是同一种任务环境。但两者放在一起，仍能看出一个朴素道理，硬件强大不等于软件可靠。玛格丽特·汉密尔顿离开了，她参与写下的工程方法，却仍留在今天的软件世界里。