核心表格

階段／要素 原書做法 關鍵數字／條件 實務重點
活動目標 由跨功能 fusion team 把真實商業問題從概念推進到可用原型 一個 business day，通常不超過 8 小時 目標是在活動結束前形成可展示的最小可行產品（Minimum Viable Product, MVP）
事前準備 先定義主題、取得主管支持、安排場地／虛擬工具、蒐集問題、準備工具與模板 至少提前 1 個月；跨部門活動可能需要更久 活動前先解決帳號、權限、sandbox 與 sample data
團隊組成 開發者、business analyst、product manager、IT admin、power user、business user 等混合 每隊約 4–6 人 Fusion team 同時需要懂流程與懂技術的人
工具 Microsoft 365 Copilot、Copilot Studio、Azure AI Foundry 每隊至少 1 人需有 Microsoft 365 Copilot license 事前測試環境與 Power Platform／Azure 權限
當日啟動 Check-in、組隊、說明目標與規則 原書 sample agenda 由 8:30–9:00 AM check-in 開始 公布清楚時間表並維持節奏
問題定義 把痛點轉成清楚 problem statement，確認使用者、價值與限制 在有限時間內收斂 避免直接跳到工具而沒有定義問題
原型階段 用 Copilot、Copilot Studio／Azure AI 工具快速迭代、測試與整合 同日完成可展示版本 Simple but working 比複雜但無法運作更有價值
Demo 與評審 說明問題、解法、價值、技術實作與後續可能性 評審考慮 innovation、technical execution、business value 等 Demo 環境事前登入、關閉通知並準備問答
活動後 建立 continuation plan、配置時間／資源、連結既有專案、指派 sponsor／mentor 原書示例：優勝團隊未來 1 個月每週可給 1 天持續開發 避免原型在活動結束後失去動能

實作說明

1. Hackathon 的成果不是點子，而是可展示原型

原書把這個活動設計成一日高密度實作：fusion team 從問題定義、設計、建置一路走到 demo。MVP 不需具備完整 production 品質，但必須能清楚展示問題、解法與可能價值。

2. 一個月前就要處理真正會卡住活動的事情

主管支持、參與者時間、Copilot 授權、Copilot Studio 環境、Azure 權限、資料與模板，都應在活動前確認。Hackathon 當天才解決存取問題會大量吃掉實作時間。

3. Fusion team 是附錄 A 的核心設計

原書強調 hackathon 不只給工程師。懂業務流程的人知道問題在哪裡，技術人員知道如何實作，兩者一起工作才容易把 AI 原型連到商業價值。

4. 評審應同時看創意與可運作性

創新與 creativity 很重要，但 technical execution 不等於追求最複雜方案。原書明確指出，簡單而穩定的原型可能比勉強運作的複雜方案更有價值。

5. 活動後的延續機制決定實際影響

原書建議為有潛力的專案定義資源、資料、時間與 stakeholder，安排 sponsor／mentor，並把成果連到既有策略或正式 pilot。沒有 follow-up，再好的 hackathon 點子也容易消失。

資料說明

依 aBook14A Appendix A；所有時間、團隊規模與工具條件均以原書為準。