玛格丽特·汉密尔顿——Margaret Hamilton——这个名字在 软件工程与航天软件可靠性 史上出现得太频繁，以至于常被当作背景而非主角。在没有软件工程师这个职业、没有单元测试、没有代码评审的年代，她把登月舱软件写成了能在陌生硬件上安全跑完的形式，而她拿到手的那份合同里写的是「工资按实际投入时间计」。
一、问题一：软件错了怎么办——程序先于硬件、且必须能被机器自己验证
美国缅因州，1936 年。这个坐标决定了 Margaret Hamilton 早年接触到的数学与工程语汇——童年在缅因州海边小镇度过，最喜欢的消遣是收集关于海洋生物的书和标本；十五岁进入布伦瑞克中学，在那里她因数学成绩优异被跳过两个年级；她后来的正式专业训练是数学
Hamilton 的童年与海洋有关。她在自述里提到自己从小想成为海洋生物学家，这种对系统的分类学兴趣后来意外地接上了她对计算机程序分层结构的理解。
她在中学阶段跳级，数学成绩突出，随后进入拉德克利夫学院与宾夕法尼亚大学学习数学。她在宾大取得数学与哲学双学位，这个跨学科组合在此后很多年里都没有被真正用到，直到她开始做阿波罗导航软件的验证工作。
她后来在访谈中说过一句被反复引用的话：她之所以能做好那项工作，一部分原因是「数学训练让我习惯于把问题拆成可以逐个验证的部分」。
她早年做过一段时间的家庭教师，这份工作的性质是独自完成全部判断而没有同事可以商量。她后来形容这段经历训练出的习惯，正是她在阿波罗项目里最需要的能力。
二、1936 年的缅因州，以及一门当时不存在的学科
1960 年前后，Margaret Hamilton 在 麻省理工学院计算技术实验室的 SACCHARIN 项目做的是 参与为新一代计算机编写 BASIC 语言的实现，并参与编写了编译器与解释器。这件事的技术核心是 在这个阶段她学到的核心认知是：程序必须由计算机自己来检查它的正确性，而不是依赖人来读代码；一套好程序要能被分解成可独立验证的小块，而它之所以重要，在于 这套「分层验证」与「优先设计错误检测机制」的思路，直接决定了后来阿波罗导航软件的架构形态，而她自己把那套思路称作「软件工程」这个名称的由来之一。
SACCHARIN 项目是麻省理工学院与 IBM 合作开发的第三代计算机项目，运行的是他们自行设计的编程语言。Hamilton 在这里的工作是编写 BASIC 的实现，并且参与构建了编译与解释工具链。
她在这一时期参与的一项后来广为人知的工作，是编写了运行时错误检测机制。这段经历是理解她后来阿波罗软件设计的关键：她坚持认为，错误检测不应该是事后加上的补丁，而应该是程序结构的一部分。
她后来在麻省理工学院的文档中描述过一种她亲手发明的做法：用「优先级调度」的方式，让最重要的任务永远排在最前面执行，当系统资源紧张时，可以主动放弃次要任务以保证关键任务完成。
她也是最早一批公开谈论「软件与硬件应当分开设计」的工程师之一。这一主张在当时是反主流的——多数人认为软件只是硬件的附属说明。
三、SACCHARIN 与 MIT：把「可验证」写进工程习惯
1963 年前后，Margaret Hamilton 在 麻省理工学院仪表实验室，HAL 飞行计算机项目做的是 为阿波罗制导计算机编写机载软件，重点是导航、优先级调度、密钥表与错误恢复机制。这件事的技术核心是 她把整套软件设计成一个可以自检的优先级系统：最高优先级的任务是确保飞行器在任何状态下都有一条可靠的路径可以执行，较低优先级的任务在资源不足时可以被牺牲，而它之所以重要，在于 这套设计让阿波罗制导计算机在极小的内存与算力条件下，仍然能在出现异常时自动重排任务并继续运行，而这正是后来着陆前计算机多次报警却未酿成事故的技术基础。
她接手任务的方式很朴素：被叫去见负责人，对方给了她一份合同，合同上写的是按她实际投入的工作时长计酬。合同签署后她被要求全职投入，而这实际上是她第一次担任软件工作的正式职位。
阿波罗制导计算机的硬件条件极其紧张，内存以当时的度量单位计只有几千字，无法容纳现代意义上的操作系统。她必须在这样的资源限制下设计出具备任务分派与优先级保证的调度结构。
她在软件中内置了一张「密钥表」，用于处理航天器可能收到的意外指令；她同时设计了一套错误检测机制，使计算机在遇到无法解释的状态时能够自动转入预先定义的恢复路径，而不是停机。
在阿波罗 8 号任务的飞行过程中，导航计算机连续报出程序警报。按 Hamilton 后来设计的逻辑，优先级最低的任务在系统过载时被主动放弃，警报因此停止，报出的数字是并不需要执行的、与导航无关的计算。这一设计细节后来被反复引用为软件工程史上的经典案例。
她也在这个时期开始意识到自己作为女性工程师所处的环境——在以男性为主的工程团队里被默认当作辅助角色，需要自己争取技术判断上的话语权。
四、1963 年接到的那份合同：优先级调度与阿波罗导航软件
1970 年前后，学界的主流判断仍偏保守。她试图推动的「软件工程是一门独立学科」的判断长期得不到学界与工业界的正式认可，软件在多数机构里仍被视为硬件的附属物，但 Margaret Hamilton 选择 她在阿波罗项目上亲眼看到，一段逻辑正确但不具备错误恢复能力的软件，在真实系统里是危险的——因此软件必须像硬件一样被独立设计、独立验证、独立负责，代价是 她在申请把「软件工程」确立为正式学科名称时遭遇阻力，最终该名称是在一次公开会议上由别人提出并很快被广泛接受的，而她自己没能得到与之相称的学术位置与经费。
1970 年，她在麻省理工学院的一次会议上公开提出，应当把「软件工程」确立为一个独立学科，并给出这个词的定义。这个词在几年内被行业广泛接受，但学界始终没有为它设立独立的院系与研究序列。
她离开麻省理工学院后自己创办了一家名为 Higher Order Software 的公司，业务是为波音这样的航空客户提供嵌入式软件。她的团队参与了波音 747 的控制软件的一部分。
她在公司里负责的是最难的那部分：客户需求经常互相矛盾且表述含糊，而这类软件一旦出错就是灾难性的。她把这一点当作公司存在的理由——专门承接那些别人不敢接的高风险项目。
她曾公开表示自己被付的报酬远低于同岗位的男性同事，并指出她的资历与经验在业内并不被看重。这段经历成为后来讨论科技行业性别与资历评价机制时被反复引用的案例。
她也长期担任计算机科学历史与博物馆项目的志愿者，组织修复并保存早期计算机设备，包括重建阿波罗制导计算机的部分软件档案。
五、问题二：一门没有名字的学科该由谁来命名——1970 年之后：术语、一所独立公司，以及被系统低估的十年
2016 年，Margaret Hamilton 进入 白宫。这一步不是履历跳跃，而是问题换轨：在 麻省理工学院仪器实验室与 Higher Order Software 公司 里 Margaret Hamilton 关心的是 如何在一个男性主导、且不把软件当作独立学科的工程环境里，把一套技术主张坚持到底，到了 白宫，问题变成 如何让阿波罗软件工程的贡献被国家级荣誉正式承认，从而进入公共记忆。
2016 年 12 月，白宫向她颁发杰出贡献勋章，专门表彰她为阿波罗软件所做出的贡献。她由此成为首位获得这一荣誉的女性。
勋章颁发本身的意义在于它打破了一种长期存在的叙事惯性：在大众印象里，阿波罗登月被记为一群男性工程师与宇航员的成就，地面软件支持团队的存在感极低。
在登月五十周年前后，她的口述历史访谈被完整公开，其中包含大量关于团队协作细节、软件调试过程和当时工作氛围的一手记录。
她对后来者给出的建议是朴素而具体的：把想做的事情做到足够扎实，让别人无法忽视；同时不要把等待别人认可当成工作的一部分。
她强调自己对阿波罗项目的归属感来自「把它当作一件必须做好的具体事」，而不是对荣誉的期待——这一态度与她早期在男性主导的工程团队中的处境形成明显对照。
六、她提出的那个概念：让软件本身承担可靠性
美国联邦政府杰出贡献勋章（2016）之后，Margaret Hamilton 的工作重心转向 把早年手写代码从档案中抢救出来并重新实现为可运行系统，同时推动计算机科学史的公共教育。这条线的意义在于 让「阿波罗是谁做的」这个问题不再只有一个模糊答案，而成为可以查证的工程史。
她留下的最具延续性的贡献，是把「错误检测与恢复」确立为软件设计的基本组成，而不是附加环节。这一原则在今天的航空软件、医疗器械软件与任何失效代价极高的系统中仍然是强制要求。
她关于「软件与硬件应当被分别对待」的主张，在今天看来几乎是常识，但在 1960 年代是明确的反主流观点。当时多数硬件公司不做软件工程，不为软件编写测试，也没有软件这一职业类别。
她提出的「软件工程师」身份定位，本质上是在主张软件有它自己的工程规范：需求、可验证性、失效模式与责任边界，都应当像硬件那样被严肃对待。
她晚年推动修复与重建早期计算机与保存其软件档案的工作，被认为具有无可替代的史料价值——大量早期软件因为缺乏保存意识而永久失传，她的抢救让其中一部分得以被后人读取和运行。
她反复讲过自己坚持「把最难的问题接下来」这一工作方式：在阿波罗项目里是别人不愿碰的错误恢复，在公司里是别人不敢接的高风险项目。这种选择本身构成了一种对行业环境的回应。
