RCF-011 — 產品起草 SKILL 建立
類型：SKILL
日期：2026-04-26
觸發條件：條件 4 — 新增 .claude/skills/產品起草.md SKILL 文件
相關文件：
C:\Users\USER\Desktop\tzlth-hq\.claude\skills\產品起草.md（新建）C:\Users\USER\Desktop\tzlth-hq\CLAUDE.md（SKILL 表新增一行）C:\Users\USER\Desktop\tzlth-hq\knowledge\CLAUDE.md（文件索引新增 RCF-011）
問題背景
在本次對話（Session 38）中，針對「5個關鍵句型電子書從 v1 改到 v8」的根本原因進行分析。
發現根本原因：不是角色太多、不是流程太複雜，而是沒有事前的「完成標準」。
每一輪修改，Tim 依照當下感受給 Claude 方向，Claude 依照指示修改；但雙方都沒有在一開始對齊「什麼樣才算做完」，導致：
- 改版目標在每輪對話中隱性漂移
- 沒有明確的驗收清單可以核對
- Tim 每次確認後又有新想法，但無從判斷「這是原本計劃內的修改」還是「目標在改變」
現有的兩段式查照協議（作業前查照 → 執行）解決的是「任務分配與規則遵循」的問題，但無法解決「內容產品的完成標準從哪來」的問題。
考慮過的方案
| 方案 | 描述 | 優點 | 缺點 | 採用？ |
|---|---|---|---|---|
| 方案 A：新增角色（編輯、校稿） | 讓 Claude 在「起草模式」後切換到「編輯模式」做自我審查 | 有角色分離感 | Claude 仍是同一個 context，無真正獨立性；root cause 是缺完成標準，不是缺角色 | ❌ 未採用 |
| 方案 B：新增部門（內容審查部） | 建立獨立 CLAUDE.md 負責所有內容品質審查 | 架構上看起來完整 | 同一對話窗口內角色仍是 Claude；overhead 高；不解決根本問題 | ❌ 未採用 |
| 方案 C（最終採用）：Product Brief SKILL | 任何新內容產品開始前，先輸出 7 欄 Brief → Tim 確認 → 才進入起草；Brief 含完成標準 + 不解決的問題 + 改版上限 | 直接解決根本問題（完成標準缺失）；不新增架構複雜度；改版上限機制防止無限漂移 | 需要 Tim 說觸發詞才啟動；自動觸發邏輯仍依賴 Claude 判斷是否為「新產品起草情境」 | ✅ 採用 |
最終決策
採用方案 C：Product Brief SKILL。
核心邏輯：角色分離不能解決「事前沒有對齊完成標準」的問題。一份在起草前就確認的 Brief，讓 Tim 和 Claude 在同一份文件上確認「這個產品做完長什麼樣」，才是讓修改輪數可控的根本解法。
方案 A 和 B 都在解決「誰來審」的問題，但真正的問題是「審什麼標準」。Brief 的完成標準欄位解決了「標準在哪」；改版上限欄位解決了「什麼時候要重新對齊方向」；「已使用輪數由 Tim 手動追蹤」解決了「Claude 跨 Session 無法計數」的技術限制。
影響範圍
| 影響類型 | 具體項目 |
|---|---|
| 新增文件 | .claude/skills/產品起草.md |
| 修改文件 | CLAUDE.md — SKILL 表末尾新增 產品起草 [產品名稱] 行 |
| 修改文件 | knowledge/CLAUDE.md — 文件索引新增 RCF-011 條目 |
| 觸發部門同步 | 無（僅 SKILL 新增，未修改 HARD STOP 規則或收尾規則） |
| 影響的 SKILL | 產品起草（新建） |
驗證方式
下次 Tim 說「產品起草 [名稱]」或「[名稱] 先做 Brief」時，Claude 應：
- 讀取
product/service-catalogue.md確認 A/B 類狀態 - Grep
knowledge/product/確認無舊 Brief - 輸出完整 7 欄 Brief，結尾固定為「Brief 確認後說「開始起草」」
- 等 Tim 說「開始起草」才進入正文起草
若 Claude 跳過 Brief 直接起草 → SKILL 未生效，需檢查觸發詞是否匹配。