rdq

name	rdq
description	使用 RDQ Method（需求探索四象限法）在中大型任務動工前釐清目標、對象、產出、限制、風險與驗收條件，產出一頁需求規格卡並等待確認。使用者說「用 RDQ」「先訪談我」「幫我釐清需求」「我還沒想清楚」「幫我想還缺什麼」時必須使用；面對只有一兩句的全新中大型任務，可先詢問是否使用。不要用於純知識問答、小型修改、執行中追加調整、需求已完整，或使用者要求直接動工的情況。

RDQ Method — ChatGPT App 版

在執行之前，先找出真正的問題。將 RDQ 當作執行型工作流程的前置需求層；先產出需求規格卡，經使用者確認後才執行或交棒。

核心原則：訪談成本必須低於它省下的返工成本。違反時立即收斂，直接產出規格卡。

四象限規則

每個象限使用專屬動詞，不可越界：

象限	內容	動作	不可做
Ⅰ Known Knowns	已明說或環境已知	只擷取、回顯	不提問
Ⅱ Known Unknowns	使用者主動問出的疑問	只解答	不把問題丟回去
Ⅲ Unknown Knowns	使用者知道但沒想到要說	只訪談	不問當場答不出的事
Ⅳ Unknown Unknowns	使用者尚未想到的風險或選項	只陳述建議	不問開放式問題

擬定每一項前先判斷：

• 使用者現在當場答得出來 → 象限Ⅲ，用具體選項詢問。
• 使用者需要先獲得資訊才能判斷 → 象限Ⅳ，主動提供選項、影響與代價。

永遠不要問「你還有什麼沒想到的嗎？」

互動預算

模式	適用情況	訪談	建議	確認	使用者回覆次數
Lite（預設）	單一成品、半天內可完成	1 輪，最多 3 題	併入同一則訊息	1 次	最多 2 次
Full	多產出、跨天、公開、花錢或不可逆	最多 2 輪，每輪最多 4 題	獨立 1 輪	1 次	最多 3 次

• 靜默判定模式，不詢問使用者要 Lite 或 Full。
• Full 第二輪只在第一輪答案開啟新分支時使用。
• 紅燈問題超出預算時，降級成規格卡上的待確認假設。
• 一輪內過半答案為「都可以／你決定」時，不再追加訪談。

ChatGPT 互動相容規則

• 有結構化選項介面時可以使用，但不要依賴特定工具名稱或多選功能。
• 沒有結構化介面時，在同一則訊息列出編號問題與選項，讓使用者一次回覆。
• Lite 第一輪絕對不得超過 3 個象限Ⅲ訪談題；第 4 個紅燈題必須降級為待確認假設，不可擠掉象限Ⅳ菜單。
• Lite 第一則回覆必須先列最多 3 個訪談題，再在同一則訊息列 3–5 項象限Ⅳ建議；建議不是第 4 個訪談題。
• 結構化介面無法同時容納訪談與建議時，改用純文字合併呈現，不得因此增加使用者回覆輪次。
• Lite 模式可用「1A、2C、3B；建議採納②④」這類格式收集答案。
• 每輪最後固定提供「先這樣，直接開始」。
• 使用者說「直接做」「不用問了」「先給我初版」時，立即停止訪談。

判斷問、推測或自行決定

等級	判準	動作
紅燈	答案不同會導致重做、成本、合規或不可逆影響	優先詢問
黃燈	有合理預設值	不詢問，列為待確認假設
綠燈	不影響成果是否可用	自行決定

執行流程

0. 靜默判定

1. 判定 Lite 或 Full。
2. 判定領域：研習、投影片、教材、影片、程式或通用。
3. 任務太小或必要資訊已完整時，告知資訊已足夠並直接執行，不強迫跑訪談。

1. 象限Ⅰ：擷取已知資訊

在權限與目前介面允許的範圍內，讀取：

• 使用者訊息與本對話已確認內容。
• 附件、已連接資料、ChatGPT Project 內容。
• 本機專案的 AGENTS.md、README、設定檔、handoff.md。
• 當前資料夾、既有 RDQ 規格卡。

沒有檔案或專案工具時安靜略過，不要求虛構的路徑或檔案。

回顯：

我目前理解的是：
- 目標：
- 對象：
- 產出：
- 已知限制：

語音輸入中推測還原的人名、日期、數字、檔名與路徑必須醒目標示，方便使用者糾錯。回顯後不停下，直接處理下一階段。

2. 象限Ⅱ：先解答使用者的疑問

找出使用者已經提出的問題，先回答或查證。不要讓使用者帶著未解疑問回答訪談問題。沒有疑問時直接略過。

3. 象限Ⅲ：訪談

讀取 references/question-bank.md 的領域判定與對應題庫。

1. 依紅黃綠燈篩選。
2. 已知資訊不可重問。
3. 選項必須具體到可直接寫入規格。
4. 涵蓋光譜兩端及「不確定／其他」，避免只提供偏好的方向。
5. 答「不知道／都可以」時採合理預設，列入待確認假設，不重複追問。

即使使用者明確要求 RDQ，若目標、對象、產出格式與硬限制都已齊全，可以零題坍縮，直接產出規格卡。

4. 象限Ⅳ：主動提供選項

從題庫、任務脈絡與已知風險中選出 3–5 項真正有用的建議。每項包含：

建議 — 代價或影響

• 不預設採納。
• 全部不採納也能繼續。
• 沒採納的項目記為「本次不納入」，不解讀為永久反對。
• Lite 模式與象限Ⅲ放在同一則訊息中。

5. 產出需求規格卡

讀取 references/spec-template.md，產出一個螢幕可讀完的規格卡。

• 一律先完整貼在對話中。
• 有可寫的本機專案時，可存至 rdq/RDQ-spec-<slug>-<YYYYMMDD>.md。
• 在沒有檔案系統的 ChatGPT 對話中，只交付對話內 Markdown 或可下載檔案。
• 不要求使用者提供目前介面無法使用的本機路徑。
• 初始狀態為 draft。

6. 唯一硬停點：等待確認

在使用者明確確認前，不開始製作成品。提供：

• 照這份開始。
• 有地方要改。
• Full 模式可再問一輪。

請使用者特別檢查待確認假設、本次不納入項目，以及人名、日期、數字、檔名等關鍵詞。

需要修改時只改規格卡並再次確認，不重跑整套訪談。確認後將狀態改為 confirmed。

status 是 RDQ 工作流程契約，不宣稱能在所有產品、模型或工作階段中自動強制執行。只有能讀取該規格卡並遵守 RDQ 契約的後續流程才能依此判定。

7. 執行或交棒

• 目前環境有適合的執行型技能時，將規格卡的「一段式需求規格」交給它。
• 沒有適合技能時，由目前 Agent 直接執行。
• 不假設使用者已安裝任何特定技能。
• 若有 handoff.md 且具寫入權限，記錄已確認的規格卡與下一步。

交棒時附上：

需求已經過 RDQ 訪談與使用者確認。請勿重複詢問已確認事項，但保留產出本身必要的確認關卡。

需求確認與產出確認分層，不重複。

示範模式

只有使用者說「示範 RDQ」或「demo 給觀眾看」時：

• 顯示各象限名稱。
• 空象限也顯示簡短佔位，讓觀眾看見四格都被處理。
• 說明環境掃描實際找到哪些內容。
• 在結尾附上 references/method-positioning.md 的原創性與研究定位聲明。

日常使用不增加這些儀式性內容。

參考檔

• references/question-bank.md：領域判定、象限Ⅲ題庫與象限Ⅳ建議。
• references/spec-template.md：需求規格卡模板。
• references/method-positioning.md：方法來源、研究定位與對外表述。