他們第二週就發現了我沒看到的 bug
Sean 加入專案的第二週，在測試朗讀功能時回報了一個問題：「某些字的注音顯示不對」
我一開始以為是小 bug，他繼續追，發現這不是顯示問題 — 是破音字處理的根本邏輯有缺陷，這個問題存在於系統從第一天就有的核心模組裡，我開發了三個月都沒注意到
因為我每次測試用的都是同一批文章，他用了不同的
這不是他厲害（雖然他確實不錯），這是 PBL 的設計在起作用：當你把真實的問題交給學生，他們會從你沒想過的角度去碰它
為什麼要帶實習生？
先說背景
我在做一個叫 LingoLeap 的中文閱讀學習平台，用 AI 幫助閱讀困難的孩子練習朗讀和理解，技術棧是 React + FastAPI + GCP，AI 用 Vertex AI Gemini 做蘇格拉底式對話
開發團隊只有我一個人，靠 Claude Code 做 AI 輔助開發，一個人可以交付整個產品 — Demo 4 那次，一個 session 合併了 44 個 PR
所以問題來了：既然一個人 + AI 就能交付，為什麼還要帶實習生？
兩個原因
第一，這個平台的目的是教育，如果做教育產品的人自己不願意教人，那這個產品的說服力在哪？
第二，我想驗證一件事：AI 時代的 PBL 長什麼樣子？
PBL 不是口號 — 7 個元素的對照
PBL（Project-Based Learning，專題式學習）有很多人在講，但大部分的「PBL」是這樣的：老師設計一個假題目，學生做一個會被丟掉的報告，然後打分數
PBLWorks（前 Buck Institute）定義了 Gold Standard PBL 的 7 個設計元素，我拿來對照我們的實習生專案：
| Gold Standard 元素 | 我們怎麼做 |
|---|---|
| Challenging Problem | 「怎麼讓閱讀困難的孩子學會朗讀？」— 真實社會問題 |
| Sustained Inquiry | 6 個月持續開發，不是一次性作業 |
| Authenticity | 真 GitHub Issue、真用戶（老師+學生）、真 Production 部署 |
| Student Voice & Choice | 自己選 Issue、自己決定解法、PR 是自己寫的 |
| Reflection | 每週 weekly meeting 回顧 + Skill Tree 自我追蹤 |
| Critique & Revision | Code Review = 真實的 mentor 回饋循環 |
| Public Product | GitHub contribution graph — 可以放進大學備審 |
7 個全中，設計課程時我沒有特別對照這個框架 — 做法來自這些年在教育科技領域帶人的經驗，後來為了演講去找文獻，才發現學術框架跟實務做法有很高的對應，完整的論文對照整理在另一篇文章
學術研究怎麼說？
2025 年有兩篇重要論文直接支撐這個做法
MDPI Education Sciences（2025） 調查了 300 位教師，根據教師評估，AI 輔助的 PBL 比傳統 PBL 效果顯著更好，效果量 Cohen's d = 1.30 — 這是「大效果」，AI 最大的價值不是取代老師，而是提供個人化學習路徑和持續回饋
Frontiers in Education（2025） 在程式教育中實測 AI + PBL，發現：
- 學生投入度（engagement）：η² = 0.694
- 內在動機（intrinsic motivation）：η² = 0.690
- 學業成就（academic achievement）：η² = 0.519
η² 超過 0.5 代表超過一半的變異量可以歸因於 AI-PBL 介入，這不是微小差異，是巨大差異
課程設計：四層爬坡
我幫兩位實習生 — Ryan 和 Sean — 設計了四層漸進式課程，每一層都是真實的 GitHub Issue，不是練習題
Tier 1：Bug Fix Challenge
最安全的起步，5 個真實的 bug，每個都有明確的重現步驟和預期行為，學的是：讀懂別人的 code、用 Git 操作、發 PR、接受 Code Review
Ryan 第一週就合併了 2 個 PR，而且是一次過審
Tier 2：UX Improvement
開始碰 UI，5 個改善任務，包含 RWD 適配和 WCAG 無障礙，學的是：讀設計規範、理解使用者需求、寫跨瀏覽器的 CSS
Tier 3：Feature Development
獨立開發功能，4 個任務，包括自己寫 Acceptance Criteria（用 Given/When/Then 格式），學的是：從需求到實作的完整流程
Tier 4：Technical Deep Dive
追蹤資料流、寫技術文件、做 Code Review、教別人，學的是：系統思維和知識傳遞
不打分數 — 用 Skill Tree 追蹤成長
傳統教育用分數，我用 Skill Tree
20 個技能，600 總 XP，分佈在四個 Tier，每個技能有明確的解鎖條件（通常是完成某個 PR 或通過某次 Code Review）
到 3 月 13 日的進度：
- Ryan：6/20 技能，85 XP — Tier 1 全通，開始 Tier 2
- Sean：10/20 技能，215 XP — Tier 1 + 大部分 Tier 2，開始 Tier 3
我還做了互動式的 Skill Tree 網頁，可以切換兩人的檔案，他們每週五更新自己的進度
為什麼不打分數？
因為分數是終點，Skill Tree 是地圖，分數告訴你「你考了幾分」，Skill Tree 告訴你「你在哪裡、接下來往哪走」，而且它永遠不會滿 — 你可以一直往上
AI 在這裡扮演什麼角色？
這裡有兩層 AI 的運用，而且交織在一起
第一層：平台本身用 AI 教閱讀 Vertex AI Gemini 驅動蘇格拉底式對話，用「溫暖但堅定」的語氣引導學生思考，AI 做即時朗讀錯誤偵測（LCS diff 演算法）和流暢度分析（CPM 計算）
第二層：開發過程用 AI 輔助 我用 Claude Code 做主力開發，一個人可以交付整個產品，這讓我有時間當 mentor，而不是一直在趕 code
這兩層加在一起，創造了一個在學術上幾乎沒人做過的模式：
平台用 AI 教閱讀 × 開發過程用 AI 教程式 = 雙層 AI-PBL
而且最關鍵的是：專案不是模擬的，不是練習題，是真正在 Production 上運作的教育產品，學生改的 code，真的會被老師和學生用到
減法開發 — AI 開了 400+ Issue，用人腦判斷必要性
在 3 月 13 日的 weekly meeting 裡，我們討論了一個有趣的現象
在 AI 輔助開發的過程中，系統累積產生了 400 多個 GitHub Issue，從 bug、改善建議、到架構重構，什麼都有
如果全做，要做到明年
所以我教實習生的一件事是：不是所有 Issue 都要做，判斷「什麼不做」比「做什麼」更重要
這就是「減法開發」，AI 很擅長產出，但不擅長判斷價值，人的角色是篩選、排序、決定方向
這個觀念，對剛開始寫程式的高中生來說，可能比任何技術技能都重要
他們帶走了什麼？
不是證書，不是分數
GitHub contribution graph — 真實的綠點，代表真實的貢獻
Skill Tree 截圖 — 20 個技能的進度，每一個都有對應的 PR 和 Code Review 紀錄
可以放進備審的作品集 — 「我參與開發了一個真正在學校使用的 AI 閱讀平台」比任何專題報告都有說服力
但最重要的是一個認知的轉變：
程式不是考試科目，程式是解決真實問題的工具，而 AI 是讓你能更快解決問題的加速器
Ryan 和 Sean 在這 6 個月裡學到的，不是「React 怎麼寫」或「Git 怎麼用」，他們學到的是：面對一個你沒見過的問題，怎麼拆解它、怎麼找資源、怎麼求助、怎麼交付
這才是 PBL 真正在教的東西
而 AI 讓這一切變得可能 — 不是因為 AI 替代了學習，而是因為 AI 讓一個人有能力同時當架構師和 mentor
後記：寫給想試的人
如果你也想用這個模式帶學生或實習生，幾個建議：
Issue 要真的 假題目學不到真東西，讓他們碰真實的 codebase，就算一開始會害怕
Code Review 要認真 不是蓋橡皮章，具體說哪裡好、哪裡可以改、為什麼，這是 PBL 裡 Critique & Revision 最強的實踐方式
Skill Tree > 分數 讓學生看到自己在哪裡、還能往哪走，比給一個數字有意義得多
AI 是你的槓桿，不是學生的捷徑 你用 AI 加速開發，省下來的時間拿去 review 他們的 PR、跟他們討論設計決策，別讓學生用 AI 交差 — 那就失去 PBL 的意義了
降低門檻，不是降低標準 Tier 1 從簡單的 bug fix 開始，但 Code Review 的標準不降，門檻低讓他們敢踏進來，標準高讓他們真的學到東西
參考文獻
- MDPI Education Sciences (2025) — 10.3390/educsci15020150
- Frontiers in Education (2025) — 10.3389/feduc.2025.1674320
- PBLWorks Gold Standard PBL — pblworks.org