本頁譯自英文文件。指令、識別名稱與範例保持原樣。執行環境 7.24.4 · SDK 2.6.7。 英文原文

已驗證的多模型變更

狀態：現行 範圍：現行狀態 上次審閱：2026-08-21 負責人：AX Code 執行環境

這是給這項工作的流程頁：「我有一項後果重大的變更，想對它多試幾次，並讓儲存庫自己的檢查決定哪一次值得留下。」

模式參考，也就是旗標、設定鍵與排序輸入，請見 執行模式。這一頁是從頭到尾的工作說明。

什麼時候值得

同時跑數個模型，成本是只跑一個的數倍。當變更後果重大，而且失敗要到後來才發現會很貴時，才划算：跨越模組邊界的重構、一次遷移、安全性敏感程式碼裡的修正，或你確實不知道哪一種作法才對的變更。

一行編輯、重新命名，或你讀過就能驗證的事情，都不值得。

兩種不同的工具

用 council 決定要做什麼。它把設計或審查問題散發給數個已連線的供應商，並把答案彙整成共識、嚴格多數、少數與單一發現，也可以加上匿名辯論回合。它是建議性質。模型之間的一致並不是正確的證明；它是這個問題有多受爭議的訊號。

用 arena 決定要留下哪一個實作。

arena implement 工作流程

1. 準備

實作模式需要一個 Git 專案，至少有一次提交，以及乾淨的主要工作樹。參賽者的工作樹從精確的基底提交建立，不能繼承未提交的變更，因此請先提交或暫存。

你還需要在已連線的供應商上，至少有兩個可分別選取、且彼此不同的模型（支援共用閘道），以及 modes.arena.enabled: true。

2. 執行

/arena <task description>

每個參賽者都會從已記錄的基底提交得到自己的 Git 工作樹，並在其中執行實作代理程式。參賽者不會修改你的主要工作樹。

3. AX Code 如何處理每個候選

• 把參賽者已追蹤以及未追蹤的變更快照成持久的分支提交，包含代理程式自己做的任何提交。
• 執行偵測到的專案驗證指令，也就是型別檢查、測試與 lint，但只在擷取到非空白修補之後。空白修補不能勝出。
• 預設以驗證優先排序：只有已完成、非空白，而且通過驗證的修補才有資格勝出。在通過的候選之中，它偏好風險較低、差異較大的修補。

4. 決定

報告會給你工作樹路徑、分支名稱與提交範圍。

AX Code 不會合併勝出者。 請自行檢查、合併或 cherry-pick。這是刻意的：驗證的意思是「你設定的檢查在這個修補上通過了」，這是真實的訊號，但不能取代審查。

5. 審查，必要時還原

候選進入你的工作樹之後，證據指令照常適用：

ax-code graph <sessionID>       # what the winning run actually did
ax-code risk <sessionID>        # heuristic risk signals for the change
ax-code session rollback <sessionID> --dry-run

請見 執行證據。

這裡的「已驗證」精確指什麼

它的意思是：專案偵測到的型別檢查、lint 與測試指令，曾對該候選的修補執行，而且通過了。

它不表示這項變更正確、完整、安全或設計良好。若你的測試套件沒有涵蓋被改到的行為，通過的候選只證明已經被涵蓋的部分沒有壞掉。驗證提高的是下限，並不認證上限。

它也不延伸到一般的互動式編輯。Arena 候選與有閘門的重構套用會執行檢查；一般工作階段中的普通 edit 或 write 不會自動這樣做。若要為一般執行記錄該證據，請執行 verify_project。

成本與失敗模式

• 成本隨參賽者增加。 每一個都會執行完整的實作代理程式。
• 不乾淨的工作樹會在其他事情發生之前停止這次執行，這是刻意的。
• 少於兩個彼此不同的模型會讓比較沒有意義，工具會回報這個情況，而不是編造排序。
• 所有候選都可能無法通過驗證。 這是有用的結果：通常表示工作規格不夠明確，或儲存庫的檢查比代理程式所假設的更嚴格。

相關內容

• 執行模式：council、arena 與其他模式的完整參考
• 執行證據：審查並還原結果
• 為什麼選擇 AX Code：為什麼驗證優先的排序是切入點
• 多模型路由的最佳做法：把高階工作與支援工作分開