可問責的生成：意圖，才是留存記錄的產物

每一個認真的工程組織，都花了數十年圍繞著一種產物建立治理：原始碼。程式碼有版本控管、有審查、在上線前有簽核。這整套機制假設程式碼是人類判斷所在之處——因為自軟體成為一門產業以來，長久以來確實如此。

AI 輔助的生成打破了這個假設。當一套系統能從「應該存在什麼」的結構化描述中，產出數千行看似合理的程式碼時，程式碼就不再是那個昂貴的產物。變得稀缺的，是意圖：關於該建造什麼、在哪些限制之下、由誰為它負責的那個人類決策。

我經營一套 AI 原生的交付作業，其中大多數程式碼由代理產出，而這篇文章正是這套作業逼我得出的結論：留存記錄的產物應該是意圖，而程式碼應被視為受治理的輸出。

廉價的程式碼破壞了審查模型

程式碼審查之所以成為工程治理的核心，有其充分理由。程式碼是人類思考的結晶——生產緩慢、決策密集，也是錯誤在化為行為之前能被攔截的最後一道關卡。審查程式碼，就是在審查那份思考。

生成同時改變了兩端的經濟結構。輸出量的成長，快過任何團隊閱讀它的能力，所以逐行審查生成的程式碼追不上。較不明顯的是，這種審查也不再能攔截真正要緊的錯誤。當程式碼是被生成的，缺陷很少是某一行放錯位置，而是系統被要求去做什麼時，那個錯誤或缺漏的決策。把輸出讀得更用力，也找不出請求裡的瑕疵。

這不是在主張程式碼審查已死，而是在主張審查的對象必須往上移一層：從「這段程式碼正確嗎？」變成「這份意圖對嗎——而且我們能否驗證生成的系統確實忠於它？」這個問題的後半段確實困難，我會在後文回到它。

折舊測試

如今我對 AI 輔助工程堆疊中的每一項資產，都會套用一個問題：當模型變得更好時，這項資產會增值還是折舊？

業界今天所建構的大部分東西，都落在折舊的那一邊。任何價值主張是「更便宜地產出程式碼」的東西——鷹架工具、樣板函式庫、主要職責是省下生成心力的中間層——每一次模型改版都會流失一部分價值，因為前沿模型不斷吸收掉這些層當初被創造來節省的那些工作。

作為受治理記錄的意圖，落在另一邊——但理由比「人類來寫規格」更狹窄。模型也能協助草擬規格；意圖的生產並非對自動化免疫。模型無法供給的，是問責。它無法承擔責任、無法簽名，也無法向稽核員或事件檢討交代。當生成的程式碼趨近免費，稀缺的那一層不是撰寫意圖——而是擁有它。附著在「擁有權」這一層上的治理會增值，理由和附著在「輸出」那一層上的工具會折舊，是同一個。

即使你否定這篇文章裡的其他每一項主張，這個測試仍值得保留。把它套用在你自己的工具鏈與路線圖上：你正在建構的東西裡，哪些會被一個更好的模型直接吸收掉？

「留存記錄的產物」究竟是什麼意思

留存記錄的產物，不是一份剛好存在於某處的文件。它是你的組織視為權威的那個產物——治理真正附著其上的那一個。當以下四件事成立時，意圖才成為留存記錄的產物：

• 可版本控管。 這份規格有歷史。你能看見系統上一季本應是什麼樣子，以及是誰改動了它。
• 可比對差異。 對系統的一次變更，被表達為對意圖的一次變更——一份可讀的決策差異，而不是一萬行重新生成的輸出。
• 可稽核。 當有人問系統為何如此運作時，這條線索止於一個被記錄的人類決策，而不是止於一份生成日誌。
• 可簽核。 核准發生在意圖這一層，在這裡核准者能理解自己正在核准什麼。

這一切都沒有把程式碼貶為無關緊要。程式碼仍是那個會運行、會失敗、會被攻擊的東西；它仍必須被測試、掃描與檢視——而且在生成的量級下，這道驗證本身就是一筆嚴肅的成本，而非一個註腳。

這裡描述的終局狀態，就像原始碼對編譯後二進位檔的關係：下游的產物被驗證與部署，但權威存在於上游。我必須誠實面對這個類比所假設的東西。編譯是確定性的；今天的生成不是。從同一份意圖重新生成，不能可靠地產出同一個系統，這意味著意圖層級的差異比對與回滾，目前仍是揹著工程債的抱負，而非你能直接買到的性質。當前狀態與終局狀態之間，橫亙著兩個尚未解決的問題：重新生成的確定性，以及意圖的驗證——如何在不重讀每一行的前提下，檢查生成的系統忠於它的意圖。從意圖衍生出的測試與屬性是顯而易見的候選;把任一問題稱為已解決都是不誠實的。這篇文章所主張的更為狹窄，而且不必等待：治理應該現在就附著在意圖這一層，因為一個等待這些問題被解決的組織，會在這段等待的歲月裡，持續交付出「沒有人記錄下其緣由」的系統。

這件事最先要緊之處：受監管的情境

有些環境裡，這個轉變目前還是選配——也有些環境裡，它就是整個問題本身。在金融、醫療與政府系統中，「是代理做的」不是一個可接受的答案。一位稽核員、一位監管者，或一個事件檢討委員會，需要這條線索止於一份人類可讀、由具名者核准的記錄。

受監管的工程會立刻認出這個論點的一部分，因為它治理意圖產物已有數十年：需求基線、變更請求、追溯矩陣。這些紀律存在，其背後的預算也是真實的。生成所改變的，是權威的方向。過去，需求是一份文件，它以人力與持續的漂移，追溯到人們手寫的程式碼。當規格就是生成系統的那個東西時，追溯不再是事後維護的一層疊加：意圖的記錄與軟體的來源，成為同一個產物。這不是一門新的合規紀律，而是舊的那一門，終於附著到它一直想治理的那一層上。

我應該精確說明這個主張的狀態：它是一個關於契合度的論證，而非一份回報的結果。但它要求受監管的組織去延伸一門他們已經在資助的紀律，而不是去採用某種陌生的東西。

我今天如何經營這套模式

我自己的交付作業，正以小規模運行在這套模式上。每一個重大決策，都連同它的脈絡與備選方案，落入一份僅可追加的帳本。工作不在測試通過時算完成;它在通過「要求證據而非斷言」的關卡時才算完成。簽核發生在意圖這一層，而「誰、基於什麼理由、核准了什麼」的記錄，比實作它的那段程式碼活得更久。

那是實踐，不是證明：一套小型作業，由提出這個論點的人親自經營。我提出它，是因為它是透過交付、而非透過書寫塑造出這個立場的，也因為它讓收尾的那幾個問題變得具體，而非流於修辭。

如果你想知道自己的組織站在哪裡，三個問題能很快切中要點：

1. 你的規格有版本歷史嗎——還是它是一份在啟動會議後就不再準確的簡報？
2. 當一位核准者為一次發版簽核時，他實際上在讀的是什麼？
3. 當出了差錯時，你的稽核線索指向哪一層——一個被記錄的人類決策，還是一堆沒有人寫過的生成程式碼？

程式碼過去昂貴，所以我們治理程式碼。程式碼正在變得廉價，而治理尚未跟著移動。那些把留存記錄的產物移到意圖層的組織，將會是仍然能回答「問責」最終總會歸結到的那個問題的組織：這件事是誰決定的，又是基於什麼理由？