React 課綱設計報告 II：AI 輔助改變了什麼——從「寫 React」到「驗收 AI 生成的 React」

• 07 July 2026
• React,
• React Native,
• Course Design,
• Curriculum,
• AI-assisted Development,
• Education

React 課綱設計報告 II：AI 輔助改變了什麼

本文是系列第三篇。第一篇 《React 課綱設計報告：從 143 個 App 反推該教什麼》 回答「該教哪些」，第二篇 《143 個練習 App 完整圖鑑》 是配套的練習目錄。
這篇回答的是：同一份課綱，加上 AI 輔助開發之後，哪些結論要修、哪些不用動。

〇、執行摘要（TL;DR）

1. 「應用反推」的方法論不用推翻，但反推的終點位移了。
沒有 AI 時，反推鏈是「App 行為 → 需要的 React 觀念 → 教學順序」，因為學生要親手寫出每一行，「要會寫什麼」就等於「要教什麼」。有 AI 時，反推鏈變成「App 行為 → 需要的 spec → AI 生成 → 需要會驗收與修改什麼 → 才決定要教什麼」。很多觀念的出場理由從「因為要手寫」變成「因為要驗收」。

2. 三層邊界之上，多一層 Layer 4 — AI 協作能力。
原本的 Layer 1（React 核心）、Layer 2（Web 工具）、Layer 3（RN 平台專屬）全部保留，判準不變。新增的 Layer 4 不是 React 本身，但會改變每一層怎麼教。

3. React 核心不會少教，但教的姿態變了。
從「會不會手寫」變成「看不看得懂、改不改得動、審不審得出問題」。Layer 1 那 20 個觀念一個都不能拿掉——它們正是 AI 最容易「寫出可跑但不穩」的地方。

4. 少教的是低價值手打流程，不是觀念。
boilerplate、重複表單欄位、靜態 card、假資料列表交給 AI；state 放哪裡、effect 該不該存在、component 邊界怎麼切，這些照教，而且權重上升。

5. 一句話：課綱要問的問題變了。
原本問「學生能不能寫出這個 App」；現在要問「學生能不能定義這個 App、讓 AI 產出初稿、判斷初稿哪裡錯、把它修成可維護的專案」。

一、反推鏈多了兩節

第一篇的核心主張：不要從「JSX → Props → State」順排課綱，要從「學生結訓能做出哪種 App」反推。這個邏輯在 AI 時代不變——變的是鏈條本身。

沒有 AI：

目標 App 行為
    ↓ 拆行為
需要的 React 觀念
    ↓
排成教學順序

有 AI：

目標 App 行為
    ↓ 拆行為
需要的 spec（把行為寫成 AI 能執行的規格）
    ↓
AI 生成初稿
    ↓
需要會驗收、修改、整合什麼
    ↓
才決定要教什麼

多出來的兩節（寫 spec、驗收產出）不是額外的「AI 課」，而是每一個 App 練習裡都要走一遍的流程。

最典型的例子是 useEffect 的 dependency array：原本它的出場理由是「你要自己寫對才跑得動」，現在變成「AI 寫了，你能不能判斷它對不對、漏了什麼」。觀念沒變，考的能力變了。

二、新增 Layer 4：AI 協作能力

原本的三層邊界（第一篇第三節）完全保留：

Layer 1 — React 核心（必教，無條件）
Layer 2 — Web 常用工具（看時數與目標）
Layer 3 — RN 平台專屬（只在 RN 課程教）

往上疊一層：

Layer 4 — AI 協作能力（每一層的教法都受它影響）

Layer 4 的內容：

Prompting for code / explanation / refactor / test cases / debugging
Prompting for architecture alternatives
Reading AI-generated diffs
Rejecting wrong AI code
Constraining AI output with project rules（AGENTS.md）
Using AI inside Git / PR workflow

判準：Layer 4 不能獨立成一週教完。它像打字一樣是貫穿式能力——每個 App 練習都嵌一點，而不是開一堂「如何下 prompt」。

同時，原本三層的判準要微調：

三、L1–L5 每層的重心位移

五層能力地圖的結構不變，但每層多了一個維度：AI 生成可靠度。層級越低，AI 生成越可靠，教學重心越往「讀＋改＋驗」移；層級越高，AI 越不可靠，人工實作的教學價值反而保住了。

graph LR
    L1["L1 最小互動
AI 幾乎完美生成
重心：讀懂+驗收"] --> L2["L2 狀態複雜
AI 會生但架構常錯
重心：架構判斷"]
    L2 --> L3["L3 外部資料
AI 最常出錯區
重心：驗錯能力"]
    L3 --> L4["L4 大型結構
AI 產值最大區
重心：決策+整合"]
    L4 --> L5["L5 即時/裝置
AI 仍然薄弱
重心：傳統實作"]

    style L1 fill:#e0f2fe,stroke:#0369a1
    style L2 fill:#dcfce7,stroke:#15803d
    style L3 fill:#fef9c3,stroke:#a16207
    style L4 fill:#ffedd5,stroke:#c2410c
    style L5 fill:#fee2e2,stroke:#b91c1c

L1（Todo、Quiz、Counter）——AI 幾乎能瞬間生成。學習價值從「如何從零建構」轉移到「如何讀懂 AI 生成的程式碼、修改它、判斷它對不對」。JSX、Components、Props、useState 照教，但姿態從「教你寫」變成「教你讀＋改＋驗」。
AI 任務範例：AI 生成元件，學生檢查 props、state、event 設計是否合理。

L2（Shopping Cart、Kanban、Multi-step Form）——AI 能 scaffold 出結構，但狀態管理決策（useReducer vs useState、狀態放哪、derived state 怎麼算）是 AI 「看起來對但架構爛」的高發區。教學重心往架構判斷移動。
AI 任務範例：AI 生成 reducer，學生檢查 state shape、derived state、immutable update。

L3（Dashboard、Login、Search）——AI 擅長生 fetch + loading/error boilerplate，但 effect dependencies、race condition、cleanup、debounce 是 AI 最常出錯的地方。L3 的觀念因 AI 而變得更重要——學生要能驗出 AI 在這裡的錯。
AI 任務範例：AI 生成 data fetching hook，學生檢查 loading/error/empty、dependency、race condition。

L4（E-commerce、CMS、Admin Panel）——AI 發揮最大價值的區域。路由、巢狀版面、權限路由、DataTable 這些結構性工作 AI 能大量生成；但「全域狀態怎麼分層」「快取策略怎麼定」「哪些該抽成 reusable component」仍然是人的工作。
AI 任務範例：AI 生成 feature branch，學生檢查 routing、權限、快取、型別、測試。

L5（Chat、Map、Camera、Realtime Collaboration）——AI 在即時同步、裝置感測器、原生權限整合上仍然薄弱。WebSocket cleanup、useSyncExternalStore、虛擬列表效能、CRDT 衝突解決——AI 能給範本但很難給對的實作。L5 在 AI 時代保住了最高的教學價值。
AI 任務範例：AI 生成 socket / permission 程式碼，學生檢查 cleanup、lifecycle、平台 edge case。

附帶一提：同一層之內可靠度也有差。同樣是 L3，Weather App（API 串接＋條件渲染）AI 生成可靠度高；Search App（debounce + AbortController + race condition）可靠度低。老師挑 App 時可以同時考慮「逼出什麼觀念」和「AI 在這個 App 上會不會出錯」——故意挑 AI 會出錯的，驗收練習才有材料。

四、「果斷不教」清單逐條重審

第一篇的判準是「拿掉之後學生做不出指定 App 嗎？不影響就拿掉」。AI 時代判準要加一句：「拿掉之後，學生能驗收 AI 幫他做的 App 嗎？」用新判準重審：

五、作業型態：從一種變三種

原本作業只有一種：從零寫出來。AI 時代拆成三種，各有不可取代的功能。

型態一｜手寫作業（保留，放最前面）

用來確認學生真的建立了 React 心智模型。適合：useState、props、events、forms、lists、conditional rendering、immutable update。

這些不能一開始就交給 AI——否則學生只會貼 code，不會形成 React 的內部地圖。

型態二｜AI 生成 + 人類審查（新主軸）

例如：

請 AI 生成 Todo App，學生標註：
- 哪些 state 是必要的
- 哪些是 derived state，不應該存
- 哪些 component 拆得不合理
- 哪個 useEffect 不該存在
- 哪裡可能產生 bug

這比單純「叫學生寫 Todo」更接近工作現場。

型態三｜AI 生成壞 code，學生修（刻意設計）

老師刻意準備 AI 常見錯誤樣本：

useEffect dependency 錯誤
nested state mutation
props drilling 過深
RN FlatList 效能差的寫法
login flow 把 token 放錯地方
dashboard 沒處理 loading/error/empty
form validation 只做前端假驗證

學生任務不是「寫出來」，而是「診斷、修正、說明為什麼」。

六、速查表多兩欄：AI 可代勞 × 人必須審查

第一篇第六節的速查表原本是「App → 必教觀念 → 進階觀念」。AI 時代加兩欄，變成「App → 觀念 → AI 可代勞 → 人必須審查」。三個例子：

Todo App（L1）

React 核心：state、event、list、conditional rendering、immutable update

AI 可代勞：
- 生成基本 UI、CRUD function、localStorage persistence

人必須審查：
- 是否有 duplicated state
- 是否直接 mutate array
- key 是否穩定（不能亂用 index）
- component 是否過度拆分

Dashboard App（L3）

React 核心：useEffect、fetch、loading/error/empty、custom hooks、memoization

AI 可代勞：
- 生成 API service、table component、chart wrapper、loading skeleton

人必須審查：
- useEffect dependency
- race condition
- error handling 是否只是裝飾
- cache 策略
- server state / client state 是否混在一起

Camera / QR Scanner App（L4–L5，RN）

RN 主題：permission、camera module、app lifecycle、file upload

AI 可代勞：
- 生成相機畫面、permission request flow、upload function

人必須審查：
- permission denied 之後的 flow
- iOS / Android 差異
- app 進背景的行為
- 檔案大小與 upload failure
- 裝置沒有該 capability 時怎麼辦

這張表還有一個反向用法：每個 App 的「React 核心觀念」欄，同時就是「AI 生成這個 App 時最可能出錯的觀念清單」。第二篇圖鑑裡 Search App 標了 AbortController 和 race condition——那正是 AI 生成搜尋功能最容易漏 cleanup 的地方；Chat App 標了 WebSocket 和 cleanup——AI 生成的 socket 程式碼常缺 cleanup 導致記憶體洩漏。把圖鑑當成「AI 易錯點索引」用，型態三的壞 code 作業就有現成題庫。

七、三套方案怎麼調：時數不動，分配要動

三套方案（A: 24–30hr、B: 48–60hr、C: 60–80hr）的時數結構不用改，改的是模組內的時間分配。以方案 B 為例：

兩個新元素的嵌入位置：

• AGENTS.md（定義專案規則與 AI 工作方式）→ 嵌在 L4 大型應用結構。它只在 App 規模大到需要多人／AI 協作時才有意義，對應 E-commerce、CMS、Admin Panel 這批 App。
• Spec writing → 嵌在方案 B、C 的專案實作模組。第一篇說「專案導向是應用反推的自然落地形式」，spec-first workflow 就是同一個精神的 AI 版延伸。

注意：這兩個新模組塞不進方案 A。24–30 小時不夠支撐 spec + AGENTS.md + 核心觀念三者並存，硬塞會擠掉 Layer 1。方案 A 的 AI 元素以「讀＋驗收」練習為限。

課程順序：先心智模型，後 AI 加速

不要一開始就 AI-first。比較穩的順序：

Phase 1：不用 AI，建立 React 心智模型（型態一作業）
Phase 2：用 AI 生成小片段，學生審查（型態二）
Phase 3：用 AI 生成 feature，學生整合
Phase 4：用 AI 做 refactor / test / debugging
Phase 5：用 AI agent 做 issue → PR，學生 code review

AI coding agent 已經能開 PR、做 feature、跑任務（GitHub Copilot 官方文件已把它定位成涵蓋 code review、PR 管理、coding agent 的完整開發生命週期工具），但對 agent 產出 PR 的實證觀察也顯示：CI 不過、任務錯位、與既有程式碼衝突仍然常見。AI 可以進入工作流，但取代不了審查能力——這正是 Phase 5 要練的東西。

八、評量與老師角色

評量要多量什麼

原本評「能不能做出 App、能不能解釋概念」。加 AI 後要多評：

能不能把任務規格寫清楚
能不能限制 AI 不要亂改架構
能不能讀懂 AI 生成的 diff
能不能找出錯誤、要求 AI 補測試
能不能拒絕「看似能跑但架構錯」的 code
能不能把 AI 產物整合進既有專案

一個可直接用的 rubric：

老師角色的位移

原本：概念講解者、Demo 示範者、作業批改者
AI 後：架構守門人、錯誤樣本設計者、code review 教練、任務規格訓練者

老師最有價值的地方不再是「我比 AI 更快寫 component」，而是：

知道哪些 code 看起來對，但三週後會壞
知道哪些 abstraction 抽太早
知道哪些 useEffect 根本不該存在
知道哪些 state shape 之後會卡死
知道哪些 RN 寫法在模擬器可以、真機不行

九、少教什麼、不能少教什麼

會少教的——低價值手打流程：

一行一行打 boilerplate
手刻大量重複表單欄位
手刻靜態 card component
手刻假資料列表
手刻基本 CSS layout

這些交給 AI，學生負責規格、修改、抽象化。

不能少教的——正是 AI 最容易「寫出可跑但不穩」的地方：

state 放哪裡
什麼是 derived state
為什麼不能 mutate state
effect 什麼時候不該用
dependency array 為什麼會出 bug
component 邊界怎麼切
props API 怎麼設計
list key 為什麼不能亂放 index
loading/error/empty 為什麼是產品狀態
Context 不是萬用全域變數
RN 的裝置權限不是單純 API 呼叫

對照一下會發現：這張「不能少教」清單，幾乎就是第一篇 Layer 1 那 20 個觀念的展開。AI 沒有讓核心變少，它讓核心的「為什麼」變得更重要。

十、一句話結論

如果會議只剩 30 秒，請講這段：

AI 輔助不會讓 React 課綱變成「少教 React」。它讓課綱從寫 React 變成設計、審查、修正 AI 生成的 React。

「應用反推」的方法論不變，反推的終點位移：原本問「學生能不能寫出這個 App」，現在要問「學生能不能定義這個 App、讓 AI 產生初稿、判斷初稿哪裡錯、把它修成可維護的 React / React Native 專案」。

具體改四件事：三層邊界上疊一層 AI 協作層；L3 副作用與 L5 即時/裝置的教學權重上升；作業從一種變三種（手寫、審查 AI、修 AI 壞 code）；評量加入規格品質與 review 品質。時數結構不用動，Layer 1 那 20 個觀念一個都不能拿掉。

本文所有層級（Layer 1–3、L1–L5）、方案（A/B/C）與 App 引用均沿用系列前兩篇的定義：課綱框架見 《React 課綱設計報告》，App 難度與觀念對應見 《143 個練習 App 完整圖鑑》。把圖鑑的「React 主題」欄當成 AI 易錯點索引，是本篇建議的新用法。

• ← Previous
  143 個 React / React Native 練習 App 完整圖鑑：從行為反推學習重點