只有短短一句话：“阿波罗11号源代码已在 GitHub 上公开。”
2026年10月中旬，账号 World of Engineering 发出的这条极简推文，突然在科技圈掀起了一场海啸。
GitHub 上的开源仓库 chrislgarry/Apollo-11 再次冲上趋势榜，星标数狂飙突破 7.6 万。
▲ World of Engineering 帖子卡片：阿波罗11号源代码在 GitHub 上公开
为什么一份公开了十年的老代码，今天又让程序员们感慨万千？
就在此前的
2026年9月30日，阿波罗机载软件工程负责人 玛格丽特·汉密尔顿（Margaret Hamilton）走完了她 90 岁的人生。
她在半个多世纪前推动了“软件工程（Software Engineering）”这一概念的发展。
当无数开发者点进仓库向这位老奶奶致敬时，他们不仅看到了一份用针线“缝”进硬件里的传奇，更在几万行汇编代码里，读出了一场 比好莱坞大片还要惊心动魄的月球生死劫。
▲ 麻省理工学院发布的讣告：阿波罗计划软件工程先驱玛格丽特·汉密尔顿逝世，享年90岁
01.4KB 内存的极限操作：代码写完，真要拿针线去“织”
你今天在电脑上随便打开一个浏览器标签页，就要吃掉几百 MB 的内存。
而 1969 年把阿姆斯特朗送上月球的阿波罗制导计算机（AGC），主频只有 2.048 MHz，可读写的随机内存（RAM）只有大约 4 KB，只读存储器（ROM）也不过 72 KB 左右。
整台机器重约 32 公斤，功耗 55 瓦，连块像样的屏幕都没有，宇航员全靠一个叫 DSKY 的数字键盘，像按计算器一样输入“动词（VERB）”和“名词（NOUN）”来跟飞船对话。
▲ 开发者感慨：4KB 内存帮人类登上月球，而今天一个浏览器标签页就要吃掉几百 MB
GitHub 上的这份代码，走过了一段漫长的数字化之路。
这些代码原本是一摞厚得像人一样高的纸质打印清单，锁在麻省理工学院博物馆里。
是 Paul Fjeld 等志愿者在博物馆里 一页一页拍照扫描，再由 Virtual AGC 项目的维护者 Ron Burkey 和开发者 Chris Garry 等人，对着发黄的扫描件一行一行敲进电脑，才让它在 GitHub 上重见天日。
点开这个仓库，里面静静躺着两个主文件夹：指令舱程序 Comanche055 和 登月舱程序 Luminary099。
▲ GitHub 上的 chrislgarry/Apollo-11 仓库，目前已收获超 7.6 万星标
如果你点开 CONTRACT_AND_APPROVALS.agc 这个文件，历史感会瞬间扑面而来。
当年纸质合同审批页被忠实转录下来，上面写着：提交人 Margaret H. Hamilton，日期 1969年3月28日。
而登月舱代码
Luminary099 的最后修订日期，更是让人倒吸一口凉气：1969年7月14日。
此时，距离阿波罗11号点火升空，只剩下不到两天！
在那个年代，写代码是没有“在线热更新”这种后悔药的。
代码定稿后，要交给雷神公司（Raytheon）的女工们，制成 “磁芯绳存储器（Core Rope Memory）”，女工们拿着细长的金属针，带着导线在一排排小磁环里穿针引线。
导线穿过磁芯代表“1”，绕过磁芯代表“0”。
软件，在物理意义上变成了一束被缝进钢铁里的线。
写错一行代码，就要拆掉重织
这群程序员依然在高压下留下了浪漫：登月舱点火例程的文件名，被他们直接命名为 BURN_BABY_BURN--MASTER_IGNITION_ROUTINE.agc（燃烧吧宝贝，主点火例程），灵感来自当时黑人电台 DJ 的著名口头禅。
▲ 登月舱主点火例程的文件名与注释片段
02.1202 警报惊魂：被偷走的 13.36% 算力
这份源码里最封神的部分，藏在 Luminary099/EXECUTIVE.agc 文件的第 133 到 208 行。
时间拨回 1969 年 7 月 20 日，“鹰号”登月舱正在向月球表面急速下降。
突然，警报灯狂闪，屏幕上接连跳出 4 次 1202 警报和 1 次 1201 警报！阿姆斯特朗声音紧绷地呼叫休斯顿：“给我们一个关于 1202 程序警报的读数。”
几十年来，坊间流传的科普都把锅甩给了宇航员巴兹·奥尔德林，说他“错误地打开了交会雷达开关”，导致计算机过载。
但登月舱软件工程师 Don Eyles 在技术论文中追溯了故障根源：交会雷达的预热操作符合飞行程序，硬件接口文档（ICD）却漏了一项要求。
原来，为了防备随时中止降落、逃回轨道，把交会雷达开到预热模式是完全合规的操作。
但在登月舱里，麻省理工负责的制导系统（PGNS）和格鲁曼公司制造的姿态控制组件（ATCA），各自用着一套独立的 800 Hz 交流电源。
当年的硬件文档规定这两路电源必须“频率锁定”，却 偏偏漏掉了“相位同步”！
这就好比两个节拍器，虽然打拍子的速度一样快，但谁先谁后全看通电那一瞬间的运气。
而在阿波罗11号登月那天，宇航员通电的瞬间，两路电源的相位差
好死不死地卡在了最恶劣的 90 度或 270 度附近！
交会雷达瞬间“精神分裂”了
它觉得天线角度一直在剧烈晃动，于是以每秒 12,800 个脉冲 的极限速度，疯狂向计算机发送增减指令。
每来一个脉冲，硬件就会强行暂停 CPU 11.7 微秒。
这场幽灵般的脉冲风暴，生生偷走了登月舱计算机 13.36% 的算力！
算力被偷，为什么会报 1202 和 1201？
打开 EXECUTIVE.agc 源码就能一眼看懂：
你可以把那台 4KB 内存的计算机想象成一个只有 8 张工作台（Core Sets） 的小作坊，其中 5 张工作台配了高级计算器（VAC Areas，向量累加器区域）。
在下降过程中，系统严格每隔 2 秒 就会派发一个叫 SERVICER 的大活儿，负责算推力、算姿态、算导航。
原本算力是够用的
但交会雷达白白偷走了 13.36% 的算力后，奥尔德林又在键盘上敲了 Verb 16 Noun 68，让屏幕实时刷新高度差。
这成了压垮骆驼的最后一根稻草，前一个 2 秒的 SERVICER 还没算完交差，后一个 2 秒的新任务又来了！
短短十几个周期，8 张工作台被积压的半成品任务塞得满满当当。
当第 9 个任务进来找不到空位时，源码第 207 行立刻触发：TC BAILOUT1 -> OCT 1202（无可用核心工作台）！如果是需要高级计算器的任务找不到空位，则在 146 行触发：TC BAILOUT1 -> OCT 1201（无可用向量计算区）！
但汉密尔顿团队与系统架构师 Hal Laning 设计的 异步优先级调度系统，展现出了教科书般的神级自愈能力，触发 BAILOUT 重启瞬间，系统 当场扔掉了奥尔德林那个不重要的屏幕刷新任务，清空了积压的旧任务存根，唯独死死保住了最核心的发动机控制与制导计算！
“死机重启”，竟然在 1969 年被写成了一种自动卸载包袱的救命机制。
直到阿姆斯特朗在 430 英尺高度切入半自动模式 P66，CPU 负载回落，鹰号才终于稳稳落在静海基地。
03.鲜为人知的第二重鬼门关：程序员“少写 0.1 秒”保住了登月机会
躲过 1202 警报后，风险仍未消散
Don Eyles 还披露了另一处险情。
在阿波罗11号成功返航后，工程师检查遥测数据时吓了一跳：在最后着陆阶段，登月舱发动机的推力指令竟然出现了 幅度高达 25% 的剧烈方波震荡，波形像城堡的锯齿女墙一样恐怖！
一查原因，又是 硬件团队改了设计没通知软件团队。
在早期的硬件接口文档里，写着下降发动机的阀门响应延迟是 0.3 秒。
年轻的程序员 Don Eyles 在写节流阀控制代码（THROTTLE_CONTROL_ROUTINES.agc）时，要在代码里写一个提前补偿参数。
他在模拟器里试了试，发现补偿写到 0.2 秒 时推力就已经很稳了。
本着 “像吃药一样，既然两片药能好，就别吃三片” 的朴素直觉，Eyles 违背了文档上的 0.3 秒，在代码里悄悄写了 0.2 秒。
他做梦也没想到，发动机硬件团队后来大幅改进了阀门性能，真机在太空里的延迟只有 0.075 秒，却忘了改文档！这就导致 0.2 秒其实都已经补偿过头了。
事后的数学稳定性分析证明：如果当年 Eyles 乖乖听话，照着文档把参数写成“正确的” 0.3 秒，阿波罗11号在减速阶段就会发生毁灭性的推力发散震荡，发动机会在最大推力和最小推力之间疯狂抽搐，休斯顿控制中心看到 1202 警报加上发动机失控，很可能下令中止登月！
一个程序员在键盘上“保守了 0.1 秒”的工程直觉，在毫不知情中，挽救了人类第一次登月。
04.算力暴涨百万倍的今天，我们弄丢了什么？
今天，当我们重新翻开 chrislgarry/Apollo-11 的源码，看着那一行行工整的汇编指令，很难不产生一种荒诞的时空错位感。
57 年前，先驱们用着 4KB 的内存，面对着
改了延迟却未更新文档的硬件、面对着 800Hz 电源相位差引起的脉冲风暴，硬是靠着对每一个字节的敬畏、对“系统一定会出错”的底线思维，把人类安全送上了 38 万公里外的月球。
这段工程史留下了一条经验：当系统濒临过载时，代码仍要分清哪些任务可以丢弃，哪些计算必须保住。
而今天，我们的内存从 4KB 变成了 64GB，算力暴涨了何止百万倍。
可一些软件塞满了动辄几个 G 的依赖库，却仍会因为一个空指针、一次网络抖动就彻底白屏卡死。
汉密尔顿老奶奶已经远行，但她在 1969 年签下名字的那份代码，依然在 GitHub 上闪烁着幽微却不灭的光。
软件工程诞生之初的智慧，至今仍能从这些指令间照进现实。
