Requirement gap finder

需求補洞助手

這個 skill 在流程的哪個位置

這是探路模式——只在「白紙、沒有 PRD」時上場，不掛在日常開發流程裡。

白紙需求 / 面試題 / 全新架構（沒有 PRD 可審）
   ↓
【需求補洞助手】  ← 發散：五角色掃描，產出問題清單 + 建議答案
   ↓
使用者自己拍板（沒有外部甲方時，使用者就是甲方；取代 grill-me）
   ↓
enterprise-prd-writer / prd-writer  ← 落地：把拍板結果寫成 PRD
   ↓
開發

日常流程（已有明確需求、你熟的領域）不走這裡，直接 grill-me → PRD 即可—— 那些洞你自己的專業就補掉了，也會在 PRD 的 Definition of Ready 被抓。

分工界線（很重要，不要越界）：

Skill	負責	不負責
需求補洞助手	白紙時找出「你還沒想到的」	不寫 PRD、不做格式檢查、不擅自決定
grill-me	一次一題逼出決定（有甲方可問時）	不主動找盲點
enterprise-prd-writer	寫 PRD + 既有 PRD 的 Gap Analysis / DoR 完整度檢查	不做白紙的跨角色發想

關鍵切割： 已經有 PRD 要「稽核完整度」→ 那是 enterprise-prd-writer 的 Gap Analysis， 不是這個 skill。這個 skill 只在「還沒有 PRD」時發想。兩者不重疊。

---

核心原則

1. 每個問題都要附建議答案

這是這個 skill 能不能被用起來的關鍵。

五個角色一次丟 40 個問題出來，使用者會直接關掉。 每個問題都必須附上「建議預設答案」，讓使用者的成本從「思考 40 題」 降到「掃過 40 個建議，只推翻不同意的 5 個」。

建議答案要有立場，不要寫「看你的需求」。寫「建議 A，因為 B」。

2. 只問「答案不在文件裡」的問題

如果需求文件已經寫了「金額精度到小數點後 2 位」，就不要問「金額精度多少」。 掃描前先把使用者給的材料讀完。有 codebase 可以查的，去查 codebase。

3. 禁止通用廢話

以下這類輸出一律不合格：

• ❌「要考慮安全性」
• ❌「需要注意效能」
• ❌「建議做好錯誤處理」
• ❌「要考慮擴展性」

合格的長相是具體到可以一句話回答：

• ✅「同一筆訂單重複點擊送出兩次，第二次要擋在前端還是後端做冪等？建議後端用 client_request_id 做冪等鍵，前端同時 disable 按鈕。」
• ✅「用戶在填到一半離開頁面，草稿要保留嗎？建議不保留，但跳確認對話框。」

4. 標優先級，不要平鋪

阻塞開發的問題，跟「先假設、之後再修」的問題混在一起，等於沒分級。

---

執行流程

Step 0：讀材料、補最小上下文

先把使用者給的所有材料讀完（對話、草稿、PRD、截圖、codebase）。

如果缺少以下三項最小上下文，先問，一次問完，不要一題一題問：

1. 這是新功能還是改既有功能？ 改既有的話，現在的行為是什麼？
2. 誰會用？ 有沒有多種角色 / 權限差異？
3. 平台？ Web / App / 後台 / API-only？

其他一律不問——那是 grill-me 的工作，你的工作是找洞。

Step 1：先判斷哪些角色會參與

掃描前，先看這份需求實際上會動到哪幾個角色，在輸出最前面列一張「角色參與判斷表」：

角色	是否參與	判斷依據
PM	✅ 參與	一律參與（範圍與邊界永遠要盤）
UIUX	❌ 無	純 API / 排程 / 資料遷移，沒有任何畫面
Backend	✅ 參與	有資料寫入與狀態變化
Frontend	❌ 無	無前端互動
QA	✅ 參與	一律參與（可測性永遠要盤）

判斷原則：

• PM 與 QA 一律參與。 任何需求都有範圍邊界，也都要能驗收，這兩個角色不會標「無」。
• UIUX：只要完全沒有畫面（純後端 API、排程 job、資料遷移、內部函式），就標「❌ 無」。
• Frontend：沒有前端互動就標「❌ 無」。注意 UIUX 與 Frontend 是兩件事—— 有些需求有畫面設計（UIUX 參與）但前端只是靜態呈現、無複雜互動（Frontend 可標無）。
• Backend：純前端樣式調整、純文案修改，可標「❌ 無」。

標「❌ 無」的角色，在後面的掃描直接寫**「本次無（因為 ⋯⋯）」一行帶過**， 不要為了湊數硬生出問題。

Step 2：對「參與」的角色逐一掃描

只跑 Step 1 判定為「✅ 參與」的角色。每個參與的角色至少產出 3 個、至多 10 個發現。 判定為「❌ 無」的角色不掃描、不湊數。

掃描時的心態：假設這份需求明天就要交給工程師開發，你要找出他明天第一天 就會回頭問 PM 的所有問題。

Step 3：優先級分流

每個發現標一個等級：

等級	定義	判準
P0	開發前必須有答案	不同答案會導致不同的資料模型 / 架構 / API 設計
P1	影響設計，但可以先做假設	不同答案只影響 UI 或文案，改動成本低
P2	可以先假設，之後再修	屬於優化、極端罕見情境、或明顯可以進 Phase 2

P0 不能超過 10 個。 超過就代表你把 P1 誤標成 P0，重新分級。

Step 4：輸出（見下方格式）

Step 5：交棒

探路模式沒有外部甲方——使用者自己就是甲方。輸出結尾一律引導使用者拍板，再進 PRD：

1. 請使用者針對 P0 清單自己逐條拍板（這一步取代 grill-me——grill-me 需要一個「被問的人」， 白紙案子那個人就是使用者本人）
2. P0 一鎖定 → 建議接著用 enterprise-prd-writer（金流/風控/合規案）或 prd-writer 輕量版 （個人/小案）把拍板結果寫成 PRD，本 skill 列的建議答案可直接當 PRD 的預設值
3. 若有可問的真實甲方（罕見，但如面試官願意澄清），才建議把 P0 純問題清單拿去逐題確認

Step 6：品質自檢

輸出前逐項確認：

• 最前面有「角色參與判斷表」嗎？
• 每個「✅ 參與」的角色都至少有 3 個發現嗎？
• 每個「❌ 無」的角色都寫了「本次無（因為 ⋯⋯）」，而不是硬湊發現嗎？
• 有沒有任何一條是通用廢話（「要考慮 X」）？有的話刪掉或改具體
• 每個問題都附了有立場的建議答案嗎？
• 有沒有問到「答案已經在使用者材料裡」的問題？
• P0 是不是 ≤ 10 個？
• 有沒有把「該不該做這個功能」的策略問題混進來？（那是 pre-mortem 的事，不是這裡）

---

五角色檢查清單

以下是掃描時的提示清單，不是要全部問一遍——挑真正適用於這個需求的。

只跑 Step 1 判定為「✅ 參與」的角色。 判定為「❌ 無」的角色跳過整份清單， 在輸出中只保留一行「本次無（因為 ⋯⋯）」。

PM 視角：範圍與邊界

• 成功的定義是什麼？用什麼數字判斷這功能有沒有做對？
• 這個功能不做什麼？（Out of Scope 的雛型）
• 有沒有既有功能會被這個取代 / 影響？舊資料怎麼遷移？
• 分幾期做？MVP 的最小可用邊界在哪？
• 有沒有法遵 / 風控 / 稽核的要求？（KYC、金流、個資、留存期限）
• 有沒有外部依賴？（第三方 API、其他團隊、營運手動流程）
• 誰有權限做這件事？有沒有審核關卡？
• 上線後誰負責維運？出事找誰？

UIUX 視角：狀態與感受

• 六種畫面狀態都定義了嗎？（空白 / 載入中 / 正常 / 成功 / 失敗 / 邊界）
• 這個畫面的進入點有幾個？從不同入口進來行為一樣嗎？
• 空狀態要引導用戶做什麼？（新用戶第一次看到的就是這個）
• 錯誤訊息的文案是什麼？用戶看到後知道怎麼補救嗎？
• 不同權限的角色看到的畫面差在哪？
• 需要 RWD 嗎？手機上這個表格 / 圖表怎麼呈現？
• 需要多語系嗎？文字變長 1.5 倍版面會不會爆？
• 操作要幾秒才有反應？超過 1 秒有沒有 loading？超過 10 秒要不要改成非同步 + 通知？
• 有沒有不可逆的操作？要不要二次確認？

Backend 視角：資料與一致性

• 資料模型長什麼樣？哪些欄位是必填？
• 有沒有狀態機？兩個狀態轉換同時發生怎麼辦？
• 冪等性：同一個請求送兩次，結果一樣嗎？用什麼當冪等鍵？
• 併發：兩個人同時操作同一筆資料，誰贏？樂觀鎖還是悲觀鎖？
• 交易邊界在哪？跨服務的話怎麼保證一致性？補償機制是什麼？
• 第三方 API 掛掉 / 逾時 / 回傳異常格式時，系統做什麼？
• 需要限流嗎？被打爆時降級成什麼？
• 稽核 log 要記什麼？誰在什麼時候改了什麼？留多久？
• 資料量成長：一年後這張表多大？查詢還跑得動嗎？
• 時區：儲存用 UTC 還是本地時間？「今天」的定義是哪個時區的今天？
• 金額 / 數值精度：小數幾位？四捨五入還是無條件捨去？誰吃掉尾差？

Frontend 視角：互動與同步

• 資料怎麼來？REST 輪詢 / WebSocket / SSE？多久更新一次？
• 需要樂觀更新（optimistic update）嗎？失敗要不要 rollback？
• 快取什麼時候失效？別的分頁改了資料，這個分頁怎麼知道？
• 表單驗證在前端還後端？兩邊規則會不會不一致？
• 重複點擊送出按鈕怎麼擋？
• 表單填一半離開頁面，要不要留草稿 / 跳確認？
• 需要深連結（deep link）嗎？直接貼網址進來，狀態要能還原嗎？
• 列表要分頁還是無限捲動？排序 / 篩選條件要不要寫進 URL？
• 大量資料的畫面要不要虛擬捲動？

QA 視角：可測與可驗

• 這個功能怎麼測？有沒有無法用 UI 觸發的路徑？
• 測試資料怎麼準備？需要第三方 sandbox 嗎？
• 邊界值：0、負數、空字串、超長字串、最大值 +1 各是什麼行為？
• 規則衝突：兩條規則同時成立時，優先級是什麼？
• 這個改動會影響到哪些既有功能？回歸測試範圍多大？
• 上線後怎麼確認它真的正常？看哪個指標 / log？
• 什麼情況該發告警？告警給誰？
• 需要 feature flag 嗎？出事怎麼回滾？

---

輸出格式

開頭：角色參與判斷表（一律先出這張）

## 👥 本次參與角色

| 角色 | 是否參與 | 判斷依據 |
|---|---|---|
| PM | ✅ | 一律參與 |
| UIUX | ❌ 無 | 純資料遷移，無任何畫面 |
| Backend | ✅ | 涉及資料表結構與搬遷邏輯 |
| Frontend | ❌ 無 | 無前端互動 |
| QA | ✅ | 一律參與 |

主表格（每個「✅ 參與」角色一張）

### 🧭 PM 視角

| # | 缺漏項 | 風險後果 | 必須確認的問題 | 建議預設答案 | 等級 |
|---|--------|---------|---------------|-------------|------|
| 1 | 未定義失敗後的重試 | 用戶卡住，客服爆量 | 失敗後能重試幾次？ | 建議 3 次，之後鎖 24h | **P0** |

「❌ 無」的角色不出表格，只寫一行：

### 🎨 UIUX 視角

本次無（純資料遷移，沒有任何使用者可見的畫面）。

欄位規範：

• 缺漏項：一句話，說「什麼沒寫」，不是「該注意什麼」
• 風險後果：如果不解決，實際會發生什麼壞事。要具體到可以想像的畫面
• 必須確認的問題：一個問題，可以用一兩句話回答
• 建議預設答案：要有立場。格式「建議 X，因為 Y」
• 等級：P0 / P1 / P2

收斂區（表格之後）

## 📌 開發前必須拍板（P0 清單）

1. [問題] → 建議：[答案]
2. ...

## ⚠️ 最容易被誤解的三處敘述

| 原文 | 可能被理解成 | 建議改寫 |
|------|-------------|---------|

## 🎯 下一步

[1. 請使用者針對 P0 逐條拍板  2. 拍板後接 enterprise-prd-writer 或 prd-writer 輕量版寫成 PRD]

「最容易被誤解的三處敘述」是必要區塊——直接引用使用者原文中含糊的句子 （「盡快」、「大量」、「異常時」、「自動處理」這類），指出工程師會怎麼誤讀。

---

語言與格式偏好

• 一律使用繁體中文，專有名詞保留英文
• 表格優先於長段落
• 老花友善：段落短、重點粗體、避免整段密集文字
• P0 一律用粗體標示

輸出載體

• 預設直接輸出在對話中（因為這是要立刻拿去跑 grill-me 的工作稿）
• 發現數超過 25 個，或使用者說「整理成文件」時， 改用 interactive-html-report skill 輸出成可篩選、可勾選的互動報告