Zeroshot：讓寫程式碼的 AI 不能給自己打分，用獨立評審與有界修復迴圈交付程式碼

它要解決的問題

AI 編碼代理最常見的毛病，不是寫不出程式碼，而是寫完之後自己宣佈「已經好了」。同一個模型既負責實現，又負責驗收，等於讓考生給自己判卷。

Zeroshot 的核心主張只有一句話：寫程式碼的代理，不應該是決定程式碼能不能用的那一個。專案團隊在自述裡說，他們做這個工具，是因為受夠了被代理「煤氣燈式」地誤導，明明是壞程式碼，卻被告知可以交付。

核心架構：顯式的多代理圖

Zeroshot 把一個軟體目標變成一張顯式的多代理圖。圖中有一個代理負責實現，若干個獨立代理負責評審。評審不透過，任務就進入一個有上限的修復迴圈。只有圖裡設定的全部檢查都透過，成果才會被交付。實現程式碼的代理永遠不能批准自己的工作，這是整個設計的硬約束。

定位同樣關鍵。Zeroshot 不替代 Claude Code、Codex 或 GitHub Copilot，而是把其中之一當作 worker 和 reviewer 來執行。也就是說，它不是又一個編碼模型，而是套在現有編碼代理外面的編排層與問責層。使用者可以使用內建的圖，也可以自帶拓撲：增加評審者、測試和修復迴圈，再把這套配置儲存為 profile，留給下一個任務複用。

工作機制與使用流程

安裝只需一條命令：npm install -g @the-open-engine-company/zeroshot。安裝器要求 Node.js 18 或更高版本，併為 Linux x64/arm64、macOS x64/arm64 或 Windows x64 安裝一個經過校驗的原生二進位制。它還會在使用者級別，為 Codex、GitHub Copilot 和 Claude Code 安裝同一個 Zeroshot skill。 本地執行時，使用者需要先安裝並登入 Codex、Claude Code 或 GitHub Copilot 之一。Zeroshot 可以直接複用該工具已有的登入狀態，包括訂閱制會話。 執行一個任務需要兩個 JSON 檔案。input.json 描述任務，例如「給 status 命令增加 JSON 輸出，並補上針對性的測試」。runtime.json 指定執行時：harness（如 codex）、provider（如 openai）、model 和 effort（如 high）。隨後執行 zeroshot run，並指定 --template software-change 與 --uniform-runtime-config runtime.json。從引數名可以看出，這個選項讓圖中的各個代理共用同一份執行時配置。加上 --validate-only，可以先檢查圖、執行時配置和輸入是否合法，而不真正啟動。

有一個必須記住的事實：worker 會直接修改當前的 Git 工作樹。因此官方建議，在一個專門為該任務準備的乾淨工作樹裡啟動。

為什麼獨立評審是合理的工程選擇

以下是我們的分析，不是專案自己公佈的資料。第一，實現者和驗收者角色分離，可以打破自我確認的閉環：寫程式碼的上下文裡已經帶著「我這樣做是對的」的假設，換一個沒有這段歷史的代理來看，更容易發現遺漏。

第二，修復迴圈被設了上限，這在工程上很重要。沒有上限的「評審、修復、再評審」可能無限消耗額度，有上限則把成本和時間變成可預期的量。第三，把拓撲當成可配置的資料，而不是寫死的流程，團隊就能按任務風險調整：改一行文件用輕圖，改支付邏輯用多評審者加測試的重圖。

效能與成本

需要說清楚：我們讀到的材料裡沒有公開的基準測試數字，所以無法給出透過率、缺陷攔截率或延遲的提升幅度。README 裡的影片標註為指令碼化演示，只能算示意，不能當作證據。

可以確定的是成本結構：多個代理意味著更多的模型呼叫和更長的牆鍾時間。本地執行如果複用訂閱登入，邊際成本會落在訂閱額度上。雲端版本 Zeroshot Cloud 的定價，請檢視官網 zeroshot.sh。

對開發者與企業的影響

對個人開發者，Zeroshot 把「讓另一個代理再看一遍」這個手工習慣，變成一條可重複執行的命令。對團隊，它提供了一個與具體模型廠商解耦的驗收層：底層可以是 Codex，也可以是 Claude Code 或 Copilot。

專案採用 MIT 許可，透過 npm 分發，倉庫帶有構建、覆蓋率和文件的持續整合標記，說明它按正式軟體的方式維護。專案還聲稱有來自多家大型科技公司的工程師加星，這是專案方的自述，我們沒有獨立核實。

與常見做法的對比

目前多數團隊的做法，是讓同一個代理在一次對話裡寫完程式碼、跑完測試，再自己總結「全部透過」。這種流程的問題在於，驗收標準、實現過程和最終結論都出自同一個上下文，錯誤很容易被一併帶過。另一種常見做法是人工逐行審查，可靠但耗時，也難以隨任務數量擴充套件。

Zeroshot 走的是中間路線：把審查這一步交給獨立的代理，並把整個流程寫成圖，讓每一步的輸入、輸出和透過條件都清楚可查。人仍然可以在最後把關，但不必再從零開始檢查每一處改動。這套流程能否真正省下人力，還要看後續公開的資料。

侷限與挑戰

第一，沒有公開基準，價值主張目前主要靠設計邏輯支撐。第二，獨立評審的價值取決於獨立程度。如果評審者與實現者用同一個模型家族，它們可能共享同樣的盲區。

第三，有上限的修復迴圈意味著任務可能在上限內仍未透過，使用者要為這種結果設計後續處理。第四，worker 直接改寫當前工作樹，沒有乾淨的起點就有風險。第五，v8 是硬性的介面切換，用原生二進位制取代了 Node.js 執行時，舊版本的使用者需要遷移。

未來走向

如果專案方後續公佈可復現的基準，例如在同一批任務上對比單代理與帶評審圖的透過率和總成本，這類工具的價值就能被量化。

另一個值得關注的方向是 profile 的共享：團隊把針對不同風險等級調好的圖沉澱下來，會逐漸形成一套組織內的交付標準。無論如何，「寫的人不能自己驗收」這條原則，已經成為 AI 輔助程式設計裡越來越難迴避的工程底線。