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 個檔案時，必須先列出修改計劃並等待使用者確認後再動手。」拖動滑塊，改變本次要動的檔案數，看斷點什麼時候觸發。

本次要改的檔案數

2 個檔案

修改計劃的三要素

完整的檔案清單。人先看範圍對不對，再看內容。清單本身就能暴露「怎麼這個需求要動到設定檔」這類異常。

逐檔案寫清楚改動內容。避免 AI 藉著一次需求「順手」做無關的重構和清理。

先改哪個、後改哪個、誰依賴誰。防止連續改一串檔案後發現思路有誤，回滾成本過高。

閾值可以按專案調整：3 個檔案是作者專案裡的經驗值，謹慎的專案可以調成 1，快速原型可以放寬到 5。

新增功能前的查重規則

AI 的上下文只有當前對話，它看不到三個月前另一個對話裡寫的工具函式。不加約束，同一個 formatDate 會被寫四遍，每遍行為還略有不同。

本節要點

斷點要設在動手之前。複述和 PRD 攔截理解偏差，修改計劃攔截連鎖錯改，查重攔截重複造輪子，三道關卡都比事後回滾便宜。

素材來源：對應 rule-opensource.mdc 第二章「需求處理與開發流程」，倉庫 itshen/xs_vibe_rules。