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

output-template

11 min read

User Requirement 輸出模板

寫入 requirement/{feature}/ 的標準格式。 Partner skill 在步驟 5（寫收斂結論）與步驟 6（最終輸出）時組裝此模板。 與 product-module-development-workflow.md Stage 1 的目錄約定一致。

資料夾結構

requirement/{feature}/
├── index.md           ← 索引 + 一句話 Problem statement（本模板主體）
├── raw/               ← 原始素材（圖、錄音、檔案、PDF、Email、Slack 截圖）
└── notes/             ← 整理過的筆記（可選；逐字稿、訪談摘要）

命名規律

  • {feature}/ 與下游 spec/{feature}/{feature}.fp.md、spec/{feature}/{feature}.ooa.md、spec/{feature}/{feature}.pseudo.md 同名成組
  • raw/ 內檔案：{YYYY-MM-DD}-{來源簡稱}-{簡述}.{ext}
    • 例：2026-05-20-客戶會議-換線時間.png
    • 例：2026-05-28-PO訪談-排程量級.md

index.md 模板全文

# {feature 中文名稱} Requirement
 
> 下游：Functional Spec [spec/{feature}/{feature}.fp.md](../../spec/{feature}/{feature}.fp.md) → OOA [spec/.../ooa](../../spec/{feature}/{feature}.ooa.md)（尚未建立）→ 虛擬碼 [spec/.../pseudo](../../spec/{feature}/{feature}.pseudo.md)（尚未建立）
> 性質：{可選——僅當本 feature 是跨 feature 共用模組、或有上下游消費關係時宣告（一句話講定位與消費對象）。純單一 feature 可整行省略。需宣告消費關係時亦可另起 `> 上游消費：…` 行}
> 來源類型：{客戶 / PO / 現場 / 法規}　|　STD / `{CLIENT-CODE}`
> 狀態：紀錄區（living doc）— 需求變更時追加素材並更新未解問題；**不在此寫 Scope / Use Case / AC**
 
---
 
## Problem Statement
 
> 一句話。寫不出來就回去問。
 
{誰、痛在哪、想解什麼——一句話}
 
---
 
## Stakeholders
 
| 類型 | 對象 | 備註 |
|---|---|---|
| 需求提出方 | {客戶名 / PO / 現場單位} | … |
| 受影響方 | {排程員 / 現場 / 業務 ...} | … |
| 決策方 | {誰能拍板 scope — Scope 本身在 Stage 2 才定} | … |
 
---
 
## 素材清單
 
> 每筆對應 `raw/` 一個檔或一條連結。**照實記，不要美化**。
 
| # | 素材 | 來源（誰） | 日期（何時） | 為何提 | 簡述 |
|---|---|---|---|---|---|
| 1 | `raw/2026-05-20-客戶會議-換線時間.png` | 客戶 A 工廠廠長 | 2026-05-20 | 現場痛點 | 白板手繪換線流程 |
| 2 | https://linear.app/.../LP-123 | PO Bob | 2026-05-28 | 工單追蹤 | 換線時間需求 ticket |
| 3 | `raw/2026-05-30-mail-規格初稿.pdf` | 客戶採購 | 2026-05-30 | 法規要求 | ISO 文件節錄 |
 
---
 
## 標籤 / 重複 / 矛盾
 
> AI 主動標、人確認後寫入。
 
**標籤**：#換線 #排程 #{CLIENT-CODE}
 
**狀態標籤**：#待問 #已釐清　（皆含非數字字元才是合法 tag；純數字 `#1` 不可當 tag）
 
**重複**：
- [#1](#素材清單) 與 [#2](#素材清單) 都提到「換線 30 分鐘」——是同一條還是不同情境？（已列入未解問題）
 
**矛盾**：
- [#1](#素材清單) 寫「加型優先」、[#2](#素材清單) 寫「按交期排」——彼此衝突（已列入未解問題）
 
**缺失**：
- 所有素材都沒提失敗排程處理方式（已列入未解問題 [#3](#q3)）
 
---
 
## 未解問題
 
> AI 主動列、不裁決。每條：問題 + 來源 + 類型 + 建議找誰問。
> 每條為編號清單項；逐題錨 `#qN`（依題號）由 build 注入，狀態導航與其他文件以 `[#N](#qN)` 連到各題。
 
> [!NOTE] 狀態導航
> 
> 點編號可跳到該題。
> - ⬜ #待問 — [#1](#q1) [#4](#q4)
> - ✅ #已釐清 — [#2](#q2) [#3](#q3)
 
1. 「大量工單」未定義量級
   - 來源：[#2](#素材清單) PO 訪談
   - 類型：含糊
   - 建議找誰問：客戶現場排程員
   - 狀態：待問 / 帶進 Stage 2 / 已釐清 #待問
 
2. 加型優先 vs 按交期排——兩條素材衝突
   - 來源：[#1](#素材清單)、[#2](#素材清單)
   - 類型：矛盾
   - 建議找誰問：PO + 現場主管，需要一場對齊會
   - 狀態：… #已釐清
 
3. 失敗排程怎麼處理（進未排清單 / 報錯 / 改人工）未提
   - 來源：所有素材都沒提
   - 類型：缺失
   - 建議找誰問：客戶或 PO
   - 狀態：… #已釐清
 
4. {CLIENT-CODE} 是否打算 STD 化？影響下游寫在 core 或 client
   - 來源：[#3](#素材清單) 內部討論
   - 類型：缺失
   - 建議找誰問：PO 或產品負責人
   - 狀態：… #待問
 
---
 
## 需求收斂結論
 
> 把這份紀錄「收斂到什麼」描述清楚，作為 Stage 2 的乾淨 input。
> **鐵則**：每一點都回指素材 [#N](#素材清單) 或已答未解問題 [#N](#qN)；**不寫 scope（做不做什麼）**——那是 Stage 2。指不出來源的那一行就是 scope 決策或腦補，不要寫。
> **全域碼**：每條「已定向」結論是本階段「對外」項目，行首掛全域碼 `§{SHORT}-UR-{N}`（N＝其所解 `^qN` 的數字，去 `q`）。短名 `{SHORT}` 查 [spec-codes.md](../../spec-codes.md)；格式見 workflow §可追溯性「全域編碼」。
 
**核心需求**（比 Problem statement 展開的一段，描述關係人已表達的完整訴求；回指素材）：
 
{把問題與關係人已表達的核心訴求描述完整，例如：…（[#1](#素材清單)、[#2](#素材清單)）}
 
**已定向（關係人已答／已釐清）**：
 
- `§{SHORT}-UR-2` {已釐清的點}（[#2](#q2) / 素材 [#1](#素材清單)）
- `§{SHORT}-UR-6` {已釐清的點}（[#6](#q6)）
 
**仍待 Stage 2 拍板**：
 
- {未答或部分釐清的關鍵點}（[#9](#q9)）
- {未答或部分釐清的關鍵點}（[#12](#q12)）
 
**交棒**：→ `/functional-spec-partner`，以本結論 + 素材清單為 input 定 scope。
 
---
 
## 變更歷史
 
> Living doc 追加段落，不覆寫。
 
- 2026-05-20：初版（素材 #1 入庫）
- 2026-05-28：追加素材 #2，未解問題新增「加型 vs 交期」矛盾
- 2026-05-30：追加素材 #3

連結慣例（GFM，寫檔時遵循）

完整規則見 product-module-development-workflow.md §可追溯性「連結慣例（GFM）」。一律純 GFM（VSCode／GitHub／Quartz 三處渲染一致），不用 [[wikilink]]、^block-id、非 GFM callout。Stage 1 重點：

  • breadcrumb / 跨檔：index.md 在 requirement/{feature}/，兩層深，相對連結用 ../../{stage}/…。
  • 未解問題：每條為編號清單項（不加 ^qN）；逐題錨 #qN（依題號）由 build 注入；狀態導航用 > [!NOTE] callout，編號寫 [#N](#qN)。
  • 指素材（來源 / 重複 / 矛盾裡的 #N）：連到所屬 heading [#N](#素材清單)。
  • 狀態標籤（#待問/#已釐清）為純文字標記、非可點連結；編號導航一律用上面的 [#N](#qN)。

組裝檢查清單（Exit Gate）

寫檔前確認——對齊 product-module-development-workflow.md Stage 1：

  • index.md 存在
  • Problem statement 一句話寫得出來
  • 至少有一份原始素材（raw/）或筆記（notes/）
  • AI 已挑出未解問題清單，人確認可以進下一階段
  • 需求收斂結論已寫，每點回指素材／已答未解問題，無 scope 決策
  • 素材清單每列都有「誰、何時、為何」（缺則標 來源待補）
  • 開頭 breadcrumb 指向下游 Functional Spec
  • 本檔內無 Scope / Use Case / 業務規則 / AC 內容（那是 Stage 2 的事）

與其他文件 / 階段的對應

Requirement 元素下游對應
Problem statementFunctional Spec 的範圍上限
需求收斂結論Stage 2 的乾淨開場 input；下游 Spec 回指「哪個需求造就此 Spec」的上游錨點
素材清單Functional Spec 起 Use Case 的素材庫
未解問題Stage 2 開場討論清單；逐條由 functional-spec-partner 請使用者裁定
標籤 / 重複 / 矛盾提醒 Stage 2 在定 Scope 時要處理
STD / 客戶分類（來源類型）影響下游 Code 寫在 leanplay-core 還是 leanplay-client-xxx
變更歷史跨階段一致性檢視（Consistency Audit）的起點

常見錯用——這些內容不要寫進 index.md

你想寫的該去哪
「這次做 X、不做 Y」（Scope）Stage 2 spec/{feature}/{feature}.fp.md
Use Case（actor + 觸發 + 行為 + 預期結果）Stage 2 spec/{feature}/{feature}.fp.md
業務規則 + 邊界條件Stage 2 spec/{feature}/{feature}.fp.md
驗收條件（AC）/ 測試預期值Stage 2 spec/{feature}/{feature}.fp.md
流程圖 / 狀態機Stage 2 spec/{feature}/{feature}.fp.md（白板照當素材收 OK）
Class diagram / 領域模型Stage 3 spec/{feature}/{feature}.ooa.md
帶 §編號的虛擬碼Stage 4 spec/{feature}/{feature}.pseudo.md

「需求收斂結論」vs「Scope」——這條界線別跨錯

新增的「需求收斂結論」可以寫，但它是對既有紀錄的收斂，不是 scope 決策。判準很簡單：

寫法可不可以為什麼
「需求收斂為：到天、純試算的粗排引擎（#2、素材 #1）」✅ 可收斂已記錄、已答的內容，且回指來源
「節拍點 = 單一工作站-製程（#8）」✅ 可關係人已答，回指得到
「本期做 X、不做 Y」❌ 不可這是 scope 拍板 → Stage 2
「我們建議採方案 2」❌ 不可這是替 Stage 2 選邊 → 列未解問題就好

回指鐵則：結論裡每一行都要指得到素材 #N 或已答未解問題 [#N](#qN)；指不出來源 → 就是 scope 或腦補，不要寫。

紀錄區的價值來自克制——收斂而不越權：可以把「需求收斂到什麼」描述清楚（每點回指來源），但不替 Stage 2 拍板 Scope／Use Case／AC。

Graph View