demo-storytelling

把 PoC / prototype 包裝成有說服力的 demo 故事。輸入技術成果/受眾/數據,輸出 demo 腳本 + 一頁摘要 + FAQ。當用戶要展示成果、準備 demo、報告 PoC 時使用。

Demo 故事包裝器

目標

把技術成果轉化為有說服力的 demo 故事。產出包含:完整 demo 腳本、一頁摘要、FAQ 預備。適用於週會報告、面試作品集、LinkedIn 展示、blog 文章。

不適用場景

  • 還沒做出東西(先去做,再來包裝)
  • 純理論研究(沒有可展示的成果)
  • 需要保密的內容(NDA / 公司機密的核心數據)

輸入

$ARGUMENTS 或對話中取得:

欄位必填說明
做了什麼技術成果的簡述
給誰看預設:技術主管 / 非技術老闆
量化數據省了多少時間、自動化了什麼、前後對比
展示形式預設:3-5 分鐘 live demo

若缺必填欄位,直接問用戶。

Decision Model

Step 1: 素材盤點(Pre-flight)

在動手寫腳本前,先盤點手上有什麼:

素材有/沒有沒有怎麼辦
可展示的畫面(截圖/GIF/live)必須有先錄一段或截圖,沒畫面沒 demo
量化數字(時間/成本/準確率)最好有用代理指標或定性描述,標記 TBD
前後對比最好有用情境對比代替數字對比
受眾背景資訊最好有預設用「非技術主管」設定

若關鍵素材(畫面)缺失,先提醒用戶補齊再繼續。

Step 2: 萃取故事核心

從技術描述中抽出三個要素:

要素問題範例
Pain之前怎麼做?多痛?「人工分類 500 張素材要 2 小時」
Solution你怎麼解決的?(一句話)「用 Claude Vision 自動分類 + 標籤」
Impact結果如何?(數字)「30 秒完成,準確率 95%」

關鍵原則:Pain → Solution → Impact 的順序不能變。先讓人感受到痛,才會覺得解法有價值。

Step 3: 受眾調適

根據受眾調整語調和重點:

受眾Hook 類型重點避免
非技術老闆業務數字ROI、效率提升、可擴展性技術名詞、架構圖
技術主管技術亮點架構選擇、為什麼這樣做入門級解釋
同事工程師踩坑經驗實作細節、學到什麼過度包裝
面試官個人貢獻你做了什麼決策、為什麼團隊功勞攬身上
社群 / LinkedIn反直覺洞見意外發現、違反常識的結果太 promotional

Step 4: 建構 Demo 腳本

格式分支

形式時長結構備註
Live demo3-5 分鐘完整五段式(下方)預設
短版 demo60-90 秒Hook + 1 步 demo + Impact週會插播 / Lightning talk
非同步影片2-3 分鐘同 live 但加字幕、可剪輯作品集 / 社群
文字版300-500 字Hook + Problem + 結果Blog 段落 / LinkedIn

結構(3-5 分鐘版)

1. Hook(15 秒)
   → 一句話製造好奇或驚訝
   → 模式:數字對比 / 反直覺 / 提問

2. Problem(30 秒)
   → 用情境描述痛點(不是功能列表)
   → 讓受眾產生「對,我也遇過」的共鳴

3. Live Demo(2-3 分鐘)
   → 按操作順序列出每一步
   → 每步標註:做什麼 + 說什麼 + 停頓點
   → 標記「wow moment」(觀眾會反應的點)

4. Impact(30 秒)
   → 前後對比(時間/成本/品質)
   → 數字 > 形容詞

5. Closing(15 秒)
   → 留下一個記憶點
   → 模式:下一步計畫 / 邀請試用 / 金句收尾

節奏控制

  • wow moment 放在 demo 的 60% 位置(不是開頭也不是結尾)
  • 每步之間有 transition sentence(不要跳躍)
  • 如果有 bug 風險的步驟,準備 fallback 說詞

Step 5: 產出附件

一頁摘要(Slack / Email 用)

[一句話 Hook]

做了什麼:[Solution 一句話]
解決什麼:[Pain 一句話]
成果:[Impact 數字]

想看 demo 的話 [行動呼籲]

FAQ 預備

預測 3 個最可能被問的問題,分兩類:

  • 技術問題:「這個能 scale 嗎?」「API 費用多少?」
  • 業務問題:「能用在其他場景嗎?」「多久能上線?」

每個問題準備:簡短回答(30 秒)+ 如果追問的延伸答案。

輸出格式

## Demo 故事:{標題}

### 受眾:{受眾}|時長:{X} 分鐘

---

### Demo 腳本

**1. Hook**(15 秒)
> "{Hook 台詞}"

**2. Problem**(30 秒)
> {情境描述}

**3. Live Demo**({X} 分鐘)
- Step 1:{操作} → 說:"{台詞}"
- Step 2:{操作} → 說:"{台詞}"
- ⭐ Step 3(wow moment):{操作} → 說:"{台詞}"
- Step 4:{操作} → 說:"{台詞}"

**4. Impact**(30 秒)
> 之前:{舊數據}
> 之後:{新數據}
> 提升:{百分比或倍數}

**5. Closing**(15 秒)
> "{收尾金句}"

---

### 一頁摘要

{Slack/Email 可直接貼的版本}

---

### FAQ 預備

**Q1:{問題}**
簡答:{30 秒回答}
延伸:{如果追問}

**Q2:{問題}**
簡答:{30 秒回答}
延伸:{如果追問}

**Q3:{問題}**
簡答:{30 秒回答}
延伸:{如果追問}

Quality Gates

  • Hook 在 15 秒內能說完,且能製造好奇
  • Pain 用情境描述,不是功能列表
  • Demo 有標記 wow moment
  • 每個 demo step 都有「說什麼」,不只有「做什麼」
  • Impact 有具體數字(不是「大幅提升」這種模糊詞)
  • 一頁摘要可以直接貼 Slack 不用修改
  • FAQ 涵蓋至少 1 個技術問題 + 1 個業務問題
  • 語調符合目標受眾(不會對老闆講 API schema)
  • 高風險 demo 步驟有備案(錄影截圖 / 備用敘事)
  • 沒有硬數字時用代理指標,且標記 TBD

Heuristics

成功案例模式

  • 「原本 2 小時 → 現在 30 秒」→ 數字對比 hook,最容易打動非技術人
  • 「大家都用 X,但我發現 Y 更好」→ 反直覺 hook,LinkedIn 擴散強
  • 「我以為最難的是 A,結果真正卡住的是 B」→ 踩坑故事,工程師共鳴

失敗案例模式

  • 「我用了 X 技術和 Y 框架和 Z 服務...」→ 技術堆疊不是故事
  • 「這個功能可以做 A、B、C、D...」→ 功能列表不是 demo
  • 「AI 是未來趨勢...」→ 空泛開頭,觀眾秒滑走

判斷捷徑

  • 有前後對比數字 → 優先用數字對比 hook
  • 給非技術人看 → 把所有技術名詞換成動作描述
  • 面試用 → 強調「你做了什麼決策」而不是「發生了什麼」
  • 沒有硬數字 → 用代理指標(「從 5 個步驟縮減到 1 個」)