[長篇] PC 平台演化與相容性失效的統一解釋框架 — 契約失效模型 Contract Failure Model (CFM)

型號	CPU / 年份	PassMark	YouTube 硬解	獨立顯卡	已觸發限制條件
P2530U	i5-6200U / 2017	3,100	VP9 8-bit	無	無硬性斷裂（唯一現代節點）
P2420L	i5-5200U / 2015	2,700	H.264	無	VP9 軟解吃 CPU（AVX2 具備，AI 推論 CPU 路徑可用）
G480	i3-2328M / 2012	2,100	H.264	GT 635M	VP9 軟解；GT635M 僅 3D 啟動，iGPU 主導；驅動 legacy
P43S	i5-2450M / 2012	2,000	H.264	AMD HD 520M	VP9 軟解；HD520M ROCm 不支援；無 AVX2
4745G	i5-460M / 2010	1,900	無	ATI HD 5650	無 H.264 硬解；HD5650 驅動斷；無 AVX2
X210E	Celeron 847 / 2012	800	無（僅 H.264）	無	PassMark 極低；VP9 全軟解；無 AVX2
A42F	P6100 / 2010	700	無	無	PassMark 極低；VP9 全軟解；無 AVX2
F6VE	C2D T6500 / 2009	650	無	AMD HD 4570	SSE4.2 缺失；HD4570 驅動完全斷；無 AVX2

1.2　現役主力機群：健康基準線

上述八台機器是 CFM 框架的「失效案例庫」，用來歸納契約斷裂的各種形式。作為對照，現役主力機群由六台 Lenovo ThinkPad 組成——三台 T480（Kaby Lake R，2018）與三台 T490（Whiskey Lake，2019），全數搭載 i7 處理器。

這六台機器在 CFM 四維評級上全部落在綠燈區間：SSE4.2 與 AVX2 完整支援、TLS 與憑證無問題、ThinkPad 的 Linux 驅動支援品質在消費級筆電中名列前茅、韌體維護持續有效。它們代表的是「契約仍然完整」的現役基準線。

機群內部採差異化配置，以最小的採購差異換取最大的場景覆蓋：外勤專責的 T480 特別採購最高 cell 數的大容量電池，利用該世代獨有的雙電池架構（內置 24Wh + 外置最大 72Wh）實現全天不插電；T490 機群中有一台配置 NVIDIA MX250 獨顯，作為機群內算力最強的節點，負責現代任務測試，並在需要 CUDA 的輕量推論任務上提供逃生路徑。

六台統一機型帶來的維護標準化效益同樣不可忽略：零件可在機群內互換，備用機可快速頂上，這正是 SMB 設備管理中「設備沒壞繼續用」哲學的組織級體現。

二、現象層：數位演化汰除編年表（2009–2026）

在建立理論框架之前，先系統整理導致舊硬體陸續失效的關鍵技術門檻。這些門檻依時序排列，構成一部「PC 平台相容性失效編年史」。

年份	關鍵技術門檻	代表受災硬體	失效性質
2009–2011	Flash 沒落／SSE2 指令集	Pentium 4、Celeron D	執行能力
2012–2014	SSE4.2 普及（Chrome 強制）	Core 2 Duo、早期 Pentium	執行能力
2013–2016	ACPI 電源管理實作缺陷	Ivy Bridge 主機板（B75/H77）	溝通能力
2014–2016	PAE / NX bit 要求	初代 Eee PC、Pentium M	執行能力
2014–2016	JS 引擎優化、網頁記憶體暴增	第一代 Core i（Nehalem）	執行能力
2016–2018	VP9 硬體解碼需求	Sandy Bridge、Ivy Bridge	執行能力
2018–2020	TLS 1.3 / 根憑證失效	Windows 7 以下系統	溝通能力
2019–2022	Linux HWE kernel 靜默升級 / DKMS 斷裂	Out-of-tree driver 硬體	維護能力
2021–2023	Windows 11 TPM 2.0 / Secure Boot	Haswell 以下平台	溝通能力
2023–2026	AI Runtime 要求 AVX2 / FMA / BMI	Ivy Bridge 以下、Xeon E5 v1/v2	執行能力
2024–2026	新版 GRUB UEFI Boot Entry 寫入方式更新	2012 年前後早期 UEFI 主機板	溝通能力

2.1　指令集淘汰的本質：能力缺失，而非效能不足

上表中最關鍵的洞察，是區分兩種根本不同的失效性質：

效能不足（Performance Degradation）：CPU 跑得動，但太慢。

能力缺失（Capability Absence）：CPU 根本不會那個動作。

當 Chrome 的 V8 引擎編譯時加入 -msse4.2 旗標，在不支援 SSE4.2 的 CPU 上執行時，CPU 的指令解碼器遇到未知 opcode，觸發 #UD（Invalid Opcode Exception）硬體中斷，作業系統送出 SIGILL 信號，程序立即終止。這不是「變慢」，而是「直接拒絕執行」。沒有降級路徑，沒有警告訊息，直接閃退。

同樣的機制在 AI 時代重演。Ollama 的預編譯二進位以 -march=haswell 為目標，在 Ivy Bridge 以下的 CPU 上執行時，同樣觸發非法指令中斷。一台擁有大量 RAM 和 PCIe 插槽的 X79 工作站，在 AI 推論需求面前，不是「太慢」，而是「根本不被允許執行」。

2.2　Side channel：契約的側門

並非所有斷裂都是不可繞行的。部分看似「系統性死刑」的失效，實際上只是「預設路徑失效」，繞道仍然可行。

典型案例：h264ify 瀏覽器擴充套件。YouTube 改用 VP9 後，不支援 VP9 硬解的舊機器面臨影片卡頓問題。一般使用者的直覺結論是「電腦太舊要換」。但 h264ify 透過修改瀏覽器送出的 codec 偏好設定，讓 YouTube 改送 H.264，讓原本被判定淘汰的機器重獲生機。

這個案例揭示了一個重要的診斷原則：在宣判死刑之前，應先確認「這個契約是否有側門存在」。現場工程師和一般使用者之間的能力差距，很大程度上正是在此。

三、理論層：契約失效模型（CFM）

3.1　核心命題

電腦的死亡，從來不是硬體失能，而是它所依賴的執行、溝通、維護與取得四種契約，被標準組織、平台廠商、作業系統開發者或硬體供應商，在使用者不知情的情況下單方面終止或改寫。

本文所稱「契約」，並非法律意義上的合意文件，而是指系統各層之間隱性存在的能力假設——上層軟體假設下層硬體具備某種能力，這個假設就是契約。契約的特殊性在於它從未被明文寫下，卻在被違反的那一刻，以系統失效的方式強制顯形。

這些契約的關鍵不對稱性在於：契約由強勢的一方（標準組織、平台廠商、OS 開發者）單方面更新，硬體端沒有協商能力，只有合規或出局兩個選項。使用者從未收到通知，從未有協商機會，也從未有申訴管道。

3.2　七層現象分類（歸納層）

從現場案例自下而上歸納，所有失效現象可以分類為七種具體死亡方式：

層次	失效類型	代表案例
1	ISA Failure（指令集失效）	SSE4.2 / AVX2 / FMA 缺失
2	Codec Failure（編解碼失效）	VP9 / AV1 / HEVC 不支援
3	Protocol Failure（協定失效）	TLS 1.3 / 根憑證過期
4	Platform Failure（平台失效）	ACPI 缺陷 / TPM 2.0 缺失
5	Maintenance Failure（維護失效）	HWE / DKMS / Integration Hell
6	License Infrastructure Failure（授權失效）	Drobo 倒閉 / Windows 7 啟動關閉
7	Repository Retraction Failure（倉儲撤離失效）	Synology / Zyxel firmware 消失

七層模型是歸納法的產物——從具體案例往上收斂，描述「發生了什麼」。

3.3　四維斷裂模型（演繹層）

七層現象可以進一步收斂為四個統一的斷裂維度，以「斷裂發生在哪種能力邊界」作為唯一分類標準：

維度	核心問題	包含的七層類型
① 執行能力斷裂	CPU / GPU 不會做	ISA Failure、Codec Failure
② 溝通能力斷裂	系統之間無法對話	Protocol Failure、Platform Failure
③ 維護能力斷裂	系統無法持續演化	Maintenance Failure
④ 取得能力斷裂	系統無法被重新取得	License Failure、Repository Failure

四維模型是演繹法的產物——從統一原則往下覆蓋，解釋「為什麼會發生」。七層是現象的清單，四維是現象的解釋機制，兩者是同一理論的兩個觀察高度。

當一個失效案例同時符合多個維度，以「最初斷裂點」作為分類依據，而非失效的最終結果。

3.4　取得能力斷裂的特殊性：契約被武器化

前三個維度的失效，主動方雖然強勢，但至少有技術邏輯支撐。取得能力斷裂中有兩個子類型更為特殊：

其一是「公司死亡型失效」（Corporate Mortality Failure）。Drobo NAS 的初始化流程依賴公司雲端伺服器做授權驗證。公司倒閉後，所有設備永久無法重新初始化。使用者購買的是硬體，卻在不知情的情況下同時租用了一個「公司存活」的隱性前提——這個前提從未出現在產品規格表上。

其二是「主動撤離型失效」（Platform Deliberate Withdrawal）。Microsoft 主動關閉 Windows 7 的啟動伺服器，合法購買的永久授權軟體因驗證基礎設施被撤除而無法重新部署。「永久授權」的「永久」在此成為一個謊言。

更嚴重的是商業軟體的 phone home 監控機制。部分 CAD 業界軟體會靜默掃描網路內的授權使用情況，將硬體指紋、使用者資訊回傳原廠，再由律師或執法機關介入。這不是契約失效，而是「契約被武器化」——使用者付費取得了使用權，但使用權本身內建了監控機制。

3.5　Shadow Infrastructure（影子基礎設施）

當正式取得能力失效後，由非正式網路自發形成的替代分發系統稱為 Shadow Infrastructure，包括 Archive.org、GitHub mirror、論壇上傳存檔、個人 NAS 備份等。

以醫學類比，這是數位世界的「側枝循環」（Collateral Circulation）——主血管堵塞後，周邊小血管試圖補償，但供血量不穩定，也可能隨時消失。Shadow Infrastructure 的關鍵風險不在於不可靠，而在於它的消亡是無聲的：一個論壇帖子被刪除、一個個人 NAS 關機，沒有任何通知，沒有任何記錄。

Shadow Infrastructure ≠ 解決方案。Shadow Infrastructure = 系統已失去正式契約的證據，且面對雙重消亡風險。

四、決策層：四色交通燈系統

CFM 的四維模型是靜態的能力描述，但現場工程師需要的是動態的決策工具。四色交通燈系統將四維能力狀態投影到「風險時間性」維度，形成可直接操作的現場評級系統。

4.1　四色定義

燈號	狀態名稱	條件	建議行動
🟢 綠燈	Operational Stable	四維契約全部完整	正常使用，無需介入
🟡 黃燈	Degraded but Contained	某一維失效，但可繞行補丁	可用，需技術補丁維持
🟠 橘燈	Time-bomb State	契約依賴外部條件穩定性，正在倒數	納入遷移計畫，不建議新部署
🔴 紅燈	Hard Failure	任一維度硬性斷裂且不可繞行	停用 / 改用途 / 替換

4.2　關鍵洞察：狀態屬於用途，不屬於機器

四色交通燈系統最重要的設計原則：CFM 評級不是機器的固有屬性，而是「機器 × 用途」的組合結果。同一台機器在不同用途下，可以同時存在不同的評級。

以 i5-460M（4745G，2010 年）為例：

用途	CFM 評級	理由
SSH Headless 監控節點	🟡 黃燈	可執行，但需鎖定 OS 版本
Zeek 流量分析後端	🟡 黃燈	CPU 推論可用，需注意維護
現代瀏覽器（Chrome）	🔴 紅燈	AVX2 或其他指令集門檻已觸發
AI 推論（llama.cpp）	🔴 紅燈	缺少 AVX2 / FMA，拒絕執行

這個原則讓「能不能用」這個二元問題，轉換為更精確的問題：「它在當前用途下，還處於哪一種風險狀態？」

4.3　SMB 現場的水果切除法

中小企業的設備管理哲學是「設備沒壞，繼續用；有小問題，切掉不用，其他照舊」——如同水果有瑕疵，切除壞的部分，其他照常食用。這是非常務實的風險管理策略。

CFM 四色系統的價值，正是幫助現場工程師精確辨認：哪些斷裂可以「切除繼續用」（黃燈），哪些是「整顆水果的入口被鎖上」（紅燈），無法繞行。前者是效能或功能降級，後者是系統性死刑，性質完全不同，卻在症狀上難以區分。

4.4　案例：一台電腦的三個身份

有一台配置 i5-4750S 的 Haswell 桌上型電腦，在家中歷經了三個不同的 CFM 評級身份，清楚示範了「狀態屬於用途，不屬於機器」這個原則。

第一個身份是「孩子的學習電腦」。選購時刻意不配置有遊戲效能的顯卡，讓遊戲用途在這個平台上成為紅燈——不是機器壞了，而是購機者主動設計了一個能力邊界。

第二個身份是「退役機」。孩子升上研究所，改由 Ryzen 5 3500X + Intel ARC A380 主機接手，i5-4750S 的教養任務完成，原有用途結束，進入待命狀態。

第三個身份是「臥室串流主機」。43 吋 Full HD 螢幕，用途鎖定在 YouTube 和四季電視等 1080p 串流播放。搭配 h264ify 強制 H.264 供檔後，評級為 🟢 綠燈。

同一台機器，三個用途，三個評級。機器本身沒有變，改變的只是它被要求履行的契約。

五、工程層：現場實踐工具鏈

CFM 框架不只是理論，它直接對應一套現場工具鏈，用於幫助 SMB 業主偵測契約失效和網路異常。

5.1　工具鏈架構

層次	工具	功能
現場探勘層	antiX 26 x64 輕量 Linux	部署在老舊硬體上的現場作業系統
現場探勘層	nmap	網路拓樸探勘，建立現場設備清單
現場探勘層	Zeek	流量語義分析，偵測 phone home 及異常行為
傳輸安全層	Tailscale	零信任加密通道，現場連回地端推論主機
推論分析層	llama-server + Qwen3 4B	本地 LLM，解析 log、生成診斷報告（4B 模型可在 8GB DRAM 老電腦本地執行）
推論分析層	RTX 3060 × 3（地端）	GPU 推論，完全不依賴雲端服務

此工具鏈的設計原則直接體現 CFM 的洞察：所有工具均為開源或自主部署，不依賴任何外部授權伺服器；敏感的業主網路資料全程不離開可控基礎設施。

nmap 回答「誰在網路上」，Zeek 回答「他們在說什麼」。兩者合力，讓業主第一次真正看見自己的網路邊界——看不見的東西無法保護，這句話對硬體淘汰成立，對網路內鬼同樣成立。

六、延伸討論：GCES 的可能性（待驗證方向）

本章為延伸討論，非 CFM 已成立的理論主張，而是基於目前三個應用案例所觀察到的結構相似性，提出一個尚待更多案例驗證的延伸方向。

系統	領域	觀察到的結構
好口福 App	食品風險決策	Ingestion Contract Evaluation System
CFM 硬體診斷	電腦相容性判斷	Hardware Capability Contract Evaluator
LandscapeProbe	網路行為分析	Behavioral Contract Reconstruction System

Input → System State Extraction → Multi-dimensional Risk Model → Decision Output

若此結構在更多領域的應用中持續成立，或許可以收斂為「廣義契約評估系統」（GCES）。然而，目前僅有三個應用案例，樣本數尚不足以支撐此命題的普遍性。這是未來可以繼續探索的方向，而非本文已完成的論證。

七、理論邊界與未來方向

7.1　CFM 的現階段定位

CFM is currently a descriptive but structurally consistent framework, capable of cross-domain explanation of system discontinuities, but not yet a fully formalized predictive theory.

CFM 目前已具備三個工程級理論的核心條件：可用（usable）、可教（teachable）、可重現（reproducible）。它能一致地解釋跨時代（2009–2026）、跨平台、跨廠商的系統失效現象。尚未完成的部分是向預測模型的形式化轉換。

7.2　CFM 的覆蓋邊界：效能淘汰的正式宣告

CFM 並非一個宣稱解釋所有系統失效的萬能框架。明確的邊界是理論成熟的標誌，而非缺陷。

效能淘汰（Performance Failure）：系統的所有契約層均完整，但純粹因為算力不足以應付現代工作負載，導致使用體驗不可接受。

本文案例集中，A42F（Pentium P6100，PassMark 700）屬於此類型。CFM 的準確覆蓋範圍：CFM 解釋「契約斷裂型失效」，不解釋「純效能型失效」。前者是本文的理論核心，後者是傳統效能評估框架（如 PassMark 基準測試）的覆蓋範圍。兩者互補，而非競爭。

7.3　必要斷裂與惡意斷裂的區分

CFM 描述的是「契約被單方面改寫或終止」這個現象，但這個描述本身是中立的——它說明發生了什麼，不評價對錯。

廠商升級 TLS 是為了安全性，這個「契約改寫」有正當理由。Drobo 倒閉讓設備磚化，這個「契約消失」對使用者毫無好處。兩者在 CFM 框架裡的描述語言相同，但道德重量截然不同。

必要斷裂（Necessary Breach）：契約改寫有明確的技術或安全正當性，且通常有公開說明、過渡期、或替代方案。TLS 1.3 的推行、Chrome 對 SSE4.2 的要求均屬此類。

不負責任斷裂（Irresponsible Breach）：契約消失對使用者造成不可逆損害，且廠商沒有提供任何補救路徑。Drobo 的雲端初始化鎖定、商業軟體的 phone home 監控均屬此類。

CFM 框架目前刻意保持描述中立，不在框架層級做道德判斷。但使用 CFM 的工程師在向業主解釋時，區分這兩種斷裂的性質，有助於做出更合理的建議。

7.4　可否證條件的設計

一個有意義的理論必須是可以被否證的。CFM 的可否證條件：若存在一個系統失效案例，其根本原因是硬體效能不足（而非任何一層契約的斷裂），且無法被歸入四個維度之任一，則 CFM 的核心命題需要修正。目前在案例集中（效能淘汰案例已明確排除）尚未發現此類反例。

7.5　數位所有權的根本問題

如果一台設備的執行能力、溝通能力、維護能力與取得能力，都可以被外部單方面改寫或終止，那麼「擁有一台電腦」究竟意味著什麼？

這不是技術問題，也不是軟體問題，而是數位時代所有權是否仍然成立的問題。如果一切能力都可以被外部單方面撤銷，那麼我們所謂的「擁有」，是否只是一種暫時被授權的錯覺？

八、結論

本文從一份中小企業現場的舊電腦清單出發，系統整理了二十年間導致 PC 平台相容性失效的七種現象，並收斂為四維斷裂模型（CFM），最終建立可直接用於現場決策的四色交通燈評級系統。

CFM 的核心貢獻在於重新定義「電腦淘汰」這件事的本質：它不是效能的自然衰退，而是系統各層之間的隱性契約，在使用者不知情的情況下，被不同的強勢行為者單方面終止或改寫。

電腦不是老了，它只是失去了被允許參與最新契約的資格。而這個資格的失去，往往不是在某個宣告的時刻，而是在某次例行更新之後，靜默地、不可逆地發生的。

附錄一：CFM 快速診斷流程

遇到系統異常，依序問以下四個問題：

步驟	診斷問題	若是 → 對應維度
1	軟體是否拒絕執行，或效能異常到無法使用？	執行能力斷裂 → 查 CPU 指令集 / Codec 支援
2	系統可以執行，但無法連線、無法喚醒、或 Boot 異常？	溝通能力斷裂 → 查 TLS / ACPI / BIOS 版本
3	系統在更新後才出問題？	維護能力斷裂 → 查 kernel ABI / driver / 套件組合
4	想重裝或重建，卻找不到授權或韌體資源？	取得能力斷裂 → 查 license 狀態 / firmware 來源

確認維度後，套用四色評級：可繞行 → 黃燈；時間炸彈 → 橘燈；硬性斷裂 → 紅燈。評級以「用途」為單位，同一台機器不同用途可有不同評級。

附錄二：現場診斷案例病歷集

以下十個案例均來自實際現場經驗，依照「配置 → 現象 → 懷疑方向 → 根本原因 → Bypass → 判定 → 建議去處」的診斷弧線記錄，供現場工程師參照。

案例 1　4745G（i5-460M / ATI HD 5650）

配置	Intel Core i5-460M（Arrandale）、ATI Mobility Radeon HD 5650、D3 4GB RAM
觀察現象	YouTube 影片完全無法流暢播放，連 720p 也持續卡頓，風扇狂轉，CPU 使用率 100%
初步懷疑方向	網路頻寬不足；記憶體不夠；瀏覽器需要清快取
根本原因	i5-460M 無硬體 H.264 加速；HD 5650 不支援 VP9 硬解。YouTube 預設供應 VP9，CPU 全程軟解，Arrandale 世代單核效能不足以應付 720p 以上 VP9 串流。HD 5650 驅動在現行 Linux 已進入 Shadow Infrastructure 狀態。
Bypass 方案	安裝 h264ify 瀏覽器擴充套件，強制 YouTube 改送 H.264；同時將播放品質鎖定在 480p。此組合下 CPU 負擔大幅降低，勉強可用。
CFM 判定	🟠 串流：橘燈（h264ify 補丁後降為 🟡 黃燈，但 480p 上限）　🟡 監控 / SSH：黃燈（可用）
建議用途／去處	Headless 監控節點；簡單後端服務；不建議作為桌面主力機

案例 2　G480（i3-2328M / GT 635M）

配置	Intel Core i3-2328M（Sandy Bridge）、NVIDIA GeForce GT 635M、D3 8GB RAM
觀察現象	YouTube 高畫質持續卡頓；獨顯感覺沒有在運作；OS 內所有 2D 畫面均由 iGPU 負責
初步懷疑方向	驅動未正確安裝；散熱問題導致降頻；需要重灌系統
根本原因	根本原因為主板或 BIOS 設定問題：OS 內全數使用 iGPU（Intel HD 3000）進行 2D 顯示，GT 635M 僅在 3D 遊戲場景才會啟動，無法用於 2D 加速或影片解碼。GT 635M 本身亦不支援 VP9 硬解，NVIDIA 已將此 GPU 列入 legacy driver 系列，新版 Linux 核心驅動相容性持續惡化（上游推進型斷裂）。即使獨顯正常啟動，VP9 仍需 CPU 軟解。
Bypass 方案	h264ify 強制 H.264 + 限制 1080p 以下；iGPU 路徑在 Linux 下反而更穩定，可直接放棄獨顯驅動。
CFM 判定	🟡 降規串流：黃燈（需 h264ify 補丁）　🟡 監控 / 後端：黃燈（可用）
建議用途／去處	區域網路監控節點；輕量後端服務；放棄獨顯、以 iGPU 為主反而更穩定。不建議跑現代桌面多工環境

案例 3　A42F（Pentium P6100）

配置	Intel Pentium P6100、無獨顯、D3 4GB RAM；PassMark 約 700
觀察現象	整體使用體驗極差，幾乎所有操作都無法正常完成
初步懷疑方向	需要重灌；硬體故障
根本原因	PassMark 700，算力已低於任何有意義的現代工作負載門檻。同時缺乏獨顯，無任何加速路徑。這是效能淘汰的極端案例，屬於 CFM 覆蓋邊界之外。
Bypass 方案	無。
CFM 判定	🔴 全面紅燈（效能淘汰，所有用途均不可行）
建議用途／去處	汰換；零件回收（SSD / RAM 若有升級過，可移植至其他機器）

案例 4　Drobo NAS / DAS 設備

配置	Drobo 品牌 NAS 或 DAS 儲存設備（各型號）
觀察現象	嘗試重新初始化設備時，精靈程式一直卡在「連線至 Drobo 伺服器」步驟，無法繼續
初步懷疑方向	網路設定問題；設備韌體損壞；需要聯絡原廠技術支援
根本原因	Drobo 公司已倒閉，官方授權驗證伺服器永久關閉。設備的初始化流程硬性依賴雲端伺服器，這個依賴從未出現在產品規格表上。這是典型的「公司死亡型授權失效」（Corporate Mortality Failure）。
Bypass 方案	社群有非官方工具嘗試繞過初始化驗證（屬於 Shadow Infrastructure），成功率因型號而異，不保證穩定。現有資料若磁碟陣列仍完整，部分工具可嘗試直接讀取。
CFM 判定	🔴 紅燈（取得能力完全斷裂，不可逆）　設備本體：報廢
建議用途／去處	資料救援為第一優先；設備本體報廢。教訓：評估 NAS 設備時需確認初始化流程是否依賴雲端服務

案例 5　Windows 7 授權啟動

配置	合法購買的 Windows 7 零售或 OEM 授權，嘗試重新安裝後啟動
觀察現象	重灌後顯示「無法連線至啟動伺服器」，系統進入未啟動狀態，功能受限
初步懷疑方向	網路問題；授權碼輸入錯誤；需要重新購買授權
根本原因	Microsoft 主動關閉 Windows 7 線上啟動伺服器。合法購買的「永久授權」實際上隱性依賴伺服器基礎設施的持續存活，這個前提從未在銷售時明確告知。這是「平台主動撤離型失效」（Platform Deliberate Withdrawal）。
Bypass 方案	電話啟動管道在部分地區仍殘存自動化系統，可嘗試；或接受降級至 Windows 10。
CFM 判定	🔴 紅燈（授權基礎設施失效，重新部署不可行）
建議用途／去處	升級至 Windows 10 / 11；或改裝 Linux（對硬體能力在 CFM 綠燈範圍內的機器）

案例 6　CAD 業界軟體 Phone Home 監控

配置	商業 CAD 軟體（如 AutoDesk 系列）部署於企業內網，多台工作站安裝
觀察現象	軟體正常使用多時後，突然收到原廠律師函，指控授權使用數量超出購買範圍
初步懷疑方向	授權數量計算誤解；競爭對手檢舉；隨機稽核
根本原因	軟體內建 phone home 機制，靜默掃描同網段安裝數量、硬體指紋，並將資料回傳原廠。這是「契約被武器化」——使用者付費取得使用權，但使用權本身內建了監控機制，使用者沒有被明確告知，也無協商能力。
Bypass 方案	防火牆建立出站規則，封鎖軟體的 phone home 連線；或建立雙網路隔離架構（授權軟體運行於無法連外的內網 VLAN）；定期清查授權合規性。
CFM 判定	🟠 橘燈（契約被武器化，持續運作中的隱性法律風險）　未處理前：時間炸彈狀態
建議用途／去處	立即清查授權合規；建立網路隔離架構；評估替代開源方案（FreeCAD 等）的可行性

案例 7　h264ify 的啟示：契約有側門

配置	任何不支援 VP9 硬解的舊機（Sandy Bridge / Ivy Bridge / 部分 Haswell 世代）
觀察現象	YouTube 高畫質影片持續卡頓，CPU 使用率飆高；直覺判斷：電腦太舊必須換
初步懷疑方向	電腦效能不足；網路頻寬不夠；記憶體太少
根本原因	YouTube 預設供應 VP9 格式，舊 GPU 不支援硬解，CPU 全程軟解吃不消。但 YouTube 的供檔系統本來就同時維護多個格式軌道，VP9 只是「預設路徑」，H.264 軌道並未關閉。
Bypass 方案	安裝 h264ify 瀏覽器擴充套件，修改瀏覽器送出的 codec 偏好，YouTube 改送 H.264。一般使用者不知道自己可以影響平台的供檔格式，但這個側門一直存在。
CFM 判定	🟡 黃燈（有側門可繞行，安裝 h264ify 補丁後可維持）　未裝補丁前：🟠 橘燈
建議用途／去處	關鍵教訓：診斷層次的升級。從「設備問題」重新定位為「協商問題」，才能發現契約有側門。宣判死刑前，先問：這個契約有沒有留後門？

案例 8　i5-4750S 桌機：三個身份的故事

配置	Intel Core i5-4750S（Haswell）桌上型電腦、Intel HD Graphics 4600、搭配 43″ Full HD 螢幕
觀察現象	原為孩子學習用機，孩子升研究所後退役，評估是否還有利用價值
初步懷疑方向	效能是否足夠現代任務？是否值得保留或直接淘汰？
根本原因	Haswell 平台 CFM 四維評級：SSE4.2 / AVX2 完整（執行能力✔）；TLS / ACPI 無問題（溝通能力✔）；驅動維護良好（維護能力✔）；韌體與授權無虞（取得能力✔）。對 43″ Full HD 螢幕的 1080p 串流用途，H.264 硬解零壓力，搭配 h264ify 後 VP9 問題消除。
Bypass 方案	不需要 Bypass。此用途下各項契約完整。
CFM 判定	🟢 綠燈（1080p 串流用途）　原教養用途（遊戲）🔴 紅燈（刻意設計的能力邊界）
建議用途／去處	臥室 1080p 串流主機。此案例同時示範：同一台機器歷經三個 CFM 身份——刻意限制的教養工具（紅燈）→ 退役機（待命）→ 串流主機（綠燈）。機器沒有變，改變的只是它被要求履行的契約。

案例 9　Gemini CLI Agent 卡住：配額透明度失效

配置	antiX 26 x64 現場作業筆電（X201E，Celeron 847）；Gemini CLI agent；Google AI Studio Free tier API 金鑰
觀察現象	Agent 執行到一半完全無回應，前台顯示「Thinking… (esc to cancel, 3m 45s)」持續計時，無任何錯誤訊息，無法判斷是否仍在處理
初步懷疑方向	任務太難、模型能力不足；本機算力不夠；網路連線問題；需要等待更久
根本原因	後台 Google AI Studio Usage 頁面顯示：429 TooManyRequests 大量觸發，Free tier 配額耗盡，Success Rate 掉至 0%。Agent 前台的「沉默」不是在思考，而是請求被雲端服務端反覆拒絕，但這個狀態沒有被傳遞給使用者介面。這是「配額透明度失效」（Quota Transparency Failure）——服務端與用戶端之間的狀態溝通斷裂。
Bypass 方案	升級至付費 tier 取得更高配額；或在 agent 啟動前先確認 API Usage 後台狀態；或改用本地 llama-server 推論，完全繞開雲端配額限制。
CFM 判定	🟠 橘燈（Free tier 配額為時間炸彈）　付費 tier 或地端部署後：🟡 黃燈
建議用途／去處	關鍵教訓：診斷工具與執行工具分離。前台 agent 的「沉默」至少對應三種原因——模型 thinking、rate limit、網路逾時——症狀完全相同，必須開後台 Usage 頁面才能區分。Free tier 不適合作為現場不間斷作業的依賴基礎設施。

案例 10　ASUS X201E 翻身記：從帳面死刑到現場工具鏈主力

配置	ASUS X201E（Celeron 847，2012 年）、120GB SATA SSD、11.6″ 輕薄機身；螢幕、鍵盤、電池、網路卡均正常；PassMark 約 800
觀察現象	第一印象：PassMark 800，直覺應該汰除。實際逐項檢查：電池可以充電完成、鍵盤正常、螢幕正常、SSD 正常、網路正常。Windows 10 單工作業反應不錯，不適合多工但單一任務沒有問題。
初步懷疑方向	PassMark 分數太低，直接汰除（第一反應）
根本原因	【第一層：算力瓶頸，但非硬體失效】Windows 10 + SSD 的順暢表現揭示關鍵線索：瓶頸在算力，不在儲存層。SSD 消除了機械硬碟的 Swap 拖累，讓「極輕量 CLI 任務」變得可行。物理層（螢幕、鍵盤、電池、網路）完全正常，硬體物理壽命仍在。【第二層：UEFI Boot Entry 相容性失效】antiX 26 的 GRUB 版本更新，EFI 變數寫入方式改變，與 X201E 的 2012 年早期 UEFI 韌體實作不相容，Boot Entry 寫入後無法被 BIOS 識別。這是溝通能力斷裂的韌體品質子類型，與硬體本身無關。
Bypass 方案	【算力問題】放棄現代桌面用途，改用 antiX 輕量發行版。【UEFI 問題】降版安裝 antiX 23 x64（已確認有效）。最終驗證：antiX 23 + 中文輸入法（fcitx5）+ nmap + Zeek + Gemini CLI 全部到位。
CFM 判定	🟡 黃燈（antiX 23 + CLI 現場工具用途）　🔴 紅燈（現代桌面用途）　🔴 紅燈（antiX 26，UEFI 相容性斷裂）
建議用途／去處	現場網路勘查工具機：nmap 拓樸探勘 + Zeek 流量分析 + Gemini CLI 輔助診斷。關鍵教訓：帳面規格是最差的淘汰判斷依據。真正的診斷起點是「它在哪個用途下還能履行哪些契約」，而非「它的 PassMark 是多少」。這台機器的翻身，靠的不是硬體升級，而是診斷框架的升級。

── Mr. τ　風雲網通系統有限公司 PCPiLOT　2026.07