跨課程分組與互評平台：實作歷程與關鍵課訓

更新日期：2026-09-08（Asia/Taipei）

文件目的與閱讀邊界

這份文件不是單純的開發流水帳，而是把本平台從課程頁面需求、既有工具盤點、資料模型設計、Supabase 實作、Persona 測試、登入策略、發布及測試帳號驗證的變化串起來。每個轉折都記錄當時的理由、得到的好處、增加的代價，以及未來更精準的做法。

本文件依據目前對話、正式專案文件 PLAN.md、SOURCE_AUDIT.md、README.md、HANDOFF.md，以及開發期間的交接摘要整理。沒有讀取或複製正式學生逐筆互評內容；CM216 舊資料的輪次推估仍屬 inferred，不當作新系統的正式證據。文件中的「已完成」只指目前可由檔案、資料庫查核、測試或公開頁面讀回的事項；「建議」則不等同已實作。

一、先看結論：這個專案真正發生了什麼

這個專案不是把舊的 GMR、PEF 或 GAS 表單搬到 Supabase，而是逐步把「手動填表」改造成一個具有課程、學期、開班、分組有效期間、互評名單快照與權限邊界的資料系統。

目前已完成的核心版本可以支援：

• 多課程、多學期共用同一套資料模型。
• 浮動分組、分組申請、成員確認、教師核定與調組歷程。
• 依合作期間產生互評對象，並在開放前凍結名單。
• 繁中／英文五面向 BARS、自評、同儕評量、觀察不足及理由。
• 互評草稿、冪等提交、一次修改、收件回條、教師查核、低樣本回饋保護與匯出。
• 學生端與教師端的帳號／密碼登入，且教師權限不由學生自行切換取得。

但目前仍是「可進入小班試辦」的核心版本，不是正式全面收件服務。正式全班名冊、學校核准的批次帳號／密碼派發、真實小班試辦、約 60 人併發、備份還原、保存期限及申覆規則仍是正式啟用前的閘門。

二、依時序整理

1. 課程頁面前導：先處理分組與 AI 政策，不急著建系統

時間：2026-09-02 前後

最初的工作不是建立平台，而是修改 CM108G 管理學課程首頁，說明本課程的分組方法、Teams／Gemini Notebook 使用方式、AI 使用政策及課程週次。指定的學生簡報提供了本課程的實際背景：61 位學生、37 位國際學生、13 個國籍，以及短任務、正式分組、調整窗口與專案檢核等安排。政策來源則要求依教師指示，在不同活動中區分禁用電子設備、禁用 AI、可使用 AI 及必須使用 AI。

這一階段也處理了課程日期與彈性教學週的解釋：假期週標為自主學習；12 月 28 日及 1 月 4 日仍照常上課；期末考維持在 12 月 21 日。另將 NotebookLM 統一改為 Gemini Notebook，刪除「課前 NotebookLM 學習記錄」10%，加回每週個案作業與 AI 對話記錄；9 月 6 日的項目標示為課堂展示，不是學生真正要繳交的作業。

這個轉折的意義：先把課程規則說清楚，避免之後把工具功能誤當成課程政策。好處是學生看得到學習流程與責任邊界；代價是課程頁面變得更複雜，且「課程頁面上的分組說明」仍然無法處理動態名冊、歷史分組或互評收件。

後來得到的課訓：課程網站適合公布規則與入口，不適合直接承擔學生資料、分組判定及互評收件。政策文字與操作系統應分層設計。

2. 從舊課程工具找到真正可重用的資產

時間：2026-09-02 至 2026-09-06

使用者提出國際企業管理課程網站作為來源，要求取用兩個工具：小組分組清單與 Peer evaluation。查核後確認：

• GMR 提供課程與學號驗證、成員清單與分組登錄經驗。
• PEF 提供自評、同儕評量、文字回饋、繁中／英文題目與五個 BARS 面向。
• GAS v1 提供 RoundWindows、Roster、Submissions、Ratings、Audit、一次修改與寄信概念。
• CM216 分析提供輪次整理、個人彙整與訊號判讀的經驗，但部分輪次是依日期間隔或缺少組名推估，不能直接當成新系統的可靠事實。

同時也發現舊做法的結構性限制：GMR／PEF 讓學生手動填寫隊友，GAS 的部分版本固定四位隊友或固定人數，部分表單用 no-cors 傳送而無法可靠確認後端是否真的收件。這些資產適合重用題項設計與使用經驗，不適合原樣重用資料流程。

轉折決策：不做「舊表單搬家」，改做一套能把分組歷程與互評名單真正連起來的跨課程資料模型。

得到的好處：保留既有教師熟悉的題項與流程，又解除固定人數、手填隊友及單一課程的限制。增加的代價：需要處理資料庫權限、名單快照、調組歷史、版本、備份及多課程隔離，開發複雜度遠高於一份表單。

3. 先寫完整計畫，再決定第一版範圍

時間：2026-09-02 至 2026-09-06

因為使用者明確要求「審慎規劃」及可長期累積資料，計畫先處理來源邊界、資料治理、角色權限、資料生命週期、容量、備份、驗收與停止條件。計畫將第一版收斂在：名冊、浮動分組、成員確認、教師核定、互評快照、雙語 BARS、自評／互評、教師查核與匯出。

刻意不把以下項目塞進第一版：自動最佳分組、學生排行榜、自動扣分／排名、Teams 作業評分 API、外部 AI 自動判讀、短問卷、研究模組及未核准的歷史逐筆資料移轉。

轉折決策：用可驗收的核心閉環取代「一次完成所有整合」的願望清單。

優點：降低第一版的資料與治理風險，讓每個功能都有明確通過條件。缺點：第一版看起來不像完整的學習分析平台，研究追蹤與自動化便利性必須延後。

後來得到的課訓：複雜教育系統最重要的不是功能數量，而是哪些資料可以被可靠解釋、誰可以看、錯了怎麼補救，以及什麼情況必須停止收件。

4. 想建立獨立 Supabase 專案，但被方案限制迫使改變

時間：2026-09-06 至 2026-09-07

原先的理想方向是建立第三個獨立 Supabase 專案，避免與其他服務混淆。但 537SONIC Free 組織已有兩個啟用中的專案，建立第三個專案被 2 project limit 阻擋。

轉折決策：依使用者最新指示，改用既有的 537SONIC's Project，並在其中以私有 course_team／course_team_private schema、專用 public.ct_* RPC、RLS 及直接表權限撤銷來隔離本平台，不修改既有 public 看板系統。

優點：不必升級方案、不必刪除或暫停既有專案，能立即繼續建置；資料模型與 migration 仍可獨立維護。代價：帳單、流量、管理責任與故障影響面仍不是完全獨立；如果既有看板流量暴增，平台會受到同一專案或組織限制的牽連。

精煉後的原則：schema 隔離可以降低資料誤讀與權限混用，不等於完整的資源、帳單或運維隔離。日後若正式班級數量、備份責任或流量風險增加，仍應重新評估獨立專案，而不是把目前的折衷永久化。

5. 把浮動分組與互評真正接在一起

時間：2026-09-06 至 2026-09-07

核心資料設計由「目前在哪一組」改為「在什麼期間、因什麼分組用途、和誰合作」。分組用途與正式 membership 分開；membership 保存有效期間；調組時關閉舊紀錄、建立新紀錄；互評開放前建立 assignment snapshot。

快照保存評量人、受評人、當時組別、來源 membership、合作期間、量表版本、自評狀態及規則依據。因此，後來換組不會重寫已經發生的互評對象。

優點：能處理活動分組與正式分組並存、同一學期多次合作、調組及事後追溯。代價：教師必須先確認觀察期間、分組用途與名單，再開放互評；學生也不能自行修改評量對象。

關鍵決策：評量對象由伺服器依名冊與合作期間產生，不再信任學生手動輸入隊友。這是從舊 PEF／GAS 最重要的結構性改進。

6. 互評的成績用途被重新定義

時間：2026-09-06 至 2026-09-08

初始設計已區分互評資料與課程成績，但使用者進一步確認：CM108G 已公告「個人反思與同儕互評」占 5%，實際希望把權重放在個人反思；同儕互評改為 0%，主要用來檢查學習責任、小組貢獻及提醒學生完成填答。

轉折決策：CM108G 採「個人反思 5%、同儕互評 0%」；互評只作教師判讀與追蹤資料，不由系統自動改分、排名、扣分或貼標籤。Teams 作業的四項 Rubrics 各 25 分，也不與平台五面向 BARS 混成一個分數。

優點：遵守已公告的成績政策，降低學生因害怕報復或分數處罰而操弄互評的誘因，也讓教師能把互評當作對話與追蹤線索。代價：部分學生可能認為互評「不算分」就不重要，因此需要清楚說明它的學習責任、完成要求及教師使用方式。

未來精煉：每門課若要改變互評的成績用途，必須獨立公告權重、缺交處理、申覆與教師採用紀錄；不能因平台共用就默默沿用 CM108G 的 0%。

7. 從功能測試轉向學生 Persona 的視覺與語言測試

時間：2026-09-07 至 2026-09-08

第一輪不只檢查 RPC 與交易能否通過，也以「第一次接觸互評、對概念不熟悉的大一學生」角度檢查：登入前是否理解成績用途、匿名程度、教師可見範圍、分組期限、下一步、選錯組員如何補救、手機畫面是否能繼續操作，以及逐位評量時是否知道自己填到哪裡。

檢查後新增或修正：

• 登入前明示成績、匿名與可見範圍政策。
• 修正桌面標題換行，增加手機「前往登入表單」入口。
• 把學生端狀態翻譯成可理解的下一步。
• 顯示分組用途、期限、名單搜尋與已選摘要。
• 提供申請撤回與重新提出路徑。
• 加入伺服器互評草稿、送出前逐人完成總覽及回收狀態。

優點：把「能操作」提升為「學生知道自己正在做什麼」。代價：文案、狀態、錯誤訊息與斷點都需要視覺驗收，測試時間增加。

關鍵課訓：教育平台的主要錯誤不一定是程式例外，也可能是學生在正確畫面上做出錯誤理解。Persona 測試應成為每次介面改版的固定驗收，不是只在第一版做一次。