持續參考
07 Demo Day 評分表
業界 demo 最低門檻是什麼?這份表給你答案。 同時也是教練 / 業師評你專題的標準。
評分維度(總分 100)
| 維度 | 配分 | 屬性 |
|---|---|---|
| 1. 問題定義 | 15 | 業務 |
| 2. 架構設計 | 15 | 技術 |
| 3. 實作品質 | 20 | 技術 |
| 4. 協作流程 | 15 | 工程 |
| 5. 復盤深度 | 10 | 反思 |
| 6. Demo 表達 | 15 | 表達 |
| 7. 業界相關性 | 10 | 對標 |
1. 問題定義(15 分)
| 級別 | 分數 | 表現 |
|---|---|---|
| ❌ 0-5 | 「我們做了一個 X 系統」(功能導向,沒有用戶) | |
| 🟡 6-10 | 有提目標用戶,但 persona 模糊 | |
| ✅ 11-15 | 有具體 persona、具體痛點、可量化現況、清楚目標差距 |
checklist:
- 一句話能講清楚為誰解什麼問題
- 用戶 persona 寫得讓人「能想像出這個人」
- 痛點有數字(X 分鐘 / X 元 / X% 不滿)
2. 架構設計(15 分)
| 級別 | 分數 | 表現 |
|---|---|---|
| ❌ 0-5 | 沒架構圖,或只有一個 Python script | |
| 🟡 6-10 | 有架構圖,但只是把工具名擺出來 | |
| ✅ 11-15 | 架構圖能對應 01 6 階段藍圖,能講「為什麼選 A 不選 B」 |
checklist:
- 一張高品質架構圖
- 對應 Source → Ingest → Storage → Transform → Serve → Observe 6 階段
- 對至少 2 個關鍵選型能講原因(例:為什麼用 MongoDB 不用 MySQL)
3. 實作品質(20 分)
| 級別 | 分數 | 表現 |
|---|---|---|
| ❌ 0-8 | 一個 notebook、沒測試、沒拆模組、變數名 data1 data2 data3 |
|
| 🟡 9-14 | 拆了模組、有一些測試、能跑 | |
| ✅ 15-20 | 完整模組化、有單元測試、有整合測試、有 CI、能 docker compose 一鍵起 |
checklist:
-
src/拆成 4 個職責分明的模組 - 有 unit tests(pytest)
- 有 integration tests
- CI 在每個 PR 自動跑
- 環境可重現(
docker compose up一行起) - 沒有 hardcoded secret
-
.env.example完整
4. 協作流程(15 分)
這項是學員 demo 最容易拿不到分的 — 也是業界看得最緊的。
| 級別 | 分數 | 表現 |
|---|---|---|
| ❌ 0-5 | commit message 全是「update」「fix」;沒 PR;只有一個人 push | |
| 🟡 6-10 | 有 commit 規範、有 PR、但 review 留言很少 | |
| ✅ 11-15 | Conventional commits、PR template、深度 review、Issue tracking、有 retro 紀錄 |
checklist:
- Commit message 符合 03 SOP 規範
- 每個 PR 都有 description + review
- 有 Issue tracking(不是只有口頭討論)
- 有 Branch protection 設定
- 有 Sprint retro 紀錄(至少 3 次)
- 每個組員都有 PR & review 紀錄(沒人神隱)
5. 復盤深度(10 分)
| 級別 | 分數 | 表現 |
|---|---|---|
| ❌ 0-3 | 沒寫復盤,或寫「都很順利」 | |
| 🟡 4-7 | 有寫,但停留在「工具卡關」層級 | |
| ✅ 8-10 | 反思流程 / 協作 / 思維,並能講「如果重來會怎麼改」 |
checklist:
- 有
docs/retro/資料夾或 sprint retro 紀錄 - 有 final retro(個人 + 小組)
- 能講出 3 個「重來會改」
- 有 ADR(Architecture Decision Records)紀錄關鍵決策
6. Demo 表達(15 分)
| 級別 | 分數 | 表現 |
|---|---|---|
| ❌ 0-5 | 念簡報、技術細節太多、時間爆 / 不夠 | |
| 🟡 6-10 | 順暢但生硬、業務技術混用 | |
| ✅ 11-15 | 能切換業務版 / 技術版、節奏好、能臨場應答 |
checklist:
- 簡報 ≤ 10 頁
- 時間控制 ±10% 以內
- live demo 流暢(沒卡)
- 至少在組內 dry run 過 3 次
- 能答 5 個常見問題:「為什麼選這題」「為什麼用 X 不用 Y」「踩過什麼坑」「未來怎麼擴展」「分工」
7. 業界相關性(10 分)
| 級別 | 分數 | 表現 |
|---|---|---|
| ❌ 0-3 | 純技術練習、跟業界對不起來 | |
| 🟡 4-7 | 有提到應用場景 | |
| ✅ 8-10 | 能對應到具體業界職位、能講「在 X 公司會怎麼用」 |
checklist:
- 能說「業界誰會做這個」
- 對照 04 痛點地圖 的業界職位
- 知道 1-2 家真實公司在做類似的事
分數對照
| 分數 | 等級 | 對應行動 |
|---|---|---|
| 90-100 | 🏆 業界 demo top tier | 直接放履歷代表作 |
| 75-89 | ✅ 業界 demo | 履歷主力專案 |
| 60-74 | 🟡 學作品 | 履歷可以放,但建議再打磨幾項再上 |
| <60 | 🌱 學作業 | 還沒到放履歷的時候,挑 2-3 個維度補強會大幅提升 |
完整 self check(demo 前 24 小時跑一次)
□ README 第一段能讓「沒看過你專案的人」30 秒理解
□ 架構圖在 README 第一頁能看到
□ 一個指令能跑起來
□ 線上有可訪問的 live demo URL
□ 至少有一支監控(pipeline 失敗會通知)
□ 過去整個課程的 commits 看得出「有人在做事」(不是 demo 前一天 commit 200 次)
□ 至少有一個 reviewed-merged 的 PR
□ docs/ 裡有 architecture / api-contract / retro 三個 markdown
□ 我能在 5 分鐘 / 10 分鐘版本之間切換
□ 我能回答這 5 個問題:選題 / 選型 / 坑 / 擴展 / 分工
打勾 ≥ 8 → 你準備好了。
評委 / 教練給分時通常會問
- 「為什麼這題是業界值得做的?」 → 對應 04 痛點地圖
- 「如果資料量 ×100 你會怎麼改?」 → 看你選型有沒有 scale 邏輯
- 「你最得意的 1 個設計?」 → 你要有準備
- 「你最後悔的 1 個決定?」 → 不要說「都很好」,誠實得分高
- 「組員 X 在這個專案的貢獻是什麼?」 → 你要說得出來
🎯 小作業:用評分表給自己現況做 self check
不是等 demo day 才看 — sprint 2 結束就要先做一次,知道差距還來得及補。
- 7 個維度都打分(不要客氣、不要嚴苛、誠實就好)
- 寫成
docs/self-check-w{N}.mdcommit 進 repo - 框出最低分的 2 個維度,列「下週要補什麼」
- demo day 前再做最後一次 self check(最低 checklist 那段)
交付:PR 連結貼到指定 channel;最低分維度寫成 task 進 task.md。
💡 第一次做通常會嚇到分數比想像低 —— 那才正確。沒嚇到表示你沒誠實打分。

送件鴿飛出去了