AIT vs Git worktree · 遊戲開發 benchmark
同一個 coding agent、同一款遊戲任務、兩種儲存庫工作流程。
我們讓全新的 GPT-5.6 Sol agent 維護同一款瀏覽器遊戲、完成相同任務。 一邊使用 AIT Task 與隔離 worktree，另一邊使用傳統 Git linked worktree； 接著比較兩邊做到「通過獨立功能驗收」各需要多少 provider token。
- 5 個具體遊戲開發任務
- 每個任務 20 組有效配對
- 每次 campaign：AIT 100 + Git 100
- GPT-5.6 Sol · max reasoning
實測結果
兩次完整 campaign 都量到 AIT 約少用三分之一 token。
範圍：五個遊戲任務與固定模型。兩次實驗分開分析，失敗與替補均有揭露；有效驗收結果包含獲准替補的執行。Token 用量不是美元費用估算，這些實驗也未量測高併發吞吐量。
主要指標讓五個 workload 權重相同；provider 原始總量只作描述性交叉檢查，不取代 workload 平衡結果。
| Campaign | Workflow | Token 節省 | 95% CI | Provider 原始總量 | 時間節省 | 證據歷史 |
|---|---|---|---|---|---|---|
| 已發布 baseline | Sprint off | 34.95% | 27.85–39.77% | AIT 46,300,272 / Git 70,140,925 低 33.99% | 21.04% | 執行 201 / 有效 200 |
| 自然檢查 replication | Sprint on | 36.28% | 28.26–41.83% | AIT 45,432,262 / Git 71,238,660 低 36.23% | 15.22% | 執行 203 / 有效 200 |
…b004-gd-05-ait；不是生成圖片，也不是另外製作的 mockup。
Agent 到底在改什麼
一款現成、可重現的瀏覽器射擊遊戲。
測試 fixture 是不依賴第三方套件的 JavaScript 遊戲 Starline Defender。它原本就有移動、敵人、計分、暫停、 replay、設定、鍵盤控制與回歸測試介面。所以這裡量測的是維護既有程式、 修 bug、加功能與重構，不是請 agent 從零生成一款遊戲。
可玩頁直接發布其中一個 100/100 通過的 AIT session 公開網頁檔案， 讓你親自理解 evaluator 檢查的產物。它只用來展示產物類型；下方統計 使用所有有效 session，不是拿這一個案例來計算或挑最好看的結果。
五個 workload
從單一回歸修復，一路增加到 beta 發布整備。
每個 session 只會收到以下一份凍結任務規格，以及相同的驗收契約；任務規模刻意逐步加大。
阻止子彈異常連發
修復射擊回歸，確保既有的 180 ms firing cooldown 確實生效，同時不能破壞正常遊玩。
加入需要兩次命中的裝甲敵人
外觀必須容易辨識、命中兩次才會摧毀，而且擊破時必須正好得到 250 分。
修復暫停／繼續後 replay 分歧
暫停期間必須凍結時間與輸入，使錄製的 replay 在繼續後仍收斂到相同最終狀態。
安全拆分單體 game.js
抽出 model、renderer 與 input 模組，同時保持原有遊戲行為與 public API 不變。
完成可發布的 beta 產物
加入有版本的 replay、設定正規化、行動裝置輸入、focus recovery、benchmark panel、release check 與文件，而且不能新增 dependency 或對外連線。
一組配對怎麼跑
同一個任務跑兩次，只有儲存庫 workflow 不同。
- 從完全相同的 bytes 開始。AIT 與 Git lane 收到相同 fixture、任務文字、模型 revision、reasoning effort 與驗證指令。
- 各開一個全新 agent session。每個 lane 都是新的 GPT-5.6 Sol max session 與獨立 workspace，不會沿用前一次對話。
- 套用一種 workflow treatment。AIT lane 使用 AIT Task lifecycle；Git lane 使用 temporary branch 與 linked worktree。
- 讓 agent 自然完成工作。兩邊都可以讀檔、修改、測試，並在有意義時使用 status 或 diff；prompt 不強制，也不禁止。
- 由獨立 evaluator 驗收產物。Harness 執行凍結的功能檢查並評分；只完成 workflow、但遊戲壞掉，不能算通過。
- 計入完整 provider usage。有效 session 的機器可讀 provider token 總量與經過時間，才進入配對分析。
AIT treatment
Task + 隔離 worktree
Agent 啟動 AIT Task，在綁定的 worktree 工作，可以建立中間 Snapshot，最後透過 Task closeout 完成。Baseline 關閉 sprint mode；replication 綁定一張精確 sprint card。
Git treatment
Linked worktree + temporary branch
Agent 在 temporary branch 的 Git linked worktree 內工作、提交結果、整合回乾淨的 target branch，最後移除暫時 worktree 與 branch。
200 個 session 怎麼組成
反覆執行配對，量到變異，而不是只比較兩個個案。
5 個 workload×20 組配對×2 種 workflow=200 個 session
每個 workload 納入 20 組 AIT／Git 配對，所以每次 campaign 都是 100 個 AIT 加 100 個 Git 有效 session。完整設計執行兩次，而且分開分析。已發布 baseline 共執行 201 個原始 session，形成 200-session 有效視圖；replication 共執行 203 個原始 session，形成另一份 200-session 有效視圖。所有排除與 replacement 都在後面逐項揭露。
數字代表什麼
先確認功能通過，再比較 provider 成本，並呈現不確定性。
有效驗收
凍結 evaluator 會檢查啟動、必要功能、決定性、分數門檻、workflow closeout，以及不得使用外部 dependency 或 network。每次 campaign 的兩邊有效驗收都是 100/100。
Provider token
成本取自每個有效 agent session 的 provider 機器可讀 total-token usage，不是用指令數量或最終 patch 大小推算。
Workload 平衡節省
先在五個 workload 各自計算 AIT 的相對 token 節省，再取其中位數，避免最大的 GD-05 單獨主導 headline。
95% 信賴區間怎麼讀
分析在每個 workload 內對觀察到的 20 組配對重抽樣 2,000 次，每次重算 workload 平衡後的節省，再取 bootstrap 結果中間 95%。如果區間跨過零，就代表方向仍不確定；兩次 campaign 與每個 workload 的區間都高於零。這個區間描述此測試設計的抽樣不確定性，不代表每個 repository 或任務都一定能省同樣比例。
逐任務結果
兩次 campaign 的每個 workload 都偏向 AIT。
已發布的 1.1.0 sprint-off baseline
| Workload | AIT 有效 token | Git 有效 token | Token 節省 | 95% CI | 配對 |
|---|---|---|---|---|---|
| GD-01 | 213,481.0 | 317,517.8 | 32.77% | 22.07–41.92% | 20/20 |
| GD-02 | 266,652.6 | 428,522.2 | 37.77% | 27.59–45.66% | 20/20 |
| GD-03 | 376,821.3 | 496,364.8 | 24.08% | 12.41–34.32% | 20/20 |
| GD-04 | 580,373.9 | 915,416.8 | 36.60% | 25.68–45.84% | 20/20 |
| GD-05 | 877,684.7 | 1,349,224.8 | 34.95% | 22.36–44.82% | 20/20 |
Sprint-on 自然檢查 replication
| Workload | AIT 有效 token | Git 有效 token | Token 節省 | 95% CI | 配對 |
|---|---|---|---|---|---|
| GD-01 | 254,455.2 | 363,422.4 | 29.98% | 15.11–41.62% | 20/20 |
| GD-02 | 286,894.6 | 454,931.1 | 36.94% | 26.82–46.31% | 20/20 |
| GD-03 | 355,256.8 | 557,551.1 | 36.28% | 22.92–47.19% | 20/20 |
| GD-04 | 636,606.8 | 904,065.0 | 29.58% | 21.19–37.73% | 20/20 |
| GD-05 | 738,399.7 | 1,281,963.4 | 42.40% | 34.53–49.32% | 20/20 |
在各自的凍結分析中，兩次 campaign 的每個 workload 區間都高於零。
執行歷史
功能失敗與主機中斷都保留在公開紀錄。
Baseline：執行 201 個 session，形成 200 個有效 session
原始 AIT GD-05 沒有保留 soundEnabled: 0，因此未通過凍結功能檢查。該結果保留在 ledger，依揭露的同 pin 政策只 replacement 一次；只有通過的 replacement 進入有效視圖。
Replication：執行 203 個 session，形成 200 個有效 session
三個來源執行被排除並揭露：一個受 executor infrastructure failure 污染的 GD-02 Git lane；一個在 terminal summary 產生前被主機關機中斷的 GD-05 Git lane；以及一個只獲准 replacement 一次的有效 GD-05 AIT 功能失敗。Infrastructure 與關機案例採 whole-pair recovery。另一個 recovered-spawn 分類以 digest-linked adjudication 修正，沒有重跑該 session。
公開紀錄保留 source_protocol_claim_eligible=false。Current policy revision game-development-2026-08-29.36 另行記錄 criteria 已滿足，並得到有效 claim_eligible=true；舊旗標沒有被抹除。
解讀邊界
對這組任務是強證據，但不是普遍定律。
兩次 campaign 共同支持
在這五個 fixture 與模型 pin 下，兩次分開分析都顯示 AIT 的 provider token 約低三分之一，同時維持相同的有效功能驗收。
這個比較不能證明
兩次 campaign 的 workflow mode、prompt、AIT binary、seed、日期與 recovery history 不同；樣本沒有合併，也不是 sprint-on/off 的因果 A/B test。結果不保證適用於每個 codebase、model 或 task，線性 session 也沒有量測 high-concurrency throughput。
稽核證據
每次 campaign 都有自己的不可變摘要、JSON、ledger 與 checksum。
已發布的 1.1.0 baseline
summary.txtBaseline 的可讀結果、方法與揭露。
result.jsonBaseline 的機器可讀整體與 workload 結果。
runs.jsonBaseline 的 session 納入、時間與 token ledger。
SHA256SUMS已發布 baseline 集合的完整性 hash。
Sprint-on 自然檢查 replication
結論
在這五個遊戲開發任務中，AIT 相較 Git worktree 約少用三分之一 provider token，而且完成相同的驗收結果。
兩次分開分析的 campaign 分別量到 34.95% 節省（95% CI 27.85–39.77%）與 36.28% 節省（95% CI 28.26–41.83%）。每個 workload 都偏向 AIT，兩邊有效驗收都是 100/100，而且兩個整體區間都高於零。