我怎麼跟 AI 工作
我負責判斷，AI 負責實作
每個專案的分工都一樣：我定義問題、列限制、做取捨、驗收結果；Claude Code 把決定寫成程式。這不是「叫 AI 寫一個 App」，而是我先想清楚要什麼、不要什麼，再把規格交出去。AI 寫得很快，所以瓶頸從來不在程式，而在判斷。
需求來自現場，不來自想像中的使用者
地球日六頂思考帽工具的第一版是每人固定一頂帽子。帶完第一個班，我看到沒分到帽子的學生在放空，才把它改成全組開放作答加 Pass 機制。我盡量在真實使用者面前看產品被使用，然後把觀察整理成下一輪的需求。
有標準答案的問題，不交給模型自由發揮
做動物園 LINE Bot 時，票價、公休日這種有標準答案的問題，一開始全交給 GPT 回答，結果它會自由發揮。後來改成程式先用規則比對，GPT 只負責把答案說得自然。能用規則算的就用規則算，模型留給真正開放的問題。
先定義要看什麼，再讓模型去看
課後用 AI 分析學生答案時，我沒有讓模型「幫我看看寫得好不好」，而是先定義四個維度：黃帽有沒有引用白帽的數據、綠帽有沒有回應黑帽的困難、藍帽是具體行動還是口號、整體是否連貫。模型的輸出品質，取決於你有沒有先把問題問清楚。
每個決策都留下紀錄
背景、當時的選項、最後的決定、理由，以及「未來什麼情況下會改」。這些紀錄一方面讓 AI 下次接手時有脈絡，一方面也是我自己回頭檢查判斷的依據。站上的決策總覽就是從這些紀錄整理出來的。
人機合作回放
每一筆都是真實發生過的：我判斷了什麼、AI 做了什麼、結果如何。
地球日 × 六頂思考帽 ·修正同步狀態 bug
我判斷了什麼
改成全組開放作答後，學生端的「儲存」按鈕被鎖死。我把這個症狀交給 Claude 處理。
AI 做了什麼
Claude 追到 subscribeHatReadiness 在 open-to-all 模式下的判斷問題，以及 hatKey 的 race condition，一併修正。
結果
開放參與模式下的儲存按鈕恢復正常，修正寫進 commit 紀錄。
一句話 流程規則一改，同步狀態的假設就要重新驗一次 →
地球日 × 六頂思考帽 ·把教學目標變成介面
我判斷了什麼
我要的是「綠帽回應黑帽提出的困難」，所以要求綠帽作答時直接看得到同組黑帽寫了什麼。
AI 做了什麼
Claude 在綠帽頁新增即時訂閱的「本組黑帽的困難點」區塊，組員一存檔就更新。
結果
黑→綠的回應從靠記憶變成有畫面可對照，之後也成為課後分析的一個維度。
一句話 想評量什麼，就先在介面上讓學生做得到 →
地球日 × 六頂思考帽 ·依課堂觀察改產品規則
我判斷了什麼
帶班後我決定放棄「一人一頂帽子」，改成全組作答、可 Pass；白帽要拆成具體欄位，老師後台也要能直接改學生答案。
AI 做了什麼
Claude 修復作答按鈕、把白帽改成三個欄位、實作 Pass 機制，並在後台加入作答編輯功能。
結果
流程變成每個人每頂帽子都有事做；不想答的欄位有明確出口，而不是空著卡住。
一句話 原型的角色設計要讓真實課堂來檢驗 →
地球日 × 六頂思考帽 ·課後 AI 分析
我判斷了什麼
我定義分析框架：不判斷是不是 AI 寫的，而是看白→黃有沒有引用事實、黑→綠有沒有回應困難、藍帽是不是具體行動。
AI 做了什麼
Claude 寫了 analyze-708.js：從 Firestore 讀資料，用程式先算好填寫率、藍帽一致性、行動分布，再把統計與原文交給 Azure OpenAI 做質性分析。
結果
產出 708 班 28 筆作答的分析報告，含各組連貫度與三項教學建議。
一句話 數字交給程式算，模型只負責解讀 →