Day 20：AI 把「例外」當成了「常態」——GCB 導入的一次分類翻車

前面幾天都在判讀別人丟過來的東西——弱掃報告、滲透測試報告。今天換個方向：**合規要求真正要落地的時候，通用的最佳實務碰上台灣公部門的在地現實，會產生什麼落差。**先從組態基準（GCB）的導入談起。這篇是整個資安篇裡，AI 幫我省下最多時間、卻也在一個最根本的地方判斷相反的一次——它把整套邏輯做反了，而拉回來靠的不是資安知識，是一句「這不合常理」的領域常識。

GCB 是什麼，以及它為什麼是規模問題

先簡單交代：GCB（政府組態基準，Government Configuration Baseline）是針對政府機關資訊設備訂的標準化安全組態規範，一條一條規定「這個設定該開還是該關、值該設多少」。導入的邏輯其實很單純：能套的就用群組原則（GPO）統一套上去，真的因為業務需求套不了的，才列進「例外清單」並附上補償措施送審。 換句話說，例外是特例，套用才是常態。這個前提，等一下會變成整篇的關鍵。

麻煩的是規模。我手上要導入的是一組公部門主機——七台，有的跑對外服務、有的是純內網的圖資或檔案伺服器。GCB 對這類 Windows 伺服器光是基礎設定加上相關角色，就有數百項規範，七台加起來是好幾千條的比對工作。逐台逐條人工核對，是不切實際的工作量。這正是我想交給 AI 的部分。

把工作流交給 Cowork

我用 Cowork 搭了一套工作流，設計成兩份輸入交叉比對：一份是 GCB 規範清單（每一條規範的編號、類別、設定名稱、建議值都在裡面），另一份是每台主機的環境說明（用途、跑什麼服務、有什麼特殊需求）。要 AI 做的事，是拿掃描報告去對規範清單，把每台主機「不符合」的項目挑出來，逐台產出一份作業紀錄表。

它跑得很俐落：七台主機、每台一份紀錄表分別存到各自資料夾，外加一份彙總表和一份處理摘要，一次到位。從「幾千條規範」到「一份份整理好的清單」，這種體力活 AI 幾分鐘就做完，人工要耗上好幾天。

但我打開彙總表一看，數字不對勁。

第一個疑點：一台主機列出一百多筆例外

彙總表上，七台主機的例外項目數是一百多筆起跳，合計超過一千項。這個數量級直接違反我對 GCB 的認知——例外應該是少數特例，怎麼會多到上千筆？

我把疑問丟回去：我以為 GCB 的做法是特殊狀況才開例外、其他都套 GPO 納管，為什麼你把像「密碼最短使用期限」這種明明可以用 GPO 套的項目，也設成例外？

AI 的回答很乾脆，直接承認邏輯錯了：「這是我在分類邏輯上的錯誤。」它解釋自己的腳本是怎麼寫的——把掃描報告裡所有「未通過」的項目，一律丟進例外清單。但正確做法應該分兩類：能透過 GPO 或本機原則修補的，該列入「待修補」讓人去設定；只有因服務需求確實無法符合的（防火牆要開服務埠、遠端桌面因維運需求之類），才需要例外管理。它自己補了一句關鍵的話：密碼原則這類項目技術上完全能用 GPO 推送，開例外反而等於在說「我們刻意不套這條規則、並有補償措施」，這邏輯根本不通。

這就是這篇的核心翻車點：AI 沒有「例外是特例」這個前提，它預設「凡是不符合的都是例外」。它掌握每一條 GCB 規範的技術細節（哪個設定做什麼、該設多少），這些它比我熟；但「例外在合規實務上意味著什麼、它的數量級本來就該很小」這個領域常識，它沒有。而這恰恰是判斷整份清單對錯的那把尺。

第二個疑點：連瀏覽器設定也開例外

AI 認錯後要重新分類，但它先問了我一個問題，想確認「哪些類型該開例外」的判斷依據。它列了幾種可能，其中把瀏覽器（IE、Chrome）相關的項目也歸進「可能要開例外」那邊。

我又糾正了一次：瀏覽器項目套 GPO 完全沒問題，不該開例外。它馬上懂了——我之前說「GPO 的問題讓業務單位去擔心」，意思是讓業務單位去執行 GPO，不是說瀏覽器要開例外，它把這兩件事搞混了。修正後，真正需要開例外的只剩下網路芳鄰（SMB）相關的項目，因為那牽涉到跟舊檔案伺服器的相容性，是真的可能套了就出問題的。

修正後：上千筆例外，精簡成二十項

重新分類跑完，結果天差地別。原本一台一百多筆、合計上千的例外清單，修正後每台只剩個位數到十來筆，七台加起來只剩二十項上下——而且幾乎全部集中在網路芳鄰相關，有兩台甚至一筆例外都不需要。

這個「上千筆塌成二十項」的落差，就是這篇最有力的證據。那上千筆不是真的例外，是 AI 把「不符合」直接等同於「例外」堆出來的假清單。真正的例外從頭到尾就這麼少——但要看穿這件事，得先知道「GCB 的例外本來就該很少」，而這是報告、規範文件、掃描工具都不會告訴你的，只有實際懂這套制度怎麼運作的人下得了這個判斷。

最後一步：把判斷原則固化成一份 prompt

分類修對之後，我做了一件事：請 AI 把這次修正後的完整邏輯，整理成一份可重複使用的 prompt。理由很實際——之後還有其他單位的 GCB 要套用，我不想每次都重新踩一次「例外爆量」的坑，下次直接把這份 prompt 貼給它、附上掃描報告和主機資訊就行。

它整理出來的核心判斷原則，收斂成一句話：

套 GPO 不會壞服務 → 套用 GPO；會壞服務才開例外。

這句話本身不難，難的是 AI 一開始並不知道要用這把尺——它是在被我用領域常識糾正兩次之後，才把這條原則反推出來。而把它固化成 prompt 這個動作，等於把「這次人補上的判斷」變成下次不用重講的預設。這條「一次性工作 → 沉澱成可重用資產」的線，會是後面方法論篇的主題，這裡先埋一個伏筆。

這一天的分工

這篇的分工很清楚。AI 的價值在規模——七台主機、幾千條規範的交叉比對，逐台產出結構化的紀錄表，這種體力活它做得又快又整齊，換人工要好幾天。它對每一條 GCB 規範的技術細節也掌握得很好。

但它在最根本的分類邏輯上做反了：把「不符合」直接當成「例外」，堆出一份上千筆的假清單。糾正它的不是更強的資安知識，而是一個它沒有的領域前提——在 GCB 的合規實務裡，例外是少數特例，不是預設。我做的兩次介入（質疑密碼原則不該開例外、指出瀏覽器套 GPO 就好），都是拿這個常識去對它的產出，把上千筆收斂回二十項。

回到這個階段的主軸：GCB 規範的技術知識可以外包給 AI，但「這份清單的數量級對不對、這個項目到底算不算例外」這種需要領域常識才下得了的判斷，不行。AI 會很有效率地把一件事做完——包括很有效率地做錯方向。最後那份省下未來時間的 prompt 之所以有價值，不是因為 AI 寫得好，是因為它裝進了一條人幫它補上的判斷。

明天換一個同樣「聽起來很正派、一上線卻容易翻車」的合規措施——檔案完整性監控（FIM）。這次翻車的不是分類邏輯，而是另一件事：有沒有把「哪些變動其實是合法的」先盤點清楚。