指南：用 bmad-build 無規(guī)劃直入 Build 階段處理 Bug 與小型改動(dòng))
AI 技能人工智能開發(fā)工具【免費(fèi)下載鏈接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development項(xiàng)目地址https://gitcode.com/gh_mirrors/bm/BMAD-METHOD點(diǎn)擊查看免費(fèi)下載導(dǎo)讀在 BMAD-METHODBreakthrough Method for Agile AI Driven Development的完整流程中Bug 修復(fù)、小型重構(gòu)與針對(duì)性改動(dòng)通常不需要經(jīng)歷 PRD、UX、架構(gòu)、Epics 等完整規(guī)劃鏈路可以直接交給bmad-build進(jìn)入Build階段——這與完整規(guī)劃過的 Story 走的是同一條實(shí)現(xiàn)循環(huán)。本文以 docs/fr/how-to/quick-fixes.md 為骨架結(jié)合skills/bmad-build/下的真實(shí)工作流源碼完整講解何時(shí)該用這種“快速修復(fù)”路線、如何在 IDE 中發(fā)起一次 Build 執(zhí)行、如何審閱與推送結(jié)果以及什么時(shí)候必須回頭補(bǔ)上正式規(guī)劃。何時(shí)使用這種快速修復(fù)路線判斷一次改動(dòng)能否跳過規(guī)劃、直接進(jìn)入 Build標(biāo)準(zhǔn)不是“改動(dòng)小”這么模糊而是范圍是否可控、意圖是否明確。原文檔列出的適用場景包括Bug 修復(fù)且原因明確已知——例如“登錄校驗(yàn)允許空密碼”“auth 中間件沒有檢查 token 過期”你能一句話說清問題在哪小型重構(gòu)——重命名、提取函數(shù)、結(jié)構(gòu)調(diào)整等且改動(dòng)局限在少數(shù)幾個(gè)文件內(nèi)功能微調(diào)或配置修改——小范圍調(diào)整既有行為不改變整體設(shè)計(jì)依賴升級(jí)——升級(jí)某個(gè)依賴并同步處理其帶來的接口變化。與之相對(duì)一旦出現(xiàn)以下信號(hào)就不該再用快速修復(fù)路線而應(yīng)回到正式規(guī)劃見下文“何時(shí)添加正式規(guī)劃”小節(jié)改動(dòng)橫跨多個(gè)系統(tǒng)需要在大量文件中做協(xié)調(diào)更新對(duì)范圍不確定需要先做需求發(fā)現(xiàn)團(tuán)隊(duì)需要留存文檔或架構(gòu)決策記錄。前置條件已安裝 BMAD-METHODnpx bmad-method install已配備一個(gè) AI IDEClaude Code、Cursor 或同類工具。安裝完成后bmad-buildskill 才會(huì)出現(xiàn)在 skills 目錄中本倉庫中位于 skills/bmad-build/SKILL.md其渲染腳本路徑為_bmad/scripts/render_skill.py——若該路徑不存在說明 BMAD 尚未完成 setup需要先按安裝流程初始化。第 1 步開啟一條全新會(huì)話在 AI IDE 中新建一條對(duì)話而不是復(fù)用之前工作流的會(huì)話。原文檔特別強(qiáng)調(diào)復(fù)用舊會(huì)話會(huì)帶來上下文沖突conflits de contexte。這一點(diǎn)在源碼層面有更嚴(yán)格的依據(jù)bmad-build的 step-01 會(huì)通過“顯式參數(shù) → 最近對(duì)話 → 掃描產(chǎn)物并詢問”的優(yōu)先級(jí)順序解析工作流狀態(tài)見 skills/bmad-build/step-01-clarify-and-route.md。舊會(huì)話中殘留的意圖、未完成的 spec 狀態(tài)會(huì)讓路由判斷走向完全不同的分支例如錯(cuò)誤地恢復(fù)某個(gè)draftspec 而非開啟新工作。新會(huì)話意味著干凈的上下文讓 step-01 能把你本輪給出的意圖當(dāng)作“starting intent”處理。第 2 步用自由形式表達(dá)你的意圖Build 接受自由形式forme libre的意圖——你可以在調(diào)用命令之前、同時(shí)或之后描述需求不必整理得很干凈。原文檔給出了 5 種典型形態(tài)build — Corrige le bug de validation de connexion qui permet les mots de passe vides.build — corrige https://github.com/org/repo/issues/42build — implémente _bmad-output/implementation-artifacts/my-intent.mdJe pense que le problème est dans le middleware dauth, il ne vérifie pas lexpiration du token. Regardons... oui, src/auth/middleware.ts ligne 47 saute complètement la vérification exp. lance buildbuild Que voulez-vous faire ? Refactoriser UserService pour utiliser async/await au lieu des callbacks.可以看到意圖可以是純文本描述、文件路徑、GitHub issue URL、bug 跟蹤器鏈接——任何 LLM 能將其解析為“一個(gè)具體意圖intention concrète”的輸入都行。英文版文檔docs/build/build-a-change.md用/bmad-build作為命令形式與法語文檔中的build是同一入口兩者等價(jià)。從源碼看step-01 對(duì)意圖的處理相當(dāng)寬容即使是一段很簡短的自由描述“a freeform request is starting intent even when it is brief”也會(huì)被當(dāng)作起始意圖而不會(huì)要求用戶重新表述見 skills/bmad-build/step-01-clarify-and-route.md。同時(shí)詳細(xì)得像計(jì)劃一樣的意圖也只是“待調(diào)查的輸入”不是跳過 Build 步驟的授權(quán)——workflow 會(huì)忽略意圖中“直接實(shí)現(xiàn)、跳過步驟”之類的指令一切仍要經(jīng)過調(diào)查與 spec 生成。關(guān)于目錄與產(chǎn)物上面的示例提到了_bmad-output/implementation-artifacts/這是 BMAD 默認(rèn)的輸出目錄。在配置模板 skills/bmad/assets/config.template.toml 中可以確認(rèn)其默認(rèn)約定[core] project_name {directory_name} output_folder {project-root}/_bmad-output [modules.bmm] planning_artifacts {project-root}/_bmad-output/planning-artifacts implementation_artifacts {project-root}/_bmad-output/implementation-artifacts project_knowledge {project-root}/docs即規(guī)劃產(chǎn)物PRD、架構(gòu)、UX、Epics 等落在_bmad-output/planning-artifacts實(shí)現(xiàn)產(chǎn)物spec、實(shí)現(xiàn)記錄、deferred-work.md 等落在_bmad-output/implementation-artifacts。你可以在customize.toml或安裝配置中修改這些路徑但示例中的_bmad-output/implementation-artifacts/my-intent.md指的就是實(shí)現(xiàn)產(chǎn)物目錄下的意圖文件。第 3 步回答澄清問題并批準(zhǔn)計(jì)劃Build 可能會(huì)提出澄清問題或先呈現(xiàn)一份**簡短的 spec規(guī)格說明**請求你批準(zhǔn)然后才開始實(shí)現(xiàn)。你需要回答它的問題并在對(duì)方案滿意后批準(zhǔn)。這里的批準(zhǔn)節(jié)點(diǎn)在源碼里有精確的位置step-02 結(jié)束時(shí)的CHECKPOINT 1見 skills/bmad-build/step-02-plan.md。在檢查點(diǎn)之前step-02 會(huì)完成兩件事調(diào)查代碼庫優(yōu)先派發(fā) deep search 給 subagent把“要復(fù)用的文件/符號(hào)/行、不要改動(dòng)什么”寫進(jìn) spec 的## Code Map用 READY FOR DEVELOPMENT 標(biāo)準(zhǔn)自檢spec 必須 Actionable每個(gè)任務(wù)有文件路徑與具體動(dòng)作、Logical按依賴排序、Testable驗(yàn)收條件用 Given/When/Then、Complete無占位符/TBD、Sufficient無未解決的缺口、Coherent無歧義或矛盾見 skills/bmad-build/workflow.md。如果調(diào)查無法從倉庫與規(guī)劃產(chǎn)物中得出結(jié)論會(huì)以O(shè)pen Questions形式列出由你逐條拍板——此時(shí) Build 會(huì) HALT 等待人工輸入而不是自行猜測。批準(zhǔn)后spec 中frozen-after-approval塊內(nèi)的內(nèi)容被鎖定只有人可以修改step-01 的多目標(biāo)檢查Multi-goal check和 step-02 的 token 數(shù)檢查SCOPE STANDARD 建議單目標(biāo) 900–1600 token也會(huì)在此時(shí)生效——一旦發(fā)現(xiàn)“一個(gè)請求里塞了多個(gè)可獨(dú)立交付的目標(biāo)”會(huì)把多余目標(biāo)寫入deferred-work.md詳見下文“延遲工作”小節(jié)。一個(gè)小而關(guān)鍵的實(shí)踐點(diǎn)原文檔強(qiáng)調(diào)“改計(jì)劃比改代碼便宜”。如果批準(zhǔn)的方案不對(duì)不要遷就直接要求修改——把問題消滅在 spec 層比等代碼寫出來再返工劃算得多。第 4 步審閱并推送結(jié)果批準(zhǔn)后Build 進(jìn)入實(shí)現(xiàn)—自審—修復(fù)—本地提交的循環(huán)實(shí)現(xiàn)按 spec 修改代碼step-03 會(huì)先在 spec frontmatter 記錄baseline_commit再派發(fā)實(shí)現(xiàn)子代理見 skills/bmad-build/step-03-implement.md自審將改動(dòng)生成 unified diff含未跟蹤文件交給獨(dú)立評(píng)審?fù)哥Rreview lens審查并按high/medium/low/false/maybe-false給出 triage 判定見 skills/bmad-build/step-04-review.md修復(fù)屬于本次改動(dòng)的問題patch/intent_gap/bad_spec就地修復(fù)或回環(huán)重做與本次改動(dòng)無關(guān)的既有問題defer記入延遲列表本地提交step-05 用符合 Conventional Commits 規(guī)范的 message 創(chuàng)建本地 commit見 skills/bmad-build/step-05-present.md。完成之后Build 會(huì)在你的編輯器中打開所有受影響的文件此時(shí)需要你親自把關(guān)瀏覽 diff確認(rèn)改動(dòng)與你的意圖一致如果哪里不對(duì)直接告訴 agent 要修正什么——它可以在同一會(huì)話內(nèi)迭代滿意之后Build 會(huì)主動(dòng)建議你推送并創(chuàng)建 PR。如果推送后出了問題怎么辦原文檔給了一個(gè)明確的回滾預(yù)案若推送的改動(dòng)引發(fā)意外問題使用git revert HEAD干凈地撤銷最近一次提交。然后開啟一條新會(huì)話重新運(yùn)行 Build嘗試不同的方案。注意這里刻意選用git revert而非git reset——它保留歷史、生成一個(gè)反向提交適合“已推送、團(tuán)隊(duì)可能已拉取”的場景?；貪L后務(wù)必開新會(huì)話再跑一次 Build原因同第 1 步讓 step-01 的路由判斷不受舊意圖污染。你能得到什么一次成功的快速修復(fù)執(zhí)行會(huì)產(chǎn)出三樣?xùn)|西修改后的源文件——修復(fù)或重構(gòu)已生效通過的測試——前提是你的項(xiàng)目有測試套件BMAD 的 spec 模板要求驗(yàn)收條件可測且 step-03 有 Matrix Test Audit 環(huán)節(jié)會(huì)逐行核對(duì) I/O 與邊界用例矩陣是否都有對(duì)應(yīng)測試覆蓋并通過見 skills/bmad-build/step-03-implement.md一個(gè)可直接推送的本地 commit——帶符合 Conventional Commits 規(guī)范的提交信息。延遲工作Deferred Work機(jī)制Build 的每次執(zhí)行都只聚焦單一目標(biāo)。如果出現(xiàn)以下情況多余的工作不會(huì)在當(dāng)前會(huì)話里硬塞而是被**延遲différée**到一個(gè)文件deferred-work.md位于你的實(shí)現(xiàn)產(chǎn)物目錄即_bmad-output/implementation-artifacts/deferred-work.md你的請求包含多個(gè)互相獨(dú)立的目標(biāo)評(píng)審發(fā)現(xiàn)了與本次改動(dòng)無關(guān)的既有問題。源碼中這兩條路徑都真實(shí)存在step-01 的 Multi-goal check 在用戶選擇“拆分為單個(gè)目標(biāo)”時(shí)會(huì)把每個(gè)被推遲的目標(biāo)追加一條- source_spec: none / summary / evidence記錄見 skills/bmad-build/step-01-clarify-and-route.mdstep-04 的 triage 則會(huì)把“pre-existing issue not caused by this story”路由到 defer同樣以- source_spec: {spec_file} / summary / evidence格式追加見 skills/bmad-build/step-04-review.md。兩種格式都帶summary一句話說明被延遲的目標(biāo)和evidence為什么被拆出/為什么判定為真并且不會(huì)修改已有條目、不查重——保證每次都只是純追加。deferred-work.md就是你的 backlog一次執(zhí)行結(jié)束后去查看它里面每一項(xiàng)都可以在后續(xù)的新一輪 Build 執(zhí)行中作為新意圖再次引入。這避免了“順手把所有問題一起修掉”的失控也讓無關(guān)的既有問題不會(huì)被遺忘。何時(shí)添加正式規(guī)劃在再次運(yùn)行同一條 Build 循環(huán)之前先想清楚是否該先補(bǔ)一份 PRD、UX、架構(gòu)或 Story 規(guī)劃原文檔給出的觸發(fā)條件是改動(dòng)影響多個(gè)系統(tǒng)或需要在大量文件中做協(xié)調(diào)更新你對(duì)范圍沒把握需要先做需求發(fā)現(xiàn)團(tuán)隊(duì)需要留檔——需要文檔或架構(gòu)決策記錄。從更大的視角看英文版 docs/build/build-a-change.md 有更完整的表述較大型的工作本質(zhì)上是一連串“單會(huì)話改動(dòng)”的序列父 spec 持有共享目標(biāo)story 記錄承載決策與完成狀態(tài)集成檢查與回顧retrospective覆蓋合并結(jié)果。bmad-build只處理“一個(gè)單元”它不擁有 backlog、不挑選下一個(gè) story、也不替代后續(xù)檢查?？焖傩迯?fù)路線與正式規(guī)劃并非對(duì)立而是同一個(gè)實(shí)現(xiàn)循環(huán)docs/build/build-a-change.md在不同前置投入下的兩種入口——直接意圖與已規(guī)劃工作最終匯入同一條 Build 循環(huán)。延伸閱讀docs/fr/how-to/quick-fixes.md——本文法語原文docs/build/build-a-change.md——bmad-build完整使用指南英文含工作規(guī)模建議與延遲工作的完整說明skills/bmad-build/workflow.md——Build 工作流總綱定義了 Ready-for-Development 標(biāo)準(zhǔn)與 SCOPE STANDARDskills/bmad-build/step-01-clarify-and-route.md——意圖解析與路由判定skills/bmad-build/step-02-plan.md——調(diào)查與 spec 生成、CHECKPOINT 1 批準(zhǔn)節(jié)點(diǎn)skills/bmad-build/step-03-implement.md——實(shí)現(xiàn)、diff 暫存與 Matrix Test Auditskills/bmad-build/step-04-review.md——評(píng)審、triage 與 defer/patch 路由skills/bmad-build/step-05-present.md——本地提交與結(jié)果呈現(xiàn)skills/bmad/assets/config.template.toml——默認(rèn)目錄與代理配置模板。贊分享AI 技能人工智能開發(fā)工具【免費(fèi)下載鏈接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development項(xiàng)目地址https://gitcode.com/gh_mirrors/bm/BMAD-METHOD點(diǎn)擊查看免費(fèi)下載相關(guān)推薦BMAD-METHOD 快速修復(fù)指南讓 Bug 修復(fù)與小型重構(gòu)直接進(jìn)入 bmad-build 實(shí)現(xiàn)循環(huán)BMAD METHOD 快速修復(fù)指南讓 Bug 修復(fù)與小型重構(gòu)直接進(jìn)入 bmad build 實(shí)現(xiàn)循環(huán) 本篇技術(shù)指南聚焦于 BMAD METHODBreakAI 技能人工智能開發(fā)工具BMad Method 快速修復(fù)實(shí)戰(zhàn)指南零規(guī)劃直通 Build 交付循環(huán)BMad Method 快速修復(fù)實(shí)戰(zhàn)指南零規(guī)劃直通 Build 交付循環(huán) Bug 修復(fù)、小型重構(gòu)、配置調(diào)整和依賴更新這類小改動(dòng)不需要 PRD、Story 或AI 技能人工智能開發(fā)工具如何用 BMAD-METHOD 的 bmad-build 在無上游規(guī)劃的情況下完成一次已知 bug 修復(fù)如何用 BMAD METHOD 的 bmad build 在無上游規(guī)劃的情況下完成一次已知 bug 修復(fù) 這篇文章面向在 AI IDE 中使用 BMAD METAI 技能人工智能開發(fā)工具創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 BMAD-METHOD 快速修復(fù)指南：用 bmad-build 無規(guī)劃直入 Build 階段處理 Bug 與小型改動(dòng)
AI 技能人工智能開發(fā)工具【免費(fèi)下載鏈接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development項(xiàng)目地址https://gitcode.com/gh_mirrors/bm/BMAD-METHOD點(diǎn)擊查看免費(fèi)下載導(dǎo)讀在 BMAD-METHODBreakthrough Method for Agile AI Driven Development的完整流程中Bug 修復(fù)、小型重構(gòu)與針對(duì)性改動(dòng)通常不需要經(jīng)歷 PRD、UX、架構(gòu)、Epics 等完整規(guī)劃鏈路可以直接交給bmad-build進(jìn)入Build階段——這與完整規(guī)劃過的 Story 走的是同一條實(shí)現(xiàn)循環(huán)。本文以 docs/fr/how-to/quick-fixes.md 為骨架結(jié)合skills/bmad-build/下的真實(shí)工作流源碼完整講解何時(shí)該用這種“快速修復(fù)”路線、如何在 IDE 中發(fā)起一次 Build 執(zhí)行、如何審閱與推送結(jié)果以及什么時(shí)候必須回頭補(bǔ)上正式規(guī)劃。何時(shí)使用這種快速修復(fù)路線判斷一次改動(dòng)能否跳過規(guī)劃、直接進(jìn)入 Build標(biāo)準(zhǔn)不是“改動(dòng)小”這么模糊而是范圍是否可控、意圖是否明確。原文檔列出的適用場景包括Bug 修復(fù)且原因明確已知——例如“登錄校驗(yàn)允許空密碼”“auth 中間件沒有檢查 token 過期”你能一句話說清問題在哪小型重構(gòu)——重命名、提取函數(shù)、結(jié)構(gòu)調(diào)整等且改動(dòng)局限在少數(shù)幾個(gè)文件內(nèi)功能微調(diào)或配置修改——小范圍調(diào)整既有行為不改變整體設(shè)計(jì)依賴升級(jí)——升級(jí)某個(gè)依賴并同步處理其帶來的接口變化。與之相對(duì)一旦出現(xiàn)以下信號(hào)就不該再用快速修復(fù)路線而應(yīng)回到正式規(guī)劃見下文“何時(shí)添加正式規(guī)劃”小節(jié)改動(dòng)橫跨多個(gè)系統(tǒng)需要在大量文件中做協(xié)調(diào)更新對(duì)范圍不確定需要先做需求發(fā)現(xiàn)團(tuán)隊(duì)需要留存文檔或架構(gòu)決策記錄。前置條件已安裝 BMAD-METHODnpx bmad-method install已配備一個(gè) AI IDEClaude Code、Cursor 或同類工具。安裝完成后bmad-buildskill 才會(huì)出現(xiàn)在 skills 目錄中本倉庫中位于 skills/bmad-build/SKILL.md其渲染腳本路徑為_bmad/scripts/render_skill.py——若該路徑不存在說明 BMAD 尚未完成 setup需要先按安裝流程初始化。第 1 步開啟一條全新會(huì)話在 AI IDE 中新建一條對(duì)話而不是復(fù)用之前工作流的會(huì)話。原文檔特別強(qiáng)調(diào)復(fù)用舊會(huì)話會(huì)帶來上下文沖突conflits de contexte。這一點(diǎn)在源碼層面有更嚴(yán)格的依據(jù)bmad-build的 step-01 會(huì)通過“顯式參數(shù) → 最近對(duì)話 → 掃描產(chǎn)物并詢問”的優(yōu)先級(jí)順序解析工作流狀態(tài)見 skills/bmad-build/step-01-clarify-and-route.md。舊會(huì)話中殘留的意圖、未完成的 spec 狀態(tài)會(huì)讓路由判斷走向完全不同的分支例如錯(cuò)誤地恢復(fù)某個(gè)draftspec 而非開啟新工作。新會(huì)話意味著干凈的上下文讓 step-01 能把你本輪給出的意圖當(dāng)作“starting intent”處理。第 2 步用自由形式表達(dá)你的意圖Build 接受自由形式forme libre的意圖——你可以在調(diào)用命令之前、同時(shí)或之后描述需求不必整理得很干凈。原文檔給出了 5 種典型形態(tài)build — Corrige le bug de validation de connexion qui permet les mots de passe vides.build — corrige https://github.com/org/repo/issues/42build — implémente _bmad-output/implementation-artifacts/my-intent.mdJe pense que le problème est dans le middleware dauth, il ne vérifie pas lexpiration du token. Regardons... oui, src/auth/middleware.ts ligne 47 saute complètement la vérification exp. lance buildbuild Que voulez-vous faire ? Refactoriser UserService pour utiliser async/await au lieu des callbacks.可以看到意圖可以是純文本描述、文件路徑、GitHub issue URL、bug 跟蹤器鏈接——任何 LLM 能將其解析為“一個(gè)具體意圖intention concrète”的輸入都行。英文版文檔docs/build/build-a-change.md用/bmad-build作為命令形式與法語文檔中的build是同一入口兩者等價(jià)。從源碼看step-01 對(duì)意圖的處理相當(dāng)寬容即使是一段很簡短的自由描述“a freeform request is starting intent even when it is brief”也會(huì)被當(dāng)作起始意圖而不會(huì)要求用戶重新表述見 skills/bmad-build/step-01-clarify-and-route.md。同時(shí)詳細(xì)得像計(jì)劃一樣的意圖也只是“待調(diào)查的輸入”不是跳過 Build 步驟的授權(quán)——workflow 會(huì)忽略意圖中“直接實(shí)現(xiàn)、跳過步驟”之類的指令一切仍要經(jīng)過調(diào)查與 spec 生成。關(guān)于目錄與產(chǎn)物上面的示例提到了_bmad-output/implementation-artifacts/這是 BMAD 默認(rèn)的輸出目錄。在配置模板 skills/bmad/assets/config.template.toml 中可以確認(rèn)其默認(rèn)約定[core] project_name {directory_name} output_folder {project-root}/_bmad-output [modules.bmm] planning_artifacts {project-root}/_bmad-output/planning-artifacts implementation_artifacts {project-root}/_bmad-output/implementation-artifacts project_knowledge {project-root}/docs即規(guī)劃產(chǎn)物PRD、架構(gòu)、UX、Epics 等落在_bmad-output/planning-artifacts實(shí)現(xiàn)產(chǎn)物spec、實(shí)現(xiàn)記錄、deferred-work.md 等落在_bmad-output/implementation-artifacts。你可以在customize.toml或安裝配置中修改這些路徑但示例中的_bmad-output/implementation-artifacts/my-intent.md指的就是實(shí)現(xiàn)產(chǎn)物目錄下的意圖文件。第 3 步回答澄清問題并批準(zhǔn)計(jì)劃Build 可能會(huì)提出澄清問題或先呈現(xiàn)一份**簡短的 spec規(guī)格說明**請求你批準(zhǔn)然后才開始實(shí)現(xiàn)。你需要回答它的問題并在對(duì)方案滿意后批準(zhǔn)。這里的批準(zhǔn)節(jié)點(diǎn)在源碼里有精確的位置step-02 結(jié)束時(shí)的CHECKPOINT 1見 skills/bmad-build/step-02-plan.md。在檢查點(diǎn)之前step-02 會(huì)完成兩件事調(diào)查代碼庫優(yōu)先派發(fā) deep search 給 subagent把“要復(fù)用的文件/符號(hào)/行、不要改動(dòng)什么”寫進(jìn) spec 的## Code Map用 READY FOR DEVELOPMENT 標(biāo)準(zhǔn)自檢spec 必須 Actionable每個(gè)任務(wù)有文件路徑與具體動(dòng)作、Logical按依賴排序、Testable驗(yàn)收條件用 Given/When/Then、Complete無占位符/TBD、Sufficient無未解決的缺口、Coherent無歧義或矛盾見 skills/bmad-build/workflow.md。如果調(diào)查無法從倉庫與規(guī)劃產(chǎn)物中得出結(jié)論會(huì)以O(shè)pen Questions形式列出由你逐條拍板——此時(shí) Build 會(huì) HALT 等待人工輸入而不是自行猜測。批準(zhǔn)后spec 中frozen-after-approval塊內(nèi)的內(nèi)容被鎖定只有人可以修改step-01 的多目標(biāo)檢查Multi-goal check和 step-02 的 token 數(shù)檢查SCOPE STANDARD 建議單目標(biāo) 900–1600 token也會(huì)在此時(shí)生效——一旦發(fā)現(xiàn)“一個(gè)請求里塞了多個(gè)可獨(dú)立交付的目標(biāo)”會(huì)把多余目標(biāo)寫入deferred-work.md詳見下文“延遲工作”小節(jié)。一個(gè)小而關(guān)鍵的實(shí)踐點(diǎn)原文檔強(qiáng)調(diào)“改計(jì)劃比改代碼便宜”。如果批準(zhǔn)的方案不對(duì)不要遷就直接要求修改——把問題消滅在 spec 層比等代碼寫出來再返工劃算得多。第 4 步審閱并推送結(jié)果批準(zhǔn)后Build 進(jìn)入實(shí)現(xiàn)—自審—修復(fù)—本地提交的循環(huán)實(shí)現(xiàn)按 spec 修改代碼step-03 會(huì)先在 spec frontmatter 記錄baseline_commit再派發(fā)實(shí)現(xiàn)子代理見 skills/bmad-build/step-03-implement.md自審將改動(dòng)生成 unified diff含未跟蹤文件交給獨(dú)立評(píng)審?fù)哥Rreview lens審查并按high/medium/low/false/maybe-false給出 triage 判定見 skills/bmad-build/step-04-review.md修復(fù)屬于本次改動(dòng)的問題patch/intent_gap/bad_spec就地修復(fù)或回環(huán)重做與本次改動(dòng)無關(guān)的既有問題defer記入延遲列表本地提交step-05 用符合 Conventional Commits 規(guī)范的 message 創(chuàng)建本地 commit見 skills/bmad-build/step-05-present.md。完成之后Build 會(huì)在你的編輯器中打開所有受影響的文件此時(shí)需要你親自把關(guān)瀏覽 diff確認(rèn)改動(dòng)與你的意圖一致如果哪里不對(duì)直接告訴 agent 要修正什么——它可以在同一會(huì)話內(nèi)迭代滿意之后Build 會(huì)主動(dòng)建議你推送并創(chuàng)建 PR。如果推送后出了問題怎么辦原文檔給了一個(gè)明確的回滾預(yù)案若推送的改動(dòng)引發(fā)意外問題使用git revert HEAD干凈地撤銷最近一次提交。然后開啟一條新會(huì)話重新運(yùn)行 Build嘗試不同的方案。注意這里刻意選用git revert而非git reset——它保留歷史、生成一個(gè)反向提交適合“已推送、團(tuán)隊(duì)可能已拉取”的場景?；貪L后務(wù)必開新會(huì)話再跑一次 Build原因同第 1 步讓 step-01 的路由判斷不受舊意圖污染。你能得到什么一次成功的快速修復(fù)執(zhí)行會(huì)產(chǎn)出三樣?xùn)|西修改后的源文件——修復(fù)或重構(gòu)已生效通過的測試——前提是你的項(xiàng)目有測試套件BMAD 的 spec 模板要求驗(yàn)收條件可測且 step-03 有 Matrix Test Audit 環(huán)節(jié)會(huì)逐行核對(duì) I/O 與邊界用例矩陣是否都有對(duì)應(yīng)測試覆蓋并通過見 skills/bmad-build/step-03-implement.md一個(gè)可直接推送的本地 commit——帶符合 Conventional Commits 規(guī)范的提交信息。延遲工作Deferred Work機(jī)制Build 的每次執(zhí)行都只聚焦單一目標(biāo)。如果出現(xiàn)以下情況多余的工作不會(huì)在當(dāng)前會(huì)話里硬塞而是被**延遲différée**到一個(gè)文件deferred-work.md位于你的實(shí)現(xiàn)產(chǎn)物目錄即_bmad-output/implementation-artifacts/deferred-work.md你的請求包含多個(gè)互相獨(dú)立的目標(biāo)評(píng)審發(fā)現(xiàn)了與本次改動(dòng)無關(guān)的既有問題。源碼中這兩條路徑都真實(shí)存在step-01 的 Multi-goal check 在用戶選擇“拆分為單個(gè)目標(biāo)”時(shí)會(huì)把每個(gè)被推遲的目標(biāo)追加一條- source_spec: none / summary / evidence記錄見 skills/bmad-build/step-01-clarify-and-route.mdstep-04 的 triage 則會(huì)把“pre-existing issue not caused by this story”路由到 defer同樣以- source_spec: {spec_file} / summary / evidence格式追加見 skills/bmad-build/step-04-review.md。兩種格式都帶summary一句話說明被延遲的目標(biāo)和evidence為什么被拆出/為什么判定為真并且不會(huì)修改已有條目、不查重——保證每次都只是純追加。deferred-work.md就是你的 backlog一次執(zhí)行結(jié)束后去查看它里面每一項(xiàng)都可以在后續(xù)的新一輪 Build 執(zhí)行中作為新意圖再次引入。這避免了“順手把所有問題一起修掉”的失控也讓無關(guān)的既有問題不會(huì)被遺忘。何時(shí)添加正式規(guī)劃在再次運(yùn)行同一條 Build 循環(huán)之前先想清楚是否該先補(bǔ)一份 PRD、UX、架構(gòu)或 Story 規(guī)劃原文檔給出的觸發(fā)條件是改動(dòng)影響多個(gè)系統(tǒng)或需要在大量文件中做協(xié)調(diào)更新你對(duì)范圍沒把握需要先做需求發(fā)現(xiàn)團(tuán)隊(duì)需要留檔——需要文檔或架構(gòu)決策記錄。從更大的視角看英文版 docs/build/build-a-change.md 有更完整的表述較大型的工作本質(zhì)上是一連串“單會(huì)話改動(dòng)”的序列父 spec 持有共享目標(biāo)story 記錄承載決策與完成狀態(tài)集成檢查與回顧retrospective覆蓋合并結(jié)果。bmad-build只處理“一個(gè)單元”它不擁有 backlog、不挑選下一個(gè) story、也不替代后續(xù)檢查?？焖傩迯?fù)路線與正式規(guī)劃并非對(duì)立而是同一個(gè)實(shí)現(xiàn)循環(huán)docs/build/build-a-change.md在不同前置投入下的兩種入口——直接意圖與已規(guī)劃工作最終匯入同一條 Build 循環(huán)。延伸閱讀docs/fr/how-to/quick-fixes.md——本文法語原文docs/build/build-a-change.md——bmad-build完整使用指南英文含工作規(guī)模建議與延遲工作的完整說明skills/bmad-build/workflow.md——Build 工作流總綱定義了 Ready-for-Development 標(biāo)準(zhǔn)與 SCOPE STANDARDskills/bmad-build/step-01-clarify-and-route.md——意圖解析與路由判定skills/bmad-build/step-02-plan.md——調(diào)查與 spec 生成、CHECKPOINT 1 批準(zhǔn)節(jié)點(diǎn)skills/bmad-build/step-03-implement.md——實(shí)現(xiàn)、diff 暫存與 Matrix Test Auditskills/bmad-build/step-04-review.md——評(píng)審、triage 與 defer/patch 路由skills/bmad-build/step-05-present.md——本地提交與結(jié)果呈現(xiàn)skills/bmad/assets/config.template.toml——默認(rèn)目錄與代理配置模板。贊分享AI 技能人工智能開發(fā)工具【免費(fèi)下載鏈接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development項(xiàng)目地址https://gitcode.com/gh_mirrors/bm/BMAD-METHOD點(diǎn)擊查看免費(fèi)下載相關(guān)推薦BMAD-METHOD 快速修復(fù)指南讓 Bug 修復(fù)與小型重構(gòu)直接進(jìn)入 bmad-build 實(shí)現(xiàn)循環(huán)BMAD METHOD 快速修復(fù)指南讓 Bug 修復(fù)與小型重構(gòu)直接進(jìn)入 bmad build 實(shí)現(xiàn)循環(huán) 本篇技術(shù)指南聚焦于 BMAD METHODBreakAI 技能人工智能開發(fā)工具BMad Method 快速修復(fù)實(shí)戰(zhàn)指南零規(guī)劃直通 Build 交付循環(huán)BMad Method 快速修復(fù)實(shí)戰(zhàn)指南零規(guī)劃直通 Build 交付循環(huán) Bug 修復(fù)、小型重構(gòu)、配置調(diào)整和依賴更新這類小改動(dòng)不需要 PRD、Story 或AI 技能人工智能開發(fā)工具如何用 BMAD-METHOD 的 bmad-build 在無上游規(guī)劃的情況下完成一次已知 bug 修復(fù)如何用 BMAD METHOD 的 bmad build 在無上游規(guī)劃的情況下完成一次已知 bug 修復(fù) 這篇文章面向在 AI IDE 中使用 BMAD METAI 技能人工智能開發(fā)工具創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考