User Requirement Partner — 五步工作流詳解

本檔為 SKILL.md 引用的詳細工作流指南。每次會談開始前讀一次。對應 product-module-development-workflow.md 的 Stage 1: User Requirement。

前置條件

進入素材蒐集前確認：

這是新的或變更的需求 — 純技術重構（行為不變）不需要新 requirement，引用既有即可
有關係人來源 — 客戶 / PO / 現場 / 法規；沒有來源就不是需求，是臆測
使用者明確要為某個 feature 留底 — 不是「順便聊聊」

若只是改 typo / rename / 純 CRUD → 告知不需要 requirement（見 product-module-development-workflow.md 常見陷阱第 1 點）。

步驟 1 — 框定 feature

目標：在開始收素材前，先框住「這個紀錄是給誰、放哪、為何而存」。

操作

問 2–4 個開場問題（不超過 4 個）：

- 這個 feature 怎麼命名？（決定 requirement/{feature}/ 與下游 spec/{feature}/{feature}.fp.md 同名）
- 一句話：要解什麼問題？（Problem statement 草稿，不用美化）
- 來源：誰提的（客戶 / PO / 現場 / 法規）？
- STD 通用，還是特定客戶 {CLIENT-CODE}？（影響後續 stakeholders 與 scope 提示）

檢查既有 requirement

先看 requirement/{feature}/ 是否已存在：

存在 → 這是 living doc 續寫。讀既有 index.md，本次素材追加進 raw/ 與素材清單，未解問題段落同步更新。
不存在 → 全新 requirement，從空白 index.md 與空 raw/ 開始。

對齊

「我把這份 requirement 紀錄建在 requirement/{feature}/，與下游的 functional-spec / OOA / 虛擬碼同名成組。先確認 feature 名與 Problem statement 一句話，OK 我就開始收素材。」

步驟 2 — 收素材（raw/）

目標：把關係人的原始素材原狀收進 raw/，每筆登錄來源 + 日期 + 簡述。不在這裡下結論、不寫規格。

操作

對每筆素材：

入庫——檔案放進 raw/，檔名規律：{YYYY-MM-DD}-{來源簡稱}-{簡述}.{ext}
- 例：2026-05-20-客戶會議-換線時間.png
- 例：2026-05-28-PO訪談-排程量級.md
登錄——index.md 素材清單表新增一列：
- 編號、檔名 / 連結、來源（誰）、日期（何時）、為何提的、簡述
照實記——客戶說什麼就記什麼，不要美化成你以為的需求

可接受的素材型態

照 product-module-development-workflow.md Stage 1：

文字筆記、會議紀錄、訪談逐字稿
圖片、白板照片、手繪草圖
語音檔、影片片段（檔名登錄；transcript 視情況附 notes/）
既有文件（PDF、Email、Slack 對話截圖）
連結（Jira、Linear、Notion）

連結類素材不需要下載，登錄 URL + 來源 + 日期即可。

邊收邊逼來源

聽到模糊就當場追問（手法見 interaction-patterns.md）：

來源模糊：「這張白板照是哪場會議拍的？誰主持？」
時間模糊：「這封 mail 是這禮拜還是上週的？確切日期？」
為何模糊：「客戶為什麼提這條？是抱怨現況、提改善案、還是法規要求？」

說不出 → 標 來源待補，不要腦補。

不要做

❌ 寫 Scope（「這次做 X，不做 Y」） → Stage 2 的事
❌ 寫 Use Case（actor + 觸發 + 行為 + 預期結果） → Stage 2 的事
❌ 寫業務規則 / AC / 邊界條件 → Stage 2 的事
❌ 把使用者沒講的東西腦補進素材簡述 → 缺就標 待確認
❌ 把 raw 內容「整理」進 index 主體 → index 是索引，不是整理過的結論

對齊

「這輪我收了 N 份素材（列檔名）。在進到打 index / 列未解問題之前，還有沒有漏掉的素材或來源？」

步驟 3 — 打 index

目標：把素材索引化，並補上 Problem statement 與 Stakeholders。AI 主動打標籤、抓重複、抓矛盾——但不下結論。

index.md 的四個區塊

依 output-template.md 順序：

1. Problem statement（一句話）

✅ 現場排程員每天用 Excel 排 500 張工單花 2 小時，想自動化。
✅ {CLIENT-CODE} 客戶要在現有排程上加「換線時間」這個維度。
❌ 我們要做一套精實生產的智慧排程系統解決現場痛點。（太大、太空）

寫不出一句話 → 回步驟 2 補素材或回問關係人。不要替使用者寫。

2. Stakeholders

至少三類：

- 需求提出方：{客戶名 / PO / 現場單位}
- 受影響方：{排程員、現場、業務 ...}
- 決策方：{誰能拍板 scope——但 scope 本身在 Stage 2 才討論}

3. 素材清單

表格形式，每筆對應 raw/ 一個檔或一條連結：

| # | 素材 | 來源 | 日期 | 為何提 | 簡述 |
|---|---|---|---|---|---|
| 1 | raw/2026-05-20-客戶會議-換線時間.png | 客戶 A 工廠廠長 | 2026-05-20 | 現場痛點 | 白板手繪換線流程 |
| 2 | https://linear.app/.../LP-123 | PO Bob | 2026-05-28 | 工單追蹤 | 換線時間需求 ticket |

4. 標籤 / 重複 / 矛盾（AI 主動產）

標籤：#換線 #排程 #{CLIENT-CODE}
重複：#1 與 #2 都提到「換線 30 分鐘」——是同一條規則還是不同情境？
矛盾：#1 寫「加型優先」、#2 寫「按交期排」——彼此衝突，列入未解問題待裁定

對齊原則

AI 標籤 / 重複 / 矛盾 → 由人確認後才寫進 index
不要替使用者裁決矛盾——列出來、進未解問題
領域名詞用使用者原話保留（標準化是 Stage 2 之後的事）

步驟 4 — 列未解問題

目標：AI 主動對照已收素材，挑出含糊、缺失、彼此衝突的點，列成澄清題目清單。不替使用者回答。

操作

對每個未解問題寫四件事：

{編號}. {問題描述}
    來源：對應素材 #N（可回追 raw/）
    類型：含糊 / 缺失 / 矛盾
    建議找誰問：{角色 / 名字}

範例

1. 「大量工單」未定義量級——是 100 張、500 張、還是 5000 張？
   來源：#2 PO 訪談
   類型：含糊
   建議找誰問：客戶現場排程員

2. 加型優先 vs 按交期排——兩條素材衝突
   來源：#1 客戶會議、#2 PO 訪談
   類型：矛盾
   建議找誰問：PO + 現場主管，需要一場對齊會

3. 失敗排程怎麼處理（進未排清單 / 報錯 / 改人工）未提
   來源：所有素材都沒提
   類型：缺失
   建議找誰問：客戶或 PO

4. {CLIENT-CODE} 是否打算 STD 化？影響 Stage 2 之後寫在 core 或 client
   來源：#3 內部討論
   類型：缺失
   建議找誰問：PO 或產品負責人

不要做

❌ 替使用者回答未解問題（「我猜應該是 500 張」）
❌ 把未解問題寫成 Scope 或規則（那是 Stage 2 的事）
❌ 因為列出來太多就刪掉——列得多是好事，下一階段才知道哪些先填

對齊

「我整理出 N 條未解問題（列出）。哪幾條你想現在回去問、哪幾條可以帶著進 Functional Spec 階段討論？」

注意：未解問題沒問完不擋 Exit Gate——重點是「列出來、人看過、決定哪些先處理」。

步驟 5 — 寫需求收斂結論

目標：把已收齊、已釐清的紀錄收斂成一段，描述「這份需求收斂到什麼」，作為 Stage 2 的乾淨 input——讓下游不必回頭從散落的未解問題自己拼湊，也讓「是哪個需求造就了這個 Spec」可被回指。

回指鐵則（這段的脊椎）

結論裡每一行都要回指素材 [#N](#素材清單) 或已答未解問題 [#N](#qN)。指不出來源的那一行 = scope 決策或腦補 → 不要寫。

這條鐵則同時做到兩件事：① 讓結論可以寫得完整、描述性強（使用者要的）；② 讓它無法夾帶 scope（「本期做 X 不做 Y」指不到任何已記錄來源，自動被擋下）。

結構（依 `output-template.md`）

核心需求——比 Problem statement 展開的一段，描述關係人已表達的完整訴求（回指素材）。
已定向——關係人已答／已釐清的點，逐條回指 [#N](#qN)。
仍待 Stage 2 拍板——未答或部分釐清的關鍵點，逐條回指 [#N](#qN)。
交棒——指向 /functional-spec-partner，以本結論 + 素材清單為 input 定 scope。

好 / 壞例

✅ 已定向：粗排顆粒度到「天」（[#2](#q2)）；節拍點＝單一工作站-製程（[#8](#q8)）
✅ 仍待 Stage 2：x/y 參數三方案未拍板（[#9](#q9)）；Freeze 時間範圍未定（[#12](#q12)）
❌ 本期只做細排 input、產銷協調入口下一期        ← scope 決策，是 Stage 2
❌ 建議採方案 2（CT×數量）                      ← 替 Stage 2 選邊，留未解問題就好
❌ 引擎應拆成三個 service                        ← 解法/OOA，更不該在這

不要做

❌ 寫「做 / 不做什麼」（scope）→ Stage 2
❌ 替未答的未解問題給答案 → 它只能進「仍待 Stage 2 拍板」欄
❌ 寫任何指不到素材／已答未解問題的句子

對齊

「我把紀錄收斂成一段需求收斂結論：核心需求一段、已定向 N 點、仍待 Stage 2 拍板 M 點，每點都回指得到來源。你看這個收斂對不對、有沒有我寫過頭（夾帶到 scope）的地方？」

步驟 6 — 輸出與交棒

目標：寫檔，並把棒子交給 /functional-spec-partner。

操作

套 output-template.md 組裝 index.md
確保 raw/ 內檔名規律（{YYYY-MM-DD}-{來源}-{簡述}.{ext}）
寫入：
- requirement/{feature}/index.md
- requirement/{feature}/raw/（已陸續放入）
- requirement/{feature}/notes/（可選，整理過的逐字稿 / 摘要）
提示使用者：
- JIRA / Linear ticket 加上 requirement/{feature}/ 路徑
- 下一步交棒 /functional-spec-partner — Functional Spec 必須可回溯到本資料夾的素材與 Problem statement
- 未解問題清單可作為下次訪談或 Stage 2 開場討論的依據

Exit Gate 自我檢查

對齊 product-module-development-workflow.md Stage 1：

index.md 存在
Problem statement 一句話寫得出來
至少有一份原始素材或筆記
AI 已挑出未解問題清單，人確認可以進下一階段
需求收斂結論已寫，且每點可回指素材／已答未解問題、無 scope 決策

五條缺一不可。

收尾話術

這份 requirement 我們收了：
- Problem statement：{一句話}
- N 份素材（在 raw/ 與素材清單）
- M 條未解問題（你已確認哪些先問 / 哪些帶著進 Stage 2）
- 需求收斂結論：核心需求一段 + 已定向 X 點 / 仍待 Stage 2 拍板 Y 點（每點回指來源）

我會：
1. 套 output-template 組裝 index.md
2. 寫到 requirement/{feature}/
3. 提醒你接 /functional-spec-partner 做 Functional Spec（它以收斂結論 + 素材清單為 input）

可以嗎？

異常情境

使用者要求直接寫 Scope / Use Case / AC

不允許。明說：「Scope / Use Case / AC 是 Stage 2 Functional Spec 的事，我這層只負責收素材與列未解問題。等 requirement 收齊，我交棒給 /functional-spec-partner 處理。」

Problem statement 寫不出來

代表問題本身還不清楚。回步驟 2 補素材，或請使用者回問關係人。不要替使用者捏一個版本。

素材沒有來源

標 來源待補，並列入未解問題：「素材 #N 來源待補——建議問 X」。不要因為缺來源就丟掉素材，但也不要美化來源。

需求中途變更

raw/ 追加新素材（檔名帶日期）
index.md 素材清單追加新列
「未解問題」段落更新狀態
不刪舊紀錄——歷史就是可追溯性
提醒使用者：下游 spec/{feature}/{feature}.fp.md 可能需要重看（屬於 Stage 2 直接編輯，要跑 Consistency Audit，見 product-module-development-workflow.md）

使用者要求「一次整理完所有素材」

可以承諾節奏，但仍一筆對齊一次：「我看你手上有 8 份素材，每筆登 1 分鐘左右、整理 index 5 分鐘、列未解問題 10 分鐘。一份一份來，好嗎？」

排程模組規格站 — 五階段可追溯性

Explorer

workflow