Margaret Hamilton 如何把 Apollo 軟體變成可容錯系統？優先排程、非同步任務與軟體工程

增量補充：容錯系統先決定什麼不能失控

NASA 的資料把 Margaret Hamilton 定位為領導 Apollo 飛行軟體團隊的工程師，並記錄 Apollo 11 降落時警報與軟體處理的脈絡。這支持本文把她的工作理解為優先排程、非同步任務與異常處理的整體設計，而不是事後補一個警報畫面。來源：NASA — Margaret Hamilton。

高可靠系統的第一個問題不是「所有事情都能不能完成」，而是資源不足或輸入異常時，哪個任務必須保留、哪個可以延後、如何讓操作員知道狀態。把優先級、降級路徑與測試情境寫清楚，軟體才會在壓力下維持安全邊界。

人物定位與讀者問題

談 Margaret Hamilton，最容易被一張站在程式清單旁的照片取代全部技術。更值得追問的是：當一台導航電腦必須同時接收飛行員操作、雷達資料與控制程式，而記憶體和處理時間都極其有限時，軟體如何判斷什麼一定要先做、什麼可以延後、什麼錯誤不能讓整個任務停止？Hamilton 的重要性不只在她參與了登月，而在她把這個問題變成可設計、可測試、可交接的工程工作。

她在 MIT Instrumentation Laboratory 的 Software Engineering Division 領導 Apollo 機載飛行軟體團隊。NASA 的人物資料與 MIT 的回顧都把她放在一個龐大合作網絡中：導航與控制系統由實驗室承接，硬體、軟體、測試、任務操作與太空人訓練必須互相對齊。把她寫成孤立的天才會遮蔽真正困難的地方，也就是如何讓不同專業在同一套優先順序、介面和故障假設下共同工作。

本文的主線是可靠性，而不是把 Apollo 神話重新包裝。Hamilton 的團隊處理非同步軟體、優先排程、優先顯示、端到端測試，以及讓人能在關鍵時刻參與判斷的介面。這些名詞不是抽象口號，每一個都對應一條可以追蹤的控制流：事件從感測器或操作輸入進來，系統依重要性分配時間，執行結果再回到顯示與控制。讀者可以用這條路線理解她如何影響今日的即時軟體工程。

關鍵技術與作品如何運作

Apollo 導航電腦的工作不是一次算完一張表，而是在反覆到來的任務中維持狀態。導航、姿態控制、引擎指令和顯示更新各自有時間要求；有些工作必須在下一個控制週期以前完成，有些則可在背景處理。若所有工作都以同一優先級排隊，突發輸入便可能阻塞真正關鍵的控制。優先排程先把任務分成重要性和時限，再讓執行器在資源吃緊時保住最不能失敗的路徑。

非同步軟體的核心，是事件不必按照人類看到的順序逐一完成。雷達、按鍵或內部計時器產生事件後，排程器把它們放入可管理的工作集合；較高優先級工作可以暫停較低優先級工作，等危機解除再恢復。這種設計要求每個任務說明自己的輸入、輸出、可接受延遲和中斷後狀態，否則搶占只會把一個隱藏的共享變數問題變成更難重現的錯誤。

Apollo 11 著陸前出現的 1202 警報，正好讓優先排程的意義被看見。NASA 的歷史說明指出，因為一個雷達開關被手動開啟，電腦面臨額外負荷；軟體沒有把所有工作一起丟棄，而是重新分配處理優先級，讓必要的導航工作繼續。這個故事不是「程式自動拯救任務」的魔法，而是事先定義好過載行為、警報顯示和可恢復路徑後，系統在真實輸入下依契約行動。

優先顯示把內部排程翻譯成人可以採取的行動。顯示器若只亮起一個無法解釋的錯誤碼，太空人和地面控制中心就不能判斷是否等待、重試或改變操作；若顯示包含警報等級、受影響任務和目前可用能力，人便能在迴路中做出有根據的選擇。人機協作因此不是把責任推回人，而是把系統狀態與決策界線做成可讀介面。

端到端測試則把需求一路追到實際輸出。測試不只檢查一個函式算得對不對，還要讓模擬感測器、排程器、顯示、控制輸出和故障注入共同運作，確認事件從入口到結果的整條鏈沒有破壞時序。對即時系統而言，數值正確但晚了幾秒仍可能是失敗；所以測試資料要同時記錄輸入、時間、優先級、重啟行為和操作者看見的訊息。

容錯設計還包含重新啟動和降級。當非關鍵工作耗盡資源，系統可以捨棄它們、保留核心控制，並以一致的方式重建必要狀態。要做到這件事，程式必須區分可重算的暫存資料與不可遺失的任務狀態，為每個共享資源定義恢復順序。這種分層讓故障不會沿著一個小模組擴散到整個任務，也為事後稽核留下可解釋的狀態轉移。

原始資料、測試與專案脈絡

NASA 的 Apollo 11 Lunar Surface Journal 收錄一份 2003 年的表彰資料，明確指出 Hamilton 領導了 Apollo 任務飛行軟體團隊，並把非同步軟體、優先排程、端到端測試和人機決策列為技術貢獻。這份資料也描述著陸前的警報事件。閱讀時應把它視為官方事後說明：它能支持貢獻與事件的範圍，但不等於完整的原始碼、每個任務週期或所有團隊成員的工作紀錄。

MIT 對她的回顧補上組織與時間線。1961 年 MIT Instrumentation Laboratory 承接 NASA 的 Apollo 導航系統工作，Hamilton 後來領導 Software Engineering Division；同一篇報導也說明她先在 Lincoln Laboratory 參與 SAGE，再投入 Apollo，之後還諮詢太空梭和 Skylab。這些背景讓人看見軟體工程並非在登月那一刻突然誕生，而是從早期數位系統、任務規格和持續測試逐步累積。

那張著名的程式清單照片也需要精確閱讀。NASA Science 的人物頁轉載 MIT News 的說明，照片是實驗室為 Apollo 工作所拍，清單代表 Hamilton 所帶領團隊負責的月球艙與指揮艙機載軟體。照片能說明程式規模與團隊身份，卻不能單獨證明某一行程式由誰寫成，也不能取代版本控制、測試紀錄或任務遙測。原始證據的用途要和它的解析度相稱。

從專案管理角度看，Apollo 軟體的難題是跨邊界協作。硬體限制決定記憶體和計算週期，任務規格決定導航精度與反應時限，地面操作決定警報如何被理解，測試團隊則要把正常與異常情境都重現。Hamilton 的方法把這些約束寫進設計和測試，而不是在任務前靠口頭提醒補洞。這正是軟體工程一詞在早期航太專案裡的實質含義。

現代開發與今日影響

即時作業系統今天仍以優先級、截止時間和可恢復狀態管理工作。醫療設備、飛行控制、工業機器人和車載系統不能只追求平均延遲，還必須回答最壞情況下哪一條控制路徑仍能運作。Hamilton 的經驗提供一種檢查表：列出每個任務的時限與故障後行為，測量排程器在負載尖峰的抖動，再確認被降級的功能不會意外取得核心資源。

雲端服務雖然不在太空船上，仍可借用同一種優先思維。當佇列暴增或依賴服務失效時，系統可以把付款、身份驗證等關鍵工作與通知、報表等可延後工作分開，採用逾時、熔斷和有限重試。這不是把網路服務硬套成 Apollo，而是把「有限資源下保住最重要能力」轉成可觀察的服務等級目標，並為降級頁面和恢復步驟準備測試。

端到端測試也從航太延伸到持續整合。單元測試能抓住函式邏輯，整合測試能確認模組介面，但只有把真實事件、排程、資料儲存和使用者介面串起來，才能發現時間順序、重試或部署設定造成的錯誤。測試報告應保留輸入版本、時間戳、排程決策和輸出狀態；否則紅燈只告訴團隊失敗，不能告訴下一位工程師如何重現與修復。

人機迴路的設計同樣適用於人工智慧與自動化運維。自動化可以快速分類警報，但遇到高影響操作時，介面必須呈現依據、信心、可撤銷範圍和目前被保留的資源，讓人知道何時介入。若系統只顯示一個總分，操作者便無法判斷是資料異常、模型錯誤還是排程延遲。Hamilton 所重視的可理解警報，提醒今日開發者把決策證據當成產品功能。

可靠性還需要把版本與責任連起來。任何排程規則或故障處理變更，都應有需求連結、程式差異、模擬輸入與回歸結果；若只更新二進位檔而沒有可追溯來源，事故後便無法知道哪個假設被改變。對現代團隊而言，這可落實為可重現建置、不可變測試資料、明確的變更審查和可讀的運行手冊，而不是把可靠性留給最後一次手動演練。

爭議、限制與常見誤讀

第一個常見誤讀是把 Apollo 的成功歸功於 Hamilton 一人。NASA 與 MIT 的資料都使用團隊語言，指出她領導或帶領軟體部門，而不是宣稱她獨自寫完全部程式。導航演算法、硬體、測試、地面支援和任務決策有不同責任鏈；正確的致敬方式是說明她在軟體工程組織、可靠性概念與關鍵設計中的角色，再保留同事和合作機構的貢獻。

第二個誤讀是把 1202 警報說成一個錯誤被忽略後奇蹟般消失。官方文字描述的是在額外雷達輸入造成負荷時，軟體覆寫了切換優先處理的命令，讓任務得以繼續；這個敘述不能推導出所有 Apollo 警報都能自動恢復，也不能證明每次超載都安全。工程師要問的是警報條件、保留的任務、被捨棄的工作和人員決策，而不是只記一個戲劇化數字。

第三個誤讀是說 Hamilton 發明了軟體工程這個領域。MIT News 說她被認為普及了 software engineering 的概念，NASA 2003 年的表彰則把她與團隊的做法稱為現代可靠軟體設計的基礎。這些是重要的歷史評價，但不等於一個人單獨創造了所有方法。需求工程、測試理論、作業系統排程和人因研究都有更廣的脈絡，應以來源的限定語描述，而不能把榮譽稱號寫成無條件的優先權。

第四個誤讀是把有限資源和今日硬體環境混為一談。Apollo 導航電腦的記憶體與運算能力遠低於現代手機，今日服務也多面對網路、容器和分散式故障；兩者的具體解法不能直接互換。可移植的是推理方式：先定義不可失敗的功能，量化時間與資源，設計降級與復原，再用端到端證據驗證。若只複製術語而沒有測量，可靠性就會變成口號。

還要注意事後敘事的限制。照片、表彰稿和回顧文章容易把長年迭代壓縮成幾個漂亮片段，讀者卻看不到被淘汰的設計、失敗測試和反覆協調。研究型文章應把官方資料中的明確事實、依工程常識做出的推論和仍待查證的細節分開標記。這種證據分層不會削弱 Hamilton 的成就，反而讓讀者理解可靠系統是如何在許多看不見的檢查中成形。

最後，不能把可容錯誤讀成不必修復錯誤。優先排程和降級的目標是讓任務在可接受範圍內繼續，並留下警報與狀態供後續處理；它們不會消除根因，也不會替代維修與版本更新。現代系統若只依賴重試和自動恢復，卻沒有事故後分析、故障注入和容量規畫，便是在把風險延後。Hamilton 的遺產更接近一套面對失敗的紀律，而不是一個永遠不會失敗的保證。

延伸閱讀

若想把 Apollo 軟體的可靠性放進更廣的程式設計與演算法傳統，可以接著閱讀Donald Knuth：TAOCP、演算法分析、TeX與Literate Programming，對照正確性、效率與可讀性的工程取捨。

官方資料與延伸查證

• https://science.nasa.gov/people/margaret-hamilton/
• https://www.nasa.gov/wp-content/uploads/static/history/alsj/a11/a11Hamilton.html
• https://news.mit.edu/2016/apollo-code-developer-margaret-hamilton-receives-presidential-medal-of-freedom-1117

把 1202 警報拆成四個工程問題

Apollo 11 著陸前的 1202 警報之所以值得保留，不是因為它適合被剪成「電腦差點當機」的戲劇片段，而是它把可靠軟體的四個問題同時放到真實任務裡。第一，系統當時收到什麼額外輸入；第二，哪些工作正在競爭有限的處理資源；第三，排程器如何分辨核心導航和可以延後的工作；第四，警報如何讓太空人與地面控制知道下一步。NASA 的 Apollo 11 Lunar Surface Journal 可以支持事件與技術概念，但不應把一段事後說明擴張成完整原始碼註解。

問題	可靠性設計要回答的內容	今日工程對應
輸入從哪裡來	感測器、開關與操作指令的來源、頻率及可信度	事件驗證、輸入去抖與遙測紀錄
誰先執行	任務優先級、截止時間與可接受延遲	即時排程、佇列優先級與資源配額
超載怎麼辦	保留核心控制、暫停或捨棄低優先級工作	降級模式、熔斷、背壓與有限重試
人如何判斷	警報等級、影響範圍與可採取行動	可解釋告警、操作手冊與人機迴路

這四個問題也說明「容錯」和「不會出錯」是兩回事。系統可以在特定故障下保留最重要功能，但仍然需要記錄錯誤、通知人員、修復根因並重新驗證。若只看到它成功繼續運作，就把所有被延後的工作和後續維護忘掉，便會把一次有條件的降級策略誤寫成永遠安全的保證。

優先排程的重點不是數字，而是責任邊界

把任務標成高優先級並不會自動產生可靠性。每一個高優先級工作都必須說明它保護什麼、需要哪些共享資源、最多能執行多久，以及被中斷後如何恢復。否則所有模組都會聲稱自己重要，排程器只是在不同競爭者之間做出沒有依據的選擇。Hamilton 所處理的價值，在於把任務責任、時限與故障後行為放進設計和測試，而不是在事故發生時臨時猜測。

對今日開發團隊而言，可以把這個方法轉成一張簡單的設計表：每項任務的輸入、輸出、截止時間、可重試次數、可捨棄資料、重啟後狀態與人工接管條件。表格不是文件裝飾，它應該能被測試程式讀取，讓壓力測試知道什麼情況算超載，也讓值班人員知道看到哪個警報時不能繼續重試。從這個角度看，優先排程是一種跨團隊協議，不只是作業系統 API。

非同步也需要同樣的邊界。事件可以不按抵達順序完成，但每個事件要有唯一識別、時間戳與狀態轉移；共享資料要有一致的讀寫規則；中斷後不能留下半完成的副作用。Apollo 的硬體條件和今日雲端不同，然而「把時序與恢復寫清楚」仍是共通的工程要求。若只引用非同步、優先級等名詞，卻沒有說明事件如何重播或失敗如何收斂，文章就只剩術語表。

從 Apollo 軟體看團隊工程，而非單人神話

NASA 與 MIT 的資料都把 Hamilton 放在團隊和部門脈絡中：她領導 MIT Instrumentation Laboratory 的 Software Engineering Division，與工程師、硬體團隊、測試人員、任務控制和太空人訓練共同完成系統。這種寫法不會削弱她的角色，反而更準確地說明領導的技術內容：建立共同術語、分配責任、讓測試可以重現，以及在壓力下讓不同專業使用同一套優先順序。

那張站在程式清單旁的照片也應該這樣閱讀。NASA人物頁與MIT回顧說明它呈現的是 Hamilton 所帶領團隊負責的月球艙與指揮艙機載軟體；照片是團隊規模與歷史脈絡的證據，不是逐行作者名冊。對讀者而言，最有價值的問題不是「這一行是不是她寫的」，而是這麼大的軟體如何被拆成可測試的任務、如何在版本更新時保持介面一致，以及如何讓下一個工程師能接手。

軟體工程的社會面也不能被抹去。早期航太計畫受硬體、時程、預算、任務規格與安全要求共同限制，任何優先級決定都會影響其他團隊。可靠性不是一個英雄在深夜想出來的技巧，而是需求、設計、模擬、審查與操作訓練互相校正的結果。把這個協作過程寫進人物文章，讀者才會理解為什麼 Hamilton 的影響延伸到今日工程管理。

現代系統如何借用這套推理，而不是照抄 Apollo

在醫療設備、機器人、車載控制或金融服務裡，第一步都是列出不能失敗的能力。第二步是測量正常與尖峰負載下的時間、記憶體、佇列和外部依賴。第三步設計降級：哪些功能可以暫停、哪些資料可以延後、哪些操作一定要交給人。最後用故障注入和端到端測試驗證，確認警報真的能被理解，恢復後的狀態也不會重複扣款、重複下令或遺失關鍵紀錄。

AI 系統尤其需要這種分層。模型可以替使用者分類請求，但高影響操作仍需呈現資料來源、信心、可撤銷範圍與目前被保留的資源。若模型延遲、工具回傳錯誤或上下文不完整，系統應能退回安全的人工流程，而不是讓自動化一路重試。這不是把 Apollo 航太軟體與生成式 AI 混為一談，而是借用同一個問題：資源不足時，什麼能力必須保住，誰有權做最後決定。

可靠性還需要可追溯性。每次排程規則、警報門檻或復原策略變更，都應連到需求、程式差異、測試輸入與回歸結果。部署之後要保留時間戳、版本、優先級決策和操作者看見的訊息。這些紀錄讓團隊能回答「當時系統知道什麼」和「為什麼選擇這條路」，也避免把事故事後簡化成某個人的粗心。

讀者查證 Hamilton 故事時的資料邊界

NASA Apollo 11 Lunar Surface Journal 的 2003 年表彰資料適合確認 NASA 對 Hamilton 及其團隊的技術描述，包括非同步軟體、優先排程、端到端測試和人機決策；NASA Science 人物頁與 MIT News 適合補充她在 MIT Instrumentation Laboratory 的職務、程式照片與歷史脈絡。三類資料用途不同，不能用一張照片證明整個軟體架構，也不能用一段榮譽文字代替所有原始測試紀錄。

文章中「能推導出的工程意義」也要和「來源直接說的事實」分開。例如，從優先排程可以合理分析現代系統的降級設計；但不能因此聲稱 Hamilton 直接設計了今日所有熔斷器、容器編排或 AI 安全模式。保留這條界線，讀者會更清楚哪些是歷史紀錄，哪些是編輯把經驗轉成今日可用的思考工具。

常見問題

Margaret Hamilton 的 Apollo 貢獻是什麼？

NASA資料把她描述為 Apollo 飛行軟體團隊的領導者，並指出非同步軟體、優先排程、端到端測試與人機決策等概念對可靠軟體設計的重要性。這些成果屬於她所領導的團隊與合作網絡，不能寫成單人完成全部程式。

1202 警報代表 Apollo 電腦故障了嗎？

它代表系統面臨額外負荷與警報條件，不應簡化成「整台電腦壞掉」。NASA的說明指出，軟體依優先處理方式讓必要的導航工作繼續；這是有條件的容錯與降級，不是所有超載都能安全自動恢復。

為什麼 NASA 和 MIT 都強調優先排程？

因為有限資源下不可能同時完成所有工作。優先級讓系統先保住有時限、不可失敗的控制路徑，再處理可以延後或捨棄的工作；前提是優先級、共享資源和恢復行為已被明確設計與測試。

Margaret Hamilton 是不是唯一的 Apollo 軟體作者？

不是。她領導 Software Engineering Division，Apollo飛行軟體由大型團隊與多個合作機構共同完成。人物文章應同時呈現她的領導與技術影響，以及硬體、測試、任務控制和其他工程師的角色。

官方資料與圖片來源

NASA Apollo 11 Lunar Surface Journal：Program Alarms補充 1201／1202 警報的任務背景，並說明電腦在超載時先恢復下降引擎與 DSKY 等重要工作，未把當時錯誤排程的雷達工作全部重新啟動。這個頁面用來支撐本文對「超載不等於整台電腦失效」的限定說明；它不等於完整原始碼或單一工程師的作者名冊。

本次內容增量依據 NASA Science Margaret Hamilton 人物頁、NASA Apollo 11 Lunar Surface Journal 表彰資料與 MIT News 回顧整理。圖片採用 NASA Science 人物頁的原始圖片，保留官方頁面與圖片 URL；官方來源歸屬不等於可自由轉授權，本文不主張超出原平台的使用權利。1202警報、程式照片與 Hamilton 的團隊角色仍應依原始資料的限定語理解，不把歷史回顧擴張成未公開的原始碼或個人作者清單。

__MARGARET_HAMILTON_APOLLO_76669_SOURCE_IMAGE_RECONCILE_20260816__

增量分析：Apollo 軟體的可靠性，來自把異常情境當成設計的一部分

Margaret Hamilton 與 Apollo 飛行軟體的歷史，讓人看見高風險系統不能只為正常流程寫程式。任務需要處理工作負載突增、資源衝突、非同步事件與操作人員介入；優先排程、監測和可恢復行為，讓系統在壓力下仍能保留最重要的任務。

這段歷史不應只被包裝成「某人發明軟體工程」。軟體工程作為方法，還包含團隊審查、測試、規格、硬體介面和任務操作；Hamilton 的貢獻是把這些要求在極端環境中做成可執行的工程實踐。評估容錯設計時，要問哪些故障被預期、如何降級、誰能介入，以及恢復後如何驗證狀態。