Vibe Coding 方法論 · 第 2 節
四步流程：複述、PRD、確認、編碼
把軟件工程的需求確認環節搬進人機協作：AI 動手之前必須複述需求、寫出 PRD、拿到明確許可。再加上批量修改斷點和查重規則，把爆炸半徑控制在動手之前。
互動演示一 · 五步流程模擬器
一個真實需求「幫我加多個導出報表功能」，走一遍完整流程。點擊「推進一步」，注意第 4 步：你唔撳「批准」，AI 就唔會寫程式碼。
STEP 1
思考提問
STEP 2
複述需求
STEP 3
編寫 PRD
STEP 4
等待許可
STEP 5
開始開發
為什麼必須給具體步驟
「請先確認理解後再編碼」這句話太模糊。AI 會自己判斷「我已經理解了」，然後直接動手。寫明「寫 PRD、等待許可」這類具體動作，AI 才會真的停下來。實際使用中，簡單的一行改動 AI 會自己判斷不需要 PRD，這套流程主要攔截多文件變更和新功能開發，也就是返工成本最高的那類任務。
互動演示二 · 批量修改斷點
規則原文：「修改超過 3 個文件時，必須先列出修改計劃並等待用戶確認後再動手。」拖動滑塊，改變本次要動的文件數，看斷點什麼時候觸發。
修改計劃的三要素
01
要改哪些文件
完整的文件清單。人先看範圍對不對，再看內容。清單本身就能暴露「點解呢個需求要郁配置文件」這類異常。
02
每個文件改什麼
逐文件寫清楚改動內容。避免 AI 藉着一次需求「順手」做無關的重構和清理。
03
改動之間的依賴關係
先改哪個、後改哪個、誰依賴誰。防止連續改一串文件後發現思路有誤，回滾成本過高。
閾值可以按項目調整：3 個文件是作者項目裏的經驗值，謹慎的項目可以調成 1，快速原型可以放寬到 5。
新增功能前的查重規則
問題：AI 不知道項目裏已經有輪子
AI 的上下文只有當前對話，它看不到三個月前另一個對話裏寫的工具函式。不加約束，同一個 formatDate 會被寫四遍，每遍行為還略有不同。
規則：先搜索，再動手
- 新增功能前，必須先搜索項目中是否已有類似實現
- 搜索範圍：相關目錄的函式名、類名、工具方法
- 找到已有實現時，優先複用或擴展
本節要點
斷點要設在動手之前。複述和 PRD 攔截理解偏差，修改計劃攔截連鎖錯改，查重攔截重複造輪子，三道關卡都比事後回滾便宜。
素材來源：對應 rule-opensource.mdc 第二章「需求處理與開發流程」，倉庫 itshen/xs_vibe_rules。