C.6 趣味歷史軼事與其時代啟示#

前幾節的案例都帶有「教訓沉重」的氛圍。本節換換口味，選錄四個廣為流傳的科技軼事：各種意義上都名符其實的「第一隻 Bug」、登月艙那聲讓人捏把冷汗的 1202 警報、ARPANET 的第一次大規模中風、以及讓 Intel 賠上 4.75 億美元的浮點數小誤差。這些故事本身就很好看，但背後都藏著值得帶走的軟體工程道理。

故事一：第一隻「Bug」真的是一隻蟲#

經過：1947 年，Grace Hopper 在哈佛大學操作 Mark II 大型電腦時，系統故障、團隊在數萬個繼電器中搜尋，最後在第 70 號繼電器裡發現一隻被夾死、導致短路停機的蛾子。她用鑷子夾出，貼在系統日誌上，寫下「First actual case of bug being found.」。這本貼著實體蛾子的日誌至今保存在美國國家歷史博物館。

啟示：「Bug」一詞雖早在工程界流行，但這隻蛾子讓我們記住：Debug 的核心是先「觀察現場證據」，再下結論——正如 9.4 節「糾正機制」與 6.3 節「觀測性」強調的：沒有一手證據的猜測是最危險的。

故事二：阿波羅 11 號的 1202 警報#

經過：1969 年，阿波羅 11 號降落月球前 3 分鐘，登月電腦 AGC 連續發出致命等級的 1202/1201 警報，地面幾乎要下令取消任務。原因：登月艙雷達被切到錯誤模式，向電腦灌入巨量無用數據，CPU 負載過載。

解法：軟體團隊負責人 Margaret Hamilton 事先設計了「優先級排程（Priority Scheduling）」架構——當 CPU 滿載時，系統自動拋棄低優先級的雷達運算，強制保留控制登月推進與姿態的最關鍵指令。人類因此踏上了月球。

啟示：這是「容錯與降級（Graceful Degradation）」的教科書範例：好系統不是「不出錯」，而是「出錯時仍保護最重要的功能」（見 9.1 節 Harness、9.3 節驗證、6.4 節自癒）。設計目標永遠是——當資源有限時，優先保護對「任務達成」不可或缺的部分，而不是平均分配。

故事三：ARPANET 的第一次中風#

經過：1980 年 10 月，網際網路前身 ARPANET 發生史上第一次大規模癱瘓，全美數十所大學與研究機構的電腦同時失去回應。罪魁竟是一台 MIT 電腦的記憶體「位元翻轉（Bit Flip）」——它向網路廣播了一條格式錯誤卻帶最高優先級的路由更新訊息。其他電腦試圖清除它，卻因演算法缺陷反而製造更多錯誤訊息，最後形成互相感染的「網路風暴」，數小時內讓整個網路停擺。

啟示：分散式系統中，單點的小硬體故障可以擴散成全域性災難（見 3.3、第 11 章分散式與多 Agent）。現代網路因此建置了路由隔離、loop prevention、及自我修復機制——設計分散式系統時，永遠要問：單一個節點發瘋時，如何不感染整個系統？（見 11.4 節 Agent 網路、3.5 節韌性）

故事四：Intel Pentium 的浮點數小誤差#

經過：1994 年，數學教授 Nicely 用 Pentium 處理器算質數時發現特定除法（FDIV）偶爾出現微小誤差。原因：Intel 在晶片裡用了 SRT 除法演算法，需要在 ROM 中擺一張查表（Lookup Table），而工程師漏填了其中 1061 個輸入點中的 5 個，導致極少數除法結果在小數第 4 位後有誤差。Intel 起初低估公關風險（「一般人幾萬年才遇到一次」），引發眾怒；最後 CEO 公開道歉、無條件換晶片，直接損失約 4.75 億美元。

啟示：一來，查表漏 5 個點證明「徹底測試 + 形式化驗證」在硬體上加倍重要（見 5 章測試、4.1 正確性）；二來，態度決定期限——面對 public bug，第一時間誠實、負責、補償，往往比任何公關話術便宜（見 13 章）。這個案例對所有「bug 發生後的應對之道」都是一堂課：逃避與淡化只會讓代價更大。

想一想#

這四個趣味故事中，哪一個最讓你覺得「軟體工程真的很講究蛛絲馬跡」？（提示：都講究，選一個你最有共鳴的即可）
阿波羅 11 號的經驗說明「出錯時保護最重要功能」。如果你設計一個 AI 客服 Agent，當它上下文爆掉或工具失靈時，你希望它優先「降級保全」哪些行為？
ARPANET 的中風說明了「單點故障會擴散」。在你自己的多 Agent 或分散式系統設計中，哪個「單一環節」最讓你擔心？它「發瘋」時要如何隔離？

本章小結#

這四則軼事提醒我們，軟體工程的趣味與嚴肅其實是一體兩面：每一則「好玩的故事」，都對應著一個不可忽視的工程原則——追證據、留備援、保重點、防擴散（9.4、9.1、6.4、11.4）。把它們放在案例集最後，是想提醒讀者：記住教訓，不一定要被教訓打敗。最好的學習，是從別人的失敗裡早一步長出警覺。