從一個想法到一套課程：用 Codex 協作製作個案、短個案與課程設計
給大學教師的 AI 協作講義
1 從一個想法到一套課程：用 Codex 協作製作個案、短個案與課程設計
對象：大學教師、個案寫作者、課程設計者
案例：《Become Judy》跨國創作者與創業個案
核心主張：AI 可以協助整理資料、生成版本、設計網頁、產出圖片與部署成果；但整個流程的方向感來自人的判斷。沒有人的決斷，AI 只會把資料堆成看似完整、但未必有教學意義的成品。
1.1 一、這件事如何開始：不是資料先出現，而是判斷先出現
這個專案不是從「我有一堆 YouTube 影片，幫我整理」開始，而是從一個教師的判斷開始。
我先看見 Judy 這個人的特質。她是一位韓國女性創作者，到台灣旅行、生活、拍片，後來把個人內容能量推進到公司化與啦啦隊事業。這裡面同時存在幾個值得管理學討論的面向：跨國市場進入、創作者經濟、平台變現限制、人才簽約、運動娛樂產業、公司化、現金壓力，以及創辦人如何從「被觀眾喜歡的人」轉成「需要管理組織的人」。
這是人類必須先完成的第一個動作：判斷這個人物與事件是否值得成為教學案例。
Codex 可以幫忙找資料、比對證據、整理影片、改寫段落、生成 HTML 與圖片；但它不會自然知道這個題目為什麼值得進入一門管理學課。題目的價值來自教師過去的訓練：我熟悉哈佛商學院長個案、哈佛商業評論短個案、主題式專業課程設計，也理解學生在管理學課堂中需要的不只是故事，而是可分析、可辯論、可形成決策建議的材料。
因此，這個專案真正的起點不是 AI 技術，而是三個人的判斷：
- 題目判斷：Judy 的故事是否具有跨國創業與管理學價值。
- 形式判斷：這個故事應該被發展成長個案、短個案與 18 週課程，而不是只做成一篇文章。
- 教學判斷：學生最後要學會如何建立一家公司，而不只是理解一位創作者的經歷。
1.2 二、流程總覽：從研究計畫到公開課程頁
整個流程可以整理為八個階段。
| 階段 | 人類的決斷 | Codex 的主要工作 | 主要產出 |
|---|---|---|---|
| 1. 研究計畫 | 判斷 Judy 是值得研究的跨國創業案例 | 建立研究計畫、資料結構、產出規格 | 研究計畫與工作資料夾 |
| 2. 資料盤點與查核 | 指定影片、新聞、社群聲量與產業資料的重要性 | 子代理蒐集資料、建立 inventory、字幕校對、證據表 | evidence table、timeline、verification queue |
| 3. 長個案初稿 | 指定 HBS 長個案形式與決策節點 | 整理事實、寫 outline、完成長個案 v1/v2 | case_draft_v2_zh.md |
| 4. 長個案 HTML | 要求可閱讀、可列印、有個案警語與質感 | 製作 HTML、表格與圖像 prompt、PDF 檢查 | 長個案網頁 |
| 5. HBR 短個案 | 判斷要改寫為兩難決策與對話場景 | 設計虛構化角色、壓縮真實脈絡、寫短個案 | HBR Case Study-style 短個案 |
| 6. 插畫式短個案 HTML | 指定漫畫風格與 HBR 影片語氣 | Image Gen 產圖、HTML 排版、渲染檢查 | 圖文短個案網頁 |
| 7. 18 週課程 | 指定以長個案為核心，走過公司建立歷程 | 對應 Robbins/Coulter 管理學架構、寫長 syllabus | 18 週課程大綱 |
| 8. 雙語課程頁與 GitHub | 指定 CM108G、1151、大學部、英文授課與首頁更新 | 產出雙語 HTML、圖像、GitHub Pages 部署 | CM108G 課程頁 |
這個表格的重點不在流程有多長，而在每一步都有人類判斷與機器執行之間的分工。
1.3 三、原始指令摘錄：教師如何逐步把 AI 帶進正確方向
以下摘錄本專案中具有轉折意義的指令。它們不是「一次寫出完美 prompt」的示範，而是呈現教師如何在過程中逐步調整任務邊界、品質標準與產出形式。
1.3.1 1. 建立專案與初始研究方向
在這個資料夾之下，我要設置一個新專案。這個專案的目標是寫出一個商業個案，圍繞在一位韓國籍女性 YouTuber「Judy」身上。
她從韓國來到臺灣發展，一開始是在臺灣旅行，因為喜歡臺灣的生活，透過旅遊介紹吸引了來自臺灣及韓國網友的注意。最後，她選擇在臺灣成立一家公司，經營啦啦隊生意。
我預計產生三個產出：
1. 管理學的 18 週課程設計
2. 哈佛商學院經典長個案的形式
3. 哈佛商業評論的短個案形式
為了完成這件事情，你需要參照相當多的外部資料。所以在一開始，我需要你先提出整個研究計畫，然後我們再來決定下一步。
註解：這段指令已經不是單純的資料整理。它同時給了人物、管理主題、產出形式與研究方法。Codex 能據此建立資料夾與研究計畫，但「三種產出」的設計來自教師對教學材料市場的理解。
1.3.2 2. 指派多代理工作與資料校正
藉由多個 Subagent 協作影片 Inventory 跟關鍵影片的字幕校對，這本來就有一個 Subagent 去處理；其他 agent 同步收集資料，自行校正資料。
註解：這裡的重點是把任務拆開。影片 inventory、字幕校對、外部資料蒐集可以平行處理；但哪些影片是「關鍵影片」、哪些主張需要查證，仍然需要人先定義。
1.3.3 3. 從資料整理進入證據分級
先校對 VID-001、VID-004、VID-006 三支影片，完成可引用逐字稿與時間戳。
依evidence_table_integrated.xlsx把所有核心主張分成 A/B/C/D 級，先寫 teaching note 的 fact base。
以Judy_public_timeline_v1.md建立個案決策節點：內容創作者、公司化、人才簽約、運動合作、財務壓力、跨國人才管理。
再展開三個產出：18 週課程設計、HBS 長個案、HBR 短個案。
註解：這是研究專案最重要的品質控點。AI 常會急著寫正文，但個案寫作不能只靠敘事流暢。先做可引用逐字稿、證據分級與決策節點，才有辦法防止個案變成未查證的故事。
1.3.4 4. 補足產業背景
需要增加產業背景與市場需求的相關資訊，以作為長個案的證據支持。特別是韓國啦啦隊的競爭狀況、市場規模及產業結構，甚至要探討其如何影響啦啦隊員的收入結構。
同時，也要觀察 YouTuber 在亞洲的實際經營狀況。由於 YouTuber 在中文區的受眾相對有限，原則上以臺灣、港澳、新加坡等地的繁體中文市場為主，少部分則面向中國大陸。
註解：這裡顯示教師不是只要人物故事，而是要讓個案能承受管理分析。沒有產業背景，學生只能討論「她很努力」；有了產業結構與收入限制，學生才會討論商業模式。
1.3.5 5. 從研究進入長個案寫作
開始撰寫長個案初稿。
註解：短指令背後其實有前置條件。因為前面已經定義了證據表、timeline、產業背景與決策節點，所以「開始寫作」不等於讓 AI 自由發揮，而是進入一個已經被規範過的寫作階段。
1.3.6 6. 對第二版提出敘事與情感要求
開始寫作第二版。在第二版中，資料的豐富度跟敘事的完整性是最關鍵的，需要帶有一定情感上的描述，例如她在臺灣奮鬥的艱辛狀況。
希望能直接引用她的話語，並很好地呈現出在臺灣經營的困難點以及她的心路歷程。
敘事結構請採用哈佛商學院個案形式，不要有那種很明顯是給編輯者看的文字；這就是一份給學習者閱讀的文本。
註解：AI 初稿常有一種「研究報告味」。這段指令把它拉回個案文本：要讓讀者進入情境，但不能寫成煽情故事；要引用本人話語，但不能超出可查證材料。
1.3.7 7. 人類編輯判斷：修正個案語氣
第二版的閱讀感不好。
例如在「頻道變成公司」的這一大段，一般我們的個案寫法，不會寫成「公開公司資料顯示，與 Judy 相關的公司開始出現在臺灣登記系統中」。
我們應該用一種已經知道這件事、而且核實過的口吻直接說明，例如：「在 Judy 旗下陸續成立了幾家公司」，用這種敘事方式來陳述到底發生了什麼事。
註解：這是人類不可替代的地方。AI 會為了保守而保留查核口吻，但教學個案需要一種「事實已經核實，因此可直接敘述」的語氣。這不是事實問題，而是文類判斷。
1.3.8 8. 增加多元視角與圖像
影片中不只有 Judy，還有其他人。他們是如何看待 Judy 這個老闆的？我認為這些相關訊息也可以放入個案，讓整體視角更加多元。
現在的 Exhibit 全部都是表格，我希望能夠增加幾張圖片。你不需要直接生成圖片，而是先寫出生成圖片的 Prompt。
註解：這段指令讓個案從「創辦人視角」轉為「組織視角」。同時，它要求圖像不是裝飾，而是用來呈現生態系、分潤與組織關係。
1.3.9 9. 長個案 HTML 與教學警語
接下來就可以開始輸出成一份 HTML 式的個案。
圖片、影片的插入，以及表格的呈現，都要能夠展現出類似哈佛商學院個案的質感，但同時帶有一種雜誌排版風格，也就是具備傳統書報氛圍的個案閱讀體驗。
必須加註 AI 寫作註解，說明素材是由元智大學吳相勲副教授與 Codex 協作而成。
需明確說明：本個案未經 Judy 同意，亦未訪問其本人或身邊相關人士。
註解：這裡同時處理閱讀體驗與倫理界線。AI 可以排版，但不能自行決定個案是否需要揭露未訪談、未授權與 library case 屬性。這是教師與作者的責任。
1.3.10 10. 從長個案轉成 HBR 短個案
接下來寫成 Harvard Business Review 的 Case Study 形式。這種個案形式不會完全以真實事件作為藍本改編，而是根據兩難決策發展出簡化的場景，更多是透過不同角色之間的對話、互動與爭執，來展現個案中重要決策的立場及資訊。
它不是完全基於 Judy 這個角色來設計，盡可能讓角色稍微跳脫真實，以避免大家直接對號入座；但也不要完全脫離目前的個案範疇。
註解：這是形式轉換。長個案需要事實厚度；短個案需要張力、角色與兩難。人類在此設定了倫理與教學邊界：要改寫、要虛構化、但不能失去原本的管理問題。
1.3.11 11. 圖像風格與 Image Gen
這些圖片要採用漫畫風格，你可以參考上面這支 YouTube 影片《Harvard Business Review》為他們的短個案所做的影片風格，我們從中萃取設計靈感，製作適合這個個案的圖像。圖片中的角色可以進行對話，讓整體呈現出漫畫感。
請你使用 Image Gen 這個 Skills 去產生圖像（不是 SVG，是高品質的 PNG），然後將它完成的圖片置入到 HTML 的網頁中。
註解：這段指令非常重要，因為它同時指定了風格來源、媒材形式與實作要求。後續 Image Gen 的 prompt 必須避免模仿 HBR 具體畫面或使用真實人物肖像，因此提示詞會刻意寫出「fictional character」「no logos」「no real-person likeness」。
1.3.12 12. 從個案擴展成 18 週課程
以 HBR Case Study 為基礎，結合管理學的教學架構，設計出 18 週的課程。
這個課程上起來應該像是一個故事，我們以個案為核心，走過整個商業探索的歷程。也就是說，到最後學生應該要能夠體驗到如何建立一家公司。
搭配的教科書是 Robbins and Coulter 的 Management。
註解：這段指令把產出從個案材料推向課程設計。關鍵不在「列 18 週主題」，而在讓課程像一段公司建立歷程。每週管理學概念都要嵌入同一家公司，而不是變成章節摘要。
1.3.13 13. 修正課程核心：不是短個案，而是長個案
不是短個案版本，是長個案版本。
註解：這是一個很小但很關鍵的修正。短個案適合決策討論，但 18 週課程需要完整事實、產業背景與多週累積作業，因此應以長個案作為主軸。這種材料適配判斷必須由教師掌握。
1.3.14 14. 雙語 HTML syllabus 與學生閱讀體驗
將這一份做完的超長的課程大綱轉換成 HTML 格式，然後將長短個案的資料放進來，再加上合適的配圖。
一樣使用 Image Gen 生成圖片的方式置入，讓這整個 HTML 的 syllabus 看起來非常完整，而且本身就是一份極佳的學習教材。
只是要注意使用的流暢性，或許可以透過頁籤或折疊卡片的方式呈現，讓整個頁面不會過長，並提供較好的引導閱讀體驗。
再次強調，這是提供給學生看的版本，因此不應殘留給開發者或教師看的文字。
請注意網頁須提供雙語版本，具備中英文切換的功能。
註解：這裡把 syllabus 從「課綱文件」變成「學生可使用的學習介面」。人類提出閱讀行為的判斷：長頁不能只是塞滿內容，要有頁籤、折疊卡、引導與雙語切換。
1.3.15 15. 正式課程資訊與 GitHub 首頁
這門課將於 115 學期第 1 學期開設，大學部，英文授課，代號 CM108G。新增這些資訊，並 Git commit。
並且，更新https://537sonic.github.io/SONIC/的「課程介紹」部份。除了 CM108G，其餘課程先呈現無連結、僅有卡片訊息的樣貌。
註解：這是從原型進入公開課程資訊的階段。AI 可以改 HTML、複製資產、commit、push；但課程代號、學期、課程層級與首頁呈現策略都必須由人決定。
1.4 四、AI 協作過程：Codex 具體做了什麼
在這個專案裡，Codex 的工作不是單一任務，而是跨越研究、寫作、設計、圖片、程式與部署。可分為六類。
1.4.1 1. 研究與資料整理
Codex 能處理大量公開資料與本機資料。它可以建立影片 inventory、整理新聞與公開資料、比對社群討論、產生 timeline、建立 evidence table，並把核心主張分成可信度等級。
但這類工作必須有清楚的規則。例如「A/B/C/D 級證據」的分級，是為了避免把未查證的敘事直接寫進個案。Codex 可以執行分級，但要先知道什麼叫作可引用、什麼叫作推論、什麼叫作仍待查證。
1.4.2 2. 長個案寫作
Codex 先根據資料結構完成 outline，再寫出長個案初稿。之後，根據人類回饋修正語氣、敘事節奏、角色視角與 exhibit。
這裡的協作不是「AI 寫，人類收稿」。比較精確的說法是：人類定義文類、讀者與判準，AI 依判準產生版本，人類再指出偏差。
1.4.3 3. HBR 短個案改寫
長個案有厚度，但短個案需要兩難。Codex 依照指令把真實情境虛構化為一個角色場景，讓不同角色透過對話呈現擴張合約的代價。
這裡 AI 的能力在於快速生成角色、對話與衝突；人類的責任在於確保角色沒有直接對號入座，並且兩難不是為戲劇化而戲劇化，而是能回到管理決策。
1.4.4 4. HTML 與閱讀介面
Codex 製作了長個案 HTML、短個案 HTML 與雙語 syllabus HTML。這些 HTML 不是簡單轉檔，而是根據閱讀任務重新設計。
長個案重視書報式閱讀、註解、exhibit、PDF 輸出。短個案重視漫畫分鏡、角色對話與決策張力。Syllabus 重視導覽、頁籤、週卡、雙語切換與長短個案連結。
1.4.5 5. 圖片生成與資產管理
Codex 使用 Image Gen 產生 PNG 圖像，並把圖片複製到專案 assets 目錄。這是很重要的細節：不能讓 HTML 只連到 Codex 暫存資料夾，否則部署後圖片會失效。
圖片 prompt 的設計也不只是美術描述。每個 prompt 都要同時處理：風格、構圖、角色虛構化、避免商標、避免真實人物肖像、避免 AI 產生錯誤文字，以及預留 HTML 排版空間。
1.4.6 6. GitHub Pages 部署
最終成果被放入 C:\Users\sonic\OneDrive\SONIC-repo，並透過 git commit 與 push 發布到 GitHub Pages。GitHub Pages 可以從 GitHub repository 發布靜態網站；官方文件說明可從 repository 建立 Pages site，也可以設定發布來源。對未使用過 GitHub 的老師來說，可把它先理解成「把一個含有 index.html 的資料夾放到 GitHub，讓 GitHub 幫你變成公開網址」。
相關官方說明：
- GitHub Docs: Creating a GitHub Pages site
- GitHub Docs: Configuring a publishing source for your GitHub Pages site
1.5 五、關鍵轉折：人的判斷如何改變 AI 的產出
1.5.1 轉折一：從人物故事改成管理個案
如果只把 Judy 當成網紅故事，最後會得到一篇人物報導。真正讓這個題目成為管理學個案的，是人類先判斷她的故事背後有一個「個人內容能量如何變成公司」的問題。
1.5.2 轉折二：從資料整理改成證據分級
AI 很容易把所有找到的資料放進正文。這在個案寫作中很危險。要求先做 evidence table 與可引用逐字稿，等於建立了一道閘門：只有經過分級的資料，才有資格進入教學事實基礎。
1.5.3 轉折三：從研究報告口吻改成個案敘事
「公開公司資料顯示」這類句子在查核報告中合理，但在個案正文中會讓讀者一直停在資料來源層，而不是進入決策情境。人類在這裡修正的是文類語氣。
1.5.4 轉折四：從真實人物改成虛構化短個案
HBR 短個案不是縮短版長個案，而是決策場景。人類要求角色稍微跳脫真實，是為了降低對號入座與倫理風險，同時保留管理張力。
1.5.5 轉折五：從課程表改成學習旅程
18 週課程若只是把 Robbins/Coulter 的章節排進週次，學生很難感受到管理學的整體性。人類要求課程像故事，讓學生一路經歷「看見機會、形成公司、建立制度、承擔風險、提出建議」。
1.5.6 轉折六：從本機檔案改成公開教學資產
當課程確定為 CM108G、1151、大學部、英文授課後，成果就不只是實驗稿，而是公開課程介紹的一部分。這時 GitHub Pages 與首頁課程卡片就成為教學作品的發布通道。
1.6 六、技術細節揭露
1.6.1 A. HTML 設計：不是把 Word 貼上網頁
這個專案做了三種 HTML，每一種的閱讀任務不同。
| HTML 類型 | 設計重點 | 檢查項目 |
|---|---|---|
| HBS 長個案 | 長文閱讀、傳統書報感、exhibit、註解與列印 | 字體大小、表格可讀性、PDF 輸出、AI 與 library case 聲明 |
| HBR 短個案 | 漫畫分鏡、角色對話、兩難決策、閱讀節奏 | 圖片載入、對話不遮蔽、手機版排版、圖片非真實肖像 |
| 18 週 syllabus | 頁籤、週卡、雙語切換、長短個案連結 | 18 週資料完整、圖片 assets 正確、中文英文切換、列印功能 |
HTML 設計中最重要的不是美觀，而是閱讀行為。
長個案需要讓讀者連續閱讀，因此主體字不能太小，段落間距要像教學個案。短個案需要讓讀者停在角色衝突，因此圖片與對話框要服務情節。Syllabus 則不能讓學生在一個超長頁面迷路，所以使用頁籤與折疊卡，讓學生按圖索驥。
在實作上，Codex 使用下列檢查方法：
- 用瀏覽器自動化檢查圖片是否載入。
- 檢查週卡是否生成 18 週。
- 檢查中英文切換後是否仍可閱讀。
- 產生桌機與手機截圖。
- 產生 PDF 預覽。
- 搜尋是否殘留「教師使用建議」「developer」「TODO」「prompt」等不該出現在學生版的字眼。
1.6.2 B. 圖片生成指令：為什麼 prompt 要寫得這麼細
短個案插畫的共用風格提示如下：
Premium business-magazine comic illustration inspired by animated case-study videos: bold black ink outlines, flat color blocking, subtle halftone paper grain, cinematic cropping, restrained palette of teal, charcoal, cream, warm coral, and muted gold. Do not imitate any specific copyrighted frame; do not include Harvard Business Review branding, YouTube UI, logos, trademarks, or real-person likeness. Include empty speech-bubble shapes only; exact Chinese dialogue is rendered in HTML.
這段 prompt 有幾個目的。
第一，指定風格，但不要求模仿特定受版權保護的畫面。第二，要求沒有 HBR 標誌、YouTube UI、商標或真實人物肖像。第三，要求對話泡泡可以出現，但不要讓圖片模型自行生成中文對話，因為生成圖片中的文字常會失真；真正的對話應該由 HTML 呈現。
Syllabus 圖像的 prompt 也採取同樣邏輯，例如：
High-quality PNG illustration for a bilingual management syllabus webpage. Editorial business-magazine comic style, warm paper texture, clean ink outlines, restrained palette of ivory, deep teal, coral, muted gold, charcoal. Scene: a Korean woman creator-entrepreneur in Taiwan is standing at a table with a laptop, camera, sports arena tickets, sticky notes, and a simple company roadmap; diverse university students look at the evidence and discuss. No real-person likeness, fictional character only. Include subtle Taipei street and baseball stadium cues in the background. Horizontal hero composition, cinematic but readable, no logos, no legible text, no brand names, no watermark.
這段 prompt 的重點是「教學情境」而不是「Judy 肖像」。它讓圖片服務課程頁，而不是替真實人物製造替代肖像。
1.6.3 C. GitHub Pages：給未接觸過 GitHub 教師的簡短說明
GitHub 對許多教師來說，第一印象可能是工程師寫程式的地方。但在這個專案中，它扮演的是公開作品架與靜態網站託管工具。
簡化來看，流程如下：
- 準備一個資料夾，裡面有
index.html與assets/。 - 把這個資料夾放進 GitHub repository。
- 使用 git commit 記錄改動。
- 使用 git push 上傳到 GitHub。
- 如果 repository 已設定 GitHub Pages，網站會透過固定網址公開。
這次的三個公開成果分別是：
- 長個案：
https://537sonic.github.io/SONIC/hbr/become-judy/ - HBR 短個案：
https://537sonic.github.io/SONIC/hbr/become-judy-hbr-case-study/ - CM108G 課程頁：
https://537sonic.github.io/SONIC/class/cm108g-1151/
三次主要 commit 為：
8d3fd97 Add Become Judy teaching casec3e6287 Add illustrated Become Judy HBR case studyad0fa0d Add CM108G 1151 syllabus and course cards
1.7 七、回溯過程時會遇到的問題
1.7.1 1. 對話不是完整資料庫
回溯流程時，不能只靠記憶或聊天紀錄。對話裡有指令，但產出、檔案、測試結果與 commit 在檔案系統和 git 裡。要重建流程，必須同時看：
- 專案資料夾中的
02_Process與03_Output - 長短個案 Markdown 與 HTML
- Image Gen prompt 紀錄
- Git commit log
- GitHub Pages 線上頁面
1.7.2 2. 中文檔案與終端輸出可能亂碼
PowerShell 直接讀 UTF-8 中文檔時，有時會出現亂碼。這類問題不能直接解讀為檔案壞掉。較穩定的作法是使用 python -X utf8 或明確指定 encoding='utf-8' 讀檔。
1.7.3 3. 工具路徑不一定如預期
在檢查 HTML 時，原先使用 Node Playwright，但本機套件路徑缺少 playwright-core，出現錯誤。後來改用 Python Playwright 完成瀏覽器檢查。這是 AI 可以自行修復的典型問題：目標清楚，工具 A 壞了，就找工具 B。
1.7.4 4. GitHub Pages 需要部署驗證
push 到 GitHub 不代表網頁立刻可用。需要用線上網址重新抓取或用瀏覽器檢查。這次也遇到過網址形式造成的 404 與 PowerShell $HOME 變數不可覆寫問題。這類錯誤不涉及課程判斷，Codex 可以自行修正變數名稱或改用更明確的 index.html 驗證。
1.7.5 5. Git 工作區可能有無關檔案
SONIC repo 當時已有兩個未追蹤 SVG。正確作法不是順手加入 commit，而是只 stage 本次相關檔案。這是機器可以執行，但必須遵守工作區倫理的部分。
1.8 八、哪些地方人類必須介入，哪些地方機器可以主導
| 任務 | 人類必須介入 | 機器可主導 | 註解 |
|---|---|---|---|
| 題目選擇 | 判斷 Judy 是否值得成為管理個案 | 蒐集初步資料支持判斷 | 題目的「重要性」不是資料量決定的 |
| 產出組合 | 決定要做長個案、短個案與課程 | 根據格式產生草稿與檔案 | 形式選擇反映教師教學經驗 |
| 證據規則 | 定義何謂可引用、何謂推論 | 建立證據表、標記等級、找缺口 | AI 可以分級，但標準要人設定 |
| 個案敘事 | 判斷語氣是否像教學個案 | 依回饋重寫段落 | 「閱讀感不好」是人類的文類直覺 |
| 角色虛構化 | 決定倫理邊界與可改寫程度 | 生成角色、對話與場景 | 避免對號入座是作者責任 |
| 產業背景 | 判斷哪些背景足以支撐分析 | 蒐集與整理產業資料 | 背景不是越多越好，要能支持決策 |
| 課程設計 | 設定學生最終要學會什麼 | 對應章節、設計週次、作業 | 教學目標必須先於週次安排 |
| HTML 設計 | 判斷讀者如何使用頁面 | 寫 HTML/CSS/JS、測試響應式 | AI 可修版面，但閱讀策略要人決定 |
| 圖片生成 | 決定風格、倫理、是否可用真實肖像 | 寫 prompt、生成圖、管理 assets | 圖像不能只是漂亮，還要安全且有教學功能 |
| GitHub 發布 | 決定公開範圍與課程資訊 | commit、push、驗證 URL | 發布是教學品牌與倫理決策 |
1.9 九、可複製的協作心法
1.9.1 1. 不要一開始就要求 AI 寫正文
先要求 AI 做研究計畫、資料盤點、證據表與決策節點。這些東西看起來不像成品，卻決定成品品質。
1.9.2 2. 把「你知道的文類」說出來
如果你熟悉 HBS 長個案、HBR 短個案、課程 syllabus 或研討會講義，就要明確告訴 AI。AI 不會自動知道你心中的文類標準。
1.9.3 3. 對 AI 的第一稿保持不滿意
第一稿常常只是讓問題浮現。真正的協作發生在你指出「這不是個案語氣」「這裡讀者會看不懂」「這不是學生版」「這應該用長個案而不是短個案」的時候。
1.9.4 4. 把抽象回饋改成可執行指令
「閱讀感不好」之後，最好接著說明哪一句不好、應該改成什麼敘事口吻。AI 需要具體偏差，才會修得準。
1.9.5 5. 把每個產出都當成下一個產出的材料
長個案不是終點，它會變成短個案的事實基礎，也會成為 18 週課程的主軸。課程頁也不是另一個孤立網站，而是把長短個案變成學生可使用的學習介面。
1.9.6 6. 發布前一定要做機器檢查
HTML 是否能打開、圖片是否載入、手機是否爆版、PDF 是否可列印、連結是否有效，這些都不應該靠肉眼猜測。Codex 很適合主導這些檢查與修復。
1.10 十、給大學教師的操作建議
如果你想用 Codex 做類似專案，可以依序給出下列指令。
1.10.1 第一輪：先讓 AI 建立研究計畫
我想把某個人物、組織或事件發展成管理教學個案。請先不要寫正文，先幫我建立研究計畫：資料來源、待查證問題、可能的決策節點、可形成的教學產出，以及每個產出的風險。
1.10.2 第二輪：要求證據表與資料缺口
請把目前找到的資料分成事實、推論、未知與待查證。每個主張都要標來源與可信度等級，並說明哪些主張不能直接寫進正文。
1.10.3 第三輪：指定文類
請依照 HBS 長個案形式寫 outline。不要寫成報告，也不要寫成評論文章；讀者應該像進入一個決策情境，而不是讀到資料整理。
1.10.4 第四輪：要求第二版
第一版之後，請加強敘事節奏、角色視角、產業背景與決策張力。若有未查證之處，請明確標示，不要把推論寫成事實。
1.10.5 第五輪：轉成短個案或課程
請把長個案轉成 HBR Case Study-style 短個案，設定一個兩難決策，角色可虛構化，但管理問題必須保留。
或者：請以長個案為核心，設計一門 18 週課程，讓學生每週累積一個管理工具，最後形成完整建議。
1.10.6 第六輪：產出 HTML 與部署
請將完成內容轉成學生可閱讀的 HTML，加入頁籤、折疊卡、圖片、列印 PDF 功能與必要聲明。圖片使用生成式插畫，不使用真實人物肖像。完成後請檢查桌機、手機、圖片載入、連結與 PDF。
1.11 十一、延伸附件：GitHub Pages 與 Codex 入門
本講義另附兩份操作型附件，供希望實際複製這套流程的教師使用。
| 附件 | 內容 | 適合閱讀時機 |
|---|---|---|
| 附錄 A：大學教師的 GitHub Pages 架站與版本管理入門 | 以檔案總管作為類比，說明 GitHub Pages 架站流程、Repository、Commit、Main、Commit to Main、Push、Pages 等概念 | 當你想把教材、課程頁或個案 HTML 放到公開網址時 |
| 附錄 B：大學教師的 Codex 入門與跨裝置換手寫作 | 說明 Codex 與 ChatGPT 的差異、Windows 與 Mac 安裝方式、Claude Code 與 Cursor 的對應關係，以及用 OneDrive 或 Google Drive 進行跨裝置換手寫作的方法 | 當你想把教材專案放到不同電腦接續製作時 |
| 附錄 C：Become Judy 專案對話歷程與 Codex 修改紀錄 | 保留本專案逐輪指令、Codex 工作結果、關鍵檔案與 GitHub commit 紀錄，讓讀者可對照真實協作過程 | 當你想理解每個成果是在什麼對話與修改階段形成時 |
這些附件的目的不是把教師變成工程師，而是讓教師能理解工具背後的管理意義：資料夾如何變成專案，修改如何變成版本，版本如何變成公開教材，跨裝置工作又如何透過交接檔與同步資料夾延續。
1.12 十二、這個案例真正教我們什麼
這個專案表面上是用 Codex 做出長個案、短個案、課程頁與 GitHub Pages。實際上，它示範的是一種新的教師工作方式。
教師不再只是把既有教材整理成投影片，也不只是把 AI 當作文字代工。教師真正要做的是提出判斷：什麼題目值得成為教材？什麼形式最適合這個題目？學生最後要學會什麼？哪些資料足以進入教學文本？哪些地方必須保留不確定性？
AI 的價值在於把這些判斷快速轉成版本。它能做資料整理、寫草稿、生成圖片、設計 HTML、跑檢查、修錯誤、commit、部署。只是，版本越多，越需要人的方向感。
因此，這份講義最後想強調的不是「老師如何學會更多工具」。重點其實相反：老師越能清楚說出自己的判斷，Codex 越能成為有用的協作者。