起點不是自動化，是不想每週重新受一次苦

一開始最直接的想法其實很樸素：如果每週都要找資料、整理教材、改逐字稿、做題目、檢查作業、整理結果，為什麼不能讓系統自己跑？教師真正想省下的，不只是幾個小時，而是每次重新進入同一個繁瑣流程時，都要再把脈絡從頭想一遍的精神消耗。

於是自動化很容易被想成一條理想輸送帶：來源進來，人工智慧處理，文件產出，學生收到，作業回來，系統批改，結果寄出。這幅圖很有吸引力，因為它把教師從大量重複動作中解放出來。問題是，教學工作的難處往往不在「做出一份檔案」，而在於判斷這份檔案是否適合這一週、這一班、這一批學生，以及它是不是仍然忠於原本的課程意圖。

後來回頭看，最初的自動化願望並沒有錯。錯的是把「重複」和「可以放心交給機器」當成同一件事。重複的動作可以自動化，重複出現的判斷卻要先被說清楚，否則機器只會很有效率地把不清楚的規則放大。

這一頁留下的判斷：自動化的需求，通常是流程痛苦的訊號；它還不是可直接執行的規格。

教師一開始在腦中建構的完整架構，長什麼樣子

那時候腦中其實已經有一張相當大的圖：上面是課程目標與每週進度，中間是教材、案例、逐字稿、Notebook、作業、Quiz、討論、白板與分組，下面則是學生提交、批改、通知、紀錄、備份與發布。每一個東西都應該能找到來源，每一次修改都應該留下理由，每一個結果都應該可以在需要時重建。

這張圖並不是純粹的資訊系統藍圖。它同時包含一套教學理想：學生不只讀答案，而要先形成自己的判斷；AI 不只替學生寫完，而要迫使學生說明取捨；分組不能只是把名字放在一起，而要能在成員變動後說清楚誰在什麼期間和誰合作；教材不能只追求完整，而要適合實際的課堂節奏。

也正因為這些事情在腦中彼此相連，第一個困難就出現了：教師看到的是整體，工具卻一次只能處理一小段。要把整體交代給工具，提示會變得很長；要切小，脈絡又可能斷掉。於是工作開始在不同平台之間來回：有時在 ChatGPT 把教學想法說清楚，有時在 Codex 讀檔案和修改程式，有時在 Work 裡處理批次或外部平台，還有一些事情回到 Google Drive 或 Notebook 才能繼續。

這一頁留下的判斷：完整架構可以先存在教師腦中，但必須被拆成可交接、可驗證、可暫停的工作包。

為什麼第一版幾乎一定會太大

第一版之所以容易過大，是因為每一個需求單獨看都很合理。教材需要來源；來源需要同步；同步需要登錄；登錄需要檔案地圖；檔案地圖需要網站；網站需要實例；實例需要去識別；作業需要規則；規則需要批改；批改需要通知；通知又牽涉帳號、權限與紀錄。當這些事情同時出現時，很難說哪一個不重要。

更麻煩的是，教師通常不是在空白紙上設計系統，而是已經有一些舊的表單、試算表、GAS 原型、課程頁面、Notebook、電子郵件與人工習慣。每一個舊工具都承載了過去的經驗，卻也帶著舊的限制。若把所有舊東西一併搬進新架構，表面上像是保留成果，實際上可能只是把舊問題一起升級。

後來比較可行的做法，是把需求分成三類。第一類是沒有它就不能教的核心，第二類是有了會比較方便的改善，第三類則是未來可以研究但目前不應該承諾的想像。這個分類不是一次完成的；它會在每次課堂、每次測試、每次服務限制出現時重新調整。

這一頁留下的判斷：MVP 不是少做幾個功能，而是先承認哪些問題目前還沒有足夠證據可以解。

從《陸王》開始：案例先於系統

回頭看整段歷程，最早不是從「我要做一個 AI 教學平台」開始，而是從一個個案、一部作品、一個教學現場的問題開始。使用《陸王》這類案例時，教師在意的不是把故事變成摘要，而是如何讓學生從人物、組織與決策中看見管理概念。案例先把教學問題逼出來，系統才有理由出現。

早期做法往往是先把能找到的資料集中起來，再試著整理成講義、問題或討論方向。這樣很快就能得到一份看似豐富的內容，但內容多不代表學生知道要觀察什麼。當情節、背景、理論、活動與作業全部堆在一起時，教師自己可能覺得完整，學生卻不知道第一步該從哪裡開始。

這個階段的重要收穫，是開始意識到案例不是教材的全部。案例只是讓學生進入問題的門；真正的教材還要說清楚本週要做的判斷、可使用的證據、尚不知道的部分、討論要留下的產物，以及課堂之後如何重新檢查原本的想法。這也成為後來所有內容設計的底層節奏。

這一頁留下的判斷：如果一個功能無法說明它改善了哪一個學習判斷，就先不要把它當成系統需求。

到《未生》：同一套方法不能原封不動複製

後來從《陸王》走到《未生》，最明顯的感覺是：看起來都在談組織、工作與管理，實際上學生進入情境的方式並不一樣。不同作品的節奏、人物關係、權力位置與情緒重量不同，不能只換一個標題，就把同一份教材、同一組提示詞、同一種作業形式直接套上去。

這也是為什麼「做一個通用模板」很快會變成雙面刃。模板可以保留格式與檢查順序，卻不能替教師決定每一週最值得留下的問題。模板若太鬆，品質會漂移；模板若太緊，所有案例最後都會變成同一種說話方式，學生看到的不是案例，而是模板的影子。

真正逐漸穩定的，不是內容本身，而是內容生成前後的幾個問題：這週只處理哪個範圍？哪些材料是正式來源？哪些細節不能自行補造？學生要先做什麼？AI 可以在哪一步加入？最後的產物要讓教師看見什麼？這些問題可以跨案例重複，答案卻必須回到個案。

這一頁留下的判斷：跨課程最值得複製的是判斷程序，不是上一門課的答案。

企業授課讓「看起來合理」變得不夠

企業授課經驗帶來另一種壓力。課堂時間更緊，參與者背景差異更大，問題不一定能留到下一週才處理。學員不會因為教師在後台建立了一套漂亮架構，就自然理解其中的規則；他們只會直接感受到：現在要做什麼、資料在哪裡、能不能登入、交錯檔案會不會不見、如果做錯能不能補救。

這些現場經驗把一個常被忽略的事實推到前面：任何技術設計最後都要落在人的行動上。學生需要知道下一步，教師需要知道目前狀態，助教需要知道哪一件事可以代處理，系統則需要在大家做出不完美行動時，仍然留下可理解的紀錄。

企業場景也讓「自動化越多越好」受到挑戰。當資料涉及客戶、版權、公司內部案例或不同角色的權限時，最有價值的功能不一定是自動完成，而可能是幫人清楚分開哪些資料可以分享、哪些人可以看、哪一個版本已經被確認。速度重要，但可追溯與可收回更重要。

這一頁留下的判斷：使用者經驗不是介面最後的修飾，而是課程流程本身的一部分。

教材生成與教學設計，必須分開看

一開始很容易把「生成教材」想成主要工作：只要來源夠多、提示詞夠完整、模型夠強，便能產生一份高品質教材。後來才發現，生成只是把文字寫出來，教學設計則要決定學生為什麼在此時讀這段、要用它做什麼、完成後要如何證明自己真的做過判斷。

同一份內容可以是教師備課筆記、學生閱讀材料、課堂投影、作業背景或教師評量依據；放在不同位置，寫法與責任都不同。若沒有先分清楚，AI 會把所有用途混成一篇「看起來很完整」的文章。教師也容易在後面才發現，學生需要的是清楚的入口，不是更多段落。

因此後來的工作包通常先寫一份週次簡報或教學摘要，說明本週要處理的決策、前後週如何銜接、學生要留下哪些證據，以及哪些規則仍待教師確認。研究與寫作是在這個框架內工作，而不是各自自由發揮。這個改變看似增加前置工作，實際上減少了後面大幅重寫的機會。

這一頁留下的判斷：教材的完成條件，不是字數或頁數，而是學生能否沿著它做出可說明的行動。

混沌的工作場所：ChatGPT、Codex 與 Work 反覆接力

整段歷程最難描述的地方，正是工作並沒有待在同一個地方。某些想法先在 ChatGPT 裡形成，接著交給 Codex 讀取本機檔案；某些檔案在 Codex 修改後，又回到 ChatGPT 做課程設計；有些工作在 Work 做到一半，才發現需要回到本地檔案確認；另一部分則是先由工具完成，再由教師重新判斷是否適合放進課堂。

如果把這種混亂當成單純的工具問題，會低估真正的原因。每個地方擅長的事情不同：對話比較適合展開想法與反駁，Codex 比較適合讀寫檔案、執行檢查與理解版本，Work 可能承接外部服務或批次工作，而 Google Drive、Notebook 與 Teams 又是實際教學資產所在。問題不在於工具多，而在於交接時常常沒有留下足夠的狀態。

後來才逐漸理解，不能要求每一個平台記住全部歷史。必須把「目前結論、來源位置、已完成、未完成、不可做的事、下一步」寫成一份可以被下一個工作者讀懂的交接。這些文件不是行政負擔，而是讓混沌不至於每次都重新開始的外部記憶。

這一頁留下的判斷：跨工具工作的最小單位不是一次對話，而是一個有來源、狀態與接手方式的工作包。

最先要管理的不是模型，而是來源

在大量內容生產中，最容易被忽略的是來源。大家通常先問要用哪個模型、提示詞要寫多長、結果要不要再潤稿；但如果不知道目前使用的是哪個版本、來源是否更新、某段內容是原文還是整理稿，後面所有比較都會失去基準。

因此來源登錄表慢慢變成不可省略的底層工作。它不只記檔名，還要知道用途、目前版本、來源類型、是否允許進入學生端、上次檢查時間、是否有衝突，以及最後由誰確認。來源本身也要分層：正式原稿、教師工作稿、學生可見副本、合成示例與仍待核定資料不能混成同一種東西。

這個做法一開始很慢，因為每一個檔案都要問「它到底是什麼」。可是沒有這個停頓，AI 很容易把舊內容當新規則，把草稿當正式版，把推測寫成事實。最危險的錯不是句子不漂亮，而是內容看起來合理，因此沒有人發現它其實沒有來源。

這一頁留下的判斷：任何生成結果的可信度，都不能高於它所依賴的來源與狀態紀錄。

Notebook 的小入口，解決的是人的迷路

Notebook 相關工作給了一個很具體的教訓：同步問題常常不是因為人不知道要同步，而是因為人找不到正確的資料夾、記不住正確的版本，或每次進入都要重新穿過一長串路徑。當教師正在處理教材時，這些小摩擦會累積成很大的阻力。

後來建立一個方便快速連接的本地 HTML 入口，讓教師能從熟悉的位置進入需要新增或編修的資料夾。它不負責取代 Google Drive，也不假裝自己就是正式來源；它只做一件小事：縮短從「我知道資料存在」到「我能看見正確資料」之間的距離。

這個設計看起來不像高難度功能，卻比新增更多自動同步規則更符合現場。入口頁如果清楚標示正式來源、工作副本與待核定區，還能順便提醒教師：現在看到的是哪一層資料。也就是說，好的入口不只是捷徑，同時也是一個小型的判斷提示。

當然，入口頁並不會自動解決權限、來源更新或內容衝突。這些仍然要靠登錄、讀回與人工核對。它的價值在於把人力留給真正需要判斷的地方，而不是消耗在尋找資料。

這一頁留下的判斷：MVP 有時只是一個穩定、誠實、能帶人抵達正確來源的入口。

逐字稿清理：不是把話說得漂亮，而是把課堂留下來

逐字稿是原本架構裡比較少被正式照顧的一塊。課堂會持續產生錄音與轉譯文字，久了之後，教師手上可能有很多內容，學生卻不願意閱讀。因為原始轉譯通常包含錯字、斷句、贅詞、收音外片段與說到一半的句子；它保留了發生過什麼，卻沒有提供一個清爽的閱讀入口。

清理逐字稿最重要的原則，是改善可讀性，不替課堂補講沒有說過的內容。可以修正文法、合併重複、校正明顯的語音辨識錯誤、統一已確認的術語，也可以移除與課程無關的收音片段；但不能為了讓文章更完整，就自行添加老師沒有說過的例子、理論或結論。

因此清理後應留下幾種痕跡：原始檔仍然保留，清理稿另存；明顯不確定的地方要標記；外部影片或活動只在確有必要時保留流程註記；每一週都要知道目前是草稿、待核定還是正式鏡像。學生看到的應該是教師確認過的閱讀版本，而不是一份被過度加工、卻無法追溯的漂亮文章。

這一頁留下的判斷：文字清理的成功，是保留內容邊界後提高可讀性，不是把不確定性藏起來。

模型與提示詞：先建立測試題，再談哪個模型最好

逐字稿清理也暴露出另一個誘惑：遇到一個新任務，就立刻問哪個模型最強。可是模型名稱本身不能保證結果適合教學。對逐字稿來說，真正重要的是能不能遵守術語、能不能不臆測、能不能保留說話者的限定、能不能處理長文、能不能在必要時說「這裡不確定」。

比較穩定的做法，是先準備一小組測試片段：有明顯錯字、有專有名詞、有未完成句、有需要保留的不確定性，也有不應該被納入的收音。讓不同模型或不同提示詞處理同一組材料，再比較它們是否保留事實、是否新增內容、是否刪掉重要限制。這樣才有資格談選擇。

一個可重用的提示詞可以這樣寫：

你是臺灣繁體中文的課堂逐字稿編輯。
請只做：校正明顯轉譯錯誤、調整斷句、刪除贅詞、統一已提供的術語，並保留原本的限定語氣。
請不要：補造案例、補寫理論、替講者下結論、猜測聽不清楚的內容，或刪除仍有教學價值的不確定性。
請把無法確認的地方標成「[待確認]」，最後列出你改動最多的三類地方。
輸出：清理稿、待確認清單、與原稿可能有實質差異的提醒。

這個提示詞只是工作範本，不是自動核准。模型回傳後仍要逐項比對原稿，尤其是數字、日期、人名、術語、論點與限制。實際採用哪個模型，應以測試結果、資料敏感度與當時可用的服務為準，而不是以印象決定。

這一頁留下的判斷：模型選擇要由任務測試回答，提示詞要把不能做的事寫清楚，最後核定仍是人的責任。

Assignments：從「交一份東西」變成「留下判斷過程」

作業設計早期容易從成果名稱出發，例如要求一份分析、一份備忘錄或一個決策方案。這樣對熟悉學術寫作的人很清楚，對第一次接觸管理個案的學生卻不一定。學生仍然要猜：情境到底在談什麼？要做哪個選擇？需要哪些段落？AI 可以用在哪裡？最後教師想看見的是結論，還是形成結論的過程？

後來作業逐漸改成先給範圍卡，再給具體步驟。情境先說清楚本週處理的是哪一種服務、哪一個決策、哪些已知與未知，以及哪些看似相關但不在本週範圍內。學生先寫自己的第一判斷，再進行小組討論；若使用 AI，就留下 AI 提供了什麼、自己保留了什麼、修改或拒絕了什麼。

這樣的設計讓作業不再只是把最後答案交出去。教師可以看見學生如何理解問題，學生也比較不會因為格式或檔名猜錯，就被誤判為沒有完成。這並不代表規則變鬆，反而是把真正重要的規則移到內容：問題是否有範圍、理由是否有證據、未知是否被承認、行動是否可重新檢查。

這一頁留下的判斷：好的作業不是要求學生猜中教師腦中的格式，而是把學習行動拆到學生能開始的位置。

Quiz：從背定義，轉向檢查學生有沒有真的判斷

Quiz 的困難和作業很像。只要題目能自動計分，就容易被誤認為已經穩定；但一個學生選對名詞，不表示他知道何時使用，也不表示他能在資料不完整時做出合理決定。Quiz 如果只測記憶，會讓 AI 很容易代替學生完成；如果要測判斷，就要把條件、證據、可逆行動與重新檢查放進題目。

因此每週題目需要回到該週教材與前後週學習地圖。它不應該只是從一般管理學題庫抽幾題，而要讓學生在課前用短時間確認自己是否抓到本週的基本問題。題目、選項、回饋、配分與表單狀態都要分開讀回，不能只看一個「已建立」就以為整個 Quiz 可以使用。

另一個重要轉折，是把建立流程和正式成績分開。可以先建立測試版、做合成資料的批改與通知演練，也可以記錄尚未完成審查的 provisional 狀態；但沒有教師核定的正式版本，不能冒稱為正式標準。某一週做得很好，也不能直接把題目答案複製到其他週。

這一頁留下的判斷：一個能自動出分的 Quiz，仍然可能是一個沒有教學價值的 Quiz。

Prompt 的核心不是命令 AI，而是安排學生思考

當 Prompt 被當成「叫 AI 給答案的句子」，它很快就會把學習變薄。學生只要複製一個問題，AI 便可以回傳一段完整說明，最後大家交出的內容都很像。後來 Prompt 的設計方向逐漸轉變：先讓學生在沒有 AI 時留下第一判斷，再讓 AI 擔任反方、提問者或整理者，而不是直接擔任代答者。

一個實際的課堂流程可以先要求學生說明情境、選項、已知、未知與第一決定，接著請 AI 提供一到四個討論方向。小組選一個方向後，再要求 AI 提出相反觀點、指出需要補的證據、連到一個管理概念，最後提出一個可以回到課堂討論的理論問題。學生不是把思考交出去，而是用 AI 把自己的思考照得更清楚。

這也讓深層理論有了比較自然的入口。教師不是先把全部理論講完，再要求學生套用；而是先讓學生碰到一個實際取捨，等學生看見自己的判斷有缺口，再把責任、決策權、授權、問責或有限理性等概念接回來。理論因而不只是後段的名詞整理，而是用來修改原本決定的工具。

這一頁留下的判斷：Prompt 設計的成功條件，是學生最後能說清楚自己如何改變，而不是 AI 回答有多完整。

自動批改的誘惑：只要規則寫得夠細就好了嗎

自動批改是最容易讓人產生「終於可以交給機器」錯覺的地方。因為它看起來有明確輸入和輸出：學生交檔案，系統找檔案，AI 讀內容，回傳分數，再寄出通知。但實際上，檔案配對、遲交、重交、缺欄位、格式錯誤、同名、版本混淆與空白回覆，都可能讓後面的評分失去對象。

此外，批改規則本身也常常有不同用途。課程要求、檔名辨識、內容證據、遲交調整、教師覆核與最後分數不能被壓成一個欄位。若系統只留下最後分數，教師很難知道錯在學生沒有交、系統找不到、AI 判斷不穩，還是教師後來做了調整。

比較可靠的方向，是先建立原始回應與結果的分層。原始檔保存學生實際交付的內容；處理結果說明系統做了什麼；批改狀態標記是否需要人工查看；最後分數與覆核理由另存。這樣即使某個步驟失敗，也能回到上一層重新處理，不必把全部流程重跑。

這一頁留下的判斷：批改自動化最先要保存的不是分數，而是讓分數可以被追問的路徑。

檔名只是線索，不是證據

早期最容易犯的錯，是把檔名當成可靠身份。檔名看起來很方便：有週次、有姓名、有作業名稱，系統就能依規則抓取。可是學生可能改錯副檔名、複製上一週名稱、用手機直接上傳、把協作紀錄接在本文後面，或根本不清楚教師期待的命名方式。若直接用檔名判定成敗，系統評估的可能是學生的檔案操作能力，不是學習成果。

後來配對的優先順序改得更保守：先看提交編號、課程、週次、學生身分、群組、產物角色與 attempt，再用檔名作為輔助線索。找不到清楚配對時，標記為需要查看，而不是自動判定為零分。對教師來說，這多了一個人工檢查；對學生來說，卻避免了因為一個格式失誤而被系統誤判。

這個轉變也改變了批改規則的寫法。規則不再只寫「檔名必須符合格式」，而要說明：系統如何找到人、如何判斷哪個版本、缺少什麼時應該停下來、教師可以怎麼修正、修正後如何留下紀錄。規則越靠近真實風險，越不適合只用一句自動化條件帶過。

這一頁留下的判斷：凡是會影響學生權益的判定，都要先問「如果這個線索錯了，能不能救回來」。

Skill 是把經驗寫出來，不是把責任交出去

當同樣的錯誤反覆出現，就會產生建立 Skill 的念頭。它可以把工作順序、檔案命名、輸入輸出、禁做事項、檢查方法與交接格式集中起來，讓下一次不必只靠記憶。這確實有價值，因為很多失敗不是能力不足，而是每次重新開始時漏掉了一個曾經踩過的坑。

但 Skill 也很容易變成一張看似完整的說明書。它把流程寫得很漂亮，卻沒有說明在哪些情況下必須停止；或者它沿用了已經被驗證有問題的做法，只因為那是上一版的正式文字。真正有效的 Skill，必須能吸收失敗，並且把失敗轉成新的驗收條件。

以作業和 Quiz 為例，Skill 不只是指定生成格式，也要規定先讀前一週課後回顧、確認本週範圍、區分學生端與教師端、檢查 AI 使用規則、建立合成測試資料，再把正式核准留在人手上。以逐字稿為例，Skill 要求保留原稿、標記待確認、不補造內容，並且在模型回傳後逐項比對。

這一頁留下的判斷：Skill 的成熟度，不看它有多長，而看它是否把「何時停止」寫得和「怎麼完成」一樣清楚。

Reviewer 為什麼必要：作者不能同時替自己判定安全

在內容與系統同時變動的專案裡，作者很容易對自己的結果產生盲點。因為作者知道原本想做什麼，所以看到畫面時會自動替它補上缺少的意思；作者知道哪個檔案是新的，所以沒有發現另一個地方仍然指向舊版；作者熟悉流程，也可能忘記第一次使用的人根本不知道下一步。

Reviewer 的作用不是把所有文字改成同一種風格，而是用另一個角度問幾個問題：這句話有來源嗎？這個狀態是否被誇大？學生能不能照做？錯誤能不能回復？公開頁面是否暴露不應該出現的資料？程式檢查通過之後，畫面和實際內容是否仍然一致？

更重要的是，Reviewer 不應該只在最後一天出現。研究、寫作、建置、資料處理與發布各自有不同的檢查點；在早期讓 Reviewer 看到方向，可以避免後面才發現整個成果建立在錯誤前提上。若審查意見和教師決定不同，也要保留差異，而不是把所有不同意見都偷偷改掉。

這一頁留下的判斷：技術 QA、內容 Reviewer 與教師核定是三個不同關卡，任何一個都不能冒充另外兩個。

分組問題浮現時，才知道表單不等於平台

分組最初看起來很簡單：學生填自己的資料、輸入組名、列出組員，教師收回來整理。當課程只有一個班、只分一次組時，這種方式或許可以靠人工撐住。但一旦出現跨課程、跨學期、浮動分組、成員更換、多人搶同一位成員、教師需要核定，以及後面還要做互評，原本的表單就開始顯露它沒有保存關係與歷史的能力。

真正的問題不是表單欄位不夠，而是「誰在什麼時間和誰合作」本身是一段有開始與結束的關係。學生現在的小組，可能和上一輪不同；互評名單應該依當時的合作期間產生，而不是讓學生每次重新手打。若後來調組，歷史紀錄不能被整段改寫，否則教師無法解釋一份舊評量到底對應哪一次合作。

當需求走到這裡，平台就不再只是表單的升級版。它需要知道課程、學期、班級、分組期間、成員有效性、申請、確認、教師核定、評量快照與提交版本。這些概念並不一定都要在第一天完成，但如果一開始完全不承認它們存在，後來補救的成本會更高。

這一頁留下的判斷：當資料會隨時間變動時，單一張表很難同時保存現在與過去。

舊工具不是失敗品，而是把限制留下來給下一版看

在建立分組與互評平台前，必須先看舊工具：早期的分組表單、Peer evaluation 原型、GAS 版本、瀏覽器草稿、JSON 匯出，以及其他課程曾經採用的欄位。這些東西各自解決過當時的問題，也各自留下了限制，例如手動輸入隊友、固定人數、固定輪次、只能在瀏覽器留下草稿，或無法從不透明回應確認資料是否真的寫入。

盤點的目的不是挑出一個「最好的舊版本」直接複製，而是分辨哪些是教學政策，哪些只是某版程式的限制。四位隊友、五個面向、固定輪次或某一個成員上限，都不能因為曾經出現在程式裡，就被當成所有課程的正式規則。程式的樣子只是歷史證據，不是教師決定的替代品。

同樣地，舊資料也不能為了讓新平台看起來完整，就全部搬進來。若無法確認它們的來源、權限、評量用途與資料品質，最安全的做法是把舊設計作為參考，把新平台從乾淨的資料模型開始。保留歷史，不代表要把每一筆舊資料都轉成新系統的正式資料。

這一頁留下的判斷：盤點舊系統的首要產物不是搬移清單，而是限制與證據的清單。

Supabase 與 GAS：不是誰比較高級，而是問題不同

GAS 很適合快速把表單、試算表與通知接起來。教師容易看懂資料落在哪裡，也能很快做出第一個可用原型。它的優勢是靠近既有工作習慣，適合小規模、規則清楚、以表格為中心的流程。問題是當資料關係變複雜、需要權限隔離、需要伺服器確認、需要保存多段歷史時，原本的簡單會開始變得不夠。

Supabase 提供另一種思考方式：讓課程、班級、成員期間、快照、草稿、提交與權限成為資料的正式關係，再由前端依照規則讀取與操作。它比較適合需要登入、角色、跨課程沿用與可查核狀態的系統，但也帶來新的責任：資料庫權限、備份、郵件、流量、部署與環境設定都不能只靠「頁面能打開」來判定完成。

中間還遇到服務方案的實際限制，原本想獨立建立新專案的路徑不一定能走通。最後採取隔離既有專案的方式，保留專用資料區與驗證入口，不去改動原有公開看板。這是一個務實的折衷：它讓工作繼續，也提醒人們共用資源不是免費的，未來仍要管理容量、備份與責任邊界。

這一頁留下的判斷：工具選擇要從資料關係與風險出發，不要從流行名稱或個人偏好出發。

成員確認與衝突處理，才是分組平台的核心

分組平台真正難的部分，不是讓學生送出一個組名，而是處理送出之後的世界。學生可能選錯人、有人尚未同意、同一個人被不同組申請、有人中途退出、教師需要強制調整，或某個組別根本沒有完成確認。若系統只提供一個成功或失敗的按鈕，教師最後還是要把所有例外搬回私人訊息和試算表。

比較清楚的設計，是把申請、成員確認與教師核定分成不同狀態。學生知道自己的申請在哪一階段，也知道如果有人未確認，下一步是等待、提醒還是撤回。教師看到的不是一張混在一起的總表，而是待處理、衝突、已核定與需要協助的清單。這些狀態本身就能降低很多來回詢問。

但狀態越細，越不能只在後台存在。學生端要用人看得懂的語言說明目前狀況，例如「等待某位成員確認」或「教師正在處理重複申請」，而不是顯示一個只有開發者看得懂的代碼。學生也需要知道錯誤能否撤回、何時截止、換組後舊紀錄會怎麼處理。

這一頁留下的判斷：權限設計與補救設計是一組，只有禁止沒有補救的系統，最後會把壓力推回教師。

歷史不能被現在的組別覆寫

浮動分組帶來一個很容易被忽略的問題：現在的組別和過去的合作不是同一件事。若學生今天換組，系統把所有舊資料都更新成新組，未來就無法回答「上一輪互評時，這位學生和誰合作」。如果教師要處理申訴、了解合作脈絡或檢查評量公平性，這個缺口會變成非常大的困難。

因此平台需要保存有效期間與評量名單快照。有效期間記錄一段合作關係何時開始、何時結束；快照則在某次互評或作業開始時，固定當時的評量對象。之後即使成員調整，舊評量仍然可以對應回當時的情境。這不是要把系統做得複雜，而是承認教學活動本來就發生在時間裡。

這種設計也讓教師比較容易向學生說明：換組不會抹掉已經發生的合作，新的分組會影響後續活動，但不會偷偷重寫過去。學生不需要每次重新輸入隊友，系統從教師核定的資料產生對象；如果資料錯了，教師有一個明確的位置可以修正，而不是要求學生自行猜測如何改。

這一頁留下的判斷：只要課程會變動，就要在設計之初預留「回頭解釋過去」的能力。

互評不是把同學變成彼此的分數機器

互評功能很容易被理解成「讓學生互相打分，再自動算出成績」。這種想法很直觀，也最容易工程化；但在教學上，互評的價值可能更接近合作證據與反思線索。學生能否描述具體行為、指出自己看到的協作、理解不同角色的貢獻，往往比一個漂亮的平均數更有意義。

因此後來把個人反思、同儕互評與教師判斷分開。某一門課的個人反思可能有正式配分，同儕互評也可能只作為回饋或輔導線索；不能因為平台有一個評分欄位，就自行推定它一定要進入總成績。BARS 可以幫助學生描述行為層次，但不能替教師制定整門課的成績政策。

平台的責任，是讓評量對象正確、讓學生有草稿與一次修正的機會、讓提交後有回條、讓教師看到低樣本或異常情況，並且避免任何人任意改寫歷史。至於如何解讀結果，仍要回到課程規則、合作情境與教師的專業判斷。

這一頁留下的判斷：平台可以計算，但不能因為能計算，就自動把所有計算結果變成成績。

白板有兩種世界：教師要管理，學生要閱讀

白板一開始很容易做成「大家都能看到的公告牆」。但教師真正需要的是一個管理工具：建立公告、編輯內容、調整順序、設定發布、清理附件、確認最近資料、刪除不再使用的項目。學生需要的則是另一件事：快速看懂目前最重要的公告，不被後台選項、草稿與過期內容干擾。

所以教師端與學生端不能只靠同一個頁面加幾個按鈕解決。教師端要先看摘要和狀態，再進入全文編輯；學生端要直接看到已發布、排序清楚、手機能讀的內容。刪除也要說清楚是隱藏、取消發布、移除附件，還是永久刪除。模糊的動詞，會讓教師不敢操作，也讓排錯變得困難。

白板的修改歷程同樣說明，介面問題常常不是美觀問題。Loading 太慢，可能是查詢太多、附件處理不當或沒有先顯示摘要；無法刪除，可能是權限、資料關聯或前端沒有讀回實際錯誤。要先找出原因，再決定是修介面、改資料流程還是調整教師操作方式。

這一頁留下的判斷：當同一個工具同時服務兩種角色時，先分清楚兩種角色各自要完成的最小任務。

Loading 太慢與刪不掉，教會人不要只看成功畫面

在實際使用中，最令人挫折的往往不是大功能沒有完成，而是小動作不可靠。頁面轉很久、按下刪除沒有反應、剛改好的內容重新整理又消失，這些問題會讓教師懷疑整個系統。開發者若只在自己的測試資料上看到成功，就很容易以為使用者只是操作不熟。

後來逐漸形成一個排錯順序：先確認使用者看見的狀態，再確認請求是否送出，再確認服務端是否接受，最後確認重新讀回的資料是否真的改變。任何一層失敗，都要留下可讀的說明。若服務端已經成功，但前端沒有更新，問題不是資料沒有寫入，而是畫面沒有反映結果；若請求根本沒有送出，就不應該先去改資料庫。

這種「讀回優先」的習慣後來也被帶到教材、Quiz、分組與公開網站。建立、修改、發布、部署都不能只看按鈕顯示成功；必須重新讀取目標位置，確認內容、狀態與連結真的存在。它增加了幾分鐘，卻大幅降低「以為完成，隔天才發現沒有」的風險。

這一頁留下的判斷：沒有讀回的成功，只是一個暫時的畫面，不是可交付的證據。

新商業模式研究與實戰：系統開始碰到真正的責任

「新商業模式研究與實戰」讓整個問題往前走了一步。這門課不只要學生讀案例、做研究、形成商業模式，也會接觸一些不適合直接公開的版權資料。此時網站不再只是教材入口，而開始承擔一個小型派發系統的角色：誰可以拿到檔案、何時拿到、拿到的是哪個版本，以及教師事後能不能知道發生了什麼。

這個需求和一般下載連結很不一樣。若把檔案放在公開頁面，任何人都可以轉發；若把所有流程都交給人工，又很容易漏寄、寄錯或無法追蹤。於是 access code 的想法出現了：讓學員以個別代碼進入或下載，教師保留一個可以檢查派發狀態的地方。

但 access code 並不等於完整的權限管理。它只是把「誰可以取得」往前推一步，後面仍有帳號建立、代碼保存、補寄、失效、下載紀錄、版權範圍、資料保留與申訴問題。如果沒有把這些事情分開，系統看起來會很方便，責任卻可能比原本更不清楚。

這一頁留下的判斷：教學網站一旦處理版權與身份，就已經是治理問題，不只是介面問題。

access code 的邊界：方便不能取代最小權限

設計 access code 時，最容易犯的錯是把代碼當成萬用鑰匙。只要有代碼就能看全部資料、代碼永不失效、所有人共用一個代碼，這些做法雖然最快，卻無法回答教師最基本的問題：哪位學員被授予哪一個檔案？代碼是否已使用？如果有人離開課程，權限怎麼停止？

比較穩健的概念，是把公開內容、教師後台、學員身份、版權檔案與下載紀錄分開。公開網站只說明課程和使用規則；教師後台查看派發狀態；學員只看得到自己被授予的資源；真正的檔案放在適當的受控位置；紀錄只保留完成管理所需的最小資訊，不把明文密碼或不必要的個資寫進程式與版本庫。

這裡還需要接受一個不舒服的事實：下載紀錄不一定能證明資料被讀完，也不能自動證明沒有轉發。它只能成為管理線索。教師可以看到派發與下載狀態，卻不應把這些狀態包裝成過度精確的監控結論。

這一頁留下的判斷：權限系統的成熟度，表現在它知道哪些資料不該被看見，以及哪些結論不能由紀錄推導。

派發與監控：最值得自動化的是提醒，不是最後裁決

當教師需要派發一批受控檔案時，最合理的自動化通常不是「系統自己決定誰可以拿什麼」，而是把已經確認的名單與資源，穩定地轉成一批可追蹤的派發工作。系統可以產生待派發清單、檢查缺漏、記錄成功或失敗、提醒未完成項目，讓教師不必靠記憶逐封追蹤。

真正需要小心的是批次失敗。某一列可能是既有帳號、某一列資料不完整、某一封通知被拒收，或教師後來決定補寄。若系統把整批當成一個成功或失敗，教師會不知道要重做全部還是只處理其中幾列。因此每個項目需要自己的狀態與嘗試次數，批次本身也要有封存與回看。

教師後台除了看數字，也要能看到下一個行動：哪些等待教師確認、哪些需要補資料、哪些已成功、哪些已失敗、哪些不能重寄。這些畫面不應該鼓勵教師長時間盯著監控，而應該把注意力集中到少數真正需要判斷的例外。

這也說明為什麼「有後台」不代表已經完成正式營運。還要檢查角色權限、備份還原、資料保留、補寄規則、停止條件、實際小班試辦與版權責任。這些是上線前的門檻，不是日後有空再補的裝飾。

這一頁留下的判斷：監控畫面最有價值的用途，是幫教師找到需要處理的例外，而不是製造一種一切都被完全控制的錯覺。

MVP 應該放棄什麼，才有可能真的用起來

經過這些反覆修改後，MVP 不應該被理解成「功能比較少的完整版」。它比較像一個能在真實課堂中跑過一輪、教師知道怎麼救回來、學生知道下一步、資料沒有失去來源的最小閉環。它必須小到可以測試，也必須完整到能暴露真正的問題。

以教材工作流來說，第一個 MVP 可能只需要一個課程週次、一份來源登錄、一個本地入口、一份教師核定的教材、一個簡單作業、一個可回看的提交方式，以及一份人工覆核清單。逐字稿可以先只處理一週，Quiz 可以先做一個測試週，白板可以先完成公告讀取與教師編輯，不必一開始就做全期自動化。

以分組與互評平台來說，第一個 MVP 也不應承諾自動找最佳組合、自動排名、自動扣分、跨校整合或研究級分析。先把名冊、申請、確認、教師核定、合作期間、評量名單快照、草稿、送出與讀回做穩，才有資格討論更大的功能。以受控檔案派發來說，先把一小批資源的授予、下載、補寄與停止流程跑通，比先做複雜的推薦引擎更有價值。

這一頁留下的判斷：MVP 的目的不是證明可以做大，而是讓教師知道下一個真正值得解的問題是什麼。

教師需要掌握哪些技術能力

走到這裡，會發現教師不需要把每一種技術都學到專業工程師的深度，但必須具備足以管理風險的基本能力。第一是資料能力：知道來源在哪裡、版本如何辨識、哪些資料可以公開、哪些資料只能留在私人工作區。第二是流程能力：能把一個大任務拆成輸入、處理、輸出、驗證與停止條件。

第三是閱讀能力。教師不一定要自己寫完整的前端或後端，但要能看懂一個頁面在做什麼、資料如何流動、錯誤訊息代表哪一層出問題、某個檔案是原稿還是產生物。第四是測試能力：能用一個正常案例、一個錯誤案例、一個空資料案例與一個權限案例，檢查系統是否真的符合預期。

第五是判斷與溝通能力。要能清楚告訴 AI 哪些是正式規則、哪些是想法、哪些不能猜；也要能告訴 Reviewer 哪些地方要嚴格驗證、哪些地方只是風格偏好。最後是版本與交接能力：知道目前哪一版可用、哪一版只是草稿、下一個人要從哪裡開始，而不是把所有希望都放在「下次再說」。

這一頁留下的判斷：教師的技術能力核心不是親自完成所有程式，而是能在關鍵位置提出正確問題並拒絕沒有證據的結論。

最昂貴的不是工具費，而是持續做決定的思維能量

這整段歷程最容易被低估的成本，是教師必須持續做決定。每次工具回傳，都要問它有沒有讀對來源；每次文件完成，都要問是否符合這一週；每次功能上線，都要問學生能否理解；每次資料進入系統，都要問權限是否適當；每次 Reviewer 通過，都要問教師是否真的核定。

當工作同時在 ChatGPT、Codex、Work、Drive、Notebook、Teams、GitHub 與外部服務之間流動，思維能量很容易被切碎。人會因為想保留上下文，而把提示寫得越來越長；又因為提示太長難以驗證，開始新增摘要；摘要又和原文產生落差，於是需要再建立索引。這不是懶惰，而是人試圖用文件補回工作記憶的自然反應。

比較可持續的方式，是固定每次工作只回答幾件事：目前目標是什麼？正式來源在哪裡？這一輪已經完成什麼？哪一個問題被證明不能用原方法解？目前最小的下一步是什麼？若這五件事沒有寫清楚，就先不要繼續擴大範圍。這個節奏看起來保守，卻能避免在錯誤方向上累積大量產物。

這一頁留下的判斷：真正的工作流管理，是管理注意力、決策與恢復成本，不只是管理檔案。

何謂穩定：不是沒有錯，而是錯了知道怎麼停

一開始把穩定想成「流程可以一路跑完」。後來發現，真正可靠的系統一定會遇到例外；差別在於它是否在錯誤發生時停止、保留現場、提示下一步，而不是繼續往下生成一堆看似完整的結果。完全不停止的自動化，往往只是把錯誤藏到更後面。

因此每個工作包都需要幾個明確門檻：來源是否已確認，內容是否已經由教師核定，學生端是否能理解，測試資料是否包含錯誤情況，公開版本是否沒有敏感資料，實際讀回是否與預期一致。對網站來說，還要檢查內部連結、手機顯示、列印版、檔案存在、manifest 與交接資料。

對外發布也必須和內容完成分開。本機建置通過，不代表 GitHub 已同步；GitHub 已同步，不代表 Pages 已部署；Pages 顯示成功，也不代表公開網址讀到的是最新內容。這些步驟看似重複，其實各自回答不同問題。只有全部讀回，才有資格說發布完成。

這一頁留下的判斷：穩定的核心不是永遠不出錯，而是錯誤不會悄悄變成正式結果。

自動化真正適合放在哪裡

走過這些失敗之後，對自動化的看法不再是全有或全無。適合交給系統的，是重複、可規則化、出錯後能重做、結果可以讀回的工作，例如建立索引、計算雜湊、檢查連結、整理檔案清單、產生測試報告、標記待處理項目與通知教師有例外。

需要保留在人手上的，是會改變學生權益、課程意義、資料權限與對外責任的決定。例如本週到底要教什麼、某段教材是否符合學生程度、逐字稿是否可以正式發布、AI 建議是否足以作為評量證據、某位學員是否應取得版權資料、同儕互評是否應影響成績。這些決定可以被系統整理資訊，卻不能被系統默認完成。

介於兩者之間的，是「人先決定規則，系統負責依規則執行並回報例外」。這可能是最值得發展的區域。它不如全自動化那麼有戲劇性，卻比較符合教師每天面對的真實世界：規則會調整，學生會遇到例外，來源會更新，平台會改版，而教師仍然要對最後的教學結果負責。

這一頁留下的判斷：自動化的終點不是無人化，而是讓人更有能力處理真正重要的例外。

這不是一個完成的系統，而是一種比較不容易失控的工作方式

從《陸王》到《未生》，從個案教材到企業授課，再到管理學課程的每週教材、作業、Quiz、逐字稿、分組、互評、白板與受控檔案派發，scope 之所以變大，不是因為一開始就有一個完美藍圖，而是每個現場都讓原本被忽略的責任浮現出來。學生需要入口，教師需要回讀，內容需要來源，系統需要補救，版權資料需要邊界。

這些修改有時候很痛苦，因為它們常常意味著承認先前的做法不夠穩定：過長的提示詞讓學生負擔太大，檔名規則不能代替內容判斷，表單不能保存浮動分組歷史，登入成功不等於課程權限，技術測試通過不等於教師核准，公開頁面能打開也不等於所有資料都適合公開。可是正是這些承認，讓後來的流程比較誠實。

如果下一位教師想建立類似工作流，最實際的起點不是先買更多工具，也不是先要求 AI 一次完成整學期。可以先選一個真實週次、一個可控案例、一個明確產物，建立來源、做一次人工版本，再讓 AI 介入其中一小段。每做完一步，就留下它的來源、狀態、失敗、修正與下一個門檻。等第一個小閉環穩定，再決定要不要擴大。

最後真正留下的，不是某個模型、某個平台或某張架構圖，而是一種習慣：先問這件事為誰服務，接著問它的來源與風險，再問哪一部分可以自動化，最後保留一條人能看懂、能介入、能收回的路。這套習慣仍然需要時間，也不會讓工作變得完全輕鬆；但它讓下一輪不必再從混沌開始。

這一頁留下的判斷：穩定不是終點；它是下一次修改可以安全開始的地面。