從議題探索到專題成立：認識 Gate A、Gate B、Gate C 三大決策關卡
問題診斷導向 Capstone 教學文章｜適用於不同產業、組織、社區及跨域合作場域
在 Capstone（總整課程／專題實作）中，學生常急著決定要開發網站、App、智慧設備或 AI 應用，卻未必先確認真實工作情境中的問題是否存在、為何持續發生，以及是否適合在課程期間完成。問題診斷導向的核心，就是先以訪談、觀察與工作證據理解問題，再把經過驗證的問題轉化為可執行的專題。
為避免各階段過早跳到解決方案，教學流程設置三個階段性決策關卡（Decision Gates）：Gate A、Gate B、Gate C。每一關都要回答不同的問題，且未通過時應補足資料或調整方向，而不是直接進入下一步。
一、三個 Gate 有什麼不同？
| 比較項目 | Gate A | Gate B | Gate C |
|---|---|---|---|
| 核心提問 | 這個議題值得進一步探索嗎？ | 是否找到有證據支持的跨角色系統性核心問題？ | 能否轉成學生可執行、可驗證的課程專題？ |
| 主要依據 | 高階訪談、問題線索、候選議題比較與合作條件 | 執行層訪談、旅程圖、工作流程圖、關鍵資訊流圖與六要素 | POV、介入位置、HMW、教學可行性與責任邊界 |
| 產出 | 焦點議題與場域探索邊界 | 跨角色系統性核心問題 | 課程專題成立／調整判定 |
| 通過後 | 規劃執行層訪談及場域探索 | 萃取 Needs、Insight、POV | 定錨正式課程挑戰任務 |
| 未通過 | 重新比較議題、釐清範圍或合作條件 | 回到角色別三圖證據與問題群集 | 調整介入範圍、任務難度、資源或責任邊界 |
二、Gate A：焦點議題確認
Gate A 是「選定值得深入研究的議題」，而不是宣告已經找到問題根因。在前期高階訪談後，先整理受訪者提及的具體困難、反覆現象、工作負擔或風險，形成問題線索，再依共同工作情境分群為候選議題。接著比較各議題的重要性、探索價值、教學適切性、教學可行性及場域合作可行性。
Gate A 通過的三項條件
- 已形成明確且具探索價值的焦點議題。
- 已界定探索範圍與合作邊界。
- 已確認具備後續執行層訪談與場域探索的可行性。
通用示例：訪談顯示某項跨部門服務需要多次協調，於是先把「跨角色服務協作與資訊傳遞」列為焦點議題；此時仍不能斷定原因就是資訊不完整、工具不足或人員疏失。這些都要留待現場查證。
三、Gate B：跨角色系統性核心問題確認
通過 Gate A 後，教師與學生要進入實際工作情境，理解至少兩個核心角色如何共同完成任務。透過Journey Map（角色旅程圖）、Workflow Map（工作流程圖）、Information Flow Map（關鍵資訊流圖），交叉比對體驗、行為與資訊承接的證據。
接著整合六項核心問題元素：主要角色、共同關鍵情境、共同關鍵任務、共同形成機制、共同問題現象、共同影響。只有當角色別證據指向同一形成機制，才有基礎提出跨角色系統性核心問題。
Gate B 四項品質檢核
- 兩個角色的問題群集是否指向同一跨角色形成機制？
- 六項核心問題元素是否都有旅程圖、流程圖、資訊流圖的證據支持？
- 核心問題是否未預設工具、系統或 AI 解方？
- 是否可進入 Needs、Insight 與 POV？
通用示例：若兩個角色都在同一服務交接流程中反覆補問與確認，學生不能只因兩人都說「溝通麻煩」就判定為共同問題；還須查明哪個交接節點、哪種必要資訊或完成條件未被充分承接，以及實際造成什麼工作影響。
四、Gate B 之後：Needs、Insight 與 POV
Gate B 通過後，進入設計觀點形成階段。這三個概念有明確分工：
| 概念 | 回答的問題 | 撰寫重點 |
|---|---|---|
| Needs（需求） | 角色要完成關鍵任務，缺少什麼必要工作條件？ | 寫工作條件，不寫工具功能。 |
| Insight（洞察） | 為何已有因應作法，問題仍持續發生？ | 連結既有作法、形成機制、重複現象及影響。 |
| POV（設計觀點） | 兩個角色共同需要改善的問題切面是什麼？ | 整合核心角色、共同情境、共同需求及共同洞察。 |
POV 句型：【核心角色】需要在【共同關鍵情境】下，能夠【共同關鍵需求】，因為【共同洞察】。
POV 還要經過五項品質檢核：是否對應兩角色需求、說明共同形成機制、聚焦同一資訊承接鏈、未預設工具或 AI 解方，以及能否進入介入位置與 HMW。
五、Gate C：課程專題成立
經過 POV 品質檢核後，才進一步判斷應介入哪個工作環節，並形成 HMW（How Might We，我們如何能夠……？）設計問題。教材以三個可介入位置協助思考：L1 資料產生層、L2 資訊流與交接層、L3 判斷使用層。它們是設計介入位置，不是另一套問題診斷模型。
接著確認學生的學習能力、跨域整合需求、場域合作資源、資料與驗證條件，以及專業責任邊界。若使用 AI，也必須明確界定 AI 的輔助範圍，不應把 AI 視為唯一解方，更不能以學生原型取代應由專業人員負責的判斷。
Gate C 課程成立性檢核重點
- 是否具備真實問題證據與產業／場域需求？
- 是否具有跨角色或跨領域的學習價值？
- 是否符合學生先備能力及課程時間？
- 是否能完成原型、情境測試或其他可行驗證？
- 是否具備必要的場域、人員、資料與合作支持？
- 是否清楚界定學生、AI 與領域專業人員的責任？
通用示例：即使已確認跨角色資訊承接問題，也不能直接指定學生開發一套完整管理系統。若課程僅有一學期，可能先以流程重整、表單原型、介面模擬或情境測試進行驗證，再評估是否需要進一步導入技術。
六、完整教學流程圖
七、教師帶領學生時，最常見的三個誤區
- 把候選議題當成問題根因：高階訪談指出「流程不順」，只表示值得查證；真正形成機制仍需執行層證據。
- 把需求寫成工具：「需要一個 AI 平台」是可能的解方；「需要在交接時取得完整且可確認的資訊」才是工作需求。
- 把做得出來當成值得做：技術可行不代表專題成立；還須確認問題證據、場域價值、學生學習與驗證條件。
八、課堂討論與反思
- 如果合作單位希望學生「做一個 App」，教師應先用哪個 Gate 的思考方式回應？為什麼？
- 兩個角色都抱怨資訊傳遞麻煩，是否足以通過 Gate B？還需要哪些證據？
- 若核心問題已確認，但場域無法提供測試資料，Gate C 應如何調整專題範圍？
Gate A 選對議題 → Gate B 找對問題 → Gate C 做成可執行、可驗證的專題。
三個 Gate 並不是為了增加行政程序，而是讓學生每走一步都有依據：先確認值得探索，再確認問題成立，最後確認課程可做且能驗證。這也是問題診斷導向 Capstone 與「先決定技術、再尋找應用情境」最大的差異。
