可評審 diff

在實踐中

可評審是產物的屬性，不是對評審者是否盡責的度量。一個工程師讓 agent「做個客服退款應用」，半小時後拿到一個寫著 +8,142 −0 的 PR，她只剩兩個壞選項：假裝自己審過並點下合併，或者真的去讀八千行她沒寫過的程式碼——讀到那個份上，還不如自己寫。測試過了並不能補上這道缺口：綠色的 CI 證明的是程式碼對它自己自洽，不是程式碼只做了它被允許做的事；而且測試是同一個 agent 寫的，它自然會測「能查到退款」，不會去測「該不該查到別人的退款」。

定義的 diff 之所以比生成實現的 diff 可評審，差別是結構性的，而不是程度上的。體量只是第一層：同一個行為改動——客服不再能刪除退款、金額超過 500 需要財務審批——在定義裡是十幾行宣告，在實現裡是散落在控制器、模板、遷移腳本和測試裡的幾百行。第二層是詞彙：這十幾行是用「誰可以做什麼」的語言寫的，於是有業務權限批准這項改動的那個人，恰好也是讀得懂它的那個人；評審的問題從「我讀得完嗎」變成了「這條權限對不對、這個審批閾值合不合理」。第三層最容易被忽略，是影響半徑：一份定義只能改動它所宣告的東西，所以 agent 順手改掉的那段對賬邏輯，從一條權限宣告根本夠不著。實現的 diff 沒有這種邊界——裡面任何一行都可能碰到任何東西。

有兩條限制屬於定義本身，不該塞進腳註。第一，不是所有東西都能收斂成宣告：一套全新的即時演算法、一條獨一無二的渲染管線，交回來的仍然是需要有人逐行讀的程式碼，硬塞進後設資料只會讓評審更糟。第二，可評審轉移了信任，而不是消除了信任——你不再逐個評審每個生成的應用，但你把這份保證押在了一個執行時上，它必須被認真審計一次並持續維護。審一次勝過審一千次，但它仍然是一筆交易，就該被當作交易說清楚。

ObjectStack 做的是這筆交易裡「定義的 diff」那一側：agent 交回來的是帶型別的應用後設資料，而所有人依賴的強制執行住在一個共享的開放執行時裡，不隨每個應用重新生成一遍。檢驗方法本身沒變，也適用於任何聲稱做到這一點的工具——去看你的 agent 開出的下一個 PR，問一句：那個必須為它負責的人，讀得完全部嗎？