為什麼只讓 AI「換個角色」還不夠

在 AI 開發流程裡，將同一模型先設定為分析師、再設定為工程師，最後要求它扮演審查者，並不能單憑角色名稱證明工作真的分開，也無法保證審查者看到的是正確版本的交付物。

這份 BMAD-Solo 工程草案試圖把重點從「有幾個 Agent」轉向「業務工作如何交接、證據如何驗證、誰有權放行」。草案採用 Plan／Act 兩個基本動作，並把 Analyst、Architect、Coder、Supervisor 安排在流程的不同工序；它不主張建立四套獨立 Agent 系統。

這種流程觀也呼應華為一手材料所提到的做法：將品質要求納入端到端業務流程，而不是等到最後才檢查。7 另一方面，AutoSwarm 論文摘要指出，將工作分配給多個代理不會自動產生互補成果，代理間的依賴也可能讓局部錯誤演變成任務失敗。1 這些材料可作為流程治理的背景，但不代表草案中的具體機制已經過實作驗證。

一份任務契約，串起整段工作

草案的核心工件是 Task Unit，也就是單一任務契約。它集中記錄目標、驗收條件、工作階段、授權引用、輸入、依賴、交付檔案、機器檢查及審查證據。聊天紀錄、工具清單或另一份進度表，都不能取代這份契約成為任務狀態的第二套權威來源。

四種職責則依序嵌入工作流程：

• Analyst 在 Plan 前段釐清業務問題、不變條件和完成標準，並標示哪些資訊仍未知。
• Architect 在 Plan 後段整理介面、依賴、交付範圍及驗證方式，形成可供批准的任務契約。
• Coder 在 Act 前段依照已批准的範圍實作，準備候選交付物及自測證據。
• Supervisor 在 Act 後段檢查凍結候選、驗證結果和已知限制，提出審查決定。

簡單任務可以精簡各工序的文件，但草案要求，受治理的程式交付仍須具有任務契約、明確的驗收條件、適用的機器檢查及獨立審查。

兩道門都通過，才談下游放行

草案把放行設計成兩項條件的交集：

1. 機器門禁：所有必要檢查均已實際執行並符合要求，回執可信，且綁定目前的任務契約、候選內容、依賴與環境。
2. 獨立審查：審查者有相應權限，未參與該候選的實作，並對同一候選、機器回執和審查報告留下有效簽章。

因此，測試失敗、證據缺漏、身分不明或結果無法解析，都不能被當成「大概通過」。同樣地，模型切換到 Supervisor 模式、另開一個對話，或在 Markdown 裡打勾，也不能單獨證明審查具備獨立性。

草案特別指出：單一 Agent 可以產生審查草稿，卻不能替自己實作的候選提供有效的獨立簽章。預設設計是由可信驗證入口產生機器回執，再由未參與實作且獲授權的人類維護者審查；其他獨立審查機制則需另外證明身分、權限與隔離。若沒有合格的獨立審查者，候選可以保留，但不能釋出給下游。

讓證據跟著「這一版」走

為了避免舊的通過結果被套用到新版本，草案區分三種身分：任務契約、候選交付物，以及本次驗證執行。回執與簽章都要綁定這些身分；若交付內容改變，即使檔名和路徑沒變，也應視為不同候選，重新驗證。

驗證器也不能只是讓模型自行輸入指令、再把輸出解讀成通過。草案要求命令、執行環境、網路政策、逾時處理及結果解析方式事先固定，並由可信入口產生回執。若實際宿主無法隔離候選程式碼與證據控制面，就不能僅憑本機資料夾或提示詞宣稱已具備硬門禁；草案建議使用另行核准的受保護驗證環境，否則相關驗收應保持未完成狀態。

失敗時保留現場，而不是把綠燈搬給新版本

若審查拒絕候選，草案要求阻止該候選及依賴它的下游工作，同時保留失敗回執、基線、差異和審查報告。獲准修復後，應建立新的執行批次和候選摘要；舊版本的通過證據不能直接沿用。

若修復需要改動驗收條件、公共介面或原本批准的範圍，則應回到 Plan 重新確認，而不是讓實作者自行修改契約。這項原則也適用於規範發布：接受候選不等於自動發布長期規範，更不等於獲准合併、推送或部署。

Roo Code 與 Cline：保留兩個模式，補上流程契約

在宿主適配上，草案並不要求把四種職責都變成四個獨立模式。Roo Code 可沿用 Plan 中的 Analyst／Architect 工序，以及 Act 中的實作與審查輔助；Cline 也可按工序載入相應提示片段。角色切換本身不增加工具權限，也不能直接改寫門禁狀態。

關鍵差異在於：提示詞路由只是行為引導，不等同於物理隔離。只有實際測試確認模式訊號、檔案權限、驗證入口與簽章機制都能阻擋不允許的操作，才能主張宿主具備相應的硬性控制。

目前仍是草案，不是已上線的治理系統

這份規範明確標示為 DRAFT／待工程評審。它提出 Task Unit 範本、狀態轉換、回執與簽章格式、宿主映射及分階段實作方向，但並未表示驗證器、簽章入口或 Roo Code／Cline 的硬門禁已完成。文件也說明，此次交付沒有修改工作區、實作程式碼、執行測試或遷移既有資產。

因此，讀者應把它理解為一份治理設計提案，而非已證實有效的產品功能。接下來要驗證的，不只是「正常情況能否跑通」，還包括失敗、缺證據、自我審查、候選被替換和獲准返工時，系統能否正確阻擋或恢復。只有這些行為取得實際證據，雙重把關才不會停留在文件與提示詞裡。

為什麼只讓 AI「換個角色」還不夠

在 AI 開發流程裡，將同一模型先設定為分析師、再設定為工程師，最後要求它扮演審查者，並不能單憑角色名稱證明工作真的分開，也無法保證審查者看到的是正確版本的交付物。

這份 BMAD-Solo 工程草案試圖把重點從「有幾個 Agent」轉向「業務工作如何交接、證據如何驗證、誰有權放行」。草案採用 Plan／Act 兩個基本動作，並把 Analyst、Architect、Coder、Supervisor 安排在流程的不同工序；它不主張建立四套獨立 Agent 系統。

這種流程觀也呼應華為一手材料所提到的做法：將品質要求納入端到端業務流程，而不是等到最後才檢查。7 另一方面，AutoSwarm 論文摘要指出，將工作分配給多個代理不會自動產生互補成果，代理間的依賴也可能讓局部錯誤演變成任務失敗。1 這些材料可作為流程治理的背景，但不代表草案中的具體機制已經過實作驗證。

一份任務契約，串起整段工作

草案的核心工件是 Task Unit，也就是單一任務契約。它集中記錄目標、驗收條件、工作階段、授權引用、輸入、依賴、交付檔案、機器檢查及審查證據。聊天紀錄、工具清單或另一份進度表，都不能取代這份契約成為任務狀態的第二套權威來源。

四種職責則依序嵌入工作流程：

• Analyst 在 Plan 前段釐清業務問題、不變條件和完成標準，並標示哪些資訊仍未知。
• Architect 在 Plan 後段整理介面、依賴、交付範圍及驗證方式，形成可供批准的任務契約。
• Coder 在 Act 前段依照已批准的範圍實作，準備候選交付物及自測證據。
• Supervisor 在 Act 後段檢查凍結候選、驗證結果和已知限制，提出審查決定。

簡單任務可以精簡各工序的文件，但草案要求，受治理的程式交付仍須具有任務契約、明確的驗收條件、適用的機器檢查及獨立審查。

兩道門都通過，才談下游放行

草案把放行設計成兩項條件的交集：

1. 機器門禁：所有必要檢查均已實際執行並符合要求，回執可信，且綁定目前的任務契約、候選內容、依賴與環境。
2. 獨立審查：審查者有相應權限，未參與該候選的實作，並對同一候選、機器回執和審查報告留下有效簽章。

因此，測試失敗、證據缺漏、身分不明或結果無法解析，都不能被當成「大概通過」。同樣地，模型切換到 Supervisor 模式、另開一個對話，或在 Markdown 裡打勾，也不能單獨證明審查具備獨立性。

草案特別指出：單一 Agent 可以產生審查草稿，卻不能替自己實作的候選提供有效的獨立簽章。預設設計是由可信驗證入口產生機器回執，再由未參與實作且獲授權的人類維護者審查；其他獨立審查機制則需另外證明身分、權限與隔離。若沒有合格的獨立審查者，候選可以保留，但不能釋出給下游。

讓證據跟著「這一版」走

為了避免舊的通過結果被套用到新版本，草案區分三種身分：任務契約、候選交付物，以及本次驗證執行。回執與簽章都要綁定這些身分；若交付內容改變，即使檔名和路徑沒變，也應視為不同候選，重新驗證。

驗證器也不能只是讓模型自行輸入指令、再把輸出解讀成通過。草案要求命令、執行環境、網路政策、逾時處理及結果解析方式事先固定，並由可信入口產生回執。若實際宿主無法隔離候選程式碼與證據控制面，就不能僅憑本機資料夾或提示詞宣稱已具備硬門禁；草案建議使用另行核准的受保護驗證環境，否則相關驗收應保持未完成狀態。

失敗時保留現場，而不是把綠燈搬給新版本

若審查拒絕候選，草案要求阻止該候選及依賴它的下游工作，同時保留失敗回執、基線、差異和審查報告。獲准修復後，應建立新的執行批次和候選摘要；舊版本的通過證據不能直接沿用。

若修復需要改動驗收條件、公共介面或原本批准的範圍，則應回到 Plan 重新確認，而不是讓實作者自行修改契約。這項原則也適用於規範發布：接受候選不等於自動發布長期規範，更不等於獲准合併、推送或部署。

Roo Code 與 Cline：保留兩個模式，補上流程契約

在宿主適配上，草案並不要求把四種職責都變成四個獨立模式。Roo Code 可沿用 Plan 中的 Analyst／Architect 工序，以及 Act 中的實作與審查輔助；Cline 也可按工序載入相應提示片段。角色切換本身不增加工具權限，也不能直接改寫門禁狀態。

關鍵差異在於：提示詞路由只是行為引導，不等同於物理隔離。只有實際測試確認模式訊號、檔案權限、驗證入口與簽章機制都能阻擋不允許的操作，才能主張宿主具備相應的硬性控制。

目前仍是草案，不是已上線的治理系統

這份規範明確標示為 DRAFT／待工程評審。它提出 Task Unit 範本、狀態轉換、回執與簽章格式、宿主映射及分階段實作方向，但並未表示驗證器、簽章入口或 Roo Code／Cline 的硬門禁已完成。文件也說明，此次交付沒有修改工作區、實作程式碼、執行測試或遷移既有資產。

因此，讀者應把它理解為一份治理設計提案，而非已證實有效的產品功能。接下來要驗證的，不只是「正常情況能否跑通」，還包括失敗、缺證據、自我審查、候選被替換和獲准返工時，系統能否正確阻擋或恢復。只有這些行為取得實際證據，雙重把關才不會停留在文件與提示詞裡。