AI 開發的兩條路

用 AI 寫程式，你是先寫 Plan 還是先寫案例？

最近跟幾位工程師朋友聊到各自怎麼搭配 AI 開發，發現大家的做法大致分成兩派：

【Plan 派】先跟 AI 討論需求，產出 plan.md，再照著 plan 用 TDD 開發 【BDD 派】先跟 AI 用案例探討需求，產出 feature file，再照著 feature file 用 TDD 開發

兩條路最終都走向 TDD，差別在於「怎麼定義需求」這一步。

Plan 派的優勢在於彈性。你可以在 plan 裡面放架構設計、效能考量、未來擴展性這些「非功能性需求」。但代價是非常吃工程師的經驗——DB 怎麼設計比較好、domain 怎麼切未來好擴展，這些隱性知識很難光靠 prompt 傳達給 AI。

BDD 派的優勢在於結構。Given/When/Then 的格式本身就是一道護欄，強迫你把需求拆成具體案例，還能直接生成 E2E test 骨架。但它天生對非功能性需求不太友善——你很難用一個 scenario 描述「系統要能撐住一千人同時上線」，這類需求只能靠額外文件補充，而這些文件往往缺乏測試覆蓋，時間久了容易跟實際系統脫節。

兩種做法還有一個共同的挑戰：當文件數量成長到一定規模，很難追蹤新功能會影響到哪些既有功能，甚至可能出現需求互相矛盾卻沒人發現的情況。

或許有人會說兩者可以並用——Plan 處理架構決策，BDD 處理功能需求。但這裡有個根本的矛盾：BDD 的最大優勢是 feature file 同時作為需求文件和測試依據，所有需求都有自動化驗證來確保文件不會過時。一旦你在旁邊放了額外的架構文件或非功能性需求文件，這些文件沒有對應的測試保護，隨著系統迭代就容易跟現實脫節，反而破壞了 BDD「活文件」的可信度。

所以這不只是工具選擇的問題，更是一個還沒有完美解法的取捨——你要 BDD 的文件可信度，就得接受它對非功能性需求的侷限；你要完整涵蓋非功能性需求，就得接受一部分文件會脫離自動化驗證的保護網。