軍械庫已開啟
機關槍已經發下去了。
AdEspresso 共同創辦人暨 Unkover 首席 AI 長 Massimo Chieruzzi 精準地捕捉到了這一點：*「AI 有時讓你覺得自己像一隻拿著機關槍的猴子。」*我們同意。並從這個洞見中得出我們自己的：我們就是那隻猴子，槍已經在我們手中，問題不在於這兩者任何一方，而在於缺少瞄準。
Cursor、Copilot、Claude Code、v0 —— 這些不是在 architecture review 上討論的未來技術。它們已經活在你的技術棧中，在工程師旁邊生成程式碼，提交到你的 repositories。AI 代理人已經擁有你 codebase 的 API 存取權。「我們應該允許 AI 工具嗎？」這個問題在六個月前就因為沒有人開口請求許可而塵埃落定了。
你的團隊已經武裝好了。唯一的問題是：你裝了aimbot沒有？
什麼是 AI 程式碼治理？
AI 程式碼治理是一套結構性規則，用來引導開發者和 AI 代理人如何編寫、修改和交付程式碼。它不是權限式官僚主義，不是工單佇列或強制簽核鏈。它是guardrails式強制執行，以開發者的速度運作：對 service module施加硬性邊界、明確的 dependency interfaces，以及在 CI 中就會失敗的 contract tests，讓壞程式碼永遠到不了生產環境。
沒有它，每個 AI 生成的 pull request 就等於往黑暗中開一槍。有了它，猴子照樣開火 —— 但每一發都落在該落的地方。
猴子命中目標
恐怖之處就在這裡。功能上線了，工單關閉了，demo 完美運作。
猴子打中了目標。但代價是什麼？因為為了命中那一個目標，它噴了三十發子彈穿過 authentication 服務、database schema 和三座被撕裂的 microservices，因為猴子不瞄準 —— 它掃射。
Slack 頻道在慶祝。生產環境在默默流血。auth 回歸問題不會出現在 pull request 的 diff 裡，它在四十八小時後才浮現，當值班工程師在凌晨兩點被呼叫，因為全平台的登入 token 都在崩潰。
目標從來就不是問題，附帶損害才是。
為什麼 Code Review 無法勝任治理工作
Code Review 是手動子彈偏轉
標準的應對方案不是訓練。沒有人有六週時間搞 bootcamps。真正的應對方案更糟：讓資深工程師審查每一個 pull request。
code review 變成了子彈偏轉。資深工程師閱讀每一行程式碼，攔截每一發流彈，把它重新導向目標。他們不是在指導，不是在架構設計，他們是站在猴子前面，手動調整每一槍，讓它落在某個可接受的地方。
這無法擴展。一位資深，十二隻猴子，每個 sprint 四百發子彈。資深工程師筋疲力竭，審查佇列越積越長。最終他們核准了本不該核准的東西，不是因為他們懈怠了，而是因為人類的注意力是有限資源，而猴子的彈藥無窮無盡。
即便有訓練，也是在沙盒中進行。真正的猴子是在生產環境中開火學到教訓的。等到教訓內化，codebase 已經承受了需要好幾個季度才能修復的打擊。
你不可能雇用足夠的資深工程師來手動偏轉每一發子彈。這道數學題無解。
AI 倍增效應：無驕傲、無恐懼
初階開發者至少還有感覺。快速出貨時他們會在 Slack 上咧嘴笑。最終他們會感受到後座力，當跳彈以 postmortem 或 rollback 的形式打回他們身上。
AI 代理人什麼都感受不到。沒有驕傲，沒有恐懼，沒有責難。當 auth 層在凌晨三點掛掉，沒有人會呼叫模型，他們呼叫的是合併 pull request 的那個人。
一個 LLM 會在凌晨三點「清理 codebase」，信心十足地重構你的 authentication 層。它會刪除已棄用的欄位，而下游消費者仍然依賴它們。它會引入編譯能通過但執行時會崩潰的循環 dependency。它會禮貌地完成這一切，附上出色的變數命名和詳盡的註解。
猴子最終學會掃射會被跳彈打回來。牠學會先瞄準再開火。到了那時候，傷害已經造成了。
Autotomy 就是aimbot
這就是比喻從警示轉向解方的時刻。
你不沒收槍枝，不安排一門六週的安全課程（反正業務端也會取消），你安裝aimbot。
Autotomy 不是官僚審批流程，不是工單佇列，也不是讓已經溺水掙扎的資深工程師強制進行的 code review。它是guardrails式治理，以開發者的速度運作。
猴子照樣開火。猴子開火更有自信，因為準星鎖定的是有效目標。service boundaries 是硬性約束，不是建議。dependencies 必須流經明確的 interfaces。contract 變更沿著經過驗證的路徑傳播。功能上線了，其他東西沒有陣亡。
這就是權限式治理和guardrails式治理的差異。權限說：停下來請示。guardrails說：全速前進，相信結構會在壞槍落地之前攔截。
回報：資深工程師重新成為觀測員
今天，你的資深工程師是保鑣。他們站在猴子前面攔截流彈。每個 pull request 都是損害控管，每次審查都是急診檢傷分類。資深工程師花時間在說「不，不要碰那個檔案」、「不，那個 module 是禁區」，直到他們自己的生產力歸零。
裝上aimbot之後，資深工程師重新成為觀測員。他們驗證風偏，確認高難度目標的命中，追捕自動化治理看不見的邊界情況。他們不再是肉身盾牌，他們是力量倍增器。
能夠擴展的治理，是不依賴資深工程師逐行審查程式碼的治理。它依賴的是結構性規則，嚴格到即使是一隻拿機關槍的猴子也無法意外違反。
想更深入了解剛性邊界如何讓 AI 生成的程式碼在生產環境中值得信賴，請看〈AI 編碼如何與 Autotomy 框架協作〉。如果你想理解guardrails在整個技術棧中的定位，請閱讀〈AI 安全棧〉。
接下來真正該做的事
如果你正在管理一個有初階開發者或 AI 代理人的團隊，不要從訓練課程開始。從硬性邊界開始。
在任何人撰寫實作之前先定義 module interfaces。透過 composition root 串接每一個 dependency。每條邊界加一個 contract test。在 CI 中強制執行 import restrictions，讓違反 architecture 的 pull request 根本無法合併。
這些步驟只需要一天，決定了你的團隊在第四週時是否信任自己的開發者。對於使用 AI 生成程式碼的團隊而言，為每個 API 邊界加上 contract tests 是槓桿效應最高的第一步。
猴子已經進了大樓，槍已經上膛。裝好aimbot，否則準備繼續徒手攔子彈。