給 AI 讀的 PRD 長什麼樣？一份可直接複製的 YAML 範本

Q: 這份 PRD 要放在專案的哪裡？

放在專案根目錄，並且納入版控。建議在檔頭保留 version 與 last_updated 兩個欄位，每次調整需求就更新。實務上更重要的是：改需求時改 PRD、再讓 AI 依 PRD 重新生成，而不是直接叫 AI 改程式碼——否則文件與程式碼會很快脫節。

結論先講

如果你要讓 AI 幫你寫程式，PRD 不該是給人讀的散文，而該是給機器讀的結構化規格。差別集中在三件事：

用鍵值結構取代段落敘述 —— 讓模型讀到明確欄位，而不是需要推論的文章。
把「不能做什麼」寫得跟「要做什麼」一樣清楚 —— 限制條件是 AI 最常漏掉的一塊。
把輸出格式定義成 schema，而不是用文字描述 —— 「回傳一個包含標題和內文的物件」與一份真正的欄位定義，得到的穩定度差很多。

以下是拆解與一份可以直接複製的範本。

為什麼傳統 PRD 餵給 AI 會失敗

傳統 PRD 是寫給人看的。人有常識、會追問、看到矛盾會停下來確認。AI 這三件事都不會做——它會用最合理的猜測把空白填滿，然後繼續往下寫。

失效通常發生在三個地方：

失效點	傳統 PRD 的寫法	實際發生的事
輸出格式	「回傳生成好的文案內容」	每次回傳的結構都不一樣，前端解析一直爆
限制條件	寫在文件末尾的「注意事項」	模型當成參考建議，不當成硬性規則
品質門檻	完全沒寫	功能全對，但首字要等五秒才出來

這三件事有個共通點：它們都不是「功能」，所以在傳統 PRD 裡被放到附註或省略了。 而對 AI 來說，沒寫進結構裡的東西等同不存在。

AI-native PRD 的六個必要區塊

#	區塊	回答什麼問題	漏掉的後果
1	策略基礎	為誰做、解決什麼、憑什麼比現有方案好	AI 做出「功能正確但沒人要用」的東西
2	系統上下文	在什麼產業、受什麼法規限制、用什麼技術棧	生出違反產業規範或與現有系統不相容的實作
3	功能需求	畫面上有什麼、使用者怎麼操作、資料怎麼流動	互動流程被自由發揮
4	資料結構	每一筆輸出長什麼樣、哪些欄位必填	回傳結構不穩定，解析錯誤率高
5	非功能性需求	多快、多穩、錯誤率上限多少	體感很慢，但「規格上沒說不行」
6	提示詞策略	模型扮演什麼角色、有哪些硬性禁止	觸碰法規紅線或輸出風格飄移

第 4、5、6 這三塊是 AI-native PRD 與傳統 PRD 差最多的地方，也是實務上最常被省略的三塊。

完整範本（可直接複製）

以下用一個「AI 廣告文案生成器」當作已填寫的範例。把值換掉即可用在自己的專案。

version: 1.0.0
last_updated: 2026-07-30
status: Approved
project_name: AdCopy Inspiration Library
type: AI-Native Web Application

# ==========================================
# 1. 策略基礎 (Strategic Foundation)
# ==========================================
strategy:
  goal: >
    打造一個即時 AI 廣告文案生成器，協助使用者快速獲取高轉化率的廣告靈感，
    並透過模擬數據輔助決策，最終建立個人的文案資產庫。
  target_audience:
    - 電商小編
    - 專業廣告投放手
    - 獨立開發者
  value_proposition:
    - AI 即時生成：針對特定場景現場產出，非靜態資料庫。
    - 數據輔助：每條文案附帶 AI 預測的模擬點擊率。
    - 細緻分類：支援行業、情感、平台、長度等多維度控制。

# ==========================================
# 2. 系統架構與上下文 (System Context)
# ==========================================
context:
  domain:
    industry: Digital Marketing / Ad Tech
    compliance:
      - 嚴格禁止誇大不實
      - 禁止醫療療效宣稱
      - 符合各大社群與搜尋廣告平台規範
  technology_stack:
    frontend: React + Tailwind CSS
    backend_service: Firebase (Auth, Firestore)
    ai_engine:
      provider: <填入選定的模型供應商與版本>
      role: Real-time Content Generator
      response_format: JSON Object (Strict Mode)

# ==========================================
# 3. 功能需求 (Functional Requirements)
# ==========================================
features:
  ui_layout:
    search_bar:
      type: Input Field
      purpose: 使用者輸入產品名稱或核心關鍵字，作為提示詞的主體。
    filters:
      taxonomy:
        industry: [美妝, 3C, 服飾, 食品, 金融, 其他]
        emotion: [幽默, 痛點, 溫馨, 專業, 緊迫]
        platform: [Facebook, Instagram, Google Ads]
        length: [短文案, 中長文案, 長故事]
    display_area:
      style: Grid Card Layout (Responsive)
      elements_per_card:
        - Headline
        - Body Text
        - Tags
        - Predicted Metrics
        - Actions: [Copy to Clipboard, Save to Library]
  interaction_flow:
    trigger: User clicks "Generate"
    process:
      - Frontend collects inputs (keyword + filters).
      - Construct system prompt with constraints.
      - Call LLM API with streaming enabled.
      - Parse JSON stream to UI.
    output: Render 3 distinct ad cards.

# ==========================================
# 4. 數據結構 (Data Schema)
# ==========================================
data_schema:
  # 這一節是給模型遵循的輸出契約，不是給人看的說明
  ad_card_object:
    type: object
    properties:
      id:
        type: string (uuid)
      headline:
        type: string
        description: 吸睛標題
      body:
        type: string
        description: 廣告主文案，需符合平台風格
      tags:
        type: array
        items: string
      predicted_ctr:
        type: float
        range: [1.5, 5.0]
        description: 基於文案吸引力模擬的點擊率數值
      rationale:
        type: string
        description: (選填) 解釋這段文案為何有效
    required: [headline, body, predicted_ctr]

# ==========================================
# 5. 非功能性需求 (NFRs)
# ==========================================
nfrs:
  performance:
    time_to_first_token: 低於 1.5 秒
    generation_batch_size: 每次請求 3 張卡片
    streaming: true (必要，直接影響體感)
  quality_assurance:
    json_parse_error_rate: 低於 0.1%（必須使用 JSON Mode 或 Function Calling）
    tag_consistency: 高於 90%（標記為幽默的文案必須真的幽默）
    hallucination_safety: 嚴格過濾不合規宣稱
  metrics_logic:
    ctr_simulation: 依文案品質分數加權的隨機浮點數，範圍限制在 1.5% 至 5.0% 之間。

# ==========================================
# 6. 提示詞工程指引 (Prompt Engineering Guide)
# ==========================================
prompt_strategy:
  role_definition: >
    你是一位擁有 10 年經驗的資深廣告文案撰寫專家與數據分析師。
  constraints:
    - 輸出必須是純 JSON 陣列，包含 3 個物件。
    - 嚴格遵守使用者選擇的平台風格。
    - 安全過濾：若輸入包含違禁品或醫療宣稱，回傳指定錯誤碼而非生成文案。

三個最常見的失敗模式

一、把限制條件寫成「注意事項」

錯誤寫法：在文件最後加一段「注意：文案不可誇大不實」。

為什麼失敗：模型會把它讀成建議，不是硬性規則。當使用者輸入「三天瘦十公斤」時，它仍然會生成。

正確做法：放進 prompt_strategy.constraints，並明確寫出違反時的行為——回傳錯誤碼，而不是「盡量避免」。

二、用文字描述輸出格式

錯誤寫法：「請回傳一個包含標題、內文與預估點擊率的物件。」

為什麼失敗：欄位名稱、型別、必填與否全部靠模型猜。同一句話跑十次可能得到 title / headline / head 三種鍵名。

正確做法：寫成第 4 節那樣的 schema，明確標出 required。並在實作端啟用 JSON Mode 或 Function Calling，把約束從「請求」變成「機制」。

三、完全沒寫非功能性需求

錯誤寫法：整份 PRD 只有功能。

為什麼失敗：AI 生成的預設實作是「一次算完再回傳」。功能驗收會全過，但使用者要盯著空白畫面等五秒。

正確做法：把 streaming: true 和首字延遲門檻寫成明文需求。這一行的效益，通常比多寫三個功能還高。

怎麼驗收這份 PRD 有沒有寫好

一個簡單的測試：把 PRD 交給一個沒參與討論的人（或另一個 AI），請他只依文件說出「這個產品做完長什麼樣」。

如果他問出以下任何一個問題，代表對應區塊還沒寫夠：

「這個要回傳什麼格式？」 → 第 4 節不足
「這個有什麼不能做的？」 → 第 6 節不足
「多快算夠快？」 → 第 5 節不足
「這是做給誰用的？」 → 第 1 節不足

常見問題

AI-native PRD 一定要用 YAML 嗎？用 Markdown 可以嗎？

Markdown 可以，但 YAML 更好。關鍵不是副檔名，而是「鍵值結構」。YAML 強迫你把每個需求放進具名欄位，模型讀到的是明確的鍵值對而非需要推論的段落，漏讀的機率明顯較低。若團隊已習慣 Markdown，至少要用標題階層與列表把欄位結構化，不要寫成連續散文。

PRD 要寫多細？寫太細不是限制了 AI 的發揮空間嗎？

要區分「什麼該定死」與「什麼該留白」。輸出格式、限制條件、驗收標準必須定死，因為那是不能猜的；實作方式、演算法選擇、程式碼結構可以留白，那才是 AI 該發揮的地方。實務上多數失敗案例是「該定死的沒定死」，而不是「限制太多」。

非功能性需求（NFR）真的需要寫進 PRD 嗎？

需要，而且這是 AI-native PRD 與傳統 PRD 差最多的一節。AI 生成的程式碼預設不會考慮首字延遲、串流、錯誤率這些指標。若不明文寫出數值門檻，模型不會主動處理，你會拿到一個功能都對但體感很慢的版本。

同一份 PRD 可以餵給不同的 AI 編程工具嗎？

可以，這正是採用結構化格式的好處之一。YAML PRD 不綁定特定工具或模型，同一份文件可以交給不同的 AI 編程助理，也可以在更換模型時直接沿用。要注意的是把模型與供應商本身寫成 PRD 裡的一個欄位，而不是散落在敘述中，換的時候才好維護。

這份 PRD 要放在專案的哪裡？

放在專案根目錄，並且納入版控。建議在檔頭保留 version 與 last_updated 兩個欄位，每次調整需求就更新。實務上更重要的是：改需求時改 PRD、再讓 AI 依 PRD 重新生成，而不是直接叫 AI 改程式碼——否則文件與程式碼會很快脫節。