PRD驅動開發：我如何用30多份PRD搭配AI代理人交付成果

SaasMaker的RalphBlaster工作流程能在45分鐘內從一行工單生成完整的pull request，開發者在實作過程中完全不需要接觸程式碼。¹

我嘗試過這個模式。它確實有效。但它也會以展示影片中看不到的方式失敗。

TL;DR

過去六個月，我撰寫了超過30份PRD用於AI代理人任務。這個模式對定義明確且具有清晰驗收標準的任務效果良好：CRUD端點、測試新增、遵循既有模式的UI元件。但它在面對模糊需求、全新架構決策，以及任何需要反覆人工判斷的任務時會失敗。我的PRD範本從簡單的使用者故事格式，演進為包含檔案位置、測試期望、限制條件和明確「禁止修改」清單的結構化文件。這個演進之所以發生，是因為代理人會以出人意料的方式解讀模糊的PRD。

我實際使用的工作流程

步驟1：建立工單

我用白話描述需要完成的事項。具體程度比我最初想像的更為重要：

模糊（產生不可預測的結果）：

Add user preference saving to the settings page.

具體（產生可預測的結果）：

Add dark mode toggle to /settings. Persist to user_preferences
table (column: dark_mode, type: boolean, default: false).
Use existing SettingsForm component. Add toggle below the
notification section. No new dependencies.

第二個版本對代理人施加了足夠的限制，使輸出結果符合預期。第一個版本卻給了我一個包含新React元件、三個新npm套件，以及用localStorage實作而非我想要的資料庫持久化的設定頁面。

步驟2：生成或撰寫PRD

我的/prd技能會將工單轉換為結構化的PRD，包含使用者故事、驗收標準、檔案位置和測試期望。²一份典型的PRD如下所示：

## Story: Add dark mode toggle
**As a** user
**I want to** toggle dark mode from settings
**So that** I can read comfortably in low light

### Acceptance Criteria
- [ ] Toggle appears in SettingsForm below notifications
- [ ] Persists to user_preferences.dark_mode (boolean)
- [ ] Default: false (light mode)
- [ ] Toggle state reflects current DB value on page load

### Files to Modify
- app/routes/settings.py (add dark_mode to form handler)
- app/templates/settings.html (add toggle component)
- app/models/user.py (add dark_mode column if missing)

### Files NOT to Modify
- app/static/css/styles.css (dark mode CSS already exists)
- app/templates/base.html (already reads dark_mode class)

### Test Expectations
- Test toggle persists to database
- Test default value on new user
- Test toggle reflects current state on reload

「Files NOT to Modify」區段是範本演進中最重要的改變。沒有它的話，代理人會好心地「改善」相關檔案，引入我未要求也不希望的變更。

步驟3：代理人實作

代理人在獨立的git worktree中工作，避免干擾我目前的分支：³

# Create isolated worktree for agent task
git worktree add ../worktrees/dark-mode -b feature/dark-mode

# Agent works in ../worktrees/dark-mode/
# I continue working in main workspace

# Review and cleanup after merge
git worktree remove ../worktrees/dark-mode

我的遞迴防護機制會監控代理人的生成行為。我的git安全守護機制會防止代理人強制推送或提交憑證。這些hook會自動執行。我在實作期間不需要監督代理人。

步驟4：審查

代理人完成後會發送通知。我會對照PRD驗收標準審查差異。如果所有標準都通過，我就合併。如果沒有，我會手動修復或以更新的上下文重新啟動代理人。⁴

PRD驅動開發有效的場景

具有清晰資料模型的CRUD端點。 PRD指定了模型、路由和回應格式。代理人生成的樣板程式碼能匹配現有模式。

為現有程式碼新增測試。 「為app/content.py撰寫測試，涵蓋load_post_by_slug的有效slug、無效slug和缺失檔案情境」能產出有用的測試，因為函式已經存在且驗收標準是客觀的。

遵循既有模式的UI元件。 「使用與指南頁面相同的分頁模式，為部落格列表頁面新增分類篩選器」能正常運作，因為代理人可以參考現有模式。

具有定義明確schema的資料庫遷移。 PRD指定了欄位、型別、預設值和限制條件。代理人生成遷移檔案並更新模型。

PRD驅動開發失敗的場景

模糊的需求。 「讓部落格變得更好」不是PRD。代理人會進行變更，但這些變更不會符合您的意圖，因為您的意圖從未被明確指定。

全新的架構決策。 當我需要設計審議系統的共識模型時，沒有任何PRD能捕捉到這個決策。我需要探索選項、評估取捨，並反覆迭代設計。這需要我的審議技能，而非PRD。

效能最佳化。 「讓頁面載入更快」需要分析、測量和反覆調查。代理人無法從PRD中分析您的生產環境流量模式。

安全關鍵程式碼。 用於身份驗證系統的PRD產出的程式碼只處理了正常路徑。身份驗證中的邊界情況（計時攻擊、session固定、非標準流程中的CSRF）需要PRD無法編碼的人類專業知識。

我的PRD範本如何演進

版本1（第1個月）：簡單的使用者故事

As a user, I want to save preferences so I can customize my experience.

問題： 太模糊。代理人對儲存機制、UI位置和範圍做出了合理但錯誤的假設。

版本2（第2個月）：新增檔案位置

## Story: Save preferences
### Files to Modify
- app/routes/settings.py
- app/templates/settings.html

問題： 有所改善，但代理人仍然在未經許可的情況下「改善」相鄰檔案。

版本3（第4個月）：新增限制條件

## Story: Save preferences
### Files to Modify (only these)
- app/routes/settings.py
- app/templates/settings.html
### Constraints
- No new dependencies
- Use existing database models
- Do not modify CSS

問題： 當限制條件與訓練資料中的「最佳實踐」衝突時，代理人有時會忽略這些限制。

版本4（目前版本）：明確排除項目 + 測試期望

目前的範本新增了「Files NOT to Modify」、明確的測試期望和驗收標準核取方塊。這個版本大約85%的情況下能產出可預測的結果。剩餘的15%需要以澄清後的指示進行第二輪處理。⁵

30份PRD的模式庫

在撰寫超過30份PRD之後，模式浮現了：

全新功能的成功率（50%）解釋了為什麼PRD驅動開發是補充我的工作流程，而非取代它。有一半的時間，全新的工作需要PRD無法事先捕捉的反覆迭代。

重點摘要

給獨立開發者： - 從一種定義明確的PRD類型（CRUD、測試）開始，先驗證工作流程再擴展到複雜任務 - 在每份PRD中加入「Files NOT to Modify」；代理人會好心地「改善」您未要求它們碰觸的程式碼 - 使用git worktree隔離代理人的工作；失敗的代理人執行的清理成本應該只是一個指令，而非一場git考古之旅

給工程主管： - PRD品質決定代理人輸出品質；在擴大自主代理人使用規模之前，先投資PRD範本和審查流程 - 追蹤無需修改即可合併的比率來衡量工作流程成熟度；隨著PRD範本的演進，這個比率應該會提升 - 全新架構工作和安全關鍵程式碼不應委派給PRD；將代理人委派保留給定義明確、可重複的任務

參考資料