Skip to main content

BMAD

How to Plan & Build Complex Apps with Free AI (BMAD V2 Full Workflow Tutorial)

介紹 BMAD V2 方法

截圖 1

感謝你加入 BMAD code。今天我要向你展示敏捷 AI 驅動開發的 BMAD 方法的驚人更新。這個方法是根據社群和許多一直在觀看和支援這個頻道的觀眾的反饋而提升的。我採納了你們的建議,讓這個方法變得更加強大。今天我要向你展示如何最大化其潛力。

在上一部影片中,我說過我們要建立一個應用程式,可以抓取 Hacker News 的前 10 則新聞,發送每日摘要,但我們要將其提升到下一個層次。我們還要讓它建立一個真正的 AI 生成的播客,內容是 Hacker News 的熱門新聞和評論。這會很有趣,我要向你展示如何用敏捷 AI 驅動開發的突破性方法來做到這一點,我們稱之為 BMAD 方法。

BMAD V2 的重大改進

截圖 2

上次我向你展示了如何在 IDE 中執行 BMAD 方法的前四個階段,但我們要將其提升到下一個層次,在 Gemini 中使用 2.5 Pro 的全部功能和其 100 萬 token 的內容視窗來完成。

目前的 V2 資料夾是新版本的方法論。這個 repo 會詳細說明為什麼會有這個版本。我更新的主要原因有兩個:

代理程式的統一性

截圖 3

第一,我希望進入你 IDE 的代理程式與你可能想要放入 Gemini 或 ChatGPT 自訂 gems 的代理程式保持一致。我優化了所有代理程式,讓它們精簡、強大且更具互動性。現在,不再只是要求 PRD,讓它問你幾個問題然後輸出整個檔案,而是會更加互動式地工作。架構師 (architect)、業務分析師 (business analyst) 和 Scrum Master 以及 PO 也是如此。

為 LLM 開發優化

截圖 4

V2 方法是為與 LLM 開發而優化的。以前我們會產生非常大的 PRD 和非常大的架構文本,但問題是開發者代理程式知道要查看哪個故事,但開發者代理程式也必須載入完整的 PRD 和完整的架構文本才能找到所需的資訊。這非常低效,導致代理程式臃腫。它能工作,但不理想。

在 V2 中,一切都經過精簡。讓我向你展示。進入目前的 V2 資料夾。你會看到有 gems 和 GPTs。這是為了我們的四個代理程式,我們實際上把它們放入 Gemini 或 ChatGPT 中,就像我提到的。但你這裡仍然有所有的代理程式。所以,你可以有自訂的 Scrum Master 或開發者。

設定自訂代理程式

截圖 5

但我建議使用我今天要向你展示的方法,將這些代理程式實際放入網路並設定它們。我們將使用分析師、產品經理或架構師,獲得網路的全部功能,不會在 Cursor 或 Windsurf 或我們自己的 LLM 中浪費任何積分。

多人在上次聯繫我,說僅僅從我上次分享的想法(因為我確實提到你也可以在網路上這樣做),就已經節省了數百美元。有一個人甚至告訴我,自從轉換到我的方法後,他們節省了超過 1,000 美元的積分。

在 Gemini 中設定代理程式

截圖 6

讓我向你展示如何設定其中一個,但你可以閱讀這些說明。非常簡單。讓我們跳到網路上。你會進來這裡,給它一個名字。我總是以數字開頭,因為在 Gemini 中你會看到這個圓圈。當你在導航中時,你只會看到這個來識別它。所以我要叫它架構師 2,這樣我可以與另一個區分開來。

我們要來到我們的架構師 gem。我們要複製這裡的所有內容,然後貼到這裡。來到說明,你要尋找你正在設定的那個。對於架構師,我們需要架構範本和架構檢查清單。我們要點擊加號按鈕。然後我們要說上傳檔案、範本,我們要找到我們的兩個架構師檔案。我們要確保它們變成藍色。如果它們變紅色,那意味著是無效檔案。現在我們要儲存它。現在,每當你回到 Gemini 時,你的自訂 gem 就準備好了。

在 OpenAI 的 ChatGPT 中也有類似的流程。他們有自訂 GPTs。

業務分析師的功能

截圖 7

我在這裡使用 BA (Business Analyst)。首先,這個 BA 是一個腦力激盪精靈。它實際上有三種工作模式。它可以為你進行腦力激盪。它可以進行深度研究,或者可以直接跳入產生產品簡報或專案簡報。專案簡報是 BA 的最終輸出。

在其中,它不僅會有一個小專案簡報,還會有一個自訂的提示,準備好給 PM。

腦力激盪過程

截圖 8

我說:「我嘗試製作一個簡單的應用程式來演示整個方法論。」它可以幫你腦力激盪一些事情。你想要做什麼?也許是一個簡單的實用工具等等,對吧?它給了我一些想法。

我說:「好的,你提到了待辦事項應用程式。那可能是一個簡單的事情,但可能有點無聊。如果我們實際上結合一些 AI 或一些 LLM 智慧呢?那可能會很有趣。」所以,它給了我更多想法。我想了想,我說:「你知道嗎?我不想做那個。我認為讓它抓取前 10 則故事和它們連結的文章以及來自 Hacker News 的評論會很有趣。我們可以發送一封由 LLM 總結的每日簡報電子郵件。」

專案需求確定

截圖 9

由於這是一個演示,我想保持簡單並向你展示完整的應用程式建立,我想保持相當簡單,只在本地開發所有內容。所以,我來回腦力激盪。我提到了所有這些。我說我想使用本地 LLM。我提醒它我也想獲取文章內容,但我想保持簡單。

在第一個中,它說有很多機會,很多不同的挑戰。你知道,有不同的抓取方式,因為有 JavaScript 可能會阻擋內容。有安全功能。我說我只想保持簡單。讓我們現在只做最簡單的抓取方式。我想使用 Node.js。我想使用 TypeScript。我們不會部署這個。我們只會在本地做。但在未來,我想部署這個。

所以,我想能夠使用本地 LLM,只用 Ollama。你知道,我只想保持簡單,但我也告訴它我想在未來做什麼。

意外的建議

截圖 10

來回腦力激盪對我來說。這是最酷的事情之一。我甚至沒有預期這個,但它建議既然我想獲取評論,當我們來回談話時,我說,你知道,我想做一些有點不同的事情。如果我們的 LLM 也取得所有評論,然後將其總結成有趣的摘要,稍後我們可以將所有這些傳遞給 AI 來製作我們總結的所有內容的播客,會怎麼樣?

它發現有這個 Algolia API,基本上讓獲取 Hacker News 中所有已經串接的評論變得更簡單,而不是透過他們的 API 的正常方式。我永遠不會想到這個。它想到了並向我建議,這實際上會讓到達我們想要做的目標更簡單、更容易。

非常酷。然後說,好的,你想給你的專案取什麼名字?我喜歡那個。我甚至沒想到命名它,它說,我應該給它取什麼名字?它給了我一個建議。我不喜歡。我說,BMAD Hacker 每日摘要怎麼樣?它說,好的,這基本上聽起來不錯嗎?我說,那完美。讓我們做吧。

產品經理的工作流程

截圖 11

所以,然後它進入下一個部分,這是逐部分進行的。所以,現在它要談論願景和目標。我說:「是的,那很好。我喜歡它。我喜歡這是細粒度的,逐步進行,所以我不必一次接受很多東西。」所以,它提出了。我說:「是的,那很好。我喜歡範圍。」等等,對吧?我不會浪費你的時間閱讀所有這些。

這是我來回很多次真正推進這個,因為我只想看到這個腦力激盪能夠做的所有事情。所以,這是文本的結尾。整個文本準備好輸出,它給了那個 PM 提示。

儲存工作流程

截圖 12

現在,在這一點上,我會做的是複製這個並將其儲存到 Google Doc。這很簡單,因為它給你這裡的複製按鈕。你可以複製那個,然後一旦你複製它,只需將其儲存到 Google Doc。儲存它。然後當你去你的 PM 提示時,去探索 gems。如果你找不到它,我要去這裡的 PM 附件。

PM 將產生一個 PRD,它將像我說的那樣逐部分詢問你問題。這讓接受這些事情變得非常容易。現在這裡我們已經有了我們的 PRD 草稿,因為它得到了如此詳細的產品簡報。它能夠快速想出這個,並找出什麼是 MVP,什麼不是 MVP。

Epic 建立過程

截圖 13

然後它會逐部分詢問我們是否同意一切。所以它給了我們高層次的 epic,但現在它要一次建立一個 epic 並讓我們審查它。它會給我們高層次的故事和驗收標準。所以這是它認為第一個故事應該是什麼。我審查了它,我說:「好的,那看起來不錯。」然後它給了我們 epic 2、epic 3 和 epic 4。

你要擷取每個檔案並儲存那些。你可以做我之前說的,將它們儲存為 Google doc,或者你可以將所有這些直接儲存到你的專案中。所以你可以將它們都直接放在我們的專案中。

專案結構展示

截圖 14

所以你可以看到這裡我已經開始建立專案並將其中一些檔案收集到文件資料夾中。所以你可以看到我有它建立的所有 epic 檔案。你也可以提前看到我有 PRD 和很多內容。你看到這裡有很多檔案。架構師不再只包含一個架構檔案。它為我們建立了編碼標準、資料模型、環境變數、產品結構,非常重要。

PM 的最終檢查

截圖 15

回到 PM,我們要成為這個 LLM 的積極參與者。我們要告訴它執行檢查清單。它會說,在我們將此交給架構師之前,你準備好執行檢查清單了嗎?這是 PM 的最終批准,以確保它產生的一切都有意義。

由於它是細粒度地做所有事情,現在它要取得所有這些並整體地查看它們,確保它滿足產品簡報的目標、它自己的 PRD,並且順序基本上有意義到這一點。

所以,它會執行一個相當長的檢查清單。它檢查很多事情。它實際上也在這裡考慮其他事情。它沒有發現任何關鍵問題。這是你想要尋找的基本事情,就是這個最終輸出。它非常簡潔和切中要點。如果它確實發現任何東西,它會告訴你。

現在這裡,很好的是它說它沒有發現任何關鍵缺陷。Epic 是全面的並與簡報一致。它批准這現在已經準備好給架構師。所以,我們現在準備好交接了。

與 IDE 的成本比較

截圖 16

在你的 IDE 中與 LLM 來回做所有這些會浪費很多積分,或者你會使用具有低內容視窗的非常低功率模型,它會錯過事情。或者你不這樣做,然後你實際上沒有規劃,你會有差距並可能稍後遇到問題。

架構師的改進

截圖 17

這次在 BMAD 方法的 V2 中,我認為架構師是最改進的,因為它產生這些細粒度的小 artifacts,開發者真的可以消化,但它也被調整為以迭代方式與你工作,讓你更好地理解正在發生的事情並與之合作,也學到很多,因為它會像我們的 PM 一樣增量地工作。

架構師的工作流程

截圖 18

看看這個。我們把所有文本放在這裡,草稿、PRD 和所有 epic。它已經有了 PM 給我們的提示,基本上讓架構師開始。它會確認將處於架構建立模式,因為 PM 也有多種模式。

它會首先確認方法。它會說如果我們想要的話,我們可以做 yolo 模式。如果我們做那個 yolo 模式,我不建議,它只會輸出整個架構,可能不會像如果我們透過實際流程那樣好。

所以,這不會花太長時間。因為這會細粒度地做,你會一路理解一切。所以,首先它只會告訴你一些基礎的東西,然後它會繼續技術選擇。

技術選擇過程

截圖 19

這是我們要用於文章抓取的。它找到了一個我甚至沒有考慮過的函式庫,它正在考慮這兩個,它實際上告訴你為什麼它推薦兩者中的一個。所以不是 Cheerio,它要使用來自 Extractus 的文章萃取器。

現在你可以告訴它不,你想在這裡使用其他東西。看,這裡要使用日期函式而不是日期,但我就是喜歡這非常非常清楚地解釋它。所以這是它找到的依賴項摘要。我可以說:「是的,去做吧。」然後它會對下一部分做同樣的事情。

架構師的決策制定

截圖 20

但這被調整為非常清楚地與你溝通,解釋它做出的每個決定或每個選擇。它會做出選擇。這是 BMAD 方法 V2 版本的另一個大好處,有時它會讓事情保持模糊。

例如,在過去,它可能會說使用 Axios 或 fetch。現在,那是兩個做同樣事情的不同函式庫,有點開放式。這會變成災難的地方是稍後如果你沒有捕捉到那個並實際上將其更正為一個,稍後當你的代理程式正在開發時。假設它們開始使用 Axios 與其他 API 通信,然後它進入測試、失敗、死亡螺旋。

你以前見過這種情況發生在你的代理程式身上,我敢打賭。它們開始轉圈。它們嘗試改變程式碼。它們嘗試修復程式碼。事情開始破壞。接下來發生的是它有這個愚蠢的想法,哦,也許是我正在使用的函式庫。我看到提到的這個其他函式庫,所以我只要丟這個其他函式庫。然後突然間,你的專案中有兩個函式庫。你甚至沒有意識到。然後一切都偏離軌道。

這一切都是因為有時事情會模糊,但不再是了。使用這種方法,它會確保一切都有決定,不會讓它開放式。

持續學習和互動

截圖 21

所以,你會一路完成這個架構。你也可以向它建議事情。它會向你建議事情。但這只會是一個美妙的學習過程。不僅建議,你也可以問問題。如果它說它顯示某個東西而不是其他東西,你不理解解釋,問它或挑戰它。讓它搜尋網路。

這個東西是迭代的,只要你想要,這可以繼續下去。但透過真正理解並找出所有這些東西,我們將有更多成功的機會,隨著我們的專案進行和成長。

架構師的檔案管理

截圖 22

架構師的一個特點是它產生很多檔案。所以要取得所有這些檔案,你知道,可能會很痛苦。另外,很多這些文本都有嵌入的 mermaid。

Gemini 和 ChatGPT 的重要功能

截圖 23

所以,我想向你解釋關於 Gemini 和 ChatGPT 的一些非常重要的事情。當你在網路上時,你看到的所有輸出,比如這裡,實際上已經是 markdown。所以,我在 V2 中做的關鍵改變是代理程式不再將所有輸出包裝在 markdown 中。它們給你 markdown。然後有時這個輸出會有嵌入的 markdown。

所以這就是為什麼你有時仍然看到這樣的東西。這是 markdown 程式碼片段。這是純文字的 markdown。以前複製所有這些會搞砸。但現在你可以做的是來到這裡回應的結尾。每次它完成回應,會有這些三個點。你點這個。你點複製。

我只想讓你注意到現在這整個東西是完美的 markdown。沒有任何東西被破壞。你所要做的就是去掉開頭和去掉這裡的結尾。結尾在這裡。現在我們有了完美萃取的 markdown。

產品負責人的檢查清單

截圖 24

架構師也會執行檢查清單。這裡最強大的一個,如果沒有別的,在網路上做這個。這非常強大。這個 PO 取得你所有的文本。所以所有你知道的六或八個架構文本,所有你的 epic 檔案與高層次故事和你的 PRD,它會分析所有這些。

這是 Gemini 的巨大內容視窗真正有回報的地方,因為它是專門調整的。這一切所做的就是執行檢查清單。PO 所做的一切就是執行檢查清單。沒有很多來回詢問。它只是檢查一切都到位,你有一個良好的堅實框架,你有任何故事指出你作為使用者可能需要做的手動設定來讓你的專案起步,比如設定 GitHub,也許購買 API 金鑰,註冊帳戶,獲取基礎設施,無論什麼,對吧?它會確保所有這些都到位。

PO 的智慧理解

截圖 25

它也會比其他的更理解這一切都將由非常愚蠢的開發者代理程式開發。即使使用最強大的模型,LLM 仍然不那麼聰明,對吧?沒有適當的內容,它們仍然會犯錯誤。所以這個東西知道我們需要有完美順序的故事,我們需要有所有架構和其他文本圍繞它,真正給我們的開發者代理程式最好的機會能夠推進我們的專案並正確完成。

所以它會檢查架構和之前完成的 PRD artifacts 之間的不一致,並確保它們都一致。在最後我們會跳到前面。它會分析一切,它會給你一個最終決定,它說它被批准了。

檢查結果示例

截圖 26

現在,在這種情況下,它確實給了我們摘要。一切都通過了,但它只是發現了一些小缺陷。它發現的缺陷實際上很有趣。我忘記將一個檔案附加到 PO,所以它只是認為缺少某些東西並指出了。這是 Epic 4 中需要的東西。所以,相當小,但說在 Epic 4 之前需要建立。所以我只是糾正了它並告訴它哦實際上那已經存在。

進入開發階段

截圖 27

請按讚這個影片並訂閱頻道如果你還沒有。我們要跳入 Cursor,但你可以使用任何 IDE,我要向你展示如何實際現在使用 Scrum Master。

Scrum Master 代理程式

截圖 28

SM 代理程式被調整為一次產生一個故事的草稿模式,然後你切換到開發者代理程式。這基本上是我們想要在 IDE 中生活的地方。我們在這一點上完成了網路。我們節省了大量金錢。我們有大量功能真正產生驚人的 artifacts。

這些 artifacts 不可能用 Taskmaster 或其他一些做到。它們會給你簡單專案的良好流程,但你必須有非常好的提示來餵給它們以獲得適當的流程。那就是我們產生的 artifacts,導致這一點。

開發工作流程

截圖 29

所以現在我們在這裡,我們有包含高層次故事的 epic。那是我們的任務。Scrum Master 會在 IDE 中起草一個故事。我們會批准它。我們會與開發者開始新聊天。開發者有自己的自訂說明。

所以它確切知道這些不同故事檔案在哪裡,如何使用它們,Scrum Master 放入故事的內容,因為 Scrum Master 知道拉取所有各種架構和 PRD 和 epic 的片段。它查看所有這些檔案,它只把開發者代理程式需要的東西放入故事。

開發最佳實務

截圖 30

我想在這裡暫停並說我收到的很多問題是當開發者代理程式偏離軌道時你該怎麼辦?我們會在完整應用程式建立中演示這個。但如果我現在可以告訴你一件事,如果你還沒有意識到這一點,永遠不要完成一個故事然後在同一個聊天視窗中開始新故事。內容會增長,你只是不需要這樣做。所以繼續與你的開發者或 Scrum Master 開始新的聊天視窗。

但第二個是確保你讓代理程式寫測試,你與架構師制定測試計劃。它會建議某些東西,但你也可以向它建議。但確保你有良好的測試覆蓋率,特別是單元測試覆蓋率,這是針對每個小功能程式碼片段的細粒度測試。

這些測試會一次又一次地拯救你。當故事被實作時,你確保所有測試通過,但你也確保所有先前故事的所有測試都通過。只有當它們通過時,然後你提交你的程式碼並推送到遠端。現在故事完成了。現在,你繼續。

錯誤恢復策略

截圖 31

現在,假設你在下一個故事的一半,發生了什麼事情。它搞砸了。也許它混亂了或者你有錯誤的指令在那裡,它開始把東西扔得到處都是,你不知道如何退出或讓它回到軌道上,或者也許你讓它穩定,但它造成了很大的混亂,現在你不知道該怎麼辦。

很多次我看到最好是扔掉所有這些並回到開頭,既然你在上一個故事結束時將所有東西推送到遠端,你只回到故事的開頭。這不會太遠,因為這些故事意味著是細粒度的增量交付。所以恢復並重新開始並採取不同方法很容易。

也許那個不同的方法是查看 Scrum Master 寫的故事,看看它是否在那裡犯了錯誤,或者看看你是否可以在那裡澄清某些東西,所以開發代理程式不會犯同樣的錯誤。確保你經常提交並推送到遠端,然後如果事情真的偏離軌道,你總是可以及時回到任何你需要的點。

專案初始化建議

截圖 32

如果你有啟動專案或者你可以自己搭建,也許用 Next.js,你知道,專案 init 或 Nest.js 或一些現成的東西。建立基線,因為你會節省很多時間和積分,而不是嘗試讓 Cursor 或 Windsurf 為你搭建所有這些。它會犯錯誤或搞砸 linting 或某些配置。最好只是從專案基線開始,並早期告訴你的 PM 和架構師你開始的設定。它會讓事情容易得多。

實際開發演示

截圖 33

我已經完成了故事一,因為這只是一些基本設定,說是的,樣板到位。SM 知道,我可以說起草下一個故事。它知道首先查看這個資料夾。如果它在這個故事資料夾中看不到任何東西,它會看到 PRD 中列出了什麼 epic,它會找到第一個 epic,epic 一,它會看到第一個故事是需要發生的。

現在在這種情況下,它會在這裡找到一個故事,它確實看到狀態是完成的。所以,我們應該看到它查看了範本。所以,它知道如何建立下一個故事。它在這裡看到故事一完成了。所以,它會檢查 epic 並看下一個故事是什麼。它在這裡發現下一個故事應該是故事 1.2,因為故事 1.1 在那裡完成了。

但我喜歡這個工作流程只是知道如何找到下一個是什麼並將其組合在一起。我要完成 epic 一,只是因為它主要是手動設定。然後在下一個影片中,我們要做令人興奮的事情,拉取 Hacker News,建立 LLM 摘要,在電子郵件中發送,抓取網站,然後生成 AI 生成的播客。這會非常令人興奮。

結語

截圖 34

所以,我很快會見到你。我的名字是 Brian。再次,請按讚這個影片,訂閱頻道,查看 repo,給我你的評論和反饋和建議,我們都可以一起幫助改進這個工作流程。我會在下一個影片中見到你。