「大概能跑」在正式環境基礎設施裡是行不通的 #
BASTION 是一個由 AI 分析基礎設施日誌、自動阻擋攻擊、並控制頻寬品質的「AI Ops Platform」。這樣寫聽起來很炫，但我們在開發中最費心的並不是增加功能，而是「只把能夠證明可用的東西放進正式環境」這條樸素的紀律。
替正式環境基礎設施加入自動控制，意味著 AI 的判斷失誤會直接變成事故。把並非攻擊的通訊誤判為攻擊而阻擋，正常客戶就會被擋在門外；在並未壅塞時收緊頻寬，服務就會劣化。所以我們不會把僅停留在「理論上應該正確」「大概能跑」階段的東西放進正式環境。
本文寫的是，在把新的偵測邏輯或控制放進正式環境之前，我們實際會做的事。
工程師會被「優美的設計」吸引 ―― 而這正是陷阱 #
老實說，我們自己也曾有一個「理論上優雅的模型」。在紙面上邏輯自洽，講起來也很舒服。這樣的設計很有魅力。
但正式環境的流量並不會按照紙面上的假設運行。我們用自家基礎設施的真實資料去檢驗那個模型，找出了與預期不符的部分。我們隨之採取的行動很簡單 ―― 把模型本身改造，將其主張收回到資料所支持的範圍。不是「因為圖好看就採用」，而是只採用資料所支持的範圍。
這並不是失敗。恰恰相反，能夠用自己的資料反駁自己優美的假設，我們認為正是一個託管正式環境基礎設施的產品所不可或缺的。
檢驗的章法 ―― 在不影響正式環境的前提下試驗假設 #
具體來說，我們按這樣的順序檢驗。
1. 只用觀測來試驗假設（READ-ONLY） #
新的偵測邏輯，首先以對正式環境不寫入任何內容的「僅觀測」模式運行。完全不觸碰正式環境的阻擋或控制，只是用真實資料記錄「如果這是正式環境，會怎樣判定」。這樣一來，即使假設落空，也不會讓任何人為難。
2. 確認它能否把真正的異常與單純的雜訊區分開 #
偵測邏輯的價值，與其說取決於「能找出異常」，不如說取決於「不把非異常說成異常」。在滿是背景雜訊的日誌中，能否只挑出真正的異常？我們關注的不是單一指標是否越過閾值，而是多個觀測面是否步調一致地開始崩塌（協調性的起始，co-onset），並將其作為各對象相對於自身平常的相對變化來捕捉。我們在自家環境中施加模擬負載或事件，用真實資料確認偵測邏輯能否把「真正的協調性異常」與「恰好同時發生的無關波動」分離開。若無法分離，那樣的偵測便毫無用處。
3. 給自己的假設迎頭撞上相反的看法 #
我們會刻意把對立的解釋拋向自己的假設：「這個偵測真的有效嗎？會不會只是碰巧命中？」即使改變觀測窗口的取法，結論是否依舊不變；用別的解釋會不會得出相同的結果。經不起反駁的主張，會從產品說明中剔除。
能證明的進正式環境，未能證明的進觀察層 #
只有通過檢驗的，才會分階段地推進到正式環境。對正式環境的寫入，必定經過「試運行 → 受限正式環境 → 全量正式環境」這三個階段。緊急停止指令從一開始就備好。並且所有的正式環境上線，都要通過「AI 提議、人來核准」這道關卡。
這條紀律也直接體現在產品的呈現方式上。比如 BASTION 的兩個模組，運行狀態就不一樣。
- 資安模組在實戰中偵測並自動阻擋了大量攻擊行動，已有實績，在正式環境中以全自動運行。
- 另一方面，品質模組（頻寬的動態控制）作為功能雖已實作，但目前仍以觀測為中心、處於分階段投入中。當線路真正發生壅塞時控制是否如預期奏效，要先用那個場景的資料確認之後再說 ―― 所以我們不寫「已在正式環境中全速運行」。
「已實作」並不等於「在正式環境中能跑」。這個區分，我們在產品頁上也不會含糊。
對 AI（LLM）本身，我們同樣不輕信、要檢驗 #
這種「不輕信、要檢驗」的姿態，同樣指向作為 BASTION 核心的本地 LLM。
此前，本地 LLM 曾在監控報告中生成了並不存在的數值（其經過與對策，我們寫在了《本地 LLM 在監控報告中捏造數值的經過及其對策》）。自那以後，在 LLM 的輸出之中，真正驅動系統的判定 ―― 是否為攻擊 IP 的最終判定、以及阻擋的執行 ―― 不交給 LLM 決定，而是用與實機日誌相對照的數學的、確定性的判定來完成。LLM 擅長的是自然語言的摘要與整形，而非正式環境中的決策。LLM 也好，（部署在可能被攻陷的 DMZ 中的）Agent 也好，對我們而言都是「不輕信、要檢驗」的對象。
為何這條樸素的紀律才是最大的差異化 #
AI Ops 與 AI 資安領域充斥著炫目的詞藻。但真正託管正式環境基礎設施的第一線負責人，真正在意的是「它會不會引發事故」「會不會因誤偵測、誤控制而讓我們為難」。
所以我們不靠流行詞，而是用實際正在運行的事實來說話 ―― 在正式環境中運行的攻擊行動偵測、若為閉網構成則日誌一概不外送、以及「只把能證明的東西放進正式環境」這一做法本身。
不以優美定奪，不在案頭定奪。要能用資料去懷疑自己優美的假設。這就是我們把 BASTION 帶到「可以放進正式環境基礎設施」這一狀態所憑藉的紀律。
