TimLai666 服務創新案例研究 Skill
核心原則（必讀）
這份 skill 來自一個真實的 Doji 案例研究過程，以下是這個過程中提煉出的最重要原則：
原則一：所有內容必須有來源，不得自行捏造
每一個事實、數字、引言都必須來自可查核的網路資料。每次寫入報告前先查詢，查到了才寫，查不到明確說明「無公開數據」。這是整個 skill 最重要的單一規則。
原則二：分析鏈必須環環相扣
PESTEL → 五力 → SWOT → STP → BMC → Persona → 服務藍圖 → CJM 是一條邏輯鏈，每一步的輸出是下一步的輸入。STP 的市場區隔必須引用 PESTEL 的高優先分因素；定位必須從選定的主要策略推導；Persona 必須從 STP 的目標客群萃取；服務藍圖和 CJM 必須以 Persona 為主角。
原則三：PESTEL 必須有優先分，且下游分析只用高分因素
每個 PESTEL 因素都要打分（重要性 × 影響程度 × 時效性），只有優先分 ≥ 48 的因素才進入 SWOT 和 STP。低分因素明確說明不納入。
原則四：CJM 必須反映真實摩擦，不是品牌視角的理想化版本
情緒分數要基於真實用戶反饋（App Store 評論、媒體評測等），不是假設一切順利。服務藍圖的缺口診斷要對應 SWOT 的劣勢。
原則五：報告區段順序不能亂
正確順序：案例名稱 → 公司背景 → 創辦人背景 → 推出背景 → 推出時間 → 推薦原因 → 應用情境 → 創新類型/模式 → 生態系地圖 → PESTEL → 五力 → SWOT → 主要策略 → STP → BMC → Persona → 服務藍圖 → CJM → 創造效果 → 相關展示 → 目前成效 → 背後啟發 → 參考資料（最後）
執行流程
階段 0：啟動前確認
讀取 references/01-research-protocol.md，確認：
- 研究目標的正式名稱與官方網址
- 是否有同名的其他公司（需要明確區分，如 doji.com vs doji.co.uk）
- 使用者是否有提供課堂格式要求（若有，記錄下來對照）
階段 1：基礎資料研究（查詢 → 寫入）
按以下順序查詢，每個查詢結果立即標記來源：
1-A 公司基本資料
- 公司全名、成立年份、總部地點
- 創辦人姓名、職稱、前雇主背景（LinkedIn、TechCrunch、公司官網）
- 目前員工數、融資輪次與金額（Crunchbase、PitchBook、Tracxn）
1-B 投資背景
- 每個投資方的詳細介紹（不只是名稱）
- 投資金額、輪次、時間點
- 「如何被發現」的故事（是否有口碑傳播、介紹人、Demo Day）
- 注意：必須查證每個投資方是否真的投資了這家公司，不能假設
1-C 推出時間線
- 找出所有重要節點（成立、stealth、beta、正式上線、融資宣布、功能更新、獲獎）
- 每個節點都要標來源與確切日期
- 若不同來源有衝突，以最可靠來源（TechCrunch、官方聲明）為準並說明
1-D 推薦原因與口碑
- 找真實的外部引言（投資人、媒體、用戶、KOL）
- 每則引言標明說話者身份、出處、日期
- 不只找正面回饋，也找批評性評論（App Store、競品評測）
1-E 應用情境
- 創辦人自述的使用場景（LinkedIn、訪談）
- 實際用戶的使用方式（媒體報導、社群發文）
- B2B vs B2C 的場景區分
階段 2：產業生態系地圖
在 PESTEL 之前完成。讀取 references/02-analysis-chain.md 的生態系地圖規格。
必須涵蓋的層次：
- 資金層（所有投資方，含輪次與金額）
- 技術來源層（創辦人前雇主、技術合作方）
- 核心（公司本身）
- 品牌合作方（內容供給、策展品牌、過往合作）
- 電商導購目的地
- 通路層（App Store、擴充套件、社群媒體）
- 終端用戶層
- 直接競爭者（同類新創，附融資金額）
- 間接競爭者（大廠自建）
- 監管環境（相關法規機構）
輸出格式：Mermaid 程式碼（可嵌入 Markdown，可在支援 Mermaid 的渲染器中顯示）
品質標準：每個節點都要有來源依據。不確定的關係用虛線箭頭，確認的用實線箭頭。
階段 3：PESTEL 分析
讀取 references/02-analysis-chain.md 的 PESTEL 規格，並參照 pestel-analysis skill。
評分系統（三軸評分）：
- 重要性（1-5）：對公司的戰略重要程度
- 影響程度（1-5）：實際衝擊的深度
- 時效性（1-3）：近期至長期
- 優先分 = 重要性 × 影響程度 × 時效性
有效因素門檻：優先分 ≥ 12（一般來說 ≥ 48 才進入 SWOT，但至少 ≥ 12 才列為有效因素）
每個有效因素必須包含：
- 因素編號（如 T-01、L-01）
- 詳細描述（含具體數字與事件）
- 來源依據（直接引用原始來源）
- 影響方向（機會傾向 / 威脅傾向 / 中性）
- 各維度評分與優先分
輸出移交包：PESTEL 結束時輸出「PESTEL → SWOT 移交包」，列出機會池和威脅池（依優先分排序）。
階段 4：五力分析
讀取 references/02-analysis-chain.md 的五力規格。
五力分析必須：
- 列出所有有名字的競爭者（直接 + 間接），不能只說「競爭強度高」
- 替代品威脅要分析「為何這些替代品不能完全取代本產品」的理由
- 買方/供應商議價能力要說明對商業模式的具體影響
- 每個力量給出判斷等級（低 / 中低 / 中 / 中高 / 高）
階段 5：SWOT 分析
強制規則：
- S、W、O、T 各剛好 3 項（S1-S3、W1-W3、O1-O3、T1-T3）
- O 和 T 必須對應 PESTEL 移交包的因素，並標 PESTEL 編號與優先分
- 每項都要有來源
- S/W 來自公司自身（有來源的事實），O/T 來自 PESTEL 高分因素
階段 6：SWOT 碰撞策略
強制規則：
- 生成 SO × 2、WO × 2、ST × 2、WT × 2，共 8 個策略
- 每個策略標示組合代號（如 [S2×T1]）
- 從 8 個策略中選出 1 個主要策略
- 主要策略的選擇必須有有依據的理由：
- 引用 PESTEL 優先分（選最高分威脅/機會）
- 引用創辦人或媒體的真實話語
- 說明「為何這個策略比其他策略更強」
階段 7：STP 分析（三軌整合）
強制規則：
- 只引用 PESTEL 優先分 ≥ 48 的因素，低分因素明確說明不納入
- S（區隔）：PESTEL 高分因素 + 五力結構共同決定區隔維度
- T（目標）：做三軌聯合篩選矩陣（PESTEL + 五力 + SWOT 三欄並列）
- P（定位）：只從主要策略推導，不能同時用多個沒有選中的策略
市場區隔的維度設計邏輯：
- 每個維度都要有 PESTEL 因素作為依據
- 維度必須能清楚切割出不同的用戶群
- 交叉出的區隔（如 AX/AY/BX/BY）要有明確的排除或選擇依據
階段 8：商業模式圖（BMC）
讀取 references/02-analysis-chain.md 的 BMC 規格，並參照 business-model-architect skill。
震央選擇（Epicenter Selection）——必須從分析推導：
| 震央類型 | 選擇條件 |
|---|---|
| 資源導向 | 核心優勢 = 稀缺資源/能力；買方切換成本低（不適合顧客導向）；商業化路徑未確立 |
| 顧客導向 | 有清楚的未被滿足需求；切換成本高；顧客關係是護城河 |
| 財務導向 | 收益模式清晰；成本結構是競爭優勢；規模效益明確 |
| 產品導向 | 產品本身是差異化核心；技術/IP 保護強 |
震央選擇表格必須包含：每個依據的來源（SWOT/五力/STP）、指向結論。
九格設計順序（從震央格向外推）：關鍵資源 → 價值主張 → 目標客群 → 通路 → 顧客關係 → 關鍵活動 → 關鍵合作夥伴 → 收益流 → 成本結構
暫緩要素：若商業化路徑未確立或財務資料未公開，相關格子標 ⏸ 並說明暫緩原因。
階段 9：顧客 Persona
強制規則：每個屬性都必須有來源依據
Persona 不是虛構人物，而是從有來源事實萃取出的複合樣本：
- 職業/年齡/地點：從實際用戶報導或beta用戶描述推導
- 品味偏好：從公司的策展品牌或合作對象推導
- 行為特徵：從具名用戶的真實使用方式引用
- 痛點與動力：從SWOT的劣勢和機會，加上用戶反饋
格式：製作屬性表格，每列 = 一個屬性、內容描述、來源依據
階段 10：服務藍圖
讀取 references/02-analysis-chain.md 的服務藍圖規格，並參照 ecosystem-map-and-blueprint skill。
必須呈現的六層（縱軸）：
- 實體支援（顧客能看到的實體物件）
- 用戶行動
- — 互動線 —
- 前台（科技層 + 真人層）
- — 可視線 —
- 後台
- — 內部互動線 —
- 支援系統
橫軸（流程階段）：根據服務特性設計 4-6 個階段（如：發現→建立→使用→分享→購買）
流程缺口診斷（⚡）：
- 每個缺口標嚴重程度（最高 / 高 / 中）
- 每個缺口對應 SWOT 的哪個劣勢項目
- 每個缺口有具體的改善建議方向
階段 11：顧客旅程地圖（CJM）
讀取 references/02-analysis-chain.md 的 CJM 規格，並參照 customer-journey-mapper skill。
強制規則：
- 必須以 Persona 為主角（不是抽象用戶）
- 情緒分數必須基於真實用戶反饋，不是假設
- 旅程中必須包含真實的摩擦點，不是品牌視角的理想化版本
- Aha Moment 若有前提條件必須說明，不能無條件標注
必要欄位：動機、行動、情緒曲線（附分數）、接觸點、感受/關鍵時刻、科技服務、行銷方法、目標
情緒分數標準（1-5 分）：
- 1：極度負面（放棄使用）
- 2：負面或明顯不滿
- 3：中性（可接受但未被打動）
- 4：正面（有好感）
- 5：強烈正面（Aha Moment）
情緒分數明細表：每個階段列出加分原因與減分原因，每個原因都要有來源。
階段 12：創造效果 / 解決問題
三層分析（不能只寫正面效果）：
- 宣稱解決的問題（創辦人/品牌自述）
- 目前實際已解決的程度（✅/⚠️/❌，有來源）
- 尚未解決的缺口（技術 / 商業 / 體驗層面）
階段 13：目前成效 / 獲獎情況 / 外部討論
強制規則：只呈現可查核的數字
- 若公司未公開用戶數、MAU、營收，明確說明「無可查核的公開來源」
- 媒體報導做成時間軸表格（時間、媒體、事件）
- 關鍵聲音正反並列，批評性評論不能省略
階段 14：背後代表的啟發與意義
強制規則：每個啟發都必須從上方的具體分析推導
- 標明依據來源（如「PESTEL T-01 優先分 75」、「SWOT ST1 策略」、「CJM 情緒曲線」）
- 不是泛泛的創業感言，而是從這個案例的具體分析結論提煉出的普遍規律
品質管制規則
完成每個區段後，在進入下一區段前執行自我檢查：
每個區段通用檢查：
- 所有事實都有來源標注（在當下或區段末尾）
- 沒有任何「可能」、「應該」、「大概」等推測性語言（除非明確說明是推測）
- 沒有捏造數字（特別是用戶數、成長率、市佔率）
分析鏈一致性檢查：
- STP 的 S 只用了優先分 ≥ 48 的 PESTEL 因素
- STP 的 T 有三軌聯合篩選（PESTEL + 五力 + SWOT）
- STP 的 P 只從主要策略推導，沒有混入其他策略
- BMC 的震央選擇有從 SWOT + 五力推導的表格依據
- Persona 的每個屬性都有來源
- CJM 的情緒分數有真實用戶反饋支撐
- 背後啟發的每一點都追溯到具體的分析依據
報告順序檢查（最終輸出前）：
- 生態系地圖在 PESTEL 之前
- PESTEL 在五力之前
- 商業模式圖在 Persona 之前
- Persona 在服務藍圖之前
- 服務藍圖在 CJM 之前
- 創造效果/解決問題在 CJM 之後
- 參考資料是最後一個區段
- 參考資料是獨立的
## 參考資料區段，有清楚編號，不是散落在各區段底部
常見錯誤（來自 Doji 案例的教訓）
錯誤一：STP 的定位用了多個策略而非主要策略 症狀：定位區段同時提到 ST1、ST2、WT2 等多個策略，顯示沒有從主要策略聚焦推導。 修正：定位只從選定的主要策略推導。若主要策略是 ST1，定位就只從 S2 和 T1 的張力推導出差異化位置。
錯誤二：Persona 屬性沒有來源，是主觀創造的 症狀：Persona 的職業、年齡、地點等屬性是「感覺合理」的設定，沒有連接到真實數據。 修正：每個屬性都要追溯到有來源的事實（beta 用戶報導、創辦人自述、實際用戶案例）。
錯誤三：CJM 是理想化的品牌視角，沒有真實摩擦 症狀：情緒曲線一路上升，Aha Moment 無條件出現，沒有真實的挫折點。 修正：查詢 App Store 評論、競品評測、媒體真實測試記錄，把真實摩擦寫進 CJM。
錯誤四：Avatar 是否真的還原身材 vs 只是換臉 這個問題在 Doji 案例中被明確指出：diffusion model 生成的 avatar 體型偏瘦偏高，不是精確身材還原。每次分析「虛擬試衣」類服務時，都要主動查詢「是否真的按用戶體型建模，還是視覺生成」。
錯誤五：參考資料散落各處或有重複編號
症狀：編號重複（如兩個「10」）、沒有統一的 ## 參考資料 區段、部分來源只在區段底部的 > 來源： 標注中出現。
修正：最終輸出前，把所有來源整合成一個帶 ## 參考資料 標題的獨立區段，有序編號，分類整理，放在報告最末尾。
錯誤六：PESTEL 低分因素進入了 STP 症狀：STP 的市場區隔引用了優先分只有 18 或 24 的 PESTEL 因素，與高分因素並列，沒有說明篩選邏輯。 修正：在 S（區隔）開頭明確說明「只引用優先分 ≥ 48 的因素」，並說明哪些因素因優先分不足而不納入。
錯誤七：生態系地圖只畫了幾個大廠，競爭者不完整 症狀：競爭層只有 Google、Amazon 等大廠，遺漏了直接競爭的新創公司和有名字有融資金額的競爭者。 修正：用 Tracxn、Crunchbase、ProductHunt 查詢同類競爭者清單，把有融資記錄的全部畫進去。
使用其他 Skill 的時機
本 skill 在以下區段會呼叫其他 skill：
| 區段 | 呼叫的 skill | 原因 |
|---|---|---|
| PESTEL 分析 | pestel-analysis |
有完整的評分框架和移交包格式 |
| 商業模式圖 | business-model-architect |
有震央選擇和九格設計的完整方法論 |
| 服務藍圖 | ecosystem-map-and-blueprint |
有六層結構和缺口診斷的格式規範 |
| 顧客旅程地圖 | customer-journey-mapper |
有情緒分數和階段設計的規格 |
使用方式：在執行對應區段前，讀取該 skill 的 SKILL.md 確認格式要求，然後依照本 skill 的品質標準執行。
報告輸出規格
- 格式：Markdown（.md）
- 路徑：
/mnt/user-data/outputs/[品牌名]_report.md - 更新模式：迭代更新，每個階段完成後立即寫入同一個檔案
- 結構：使用
## 一級標題和### 二級標題，表格用標準 Markdown 語法 - Mermaid 圖：用
mermaid包裹，確保可在支援 Mermaid 的渲染器中顯示 - 參考資料：分類編號，放在最後
詳細的空白模板見 assets/report-template.md。