同一種工具，兩種結果
觀察兩個團隊使用同一個 AI 模型，你會看到兩種完全不同的結果。
第一個團隊向模型下達提示，要求構建一個畫面。輸出接近正確，但不完全對。樣式偏離了 Figma 檔案。狀態管理碰到了不該碰的檔案。建置在本機通過，但在 CI 中失敗，而且沒人說得出原因。健全性檢查沒過。工程師花了三小時修復模型三分鐘產出的程式碼。他們再試一次。同樣的結果。他們得出結論：AI 程式設計還沒準備好上生產環境，實驗就此結束。
第二個團隊向模型下達提示，要求構建一個畫面。輸出同樣不完美。但他們清楚知道模型應該碰哪些檔案、不該碰哪些檔案。他們立刻察覺到偏離，用提示修正，然後發布。當生產環境出現錯誤時，他們不慌。他們向模型下達提示，讓模型追蹤失敗原因、生成修補程式，然後部署。整個循環只需幾分鐘。Reddit 上出現投訴。他們也用同樣的速度公開修復。
同一模型。同樣的提示。完全不同的結果。
差距不在於模型
第一個團隊責怪工具。輸出不穩定。模型會產生幻覺。產出的程式碼很脆弱。這些抱怨並非錯誤。模型的確會產生幻覺。產出的程式碼的確很脆弱。但第二個團隊面對的是同樣的幻覺和同樣的脆弱。他們只是恢復得更快。
差距在於信心：第二個團隊對 codebase 足夠熟悉，知道模型什麼時候正在走向懸崖。他們知道哪些 boundary 重要、哪些不重要。他們在足夠大的規模上部署過足夠多有問題的東西，以至於修復生產環境錯誤感覺像例行公事，而非事關存亡。對他們來說，AI 消除了打字和 boilerplate。它沒有消除判斷力。判斷力本來就在那裡。
對第一個團隊來說，AI 消除了打字，卻放大了不確定性。他們不知道模型是否碰對了檔案。他們不知道產出的狀態管理會不會破壞另一個畫面。他們不知道 CI 失敗是真正的問題還是 flaky test。每一次 AI 產生的變更都是一場賭博。大多數人不喜歡在生產環境上賭博。
第二個團隊到底是誰
這不是理論上的原型。第二個團隊很像是構建 Claude Code 的那些人。
Anthropic 的工程師是世界上最頂尖的一群。他們部署過分散式系統、ML 基礎設施，以及面向使用者的產品，而且都在相當大的規模上。他們見過每一種失敗模式。當他們的 AI 產生一個有 bug 的 refactor 時，他們幾秒鐘內就能發現問題，因為他們以前犯過完全一樣的錯誤。當生產環境出狀況時，他們不需要 guardrails 來告訴他們該從哪裡查。他們的直覺就是 guardrail。
這就是他們能夠勢如破竹的原因。他們發布含有 bug 的程式碼，以破紀錄的速度公開修復，然後繼續前進。網路上到處都是對他們產品的投訴。他們不會放慢腳步，他們的工程師也不會失眠。穩定性很重要，但當你可以用同一個 AI 在幾分鐘內修復 bug 時，一個 bug 的代價就很低。
他們不需要 Autotomy，因為他們的工程師已經具備了 Autotomy 編碼成規則的那種判斷力。
99% 的問題
業界的其他人不是 Anthropic。
大多數工程團隊沒有在規模上部署過幾十次的工程師。他們沒有在幾秒內發現糟糕 AI refactor 的直覺。他們沒有發布已知 bug 並即時修復的信心。當他們的程式碼在生產環境出問題時，他們的老闆會問問題。當 QA 退回東西時，截止日期就會滑掉。當回歸錯誤出現在演示中時，信任就會蒸發。
對這些團隊來說，一個生產環境 bug 不是五分鐘的修復。它是一整天的壓力。是與利害關係人的對話。是他們信譽上的凹痕。
他們需要精英團隊不需要的東西：一個讓 AI 輸出值得信賴、而不需要精英判斷力的框架。他們需要 guardrails，在合併之前就捕捉到 boundary 違規。他們需要 contract tests，能夠獨立驗證行為。他們需要 CI，能夠強制執行規則，這樣他們就不必對每一次 AI 產生的變更都提心吊膽。
他們需要 Autotomy，不是因為他們是糟糕的工程師。他們需要 Autotomy，是因為他們是普通的工程師，在普通的組織中工作，在那裡穩定性很重要，犯錯會有後果。
精英團隊也需要 Autotomy 嗎？
或許。
精英團隊能夠勢如破竹，是因為他們的工程師可以從任何事情中恢復。但恢復仍然需要時間。即便是 Anthropic 的工程師，也會花幾個小時修復那些一個嚴格的 boundary 本可以防止的 bug。即便是最好的直覺，當 codebase 變得足夠大時，也會遺漏邊界情況。
問題在於，預防的成本是否低於恢復的成本。對於一個能在幾分鐘內修復任何 bug 的團隊來說，預防可能感覺像是額外負擔。既然可以直接修復違規，為什麼要強制執行 boundary？既然可以用肉眼檢查整合，為什麼要寫 contract test？
但團隊不會永遠保持精英水準。工程師會離開。codebase 會成長。在第一年能捕捉到每一次糟糕 refactor 的直覺，到了第三年就會被拉伸得稀薄。那位了解每一個隱含依賴關係的工程師調到了另一個團隊。在一萬行程式碼時奏效的勢如破竹策略，到了十萬行時就變成了負債。
Autotomy 不會拖慢精英團隊。它讓他們的速度變得可持續。它將他們的判斷力編碼成規則，使其能夠承受人員流動和規模增長。它將個人的專業知識轉化為團隊的基礎設施。
這對你的團隊意味著什麼
如果你屬於第一類——那些嘗試過 AI、被燙傷、失去信心的團隊——你並不孤單。你是大多數。AI 程式設計的論述被一種現象扭曲了：看著精英操作者的工作，然後假設他們的工作流程可以平移到你的環境中。無法平移。
你的團隊不需要變成 Anthropic。你需要一個系統，讓 AI 的輸出足夠安全，讓你能夠信任它。這意味著嚴格的 boundary。這意味著確定性的強制執行。這意味著一個框架，在這個框架中，違規會在送到 QA 之前就讓建置失敗，正如我們在《AI 在生產環境中的程式設計：為什麼大多數團隊會放棄》中所描述的。
因為真相是這樣的：AI 在生產環境中的程式設計，問題不在於模型是否夠好。問題在於你的系統是否結構化得足夠好，以至於模型無法犯下代價高昂的錯誤。精英團隊透過判斷力來達成這一點。其他人需要 guardrails。
目標很簡單。用 AI 來發布功能。安睡整晚。醒來時沒有來自老闆的憤怒訊息。
關於 AI 程式設計鴻溝的常見問題
為什麼 AI 程式設計對某些團隊有效，對其他團隊無效？
精英團隊擁有深厚的系統直覺，能夠即時發現 AI 產生的錯誤並從中恢復。大多數團隊沒有這種直覺。沒有 guardrails，每一次 AI 產生的變更都像是一場賭博。當賭博失敗時，團隊失去信心並停止使用 AI。
精英團隊真的會產出有 bug 的程式碼嗎？
是的。即便是頂尖的工程組織也會發布 bug。差別在於他們的恢復速度。一個普通團隊需要花一天來診斷和修復的 bug，精英團隊只需要幾分鐘。他們把 bug 視為運營噪音，而非存亡威脅。
嚴格的 guardrails 會拖慢精英團隊嗎？
起初會。設置 boundary 和 contract tests 需要時間。但一旦到位，強制執行是自動的，而且只需幾秒就能完成。長期的好處是，隨著 codebase 成長和工程師輪調，團隊的速度變得可持續。
普通團隊應該先做什麼？
在產生程式碼之前定義 module interface。在 CI 中以規則強制執行這些 interface，讓建置失敗。加入 contract tests，獨立於完整系統來驗證行為。這三步讓 AI 的輸出變得足夠可預測，以至於 QA 不再退回所有東西。更深入的做法，請參閱《AI Codebase 的確定性 Guardrails》。
目標是零 bug 嗎？
不是。目標是可信任的 AI 程式設計。這意味著 bug 保持在局部範圍內、可診斷、並且可以被引入它的同一個模型修復。這意味著團隊在第六個月仍在使用 AI，而不是在第三週就放棄。