Plan-then-Execute SOP

Vibe Coding 的端到端工作流程。禁止跳過 Step 1–3 直接進入 Step 4——這是規範底線，違反這條的 PR 直接退回。

7 步流程

Step 1. 需求釐清（人）
  寫下商業目標、使用者故事、Done 的定義

Step 2. Codebase 探索（人 + AI 對話 #1）
  與 AI 一起閱讀相關檔案、列出受影響範圍
  確認應沿用的程式碼風格與設計模式

Step 3. 計畫產出（人 + AI 對話 #1）
  共同擬定 plan.md：步驟、檔案、測試策略、風險
  人類審閱、修改、批准 plan.md
  Compact 對話或開新 session

Step 4. 開新對話執行（AI 對話 #2）
  餵入 plan.md 與必要 context，請 AI 執行

Step 5. 自我驗證（人）
  跑測試、stress test、確認輸入輸出符合規格
  對核心區塊逐行 review；leaf node 抽查

Step 6. PR 提交（人）
  套用 PR 模板，標示 AI 產出範圍

Step 7. Code Review（同儕）
  依 Code Review 準則進行

為什麼分兩個對話（#1 探索/計畫、#2 執行）

避免 context pollution：

• 對話 #1 探索 codebase 會把大量 file content / code reading 灌進 context
• 進入 Step 3 計畫產出時，剩餘 context 已被吃光
• Step 4 開始實作時，AI 容易忘記早期的細節（譬如「不可動 src/auth/」這種 scope 限制）

→ Step 3 結束時 compact 或開新 session，餵入精簡的 plan.md 跟必要 context，重置可用空間。

詳見 Compact 與 Session 管理 SOP。

各 step 的常見錯誤

Step	反模式
1	「Done」沒寫清楚 → AI 產出符合表面需求但漏掉邊界
2	跳過直接打「我要 X 功能」 → AI 重新發明已有 utility
3	plan.md 不審就讓 AI 直接執行 → 計畫本身就錯
4	在對話 #1 直接執行（沒開新對話） → context 灌爆
5	只看「測試 pass」就 approve → 不看測試是否合理
6	PR 不標 AI 範圍 → reviewer 不知道哪裡要嚴看
7	Reviewer 不依 Code Review 準則 (AI 編程) → 沒抓出 AI 特有風險

跟 Be Claude’s PM 法則 的關係

法則一是 input quality（給完整 context），SOP 是 input flow（怎麼把 context 餵進去）。Step 1-3 是法則一的具體實作。

跟陌生 codebase 場景

如果是不熟悉的 codebase，Step 2「Codebase 探索」要更扎實——詳見 陌生 Codebase 探索 SOP。

跟 3A 架構 的對應

3A	Plan-then-Execute Step
Architect (架構)	Step 1-3
Author (執行)	Step 4
Audit (驗證)	Step 5-7

落地工具

• CLAUDE.md 4 層機制 / Skills 九種類型 — 把可重用 context 包好供 Step 2 使用
• Sub-agent — Step 2 codebase 探索可派 sub-agent
• Compounding Engineering — 整體精神
• plan.md 範本（每個團隊自訂）

相關

• Vibe Coding / 四大黃金法則 (Vibe Coding)
• Be Claude’s PM 法則 — 對應法則一
• Compact 與 Session 管理 SOP — Step 3-4 之間的 session 管理
• 陌生 Codebase 探索 SOP — Step 2 的 deep-dive 版
• Prompt 必備六元素 — Step 4 餵入 prompt 的結構
• AI 編程 PR 模板 — Step 6 套用