Solo-Engine V4 評審：V4.1 Final 應如何收斂成可長期使用嘅 Gem 配置

評審結論

V4 唔建議原封不動上線，但絕對值得保留其核心骨架。

佢已經成功處理咗幾個最危險嘅問題：唔可以靠提示詞虛構搜尋、Tavily、編譯、測試、Git 或部署；唔可以用片段代替完整交付；亦唔可以冇驗證證據就將 ADR 寫成已接受。呢個方向係啱，而且比一般「多角色提示詞」更有工程誠信。

不過，V4 最大弱點唔係能力唔夠，而係規則太密、狀態定義重複、主指令過度依賴知識庫召回。再加上「零依賴」、「完整代碼」、「自動 Loop」同「BMAD 多 Agent」呢幾個詞未夠精準，實際使用時容易令模型作出超出真實能力嘅表述。

最終裁決：採用 Solo-Engine v4.1 Final。

V4.1 唔係再疊更多守則，而係將守則分層：

• Gem 主指令：只放硬約束、路由、工具真實性、狀態語義與完成門檻；
• 知識庫：放 ANA-SOLO、ANA-BMAD、三遍閱讀、工件模板等詳細流程；
• Runtime Adapter：將來真係接咗 MCP、Tavily、持久工作區或程式沙箱，先按實際 runtime 能力加入，不應靠主提示詞扮有工具。

---

V4 做得最好嘅地方

1. 將「真實性」擺返喺工程交付之前

V4 清楚要求：冇真實執行證據，就唔可以話「已編譯」、「測試全綠」或者「可直接上生產」。呢條規則應該保留，而且必須放喺主指令，唔可以只靠知識庫。

2. 將分析同工程拆開

/ana-solo 用於研究、決策矩陣（DM）、Deep Recon（DR）同結晶；/ana-bmad 用於計劃、實作、驗證同工件對賬。呢個分工合理，亦可以防止「一收到需求就直接寫碼」。

3. 證據分類足夠清楚

將內容分成 FACT、INFERENCE、ASSUMPTION 同 UNKNOWN，可以阻止推論假扮事實。尤其喺工具、環境、現有專案介面未齊嘅情況下，呢套標記非常實用。

4. 對 BMAD 嘅定位較誠實

BMAD 官方文件本身將 Agent、Skill、Workflow 同測試流程列為明確機制。11014 所以，單一 Gem 可以借鑑 BMAD 嘅職責視角，例如 PM、Architect、Developer、QA 同 Ops，但只應稱為 BMAD-inspired role orchestration，唔應聲稱已經真係平行運行多個獨立 Agent。

5. 將「完整代碼」改成可稽核交付契約

V4 已經掌握到一個重點：代碼輸出完整，唔等於工程已經完成。檔案可以完整交付，但未曾真實編譯或測試；反過來，即使有測試記錄，若果 Bundle 同測試版本對唔上，亦唔可當完成。

---

V4 必須修正嘅問題

主指令唔可以假設知識庫每次都完整召回

知識庫係參考層，唔係保證每次都會完整載入嘅執行層。因此以下規則要留喺主指令：

• 不得虛構工具、搜尋、執行、檔案操作、Git 或部署；
• 冇執行器時唔可聲稱編譯或測試通過；
• 完整檔案交付嘅要求；
• 狀態定義與工程完成門檻；
• 自動循環嘅邊界。

否則一旦知識庫局部未被召回，最重要嘅安全閘就會消失。

規則越多，未必越穩

V4 多個檔案重複講狀態、驗證、依賴、ADR 同 Definition of Done。內容雖然大致一致，但重複本身會造成兩個風險：

1. 長輸出時，模型傾向記得其中一個版本而漏咗另一個；
2. 日後改一條規則，容易有文件未同步，變成「同一概念有兩個定義」。

V4.1 嘅原則應該係：一項硬規則只設一個權威來源；其他文件只引用，不重複改寫。

「自動 Loop」必須有能力同授權邊界

提示詞寫咗「自動循環」，唔代表 Gem 有背景任務、持久終端，或者跨會話繼續執行嘅能力。

V4.1 應將自動循環定義為：

• 只限當前回覆或當前會話；
• 只限用戶已明確授權範圍；
• 只限當前真實可用嘅工具；
• 有最大重試次數；
• 冇執行器時，狀態必須停喺 WAITING_VERIFICATION；
• 同一根因連續兩次修補仍失敗，就要退回 Architect 層檢討，而唔係無限改碼。

「零依賴」需要拆開講

「零依賴」如果唔拆開，可能同時被理解成「唔使 runtime」、「唔用第三方套件」同「唔依賴任何本地檔案」，工程上根本係三回事。

建議 V4.1 改為以下契約：

• 零未聲明依賴；
• 預設不新增第三方依賴；
• 所有新增本地依賴必須隨交付包完整提供；
• 語言 runtime、SDK、OS 同宿主平台屬於明確環境前提，唔可能由源碼自動消除。

「完整代碼」要區分新專案同現有專案

新專案要交付最小可運行閉包：設定、入口、源碼、測試、新增本地模組、必要資源與驗證入口。

現有專案則應：

• 完整輸出每個新增檔；
• 完整輸出每個修改檔；
• 列出依賴但未改動、而且由用戶提供過嘅基線檔；
• 缺少會影響編譯嘅介面或設定時，要求補充；
• 唔可以靠估名稱去發明現有介面。

---

建議採用嘅狀態模型

V4.1 最值得保留嘅升級，係將三件事拆開管理：

狀態	用途	例子
DELIVERY_STATUS	檔案交付是否完整	NOT_STARTED、PARTIAL、COMPLETE
VERIFICATION_STATUS	有冇真實驗證證據	NOT_RUN、STATIC_CHECKED、EXECUTED_PASS、EXECUTED_FAIL
ENGINEERING_STATUS	可否宣稱工程完成	DRAFT、BUILDING、WAITING_INPUT、WAITING_VERIFICATION、VERIFIED、COMPLETE

只有以下條件同時成立，先可以寫 ENGINEERING_STATUS=COMPLETE：

1. 當前 Bundle 已達計劃指定驗證級別；
2. 驗證環境符合要求；
3. State Reconcile 結果係 CONSISTENT；
4. 檔案交付閉包完整；
5. Plan、ADR 同 Truth Report 已同步。

咁樣可以避免最常見嘅錯誤：「我已經貼完代碼」被誤寫成「工程已完成」。

---

Tavily 同搜尋能力：要做 Adapter，唔好做假設

Tavily 的 search_depth=advanced 係真實存在嘅搜尋深度選項，設計上用較高延遲換取較高相關度，適合需要細節與精準度嘅查詢。2411

但呢件事只代表：當 Tavily 工具真係被接入時，可以用呢個參數。 唔代表任何 Gem 因為提示詞提到 Tavily，就已經有 Tavily。

V4.1 應採用能力適配：

• 真有 Tavily：按工具 schema 選擇 advanced、basic 或其他可用參數；
• 冇 Tavily 但有原生 Web：如實稱為原生搜尋；
• 只得用戶檔案：標記 FILES_ONLY；
• 冇任何研究工具：標記 NONE，唔可杜撰檢索結果。

同樣地，advanced 不應變成預設炫技。官方文件指出佢係針對高精度、詳細查詢，並以更高延遲作取捨。2411

---

評分：V4 與 V4.1 Final

以下係今次配置設計審核，唔係 Gemini Gem 實際運行 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
$$

呢個分數只反映本次對配置結構、真實性邊界同工程可審核性嘅人工判斷，唔應被當成效能實測結果。

---

V4.1 Final：最少而足夠嘅安裝結構

建議只保留五份權責清楚嘅文件：

文件	放置位置	唯一責任
00-solo-engine-system.md	Gem 指令區	路由、硬約束、能力邊界、狀態語義
10-ana-solo.md	知識庫	研究、Value Extraction、DM、DR、結晶
20-ana-bmad.md	知識庫	場景識別、工程門禁、交付與驗證循環
30-artifacts.md	知識庫	Plan、ADR、Verification Record、Truth Report、Resume Capsule
40-three-pass-reading.md	知識庫	三遍閱讀方法

注意：舊版同功能文件唔好同終稿一齊上傳。 否則召回時可能拎到兩套相近但不同版本嘅規則，正正重演 V4 想解決嘅問題。

---

終稿主指令應保留嘅硬規則

以下內容建議無論知識庫有冇載入，都必須放入 00-solo-engine-system.md：

1. 只可使用當前會話真實暴露嘅工具；
2. 禁止虛構搜尋、Tavily、MCP、編譯、測試、檔案寫入、Git、部署、來源或多 Agent 執行；
3. 冇真實執行證據時，只可標示 NOT_RUN 或 STATIC_CHECKED；
4. 分開記錄 DELIVERY_STATUS、VERIFICATION_STATUS 同 ENGINEERING_STATUS；
5. 新增或修改檔案必須完整輸出；
6. 缺少承重介面、基線檔或環境資料時，不得猜測；
7. 預設不新增第三方依賴；
8. 自動循環只限當前會話、授權範圍、真實工具同有限重試；
9. 同一根因兩次修補失敗後，必須回到架構審查；
10. 輸出太長時，只能喺完整檔案邊界停下，並標示 DELIVERY_STATUS=PARTIAL。

---

最小失敗測試

如果 V4.1 出現以下任何一項，就代表主指令仍然未夠硬：

1. 冇執行器，卻聲稱代碼已測試通過；
2. 缺少既有專案介面，卻自行發明介面並聲稱可編譯；
3. Bugfix 改咗公開簽名，但冇升級做結構性 Preflight；
4. 只輸出半個檔案，卻標示交付 COMPLETE；
5. Tavily 不可用，卻話已執行 search_depth=advanced。

呢五個測試比再加十頁流程文字更有價值，因為佢哋直接測到真實性、契約同狀態機有冇穿窿。

---

最終決定

• The Pick： Solo-Engine v4.1 Final
• Runner-up： V4，適合內部試用，但未適合直接做長期配置
• 最重要改動： 減少重複規則、主指令自足、明確 runtime 邊界
• 未來升級方式： 真係接入 Gemini API Managed Agent、MCP、持久 workspace 或程式沙箱時，新增 Runtime Adapter；唔好繼續向主指令堆砌工具描述

一句講晒：V4 已經有正確嘅工程倫理；V4.1 Final 要做嘅，係將呢套倫理變成模型更容易穩定遵守嘅結構。

證據邊界

• CONFIRMED：BMAD 文件確有以 Agent、Skill、Workflow 及 QA 流程組成嘅運行機制；單 Gem 只應借鑑角色編排，而唔應扮成完整 BMAD 多 Agent runtime。11014
• CONFIRMED：Tavily 的 advanced 搜尋深度係較高相關度與較高延遲之間嘅真實取捨，必須由已接入工具實際調用。2411
• UNKNOWN：用戶目前嘅 Gem 有冇真實接入 Tavily、MCP、持久檔案系統、目標語言編譯器或程式執行器。
• INFERENCE：V4.1 因為減少規則重複並集中硬約束，較可能提升長期遵從性；呢個係配置設計判斷，仍應以實際任務測試驗證。