取得 PRD
總覽
get-prd 將一個模糊的請求在單一連續流程中轉化為一份經認可的 PRD。它合併三個通常分開執行的工作流程：
- 設計樹訪談 — 將每個決策映射為一個樹狀結構，逐層遍歷樹的前沿，並為每個問題提供建議。這是讓訪談收斂而非漫無邊際的機制。
- 意圖萃取 — 捕捉使用者實際想要的東西，而不是他們以為自己應該想要的東西，並在每個步驟附上明確的信心指數。這是阻止 AI 默默填補空白的方法。
- 規格撰寫 — 以結構化的產出物記錄需求，包含邊界、成功標準和批准關卡。這是下游規劃流程會消費的交付物。
合併它們的理由是，拆分會失去脈絡。當訪談是一個技能而規格撰寫是另一個技能時，第二個技能會從零開始：它會重新詢問第一個技能已經問過的問題，或者默默地假設從未給出的答案。根據過時的摘要撰寫的 PRD 比沒有 PRD 更糟，因為它看起來很有權威性。
合併帶來兩個後果，皆為刻意為之：
- 這個技能很長。 它承載了所有三個階段的完整方法論，而不是將任務委派給其他技能。請依序遵循步驟；不要直接跳到範本。
- 這個技能絕不委派訪談。 訪談機制本身就在這個技能內。不要呼叫其他技能來進行提問。
輸出是一份全面的 PRD，儲存於 docs/PRD.md（或 docs/prd/<name>.md），經使用者批准，可準備用於 get-tasks 和 get-design。
對於新使用者或處於早期階段的概念，get-prd 會將點子精煉的探索鏡頭、非功能性約束映射，以及核心實體/資料關係定義直接納入文件中，因此不需要單獨的架構或精煉技能。
何時使用
在以下情況使用此技能：
- 使用者正在開始一個新的應用程式、系統、功能或重大變更，且尚無需求文件存在
- 使用者說「get prd」、「bikin PRD」、「buat PRD」、「mau bikin sistem baru」或「mau develop X」
- 使用者要求被拷問、訪談或針對規格進行壓力測試
- 請求是常規且規格不足的（「幫我做一個儀表板」、「讓它更快」），而你無法說清楚「完成」的定義
- 你即將規劃或構建一個需要超過一天的工作，且沒有書面需求存在
何時不應使用：
- 錯誤修復、打字錯誤修正、重新命名和機械式操作
- 已經存在 PRD 或規格，且使用者只想變更一小部分 — 請直接修改文件
- 純資訊請求（「這是如何運作的？」）
- 使用者明確想要跳過文件並直接開始構建 — 尊重這個要求，但提出風險一次
- 非互動式環境（CI 管道、排程執行、自動化迴圈）。此技能需要一個即時且有反應的使用者。如果請求在非互動式環境中規格不足，請將其標記為阻礙因素，而不是自行猜測。
流程
get-prd 分八個階段執行。每個階段都有一個退出條件。在退出條件未滿足之前，不要前進到下一個階段。
0. 範圍關卡 -> 這是一個能力還是多個能力？
1. 假設種子 -> 我認為他們想要什麼，我的把握度有多高？
2. 建立樹狀結構 -> 存在哪些決策，哪些位於前沿？
3. 回合提問 -> 一次一個回合地詢問前沿
4. 意圖探測 -> 想要 vs. 應該想要
5. 重述 -> 用使用者的話說回來
6. 差距檢查 -> PRD 需要哪些訪談未產生的內容？
7. 撰寫與關卡 -> PRD，然後一個明確的是
給訪談者的通用原則
- 自然語言匹配： 始終使用使用者偏好的語言進行對話。如果使用者用印尼語發起對話（例如 "bikin PRD aplikasi absensi"），則全程親切地使用印尼語進行訪談，同時保留標準的業界技術術語（acceptance criteria, schema, endpoint, payload）。如果他們說英語，則用英語進行。絕不要強迫以另一種語言提問的使用者接受英語訪談。
- 同理心與非威嚇語氣： 使用者經常帶著原始、未成形的想法到來。絕不要盤問他們，或讓他們因缺乏技術術語而感到不足。耐心引導：將他們的業務問題轉化為技術選擇，並且始終附上你建議的答案（
-> Rekomendasi: ...），這樣他們只需做出反應，而不是從頭腦力激盪。 - 針對模糊/早期點子的三個黃金問題： 當使用者提出一個簡短的一句話點子時（例如 "mau bikin SaaS seperti Notion untuk resep masakan"），在討論技術堆疊之前，先將前沿錨定在三個以人為中心的支柱上：
- 目標人物與情境： 誰在使用、在哪裡使用、在什麼情況下使用？
- 北極星使用者旅程： 在這個應用程式中，從開始到結束必須成功的最重要的單一行動流程是什麼？
- MVP 範圍界定： 哪些功能必須在第一天上線，哪些功能刻意推遲到後續階段？
階段 0：範圍關卡
大多數請求描述一個能力。如果是這種情況，用一句話說明然後進入階段 1。這個階段是為了例外情況而存在。
檢測。 當一個單一請求綑綁了多個可獨立測試的能力時，在撰寫任何文件之前先進行分解：
- 請求命名了具有獨立消費者或資料的不同能力（身份、帳務、通知、報表）
- 接受標準可以分成可以獨立交付和驗證的群組
- 其中一個能力可以被刪除或替換，而無需重寫其他能力的需求
一旦檢測到，在任何訪談回合之前提出一個能力映射。 保持小巧且易於審查 — 一個模組表格加上一個構建順序，而不是一個專案計劃：
# 能力映射：[倡議名稱]
| 模組 ID | 職責 | 依賴於 |
|---|---|---|
| identity | 帳戶、工作階段、SSO | - |
| billing | 方案、發票、付款 | identity |
| notifications | 電子郵件和 Webhook 發送 | identity |
| reporting | 使用儀表板 | billing, notifications |
構建順序：identity -> billing, notifications -> reporting
映射規則：
- 穩定的模組 ID。 Kebab-case，只選擇一次，絕不重新命名。下游規劃透過這些 ID 選擇工作。
- 依賴方向，無循環。 箭頭指向一個方向。如果兩個模組互相需要，則它們是一個模組。
- 介面位於邊界。 映射記錄了
billing依賴於identity；兩者之間的合約屬於提供者模組的 PRD。
映射是需要關卡的。 在你為任何單一模組進行訪談之前，要求使用者批准模組邊界、依賴方向和構建順序。弄錯映射的代價很高；審查十行則不然。
然後，對於每個模組，按照構建順序依序執行階段 1-7，每個模組產生自己的 docs/prd/<module-id>.md。不要為多模組的倡議撰寫一個單體式 PRD。
退出條件： 請求是單一能力的（明確說明），或者能力映射已獲批准。
階段 1：假設種子
在問任何問題之前，寫下你目前對請求的理解以及誠實的信心指數。
假設：你想要一個在站會中回答「我們做得怎麼樣？」的方式，而「儀表板」是你想到的慣例。
信心指數：~30% - 缺少：它的對象是誰、這裡的「指標」意味著什麼、以及成功的樣子
規則：
- 假設用一句話。如果你無法用一句話寫出來，代表你還沒有讀懂。
- 信心指數是 0 到 100 的百分比。它強迫誠實：如果你無法預測使用者對你接下來三個問題的反應，那麼這個數字就是錯的。
- 低於 ~70%，在同一行附加一個簡短原因，說明還有什麼尚未解決。這會準確告訴使用者訪談需要釐清什麼。
- 在每個回合後更新假設和信心指數。
退出條件： 一個帶有百分比信心指數的假設已記錄在案。
階段 2：建立設計樹
在問任何問題之前先映射決策空間。每個決策分支到依賴於它的決策。
目標：個人實驗追蹤器
|
+-- 什麼算是一個實驗？ (定義單位)
| |
| +-- 哪些欄位描述一個實驗？ (定義架構範圍)
|
+-- 資料從哪裡來？ (輸入來源)
| |
| +-- 手動輸入或匯入？ (互動模型)
|
+-- 實驗何時「完成」？ (生命週期)
|
+-- 什麼訊號終止它？ (成功定義)
前沿 是那些前提條件已解決的所有決策：你現在可以問的問題，而無需猜測你尚未聽到的答案。
讓這個機制有效的兩個規則：
- 在一個回合中詢問整個前沿。 當多個問題是獨立的時候，不要一次只問一個問題。獨立的問題一起回答更快，而且使用者能看到決策空間的形狀。
- 答案依賴於另一個開放性問題的問題屬於後面的回合。 現在問它會鎖定錯誤的框架。
事實是你的工作，絕不是使用者的。 當一個前沿問題需要來自環境的事實（檔案系統、現有程式碼、函式庫的 API、設定值）時，派遣一個子代理去尋找。不要問使用者任何你自己可以查到的東西。不要讓此問題阻礙整個回合：探索是一個未解決的前提條件，所以只有依賴它的下游問題才需要等待。現在問前沿的其餘部分。決策是使用者的；事實是你的。
退出條件： 樹已映射完畢且第一個前沿已識別。
階段 3：回合提問
詢問當前的前沿。每個問題的格式如下：
**Q1 - <問題標題>**: <問題主體，可能有多個段落，通常會列出候選選項>
-> <你建議的答案，以及產生該答案的理由>
規則：
- 為每個問題編號。
Q1、Q2、... 每個回合重新開始編號。 - 始終附上建議。 使用者對錯誤建議的反應速度比他們從頭開始產生答案更快。這也讓你對一個可能明顯錯誤的假設承擔責任。
- 等待答案，然後再問下一個回合。
- 每個回合後重新計算前沿。 已解決的決策會將前沿向外推，並解鎖依賴於它們的問題。
- 記錄修正。 當使用者推翻一個建議時，同時記錄決策和理由，因為 PRD 的「技術決策」章節會從中提取。
為什麼建議很重要，及其失敗模式：
- 使用者可以在幾秒鐘內對一個錯誤的猜測做出反應，但可能需要幾分鐘才能從無到有產生一個答案。
- 它揭示了你的假設，而這正是訪談的重點。
- 風險在於奉承 — 一個有禮貌的使用者為了討好而同意你的猜測。透過表現出你願意犯錯來減輕此風險，並偶爾推薦一個你預期使用者會反駁的方向。如果每個建議都在第一次就被接受，懷疑存在奉承。
為什麼一次只進行一個回合，而不是一次問完所有問題：
- 第三個問題通常依賴於第一個問題的答案；一次問完所有問題會鎖定錯誤的框架。
- 使用者用於仔細思考的能量是有限的。逐個回合地花費。
- 一次提出十五個問題看起來像是一份調查，而不是訪談，並且會被草率瀏覽。
退出條件： 該回合的問題已回答且前沿已重新計算。
階段 4：意圖探測（想要 vs. 應該想要）
最危險的答案是那些使用者說出深思熟慮的答案聽起來的樣子，而不是他們實際想要什麼。注意以下情況：
- 答案模式匹配最佳實踐用語（「我希望它可擴展」、「乾淨的架構」）但沒有具體內容
- 答案順從慣例（「大多數應用程式使用的方式」、「標準方法」）
- 像「我應該可能......」、「我想我應該......」、「好的工程實踐說......」這樣的短語
- 將流行詞作為目標 — 當「現代」、「可擴展」或「穩健」是答案，而不是具體的結果
當你聽到這些情況時，問：
「如果你不需要向任何人證明這個決定，你實際上會想要什麼？」
這一個問題通常比之前五個問題更有用。每當出現表示專業性的答案時，至少執行一次這個探測。同時記錄陳述的答案和探測到的答案 — PRD 應反映後者。
退出條件： 如果出現任何表示專業性的答案，至少執行了一次探測，且真實答案已記錄在案。
階段 5：重述意圖
當樹幾乎穩定時，寫下你現在認為使用者想要的東西。保持簡潔，使用他們的語言，並以結構化的方式呈現，讓他們可以逐行確認或修正。
這是我現在認為你想要的：
- 成果： <一行>
- 使用者： <一行 - 誰受益>
- 為何現在： <一行 - 什麼改變了>
- 成功： <一行 - 我們如何知道它奏效>
- 限制： <一行 - 主要的限制>
- 不包含： <一行 - 我們明確不做的>
是 / 否 / 完善？
規則：
- 「不包含」是不可協商的。 一半的誤解來自於對不做什麼的沉默分歧。
- 總共五到八行。如果超過，代表訪談尚未完成。
- 儘可能使用使用者的詞彙；他們的詞彙是共同的合約。
退出條件： 一份使用使用者詞彙的具體重述已記錄在案。
停止條件
當以下兩者都為真時，你已完成訪談：
- 你能預測使用者對你接下來會問的三個問題的反應嗎？ 如果可以，表示你們有共識。
- 前沿是否為空？ 如果有任何未曾
…
[其餘部分因翻譯而截斷]