可問責的生成:意圖才是正式紀錄

每一個認真的工程組織,都花了數十年圍繞著同一個產物建立治理:原始碼。程式碼有版本控制,程式碼有審查,程式碼上線前要簽核。這整套機制假設程式碼是人類判斷所在之處——因為在軟體成為一門產業以來的時間裡,它確實是。

AI 輔助生成打破了這個假設。當一個系統能從一份結構化的描述產出數千行看起來合理的程式碼,程式碼就不再是昂貴的產物。變得稀缺的是意圖:關於該建造什麼、在哪些約束之下、由誰承擔責任的人類決定。

我經營一個 AI 原生的交付作業,大部分程式碼由 agent 產出,而這篇文章是實際營運逼出來的結論:正式紀錄的產物應該是意圖,程式碼應該被當作受治理的輸出。

便宜的程式碼打破了審查模型

程式碼審查會成為工程治理的核心,是有充分理由的。程式碼是人類思考的結晶——產出緩慢、決策密度高,而且是錯誤在變成行為之前最後能被攔下的地方。審查程式碼,就是審查思考。

生成同時改變了兩邊的經濟。輸出量的成長快過任何團隊閱讀它的能力,所以對生成程式碼逐行審查追不上。更不明顯的是,它也不再能抓到真正要緊的錯誤。當程式碼是生成的,缺陷很少是某一行放錯了位置;它是系統被要求做的事情裡,一個錯誤或缺席的決定。把輸出讀得再用力,也找不出請求本身的瑕疵。

這不是在主張程式碼審查已死。這是在主張審查的對象必須上移一層:從「這段程式碼對不對?」變成「這個意圖對不對——而我們能否驗證生成的系統遵守了它?」後半個問題是真的難,下文會再回來談。

折舊測試

現在有一個問題,我會拿來檢驗 AI 輔助工程堆疊裡的每一項資產:當模型變得更好,這項資產是增值還是折舊?

業界今天在建造的東西,多數落在折舊的一側。任何價值主張是「更便宜地產出程式碼」的東西——scaffolding 工具、模板庫、主要工作是節省生成成本的中間層——每一次模型改版就損失一片價值,因為 frontier model 不斷吸收的,正是這些層當初被造出來要節省的工作。

作為受治理紀錄的意圖落在另一側——但理由比「規格是人寫的」更窄。模型也能幫忙起草規格;意圖的產出並非對自動化免疫。模型無法提供的是問責。它不能承擔責任,不能簽名,不能對稽核員或事故檢討會作答。當生成的程式碼趨近免費,稀缺的那一層不是寫出意圖——而是擁有它。附著在擁有權層的治理會增值,理由和附著在輸出層的工具會折舊是同一個。

就算你拒絕這篇文章的其他每一個主張,這個測試也值得留著。拿它跑一遍你自己的工具鏈和 roadmap:你正在建造的東西裡,哪些會被一個更好的模型直接吸收掉?

「正式紀錄的產物」到底是什麼意思

正式紀錄的產物,不是一份剛好存在某處的文件。它是你的組織視為權威的那個產物——治理真正附著的那一個。當四件事同時成立,意圖就成為正式紀錄的產物:

• 有版本。 規格有歷史。你能看到上一季這個系統應該是什麼樣子,以及是誰改了它。
• 可 diff。 對系統的一次變更,表達為對意圖的一次變更——一份可讀的決策 diff,而不是一萬行重新生成的輸出。
• 受稽核。 當有人問系統為什麼是這樣的行為,追溯的終點是一筆有紀錄的人類決定,而不是一份生成 log。
• 有簽核。 核准發生在意圖層,核准的人能理解自己核准的是什麼。

這些都沒有把程式碼貶為無關緊要。程式碼仍然是實際運行、實際失敗、實際被攻擊的東西;它仍然必須被測試、掃描、檢視——而在生成的量級下,這種驗證本身就是一筆可觀的成本,不是註腳。

這裡描述的終局,就是原始碼與編譯後 binary 的關係:下游的產物被驗證、被部署,但權威在上游。我必須誠實面對這個類比的前提。編譯是決定性的;今天的生成不是。從同一份意圖重新生成,並不能可靠地產出同一個系統,這表示意圖層的 diff 與 rollback 目前是背著工程債的期望,不是買得到的性質。從現狀走到終局之間橫著兩個未解問題:再生成的決定性,以及意圖驗證——如何不重讀每一行就檢查生成的系統遵守了它的意圖。從意圖推導出的測試與性質是顯而易見的候選;宣稱任一問題已解決都是不誠實的。這篇文章主張的東西更窄,而且不必等:治理現在就該附著到意圖層,因為一個等這些問題被解決的組織,會在這段期間持續交付一批沒有人記下理由的系統。

這件事最先要緊的地方:受監理的情境

有些環境裡,這個轉移暫時還是可選的——也有些環境裡,它就是問題的全部。在金融、醫療、政府系統裡,「是 agent 做的」不是一個可以接受的答案。稽核員、監理機關、事故檢討委員會需要的,是追溯的終點停在一份人類可讀、由具名者核准的紀錄。

受監理的工程領域會立刻認出這個論證的一部分,因為它治理意圖產物已經數十年了:需求基線、變更申請、追溯矩陣。這些紀律存在,背後的預算也是真的。生成改變的是權威的方向。過去,需求是一份文件,靠人力、帶著持續的漂移,追溯到人手寫出來的程式碼。當規格就是生成系統的東西,追溯就不再是事後維護的覆蓋層:意圖的紀錄與軟體的來源成了同一個產物。那不是一門新的合規紀律。那是舊的那一門,終於附著到它一直想治理的那一層。

我應該對這個主張的狀態說得精確:這是一個關於適配性的論證,不是一個回報出來的結果。但它請受監理的組織延伸一門他們已經在出錢維持的紀律,而不是採納什麼外來的東西。

我今天怎麼實行

我自己的交付作業就以這個模型運轉,規模很小。每一個重要決定都進入一份 append-only 的 ledger,連同它的脈絡與被否決的替代方案。工作不是測試通過就算完成;是通過了要求證據而非口頭宣稱的 gate 才算完成。簽核發生在意圖層,而誰核准了什麼、依據是什麼的紀錄,比實作它的程式碼活得更久。

那是實踐,不是證明:一個小型作業,經營者就是提出論證的人。我提出來,是因為這個立場是靠交付、而不是靠寫作形成的,也因為它讓收尾的幾個問題變得具體,而不是修辭。

如果你想知道自己的組織站在哪裡,三個問題可以很快切中要害:

1. 你的規格有版本歷史嗎——還是一份最後一次準確是在 kickoff 時的簡報?
2. 核准者簽核一次 release 時,他實際在讀的是什麼?
3. 出事的時候,你的稽核軌跡指向哪一層——一筆有紀錄的人類決定,還是一堆沒有人寫過的生成程式碼?

程式碼曾經昂貴,所以我們治理程式碼。程式碼正在變得便宜,而治理還沒有移動。把正式紀錄移到意圖層的組織,才會是仍然回答得出問責最終那個問題的組織:這是誰決定的,依據是什麼?