以下為依據文章內容，整理出的 18 個可落地的問題解決案例。每個案例均包含問題、根因、解法、實測或量化指標、學習要點與練習與評估。

Case #1: 從 NAS 過渡到迷你 PC：以 i5-5250U 建立 Docker 自用伺服器

Problem Statement（問題陳述）

業務場景：個人部落格與日常服務希望以 Docker 正式運行（如 WordPress），原本寄望於 NAS，但在啟用多容器/服務後，NAS 的運算資源不足導致服務延遲、體驗不佳。希望用低功耗、小體積、可擴充、雙網口的機器作家庭常駐伺服器，且成本要壓低。
技術挑戰：在有限預算內取得 i5 等級 CPU、雙 RAM 槽、可用 2.5” HDD/SSD、至少 1GbE x2 的硬體，並確保 Docker 環境可穩定長時運行。
影響範圍：網站與內部服務效能、穩定度、維護成本、電費與設備噪音。
複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：
1. NAS CPU 運算能力偏弱，容器化後效能瓶頸明顯。
2. 主流 NUC 價格偏高且規格（單記憶體槽、單 LAN）不符需求。
3. 舊 NB 當伺服器 CPU 不夠力，未來擴充受限。
深層原因：
- 架構層面：以 NAS 承載應用與存儲兩種角色，資源競爭且難以水平擴展。
- 技術層面：選型偏向消費級 SoC，對 Docker/多服務不友善。
- 流程層面：未建立容量與效能規劃，臨時擴容代價高。

Solution Design（解決方案設計）

解決策略：以對岸白牌 i5-5250U 迷你 PC 取代 NAS 作為運算節點，保留 NAS 作存儲；採低功耗、無風扇設計以降低噪音與维护，搭配 Docker 部署服務。
實施步驟：
1. 規格確認與硬體選型
  - 實作細節：列出 CPU/RAM/儲存/LAN/功耗/體積/成本清單
  - 所需資源：規格表、比價平台
  - 預估時間：0.5 天
2. 採購與到貨驗收（含 ES CPU/缺件/接口測試）
  - 實作細節：按驗收清單測網口、SATA/mSATA、HDMI 音訊
  - 所需資源：螺絲工具、測試 U 盤、顯示器/網線
  - 預估時間：0.5 天
3. 安裝 OS 與 Docker，部署 WordPress
  - 實作細節：Windows/Linux 擇一；Docker Engine/Compose 部署
  - 所需資源：安裝媒體、Docker、docker-compose
  - 預估時間：0.5~1 天
關鍵程式碼/設定： ```yaml
docker-compose.yml - WordPress + MariaDB（示意）

version: “3.9” services: db: image: mariadb:10.11 environment: MYSQL_ROOT_PASSWORD: strong_root_pw MYSQL_DATABASE: wordpress MYSQL_USER: wpuser MYSQL_PASSWORD: strong_pw volumes: - db_data:/var/lib/mysql restart: unless-stopped

wordpress: image: wordpress:6.5-php8.2-apache ports: - “80:80” environment: WORDPRESS_DB_HOST: db:3306 WORDPRESS_DB_USER: wpuser WORDPRESS_DB_PASSWORD: strong_pw WORDPRESS_DB_NAME: wordpress volumes: - wp_data:/var/www/html restart: unless-stopped

volumes: db_data: wp_data:

- 實際案例：作者以 i5-5250U 無風扇迷你 PC 取代 NAS 作為伺服器。
- 實作環境：i5-5250U、雙 LAN、RAM 2 插槽、Windows 10（驗證）後續可換 Linux。
- 實測數據：
  - 改善前：NUC/ITX 選項成本＞NTD 10,000
  - 改善後：迷你 PC 含運費約 NTD 6,100
  - 改善幅度：成本節省約 39% 以上（依不同 NUC/ITX 組合）

Learning Points（學習要點）
- 核心知識點：
  - 家用伺服器選型要素（功耗/擴充/網口/空間/成本）
  - 計算與存儲角色解耦（NAS 存儲 + 迷你 PC 計算）
  - 用 Docker 提升部署一致性與維運效率
- 技能要求：
  - 必備技能：硬體選型、OS/Docker 基礎安裝
  - 進階技能：容器化服務組合、備份與資料卷策略
- 延伸思考：
  - 可否用 NUC/NUC-alike 次世代平台取代？
  - 白牌硬體的 QC 與保固風險如何控管？
  - 加入監控與告警（Prometheus/Alertmanager）進一步保障 SLA？

Practice Exercise（練習題）
- 基礎練習：撰寫你自己的伺服器需求清單（10 條以上）並比對 3 款硬體（30 分）
- 進階練習：以 docker-compose 在本機跑起 WordPress + DB（2 小時）
- 專案練習：將現有自架服務容器化並完成備份/還原演練（8 小時）

Assessment Criteria（評估標準）
- 功能完整性（40%）：完成伺服器基本服務與資料持久化
- 程式碼品質（30%）：Compose 結構清晰、環境變數安全
- 效能優化（20%）：資源限制、健康檢查、重啟策略
- 創新性（10%）：加入監控/反向代理/自動化部署


## Case #2: 以無風扇全鋁機殼打造 24x7 穩定：溫控與可靠度驗證

### Problem Statement（問題陳述）
- 業務場景：家庭伺服器長期運行，要求低噪音、免清灰、穩定不當機。選擇無風扇設計，但需驗證散熱是否足以支援長時間高負載。
- 技術挑戰：全鋁被動散熱對 CPU/GPU 的熱容與導熱能力要求高；需找出穩定運行邊界。
- 影響範圍：主機壽命、服務 SLA、環境噪音與維護頻率。
- 複雜度評級：中

### Root Cause Analysis（根因分析）
- 直接原因：
  1. 風扇是常見故障點且吸塵易積灰，增加維護與過熱風險。
  2. 被動散熱對長時間滿載的熱通道要求高。
  3. 某些工作負載（CPU+GPU）可能推高溫至保護斷電。
- 深層原因：
  - 架構層面：散熱設計不考慮最壞負載（如 GPU 3D）
  - 技術層面：導熱界面、外殼散熱面積與放置環境未校驗
  - 流程層面：未建立壓測與溫度監控流程

### Solution Design（解決方案設計）
- 解決策略：採 CPU-Z 壓測長時測試 CPU 100%（2 小時）；觀察溫度曲線與是否降頻/斷電；如需使用 GPU/3D，規劃外掛 USB 風扇作保底。

- 實施步驟：
  1. 建立壓測方法
     - 實作細節：CPU-Z Stress CPU、HWiNFO 監控溫度
     - 所需資源：CPU-Z、HWiNFO
     - 預估時間：0.5 小時 + 2 小時壓測
  2. 設備擺放與風道優化
     - 實作細節：確保散熱鰭片朝外、櫃內通風良好
     - 所需資源：散熱墊或外掛 USB 風扇（選）
     - 預估時間：0.5 小時

- 關鍵程式碼/設定：
```text
Implementation Example（實作範例）
1) 啟動 CPU-Z，選擇 "Bench" -> "Stress CPU"
2) 啟動 HWiNFO，記錄 CPU 溫度曲線
3) 若需 GPU 驗證，可同時運行 GPU 負載工具（例如 FurMark），此步驟僅於桌面/3D 情境需要

實際案例：CPU-Z 壓測 2 小時，CPU 約 58°C 穩定，無持續上升。
實作環境：i5-5250U、無風扇全鋁機殼。
實測數據：
- 改善前：未驗證散熱穩定性（風險未知）
- 改善後：CPU 100% 2 小時，穩定約 58°C，無降頻/斷電
- 改善幅度：由未知風險 → 明確可長時承載 CPU 滿載

Learning Points（學習要點）

核心知識點：被動散熱能力評估、壓測方法、風道最佳化
技能要求：
- 必備技能：監控工具使用（HWiNFO/CPU-Z）
- 進階技能：熱設計、導熱介面材質（TIM）優化
延伸思考：若常用 GPU，是否改採低轉速風扇或外掛風扇作折衷？機櫃通風如何改善？

Practice Exercise（練習題）

基礎：跑 30 分鐘 CPU 壓測並截圖溫度曲線（30 分）
進階：加入 30 分鐘 GPU 壓測，觀察互相影響（2 小時）
專案：設計並驗證櫃內風道改善方案（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：壓測策略與記錄完整
程式碼品質（30%）：監控報告清晰、可重現
效能優化（20%）：溫度峰值、降頻避免
創新性（10%）：創意散熱/風道方案

Case #3: NUC/ITX 規格與價格不符預期：以白牌迷你 PC 達成性價比

Problem Statement（問題陳述）

業務場景：需 i5 等級、雙記憶體槽、雙網口、支持 2.5” 儲存的小型伺服器。NUC/ITX 非但價格偏高，規格也不滿足，需另尋低價可用方案。
技術挑戰：在價格與規格間取平衡，同時接受白牌硬體的風險並設計相應驗收。
影響範圍：建置成本、交付時間、後續維護。
複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：
1. 多數 NUC 僅 1 記憶體槽、單 LAN、CPU 等級偏低（Atom/Celeron/i3）
2. 成本超預算
3. ITX 自組合體積/耗電/價格難壓低
深層原因：
- 架構層面：原始平台定位偏桌面/輕用戶
- 技術層面：I/O 擴充選項受限
- 流程層面：未考慮白牌方案的驗收與風險緩解

Solution Design（解決方案設計）

解決策略：選擇 i5-5250U 白牌迷你 PC（雙 RAM 槽、雙 LAN、mSATA x2、HDMI x2、USB 3.0 x4）以低價滿足需求，並搭配嚴格收貨測試。
實施步驟：
1. 比價與規格對照
  - 實作細節：列 NU C/ITX/白牌規格與價格表
  - 所需資源：電商平台、論壇評測
  - 預估時間：0.5 天
2. 風險控管
  - 實作細節：提前與賣家溝通 CPU 是否 ES；準備驗收清單
  - 所需資源：溝通紀錄、驗收表
  - 預估時間：0.5 天
關鍵程式碼/設定： ```text 驗收清單（精簡）
CPU 型號/是否 ES
RAM 槽數/容量識別
LAN 連線測試（雙口）
SATA/mSATA 偵測
HDMI 影像/音訊測試 ```
實際案例：總成本約 NTD 6,100 含運，規格符合需求。
實作環境：白牌迷你 PC。
實測數據：
- 改善前：NUC/ITX＞NTD 10,000 或規格不符
- 改善後：白牌迷你 PC NTD 6,100 符合規格
- 改善幅度：成本省 ≈39%+、規格更貼合需求

Learning Points（學習要點）

核心知識點：硬體選型與成本/規格平衡、白牌風險管理
技能要求：比價表撰寫、驗收測項制定
延伸思考：若長期維運，保固/備援策略如何設計？

Practice Exercise（練習題）

基礎：完成 3 平台的規格/價格對照表（30 分）
進階：撰寫完整驗收清單並實作 5 項測試（2 小時）
專案：端到端選型→驗收→部署報告（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：規格與驗收覆蓋完整
程式碼品質（30%）：文檔結構清晰
效能優化（20%）：能提出成本/風險最優解
創新性（10%）：提出替代方案（NUC/USFF/微型伺服器）

Case #4: USB 3.0 安裝失敗：改用 USB 2.0 與正確開機鍵完成 Win10 部署

Problem Statement（問題陳述）

業務場景：於白牌迷你 PC 安裝 Windows 10，使用 USB 安裝媒體無法從 USB 3.0 連接埠開機，且不同 U 盤相容性不一。
技術挑戰：未知 BIOS/UEFI 實作造成 USB 3.0 開機失敗，需提高安裝成功率。
影響範圍：安裝時程、導入成功率。
複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：
1. USB 3.0 控制器/驅動在安裝階段不兼容
2. 某些隨身碟開機相容性差
3. 使用者不清楚進入 BIOS/Boot Menu 快捷鍵
深層原因：
- 架構層面：UEFI/CSM 設定與媒體格式化不一致
- 技術層面：白牌 BIOS 對 USB 3.0 支援不完善
- 流程層面：未預先驗證安裝媒體

Solution Design（解決方案設計）

解決策略：改用 USB 2.0 連接埠開機、選擇相容性佳的 U 盤、確認進入 BIOS（DEL）與 Boot Menu（F11），建議使用 GPT+FAT32 UEFI 安裝。
實施步驟：
1. 製作 UEFI 安裝隨身碟
  - 實作細節：使用官方 Media Creation Tool 或 Rufus（GPT/FAT32）
  - 所需資源：Rufus/Media Creation Tool
  - 預估時間：30 分
2. 設備開機與安裝
  - 實作細節：開機敲 DEL 進 BIOS、F11 選開機裝置；使用 USB 2.0 口
  - 所需資源：鍵盤/顯示器
  - 預估時間：30-60 分

關鍵程式碼/設定：

# 以 diskpart 建立可開機 UEFI 安裝盤（進階）
diskpart
list disk
select disk <你的U盤號>
clean
convert gpt
create partition primary
format fs=fat32 quick
assign
exit
# 將 Win10 安裝檔拷入（可用 Media Creation Tool 自動完成）

實際案例：USB 3.0 開機失敗；USB 2.0 成功；兩支贈品 U 盤僅一支可用。
實作環境：白牌迷你 PC，Windows 10。
實測數據：
- 改善前：USB 3.0 成功率 0%
- 改善後：USB 2.0 成功率 100%；U 盤成功率 50%→100%（挑選可用者）
- 改善幅度：安裝成功率由 0% → 100%

Learning Points（學習要點）

核心知識點：UEFI/CSM、USB 3.0/2.0 開機差異、安裝媒體相容性
技能要求：製作安裝媒體、BIOS/Boot Menu 操作
延伸思考：Linux 安裝時的 USB 3.0 相容性策略？

Practice Exercise（練習題）

基礎：用 Rufus 製作 Win10 安裝碟（30 分）
進階：嘗試 UEFI/Legacy 兩種模式開機（2 小時）
專案：撰寫安裝失敗排查 SOP（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：安裝成功且可重現
程式碼品質（30%）：SOP 步驟清晰
效能優化（20%）：縮短安裝時間
創新性（10%）：改良相容性驗證方法

Case #5: 主機板 SATA 口失靈：以 mSATA→SATA 轉卡 + DIY 電源線救援

Problem Statement（問題陳述）

業務場景：需接 2.5” HDD 作資料盤，但主機板上唯一 SATA 接口無法偵測任何硬碟。
技術挑戰：無法 RMA 或時間成本過高，需就地利用板上 mSATA 插槽轉接。
影響範圍：儲存容量與可靠性、服務上線時程。
複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：
1. 主機板生產線 QC 不良（SATA 埠故障）
2. 需要另覓電源供應方式
3. 白牌無官方支援/維修
深層原因：
- 架構層面：單一 SATA 埠，無冗餘
- 技術層面：板設兼容性與做工參差
- 流程層面：缺少入廠前介面測試

Solution Design（解決方案設計）

解決策略：採購 mSATA→SATA 轉卡（NTD ~100），改用 mSATA 埠轉出 SATA 訊號；同時自製 SATA 電源線供電。
實施步驟：
1. 轉卡採購與安裝
  - 實作細節：插入 mSATA 槽，轉出 2.5” SATA
  - 所需資源：mSATA→SATA 轉卡、螺絲工具
  - 預估時間：30 分
2. 電源線製作與接駁
  - 實作細節：依板上小電源座→SATA 15-pin 供電（見 Case #6）
  - 所需資源：接頭/導線/焊接工具
  - 預估時間：30-60 分
3. 磁碟初始化與檢查
  - 實作細節：於 OS 初始化/格式化/健康檢查
  - 所需資源：Windows 磁碟管理或 PowerShell
  - 預估時間：30 分

關鍵程式碼/設定：

# 初始化新磁碟（Windows）
Get-Disk | Where-Object PartitionStyle -Eq 'RAW' | Initialize-Disk -PartitionStyle GPT
Get-Disk | Where-Object PartitionStyle -Eq 'GPT' | New-Partition -UseMaximumSize -AssignDriveLetter | Format-Volume -FileSystem NTFS -NewFileSystemLabel "DATA"

實際案例：購買 NTD ~100 轉卡後成功接上 2.5” HDD。
實作環境：白牌迷你 PC（mSATA x2）、Windows。
實測數據：
- 改善前：SATA 口偵測成功率 0%
- 改善後：透過 mSATA→SATA 成功率 100%
- 改善幅度：從無法使用 → 正常使用，成本 ≈ NTD 100

Learning Points（學習要點）

核心知識點：mSATA/SATA 介面轉接、電源供應需求
技能要求：硬體安裝、線材製作、磁碟初始化
延伸思考：若雙 mSATA 皆可用，規劃 SSD（系統）+ HDD（資料）混搭

Practice Exercise（練習題）

基礎：辨識 mSATA 與 SATA 介面差異（30 分）
進階：實作磁碟初始化與檔案系統建立（2 小時）
專案：設計兩顆磁碟（SSD/HDD）分工與備份策略（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：轉接成功且磁碟可用
程式碼品質（30%）：初始化腳本正確
效能優化（20%）：合理分配系統/資料盤
創新性（10%）：提出冗餘/備援設計

Case #6: 缺件（SATA 電源線）導致無法上線：自製電源線快速復原

Problem Statement（問題陳述）

業務場景：賣家未附主機板專用→SATA 的電源線，導致 2.5” HDD 無法供電。
技術挑戰：接頭規格特殊（類顯卡風扇小接頭），市售不一定買得到；需自行製作。
影響範圍：設備無法上線、時程延誤。
複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：
1. 賣家漏寄
2. 接頭非標準 PC PSU 端子
3. 無白牌官方備件通路
深層原因：
- 架構層面：板載非標電源座
- 技術層面：5V/12V/GND 針腳需確認
- 流程層面：包裝/出貨檢核不足

Solution Design（解決方案設計）

解決策略：購買相容小接頭與 SATA 電源端子，自行壓接/焊接；依板子提供的針腳圖對應 5V/12V/GND，並用萬用表驗證。
實施步驟：
1. 查針腳定義與購料
  - 實作細節：比對網友分享/板絲印，確認供電腳位
  - 所需資源：小 2-pin/3-pin/4-pin 接頭、SATA 電源端子、萬用表
  - 預估時間：30 分
2. 製作與測試
  - 實作細節：壓接或焊接，量測 5V/12V 是否正確
  - 所需資源：壓接鉗/烙鐵/熱縮管
  - 預估時間：30-60 分
關鍵程式碼/設定： ```text SATA 電源 15-pin（簡化） Pins 1-3: 3.3V（多數 2.5” HDD/SSD 不用） Pins 4-6: GND Pins 7-9: 5V（2.5” 裝置主要用） Pins 10-12: GND Pins 13-15: 12V（3.5” HDD 常用）

注意：2.5” HDD/SSD 主要使用 5V；請務必確認主板小接頭輸出腿位與對應電壓！

- 實際案例：作者自行土炮電源線，十幾元材料即解法。
- 實作環境：白牌迷你 PC + 2.5" HDD。
- 實測數據：
  - 改善前：無法上線（缺電源線）
  - 改善後：可正常供電與開機
  - 改善幅度：以 NTD 10~30 元材料、1 小時內解決

Learning Points（學習要點）
- 核心知識點：SATA 供電腳位、安全驗證
- 技能要求：線材製作、萬用表量測
- 延伸思考：建立到貨清單與缺件處理 SOP

Practice Exercise（練習題）
- 基礎：畫出 SATA 15-pin 腳位與電壓（30 分）
- 進階：用萬用表驗證自製電源線（2 小時）
- 專案：撰寫收貨/缺件處理 SOP（8 小時）

Assessment Criteria（評估標準）
- 功能完整性（40%）：電源供應正確、安全
- 程式碼品質（30%）：文檔清楚（含腳位圖）
- 效能優化（20%）：作業時程縮短
- 創新性（10%）：材料與工法選擇創意


## Case #7: 白牌 BIOS 選項過多易磚機：最小變更與設定備份策略

### Problem Statement（問題陳述）
- 業務場景：AMI 公版 BIOS 提供大量未調教選項，易誤設造成開不了機，Clear CMOS 也未必有效。
- 技術挑戰：無官方說明/支援與 BIOS 更新，需避免/降低誤操作風險。
- 影響範圍：開機可用性、RMA 風險、時間成本。
- 複雜度評級：中

### Root Cause Analysis（根因分析）
- 直接原因：
  1. 公版 BIOS 全選項開放
  2. 使用者不熟悉專業項目
  3. 缺乏回滾/預設復原策略
- 深層原因：
  - 架構層面：缺少多重 BIOS/還原機制
  - 技術層面：無廠商最佳化/限制
  - 流程層面：未建立變更前紀錄與測試流程

### Solution Design（解決方案設計）
- 解決策略：遵循最小變更原則，只調整必要項（開機順序、啟用/停用裝置）；拍照備份所有頁面；能存檔則匯出設定檔；紀錄改變的鍵值。

- 實施步驟：
  1. 變更前備份
     - 實作細節：逐頁拍照、列清單
     - 所需資源：手機相機、雲端備份
     - 預估時間：30 分
  2. 漸進式修改與測試
     - 實作細節：每次改動 1~2 項，重開測試
     - 所需資源：筆記/變更紀錄
     - 預估時間：30~60 分
  3. 災難回復預案
     - 實作細節：準備另一顯示器/鍵盤、了解復位方式
     - 所需資源：備用 I/O 設備
     - 預估時間：30 分

- 關鍵程式碼/設定：
```text
建議只調整：
- Boot Order
- CSM/UEFI 切換（與安裝媒體格式一致）
- 關閉不用的控制器（若必要）
- 其他保持預設

實際案例：作者提醒有人改到開不了機且 Clear CMOS 無效。
實作環境：AMI BIOS 白牌主機板。
實測數據：
- 改善前：誤設風險高、不可回復
- 改善後：建立備份與最小變更流程
- 改善幅度：風險由不可控 → 可控且可追溯

Learning Points（學習要點）

核心知識點：BIOS 最小變更、設定備份與回復
技能要求：BIOS 操作、風險控管
延伸思考：是否準備 SPI 程式器以最後救援（進階用家）

Practice Exercise（練習題）

基礎：將你主機 BIOS 全頁拍照備份（30 分）
進階：調整 Boot Order 並復原（2 小時）
專案：撰寫 BIOS 變更控制 SOP（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：備份/復原可用
程式碼品質（30%）：SOP 條理清楚
效能優化（20%）：變更最小化
創新性（10%）：提出額外防呆（例如上鎖某些選項）

Case #8: 不明晶片驅動取得：以硬體 ID 檢索驅動，優先使用 OS 內建

Problem Statement（問題陳述）

業務場景：白牌主機板無明確晶片組資訊、無官方驅動網站；需確保網卡/無線卡/音效等驅動。
技術挑戰：快速識別裝置並找到適配驅動，避免系統不穩。
影響範圍：網路連線、音訊輸出、系統穩定。
複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：
1. 無官方驅動頁面
2. 晶片組資訊不透明
3. 使用者需自行檢索硬體 ID
深層原因：
- 架構層面：白牌供應鏈與文件不足
- 技術層面：裝置識別（VEN/DEV）能力要求
- 流程層面：安裝後才處理驅動，時間壓力大

Solution Design（解決方案設計）

解決策略：先讓 OS 自動安裝（Realtek LAN 與隨附 WiFi/BT 多可即時可用），對未知裝置以硬體 ID 搜尋驅動；保留驅動備份。
實施步驟：
1. 取得硬體 ID
  - 實作細節：裝置管理員→內容→詳細資料→硬體 ID
  - 所需資源：Windows、網路搜尋
  - 預估時間：15 分
2. 安裝與驗證
  - 實作細節：pnputil 安裝 INF，重開機驗證
  - 所需資源：驅動 INF 套件
  - 預估時間：30 分

關鍵程式碼/設定：

# 列出未知裝置與硬體 ID（Windows 10+）
Get-PnpDevice | Where-Object Status -ne "OK" | Format-Table -Auto
# 安裝驅動（指定 INF）
pnputil /add-driver C:\Drivers\YourDevice\*.inf /install

實際案例：Realtek LAN、隨機 WiFi/BT 安裝後即能驅動。
實作環境：Windows 10。
實測數據：
- 改善前：驅動來源不明
- 改善後：網卡/無線卡 OOBE 即用，未知裝置以硬體 ID 安裝
- 改善幅度：連線可用時間縮短至安裝完成即上線

Learning Points（學習要點）

核心知識點：硬體 ID 檢索、驅動安裝工具（pnputil）
技能要求：裝置驅動診斷與安裝
延伸思考：建立驅動離線包以便重灌時快速復原

Practice Exercise（練習題）

基礎：列出你機器的硬體 ID（30 分）
進階：為未知裝置安裝正確驅動（2 小時）
專案：打造通用驅動 USB 套件（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：未知裝置驅動可用
程式碼品質（30%）：指令與紀錄清楚
效能優化（20%）：縮短上線時間
創新性（10%）：自動化驅動安裝腳本

Case #9: HDMI 雙輸出僅一路含音訊：以正確連接與 SPDIF 恢復聲音

Problem Statement（問題陳述）

業務場景：機器有 HDMI x 2，但僅一個埠能輸出音訊，導致無聲。
技術挑戰：判斷哪一路支援 HDA 音訊，或改用其他音源輸出。
影響範圍：多媒體播放、桌面使用體驗。
複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：
1. 其中一路 HDMI 未接 HDA 音訊
2. 驅動/預設裝置選擇不正確
3. 線材/顯示器音訊能力不同
深層原因：
- 架構層面：主板設計受限、成本取捨
- 技術層面：音訊路徑只佈線到一路
- 流程層面：未做音訊輸出驗收

Solution Design（解決方案設計）

解決策略：測試兩個 HDMI 埠，確認具音訊者作為主輸出；必要時改用前面板 SPDIF；在 OS 設定預設播放裝置。
實施步驟：
1. 音訊路徑測試
  - 實作細節：兩埠輪流接同一顯示器/喇叭測試
  - 所需資源：HDMI 線、顯示器/喇叭
  - 預估時間：15 分
2. OS 設定
  - 實作細節：mmsys.cpl 設定預設播放裝置
  - 所需資源：Windows 控制台
  - 預估時間：10 分

關鍵程式碼/設定：

Windows：Win + R → mmsys.cpl → Playback
選擇 "Digital Audio (HDMI)" 或 "SPDIF" → 設為預設 → 測試音訊

實際案例：兩 HDMI 僅一個有音訊，改用有聲之埠或 SPDIF。
實作環境：白牌迷你 PC、Windows。
實測數據：
- 改善前：無音訊輸出
- 改善後：透過正確 HDMI 或 SPDIF 恢復音訊
- 改善幅度：音訊可用率由 0% → 100%

Learning Points（學習要點）

核心知識點：HDMI/HDA 音訊、SPDIF 切換
技能要求：連接測試、系統音訊設定
延伸思考：若作 HTPC，是否改採 USB DAC？

Practice Exercise（練習題）

基礎：測試兩個輸出埠音訊（30 分）
進階：設定自動切換預設播放裝置（2 小時）
專案：整合 HDMI/SPDIF/USB DAC 音訊方案（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：音訊正常輸出
程式碼品質（30%）：設定流程清楚
效能優化（20%）：切換迅速無故障
創新性（10%）：多音源整合體驗佳

Case #10: Realtek Giga LAN 非 Intel：以內建驅動快速上線

Problem Statement（問題陳述）

業務場景：偏好 Intel NIC，但實機為 Realtek；需確保連線穩定與快速上線。
技術挑戰：避免因驅動問題延誤上線，並確保基本吞吐。
影響範圍：網路穩定性、部署時程。
複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：
1. 成本考量採用 Realtek
2. 使用者期望 Intel
3. 需快速取得驅動
深層原因：
- 架構層面：白牌對成本敏感
- 技術層面：Realtek 在 Windows 下通常 OOBE 可用
- 流程層面：先上線後優化的策略

Solution Design（解決方案設計）

解決策略：使用 OS 內建或 Windows Update 取得 Realtek 驅動快速上線；進階再進行吞吐與穩定性測試。
實施步驟：
1. 驅動確認
  - 實作細節：裝置管理員檢查驅動狀態；Windows Update 更新
  - 所需資源：網路、Windows
  - 預估時間：10 分
2. 基本測試
  - 實作細節：內網傳輸測速（如 iperf3）
  - 所需資源：iperf3（選用）
  - 預估時間：30 分

關鍵程式碼/設定：

# iperf3 吞吐測試（Linux/WSL/Windows 可裝）
# Server 端
iperf3 -s
# Client 端（指向 Server IP）
iperf3 -c 192.168.1.10 -P 4 -t 30

實際案例：Realtek NIC 開箱即可用，省去安裝驅動時間。
實作環境：Windows 10。
實測數據：
- 改善前：擔心驅動延誤
- 改善後：即插即用，快速上線
- 改善幅度：上線時間縮至安裝完成當下

Learning Points（學習要點）

核心知識點：OOBE 驅動策略、基礎網路測試
技能要求：裝置管理員、基本網測
延伸思考：若需高負載/低延遲，是否加購 Intel NIC（USB 3.0/Thunderbolt/外接）？

Practice Exercise（練習題）

基礎：確認網卡驅動版本（30 分）
進階：透過 iperf3 測內網吞吐（2 小時）
專案：撰寫網卡選型與測試報告（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：網路連線與測試通過
程式碼品質（30%）：測試報告清楚
效能優化（20%）：吞吐穩定
創新性（10%）：提出 NIC 升級路線

Case #11: 無線網卡規格縮水：升級 Intel 7260 解鎖 802.11ac + BT 4.0

Problem Statement（問題陳述）

業務場景：賣家號稱 300M 無線卡，實得 Dell 1703（Atheros AR9004WB-1NG）僅 1T1R 150 Mbps；且原本不含 BT。
技術挑戰：低於預期的連線速率與功能，需一次到位的升級方案。
影響範圍：無線吞吐、藍牙周邊使用。
複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：
1. 規格宣稱與實物不符
2. 1T1R 僅 150 Mbps
3. 藍牙需加價才有
深層原因：
- 架構層面：成本導向的料件配比
- 技術層面：1T1R 與 2T2R/802.11ac 差異大
- 流程層面：收貨未驗證效能

Solution Design（解決方案設計）

解決策略：更換為 Intel Dual Band Wireless-AC 7260（含 BT 4.0），支援 802.11ac 與 2.4/5GHz。
實施步驟：
1. 拆換卡與安裝天線
  - 實作細節：mini-PCIe 插槽更換、天線接妥
  - 所需資源：Intel 7260、螺絲工具
  - 預估時間：30 分
2. 驅動安裝與測試
  - 實作細節：安裝 Intel 驅動，測速
  - 所需資源：廠商驅動、Speedtest/iperf3
  - 預估時間：30-60 分
關鍵程式碼/設定： ```text 測試建議：
2.4GHz vs 5GHz 各測 3 次
近距/隔間距離 2 種情境
藍牙連接穩定性測試（滑鼠/耳機） ```
實際案例：作者建議直接升到 Intel 7260，避免日後麻煩。
實作環境：白牌迷你 PC。
實測數據（理論值）：
- 改善前：1T1R 802.11n 150 Mbps
- 改善後：802.11ac（433/867 Mbps 視頻段/天線）
- 改善幅度：理論值約 2.9~5.8 倍

Learning Points（學習要點）

核心知識點：Wi-Fi MIMO、頻段與藍牙共存
技能要求：無線卡更換與驅動安裝
延伸思考：若做伺服器，是否以有線為主、Wi-Fi 作備援？

Practice Exercise（練習題）

基礎：辨識 1T1R/2T2R 與 802.11ac 差異（30 分）
進階：更換無線卡並完成測速（2 小時）
專案：撰寫無線升級效益報告（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：Wi-Fi/BT 正常且效能提升
程式碼品質（30%）：測試方法清楚
效能優化（20%）：吞吐改善明顯
創新性（10%）：干擾環境下的優化策略

Case #12: ES 工程版 CPU 風險：下單前溝通與收貨驗證流程

Problem Statement（問題陳述）

業務場景：白牌迷你 PC 可能使用 ES（Engineering Sample）CPU；使用者需正式零售版以求穩定。
技術挑戰：出廠不可替換（BGA 焊死）、需在下單與收貨時控風險。
影響範圍：穩定性、保固合規。
複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：
1. 賣家以 ES 充數壓價
2. 移動版 CPU 無法更換
3. 部分賣家以升級 CPU 補償
深層原因：
- 架構層面：成本壓力使 ES 流入市場
- 技術層面：ES 功能/頻率/微碼可能非最終版
- 流程層面：缺少驗收與退換條款

Solution Design（解決方案設計）

解決策略：下單前書面確認非 ES；收貨用 CPU-Z/HWiNFO 驗證標記與步進；若為 ES，依約退換或更換型號。
實施步驟：
1. 下單溝通與存檔
  - 實作細節：賣場聊天紀錄保留（非 ES 承諾）
  - 所需資源：平台 IM、截圖備存
  - 預估時間：15 分
2. 收貨驗證
  - 實作細節：啟動 CPU-Z 檢視是否標示 ES/QS；比對 ARK 規格
  - 所需資源：CPU-Z、Intel ARK
  - 預估時間：15 分

關鍵程式碼/設定：

# 基本 CPU 資訊（Windows）
wmic cpu get Name, ProcessorId, NumberOfCores, NumberOfLogicalProcessors
# 詳細仍以 CPU-Z/HWiNFO 驗證 ES/QS 標記

實際案例：作者事先與賣家溝通，請求非 ES 版本。
實作環境：白牌迷你 PC。
實測數據：
- 改善前：有機率收到 ES
- 改善後：透過事前承諾 + 收貨驗證降低風險
- 改善幅度：風險由不確定 → 可控

Learning Points（學習要點）

核心知識點：ES/QS/零售版差異、驗收流程
技能要求：規格比對、平台證據保存
延伸思考：若收到 ES，接受升級 CPU 是否划算？

Practice Exercise（練習題）

基礎：用 CPU-Z 讀出 CPU 與步進資訊（30 分）
進階：撰寫與賣家的承諾條款模板（2 小時）
專案：建立收貨驗證清單（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：驗收流程完備
程式碼品質（30%）：證據留存完善
效能優化（20%）：風險控制有效
創新性（10%）：談判策略與備案設計

Case #13: 白牌 QC 風險管控：從價格異常推導驗收重點

Problem Statement（問題陳述）

業務場景：整機售價約 USD 200，遠低於單顆新零售 CPU 標價（USD 315）；推測有 QC 淘汰料件流入，需加強驗收。
技術挑戰：以最少時間找出致命缺陷（SATA 埠故障、缺件、BIOS 問題）。
影響範圍：交付成功率、返工成本。
複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：
1. 價格異常低
2. 生產與出貨 QC 不足
3. 售後支援缺位
深層原因：
- 架構層面：以成本為導向的供應鏈
- 技術層面：料件來源複雜
- 流程層面：缺乏標準驗收 SOP

Solution Design（解決方案設計）

解決策略：制定 1 小時快速驗收清單，覆蓋 CPU/GPU 壓測、儲存/網路/影音/USB、SATA/mSATA/電源線件；發現問題立即土炮或退換。
實施步驟：
1. 快速驗收（T+0）
  - 實作細節：按清單逐項測，記錄問題
  - 所需資源：CPU-Z、HWiNFO、U 盤、喇叭、網線
  - 預估時間：1 小時
2. 修復決策
  - 實作細節：能土炮就修（轉卡/線材）、否則交涉退換
  - 所需資源：材料/轉卡、IM 溝通
  - 預估時間：視情況
關鍵程式碼/設定： ```text 1 小時驗收清單（示例）
開機：BIOS/Boot Menu（DEL/F11）
儲存：SATA/mSATA 偵測、磁碟初始化
網路：雙 LAN 連線
影音：HDMI*2 影像/音訊
USB：2.0/3.0 皆測
壓測：CPU 30 分鐘
配件：電源線/螺絲/天線 ```
實際案例：作者命中 SATA 埠失效與漏寄電源線兩大問題。
實作環境：白牌迷你 PC。
實測數據：
- 改善前：問題未知
- 改善後：在 T+0 迅速發現 2 項關鍵缺陷
- 改善幅度：降低後續返工時間/溝通成本

Learning Points（學習要點）

核心知識點：從異常價格逆推風險
技能要求：驗收測試設計與執行
延伸思考：是否建立 A/B 備援設備？

Practice Exercise（練習題）

基礎：寫出你會測的 10 項項目（30 分）
進階：完成 1 小時驗收並產出報告（2 小時）
專案：建立可重用的驗收流程與工具箱（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：驗收覆蓋率高
程式碼品質（30%）：報告清楚
效能優化（20%）：驗收耗時短
創新性（10%）：自動化驗收工具

Case #14: 安全付款顧慮：以玉山虛擬帳號串接支付寶

Problem Statement（問題陳述）

業務場景：不願將信用卡資訊或資金直接存入支付寶，需安全合規的付款方式。
技術挑戰：跨境付款流程要簡單可追溯。
影響範圍：資安風險、購物體驗。
複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：
1. 對對岸平台資安信任不足
2. 不願暴露卡號或預存資金
3. 需一次性、安全的支付渠道
深層原因：
- 架構層面：第三方代收代付方案
- 技術層面：虛擬帳號對應訂單
- 流程層面：付款與物流對帳需一致

Solution Design（解決方案設計）

解決策略：採用玉山銀行 × 支付寶方案，產生一次性虛擬帳號，匯台幣 + 手續費（NTD 60），完成支付。
實施步驟：
1. 選擇付款方式
  - 實作細節：下單後選玉山虛擬帳號
  - 所需資源：玉山/支付寶帳戶
  - 預估時間：10 分
2. 匯款與確認
  - 實作細節：網銀/臨櫃匯入，待平台回饋成功
  - 所需資源：網銀/ATM
  - 預估時間：10-30 分
關鍵程式碼/設定： ```text 付款備查要點：
保留虛擬帳號、金額、手續費、匯款證明
確認訂單狀態變更為「已付款」 ```
實際案例：作者使用玉山 × 支付寶，完成付款。
實作環境：淘寶平台。
實測數據：
- 改善前：資安疑慮
- 改善後：以虛擬帳號付款，手續費 NTD 60
- 改善幅度：資安風險下降、可追溯性提升

Learning Points（學習要點）

核心知識點：代收代付與虛擬帳號
技能要求：跨境付款流程
延伸思考：若金額較大，如何風險分散？

Practice Exercise（練習題）

基礎：畫出付款流程圖（30 分）
進階：彙整付款證憑清單（2 小時）
專案：建立跨境購物付款 SOP（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：付款流程順暢
程式碼品質（30%）：文件清晰
效能優化（20%）：處理時間短
創新性（10%）：風險緩解設計

Case #15: 跨境物流與可視化追蹤：順豐 2.5 天到貨實務

Problem Statement（問題陳述）

業務場景：跨境購物需掌握物流進度與成本，避免延宕。
技術挑戰：與平台整合、時效與費用掌控。
影響範圍：交付時程、使用者預期。
複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：
1. 跨境物流節點多
2. 追蹤資訊需即時
3. 重量級距影響運費
深層原因：
- 架構層面：平台與物流 API 整合程度
- 技術層面：追蹤號碼與狀態同步
- 流程層面：報關與航班時程

Solution Design（解決方案設計）

解決策略：選用順豐，享受與淘寶整合的即時追蹤；權衡重量與費用，>1KG 費用 RMB 60，2.5 天到貨。
實施步驟：
1. 選擇物流與估算
  - 實作細節：估重、計費級距、選最適方案
  - 所需資源：平台估價工具
  - 預估時間：15 分
2. 追蹤與收貨
  - 實作細節：APP/網站查詢物流節點
  - 所需資源：淘寶/順豐 APP
  - 預估時間：—（被動）
關鍵程式碼/設定： ```text 追蹤要點：
核對寄送地址/收件人
監看卡關（報關/航班）
預估到貨與收貨安排 ```
實際案例：順豐 2.5 天到貨，運費 RMB 60（>1KG 級距）。
實作環境：淘寶 × 順豐。
實測數據：
- 改善前：不確定時程與成本
- 改善後：2.5 天到貨、費用明確
- 改善幅度：預期可控、體驗提升

Learning Points（學習要點）

核心知識點：跨境物流級距與追蹤
技能要求：時程與成本預估
延伸思考：是否合併下單以最佳化運費？

Practice Exercise（練習題）

基礎：估算 3 種重量級距費用（30 分）
進階：用追蹤號分析運送節點（2 小時）
專案：制定跨境採購與收貨計畫（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：到貨與對帳一致
程式碼品質（30%）：文件完善
效能優化（20%）：費用/時程最佳化
創新性（10%）：風險預案（延遲/遺失）

Case #16: GPU 情境溫度風險：外掛 USB 風扇的臨時風冷備援

Problem Statement（問題陳述）

業務場景：部分用戶在 CPU+GPU 壓力下溫度可達 85°C 並觸發斷電；需簡易降溫備援。
技術挑戰：在無風扇設計下保障峰值負載安全。
影響範圍：穩定性、資料安全。
複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：
1. 被動散熱對 GPU 負載不友善
2. 機殼散熱能力逼近極限
3. 機櫃內部散熱不佳
深層原因：
- 架構層面：散熱設計未為 3D/遊戲情境優化
- 技術層面：導熱/對流受限
- 流程層面：未對峰值情境做壓測

Solution Design（解決方案設計）

解決策略：在需要 GPU 的情境外掛 USB 風扇直吹外殼散熱面，降低熱阻；或改採低 TDP 設定。
實施步驟：
1. 風扇選型與擺位
  - 實作細節：以外殼散熱面為主，確保進出風
  - 所需資源：USB 風扇
  - 預估時間：15 分
2. 驗證
  - 實作細節：GPU 壓測 + 溫度觀測
  - 所需資源：FurMark/HWiNFO
  - 預估時間：1 小時

關鍵程式碼/設定：

建議：僅在 GPU/3D 情境啟用外掛風扇；平時保持無風扇靜音優勢

實際案例：網友實測反饋「效果非常好」（未提供具體數據）。
實作環境：白牌迷你 PC。
實測數據：
- 改善前：高負載可至 85°C 並斷電（他人經驗）
- 改善後：外掛風扇可明顯降溫（定性）
- 改善幅度：由不穩定 → 穩定（視驗證結果）

Learning Points（學習要點）

核心知識點：被動散熱的峰值風險
技能要求：風扇擺位與降溫驗證
延伸思考：是否以軟體限制 GPU 功耗/頻率？

Practice Exercise（練習題）

基礎：選購並安裝 USB 風扇（30 分）
進階：GPU 壓測前後溫度比較（2 小時）
專案：制定峰值負載降溫策略（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：降溫可觀
程式碼品質（30%）：報告完整
效能優化（20%）：峰值不斷電
創新性（10%）：靜音與散熱兼顧

Case #17: 運用雙網口分離網段或簡易路由

Problem Statement（問題陳述）

業務場景：迷你伺服器具備雙 Giga LAN，可分離管理網與服務網，或作簡易路由/NAT。
技術挑戰：在不影響主機服務的情況下正確配置雙網口。
影響範圍：網路安全、性能隔離。
複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：
1. 單網口難以隔離管理/服務流量
2. 雙網口未配置則閒置
3. Windows 不內建 NIC Team（家庭版）
深層原因：
- 架構層面：網段分離可減少互相干擾
- 技術層面：路由/橋接/防火牆設定需求
- 流程層面：無標準配置 SOP

Solution Design（解決方案設計）

解決策略：在 Linux（建議）上配置雙網口，分別設定靜態 IP；視需求建立 bridge 或啟用 NAT。
實施步驟：
1. 基本雙網口設定（Ubuntu netplan）
  - 實作細節：分別賦予 192.168.10.0/24 與 192.168.20.0/24
  - 所需資源：Ubuntu Server
  - 預估時間：30 分
2. 啟用 NAT（選用）
  - 實作細節：iptables/nftables 與 IP 轉發
  - 所需資源：root 權限
  - 預估時間：30 分
關鍵程式碼/設定： ```yaml
/etc/netplan/01-lan.yaml

network: version: 2 ethernets: eno1: addresses: [192.168.10.2/24] gateway4: 192.168.10.1 nameservers: { addresses: [192.168.10.1, 8.8.8.8] } eno2: addresses: [192.168.20.2/24]

啟用 IPv4 轉發（/etc/sysctl.conf）

net.ipv4.ip_forward=1

NAT 例子（nftables）

nft add table ip nat nft ‘add chain ip nat postrouting { type nat hook postrouting priority 100 ; }’ nft add rule ip nat postrouting oif “eno1” masquerade

- 實際案例：設備具雙 LAN，適用於網段分離/簡易路由用途。
- 實作環境：白牌迷你 PC、Ubuntu（建議）。
- 實測數據：
  - 改善前：單網段，無隔離
  - 改善後：管理/服務網分離，或提供 NAT
  - 改善幅度：安全性與可管理性提升

Learning Points（學習要點）
- 核心知識點：雙網口配置、路由/NAT 基礎
- 技能要求：netplan、nftables/iptables
- 延伸思考：是否需要 VLAN/防火牆進一步加強？

Practice Exercise（練習題）
- 基礎：完成雙網口靜態 IP 設定（30 分）
- 進階：啟用 NAT 並通網（2 小時）
- 專案：設計內外網隔離方案（8 小時）

Assessment Criteria（評估標準）
- 功能完整性（40%）：雙網口/路由工作正常
- 程式碼品質（30%）：設定檔正確
- 效能優化（20%）：延遲/吞吐合理
- 創新性（10%）：安全強化設計


## Case #18: 延伸應用：四網口迷你機作 Router/NAT 的硬體選型

### Problem Statement（問題陳述）
- 業務場景：需要多埠網路設備做 Router/NAT（如軟路由），文章後記提供 4 x Intel 82583v LAN 的迷你 PC。
- 技術挑戰：挑選合適的多網口硬體並規劃安裝。
- 影響範圍：網路核心、家庭/小辦公網路結構。
- 複雜度評級：中

### Root Cause Analysis（根因分析）
- 直接原因：
  1. 商用路由器擴充不足
  2. 需要多埠直連/分段
  3. 軟路由靈活度高
- 深層原因：
  - 架構層面：集中化路由/防火牆
  - 技術層面：多 NIC 與硬體加速
  - 流程層面：部署/維運自負

### Solution Design（解決方案設計）
- 解決策略：採購 4x Intel 82583v 迷你 PC 作為 pfSense/OpenWrt 平台，建立 WAN/LAN/DMZ/IoT 分段。

- 實施步驟：
  1. 硬體挑選
     - 實作細節：確認 NIC 型號、CPU TDP、儲存
     - 所需資源：商品頁、評測
     - 預估時間：0.5 天
  2. 系統安裝與分段配置
     - 實作細節：pfSense 安裝、介面對應、NAT/防火牆
     - 所需資源：pfSense ISO、USB 安裝
     - 預估時間：0.5~1 天

- 關鍵程式碼/設定：
```text
pfSense 介面建議：
- WAN：PPPoE/DHCP
- LAN：192.168.10.0/24
- DMZ：192.168.20.0/24
- IoT：192.168.30.0/24
防火牆規則：LAN 允許出網；DMZ 僅允許必要端口；IoT 隔離 LAN

實際案例：文章後記提供該型號連結作參考。
實作環境：4x Intel 82583v 迷你 PC。
實測數據：
- 改善前：商用路由擴充受限
- 改善後：多埠分段靈活
- 改善幅度：可擴充性與掌控度大幅提升

Learning Points（學習要點）

核心知識點：軟路由硬體選型、pfSense 基礎
技能要求：安裝與介面分段
延伸思考：QoS、IDS/IPS（Suricata）與 VPN 加值

Practice Exercise（練習題）

基礎：畫出 4 網段拓撲（30 分）
進階：完成 pfSense 安裝與上網（2 小時）
專案：配置 DMZ 與 IoT 隔離策略（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：分段與上網正常
程式碼品質（30%）：規則清晰
效能優化（20%）：吞吐/延遲合理
創新性（10%）：加值功能整合（VPN/IDS）

案例分類 1) 按難度分類

入門級（適合初學者）：
- Case 4（USB 安裝）
- Case 6（缺件自製電源線）
- Case 9（HDMI 音訊）
- Case 10（Realtek 快速上線）
- Case 14（安全付款）
- Case 15（物流追蹤）
中級（需要一定基礎）：
- Case 1（NAS→迷你 PC + Docker）
- Case 2（無風扇溫控）
- Case 3（選型與性價比）
- Case 5（mSATA→SATA 轉接）
- Case 7（BIOS 風險控管）
- Case 8（驅動取得）
- Case 11（無線升級）
- Case 17（雙網口配置）
- Case 18（四網口軟路由）
高級（需要深厚經驗）：
- Case 12（ES CPU 風險控管）
- Case 13（QC 驗收體系）
- Case 16（GPU 峰值降溫策略）

2) 按技術領域分類

架構設計類：Case 1, 3, 17, 18
效能優化類：Case 2, 16
整合開發類：Case 4, 5, 6, 8, 11
除錯診斷類：Case 7, 9, 10, 12, 13
安全防護類：Case 14, 15（偏流程/資安/供應鏈）

3) 按學習目標分類

概念理解型：Case 2, 3, 12, 13, 16
技能練習型：Case 4, 5, 6, 8, 9, 10, 11
問題解決型：Case 1, 7, 14, 15, 17
創新應用型：Case 18（軟路由/多網段）

案例學習路徑建議

起步（基礎與流程保障）： 1) Case 14（安全付款）→ 2) Case 15（物流追蹤）→ 3) Case 3（選型與性價比）
收貨與風險控管： 4) Case 12（ES 風險）→ 5) Case 13（QC 驗收體系）
基礎開機與安裝： 6) Case 7（BIOS 最小變更）→ 7) Case 4（USB 安裝）→ 8) Case 8（驅動）
儲存與 I/O 修復： 9) Case 5（mSATA→SATA）→ 10) Case 6（電源線）
核心穩定性與功能： 11) Case 2（無風扇溫控）→ 12) Case 9（HDMI 音訊）→ 13) Case 10（Realtek 上線）→ 14) Case 11（無線升級）
網路與服務上線： 15) Case 17（雙網口）→ 16) Case 1（Docker 化服務）
進階/延伸： 17) Case 16（GPU 峰值降溫）→ 18) Case 18（四網口軟路由）

依賴關係說明：

先完成採購與驗收（Case 14, 15, 12, 13），再進入 BIOS/安裝/驅動（Case 7, 4, 8）。
儲存/電源問題（Case 5, 6）是上線前的硬件關卡。
溫控/音訊/網卡（Case 2, 9, 10, 11）屬於功能完善階段。
雙網口配置（Case 17）為 Docker 化服務（Case 1）的網路基礎。
GPU 降溫與軟路由（Case 16, 18）屬於進階與延伸應用。

[敗家] 對岸的迷你 PC (i5-5250U), 當自用 server 的好選擇

Case #1: 從 NAS 過渡到迷你 PC：以 i5-5250U 建立 Docker 自用伺服器

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

docker-compose.yml - WordPress + MariaDB（示意）

Case #3: NUC/ITX 規格與價格不符預期：以白牌迷你 PC 達成性價比

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #4: USB 3.0 安裝失敗：改用 USB 2.0 與正確開機鍵完成 Win10 部署

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #5: 主機板 SATA 口失靈：以 mSATA→SATA 轉卡 + DIY 電源線救援

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #6: 缺件（SATA 電源線）導致無法上線：自製電源線快速復原

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #8: 不明晶片驅動取得：以硬體 ID 檢索驅動，優先使用 OS 內建

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #9: HDMI 雙輸出僅一路含音訊：以正確連接與 SPDIF 恢復聲音

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #10: Realtek Giga LAN 非 Intel：以內建驅動快速上線

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #11: 無線網卡規格縮水：升級 Intel 7260 解鎖 802.11ac + BT 4.0

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #12: ES 工程版 CPU 風險：下單前溝通與收貨驗證流程

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #13: 白牌 QC 風險管控：從價格異常推導驗收重點

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #14: 安全付款顧慮：以玉山虛擬帳號串接支付寶

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #15: 跨境物流與可視化追蹤：順豐 2.5 天到貨實務

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #16: GPU 情境溫度風險：外掛 USB 風扇的臨時風冷備援

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #17: 運用雙網口分離網段或簡易路由

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

/etc/netplan/01-lan.yaml

啟用 IPv4 轉發（/etc/sysctl.conf）

NAT 例子（nftables）

Facebook Pages

AI Synthesis Contents

Edit Post (Pull Request)

Post Directory