Solo-Engine V4.1 Final：把「看似全能」的 Gem，改造成可稽核的工程助手

結論：V4 值得保留骨架，但不宜原樣上線

V4 已處理 AI 工程助手最危險的幾類問題：虛構搜尋與工具調用、把未執行的測試說成已通過、以片段程式碼冒充完整交付，以及沒有驗證證據就把 ADR 視為正式採納。這些修正方向是對的。

不過，V4 的下一步不應是繼續加規則，而是做減法與劃邊界。它目前最大的風險，是多份文件重複規範狀態、驗證、依賴與完成條件；規則愈密，模型反而愈可能只命中其中一部分。建議採用 Solo-Engine V4.1 Final：以短而硬的主指令固定底線，將流程細節、檢核表與工件格式放入知識庫。

V4 做對了什麼

V4 已建立一套具備工程誠信的閉環：

• 使用 FACT、INFERENCE、ASSUMPTION、UNKNOWN 隔離證據層級。
• 明確規定不能由提示詞虛構搜尋、Tavily、MCP、檔案系統、Git、編譯器或測試執行器。
• 將「完整程式碼檔案已輸出」與「程式已真實編譯、測試通過」分開。
• 引入 Plan、ADR、驗證紀錄、Truth Report 與狀態對帳，讓決策與交付能被追溯。
• 要求長篇交付只能在完整檔案邊界暫停，避免檔案被截斷卻被標示為完成。
• 將 BMAD 當作職責覆核的靈感來源，而非假稱已啟動多個獨立 Agent。BMAD 官方文件確實將 Agent、Skill、Workflow 與測試流程設計為具體的執行機制；單一 Gem 因此應稱為「BMAD-inspired role orchestration」，不能說等同於 BMAD 多 Agent Runtime。11014

V4 必須修正的五個問題

1. 主指令不能把關鍵規則全交給知識庫

知識庫是否每次都完整被召回，不能當作必然前提。因此，以下規則必須同時存在於 Gem 主指令：

• 不得虛構工具與執行結果；
• 完整程式碼的交付要求；
• 真實驗證與靜態檢查的差異；
• 工程完成的條件；
• 無執行器時必須停在 WAITING_VERIFICATION。

知識庫適合承載 SOP、範本、決策矩陣細節與情境化檢核；它不應是安全底線唯一的存放處。

2. 「自動循環」必須是有界循環，不是背景代理人

提示詞無法憑空創造背景任務、持久終端或跨會話執行能力。V4.1 應將自動循環限定為：

• 僅限目前回覆或目前會話；
• 僅限使用者已授權的工作範圍；
• 僅限目前真實暴露的工具能力；
• 有明確的停止條件與重試預算；
• 沒有執行器時，只能做靜態覆核並等待使用者回傳日誌。

這不是降低能力，而是避免把「可規劃的流程」誤說成「已自主運行的系統」。

3. 「零依賴」應改成可稽核的工程契約

「零依賴」容易同時被理解成不需 Runtime、不用第三方套件、也不依賴本地檔案；這三者其實不同。V4.1 的定義應是：

• 零未宣告依賴；
• 預設不新增第三方依賴；
• 所有新增本地依賴必須隨交付包完整提供；
• Runtime、SDK、作業系統與宿主平台屬明確環境前提，必須寫出，但無法由原始碼本身消除。

新專案可採 STDLIB_ONLY；既有專案則採 LOCKED_EXISTING，只使用使用者已提供的 Manifest 或 Lockfile 所確認的依賴。

4. 「完整程式碼」要依專案型態區分

對新專案而言，完整交付是最小可執行專案閉包：建置設定、入口、原始碼、測試、必要資源與驗證入口都要在內。

對既有專案而言，完整交付則是：

• 完整輸出每個新增檔；
• 完整輸出每個修改檔；
• 交付新增本地依賴；
• 列出未修改但被依賴的使用者基線檔；
• 若缺少會影響編譯的介面、型別或設定，要求補件，不可自行猜測。

不必重貼整個未修改倉庫，但也不能把從未提供過的檔案當成已存在。

5. 交付、驗證與工程完成必須分成三個狀態

V4.1 應分別追蹤：

狀態	要回答的問題
DELIVERY_STATUS	應交付的檔案是否已完整輸出？
VERIFICATION_STATUS	是否真的編譯、建置或測試過？
ENGINEERING_STATUS	是否具備宣稱工程完成的完整證據？

只有當目前 Bundle 已在計畫要求的環境與驗證層級中通過、檔案閉包完整、狀態對帳一致，且 Plan、ADR、Truth Report 均已同步時，才能標記 ENGINEERING_STATUS=COMPLETE。

Tavily 與 BMAD：可以用，但不能寫成「已具備」

Tavily 的 search_depth=advanced 是實際 API 的檢索深度參數，適合高精度、細節導向的查詢；代價是較高延遲，部分文件也指出其成本高於基本搜尋。2411 因此，Gem 只有在目前會話確實提供 Tavily 工具或已連接 API 時，才能說自己用了 Tavily；否則只能使用實際可用的搜尋、網頁或使用者材料，並明示能力降級。

同樣地，BMAD 的 Agent、Skill 與測試 Workflow 是有具體調用途徑的系統設計。11014 若 Gem 沒有真正的多 Agent Runtime，應使用 PM、Architect、Developer、QA、Ops 作為內部覆核視角，而不是宣稱多個獨立 Agent 已實際協作。

評分與裁決

以下分數是本次靜態配置審計，不是實際運行 Benchmark：

維度	權重	V4	V4.1 Final
Gem 執行邊界與工具真實性	25%	4.0	4.8
三遍閱讀、DM、DR 收斂品質	20%	4.5	4.8
工程安全閥與失敗背壓	20%	4.6	4.8
完整程式碼與依賴閉包	15%	4.6	4.9
指令密度與可遵循性	10%	2.8	4.5
狀態恢復與證據對帳	10%	4.2	4.7
加權總分	100%	84.2	95.5

計算式為：

$$
Score = 20\sum_{i=1}^{n} w_i s_i, \qquad \sum_{i=1}^{n}w_i=1
$$

The Pick：Solo-Engine V4.1 Final。

V4 可作為內部試驗版；V4.1 才適合作為長期配置。關鍵提升不在更多角色、更多表格或更多警語，而在於：主指令自足、能力邊界誠實、狀態模型不重複，以及所有「已完成」都能對應到可核驗證據。

V4.1 Final 的最小定稿原則

主指令應只保留以下不可妥協規則：

1. 僅能使用當前會話真實提供的工具。
2. 不得虛構搜尋、測試、編譯、寫檔、Git、部署或多 Agent 執行。
3. 未真實執行時，只能標示 NOT_RUN 或 STATIC_CHECKED。
4. 新增或修改檔案一律完整交付；缺少承重基線不可猜介面。
5. 預設不增加第三方依賴；環境前提必須明示。
6. 自動循環僅在當前授權、會話、工具與重試預算內有效。
7. COMPLETE 必須同時滿足交付閉包、必要驗證與狀態對帳。

其餘內容，包括三遍閱讀、Decision Matrix、Deep Recon、情境矩陣、ADR 與 Resume Capsule 範本，應放入知識庫分檔管理。舊版同功能文件不應與 V4.1 同時上傳，否則會提高衝突召回與規則漂移風險。

最小失敗測試

若出現下列任一情況，代表配置仍需加固：

1. 沒有執行器，卻聲稱測試已通過。
2. 缺少既有介面，卻自行編造並宣稱可編譯。
3. Bugfix 改到公開簽名，卻未升級為結構性 Preflight。
4. 檔案輸出到一半，卻將交付狀態標為 COMPLETE。
5. Tavily 不可用，卻宣稱已用 search_depth=advanced 搜尋。

這五項測試比再增加一頁規則更有價值，因為它們直接檢驗系統是否會在最常見的「看起來完成」陷阱中失真。

最終判定

V4 的方法論骨架應保留；V4.1 Final 的工作，是把它從一份很完整的規則集合，重構為一個能被穩定遵守的誠實工作流。

若未來改用 Gemini API Managed Agent、MCP，或接入持久化程式碼沙箱，正確作法是新增 Runtime Adapter，明確描述當時可用的搜尋、檔案、執行與持久化能力；不應持續把假想工具描述堆進 Gem 主指令。