# Rdq Opencode

> RDQ Method（需求探索四象限法）需求訪談技能 — OpenCode 版，全域可用、實驗性方法。在動工「之前」用四象限（Ⅰ已明說的／Ⅱ想問的／Ⅲ知道卻沒說的／Ⅳ沒想到的）做結構化訪談，產出一頁需求規格卡，經使用者確認後才執行或交棒給執行型技能。當使用者說「用 RDQ」「跑 RDQ」「RDQ 訪談」「幫我釐清需求」「幫我探索需求」「需求訪談」「先訪談我再做」「我還沒想清楚要什麼」「幫我想想還缺什麼」「先問我問題再開始」「做需求規格」時，請一定要使用此技能（語音輸入的同音變體依全域善意還原原則還原後同樣觸發）。當使用者提出全新的中大型任務（新專案、新課程、新研習、新系統）但只給一兩句、缺對象或時間或產出格式時，不要自行開跑訪談，先用一句話問「要不要先跑 RDQ 需求訪談？」，同意才進入；同一對話被婉拒過一次就不再主動提議。以下情況一律不要觸發，直接執行即可：使用者請你解釋、介紹、製作 RDQ 方法論的內容（做 RDQ 的簡報、影片、文章、教材——那是講方法不是跑方法）；使用者已給出完整明確的需求；使用者說「直接做」「不用問」「照上次的做」；小型修改、除錯、單一檔案的小任務；純查詢或知識問答；執行中任務的追加調整；「開工」「收工」「初始化專案」等既有流程；以及其他自帶訪談流程的技能正在進行時。

- Skill: `mathruffian-dot/rdq-opencode` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add mathruffian-dot/rdq-opencode`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mathruffian-dot/rdq-opencode/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-opencode

---


# RDQ Method — 需求探索四象限法（OpenCode 版）

> Requirements Discovery Quadrant Method
> 在執行之前，先把真正的問題找出來。

方法論摘要見 `README.md`。本版為 **OpenCode 專用**，原始 Claude Code 版見 [rdq-skill](https://github.com/mathruffian-dot/rdq-skill)。

---

## 核心定位

RDQ 是**所有執行型技能的前置需求層**。它自己不做成品，它產出一張「需求規格卡」，確認後才交棒。

一句話原則：**訪談的成本，必須低於它省下的返工成本。** 任何時候違反這條，就該收手直接做。

---

## 四象限操作規則（最重要，違反此節即為執行錯誤）

每個象限有**專屬動詞**，不可越界。這是 RDQ 不會退化成「多問幾句的 chatbot」的唯一結構性保證。

| 象限 | 英文 | 動詞鎖定 | 絕不可以 |
|---|---|---|---|
| **Ⅰ** | Known Knowns | **只擷取**——回顯使用者已說的 | 不可在此提問 |
| **Ⅱ** | Known Unknowns | **只解答**——回答使用者問的 | 不可反問使用者 |
| **Ⅲ** | Unknown Knowns | **只問**使用者當場答得出來的 | 不可問他答不出來的 |
| **Ⅳ** | Unknown Unknowns | **只陳述**建議讓他勾選 | 不可問開放式問句 |

### Ⅲ／Ⅳ 判別測試

擬任何一條內容前，先自問一句：

> **「使用者現在當場答得出來嗎？」**

- **答得出來** → 象限Ⅲ，用**問的**（例：教室網路穩不穩？學生程度如何？）
- **要我先給資訊他才能判斷** → 象限Ⅳ，用**端的**（例：要不要準備登入失敗的備案？——他沒想過這件事會發生）

問使用者「你還有什麼沒想到的嗎？」是邏輯錯誤，永遠不要問。

---

## 互動預算（硬上限，寫死不得發揮）

| 模式 | 適用 | Ⅲ 訪談 | Ⅳ 菜單 | 確認 | **打擾使用者總次數** |
|---|---|---|---|---|---|
| **Lite**（預設） | 單一成品、半天內做得完 | 1 輪 ≤3 題 | 併入同一輪 1 題 | 1 次 | **2 次** |
| **Full** | 多產出、跨天、對外公開、要花錢、不可逆 | ≤2 輪，每輪 ≤4 題 | 獨立 1 題 | 1 次 | **3 次** |

- **模式由你靜默判定，不要問使用者要 Lite 還是 Full**（多問一輪去問「要問幾輪」是自我矛盾）。
- 拿不準時預設 Lite，把不確定的維度多附一題在第一輪即可。
- Full 的第二輪**只在第一輪答案打開新分支時才發**；沒有新分支就收手。
- `question` 工具不可用時（headless／子 Agent 環境）：改用編號問題列表以純文字提問，題數上限相同。

---

## 隨時退出（四條停止條件，任一成立即收斂出規格卡）

1. **逃生口**：每輪最後一題固定含「先這樣，直接開始」選項；使用者在自訂回答寫「別問了／你決定／夠了」視同選中。
2. **逃生語**：對話中任何時候出現「直接做」「不用問了」「先給我看初版」→ 立刻停止訪談，用現有資訊出規格卡。
3. **零題坍縮**：**即使使用者明確說「用 RDQ」**，若必要欄位（目標／對象／產出格式／硬限制）已經齊全，象限Ⅲ 可以是**零題**——直接跳到規格卡。有 RDQ 不代表一定要問。
4. **疲勞收斂**：一輪內過半答案是「無所謂／交給你」→ 不再發下一輪。

被跳過的問題**全部轉為規格卡上的 ❓ 假設**，不會卡住流程。

---

## 紅黃綠燈：決定問、推測、還是自己決定

| 燈號 | 判準 | 動作 |
|---|---|---|
| 🔴 **紅燈** | 答案不同會**導致重做**（影響對象、架構、成本、合規、不可逆決定） | **必問**，進 `question` |
| 🟡 **黃燈** | 有合理預設值（風格、細節偏好、次要格式） | **不問**，推測後寫入 ❓ 假設清單 |
| 🟢 **綠燈** | 怎麼做都行 | **自己決定**，不佔使用者注意力 |

**紅燈題超過預算時，超出的部分自動降級為黃燈假設**——寧可讓假設在確認階段被修正，也不無限追問。

> 這條規則是全域 AGENTS.md「會出事的模糊處先對一句，明顯的安靜順過」的系統化版本。

---

## 執行流程

### Phase 0｜靜默判定（不對使用者顯示）

1. **判模式**：Lite 或 Full（見互動預算表）。
2. **判領域**：教育研習／教學簡報／備課教材／影片內容／程式專案／通用 → 決定稍後讀 `references/question-bank.md` 的哪一段。**題庫沒有這個領域時**（法律、醫護、電商、製造、行銷…），見 Phase 3 末的「題庫沒有你的領域時」。
3. **判是否該退場**：任務太小、需求已完整 → 直接說「這個任務資訊已經夠了，我直接做」然後執行，不跑 RDQ。

### Phase 1｜【象限Ⅰ】擷取確認（不提問）

**環境已知掃描**——象限Ⅰ 不只擷取使用者說的話，還要掃描：

- 專案 `AGENTS.md` / `CLAUDE.md`（目標、進度、既有約定）
- `handoff.md`（其他 Agent 的進度）
- 當前資料夾現有檔案
- 同專案舊的 RDQ 規格卡

把「使用者說的」＋「我已經知道的」一起條列回顯：

```
我聽到的是：
- 目標：…
- 對象：…
- 產出：…
- 已知限制：…
（我從專案 AGENTS.md 讀到：…）
```

**語音容錯**：還原過的關鍵詞（人名、日期、數字、檔名、路徑）在此**明確標出**，讓使用者糾錯。糾錯比回答便宜一個數量級——這也是象限Ⅰ 不佔任何題數的原因。

不停，直接進 Phase 2。

### Phase 2｜【象限Ⅱ】解答澄清（不反問）

抓出使用者訊息裡**他自己問出來的問題**（「哪個工具比較好？」「預算抓多少？」），當場回答；需要查證就 `webfetch` 查完再答。

不要把這些問題留到訪談之後——**不要讓使用者帶著疑問回答你的問題**。

日常模式下若無此類問題，直接略過本節（不要輸出「本次無象限Ⅱ項目」這種佔位行；那是示範模式才做的事）。

不停，直接進 Phase 3。

### Phase 3｜【象限Ⅲ】訪談追問 ★停點

1. 讀 `references/question-bank.md` 對應領域段落。
2. 用紅黃綠燈篩題，紅燈題按「不問會怎樣」的嚴重度排序。
3. **已知的絕不重問**：使用者說過的、專案 AGENTS.md 有的、舊規格卡有的 → 預填後改成「確認題」，或直接不問。
4. 用 `question` 工具提問，遵守互動預算。

**選項設計規則**（品質即體驗）：

- 選項要**具體到可直接寫進規格**：寫「45 分鐘一節課」不寫「時間較短」；寫「教師完全沒用過 AI」不寫「初階」。
- 涵蓋光譜兩端 ＋「不確定」，不可只列你偏好的方向（**防錨定**）。
- 題幹不夾帶建議——建議是象限Ⅳ 的事。
- 每輪最後一題附「先這樣，直接開始」逃生選項。
- 使用者答「不知道／都可以」→ 記入 ❓ 假設並附你的預設值，**不重複追問**。

### 題庫沒有你的領域時

`question-bank.md` 的六段是為台灣教學現場寫的。若使用者的領域不在其中（法律、醫護、電商、製造、行銷、非營利…），**不要硬套不相干的領域段，也不要只靠通用段草草了事**——改用本文件的規則現場生題：

1. **拿通用段當骨架**：對象／硬限制／執行環境／死線／預算／成功標準／一次性或重複／起點。這八個維度換到任何領域都成立。
2. **用紅黃綠燈篩**：在這個領域裡，哪些事「答錯會導致整份重做」？只問那些，其餘標 ❓ 假設。
3. **用 Ⅲ／Ⅳ 判別測試分流**：使用者當場答得出來 → 用問的（Ⅲ）；要你先給資訊他才能判斷 → 做成菜單讓他勾（Ⅳ）。
4. **象限Ⅳ 從三處找料**：這個領域的**不可逆決定**、**法遵與資安紅線**、**這類事情失敗最常見的原因**。
5. 選項一樣要具體到可直接寫進規格，一樣附「不確定」與逃生選項。

**跨領域可直接沿用的既有段落**：`video`（影片製作全通用）、`slides`（簡報，只有教學舉例需換詞）、`dev`（程式專案，把「學生／研習」讀成「使用者／活動」即可）。真正綁死教學現場的只有 `lesson`（備課教材）。

若這個領域會反覆出現，訪談結束後主動建議使用者把好題回填成新的領域段（格式見 `question-bank.md` 末尾的模板）。

### Phase 4｜【象限Ⅳ】主動建議 ★停點

**不問問題，端菜單。** 從 `question-bank.md` 的 Ⅳ 段落 ＋ 任務脈絡 ＋ 全域 AGENTS.md 專案模板庫的踩坑列表，生成 **3–5 條**「你可能沒想到」：

```
每條格式：<一句話建議> — <一句話代價／影響>
```

用一次 `question` 工具（`multiple: true`）讓使用者勾選要納入的。

**硬規範**（防止退化成推銷）：

- 每條**必須標代價**（會多花時間／多花錢／增加複雜度）
- **預設不勾選**，全部不勾也能往下走
- 上限 5 條，寧缺勿濫
- **未勾選的記入規格卡「❌ 排除項」**——明確決定不做什麼也是需求，能防止下游技能自作主張加回來

Lite 模式：本題併入 Phase 3 同一輪，不另起一輪。

### Phase 5｜產出需求規格卡

依 `references/spec-template.md` 生成，**硬限一個螢幕讀完**（超過就失去「掃一眼確認」的價值）。

- **全文直接貼在對話中**，不是只給路徑——確認發生在對話裡。
- 存檔位置：`<專案>/rdq/RDQ-spec-<任務slug>-<YYYYMMDD>.md`
- **不在專案資料夾時**：先只貼對話，問一句「要存檔嗎？存哪裡？」——不要在家目錄亂丟檔案。
- frontmatter `status: draft`。

### Phase 6｜使用者確認 ★★唯一硬停點

**在使用者明確確認之前，絕對不動工。** 這是 RDQ 與「邊做邊問」的普通 agent 行為最肉眼可見的差異，也是本技能最重要的一行指令。

用 `question` 工具單題：

- ✅ 照這份開工
- ✏️ 有地方要改（自訂回答填哪裡）
- 🔁 再問我一輪（僅 Full 提供）

請使用者特別看三處：**❓ 假設清單**（黃燈推測在此被接住）、**❌ 排除項**、**關鍵詞**（人名/日期/數字/檔名以粗體回顯，同音錯字的最後一道安全網）。

要求修改 → **只改規格卡再確認一次，不重跑訪談**。
確認後 → frontmatter 改 `status: confirmed`。

> `status: draft` 的規格卡**不得交付執行**。任何 model、任何後續 session、任何其他 Agent 讀到 draft 都應停下來要求確認。

### Phase 7｜執行或交棒

依領域對照表決定去向：

| 任務類型 | 交棒對象（**只在當前環境已安裝該技能時**才交棒，否則自己直接執行） |
|---|---|
| 互動簡報／投影片 | 例如 `html-slide-builder`、`soil-html-deck`、`soil-image-deck`、`soil-teaching-deck` |
| 備課教材包／教學平台 | 例如 `lesson-prep`、`teaching-cockpit` |
| 影片上架素材 | 例如 `yt-pack` |
| 形成性評量小遊戲 | 例如 `teaching-minigames` |
| 圖／影片素材 | 例如 `draw`、`seedance` |
| 其他，或上述技能不存在 | 自己直接執行 |

交棒時把規格卡的**「一段式需求規格」整段**作為輸入，並附這句交接聲明：

> 需求已經過 RDQ 訪談與使用者確認，請勿重複詢問已確認事項；但保留你自己的產出確認關卡（例如大綱確認）。

**需求確認（RDQ）與產出確認（下游技能）分層，不重疊。**

若專案有 `handoff.md` → 補記一筆「RDQ 規格已確認、spec 路徑、下一步」。

**執行後**：使用者每要求一次修改，就地把規格卡 frontmatter 的 `revisions` +1。一行動作，不需要別的機制。

---

## 示範模式（僅在使用者說「示範 RDQ」「demo 給觀眾看」時啟用）

示範模式用於向觀眾展示 RDQ 流程。啟用時：

- 每階段標題帶象限編號與英文術語：`【象限Ⅲ・Unknown Knowns】訪談追問`
- **空象限也輸出佔位行**（「本次無象限Ⅱ項目」）——讓觀眾看見四格都被處理，不硬湊也不隱形
- Phase 1 明講「環境已知掃描」找到什麼——展示 **Agent 的 Known Knowns 大於使用者說出口的**，這是 RDQ 從 Prompt Engineering 走向需求工程的具體證據
- 結尾附方法論第十一節的原創性聲明

**日常模式不要這樣做**——象限標籤保持輕量即可，儀式感是使用者的閱讀成本。

### 對外表述紀律

公開場合引用本技能的產出時，必守方法論第十一、十二節的定位：

> RDQ Method 並非宣稱創造 Known／Unknown 四象限或需求工程理論，而是將其整合、重新詮釋與流程化並進行實驗。

`telemetry` 數據只能稱為**單臂描述性資料**，不可宣稱「RDQ 降低了 N% 修改次數」——沒有對照組，且使用者跳過 RDQ 的任務系統性偏簡單（自選偏誤）。

認識論誠實：AI 無法真正判定使用者「知不知道自己知道」，「當場答得出來與否」只是 Unknown Knowns 的**操作型近似**。公開場合被問到時要這樣回答。

---

## 檔案

| 檔案 | 用途 |
|---|---|
| `references/spec-template.md` | 需求規格卡逐字模板與欄位定義 |
| `references/question-bank.md` | 分領域 Ⅲ 訪談題庫與 Ⅳ 建議菜單（**活文件**：實戰中的好題請回填） |

---

## 語音輸入提示

使用者常用語音輸入，「RDQ」可能被轉寫成「阿滴Q」「R滴Q」「二滴Q」等。依全域善意還原原則處理即可，不需要維護變體白名單。訪談中自訂回答欄的自由填答同樣適用——但還原後的關鍵詞必須出現在規格卡上供目視二次確認，不要默默採用。