# Rdq

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

- Skill: `mathruffian-dot/rdq` (Agent Skill, multi-file: 8 files)
- Install (CLI): `npx skillmds@latest add mathruffian-dot/rdq`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mathruffian-dot/rdq/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: mathruffian-dot (https://skillmd.com/u/mathruffian-dot)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mathruffian-dot/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 規格卡。

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

回顯：

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

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

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

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

### 3. 象限Ⅲ：訪談

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

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

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

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

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

```text
建議 — 代價或影響
```

- 不預設採納。
- 全部不採納也能繼續。
- 沒採納的項目記為「本次不納入」，不解讀為永久反對。
- 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`：方法來源、研究定位與對外表述。