當AI寫代碼快過審查：Shipmoor如何堵上信任漏洞

Aymen 在云平臺、金融科技、開發者工具和電商基礎設施領域做了十五年平臺可靠性工程師，現在他把目光投向了一個越來越讓人頭疼的問題：AI 代理寫代碼的速度，已經遠遠超過了任何團隊能審查的速度，而整個軟件交付鏈路里，驗證層卻一直沒跟上節奏。

過去，瓶頸總是卡在“寫出代碼”這一步。如今，瓶頸變成了“敢不敢讓這些代碼跑到生產環境里”。Aymen 的感受很直接——目前的代碼審查機制，壓根不是為了面對 AI 代理這種生成速度而設計的。人類審查員也好，AI 審查員也罷，都是在讀一個 diff，然后憑感覺判斷“看起來有沒有問題”。但這套流程驗證不了代碼是否真的完成了需求提示里要求的事情，無法確認變更和它的預期規范是否對齊，更沒法用確定性的方式去核查那個代理是不是真的把“任務已完成”當成一句空話拋了出來。

于是，Aymen 動手構建了 Shipmoor，一個專門架在 AI 代理循環里的驗證層，目標就是把這個缺口給堵上。它的核心模塊叫 Claim Check。

Claim Check 的運作方式，是把你的驗收條件直接凍結成一組原子的、可檢查的待辦義務。這些條件可以從你的提示或工單里自動提取出來，再通過一次 git 提交敲定。接下來，每一條義務都必須綁定到真實的證據上，沒有例外。

具體來看，這些證據包括了構建是否通過；測試是否真正跑過并且捕獲到了異常——尤其要提防代理悄悄刪掉測試或者弱化斷言，只為了騙一個綠燈；還要對已知的 AI 代碼缺陷做確定性掃描；同時輔以 AI 輔助的深度代碼審查，以及變更前后的狀態比對。這樣一來，每一條斷言都有事實墊底，而不是靠人來猜。

Shipmoor 在這上面還加了一層安全封裝：每一份證據都被包裹在 in?toto 格式的證明里，最終的裁決則被打包成一條類 SLSA 的 Verification Summary Attestation（VSA），并且帶有自摘要。它做的事情，不是讓一個檢查重新跑一遍就信了那次的結果，而是比較兩次運行的輸出在字節級上是否完全一致。基于這些證據，一個確定性的閾值會做出最終評判。這整套機制的核心思想很清楚：AI 只負責給建議，證據才負責拍板。

在這個過程中，你帶進來的大語言模型（LLM）——也就是你自己的代理——只會去處理那些確定性方法實在綁定不到真實檢查的殘余義務。即便是面對這些義務，它也只有兩個動作可以做：要么指著一個具體的分歧點把它攔下，要么坦白說自己判斷不了。它永遠不會有直接放行的權限。

把整個閉環走一遍，大致是這樣的：你的 AI 代理先做出一處代碼變更。Claim Check 接著嘗試把每一條驗收義務綁定到內部真實的證據上。一旦綁定不上，它不會假設“大概通過了”，而是返回一個確切的原因，并把所有尚未可驗證的項目標記為“未解決”。無論哪種情況，代理都會收到一份修復檢查清單，上面清清楚楚寫著它還需要滿足哪些檢查。代理根據這份清單寫出修復代碼，系統就再次用同樣的義務條款去校驗它。如此往復，直到所有檢查都驗證通過，這一次運行才會返回一個 READY 狀態。

Aymen 還放出了一個三分鐘的終端操作演示，用來展示這個閉環在命令行下是怎么跑起來的。如果你親眼見過那種“代理聲稱任務完成、實際上漏了一大片”的場景，就能立刻感受到這種可驗證的確定性檢查到底意味著什么。

Claim Check 雖然是 Shipmoor 的軸心，但并不是它唯一的功能。比如 Test Evidence 模塊，專門盯著測試是不是真正執行過并且通過了，一旦發現代理悄悄地刪除了某個測試，或者把一個原本會失敗的用例掏空成永遠綠的擺設，它就會立刻把這事揪出來。再比如 Agent Harness，它就像一道閘門，把 Claude Code、Cursor、Codex 這些代理卡在編輯循環的內部，只要還存在阻塞問題，代理就不能把一次變更標記成“已完成”。

還有 Agent Skills，作用是把同一套驗證檢查以原生方式插入到 Codex、Claude 和 Cursor 里面——也就是開發者日常已經在使用的工作環境里。這樣一來，驗證層就不再是事后才跑一遍的附加腳本，而是和代理的每一次編輯動作纏繞在一起的實時制約。

整套 Shipmoor 的設計邏輯，說白了就是要把代碼生成和代碼驗證拉到同一個量級上。當 AI 代理能以分鐘為單位產出海量變更時，原來那種靠人逐行閱讀 diff 的信任機制早就站不住腳了。Shipmoor 給出的答案不是“更勤快地審查”，而是“讓證據替我們做決定”。

Aymen 在這里面嵌入了一種非黑即白的哲學：AI 可以猜，但驗證必須實打實。代碼審查這件事，從此不再是對“看起來對不對”給出一個意見，而是變成了一組確定性的規則，去核對“到底有沒有做到”。從平臺可靠性工程師的視角出發，這種轉變或許正是讓 AI 代理真正走向生產環境的最后一塊拼板。