C.7 案例集目錄與教學指引#
前面六節收錄了本書附錄 C 的全部案例。本節為讀者（與授課老師）提供兩樣工具：一、一份「案例 ─ 章節」對照地圖，方便在讀正文時回頭查閱對應案例；二、一份教學與研讀指引，說明每個案例最適合放在課程中的哪個時機使用。
案例總表與正文章節對照#
| 附錄節 | 案例 | 最相關正文章節 | 一句話核心教訓 |
|---|---|---|---|
| C.1 | Dropbox 影片 MVP | 2.2、2.6 | 用「真實行為」而非問卷驗證需求 |
| C.1 | Nokia 田野調查 | 2.1、2.5 | 功能價值由使用情境決定 |
| C.1 | 微信 vs QQ 內部賽馬 | 12.1、1.3 | 自己顛覆自己，別等別人顛覆 |
| C.1 | Slack 轉向 | 2.2、2.6 | 真實需求常藏在不預期的角落 |
| C.2 | 創新者的兩難（硬碟/鋼鐵/挖掘機/柯達） | 1.1、14.4 | 做對所有事仍可能被顛覆 |
| C.2 | Free Culture 法律障礙 | 13.3、13.4 | 舊法律生態可以卡死新技術 |
| C.3 | Ariane 5 火箭 | 2.4、4.1 | 重用程式碼必須重新驗證邊界 |
| C.3 | Therac-25 | 3.3、9.2 | 競態條件 + 卸責硬體 = 災難 |
| C.3 | 火星氣候軌道器 | 3.5、4.1 | 介面契約要明確定義型別/單位 |
| C.3 | 車諾比 | 9.2、13.2 | 故障安全要「壞掉時趨向安全」 |
| C.4 | Netscape 重寫 | 4.2、4.4 | 不要從零重寫，要漸進重構 |
| C.4 | Y2K 千禧蟲 | 12.1、6.1 | 技術債終將連本帶利結算 |
| C.4 | Git 誕生 | A.1、12.3 | 工具限制是協作上限 |
| C.4 | Netflix 混沌工程 | 6.1、6.4、9.3 | 為失敗而設計，主動演練故障 |
| C.5 | Healthcare.gov | 12.1、5.3、6.1 | 太晚整合注定失敗 |
| C.5 | Knight Capital | 6.2、4.2 | 部署一致性 = 公司存亡 |
| C.5 | left-pad | 6.1、13.2 | 依賴鏈是整個供應鏈的信任邊界 |
| C.5 | 500 哩 Email | 6.3、9.4 | 玄學報告背後常藏著硬核物理 |
| C.6 | 第一隻 Bug | 9.4、6.3 | 偵錯要先取得一手證據 |
| C.6 | 阿波羅 11 號 1202 | 9.1、9.3、6.4 | 出錯時保護最重要功能 |
| C.6 | ARPANET 中風 | 11.4、3.3 | 單點故障要能隔離不擴散 |
| C.6 | Intel FDIV | 5.1、13 | 徹底測試 + 誠實應對錯誤 |
教學指引：每個案例建議的授課時機#
第 2 章（需求分析）課堂使用 C.1 全部案例：Dropbox 講「行為驗證 vs 問卷」，Nokia 講「情境決定價值」，微信/QQ 講「產品定位與組織」，Slack 講「意外發現需求」。可用小組討論帶出「如果今天用 AI 做同樣事會怎麼做」。
第 4 章（程式設計/重構）使用 Netscape、Y2K、Knight Capital：分別說明「為什麼不要重寫」、「技術債如何累積」、「為什麼要清死碼」。適合搭配一次「把一段舊程式交給 AI 重構並審查差異」的實作練習。
第 9 章（Harness 工程）使用阿波羅 11 號、車諾比、Therac-25：三個案例分別示範 Harness 五要素裡的「保重點 / 約束 / 驗證」。可以引導學生回頭檢視：一個好的 Harness 如何避免 Therac-25 那類的「自動做錯」。
第 6 章（DevOps）使用 Netflix、Healthcare.gov、left-pad、500 哩 Email：涵蓋 CI/CD、部署一致性、依賴治理與觀測性的完整教學素材。
第 13 章（安全與倫理）使用 Free Culture、Intel FDIV、left-pad：分別處理「法律生態」「危機應對」「供應鏈信任」三個面向。
課程尾聲或導論使用 C.6 四則軼事：作為引起動機、或作為期末「從案例反思自己的開發流程」的引子。
如何用這份案例集做作業設計#
授課者可以採用的三種常見作業型態：
- 案例對照寫作：指定一個正文章節，要求學生用二到三個本附錄案例佐證該章核心論點（例如：用 Ariane 5 + Therac-25 佐證「為什麼要驗證」）。
- 案例復盤報告：讓學生把某個案例「重演一遍」，在 Mock 環境重現（例如重現 500 哩 Email 的逾時邏輯、或寫一個觸發 left-pad 依賴崩潰的最小範例），寫出偵錯與復盤過程。
- 設計 Harness 對策：挑選任一失敗案例，要求學生以第 9 章 Harness 五要素為框架，設計「如果在 AI 驅動的世界重造這個系統，要加哪些約束/驗證/糾正來避免同樣後果」。
想一想#
- 對照表中哪一個案例，讓你第一次真正「看懂」某個正文章節的價值？為什麼是它？
- 如果只能挑「五個最該讓大四生畢業前知道的案例」，你會選哪五個？說說你的挑選標準。
- 你身邊最近的專案（無論是作業、課程專案或社團系統），最接近本附錄哪個案例的前兆？你要怎麼讓它不要變成完整版的悲劇？
本章小結#
本節提供案例總表與教學指引，把附錄 C 的 22 個案例與正文章節逐一對應——它們不是孤立的「故事」，而是本書每個章節論點的活教材。研讀建議：先讀正文建立框架，再回來讀案例獲得體感，最後用自己的專案做對照。案例集真正的價值不在記憶，而在遷移：能在新情境中認出「這好像是 Ariane 5 / Knight Capital / Therac-25 的結構」的人，就是最難被拍賣的工程師。