以下內容基於原文事件脈絡，將實際遇到的問題、根因、解法與成效，整理為可教學、可演練、可評估的 15 個實戰案例。每案都以工作流與操作步驟為主（必要時提供設定範例），確保能在課堂、專案與評估中直接使用。

Case #1: 筆電液體災害的「第一小時」緊急處置 SOP

Problem Statement（問題陳述）

• 業務場景：會議中飲料打翻在 ThinkPad X31 上，僅能簡單倒出液體與擦拭。後續回家才處理，導致開機失敗與連鎖硬體/資料問題。情境典型、時間緊迫，現場不一定有工具與耗材，必須靠行動與流程降低二次損害風險。
• 技術挑戰：在缺乏專業工具下，如何迅速切斷電源、導流、拆解與安全乾燥，避免主機板、鍵盤、硬碟等短路與腐蝕。
• 影響範圍：機器無法開機、資料毀損、鍵盤機械損害、後續維修與停機時間上升。
• 複雜度評級：中

Root Cause Analysis（根因分析）

• 直接原因：
  1. 液體自鍵盤與縫隙直接灌入機內，造成短路風險。
  2. 當下僅擦表面未做拆解與深度導乾，殘留水分留在板件與連接器。
  3. 帶糖飲料乾燥後殘留黏性物質，造成鍵盤機械性卡滯。
• 深層原因：
  • 架構層面：裝置非防潑灑設計，缺乏導流與塗覆防護。
  • 技術層面：板件與連接器無披覆塗層，易受液體導電/腐蝕。
  • 流程層面：缺少現場緊急處置 SOP 與標準工具包。

Solution Design（解決方案設計）

• 解決策略：建立「第一小時」SOP：立即斷電→導流→初步拆解→安全低溫乾燥→必要時封存帶回進階處理；全程避免通電測試，降低二次傷害。

• 實施步驟：
  1. 斷電與導流
     • 實作細節：立刻關機、拔變壓器、取下電池；將機身倒置成倒V或鍵盤朝下，讓液體自然流出。
     • 所需資源：螺絲起子、無絨布、吸水紙。
     • 預估時間：5-10 分鐘。
  2. 初步拆解與低溫乾燥
     • 實作細節：拆鍵盤與硬碟艙蓋，使用常溫風或低溫風循環（避免熱風直吹）；必要時使用乾燥劑密封靜置。
     • 所需資源：螺絲起子、乾燥劑、密封袋、小風扇。
     • 預估時間：30-60 分鐘（後續靜置 12-48 小時）。
• 關鍵程式碼/設定：

  Implementation Example（實作範例）
  SOP Step 0：禁止通電測試
  SOP Step 1：Power → OFF、AC → OFF、Battery → OUT
  SOP Step 2：Orient → 「鍵盤朝下」/「倒V」→ 自然導流
  SOP Step 3：Remove → Keyboard、HDD 蓋板
  SOP Step 4：Dry → 低溫風循環/乾燥劑 12-48 小時
  SOP Step 5：視覺檢查 → 連接器、板件水跡與腐蝕
  

• 實際案例：原文先擦乾再回家處理，後續開不了機；拆開以吹風機低溫吹乾後暫時恢復。
• 實作環境：ThinkPad X31，傳統鍵盤結構，2.5” PATA HDD。
• 實測數據：
  • 改善前：現場僅表面擦拭；開機失敗風險高。
  • 改善後：拆解＋低溫乾燥後可正常開機。
  • 改善幅度：功能可用性由 0% → 可開機（定性提升）。

Learning Points（學習要點）

• 核心知識點：
  • 液體災害時序管理：先斷電，後處置。
  • 低溫乾燥與自然導流比分解式烘烤安全。
  • 黏性飲料的後續殘留會造成機械結構問題。
• 技能要求：
  • 必備技能：筆電基本拆解、模組識別、安全用電。
  • 進階技能：風險評估、SOP 制定與培訓。
• 延伸思考：
  • 可應用於手機、鍵盤、外接儲存裝置。
  • 風險：過熱吹風造成板件翹曲。
  • 優化：配備緊急工具包與標準作業卡片。

Practice Exercise（練習題）

• 基礎練習：撰寫你公司適用的「第一小時 SOP」（30 分鐘）。
• 進階練習：在報廢機上演練拆鍵盤與導流定位（2 小時）。
• 專案練習：設計並採購一套行動維護應急包（8 小時）。

Assessment Criteria（評估標準）

• 功能完整性（40%）：SOP 覆蓋關鍵環節（斷電/導流/乾燥/檢查）。
• 程式碼品質（30%）：SOP 文件清晰可操作。
• 效能優化（20%）：時間與工具配置合理。
• 創新性（10%）：風險提示與替代方案完善。

Case #2: 進水後無法開機的低溫烘乾復原

Problem Statement（問題陳述）

• 業務場景：液體入侵後 X31 開不了機。使用者拆機並以吹風機吹乾，系統恢復正常，但後續出現硬碟異音等連鎖問題。此案聚焦在「開不了機」階段的復原方法與風險控制。
• 技術挑戰：快速去除板件與連接器水分，避免再次通電造成短路與損害擴大。
• 影響範圍：系統停機、資料風險、進一步硬體損傷。
• 複雜度評級：中

Root Cause Analysis（根因分析）

• 直接原因：
  1. 機內殘留水分，電源上電即短路。
  2. 鍵盤與掌托區域導入液體影響主機板周邊。
  3. 連接器潮濕造成不穩定接觸。
• 深層原因：
  • 架構層面：非防潑設計。
  • 技術層面：缺乏披覆塗層/密封。
  • 流程層面：缺少「禁止通電測試」的硬性規範。

Solution Design（解決方案設計）

• 解決策略：採低溫、間接風乾與長時間靜置；重點檢查鍵盤下方、主機板邊角、連接器、HDD 艙位；通電前以目視與氣味檢查確保無殘留。

• 實施步驟：
  1. 低溫風乾與靜置
     • 實作細節：使用常溫風/低溫風，距離 20-30cm，避免集中加熱。
     • 所需資源：溫控吹風機/小風扇、乾燥劑。
     • 預估時間：12-48 小時。
  2. 通電前檢查
     • 實作細節：觀察白霧/水痕/異味；檢查連接器針腳氧化。
     • 所需資源：放大鏡、無水酒精。
     • 預估時間：20-30 分鐘。
• 關鍵程式碼/設定： ```text Implementation Checklist
• Fan_mode = Low/Cold
• Distance >= 20cm
• Time >= 12h + Desiccant box
• Visual_check(PCB/Connectors) = Pass

• Power_on_test only after all checks ```

• 實際案例：低溫吹風後系統可開機。
• 實作環境：ThinkPad X31。
• 實測數據：
  • 改善前：無法開機。
  • 改善後：能夠正常開機。
  • 改善幅度：可用性 0% → 100%（定性）。

Learning Points

• 核心知識點：低溫風乾優先；通電前檢查；避免過熱。
• 技能要求：拆裝、視覺檢查、風險判斷。
• 延伸思考：引入濕度計與乾燥箱可提升成功率；過熱風有致命風險。

Practice Exercise

• 基礎：撰寫通電前檢查清單（30 分鐘）。
• 進階：在測試板上演練清潔與檢查（2 小時）。
• 專案：制定並演練全員共用「無法開機處置劇本」（8 小時）。

Assessment Criteria

• 功能完整性：步驟完整、可落地。
• 程式碼品質：檢查表可追蹤。
• 效能優化：縮短乾燥與等待的總時程。
• 創新性：安全控制與工具選型合理。

Case #3: 硬碟異音（怪叫）之故障定位：HDD PCB 進水

Problem Statement（問題陳述）

• 業務場景：開機恢復後不久，硬碟出現怪叫。拆解檢查發現硬碟電路板（PCB）曾進水未清潔乾燥。處理後硬碟可運轉，但資料受損。
• 技術挑戰：區分機械硬體故障（磁頭/軸承）與外部電路板進水導致的異常，並在不開盤（避免污染）的前提下處理。
• 影響範圍：資料完整性、系統穩定性、可能的二次損傷。
• 複雜度評級：中

Root Cause Analysis（根因分析）

• 直接原因：
  1. HDD PCB 殘留水分導致異常電流與噪音。
  2. 連接器區域受潮，訊號不穩定。
  3. 回復後立即使用造成熱脹冷縮加劇隱患。
• 深層原因：
  • 架構層面：HDD 外部 PCB 暴露，無密封。
  • 技術層面：PCB 無塗覆，對水分敏感。
  • 流程層面：初次乾燥未覆蓋 HDD 模組。

Solution Design（解決方案設計）

• 解決策略：立即卸下硬碟，清潔 PCB 及連接器，低溫風乾後再測；避免打開硬碟上蓋；必要時更換備援硬碟進行系統恢復，將故障碟作為「只讀救援源」。

• 實施步驟：
  1. 卸載與清潔
     • 實作細節：取出 2.5” PATA 硬碟，使用無水酒精清潔 PCB 與連接器，風乾。
     • 所需資源：無水酒精、無塵布、螺絲起子。
     • 預估時間：30-45 分鐘 + 2-12 小時乾燥。
  2. 安全測試
     • 實作細節：裝回做 BIOS 健康檢查；若仍異常，轉為只讀外接做救援。
     • 所需資源：外接轉接座、測試平台。
     • 預估時間：30 分鐘。
• 關鍵程式碼/設定： ```text Implementation Notes
• DO NOT open HDD dust cover
• Clean PCB & Connector with isopropyl alcohol (IPA 99%)

• Set source disk to READ-ONLY for later recovery ```

• 實際案例：PCB 乾燥後硬碟可運轉，但資料已毀損。
• 實作環境：ThinkPad X31 2.5” HDD。
• 實測數據：
  • 改善前：異音明顯，運轉不穩。
  • 改善後：異音消失或降低，可被系統辨識。
  • 改善幅度：硬體可偵測性由 0% → 可偵測（定性）。

Learning Points

• 核心知識點：HDD PCB 與內部機構分離處理；只讀原則。
• 技能要求：硬碟拆裝與清潔。
• 延伸思考：若仍異音，應立即停用並以影像檔做救援。

Practice Exercise

• 基礎：撰寫硬碟清潔與只讀掛載流程（30 分鐘）。
• 進階：在測試碟上演練連接器清潔與 BIOS 檢測（2 小時）。
• 專案：建立標準救援工作站（外接座、只讀卡、UPS）（8 小時）。

Assessment Criteria

• 功能完整性：只讀、清潔、檢測全覆蓋。
• 程式碼品質：流程文件可重複。
• 效能優化：縮短停機時間。
• 創新性：風險控制措施到位。

Case #4: 乾燥後可轉但資料毀損：檔案系統損毀救援策略

Problem Statement（問題陳述）

• 業務場景：硬碟轉動恢復但資料毀損，開不了機；外接 USB 也讀不出。需從檔案系統層面救回關鍵資料。
• 技術挑戰：在可能的 MBR/分割表/檔案系統損毀下，安全地執行深度掃描與救援。
• 影響範圍：業務資料可用性、重建作業時間。
• 複雜度評級：中

Root Cause Analysis

• 直接原因：
  1. 不正常斷電與濕氣導致檔案系統結構損壞。
  2. 分割表/MBR 受損使外接無法掛載。
  3. 壞軌/重試造成讀取失敗。
• 深層原因：
  • 架構層面：無備援磁碟/RAID。
  • 技術層面：單碟單分割風險集中。
  • 流程層面：缺乏例行備份策略。

Solution Design

• 解決策略：以第三方救援工具進行只讀深度掃描，導出資料到健康目的碟；避免直接修復原碟結構以免二次破壞。

• 實施步驟：
  1. 只讀外接與影像化（若可行）
     • 實作細節：將來源碟只讀掛載，優先建立整碟映像檔，再在映像上掃描。
     • 所需資源：救援軟體、外接座、足量容量目的碟。
     • 預估時間：1-8 小時（視容量）。
  2. 深度掃描與資料導出
     • 實作細節：選擇原始扇區掃描，先導出關鍵資料夾，再全量。
     • 所需資源：Final Data 或同級工具。
     • 預估時間：數小時至數天。
• 關鍵程式碼/設定： ```text Implementation Example
• Source: READ-ONLY
• Mode: Deep scan (sector-level)
• Export order: Critical folders → Bulk export

• Do NOT write to source disk ```

• 實際案例：以 Final Data 掃描兩天後成功救回資料。
• 實作環境：Windows PC + 外接來源碟 + 目的碟。
• 實測數據：
  • 改善前：外接無法讀取，資料不可用。
  • 改善後：資料成功救回。
  • 改善幅度：資料可用性 0% → 關鍵資料恢復（定性）。

Learning Points

• 核心知識點：先影像再掃描；先關鍵後全量；嚴格只讀。
• 技能要求：外接只讀與救援軟體操作。
• 延伸思考：日後導入備份/快照可大幅降低風險。

Practice Exercise

• 基礎：撰寫救援前置檢查清單（30 分鐘）。
• 進階：在測試映像檔上執行深度掃描與選擇性導出（2 小時）。
• 專案：建置標準救援流程與模板（8 小時）。

Assessment Criteria

• 功能完整性：只讀、影像、掃描、導出完整。
• 程式碼品質：流程文件清楚。
• 效能優化：掃描策略合理。
• 創新性：風險防範完整。

Case #5: 使用 Final Data 進行深度掃描資料救援

Problem Statement

• 業務場景：原文使用 Final Data 在 PC 上掃描兩天救回資料。本案聚焦工具化操作與任務管理，確保長時運行穩定與成功率。
• 技術挑戰：大容量深度掃描與長時間任務的穩定度；避免中斷與寫入源碟。
• 影響範圍：資料救援成功率與時間成本。
• 複雜度評級：中

Root Cause Analysis

• 直接原因：
  1. 檔案系統/MBR 受損導致常規掛載失敗。
  2. 壞軌導致多次重試，時間極長。
  3. 使用者急於取資料，易誤操作覆寫。
• 深層原因：
  • 架構層面：資料無備援。
  • 技術層面：缺少只讀硬體保護。
  • 流程層面：缺少長任務監控與恢復策略。

Solution Design

• 解決策略：以 Final Data 深度掃描，分批導出，高可用電源/網路環境，記錄掃描進度，預先規劃目的碟空間與命名規則。

• 實施步驟：
  1. 工具準備與測試
     • 實作細節：安裝授權版 Final Data；測試短任務；鎖定來源為只讀。
     • 資源：授權軟體、只讀卡（可選）。
     • 時間：30-45 分鐘。
  2. 長任務配置
     • 實作細節：停用睡眠、省電；接 UPS；設定分批導出路徑。
     • 資源：UPS、穩定電源、目的碟。
     • 時間：15-30 分鐘。
• 關鍵程式碼/設定： ```text Final Data Runbook
• Power: UPS + Disable Sleep (Control Panel → Power Options)
• Source: Read-only bridge (if available)
• Scan: Deep Scan → Recover by file type + folder structure

• Export: Batch 1 (critical) → Batch 2 (bulk) ```

• 實際案例：掃描約兩天救回資料。
• 實作環境：Windows PC。
• 實測數據：
  • 改善前：資料不可讀。
  • 改善後：資料救回，系統恢復。
  • 改善幅度：資料可用性顯著提升（定性）。

Learning Points

• 核心知識點：長任務穩定性設計；批次導出策略。
• 技能要求：工具熟練度、電源管理。
• 延伸思考：可替換為其他救援工具但遵守同樣原則。

Practice Exercise

• 基礎：配置電源選項避免睡眠（30 分鐘）。
• 進階：模擬分批導出與命名規範（2 小時）。
• 專案：撰寫完整 Final Data Runbook（8 小時）。

Assessment Criteria

• 功能完整性：配置與導出策略到位。
• 程式碼品質：Runbook 可落地。
• 效能優化：中斷風險控制。
• 創新性：批次策略與告警設計。

Case #6: 無法以 USB 外接讀取硬碟的處理流程

Problem Statement

• 業務場景：將掛掉的硬碟以 USB 接到別台也讀不出。需判斷是邏輯損毀還是硬體層失敗，並選擇正確救援入口。
• 技術挑戰：避免在掛載失敗時嘗試修復寫入，導致二次破壞。
• 影響範圍：資料救援成功率與時間。
• 複雜度評級：中

Root Cause Analysis

• 直接原因：
  1. 分割表/MBR 損毀導致系統不指派磁碟代號。
  2. 檔案系統錯誤或目錄結構崩壞。
  3. 介面/轉接座不穩定或供電不足。
• 深層原因：
  • 架構層面：單一故障點。
  • 技術層面：缺少只讀介面。
  • 流程層面：缺乏故障分層診斷流程。

Solution Design

• 解決策略：進行分層排除：介面/供電→磁碟辨識→分割表→檔案系統；全程只讀；一旦確定為邏輯損毀，改用救援工具深度掃描。

• 實施步驟：
  1. 硬體層排除
     • 實作細節：更換 USB 線/外接座/USB 口；使用 Y 線雙供電。
     • 資源：多組線材與外接座。
     • 時間：15-30 分鐘。
  2. 邏輯層判讀
     • 實作細節：在磁碟管理確認是否偵測到磁碟與分割；若無分割，切勿初始化，改走救援。
     • 資源：Windows 磁碟管理、救援工具。
     • 時間：15-30 分鐘。
• 關鍵程式碼/設定：

  Quick Decision Tree
  Disk Detected? → No → Check cable/power/hub
  Yes → Partition Visible? → No → DO NOT INIT → Recovery Scan
  Yes → FS Mount? → No → Read-only mount & Recovery
  

• 實際案例：外接不可讀，改以救援工具深掃後救回。
• 實作環境：Windows。
• 實測數據：定性改善（可讀性從無 → 可救援）。

Learning Points

• 核心知識點：禁止初始化/格式化；只讀原則。
• 技能要求：硬體排除、磁碟管理判讀。
• 延伸思考：在企業環境導入只讀硬體橋接器。

Practice Exercise

• 基礎：畫出你的排除決策樹（30 分鐘）。
• 進階：模擬外接不可讀情境與判斷（2 小時）。
• 專案：制定標準排除手冊（8 小時）。

Assessment Criteria

• 功能完整性：排除步驟完整。
• 程式碼品質：決策樹清晰。
• 效能優化：避免無效嘗試。
• 創新性：只讀保護與告警措施。

Case #7: 臨時備援：以舊 40GB 硬碟重灌維持營運

Problem Statement

• 業務場景：原硬碟不可用期間，臨時換上舊 40GB 硬碟重灌，讓電腦可用，並行執行資料救援。
• 技術挑戰：快速恢復基本作業環境，並與救援流程彼此不干擾。
• 影響範圍：停機時間、工作連續性。
• 複雜度評級：低

Root Cause Analysis

• 直接原因：
  1. 主儲存裝置不可用。
  2. 等待救援時間長達兩天。
  3. 同機救援風險高。
• 深層原因：
  • 架構層面：缺乏可快速切換的備援系統碟。
  • 技術層面：無多開機環境。
  • 流程層面：缺乏緊急替代作業機制。

Solution Design

• 解決策略：以替代硬碟迅速重灌最小可行環境（OS+必要軟體），主機恢復日常使用；救援在另一台 PC 進行，避免資源衝突。

• 實施步驟：
  1. 替代碟安裝
     • 實作細節：裝入舊 40GB 硬碟，安裝 OS 與必要驅動。
     • 資源：安裝媒體、驅動程式包。
     • 時間：1-2 小時。
  2. 雙路並行
     • 實作細節：救援移交至桌機執行；筆電恢復辦公。
     • 資源：桌機救援站。
     • 時間：5-10 分鐘切換。
• 關鍵程式碼/設定： ```text Minimal OS List
• OS + Driver + Browser + Office Viewer

• Skip heavy apps until data returns ```

• 實際案例：以舊碟重灌撐著用；資料救援在 PC 上跑兩天。
• 實作環境：X31 + 桌機救援站。
• 實測數據：
  • 改善前：完全停機。
  • 改善後：辦公可用，救援並行。
  • 改善幅度：停機時間顯著下降（定性）。

Learning Points

• 核心知識點：最小可行系統（MVS）理念；並行作業。
• 技能要求：快速重灌、驅動部署。
• 延伸思考：維持一顆可開機的「乾淨備援碟」。

Practice Exercise

• 基礎：列出你的 MVS 清單（30 分鐘）。
• 進階：在測試機用小容量碟完成重灌（2 小時）。
• 專案：打造可熱插拔的多系統啟動盤（8 小時）。

Assessment Criteria

• 功能完整性：可開機且可工作。
• 程式碼品質：部署文檔清晰。
• 效能優化：重灌時間與體驗。
• 創新性：並行策略設計。

Case #8: 長時間資料救援作業的穩定性管理（兩天掃描）

Problem Statement

• 業務場景：深度掃描兩天。需確保長任務不中斷、可恢復，並記錄產出。
• 技術挑戰：電源、散熱、睡眠、輸出路徑、斷點續跑。
• 影響範圍：成功率與總時程。
• 複雜度評級：中

Root Cause Analysis

• 直接原因：
  1. 壞軌重試導致耗時。
  2. 系統睡眠/更新可能中斷。
  3. 目的碟空間不足風險。
• 深層原因：
  • 架構層面：無任務編排與監控。
  • 技術層面：缺乏 UPS 與散熱規劃。
  • 流程層面：無斷點記錄與報告。

Solution Design

• 解決策略：設置 UPS、關閉睡眠更新、固定導出路徑與命名規則、定時紀錄進度，必要時分段掃描。

• 實施步驟：
  1. 穩定性設定
     • 實作細節：關閉睡眠/螢幕關閉不影響；確保散熱與環境溫度。
     • 資源：UPS、散熱座。
     • 時間：15-30 分鐘。
  2. 進度紀錄與分段
     • 實作細節：每 4-8 小時記錄扇區範圍與輸出清單。
     • 資源：簡單紀錄表。
     • 時間：5 分鐘/次。
• 關鍵程式碼/設定： ```text Stability Checklist
• Power: UPS
• Windows Update: Pause during recovery
• Sleep: Never (AC)
• Export target: >= 2x source estimated data

• Log: Timestamps + sectors range + file counts ```

• 實際案例：兩天掃描完成救援。
• 實作環境：Windows PC。
• 實測數據：中斷風險下降（定性）。

Learning Points

• 核心知識點：長任務工程化管理。
• 技能要求：系統設定、任務紀錄。
• 延伸思考：可加入監控/告警。

Practice Exercise

• 基礎：編寫穩定性清單（30 分鐘）。
• 進階：模擬 8 小時長任務並產出報告（2 小時）。
• 專案：自動化生成進度報告（8 小時）。

Assessment Criteria

• 功能完整性：設定周全。
• 程式碼品質：紀錄可追蹤。
• 效能優化：降低重跑。
• 創新性：監控自動化。

Case #9: ThinkPad 鍵盤進水後黏滯之機械性根因與取代決策

Problem Statement

• 業務場景：鍵盤乾燥後按鍵「卡卡的」、如砂卡或口香糖黏住。輸入效率與體驗嚴重下降。
• 技術挑戰：判斷可否清潔恢復或應直接更換；風險是拆解清洗不一定能恢復手感。
• 影響範圍：輸入效率、錯誤率、長期使用體驗。
• 複雜度評級：低

Root Cause Analysis

• 直接原因：
  1. 甜飲料乾後殘留糖分與雜質。
  2. 薄膜結構內滲黏稠物。
  3. 彈片/導柱阻滯。
• 深層原因：
  • 架構層面：鍵盤非防潑灑。
  • 技術層面：薄膜/剪刀腳難以完全清潔。
  • 流程層面：無替換件策略。

Solution Design

• 解決策略：對於整片普遍黏滯的情況，直接更換鍵盤更具成本效益且能恢復手感；保留受損件做拆解研究或備件。

• 實施步驟：
  1. 狀態評估
     • 實作細節：抽樣 10-20 個鍵測試行程與回彈。
     • 資源：檢查表。
     • 時間：15 分鐘。
  2. 更換決策
     • 實作細節：若受影響 >10-20% 鍵位，直接更換。
     • 資源：替換鍵盤。
     • 時間：1-2 小時（含採購/更換）。
• 關鍵程式碼/設定：

  Decision Rule
  AffectedKeysRatio > 0.2 → Replace
  Else → Clean (IPA + Compressed air) → Re-test
  

• 實際案例：更換鍵盤後手感恢復。
• 實作環境：X31 鍵盤模組。
• 實測數據：
  • 改善前：大量鍵位黏滯。
  • 改善後：手感恢復正常。
  • 改善幅度：輸入體驗提升（定性）。

Learning Points

• 核心知識點：清潔 vs 更換的成本效益。
• 技能要求：鍵盤測試與判斷。
• 延伸思考：預置替換件可縮短停機。

Practice Exercise

• 基礎：設計鍵盤手感評估表（30 分鐘）。
• 進階：在舊鍵盤上實作清潔與評估（2 小時）。
• 專案：形成你的更換決策標準（8 小時）。

Assessment Criteria

• 功能完整性：決策標準可用。
• 程式碼品質：表單清晰。
• 效能優化：停機縮短。
• 創新性：定量評估方法。

Case #10: 更換鍵盤的採購優化：官方維修 vs 通路 vs 拍賣平台

Problem Statement

• 業務場景：官方報價 3650 NTD、通路 2300 NTD（無庫存需等一週）、拍賣平台 1500 NTD（隔天到貨）。需兼顧成本與交期。
• 技術挑戰：價格資訊蒐集、庫存真實性、相容風險。
• 影響範圍：維修成本、恢復時間、使用者體驗。
• 複雜度評級：低

Root Cause Analysis

• 直接原因：
  1. 官方維修價格高。
  2. 通路庫存資訊不實。
  3. 拍賣平台價格低但需驗證相容。
• 深層原因：
  • 架構層面：採購決策流程不完善。
  • 技術層面：料號/FRU 不透明。
  • 流程層面：未做多來源比價與交期驗證。

Solution Design

• 解決策略：建立「三源比價 + 庫存確認 + FRU 相容檢核」流程；以「交期×成本」綜合評分決策。

• 實施步驟：
  1. 三源比價與庫存驗證
     • 實作細節：官方/通路/平台詢價與庫存截圖存證。
     • 資源：比價表。
     • 時間：1-2 小時。
  2. 相容性審查與下單
     • 實作細節：確認 FRU/型號相容；選擇最佳交期×成本。
     • 資源：型錄/維修手冊。
     • 時間：30-60 分鐘。
• 關鍵程式碼/設定：

  Procurement Score = (Weight_Cost * NormalizedCost) + (Weight_LeadTime * NormalizedLeadTime)
  Select min(Procurement Score)
  

• 實際案例：最終以 1500 NTD 方案隔天到貨；省 800 NTD（相對通路）/2150 NTD（相對官方）。
• 實作環境：台灣市場。
• 實測數據：
  • 改善前：預計 2300 NTD，交期 7 天。
  • 改善後：1500 NTD，交期 1 天。
  • 改善幅度：成本 -34.8%；交期 -85.7%（7→1 天）。

Learning Points

• 核心知識點：多來源比價決策；交期與成本平衡。
• 技能要求：採購與驗證。
• 延伸思考：建立常用備件名單與目標價。

Practice Exercise

• 基礎：完成一份三源比價表（30 分鐘）。
• 進階：為 3 個常見備件建立決策模型（2 小時）。
• 專案：導入採購 SOP 與審核節點（8 小時）。

Assessment Criteria

• 功能完整性：比價、庫存、相容都覆蓋。
• 程式碼品質：決策模型可重用。
• 效能優化：成本/交期顯著改善。
• 創新性：風險控制措施。

Case #11: 庫存資訊不實導致維修延誤的風險與因應

Problem Statement

• 業務場景：通路顯示「庫存正常」但事後通知缺貨需等一週，影響恢復時間。
• 技術挑戰：在下單前有效驗證庫存真實性。
• 影響範圍：停機時間、使用者滿意度、信任。
• 複雜度評級：低

Root Cause Analysis

• 直接原因：
  1. 賣場庫存同步延遲或虛標。
  2. 無二備供應商。
  3. 下單前未做確認機制。
• 深層原因：
  • 架構層面：採購缺少風險緩解策略。
  • 技術層面：無 API 或人工確認流程。
  • 流程層面：未設定「庫存截圖 + 業務確認」標準。

Solution Design

• 解決策略：下單前必須二次確認庫存（電話/訊息留證），若不確定，並行詢價次要供應商；設定「超時自動轉單」規則。

• 實施步驟：
  1. 庫存驗證
     • 實作細節：索取庫存截圖與出貨日；保存聊天紀錄。
     • 資源：通訊工具。
     • 時間：15-30 分鐘。
  2. 轉單策略
     • 實作細節：若超過 SLA（例如 24 小時內未出貨），自動轉單次要供應商。
     • 資源：SLA 文件。
     • 時間：10 分鐘。
• 關鍵程式碼/設定：

  If (ShipDateConfirmed == false) OR (ETA > SLA)
  → Trigger Secondary Vendor Order
  

• 實際案例：通路缺貨改轉拍賣平台，隔天到貨。
• 實作環境：台灣市場。
• 實測數據：
  • 改善前：交期 7 天不確定。
  • 改善後：交期 1 天。
  • 改善幅度：交期縮短 85.7%。

Learning Points

• 核心知識點：庫存驗證與轉單策略。
• 技能要求：SLA 設計、供應商管理。
• 延伸思考：自動化爬取與驗證。

Practice Exercise

• 基礎：撰寫庫存確認話術與表單（30 分鐘）。
• 進階：為 2 家供應商設計轉單規則（2 小時）。
• 專案：建立採購看板與 SLA 追蹤（8 小時）。

Assessment Criteria

• 功能完整性：確認與轉單閉環。
• 程式碼品質：規則清晰。
• 效能優化：交期縮短。
• 創新性：自動化構想。

Case #12: 鍵盤相容性評估：X30 與 X31 料號互換驗證

Problem Statement

• 業務場景：收到的鍵盤與原來略有不同，推測為 X30 料號，但可正常使用。需建立相容性評估準則。
• 技術挑戰：在外觀或標示不同時，判斷能否安全互換。
• 影響範圍：功能可用性、保固風險。
• 複雜度評級：低

Root Cause Analysis

• 直接原因：
  1. 市場上的通用/替代料號混用。
  2. 賣場資訊不完整。
  3. 使用者無相容性判斷指南。
• 深層原因：
  • 架構層面：型號家族共用設計。
  • 技術層面：連接器/固定孔位兼容。
  • 流程層面：未比對 FRU 與維修手冊。

Solution Design

• 解決策略：以 FRU/維修手冊為準，核對連接器、孔位、鍵帽布局；先行做「不通電裝配測試」，再功能測試。

• 實施步驟：
  1. 文獻比對
     • 實作細節：查詢 FRU 對照表，確認兼容清單。
     • 資源：HMM（Hardware Maintenance Manual）。
     • 時間：30-60 分鐘。
  2. 裝配測試
     • 實作細節：不接電，確認孔位與卡扣吻合；再上電測試 Fn/TrackPoint。
     • 資源：螺絲起子。
     • 時間：30 分鐘。
• 關鍵程式碼/設定： ```text Compatibility Checklist
• FRU in HMM? Yes/No
• Connector type & position: Match
• Screw holes & brackets: Match

• Function keys & TrackPoint: Pass ```

• 實際案例：疑似 X30 料號鍵盤在 X31 上正常使用。
• 實作環境：X30/X31 家族。
• 實測數據：功能測試通過（定性）。

Learning Points

• 核心知識點：以 FRU 與 HMM 為準的相容判斷。
• 技能要求：文獻查核、裝配測試。
• 延伸思考：建立內部相容資料庫。

Practice Exercise

• 基礎：找出 3 組相容 FRU 對照（30 分鐘）。
• 進階：完成一個不通電裝配測試流程（2 小時）。
• 專案：建立相容性清單模板（8 小時）。

Assessment Criteria

• 功能完整性：比對與測試完整。
• 程式碼品質：清單清楚。
• 效能優化：縮短判斷時間。
• 創新性：資料庫化。

Case #13: 更換 ThinkPad X31 鍵盤的實作步驟與注意事項

Problem Statement

• 業務場景：為解決鍵盤黏滯問題，替換 X31 鍵盤。需標準化拆裝流程，避免損傷與安裝錯誤。
• 技術挑戰：正確拆螺絲、排線卡扣、重新裝配與測試。
• 影響範圍：輸入功能、TrackPoint、保固貼紙。
• 複雜度評級：低

Root Cause Analysis

• 直接原因：
  1. 原鍵盤受損需更換。
  2. 拆裝風險（卡扣/排線）。
  3. 靜電/刮傷風險。
• 深層原因：
  • 架構層面：排線脆弱。
  • 技術層面：螺絲規格多樣。
  • 流程層面：無標準扭力與測試步驟。

Solution Design

• 解決策略：依 HMM 步驟執行：斷電→拆鍵盤螺絲→鬆開排線→裝新件→依序測試普通鍵、Fn、TrackPoint。

• 實施步驟：
  1. 拆卸
     • 實作細節：移除電源/電池；標記螺絲位置；鬆開 ZIF 卡扣。
     • 資源：十字螺絲起子、塑膠撬棒、ESD 手環。
     • 時間：20-30 分鐘。
  2. 安裝與測試
     • 實作細節：插好排線、確保卡扣到位；開機進入測試程式檢驗鍵位與指點桿。
     • 資源：鍵盤測試工具（內建/第三方）。
     • 時間：20-30 分鐘。
• 關鍵程式碼/設定： ```text Post-Install Test List
• Alphabet keys: Pass
• Modifiers (Shift/Ctrl/Alt/Fn): Pass
• Function keys (F1-F12): Pass

• TrackPoint & buttons: Pass ```

• 實際案例：更換新鍵盤後手感恢復。
• 實作環境：X31。
• 實測數據：輸入功能全通過（定性）。

Learning Points

• 核心知識點：ZIF 卡扣操作；裝配測試順序。
• 技能要求：拆裝與靜電防護。
• 延伸思考：建立扭力與螺絲對照表。

Practice Exercise

• 基礎：在舊機上拆裝鍵盤一次（30 分鐘）。
• 進階：編寫裝配與測試清單（2 小時）。
• 專案：錄製標準操作影片與文件（8 小時）。

Assessment Criteria

• 功能完整性：拆裝與測試完整。
• 程式碼品質：文件可重複操作。
• 效能優化：縮短操作時間。
• 創新性：教學資源產出。

Case #14: 事件後系統全面健康檢查與回復驗證

Problem Statement

• 業務場景：液體事件處理與鍵盤更換後，需做全機驗證：開機、自檢、儲存、輸入、穩定性與體驗（手感）。
• 技術挑戰：建立涵蓋硬體/軟體/體驗的驗證清單。
• 影響範圍：避免遺留隱患。
• 複雜度評級：低

Root Cause Analysis

• 直接原因：
  1. 事件後可能有隱性損傷。
  2. 局部修復未必覆蓋所有模組。
  3. 使用者體驗需量化。
• 深層原因：
  • 架構層面：缺乏整機回歸測試。
  • 技術層面：無統一測試工具。
  • 流程層面：無標準驗收。

Solution Design

• 解決策略：建立回歸測試清單，含 BIOS/記憶體/儲存 SMART/鍵盤/TrackPoint/溫度/充放電；記錄基準以便追蹤。

• 實施步驟：
  1. 硬體自檢
     • 實作細節：BIOS 自檢、記憶體測試、SMART 查詢、溫度監控。
     • 資源：Memtest、SMART 工具。
     • 時間：1-2 小時。
  2. 輸入與體驗
     • 實作細節：鍵盤測試、TrackPoint 精度、手感評分。
     • 資源：鍵盤測試器。
     • 時間：20-30 分鐘。
• 關鍵程式碼/設定： ```text Health Checklist (excerpt)
• POST: OK
• RAM Test: 1 pass OK
• SMART: No reallocated sectors
• Keyboard/TrackPoint: Pass

• Temp (idle/load): Within baseline ```

• 實際案例：新鍵盤手感回歸；系統恢復正常。
• 實作環境：X31。
• 實測數據：功能測試通過（定性）。

Learning Points

• 核心知識點：整機回歸測試的必要性。
• 技能要求：硬體測試工具使用。
• 延伸思考：建立基準數據以追蹤老化。

Practice Exercise

• 基礎：編寫你的健康檢查清單（30 分鐘）。
• 進階：在測試機上跑一次完整回歸（2 小時）。
• 專案：打造自動化健康檢查流程（8 小時）。

Assessment Criteria

• 功能完整性：清單完整。
• 程式碼品質：紀錄規範。
• 效能優化：測試時間控制。
• 創新性：自動化程度。

Case #15: 事後復盤與成本控制：避免多花 800 元的採購教訓

Problem Statement

• 業務場景：原本在通路以 2300 NTD 下單，後改採拍賣 1500 NTD 方案，隔天到貨，避免多花 800 NTD 與一週等待。
• 技術挑戰：復盤決策過程，形成可重用的採購準則。
• 影響範圍：未來維修成本與時效。
• 複雜度評級：低

Root Cause Analysis

• 直接原因：
  1. 沒有先做全通路比價。
  2. 相容性疑慮導致傾向官方/通路。
  3. 未設定轉單規則。
• 深層原因：
  • 架構層面：缺乏採購決策框架。
  • 技術層面：不了解家族相容。
  • 流程層面：未定義評估指標。

Solution Design

• 解決策略：建立「比價-相容檢核-交期評估-風險管控」四步法，將價格、交期、相容、保障納入同一張決策表。

• 實施步驟：
  1. 指標化決策
     • 實作細節：價格、交期、相容、保障各自權重。
     • 資源：決策模板。
     • 時間：30 分鐘。
  2. 後評估與知識沉澱
     • 實作細節：事後記錄實際價與天數，更新目標價與SLA。
     • 資源：知識庫。
     • 時間：30 分鐘。
• 關鍵程式碼/設定：

  Score = 0.5*Cost + 0.3*LeadTime + 0.2*Compatibility/Safeguard
  Choose min(Score)
  

• 實際案例：選擇 1500 NTD 且隔天到貨的方案。
• 實作環境：台灣市場。
• 實測數據：
  • 改善前：2300 NTD、1 週交期。
  • 改善後：1500 NTD、1 天交期。
  • 改善幅度：成本 -34.8%；交期 -85.7%。

Learning Points

• 核心知識點：指標化決策；事後復盤。
• 技能要求：資料彙整、權重設定。
• 延伸思考：引入風險保固（退換/驗貨）因子。

Practice Exercise

• 基礎：以範例填一份決策表（30 分鐘）。
• 進階：套用到 3 種零件採購案例（2 小時）。
• 專案：建立採購決策與復盤流程（8 小時）。

Assessment Criteria

• 功能完整性：指標與流程完整。
• 程式碼品質：模板可複用。
• 效能優化：成本/交期改善。
• 創新性：可擴展到其他物料。

— — — — —

案例分類

1) 按難度分類

• 入門級（適合初學者）
  • Case 7、9、10、11、12、13、14、15
• 中級（需要一定基礎）
  • Case 1、2、3、4、5、6、8
• 高級（需要深厚經驗）
  • 無（本組案例以實務流程與作業為主）

2) 按技術領域分類

• 架構設計類
  • Case 1（應急 SOP）、8（長任務設計）、14（健康檢查回歸）、15（決策框架）
• 效能優化類
  • Case 5（長任務效率）、8（穩定性/中斷控制）
• 整合開發類（流程/採購/相容）
  • Case 10、11、12、15
• 除錯診斷類
  • Case 2、3、4、6、14
• 安全防護類
  • Case 1（斷電/防二次損害）、6（只讀/禁止初始化）

3) 按學習目標分類

• 概念理解型
  • Case 1、2、4、8、14
• 技能練習型
  • Case 3、5、6、7、13
• 問題解決型
  • Case 4、5、6、7、10、11、12
• 創新應用型
  • Case 8、15

— — — — —

案例關聯圖（學習路徑建議）

• 建議先學：
  • Case 1（第一小時 SOP）→ 奠定災害處置基礎。
  • Case 2（開不了機的復原）→ 了解乾燥與通電前檢查。
• 診斷與救援主線：
  • Case 3（HDD PCB 進水）→ Case 4（檔案系統救援策略）→ Case 5（Final Data 操作）→ Case 8（長任務穩定性）→ Case 6（USB 外接失敗處理，作為旁路）。
• 維持營運側線：
  • Case 7（臨時備援）與上面救援主線並行。
• 鍵盤修復線：
  • Case 9（取代決策）→ Case 12（相容性評估）→ Case 10（採購優化）→ Case 11（庫存風險）→ Case 13（更換實作）。
• 收尾與制度化：
  • Case 14（健康檢查與回歸）→ Case 15（復盤與成本控制）。
• 依賴關係摘要：
  • Case 1 → 2/3（安全前置）
  • Case 3 → 4/5/6（診斷決定救援路徑）
  • Case 10/11/12 → 13（採購與相容驗證在先）
• 完整學習路徑：
  • 1 → 2 → 3 → 4 → 5 → 8 → 6（備用） → 7（並行） → 9 → 12 → 10 → 11 → 13 → 14 → 15

以上 15 個案例皆源自原文情境，並補齊完整實作步驟、決策框架與評估標準，適合在實戰教學、專案演練與能力評估中直接使用。