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

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

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

〇、執行摘要（TL;DR）

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

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

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

4. 少教的是價值較低的手動輸入流程，不是觀念。
樣板程式碼、重複的表單欄位、靜態卡片、假資料列表可交給 AI；state 該放在哪裡、effect 該不該存在、元件邊界怎麼切，這些仍然要教，而且權重更高。

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

一、反推鏈多了兩節

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

沒有 AI：

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

有 AI：

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

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

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

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

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

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

往上疊一層：

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

Layer 4 的內容：

用提示詞要求程式碼、說明、重構、測試案例或除錯
用提示詞要求不同的架構方案
閱讀 AI 產生的差異內容（diff）
拒絕錯誤的 AI 程式碼
透過專案規則（AGENTS.md）限制 AI 的產出
在 Git / PR 工作流程中使用 AI

判準：Layer 4 不能獨立成一週教完。它像打字一樣，是貫穿整門課的能力——每個 App 練習都融入一點，而不是另開一堂「如何下提示詞」。

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

三、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 能建立初步架構，但狀態管理決策（useReducer 與 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、依賴關係與 race condition。

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

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

附帶一提：同一層的可靠度也有差異。同樣是 L3，AI 產生 Weather App（API 串接＋條件渲染）的可靠度較高；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——否則學生只會貼上程式碼，無法建立 React 的心智模型。

型態二｜AI 產生 + 人工審查（新主軸）

例如：

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

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

型態三｜AI 產生有問題的程式碼，學生修正（刻意設計）

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

useEffect 依賴關係錯誤
nested state mutation
props drilling 過深
RN FlatList 效能差的寫法
登入流程把 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 函式、localStorage 持久化邏輯

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

Dashboard App（L3）

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

AI 可處理：
- 產生 API 服務、表格元件、圖表封裝元件與載入骨架

人必須審查：
- useEffect 的依賴關係
- 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 可處理：
- 產生相機畫面、權限請求流程與上傳函式

人必須審查：
- 權限遭拒後的流程
- iOS / Android 差異
- app 進背景的行為
- 檔案大小與 upload failure
- 裝置不支援該功能時的處理方式

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

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

三套方案（A：24–30 小時、B：48–60 小時、C：60–80 小時）的時數結構不必更動，需要調整的是各模組內的時間分配。以方案 B 為例：

兩個新元素的嵌入位置：

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

注意：這兩個新模組無法納入方案 A。24–30 小時不足以同時涵蓋規格撰寫、AGENTS.md 與核心觀念，硬加進去會壓縮 Layer 1 的時間。方案 A 的 AI 元素以「閱讀＋驗收」練習為限。

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

不要一開始就採用 AI 優先。較穩妥的順序如下：

階段 1：不用 AI，建立 React 心智模型（型態一作業）
階段 2：用 AI 產生小片段，由學生審查（型態二）
階段 3：用 AI 產生功能，由學生整合
階段 4：用 AI 進行重構、測試與除錯
階段 5：由 AI 代理處理 issue → PR，再由學生審查程式碼

AI 程式設計代理已經能建立 PR、開發功能、執行任務（GitHub Copilot 官方文件已將其定位為涵蓋程式碼審查、PR 管理與程式設計代理的完整開發生命週期工具），但針對代理所產生 PR 的實證觀察也顯示：CI 未通過、任務偏離目標，以及與既有程式碼衝突等情況仍然常見。AI 可以進入工作流程，但無法取代審查能力——這正是階段 5 要練的能力。

八、評量與老師角色

評量要多量什麼

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

能不能把任務規格寫清楚
能不能限制 AI 不要亂改架構
能不能讀懂 AI 產生的差異內容（diff）
能不能找出錯誤、要求 AI 補測試
能不能拒絕「看似能執行，但架構錯誤」的程式碼
能不能把 AI 產物整合進既有專案

一個可直接用的 rubric：

老師角色的位移

原本：概念講解者、Demo 示範者、作業批改者
AI 導入後：架構守門人、錯誤樣本設計者、程式碼審查教練、任務規格訓練者

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

知道哪些程式碼看起來正確，三週後卻會出問題
知道哪些 abstraction 抽太早
知道哪些 useEffect 根本不該存在
知道哪些 state shape 之後會卡死
知道哪些 RN 寫法在模擬器可以、真機不行

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

會少教的——價值較低的手動輸入流程：

逐行輸入樣板程式碼
手刻大量重複表單欄位
手刻靜態卡片元件
手刻假資料列表
手刻基本 CSS 版面

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

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

state 放哪裡
什麼是 derived state
為什麼不能 mutate state
effect 什麼時候不該用
依賴陣列為什麼會產生錯誤
元件邊界怎麼切
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 產生的問題程式碼）；評量加入規格品質與審查品質。時數結構不必更動，Layer 1 的 20 個觀念則一個都不能拿掉。

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

• ← Previous
  143 個 React / React Native 練習 App 完整圖鑑：從行為反推學習重點
• Next →
  《生資料顯影術》：從未整理的資料中，看見板塊變化、摩擦與隱藏關聯