對 AI agent 寫程式，真正令人擔心的未必只是「寫錯 code」，而是它寫完之後，仲可以自己話自己驗收合格。\n\n一份 BMAD-Solo 工程規範草案提出另一種做法：用一份任務契約串連由分析、設計到實作和審查的流程，再以「可信機器檢查＋獨立審查簽章」兩道門，決定候選交付物可唔可以交畀下游。要留意，這是待工程評審的草案，唔代表相關系統已經落地。\n\n## 不是多開幾個 Agent 就等於有人把關\n\n草案保留一個人機互動入口，以及 Plan、Act 兩個基本動作；流程中再分成四種職責：Analyst 整理問題和驗收意圖，Architect 設計交付契約，Coder 按批准範圍實作，Supervisor 則反向檢查候選成果。\n\n重點是，四種職責屬於同一條業務流程，唔係四個各自保存進度、各自持有一份任務資料的 Agent。每次交接都要講清楚下一工序需要甚麼、有哪些未完成事項，以及哪些操作仍然未獲授權。\n\n這個安排亦回應多 Agent 工作的常見風險：把工作拆開，不代表各部分自然互補；如果彼此依賴，一個環節的錯誤亦可能影響整個任務。1\n\n## 一份任務契約做「唯一真相」\n\n草案把 Task Unit（任務單元）定為任務流轉的核心契約。它記錄目標、驗收標準、准許修改的檔案範圍、必要檢查、依賴項目、目前工序，以及機器回執和審查報告的引用。\n\n換句話說，聊天紀錄、模式切換畫面或某份原生待辦清單，都唔應該變成第二本可以獨立改寫的進度帳。會隨流程改變的任務狀態，應由權威契約承載；機器回執則記錄一次實際驗證的結果，唔可以自己代替整體驗收決定。\n\n草案亦要求清楚區分「未知」和「失敗」：例如環境未準備好、證據不足或權限遭拒，應該阻止放行，但唔應被扮成測試已經失敗或通過。修改了候選內容，舊有通過結果亦唔可以直接搬過去；新候選要重新驗證。\n\n## 「自己寫、自己批」唔算獨立審查\n\n雙重門禁是整份草案最關鍵的一環。第一道門由可信驗證入口執行指定檢查，並將結果綁定到實際候選、契約版本和執行環境。第二道門則由未有參與該候選實作、而且有權審查的主體作出決定。\n\n因此，同一個模型可以協助整理 Supervisor 視角的審查報告，但唔可以單靠換個模式、開個新對話，便聲稱已完成獨立審查。草案建議由合資格人類維護者，或其他經驗證、與實施方隔離的審查主體，透過受保護的入口簽章。\n\n就算兩道門都通過，也只代表該候選可進入獲准的下一步；唔代表已獲准合併、部署或發布。放行前仍要核對實際交付物，確保審查的是同一個版本，而唔係簽完之後悄悄換了另一份。\n\n## 把品質檢查放進流程，而唔係留到最後補救\n\n草案的思路，亦呼應華為提出將質量要求構築到各業務流程中、以端到端方式管理品質的說法。7 放在 agent 工作流程裡，意思是：驗收條件、檢查方式和失敗後的處理方法，應在設計任務時講明，而唔係等到程式寫完先臨時決定點樣算合格。\n\n對於被拒絕的候選，草案要求保留失敗結果、差異和審查報告；獲准修正後建立新執行批次，再重新驗證。若修改牽涉任務範圍、介面或驗收標準，就要返回 Plan 重新批准，唔可以由實作者自行改規則，再用新規則證明自己過關。\n\n## 目前仍是草案，硬門禁要靠工程驗證\n\n文件亦特別提醒，提示詞寫了「不得自簽」並不足以構成真正的權限隔離。要有可信驗證器、受保護的簽章入口、可追溯的證據，以及能阻止越權放行的宿主機制；如果候選程式仍可改寫驗證規則或偽造回執，就未能證明門禁有效。\n\n所以，這份規範目前提供的是一套設計方向和驗收要求，而唔係已經實作完成的產品功能。草案本身亦指出，驗證器、簽章入口和 Roo Code／Cline 等宿主的硬性控制，仍有待獲授權後建立和測試。換言之，文件寫得再完整，都唔等於系統已經能可靠地攔住錯誤。

對 AI agent 寫程式，真正令人擔心的未必只是「寫錯 code」，而是它寫完之後，仲可以自己話自己驗收合格。\n\n一份 BMAD-Solo 工程規範草案提出另一種做法：用一份任務契約串連由分析、設計到實作和審查的流程，再以「可信機器檢查＋獨立審查簽章」兩道門，決定候選交付物可唔可以交畀下游。要留意，這是待工程評審的草案，唔代表相關系統已經落地。\n\n## 不是多開幾個 Agent 就等於有人把關\n\n草案保留一個人機互動入口，以及 Plan、Act 兩個基本動作；流程中再分成四種職責：Analyst 整理問題和驗收意圖，Architect 設計交付契約，Coder 按批准範圍實作，Supervisor 則反向檢查候選成果。\n\n重點是，四種職責屬於同一條業務流程，唔係四個各自保存進度、各自持有一份任務資料的 Agent。每次交接都要講清楚下一工序需要甚麼、有哪些未完成事項，以及哪些操作仍然未獲授權。\n\n這個安排亦回應多 Agent 工作的常見風險：把工作拆開，不代表各部分自然互補；如果彼此依賴，一個環節的錯誤亦可能影響整個任務。1\n\n## 一份任務契約做「唯一真相」\n\n草案把 Task Unit（任務單元）定為任務流轉的核心契約。它記錄目標、驗收標準、准許修改的檔案範圍、必要檢查、依賴項目、目前工序，以及機器回執和審查報告的引用。\n\n換句話說，聊天紀錄、模式切換畫面或某份原生待辦清單，都唔應該變成第二本可以獨立改寫的進度帳。會隨流程改變的任務狀態，應由權威契約承載；機器回執則記錄一次實際驗證的結果，唔可以自己代替整體驗收決定。\n\n草案亦要求清楚區分「未知」和「失敗」：例如環境未準備好、證據不足或權限遭拒，應該阻止放行，但唔應被扮成測試已經失敗或通過。修改了候選內容，舊有通過結果亦唔可以直接搬過去；新候選要重新驗證。\n\n## 「自己寫、自己批」唔算獨立審查\n\n雙重門禁是整份草案最關鍵的一環。第一道門由可信驗證入口執行指定檢查，並將結果綁定到實際候選、契約版本和執行環境。第二道門則由未有參與該候選實作、而且有權審查的主體作出決定。\n\n因此，同一個模型可以協助整理 Supervisor 視角的審查報告，但唔可以單靠換個模式、開個新對話，便聲稱已完成獨立審查。草案建議由合資格人類維護者，或其他經驗證、與實施方隔離的審查主體，透過受保護的入口簽章。\n\n就算兩道門都通過，也只代表該候選可進入獲准的下一步；唔代表已獲准合併、部署或發布。放行前仍要核對實際交付物，確保審查的是同一個版本，而唔係簽完之後悄悄換了另一份。\n\n## 把品質檢查放進流程，而唔係留到最後補救\n\n草案的思路，亦呼應華為提出將質量要求構築到各業務流程中、以端到端方式管理品質的說法。7 放在 agent 工作流程裡，意思是：驗收條件、檢查方式和失敗後的處理方法，應在設計任務時講明，而唔係等到程式寫完先臨時決定點樣算合格。\n\n對於被拒絕的候選，草案要求保留失敗結果、差異和審查報告；獲准修正後建立新執行批次，再重新驗證。若修改牽涉任務範圍、介面或驗收標準，就要返回 Plan 重新批准，唔可以由實作者自行改規則，再用新規則證明自己過關。\n\n## 目前仍是草案，硬門禁要靠工程驗證\n\n文件亦特別提醒，提示詞寫了「不得自簽」並不足以構成真正的權限隔離。要有可信驗證器、受保護的簽章入口、可追溯的證據，以及能阻止越權放行的宿主機制；如果候選程式仍可改寫驗證規則或偽造回執，就未能證明門禁有效。\n\n所以，這份規範目前提供的是一套設計方向和驗收要求，而唔係已經實作完成的產品功能。草案本身亦指出，驗證器、簽章入口和 Roo Code／Cline 等宿主的硬性控制，仍有待獲授權後建立和測試。換言之，文件寫得再完整，都唔等於系統已經能可靠地攔住錯誤。