一串 Task Prompt，
最後長成一個學習網站。
這不是預先寫好的產品規格，而是一段真實的協作過程：使用者先說想學 Codex，接著修正教材方向、補上學習時數與情境，再不斷擴展網站用途。這一章拆解 Codex 如何把需求變成可檢查的內容和網站，也回顧哪些地方應該先釐清、哪些決策來自使用者回饋。
本章學習路線
先看使用者如何一步步定義真正想要的成果
需求不是一次交代完成，而是透過使用者回饋，逐漸從「做個頁面」變成「能自學的課程產品」。每次轉向都改變了交付物。
最初希望有一個 HTML，介紹 Codex 使用方式、quota、指令、功能和技巧。這先定義了主題，還沒有定義教學深度、受眾或學習成果。
使用者要求整理官方網站和教學，聚焦最重要的 20% 內容，並以繁中解釋技術術語。於是需要把產品功能切成可分開閱讀的教材，而不是堆成單頁速查表。
使用者說明真正的期待是「讀完文件就能應用」，並要求增加內容、情境和 20 小時學習路徑。成功標準從「列出功能」改為「完成練習後能交付」。
後續補上程式以外的生活 AI Agent、RAG 與個人脈絡、開源圖示、爬蟲友善的 SEO，最後再要求把整個網站製作過程變成 Codex 實戰案例。
如何把模糊想法改寫成可執行工作單？
最初的需求有主題，但缺少範圍、依據和完成條件。實際協作中，這些資訊是經由追問與回饋逐步補齊的。若從頭重新交辦，可以先用以下格式：
這是依照本案例回顧重寫的「更完整交辦方式」，不是最初一開始就收到的原文 Prompt。
把「介紹 Codex」轉成學習成果與章節
先問讀者學完要能做什麼：把任務說清楚、協助 Codex 理解 repo、找到 bug、實作變更、驗證結果、審查風險、設定可重用脈絡。能力比功能清單更能決定要教什麼。
- 目標是行為，不只是知道名詞。
- 每種能力配一個日常情境和可觀察成果。
- 20% / 80% 是取捨方向，不是聲稱精確計算出課程涵蓋率。
官方文件研究：找依據、翻成操作步驟、保留查證路徑
Codex 命令、設定、Quota、Cloud、AGENTS.md 和 Memories 等產品行為，優先連到官方 Learn、Help Center 和 Developers 文件。
不只照抄說明，而是整理「什麼時候用、要給 Codex 什麼、使用者如何驗收、什麼要注意」，再配情境練習。
Quota 與功能開放可能因帳號和版本而異，所以教材引導讀者查看自己的 Usage 或官方最新文件，不把固定數字寫成普遍保證。
本案例透過官方頁面搜尋與閱讀整理內容，並提供官方連結；沒有執行整站爬蟲、鏡像下載或完整抓取所有官方教材。
為什麼採用一組共用的 HTML、CSS 和 JavaScript？
課程卡片能搜尋、顯示完成進度；使用者從首頁看到整個學習地圖。
course.css 負責暗色主題、排版、時間軸、卡片、互動面板和手機版配置。
course.js 提供分頁切換、測驗回饋、複製 Prompt、完成記錄和手動計時。
每章是獨立 HTML；共用互動邏輯和樣式減少重複，每頁以 data-lesson 連結自己的進度鍵。
Lucide 開源 SVG 圖示依章節主題呈現；favicon、分享預覽圖和 meta 資料服務瀏覽器與社群分享。
localStorage 保存完成狀態和計時。它是單一瀏覽器內的本機記錄，不是帳號同步或雲端備份。
互動設計的判準
每個元件都要幫助理解或行動：Tabs 用來切換範例，複製按鈕減少重打，理解題立即回饋，計時器支持分段學習，完成勾選使長課程可續學。不要為了「看起來互動」而加沒有學習價值的動畫或表單。
使用者每次修正，如何帶動下一輪設計？
「教材太少，要能學 20 小時」→ 擴充為 10 × 120 分鐘，加入情境、實作和完成標準。不要只加長文字，要增加練習密度和成果。
「最後加生活 Agent 章」→ 增加旅行、檔案整理、學習教練案例，並將主課程時間和加值時間分開。
「補 RAG、意圖、全域同步」→ 擴充第 09 章，區分 AGENTS.md、Memories、Skills、MCP、參考檔檢索和跨專案同步。
交付前怎麼檢查？哪些事情不能宣稱做過？
把這套做法帶進你的下一個 Codex 專案
當使用者只說「做一個網站」，釐清受眾、使用情境、內容深度、交付格式和成功條件。
先建立資訊架構、單元清單、共用互動範本，再分批完成可 review 的頁面。
每次 steering 後更新相關頁面、索引、導覽和計數，不只改眼前的一句文字。
清楚報告做了什麼、檢查了什麼、依據什麼，以及哪些部分還沒驗證。