以下內容根據原文逐一抽取、整理，並補充可落地的步驟與設定，形成 16 個具教學與實作價值的案例。每個案例都包含問題、根因、解法設計、實作與指標，便於課程、專案練習與評估。

Case #1: 三螢幕全數位輸出受限，改建專用 HTPC

Problem Statement（問題陳述）

業務場景：桌機已接兩台桌上型 LCD（皆為 DVI），客廳 SHARP LCD TV 僅提供 HDMI（不提供 D-Sub），希望同時在桌機雙螢幕工作並將 MCE 輸出到電視，維持全數位輸出品質。因顯示卡輸出腳位限制，原桌機難以兼顧三路數位輸出。 技術挑戰：一般中價位顯卡很難同時提供 2×DVI + 1×HDMI，或需兩張雙 DVI 顯卡，成本高、耗電高。 影響範圍：導致接線與切換操作複雜、畫面品質受限、成本上升，最終影響居家影音體驗與工作流程。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

1. 消費級顯示卡輸出腳位限制：單卡多為 2 輸出，滿足 3 路全數位輸出需多卡。
2. SHARP TV 僅 HDMI：不能退而求其次用 D-Sub，強化了對數位輸出的剛性需求。
3. 多螢幕窗口管理複雜：MCE 會在不同螢幕間跳出，影響使用體驗。 深層原因：
   • 架構層面：以單一桌機承擔工作站與 HTPC 雙角色，需求耦合度過高。
   • 技術層面：顯卡 I/O 規格與實際需求不匹配；多卡方案驅動與電源成本高。
   • 流程層面：頻繁在工作與娛樂模式間切換，操作步驟繁瑣且易錯。

Solution Design（解決方案設計）

解決策略：將影音播放責任自桌機解耦，改建一台專用 HTPC，選用整合度高且具 HDMI 的 AMD 780G 主機板，專線連 TV，桌機維持雙 DVI 工作流。以硬體分工消除三螢幕全數位的輸出瓶頸與操作複雜度。

實施步驟：

1. 平台選型與採購
   • 實作細節：選 ASUS M3A78-EM（AMD 780G, 內建 HDMI）、低功耗 CPU（AMD 4850e 45W）、2×2GB DDR2。
   • 所需資源：主機板、CPU、RAM、電源供應器、HTPC 機殼。
   • 預估時間：0.5 天（比對規格與採購）。
2. 硬體組裝與連接
   • 實作細節：HTPC HDMI 直連 TV；桌機維持雙 DVI；避免任何切換器。
   • 所需資源：3m HDMI 線。
   • 預估時間：0.5 天。
3. 系統安裝與 MCE 配置
   • 實作細節：安裝 Vista + MCE，設定音樂/相片/影片資料庫；綠鍵快速進入 MCE。
   • 所需資源：OS 授權、MCE 遙控器與接收器。
   • 預估時間：0.5 天。

關鍵程式碼/設定：

:: 在 HTPC 自動啟動 Media Center（開機即進客廳模式）
reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v MediaCenter /t REG_SZ /d "%SystemRoot%\ehome\ehshell.exe" /f

:: 建議將 HTPC 設為單一顯示輸出（TV 為主顯示）以避免視窗跑位
control desk.cpl

實際案例：作者由「桌機雙螢幕 + TV」的三數位輸出困境，改為建置專用 HTPC（780G + HDMI）直連 TV。 實作環境：ASUS M3A78-EM、AMD 4850e、DDR2 4GB、Seasonic 330W、Vista x64、Toshiba MCE 遙控器。 實測數據：

• 改善前：需升級主機板與雙顯卡才能滿足 2×DVI + HDMI，成本高且複雜。
• 改善後：以 780G 內顯 + HDMI 直連，總體成本控制在 1 萬 NTD 以內（扣除奢侈品）。
• 改善幅度：硬體複雜度下降（多卡→單板）；操作步驟由頻繁切換降至 0（專機模式）。

Learning Points（學習要點） 核心知識點：

• 需求解耦：以專用設備替代一機多用的耦合風險。
• I/O 規格對齊：輸出接口與顯示設備的匹配是第一性原則。
• 客廳使用者體驗優先於工作站彈性。

技能要求：

• 必備技能：PC 組裝、OS/MCE 基礎安裝。
• 進階技能：多螢幕/多設備連接規劃、使用情境設計。

延伸思考：

• 還可應用在會議室投影/看板專機化。
• 風險：多設備增加維護面；需網路/檔案同步策略。
• 優化：HTPC 開機即進 MCE、Wake-on-IR、資源共享自動掛載。

Practice Exercise（練習題）

• 基礎練習：列出你現有設備 I/O，畫出目標連接拓撲。（30 分鐘）
• 進階練習：實作 HTPC（單機），完成 HDMI 連接與 MCE 自動啟動。（2 小時）
• 專案練習：將原桌機從三輸出模式改為「桌機雙螢幕 + HTPC 專用 TV」，撰寫切換 SOP。（8 小時）

Assessment Criteria（評估標準）

• 功能完整性（40%）：HTPC 可穩定輸出至 TV；桌機雙螢幕正常。
• 程式碼品質（30%）：自動啟動/登入流程無干擾、可回滾。
• 效能優化（20%）：播放穩定、無掉格，啟動流程順暢。
• 創新性（10%）：連接拓撲與自動化設定有簡化創意。

Case #2: MCE 在多螢幕環境中常開錯螢幕

Problem Statement（問題陳述）

業務場景：在雙螢幕桌機臨時接 TV 的情境下，常發生 Media Center（MCE）視窗不是出現在想要的顯示器上，導致每次播放前都必須調整視窗位置或主螢幕設定，操作繁瑣。 技術挑戰：MCE 默認於主要顯示器全螢幕，或於最後使用顯示器啟動；多螢幕切換時常與使用者預期不一致。 影響範圍：降低客廳使用體驗、提高操作成本與出錯率。 複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

1. 主顯示器設定變更：Windows 多螢幕主螢幕切換導致 MCE 開啟位置不可預期。
2. 螢幕關閉/開啟時 EDID 變化：熱插拔造成顯示拓撲重建。
3. 用途衝突：工作與娛樂用途在同一台機器，配置相互干擾。 深層原因：
   • 架構層面：缺少「專機」思維，導致設定互相影響。
   • 技術層面：MCE 對顯示器首選綁定不夠細緻。
   • 流程層面：每次播放前需要人工檢查與調整。

Solution Design（解決方案設計）

解決策略：建立專用 HTPC 並以單顯示輸出（TV）運作，避免多螢幕爭奪。同時將 MCE 設為開機自啟與綠鍵啟動，確保始終出現在 TV。

實施步驟：

1. 設定唯一顯示輸出
   • 實作細節：HTPC 僅接 TV，設為主顯示；關閉螢幕鏡像/延伸。
   • 所需資源：HDMI 線。
   • 預估時間：15 分鐘。
2. 設定 Media Center 開機自啟
   • 實作細節：登出/開機即自動啟動 ehshell.exe。
   • 所需資源：Windows 登錄編輯權限。
   • 預估時間：10 分鐘。

關鍵程式碼/設定：

:: 將 Media Center 設為使用者登入即啟動
reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v MediaCenter /t REG_SZ /d "%SystemRoot%\ehome\ehshell.exe" /f

實際案例：作者最終體認「沒有專用機的話，HTPC 只能試爽」→ 改採專機後不再遇到 MCE 開錯螢幕問題。 實作環境：同 Case #1。 實測數據：

• 改善前：每次播放前需檢查/切換主螢幕或拖移視窗。
• 改善後：電源→綠鍵→直接進 MCE 全螢幕於 TV。
• 改善幅度：操作步驟由 3-5 步降為 0 步。

Learning Points（學習要點） 核心知識點：

• 單一用途機器可避免配置衝突。
• MCE 啟動位置與主螢幕的關係。
• 自動化啟動降低操作風險。

技能要求：

• 必備技能：顯示設定、開機項目設定。
• 進階技能：以腳本配置使用者登入體驗。

延伸思考：

• 多人家庭可建立「兒少模式」獨立帳號與啟動腳本。
• 風險：自啟程式過多影響啟動性能。
• 優化：結合 S3 睡眠縮短等待時間。

Practice Exercise（練習題）

• 基礎練習：在測試機上設定 ehshell.exe 自動啟動。（30 分鐘）
• 進階練習：建立一個「客廳帳號」專用開機配置檔。（2 小時）
• 專案練習：把原多螢幕配置拆分為「工作機 + HTPC」並撰寫 SOP。（8 小時）

Assessment Criteria（評估標準）

• 功能完整性（40%）：MCE 穩定於 TV 全螢幕開啟。
• 程式碼品質（30%）：登錄/啟動設定可逆、無副作用。
• 效能優化（20%）：啟動時間可控。
• 創新性（10%）：自動化與多帳號體驗設計。

Case #3: 以 780G 平台取代雙顯卡升級，平衡成本與功能

Problem Statement（問題陳述）

業務場景：要達成 2×DVI + 1×HDMI 的輸出需求，評估換「能插兩張顯卡的主機板 + 新顯卡」成本偏高；另找到 AMD 780G 內顯平台，具 HDMI，疑似更划算。 技術挑戰：在滿足輸出需求的同時，控制總體成本與耗電，避免超規格採購。 影響範圍：硬體採購成本、耗電、散熱與噪音。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

1. 雙顯卡方案成本高：主機板、顯卡、電源升級疊加。
2. HTPC 實際運算需求低：不需高階 3D 顯卡。
3. 內顯平台已足以解碼多媒體：780G 當年對 MPEG2/DivX 播放已足夠。 深層原因：
   • 架構層面：高配硬體與實際業務需求不匹配。
   • 技術層面：無法發揮高階顯卡潛能，屬效能過剩。
   • 流程層面：以「換更強」而非「換更合適」的思維選型。

Solution Design（解決方案設計）

解決策略：以 AMD 780G（ASUS M3A78-EM）為核心建 HTPC，滿足 HDMI 輸出與影音需求；保留桌機雙螢幕工作流，避免雙卡升級。

實施步驟：

1. 成本試算與 BOM
   • 實作細節：列出 780G 平台與雙卡方案 BOM，對齊輸出與播放需求。
   • 所需資源：價格/規格表。
   • 預估時間：2 小時。
2. 採購與安裝
   • 實作細節：依 BOM 組裝，確認 HDMI 與音訊輸出。
   • 所需資源：如 Case #1。
   • 預估時間：0.5 天。

關鍵程式碼/設定：

# 參考 BOM（重點零件）
motherboard: ASUS M3A78-EM  # AMD 780G, HDMI
cpu: AMD 4850e 45W
ram: DDR2-800 2GB x2
psu: Seasonic 330W
remote: Toshiba MCE Remote
hdmi_cable: 3m generic

實際案例：作者採購 M3A78-EM, 4850e, 2×2GB RAM、Seasonic 330W、MCE 遙控器。 實作環境：同上。 實測數據：

• 改善前：預期需雙卡 + 高階主機板，成本顯著。
• 改善後：扣除奢侈品，整體一萬元內搞定 HTPC。
• 改善幅度：整體採購支出下降（雙卡方案→內顯方案），並降低耗電與噪音潛在成本。

Learning Points（學習要點） 核心知識點：

• 用例導向的硬體選型。
• 內顯平台的影音能力評估。
• 成本/耗電/噪音的三角平衡。

技能要求：

• 必備技能：BOM 建立與比價。
• 進階技能：影音解碼負載評估與平台匹配。

延伸思考：

• 類似策略可套用到數位看板、KIOSK。
• 風險：未來 4K/H.265 升級需求。
• 優化：模組化升級路線（先平台、後外接 GPU）。

Practice Exercise（練習題）

• 基礎練習：為你的 HTPC 需求列出兩套 BOM 並比較。（30 分鐘）
• 進階練習：用 TCO（硬體+電耗）比較 3 年成本。（2 小時）
• 專案練習：撰寫你的 HTPC 選型決策報告。（8 小時）

Assessment Criteria（評估標準）

• 功能完整性（40%）：輸出與播放需求被滿足。
• 程式碼品質（30%）：BOM/估算文檔規範。
• 效能優化（20%）：耗電/噪音可控。
• 創新性（10%）：替代方案與風險控制。

Case #4: 低功耗平台建置與耗電優化（實測）

Problem Statement（問題陳述）

業務場景：客廳長時間待機與觀看影片，須兼顧省電與即時可用。希望維持良好畫質且耗電低。 技術挑戰：平衡性能與功耗，並在不同情境（開機、待機、播放、壓測）下維持合理功耗。 影響範圍：用電成本、溫度、噪音與環保。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

1. 高 TDP 元件待機/播放功耗高。
2. 顯卡獨顯空載/低負載效率差。
3. OS 電源計畫設定不當造成不必要耗電。 深層原因：
   • 架構層面：未以「影音工作負載」為核心設計硬體。
   • 技術層面：電源管理（睡眠、C-State、驅動）未最佳化。
   • 流程層面：長開機習慣而非睡眠喚醒模式。

Solution Design（解決方案設計）

解決策略：採低 TDP CPU（4850e 45W）+ 780G 內顯；善用 Vista 電源管理與 S3 睡眠；以遙控器喚醒/入睡；實測驗證不同場景功耗。

實施步驟：

1. 設定電源計畫
   • 實作細節：Balanced 或 Power Saver，關閉不必要高性能狀態。
   • 所需資源：Vista 電源設定。
   • 預估時間：15 分鐘。
2. 啟用 S3 睡眠與裝置喚醒
   • 實作細節：BIOS 設 S3、允許 IR 接收器喚醒。
   • 所需資源：BIOS、Device Manager。
   • 預估時間：30 分鐘。
3. 實測與校準
   • 實作細節：用瓦特計測不同情境耗電，調整風扇曲線。
   • 所需資源：功耗計。
   • 預估時間：1 小時。

關鍵程式碼/設定：

:: 查看可用睡眠狀態
powercfg -a

:: 允許紅外線接收器可喚醒（名稱依裝置而異）
powercfg -devicequery wake_armed
powercfg -deviceenablewake "Microsoft eHome Infrared Transceiver"

:: 設定關蓋/電源按鈕為睡眠（Desktop 可忽略關蓋）
control.exe powercfg.cpl

實際案例：作者量測耗電：開機 ~85W；進入 Vista 後 50-55W；播放 DVD/AVI 60-65W；壓測 75-80W；SLEEP 1-2W。 實作環境：同上。 實測數據：

• 改善前：未特別說明（假設傳統常開與較高耗電）。
• 改善後：播放 60-65W；Sleep 1-2W。
• 改善幅度：待機耗電大幅降低（常開→S3 1-2W）；播放耗電維持在 60-65W 合理區間。

Learning Points（學習要點） 核心知識點：

• 視頻播放負載下的功耗曲線。
• S3 與喚醒裝置配置。
• 電源計畫對 HTPC 的影響。

技能要求：

• 必備技能：BIOS/OS 電源配置。
• 進階技能：功耗測試與曲線調優。

延伸思考：

• 自動進入睡眠的閒置策略。
• 風險：某些裝置喚醒不穩定。
• 優化：關閉休眠檔案、調整 USB 省電。

Practice Exercise（練習題）

• 基礎練習：測量你電腦在開機/閒置/播放/睡眠的功耗。（30 分鐘）
• 進階練習：配置 IR 喚醒與 S3，驗證可靠性。（2 小時）
• 專案練習：撰寫 HTPC 功耗報告與優化建議。（8 小時）

Assessment Criteria（評估標準）

• 功能完整性（40%）：能穩定睡眠/喚醒。
• 程式碼品質（30%）：電源設定與紀錄清楚。
• 效能優化（20%）：播放與待機耗電下降。
• 創新性（10%）：自動化省電策略。

Case #5: 遙控器一鍵進入/喚醒 Media Center

Problem Statement（問題陳述）

業務場景：客廳操作不希望依賴鍵盤滑鼠，希望用遙控器開啟/關閉（睡眠）並直接進入 MCE 播放。 技術挑戰：確保遙控器與 IR 接收器即插即用、S3 喚醒穩定、綠鍵啟動體驗一致。 影響範圍：整體操作步驟與家人上手速度（WAF）。 複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

1. 鍵鼠不適合沙發場景。
2. 冷開機時間長、體驗不佳。
3. 非所有 TV 卡/IR 裝置都能喚醒主機。 深層原因：
   • 架構層面：人機介面未針對客廳最佳化。
   • 技術層面：電源管理與 IR 裝置喚醒未配置。
   • 流程層面：手動啟動 MCE 增加步驟。

Solution Design（解決方案設計）

解決策略：選用相容 Vista x64 的 MCE 遙控器（Toshiba），綠鍵直達 MCE；配置 IR 裝置可喚醒；以睡眠代替關機。

實施步驟：

1. 安裝 IR 接收器與遙控器
   • 實作細節：插上即用（Vista x64 原生驅動）。
   • 所需資源：MCE Remote。
   • 預估時間：5 分鐘。
2. 啟用 IR 喚醒與睡眠策略
   • 實作細節：啟用 S3、允許裝置喚醒。
   • 所需資源：如 Case #4。
   • 預估時間：30 分鐘。

關鍵程式碼/設定：

:: 檢查 IR 是否已列為可喚醒裝置
powercfg -devicequery wake_armed

:: 若未列出，啟用之
powercfg -deviceenablewake "Microsoft eHome Infrared Transceiver"

實際案例：作者使用 Toshiba MCE 遙控器，Vista x64 免驅動，綠鍵喚出 MCE，電源鍵控制睡眠與喚醒。 實作環境：同上。 實測數據：

• 改善前：需鍵鼠操作、冷開機等待。
• 改善後：遙控器一鍵喚醒與睡眠。
• 改善幅度：操作步驟縮減（多步→單鍵）；待機功耗 1-2W。

Learning Points（學習要點） 核心知識點：

• eHome IR 與 MCE 的整合。
• 綠鍵對應 ehshell。
• 喚醒裝置清單（wake_armed）。

技能要求：

• 必備技能：裝置管理與電源設定。
• 進階技能：疑難排解喚醒不穩。

延伸思考：

• 可加上「自動鎖定/登出」提高安全。
• 風險：USB 供電不足導致喚醒失敗。
• 優化：使用帶電源的 USB Hub。

Practice Exercise（練習題）

• 基礎練習：讓你的遙控器能喚醒/睡眠 PC。（30 分鐘）
• 進階練習：建立腳本，睡眠/喚醒後自動進 MCE。（2 小時）
• 專案練習：評估不同 IR 接收器喚醒穩定性。（8 小時）

Assessment Criteria（評估標準）

• 功能完整性（40%）：遙控睡眠/喚醒穩定。
• 程式碼品質（30%）：設定可重現。
• 效能優化（20%）：喚醒後即時可用。
• 創新性（10%）：附加自動化。

Case #6: Vista x64 與 MCE 遙控器免驅動相容驗證

Problem Statement（問題陳述）

業務場景：期待插上遙控器 IR 接收器即用，避免尋找第三方驅動並減少相容風險。 技術挑戰：在 Vista x64 環境下，確認 IR 裝置自動辨識與鍵碼對應正確。 影響範圍：部署效率與穩定性。 複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

1. 某些非標準遙控器需額外驅動與設定。
2. x64 驅動簽章要求較嚴格。
3. 相容性不佳導致鍵碼錯亂或無法喚醒。 深層原因：
   • 架構層面：周邊選型未優先考慮原生支援。
   • 技術層面：驅動簽章與 HID 相容性。
   • 流程層面：部署前缺乏相容性檢查清單。

Solution Design（解決方案設計）

解決策略：選用知名廠牌且相容 MCE 的遙控器（Toshiba），使用 Windows 原生驅動，免安裝，降低相容風險。

實施步驟：

1. 插入 IR 接收器
   • 實作細節：確認系統自動安裝「Microsoft eHome Infrared Transceiver」。
   • 所需資源：Toshiba MCE 遙控器。
   • 預估時間：5 分鐘。
2. 驗證鍵碼與綠鍵
   • 實作細節：按綠鍵能喚出 MCE；測常用播放/返回/方向鍵。
   • 所需資源：MCE。
   • 預估時間：10 分鐘。

關鍵程式碼/設定：

:: 驗證裝置是否正確安裝為 eHome IR
devmgmt.msc
:: 在 裝置管理員 > 人性化介面裝置(HID) / 紅外線裝置，檢查 "Microsoft eHome Infrared Transceiver"

實際案例：作者回報「接收器插上去就可以用，什麼 DRIVER 設定都免了，VISTA X64 也一切正常」。 實作環境：Vista x64。 實測數據：

• 改善前：可能需尋找/安裝驅動。
• 改善後：免驅動、即插即用。
• 改善幅度：部署時間由數十分鐘降為數分鐘；失敗率顯著下降。

Learning Points（學習要點） 核心知識點：

• eHome IR 原生驅動的優勢。
• x64 驅動簽章風險。
• 驗證流程應簡短可重現。

技能要求：

• 必備技能：裝置管理基本操作。
• 進階技能：疑難排解驅動與 HID 鍵碼。

延伸思考：

• 選型時優先原生支援的外設。
• 風險：山寨裝置識別不正確。
• 優化：建立可複用的驗收清單。

Practice Exercise（練習題）

• 基礎練習：在測試機上接上 IR，完成綠鍵驗證。（30 分鐘）
• 進階練習：測試不同品牌遙控器的相容性。（2 小時）
• 專案練習：撰寫「HTPC 外設相容性白名單」。（8 小時）

Assessment Criteria（評估標準）

• 功能完整性（40%）：免驅動成功。
• 程式碼品質（30%）：驗收步驟可重現。
• 效能優化（20%）：導入時間縮短。
• 創新性（10%）：清單化與風險控管。

Case #7: 用 MCE 取代 WMP/相片檢視，實現「全遙控」操作

Problem Statement（問題陳述）

業務場景：原本播放 MP3 用 Windows Media Player、看相片用 Windows Live Photo Gallery；希望在客廳只靠遙控器完成所有多媒體操作。 技術挑戰：整合媒體庫，確保以遙控器流暢操作音樂、相片與影片。 影響範圍：家庭成員學習成本、操作一致性。 複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

1. 多應用程式造成操作界面不一致。
2. WMP/相片應用對遙控器操作不如 MCE 友好。
3. 媒體庫分散。 深層原因：
   • 架構層面：缺少「單一入口」的媒體平台。
   • 技術層面：資料夾未統一索引到 MCE。
   • 流程層面：切換應用造成步驟與心智負擔。

Solution Design（解決方案設計）

解決策略：將音樂、相片、影片資料夾統一加入 MCE 媒體庫，以 MCE 作為唯一入口，全部改用遙控器操作。

實施步驟：

1. 建立媒體資料夾與命名規範
   • 實作細節：Music/Photos/Videos 各自分類。
   • 所需資源：檔案系統。
   • 預估時間：30 分鐘。
2. 將資料夾加入 MCE 庫
   • 實作細節：MCE 設定 > 資料庫 > 新增資料夾。
   • 所需資源：MCE。
   • 預估時間：15 分鐘。

關鍵程式碼/設定：

# 範例：將網路路徑掛載為磁碟機供 MCE 索引（若媒體在他機）
net use Z: \\MediaServer\Media /persistent:yes

# 之後在 MCE 中把 Z: 下的 Music/Photos/Videos 加入媒體庫

實際案例：作者「連放 MP3 與放照片也都改用 MCE 了」。 實作環境：Vista MCE。 實測數據：

• 改善前：需在多應用間切換，鍵鼠操作。
• 改善後：單一入口（MCE） + 遙控器操作。
• 改善幅度：應用切換步驟趨近 0；學習曲線變平。

Learning Points（學習要點） 核心知識點：

• 媒體庫一體化。
• 遙控器導向的 UX 設計。
• 網路掛載與資料夾索引。

技能要求：

• 必備技能：MCE 基本設定。
• 進階技能：網路共享與路徑規劃。

延伸思考：

• 加入 DLNA/UPnP 伺服或 NAS。
• 風險：索引延遲或縮圖快取占用。
• 優化：定期清理與重建索引。

Practice Exercise（練習題）

• 基礎練習：把本機媒體加入 MCE 庫並以遙控器操作。（30 分鐘）
• 進階練習：掛載網路資料夾到 MCE。（2 小時）
• 專案練習：設計家庭媒體命名與分類規範。（8 小時）

Assessment Criteria（評估標準）

• 功能完整性（40%）：MCE 完整讀取並播放。
• 程式碼品質（30%）：共享與掛載設定清楚。
• 效能優化（20%）：瀏覽與播放順暢。
• 創新性（10%）：資訊架構設計。

Case #8: S3 睡眠取代關機，體驗與耗電雙優化

Problem Statement（問題陳述）

業務場景：客廳設備需要「隨按即用」，但冷開機耗時；同時希望待機功耗極低。 技術挑戰：在待機功耗與喚醒速度間取得平衡，並確保穩定性。 影響範圍：體驗、用電與設備壽命。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

1. 冷開機等待長且影響觀影情緒。
2. 部分 TV 卡支援硬喚醒但仍需完全關機/開機。
3. 常開機耗電無謂。 深層原因：
   • 架構層面：未善用睡眠狀態。
   • 技術層面：喚醒事件與 USB 省電未設定。
   • 流程層面：操作預設為關機而非睡眠。

Solution Design（解決方案設計）

解決策略：將電源鍵/遙控器電源鍵對應為 S3；允許 IR 裝置喚醒；關閉螢幕即睡眠；以睡眠替代關機。

實施步驟：

1. 電源鍵對應變更
   • 實作細節：將電源鍵動作設為睡眠。
   • 所需資源：電源選項。
   • 預估時間：10 分鐘。
2. 驗證睡眠耗電
   • 實作細節：用瓦特計驗證 1-2W。
   • 所需資源：功耗計。
   • 預估時間：20 分鐘。

關鍵程式碼/設定：

:: 設定目前電源方案 GUID
powercfg -getactivescheme

:: 將按電源按鈕的動作設為睡眠（需透過 GUI 設定最穩妥）
control.exe powercfg.cpl

實際案例：作者以遙控器電源鍵控制 SLEEP/喚醒，並量測 SLEEP 僅 1-2W。 實作環境：同上。 實測數據：

• 改善前：關機/開機等待久。
• 改善後：睡眠喚醒即用，待機功耗 1-2W。
• 改善幅度：待機耗電顯著下降；可用性大幅提升。

Learning Points（學習要點） 核心知識點：

• ACPI S3 特性。
• 喚醒事件配置。
• 功耗測試方法。

技能要求：

• 必備技能：電源設定。
• 進階技能：喚醒疑難排解。

延伸思考：

• 設定自動睡眠閒置時間。
• 風險：某些驅動不支援 S3 穩定。
• 優化：更新晶片組/顯示驅動。

Practice Exercise（練習題）

• 基礎練習：設定 S3 並完成喚醒測試。（30 分鐘）
• 進階練習：多次睡眠/喚醒循環測試與日誌。（2 小時）
• 專案練習：制定家庭睡眠策略與教育手冊。（8 小時）

Assessment Criteria（評估標準）

• 功能完整性（40%）：睡眠/喚醒穩定。
• 程式碼品質（30%）：設定文件完整。
• 效能優化（20%）：功耗達標。
• 創新性（10%）：自動化腳本或排程。

Case #9: Windows SideShow + WM5/WM6 手機變身 MCE 遙控器

Problem Statement（問題陳述）

業務場景：希望在不打斷大螢幕播放的情況下，於手機上查看節目表、目前播放曲目並操作 MCE。 技術挑戰：在 Vista 上啟用 SideShow、安裝 MCE Gadget、透過藍牙連結 WM5/WM6 手機，確保延遲低且穩定。 影響範圍：操作便捷度與多人觀影時的體驗。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

1. 傳統遙控器無螢幕，無法顯示 EPG/播放資訊。
2. 開啟 OSD 會中斷影片觀感。
3. 不想打開 TV 時也要能操作。 深層原因：
   • 架構層面：遙控器資訊通道為單向。
   • 技術層面：未啟用 SideShow 裝置與 Gadget 整合。
   • 流程層面：需要跨裝置的控制與顯示。

Solution Design（解決方案設計）

解決策略：安裝 Microsoft Windows SideShow for Windows Mobile（Preview）與 SlideShow Gadget for MCE（Beta），配對 WM5/WM6 手機為 SideShow 裝置，並透過藍牙控制 MCE。

實施步驟：

1. 安裝 SideShow 行動端與 MCE Gadget
   • 實作細節：依官方連結安裝；在 Vista 啟用 SideShow。
   • 所需資源：WM5/WM6 手機、藍牙。
   • 預估時間：1 小時。
2. 藍牙配對與授權
   • 實作細節：將手機加入 SideShow 裝置清單；測試 EPG 與 Now Playing 顯示。
   • 所需資源：bthserv。
   • 預估時間：30 分鐘。

關鍵程式碼/設定：

:: 開啟 SideShow 設定面板（Vista）
control.exe /name Microsoft.WindowsSideshow

:: 藍牙配對
bthprops.cpl  :: 開啟藍牙設定，新增裝置並允許服務

實際案例：作者成功以 WM5/WM6 手機做為 SideShow 裝置，顯示節目表與播放資訊，並控制 MCE。 實作環境：Vista、WM5/WM6。 實測數據：

• 改善前：資訊回饋為 0（無螢幕遙控）。
• 改善後：手機顯示 EPG/播放資訊，避免打斷播放。
• 改善幅度：資訊可得性從無到有；操作靈活性大幅提升。

Learning Points（學習要點） 核心知識點：

• Windows SideShow 架構。
• 藍牙服務與配對。
• MCE Gadget 的能力邊界。

技能要求：

• 必備技能：藍牙配對、服務授權。
• 進階技能：SideShow Gadget 安裝與疑難排解。

延伸思考：

• 可擴展至 Wi-Fi 遙控（後期方案）。
• 風險：SideShow 為 Preview/Beta，穩定性風險。
• 優化：固定藍牙通道、確保自動重連。

Practice Exercise（練習題）

• 基礎練習：完成一次手機配對並顯示 Now Playing。（30 分鐘）
• 進階練習：測試 EPG 瀏覽與播放控制。（2 小時）
• 專案練習：撰寫 SideShow 部署與回退方案。（8 小時）

Assessment Criteria（評估標準）

• 功能完整性（40%）：EPG/控制可用。
• 程式碼品質（30%）：設定文件清晰。
• 效能優化（20%）：延遲/連線穩定。
• 創新性（10%）：多裝置協作設計。

Case #10: 不開電視也能聽音樂：用 SideShow 手機選曲播放

Problem Statement（問題陳述）

業務場景：想在不開 TV 的情況下於客廳聽音樂，包含瀏覽專輯、播放與切歌。 技術挑戰：傳統遙控器無螢幕，無法瀏覽媒體庫；需要第二顯示通道。 影響範圍：用電、便利性與生活品質。 複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

1. 遙控器無法顯示媒體庫。
2. 開 TV 只為找歌浪費電力與時間。 深層原因：
   • 架構層面：單一顯示（TV）綁定控制流程。
   • 技術層面：未利用 SideShow 的離屏控制能力。
   • 流程層面：找歌→開 TV→選歌→關 TV 步驟繁瑣。

Solution Design（解決方案設計）

解決策略：以 SideShow 手機直接瀏覽 MCE 資料庫並播放，讓音樂播放不依賴 TV 顯示。

實施步驟：

1. 部署 SideShow（承 Case #9）
   • 實作細節：確保媒體庫可在手機 Gadget 顯示。
   • 所需資源：WM 手機。
   • 預估時間：30 分鐘。
2. 建立音樂清單以利行動瀏覽
   • 實作細節：以專輯/播放清單組織，減少手機端查找時間。
   • 所需資源：MCE/WMP。
   • 預估時間：30 分鐘。

關鍵程式碼/設定：

:: 若將音樂放於網路路徑，開機自動掛載
net use M: \\NAS\Music /persistent:yes

實際案例：作者透過手機選好專輯後播放，客廳即有音樂，強調「這是純遙控器辦不到的」。 實作環境：同上。 實測數據：

• 改善前：需開 TV 找歌，步驟多且耗電。
• 改善後：不開 TV 直接在手機選曲播放。
• 改善幅度：用電下降（省去 TV 功耗）；操作步驟明顯減少。

Learning Points（學習要點） 核心知識點：

• 離屏控制（Off-screen control）。
• 播放清單與資訊架構的重要性。
• 行動裝置作為第二顯示。

技能要求：

• 必備技能：SideShow 使用。
• 進階技能：媒體庫整理與清單化。

延伸思考：

• 可擴展至智慧音箱/語音控制。
• 風險：藍牙連線品質。
• 優化：Wi-Fi 遙控與快取封面圖。

Practice Exercise（練習題）

• 基礎練習：建立 3 個播放清單並用手機播放。（30 分鐘）
• 進階練習：無 TV 狀態下完成選曲播放流程錄影。（2 小時）
• 專案練習：設計你的「關燈音樂模式」自動流程。（8 小時）

Assessment Criteria（評估標準）

• 功能完整性（40%）：無 TV 仍可完整播放。
• 程式碼品質（30%）：掛載與資料庫設定齊全。
• 效能優化（20%）：切歌流暢、延遲低。
• 創新性（10%）：情境自動化。

Case #11: 合併遙控需求的成本策略：便宜遙控 + 手機 > 高價整合遙控

Problem Statement（問題陳述）

業務場景：市場上有支援 SideShow 的 MCE 整合遙控器（約 USD 199），但成本過高；希望以更低成本達成等效體驗。 技術挑戰：在成本、功能與穩定間平衡。 影響範圍：採購預算、使用體驗。 複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

1. 整合型遙控器價格高。
2. 使用頻率高的功能其實可拆分（實體按鍵 + 行動顯示）。 深層原因：
   • 架構層面：單一裝置承載所有需求的思維。
   • 技術層面：SideShow 可由手機承擔顯示層。
   • 流程層面：需求拆分可降低成本。

Solution Design（解決方案設計）

解決策略：採用便宜的 MCE 遙控器（NTD 550）負責常用控制 + 手機承擔 SideShow 顯示與精細操作，避免購買 USD 199 的整合遙控。

實施步驟：

1. 遙控器部署
   • 實作細節：見 Case #5/#6。
   • 所需資源：MCE 遙控器。
   • 預估時間：30 分鐘。
2. 手機 SideShow 部署
   • 實作細節：見 Case #9。
   • 所需資源：WM 手機。
   • 預估時間：1 小時。

關鍵程式碼/設定：

成本對比（概念）：
- 整合遙控：USD 199
- 便宜遙控 + 現有手機：NTD 550 + 既有資產（藍芽接收器約百元）

實際案例：作者評估後選擇便宜遙控 + 手機，表示「十分之一不到的成本」即可達成。 實作環境：同上。 實測數據：

• 改善前：若購買整合遙控，單品成本 USD 199。
• 改善後：遙控 NTD 550 + 既有手機 + 藍牙接收器約百元。
• 改善幅度：成本下降約一個數量級。

Learning Points（學習要點） 核心知識點：

• 功能拆分的成本效益。
• 以現有資產補位新需求。
• UX 與成本的平衡。

技能要求：

• 必備技能：需求分析。
• 進階技能：總持有成本（TCO）評估。

延伸思考：

• 是否需要紅外線學習型遙控整合音響/TV。
• 風險：多裝置協同時延遲或連線風險。
• 優化：統一充電與收納。

Practice Exercise（練習題）

• 基礎練習：列出你的遙控需求並拆分。（30 分鐘）
• 進階練習：做一份成本比較表。（2 小時）
• 專案練習：撰寫採購建議書與風險對策。（8 小時）

Assessment Criteria（評估標準）

• 功能完整性（40%）：達到原需求。
• 程式碼品質（30%）：成本計算清楚。
• 效能優化（20%）：體驗不打折。
• 創新性（10%）：資產重用策略。

Case #12: 避免重複買 TV 卡：共享錄影內容滿足 HTPC

Problem Statement（問題陳述）

業務場景：家裡其他桌機已有 MCE + TV 卡，客廳不常看 Live TV；希望不買第 3 張 TV 卡。 技術挑戰：在客廳播放已錄節目，並統一出現在 HTPC 的媒體庫中。 影響範圍：硬體成本、網路與存取體驗。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

1. Live TV 使用頻率低。
2. 已有錄影資源可用。
3. 第三張 TV 卡邊際效益低、成本高。 深層原因：
   • 架構層面：分散式錄影集中播放。
   • 技術層面：檔案共享與索引。
   • 流程層面：錄影→分享→播放流程未標準化。

Solution Design（解決方案設計）

解決策略：將有 TV 卡的桌機設定共享「Recorded TV」資料夾，HTPC 以網路磁碟掛載並加入 MCE 媒體庫，以共享錄影滿足 HTPC 播放需求。

實施步驟：

1. 設定來源端分享
   • 實作細節：在錄影主機分享 Recorded TV，給出唯讀權限。
   • 所需資源：Windows 檔案分享。
   • 預估時間：20 分鐘。
2. HTPC 掛載與加入媒體庫
   • 實作細節：將共享路徑映射成磁碟機，MCE 加入影片資料夾。
   • 所需資源：網路存取憑證。
   • 預估時間：20 分鐘。

關鍵程式碼/設定：

:: 來源端（含 TV 卡）分享 Recorded TV
:: 右鍵資料夾 > 內容 > 共享 > 指定使用者（唯讀）

:: HTPC 端開機自動掛載
net use R: \\RECORDER-PC\RecordedTV /user:domain\user P@ssw0rd /persistent:yes

實際案例：作者明確決定不買 TV 卡，因已在其他桌機錄影，HTPC 主要播放。 實作環境：多台 Windows + MCE。 實測數據：

• 改善前：需再購一張 TV 卡（成本/安裝/設定）。
• 改善後：以共享方式播放已錄節目。
• 改善幅度：硬體成本直接節省；維護複雜度降低。

Learning Points（學習要點） 核心知識點：

• 分散式錄影集中播放。
• 檔案共享與認證。
• 媒體庫跨機維護。

技能要求：

• 必備技能：Windows 檔案分享。
• 進階技能：權限控管與網路穩定性調整。

延伸思考：

• 若要看 Live TV，可用網路 Tuner 或 IPTV。
• 風險：網路不穩影響播放。
• 優化：有線網路或 QoS。

Practice Exercise（練習題）

• 基礎練習：共享資料夾並在 HTPC 播放。（30 分鐘）
• 進階練習：設定自動掛載與失敗重試腳本。（2 小時）
• 專案練習：設計家庭錄影/播放拓撲與權限。（8 小時）

Assessment Criteria（評估標準）

• 功能完整性（40%）：已錄節目可流暢播放。
• 程式碼品質（30%）：掛載與權限設定文件化。
• 效能優化（20%）：網路播放穩定。
• 創新性（10%）：整體流程設計。

Case #13: HDMI 線材性價比：便宜線也能穩定 1080p

Problem Statement（問題陳述）

業務場景：需要 3m HDMI 線連接 HTPC 與 TV；市面線材價差大，擔心便宜線不穩。 技術挑戰：在不犧牲畫質與穩定前提下降低成本。 影響範圍：採購成本與安裝。 複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

1. HDMI 為數位傳輸，短距離對線材要求相對寬鬆。
2. 高價線多為行銷加值，不一定反映實際體驗。 深層原因：
   • 架構層面：布線長度與干擾環境。
   • 技術層面：HDMI 訊號完整性 vs 距離。
   • 流程層面：過度規格化採購。

Solution Design（解決方案設計）

解決策略：選購便宜 3m HDMI 線，實測在 1080p 環境下穩定運作；不足時再替換升級，先求足夠。

實施步驟：

1. 試用策略
   • 實作細節：先購買平價線實測，確認無雪花/黑屏/音訊中斷。
   • 所需資源：HDMI 線、測試片源。
   • 預估時間：30 分鐘。
2. 問題排除
   • 實作細節：若有畫面裁切/過掃，調整 TV/顯示卡設定。
   • 所需資源：顯示設定面板（Catalyst/TV 菜單）。
   • 預估時間：30 分鐘。

關鍵程式碼/設定：

檢查事項：
- 顯示解析度：1920x1080 @ 60Hz
- TV 設定：關閉 overscan 或在顯卡端調整縮放

實際案例：作者使用 NTD 130 的 3m HDMI 線，實際可用。 實作環境：HTPC HDMI 直連 TV。 實測數據：

• 改善前：預期需購買高價線。
• 改善後：平價線可用，成本 NTD 130。
• 改善幅度：線材成本顯著下降。

Learning Points（學習要點） 核心知識點：

• HDMI 的數位傳輸特性。
• Overscan/Underscan 調校。
• 試用後升級的採購策略。

技能要求：

• 必備技能：顯示設定。
• 進階技能：訊號穩定性評估。

延伸思考：

• 長距離或高頻寬（4K/HDR）再評估線材等級。
• 風險：品質參差導致偶發問題。
• 優化：備用線材與標記。

Practice Exercise（練習題）

• 基礎練習：用平價 HDMI 線完成 1080p 連線測試。（30 分鐘）
• 進階練習：校正 overscan，記錄前後畫面。（2 小時）
• 專案練習：撰寫家庭 HDMI 佈線與標準。（8 小時）

Assessment Criteria（評估標準）

• 功能完整性（40%）：穩定輸出 1080p。
• 程式碼品質（30%）：設定記錄清楚。
• 效能優化（20%）：畫面完整無裁切。
• 創新性（10%）：採購策略與風險控管。

Case #14: TV 僅 HDMI 的介面限制與相容配置

Problem Statement（問題陳述）

業務場景：SHARP TV 不提供 D-Sub，僅有 HDMI 或色差；要求 HTPC 提供數位輸出相容。 技術挑戰：確保顯示輸出與音訊路徑在 HDMI 上工作正常。 影響範圍：接線、音畫同步、相容性。 複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

1. TV 介面限制（無類比）。
2. 桌機原本 DVI 難以直達 HDMI（需轉接器/音訊另接）。 深層原因：
   • 架構層面：設備介面不對齊。
   • 技術層面：聲畫整合在 HDMI 的需求。
   • 流程層面：轉接器帶來複雜度。

Solution Design（解決方案設計）

解決策略：選擇內建 HDMI 的 780G 主機板，HTPC 直接以 HDMI 連接 TV，確保數位輸入與音訊傳輸。

實施步驟：

1. HDMI 直連與 TV 設定
   • 實作細節：選擇正確 HDMI 端子（有些 TV 僅特定端子支援 PC 模式）。
   • 所需資源：HDMI 線。
   • 預估時間：20 分鐘。
2. 聲音輸出檢查
   • 實作細節：檢查音效裝置選擇 HDMI 裝置（若支援）。
   • 所需資源：音效驅動。
   • 預估時間：10 分鐘。

關鍵程式碼/設定：

控制台 > 聲音 > 播放 > 設定 HDMI 裝置為預設（若主機板/驅動支援 HDMI Audio）

實際案例：作者強調 TV 僅 HDMI，改採 780G HDMI 直連。 實作環境：HTPC + SHARP TV。 實測數據：

• 改善前：D-Sub 不可行，DVI 轉接複雜。
• 改善後：HDMI 直連穩定。
• 改善幅度：接線簡化、相容性提升。

Learning Points（學習要點） 核心知識點：

• 顯示介面對齊的重要性。
• HDMI 音訊輸出設定。
• TV PC 模式差異。

技能要求：

• 必備技能：顯示/音訊設定。
• 進階技能：TV 端設定與模式對應。

延伸思考：

• 若 TV 多 HDMI 埠，標記哪個用於 PC 模式。
• 風險：某些 早期 780G HDMI 音訊需額外設定。
• 優化：ARC/eARC 與 AV 擴大機整合（新代設備）。

Practice Exercise（練習題）

• 基礎練習：完成 HDMI 聲畫輸出設定。（30 分鐘）
• 進階練習：比較不同 HDMI 埠的延遲/畫質。（2 小時）
• 專案練習：撰寫你的 TV 介面對映手冊。（8 小時）

Assessment Criteria（評估標準）

• 功能完整性（40%）：聲畫皆能輸出。
• 程式碼品質（30%）：設定記錄。
• 效能優化（20%）：無延遲/破音。
• 創新性（10%）：接線簡化。

Case #15: 電源供應器選型：330W 穩定覆蓋 <100W 全速負載

Problem Statement（問題陳述）

業務場景：整機全速運轉不到 100W，但仍需穩定可靠的電源供應器；希望在過剩與不穩間取平衡。 技術挑戰：選擇適當瓦數與高可靠廠牌，兼顧效率曲線與靜音。 影響範圍：系統穩定、噪音與壽命。 複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

1. 市售電源瓦數高但在低負載效率偏低。
2. 雜牌電源品質不穩定。
3. 低瓦數優質電源選擇少。 深層原因：
   • 架構層面：電源容量與負載不匹配。
   • 技術層面：效率曲線在 20-50% 負載最佳。
   • 流程層面：以品牌與最小規格思維選型。

Solution Design（解決方案設計）

解決策略：選用 Seasonic 330W（品牌信賴、最小規格）覆蓋峰值，維持在效率甜蜜點，確保穩定與壽命。

實施步驟：

1. 估算負載與峰值
   • 實作細節：CPU 45W + 內顯 + 硬碟/風扇估算峰值 < 150W。
   • 所需資源：零件 TDP 資料。
   • 預估時間：30 分鐘。
2. 選型與驗證
   • 實作細節：以 330W 上限運行，觀察穩定與溫度。
   • 所需資源：PSU 測試。
   • 預估時間：1 小時。

關鍵程式碼/設定：

驗證項目：
- 連續播放與喚醒穩定
- 風扇噪音與溫度
- UPS 相容（若有）

實際案例：作者選擇 Seasonic 330W，指出「整台機器全速運轉也沒有破 100W」。 實作環境：HTPC 平台。 實測數據：

• 改善前：可能考慮更大瓦數電源。
• 改善後：330W 穩定覆蓋、安靜。
• 改善幅度：成本/噪音/效率綜合優化。

Learning Points（學習要點） 核心知識點：

• PSU 效率曲線與負載匹配。
• 品牌與品質的重要性。
• 功率估算方法。

技能要求：

• 必備技能：TDP 估算。
• 進階技能：穩定性與噪音測試。

延伸思考：

• 80 PLUS 等級的影響。
• 風險：負載突波與老化。
• 優化：留有 30-50% 裕度。

Practice Exercise（練習題）

• 基礎練習：估算你系統的峰值功耗。（30 分鐘）
• 進階練習：比較兩款 PSU 在 50W-150W 負載的效率。（2 小時）
• 專案練習：撰寫 PSU 選型報告。（8 小時）

Assessment Criteria（評估標準）

• 功能完整性（40%）：穩定供電。
• 程式碼品質（30%）：估算與測試紀錄。
• 效能優化（20%）：噪音/效率表現。
• 創新性（10%）：測試方法。

Case #16: 影片播放穩定與解碼負載管理（MPEG2/DivX）

Problem Statement（問題陳述）

業務場景：HTPC 主要播放 DVD（MPEG2）與 AVI（DivX/MPEG4），期望畫面與流暢度良好且功耗不飆升。 技術挑戰：在內顯平台上確保解碼能力、字體渲染與音畫同步。 影響範圍：觀影體驗與功耗。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

1. 解碼效率不足會造成丟幀。
2. 影片與顯示設定不當導致畫質不佳或 overscan。
3. 音訊路徑配置錯誤造成不同步。 深層原因：
   • 架構層面：硬體解碼/加速可用性未確認。
   • 技術層面：解碼器選用與設定。
   • 流程層面：未做播放負載與功耗驗證。

Solution Design（解決方案設計）

解決策略：在 780G 平台上以 MCE 撥放 MPEG2/DivX，調整顯示解析度至 1080p，校正 overscan，量測播放功耗 60-65W，確保穩定。

實施步驟：

1. 解析度與顯示校正
   • 實作細節：TV/顯示驅動端關閉 overscan 或做 1:1 像素映射。
   • 所需資源：顯卡控制面板。
   • 預估時間：30 分鐘。
2. 解碼器/播放測試
   • 實作細節：用代表性片源測試，觀察丟幀與 CPU 使用率。
   • 所需資源：測試片源。
   • 預估時間：1 小時。

關鍵程式碼/設定：

檢查項：
- 解析度：1920x1080p @ 60Hz
- 播放時 CPU 使用率：低至中等（視片源而定）
- 功耗：60-65W（文中實測）

實際案例：作者播放 DVD/AVI 時耗電 60-65W，觀影良好。 實作環境：780G 內顯 + 4850e。 實測數據：

• 改善前：不確定 780G 能否流暢播放。
• 改善後：實測播放穩定且功耗可控。
• 改善幅度：體驗可預期、功耗定量化。

Learning Points（學習要點） 核心知識點：

• 顯示解析度與 overscan 對畫面的影響。
• 解碼負載觀察。
• 播放情境的功耗測試。

技能要求：

• 必備技能：顯示與播放器設定。
• 進階技能：解碼器選擇與調優。

延伸思考：

• 高碼率/新編碼格式的升級路徑。
• 風險：舊驅動影響播放穩定。
• 優化：更新驅動、採用硬體加速解碼。

Practice Exercise（練習題）

• 基礎練習：校正 overscan 並播放測試片。（30 分鐘）
• 進階練習：量測播放時 CPU 與功耗。（2 小時）
• 專案練習：撰寫影片播放穩定性報告。（8 小時）

Assessment Criteria（評估標準）

• 功能完整性（40%）：無丟幀/卡頓。
• 程式碼品質（30%）：設定紀錄完備。
• 效能優化（20%）：功耗達標。
• 創新性（10%）：測試方法設計。

案例分類

1) 按難度分類

• 入門級（適合初學者）
  • Case #5, #6, #7, #10, #13, #14
• 中級（需要一定基礎）
  • Case #1, #2, #3, #4, #8, #9, #12, #15, #16
• 高級（需要深厚經驗）
  • （本批案例以家用 HTPC 為主，無需高級分佈式或深度驅動開發）

2) 按技術領域分類

• 架構設計類
  • Case #1, #3, #12, #15
• 效能優化類
  • Case #4, #8, #16
• 整合開發類
  • Case #7, #9, #10, #14
• 除錯診斷類
  • Case #2, #6, #13
• 安全防護類
  • （本篇未特別涉及，可在共享權限與帳號隔離延伸）

3) 按學習目標分類

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

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

• 先學哪些案例？
  • 起步（設備與基礎）：Case #6（免驅動相容）、Case #5（遙控與喚醒）、Case #7（媒體庫整合）、Case #13（HDMI 線材）與 Case #14（HDMI 相容）。
• 依賴關係：
  • Case #5 與 #8 依賴 Case #4（電源/睡眠觀念與設定）。
  • Case #9、#10 依賴 Case #7（媒體庫）與基本穩定播放（Case #16）。
  • Case #12（錄影共享）依賴檔案共享與映射（Case #7 中的掛載技巧）。
  • 架構選型（Case #1、#3、#15）影響全局，但可在入門後回頭強化。
• 完整學習路徑建議： 1) 硬體與相容基線：Case #13 → #14 → #6 2) 操作體驗打底：Case #5 → #7 → #2 3) 電源與省電：Case #4 → #8 → 驗證（反覆） 4) 內容來源與共享：Case #12 → 跨機播放（回到 #7） 5) 進階遙控與創新：Case #9 → #10 → 成本策略 #11 6) 架構與選型回顧：Case #1 → #3 → #15 7) 播放穩定與效能：Case #16（持續優化）

完成上述路徑後，即可從零打造一套低功耗、低成本且高可用性的 HTPC，並具備跨裝置控制與共享的完整方法論。