−25%

Windows 年繳方案適用,至 10 月 31 日。 檢視方案

EQVPS
開始使用

用於程式碼審查和 PR 檢查的沙箱:批准之前先證明修補程式有效

讀 diff 只能知道修補程式聲稱做了什麼,執行它才知道是不是真的。把 pull request 拉進一次性 microVM,在修改前後復現 bug,跑測試,用證據做審查——每次大約半美分。

diff 顯示的是修補程式聲稱要做什麼。它不會顯示 bug 是否真的消失了、某個 if 的新分支是否會被執行,或者依賴升級是否會在全新安裝時破壞 import。審查者都明白這一點,所以很多審查都以「LGTM,前提是測試透過」結束。

對於 AI 編寫的修補程式,這個缺口更大。模型能很快寫出看似合理的程式碼,而看似合理恰恰最容易從疲憊的審查者眼皮底下溜過。便宜的解決辦法是在任何人批准之前先執行這個改動——在一個它傷害不到任何東西的地方。

檢查:base、head、測試

修補程式能提供的最有說服力的證據,是一個在舊程式碼上失敗、在新程式碼上透過的復現。沙箱把它變成一段 20 行的指令碼。沙箱是一台 Firecracker microVM,內建 Python 3.12、Node.js 22、git 和 curl,大約一秒啟動:

import os
from eqvps import Sandbox

REPO, BASE, HEAD = os.environ["REPO_URL"], os.environ["BASE_SHA"], os.environ["HEAD_SHA"]

def repro(sb, ref):
    sb.exec(f"cd /root/app && git checkout -q {ref}", timeout=55)
    return sb.exec("cd /root/app && python3 /root/repro.py", timeout=55).exit_code

with Sandbox.create(tariff="standard", ttl=1800) as sb:
    sb.exec(f"git clone -q {REPO} /root/app", timeout=55)
    sb.exec("cd /root/app && pip install -q -r requirements.txt", timeout=55)
    sb.upload("/root/repro.py", open("repro.py").read())
    before, after = repro(sb, BASE), repro(sb, HEAD)
    tests = sb.exec("cd /root/app && python3 -m pytest -q", background=True).wait()
    print(f"repro on base: {before}, on head: {after}; tests: {tests.state}, exit {tests.exit_code}")

repro.py 是 bug 報告裡的程式碼片段。如果它在 base 上以非零狀態退出、在 head 上以零退出,說明修補程式確實修復了它聲稱修復的問題。把這一行連同測試摘要作為評論發到 pull request 上,審查者就能從事實出發。

測試套件作為背景任務執行,因為單條同步指令會在 55 秒時停止。30 分鐘的 TTL 限制了卡住的執行最多能計費多久。

會執行程式碼的審查代理

同樣的思路也適用於 AI 審查者。透過 MCP 伺服器連線後,代理擁有沙箱工具:建立沙箱、執行指令、上傳和下載檔案。它不會寫「這可能破壞與 Python 3.8 的相容性」,而是拉取分支、執行程式碼、引用 traceback——或者報告一切正常。

給這樣的代理設定消費上限和唯讀 token,並決定它可以不經詢問呼叫哪些工具。MCP 安全防護按風險列出了每個工具。

選哪個方案

儲存庫方案典型一次大致費用
小型庫,純 Python 或 JSsmall(0.5 vCPU,1 GB)2 分鐘$0.0011
帶測試套件的 Web 應用standard(1 vCPU,2 GB)5 分鐘$0.0055
原生擴充、需編譯的依賴plus(2 vCPU,4 GB)15 分鐘$0.033

臨時沙箱按秒計費,最少 60 秒。如果審查者想在幾天內反覆回到同一個環境,就把它建立為 persistent:它會保留磁碟最多 30 天,按每個開始的小時計費,所以為兩天審查保留的 standard 沙箱約 $3.17。pull request 合併後就刪除它。

值得了解的限制

  • 每個帳戶同時兩條指令。 對於一個接一個進行的審查來說足夠了。如果同時檢查幾十個 pull request,它們會排隊。
  • 沒有對內埠。 無法在瀏覽器裡開啟應用。在沙箱內啟動它,再從第二條指令用 curl localhost 測試。
  • 內部沒有 Docker。 需要啟動容器的測試應該放在 VPS 上的 runner 中。
  • 對外網路是開放的。 正因如此 pip install 才能工作。不要把任何您不會交給修補程式作者的東西放進沙箱。

開始使用

新帳戶可獲得 $1 的沙箱時長,足夠在 standard 方案上做一百多次審查。沙箱頁面列出了方案,SDK 參考包含上面用到的每個方法,5 分鐘上手 Python SDK 介紹了設定。

相關閱讀:面向完整流水線的隔離 CI 測試執行,以及面向編寫程式碼的代理的AI 代理沙箱。

準備好部署了嗎?以加密貨幣付款,免 KYC——大約一分鐘上線。

立即部署 →

常見問題

這和在 pull request 上跑 CI 有什麼區別?

CI 回答的是現有測試是否透過。審查檢查回答的是修補程式是否做到了它聲稱的事:在舊程式碼和新程式碼上分別執行 bug 報告裡的復現步驟,嘗試審查者擔心的邊界情況,並保留一個沙箱供審查者自己探查。兩者配合得很好。

AI 審查代理能用嗎?

能,而且在這裡收益最大。透過 MCP,代理獲得建立沙箱、執行指令和讀取檔案的工具。它不再猜測某個改動會不會弄壞什麼,而是直接執行程式碼,並在審查意見中引用輸出。

拉取陌生人的 pull request 安全嗎?

這正是沙箱的用途。程式碼在擁有獨立核心的單獨 microVM 中執行,裡面除了您放進去的東西,沒有任何屬於您的內容。不要傳入能寫您儲存庫的 token;私有儲存庫用唯讀 token 就夠了。

能在瀏覽器裡開啟 pull request 中的應用嗎?

不能。沙箱沒有對內埠,外部無法連入。您可以在沙箱內啟動應用,再從另一條指令用 curl 測試;如果審查者需要點選介面,可以把預覽部署到 VPS 上。

一次審查要花多少錢?

一次典型的審查——克隆、安裝、復現兩次、跑測試——在 standard 方案上需要幾分鐘,約 $0.005。按秒計費,最少 60 秒,從預付餘額扣除。

評論

目前還沒有評論。歡迎成為第一位。

發表評論

評論在顯示前會經過審核。