mathruffian-dot RDQ Method — 需求探索四象限法（OpenCode 版）
Requirements Discovery Quadrant Method 在執行之前，先把真正的問題找出來。
方法論摘要見 README.md。本版為 OpenCode 專用，原始 Claude Code 版見 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 環境）：改用編號問題列表以純文字提問，題數上限相同。
隨時退出（四條停止條件，任一成立即收斂出規格卡）
- 逃生口：每輪最後一題固定含「先這樣，直接開始」選項；使用者在自訂回答寫「別問了／你決定／夠了」視同選中。
- 逃生語：對話中任何時候出現「直接做」「不用問了」「先給我看初版」→ 立刻停止訪談，用現有資訊出規格卡。
- 零題坍縮：即使使用者明確說「用 RDQ」，若必要欄位（目標／對象／產出格式／硬限制）已經齊全，象限Ⅲ 可以是零題——直接跳到規格卡。有 RDQ 不代表一定要問。
- 疲勞收斂：一輪內過半答案是「無所謂／交給你」→ 不再發下一輪。
被跳過的問題全部轉為規格卡上的 ❓ 假設，不會卡住流程。
紅黃綠燈：決定問、推測、還是自己決定
| 燈號 | 判準 | 動作 |
|---|---|---|
| 🔴 紅燈 | 答案不同會導致重做（影響對象、架構、成本、合規、不可逆決定） | 必問，進 question |
| 🟡 黃燈 | 有合理預設值（風格、細節偏好、次要格式） | 不問，推測後寫入 ❓ 假設清單 |
| 🟢 綠燈 | 怎麼做都行 | 自己決定，不佔使用者注意力 |
紅燈題超過預算時，超出的部分自動降級為黃燈假設——寧可讓假設在確認階段被修正，也不無限追問。
這條規則是全域 AGENTS.md「會出事的模糊處先對一句，明顯的安靜順過」的系統化版本。
執行流程
Phase 0｜靜默判定（不對使用者顯示）
- 判模式：Lite 或 Full（見互動預算表）。
- 判領域：教育研習／教學簡報／備課教材／影片內容／程式專案／通用 → 決定稍後讀
references/question-bank.md的哪一段。題庫沒有這個領域時（法律、醫護、電商、製造、行銷…），見 Phase 3 末的「題庫沒有你的領域時」。 - 判是否該退場：任務太小、需求已完整 → 直接說「這個任務資訊已經夠了，我直接做」然後執行，不跑 RDQ。
Phase 1｜【象限Ⅰ】擷取確認（不提問）
環境已知掃描——象限Ⅰ 不只擷取使用者說的話，還要掃描：
- 專案
AGENTS.md/CLAUDE.md（目標、進度、既有約定） handoff.md（其他 Agent 的進度）- 當前資料夾現有檔案
- 同專案舊的 RDQ 規格卡
把「使用者說的」＋「我已經知道的」一起條列回顯：
我聽到的是：
- 目標：…
- 對象：…
- 產出：…
- 已知限制：…
（我從專案 AGENTS.md 讀到：…）
語音容錯：還原過的關鍵詞（人名、日期、數字、檔名、路徑）在此明確標出，讓使用者糾錯。糾錯比回答便宜一個數量級——這也是象限Ⅰ 不佔任何題數的原因。
不停，直接進 Phase 2。
Phase 2｜【象限Ⅱ】解答澄清（不反問）
抓出使用者訊息裡他自己問出來的問題（「哪個工具比較好？」「預算抓多少？」），當場回答；需要查證就 webfetch 查完再答。
不要把這些問題留到訪談之後——不要讓使用者帶著疑問回答你的問題。
日常模式下若無此類問題，直接略過本節（不要輸出「本次無象限Ⅱ項目」這種佔位行；那是示範模式才做的事）。
不停，直接進 Phase 3。
Phase 3｜【象限Ⅲ】訪談追問 ★停點
- 讀
references/question-bank.md對應領域段落。 - 用紅黃綠燈篩題，紅燈題按「不問會怎樣」的嚴重度排序。
- 已知的絕不重問：使用者說過的、專案 AGENTS.md 有的、舊規格卡有的 → 預填後改成「確認題」，或直接不問。
- 用
question工具提問，遵守互動預算。
選項設計規則（品質即體驗）：
- 選項要具體到可直接寫進規格：寫「45 分鐘一節課」不寫「時間較短」；寫「教師完全沒用過 AI」不寫「初階」。
- 涵蓋光譜兩端 ＋「不確定」，不可只列你偏好的方向（防錨定）。
- 題幹不夾帶建議——建議是象限Ⅳ 的事。
- 每輪最後一題附「先這樣，直接開始」逃生選項。
- 使用者答「不知道／都可以」→ 記入 ❓ 假設並附你的預設值，不重複追問。
題庫沒有你的領域時
question-bank.md 的六段是為台灣教學現場寫的。若使用者的領域不在其中（法律、醫護、電商、製造、行銷、非營利…），不要硬套不相干的領域段，也不要只靠通用段草草了事——改用本文件的規則現場生題：
- 拿通用段當骨架：對象／硬限制／執行環境／死線／預算／成功標準／一次性或重複／起點。這八個維度換到任何領域都成立。
- 用紅黃綠燈篩：在這個領域裡，哪些事「答錯會導致整份重做」？只問那些，其餘標 ❓ 假設。
- 用 Ⅲ／Ⅳ 判別測試分流：使用者當場答得出來 → 用問的（Ⅲ）；要你先給資訊他才能判斷 → 做成菜單讓他勾（Ⅳ）。
- 象限Ⅳ 從三處找料：這個領域的不可逆決定、法遵與資安紅線、這類事情失敗最常見的原因。
- 選項一樣要具體到可直接寫進規格，一樣附「不確定」與逃生選項。
跨領域可直接沿用的既有段落：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」等。依全域善意還原原則處理即可，不需要維護變體白名單。訪談中自訂回答欄的自由填答同樣適用——但還原後的關鍵詞必須出現在規格卡上供目視二次確認，不要默默採用。