Codex 與多 Agent：把課程構想整理成可協作的專案

先說結論

你在前面幾個單元已經接觸過不少 AI 工具：ChatGPT 協助釐清問題，Gemini 檢查文字，Gemini Notebook（NotebookLM） 管理資料來源，Peer Evaluation 記錄同儕回饋。這一單元要處理另一個實際問題：當一個課程構想經過多人與 AI 共同製作，如何維持明確的目標、來源、責任與修訂紀錄。

Codex 與多 Agent 可以同時處理多項工作，本頁關注的則是協作治理：先將模糊需求整理成任務卡，為資料來源分級，界定 AI 的工作範圍，再由不同角色負責來源查核、活動設計、Prompt 測試與讀者檢查。每個角色都必須知道自己的交付範圍、暫停條件，以及最後由誰決定。

請先記住一項原則：將工作交由 AI 協助以前，必須先設計一套人與 AI 都能確實執行的流程。 流程不清楚，模型能力愈強，錯誤擴大的速度可能愈快；流程明確，即使使用一般工具，也能維持成果的穩定性。

這一單元整合四組既有方法：Codex 工作坊的任務卡與 OIP 流程、判斷力課堂的多角色分工、企業講義的獨立檢核規則，以及 AI Agent 課程中的 PLAN.md、HANDOFF.md、Human-in-the-loop。這些方法雖然源自不同情境，目的卻一致：將一次性的構想整理成他人能理解、能查核，也能持續修訂的課程專案。^{SRC-0901SRC-0902SRC-0903SRC-0904}

你會完成什麼

完成本單元後，你會製作四份可直接運用於課程或工作坊的成果。

第一份是「開工任務卡」。它將模糊需求整理為工作資料夾、最終交付物、可用來源、禁止使用資料、完成標準與第一個步驟。這張卡雖然形式近似行政文件，實際上是你與 AI 確認工作邊界的基本依據；缺少這些資訊，後續 Prompt 就容易依賴模型猜測。

第二份是「OIP 工作流程表」。OIP 代表 Output、Input、Process：先確定最終交付物，再列出可用輸入，最後設計處理流程。若只提出「幫我做教材」，AI 並不知道教材的使用對象、要處理的問題、可採用的來源，以及驗收方式。OIP 的作用，是在開始製作前釐清成果、素材與流程。

第三份是「多 Agent 分工表」。你會將課程專案分為來源盤點、學習活動設計、Prompt 測試、文字檢查與獨立覆核。每個角色都要註明輸入、輸出、禁止事項與退回條件。角色數量不必多，明確的工作邊界才是有效分工的基礎。

第四份是「進度與修正紀錄」。內容須交代目前完成的成果、採用來源、實際測試項目、尚待處理的問題，以及下一位協作者應先閱讀的資料。修正規則則要說明哪些情況必須暫停、由誰判斷，以及修改後需重新檢查哪些項目。

這四份成果合起來，就是你的「課程專案工作包」。你不必先具備程式開發背景，但必須說明課程要完成什麼、資料從哪裡取得、如何檢查 AI 產出，以及哪些情況必須交由人員判斷。

開場故事

從「幫我改標題」看見專案治理

批次重新命名 Codex 對話標題，是一個適合說明專案治理的小案例。表面上，工作內容只是請 AI 統一多筆標題；實際執行後，便會發現其中涉及規格、權限、狀態與查核。

如果你只說「幫我改得清楚」，AI 可能會調整出整齊的標題，卻同時改掉日期、混淆任務對象、將未完成任務標示為完成，甚至混用 ChatGPT 網頁對話與 Codex 桌面任務。標題雖小，仍會影響後續搜尋、交接、引用與責任歸屬。名稱錯誤，接手者可能找不到正確紀錄；狀態錯誤，則會造成工作已完成的誤判。

較穩妥的作法是先訂定規則：日期採 Asia/Taipei；標題包含對象、主題與狀態；無法確認的任務列為待查；區分工具能修改與不能修改的標題；完成後抽查清單；遇到權限外的項目則留下紀錄。這項看似單純的命名工作，實際上已經涵蓋規格制定、工作分派、查核與交接。^SRC-0905

將這個例子帶回課堂，可以請學生思考：連標題命名都需要規則，一門 18 週課程、一套企業講義、一個 Gemini Notebook（NotebookLM） 助教或一組 Peer Evaluation 分析，怎麼可能只靠一句「幫我整理」就完成？

課程協作要先拆開不同風險

判斷力課堂曾將工作分為數個角色：主整合者維持課程主軸，來源盤點者查核資料，課前盤點角色整理學員起點，Gemini Notebook（NotebookLM） 角色設計來源邊界，評量角色處理 Peer Evaluation，企業轉用角色檢查工作場域限制，獨立檢核角色則從讀者角度找出問題。^SRC-0902

這份分工提醒我們：來源錯誤、活動失焦、Prompt 越界與讀者無法理解，屬於不同類型的問題，應分別檢查。最後一輪也不宜只由原作者自評。請一位未參與撰寫的人依照說明實際操作，通常比原作者再次閱讀，更容易發現遺漏。

企業講義的既有規則也能直接轉用：學員閱讀的文字不能混入帶課備忘；必要 Prompt 要能直接取得；要求填寫的表格必須真的可用；語文修正不能改掉提示詞中的數字、網址、欄位與停止條件。任何一項失守，都先修正再交給讀者。^SRC-0903

將這些經驗納入課堂後，學生會理解較成熟的 AI 協作方式：AI 可以分擔工作，但人員的責任與決策權必須更加明確。

核心觀念

先定交付物，再談工具

許多 AI 專案一開始便問：「我要用 ChatGPT、Gemini、Gemini Notebook（NotebookLM） 還是 Codex？」工具選擇並非第一個問題。較實際的作法，是先回答四件事：最終交付什麼、由誰使用、使用目的為何，以及達到什麼程度才算完成。

如果你的交付物是一份給學生的講義，完成標準可能是：學生不靠額外口頭補充也看得懂操作；必要 Prompt 直接可複製；每個活動都有完成證據；來源可以回查；中文自然；沒有帶課備忘語氣。如果你的交付物是一份企業 AI 專案 brief，完成標準可能是：有問題定義、輸入資料、AI 任務、人工覆核、MVP 範圍、ROI 指標與交接方式。如果你的交付物是一個課程助教規格，完成標準可能是：有來源範圍、可回答與不可回答問題、引用查核、錯誤處理與教師覆核。

工具是完成交付物的載體。Gemini Notebook（NotebookLM） 適合管理指定來源與擔任閱讀助教；Gem 適合互動式引導；Codex 適合在指定工作區產生、修改與檢查檔案；Google Sheets 適合處理表單資料與基本分析；紙筆則適合保留第一判斷與價值取捨。工具若配置不當，學生容易誤以為「AI 回答得好」便代表「課程品質良好」。

OIP：先 Output，再 Input，最後 Process

OIP 是本單元最實用的流程框架。第一步寫 Output：交付的是講義、表單、課程原型、Agent 規格、案例討論題，還是企業試行計畫？第二步列 Input：哪些來源可用、哪些不能用、哪些資料要去識別、哪些內容只是候選？最後才設計 Process，分清楚教師先做、AI 協助、人工覆核與退回修正的環節。

這個順序可以避免兩種常見問題。第一種是「資料還沒盤點，就要求 AI 寫正式內容」。這會讓 AI 很容易補故事、補案例、補不存在的事實。第二種是「流程看起來很自動，卻沒有人知道哪裡該停」。例如 AI 產生題庫後，誰檢查來源？題目是否符合課程目標？學生是否能完成？答錯時要怎麼補救？如果這些沒有寫進 Process，工具越順手，風險越大。

填寫 OIP 時，每一列都應使用可檢查的句子。「整理資料」過於抽象，可改為「讀取三份來源，分成可正式引用、需人工確認、不可使用三類，並說明理由」。「做講義」則可寫成「產出一個學員能直接操作的單元，包含案例、No AI 活動、AI 活動、Prompt、填答區、完成品範例與來源」。這樣一來，Codex 能掌握工作要求，品管者也知道查核依據。

Agent 是有明確權責的工作角色

本課將 Agent 定義為一個工作角色：依任務規格接收輸入、執行步驟、產出固定格式，最後接受檢查。這個角色可以由 AI、教師或同學擔任。角色名稱並不重要，權責與工作邊界才是判斷分工是否有效的依據。

一個合格的 Agent 任務卡至少要回答八個問題：它負責什麼？不負責什麼？可以讀哪些來源？不能讀哪些來源？輸出格式是什麼？遇到不確定要怎麼標示？完成後誰檢查？什麼情況要退回？這八個問題比「用哪個模型」更重要。

例如「活動設計 Agent」可以把來源整理成學習任務，但不能新增未核對案例；「來源查核 Agent」可以確認資料是否支持主張，卻不能代替你決定課程重點；「文字檢查 Agent」可以修正翻譯腔與不自然句子，但不能改掉 Prompt 的數字、欄位與限制；「獨立覆核 Agent」可以指出不符合條件的地方，但要留下理由，讓你知道該改哪裡。

Review Gate：為 AI 協作設定檢核關卡

Review Gate 可譯為檢核閘門，指的是流程進入特定階段前，必須暫停並完成查核。它的功能類似課程製作流程中的放行關卡。

常見的檢核關卡包括：來源未核對前，不得寫成正式主張；測試資料未建立前，不得宣稱 Prompt 可用；學員填答區不能只是靜態表格；公開分享的材料不得含有裝置路徑、個資、金鑰或非公開資料；企業訓練案例不得將真實客戶資訊提供給雲端工具；AI 產生的管理建議也不得直接作為公司的正式判斷。

Review Gate 雖然增加一道程序，卻能避免早期錯誤持續擴大。專案最耗費時間的情況，往往是到了後期才發現方向、語氣與來源都有問題，活動也無法操作，最後必須全面重作。

案例拆解

案例：把一個模糊的課程需求交給 Codex

假設你要製作一個新單元，主題是「AI 輔助學生進行個案討論」。手邊有幾篇文章、一份舊講義、一些課堂紀錄，以及幾個候選 Prompt。此時最容易提出的指令是：「幫我整理成教材。」然而，這句話缺少使用對象、來源範圍與完成標準，也最容易導致內容失準。

比較好的第一步是寫任務卡：

• 工作資料夾：指定到你的課程專案資料夾。
• 最後交付：一份學員講義草稿、一份 Prompt 檔、一份來源表。
• 可用來源：公開文章、已核對的課程進度紀錄、舊講義。
• 不可用來源：私訊、未去識別學生資料、未公開客戶資料。
• 完成標準：直接對學員說話，有案例、活動、Prompt、填答區、完成品範例與來源。
• 第一個步驟：先盤點來源，不寫正文。

接著用 OIP 把工作拆開。Output 是「可直接給學員操作的單元」。Input 是「公開文章、課程進度紀錄、已核對案例」。Process 是「來源盤點、教學架構、No AI 活動、AI 活動、Prompt 測試、文字修正、獨立檢核、進度摘要」。到這裡，你才開始把任務交給 Codex。

依照這項安排，Codex 會先整理來源，不會一開始就直接撰寫完整文章。來源確認後，先完成一小段樣章；樣章通過檢核，再擴充為完整單元；最後依品管清單檢查語氣、活動、Prompt、來源與完成證據。課程製作需要這套可查核的流程，無法只靠連續對話維持品質。

案例：多 Agent 如何守住讀者視角

某企業工作流程課程的講義製作規則中，有一條非常重要：學員講義必須直接服務正在操作的學員。每一段都要回答「我現在要做什麼？為什麼要做？我要使用哪個工具、檔案、欄位或按鈕？完成後應該看到什麼？如果沒有看到，先檢查什麼？」^SRC-0903

這條規則可以轉成多角色檢查。活動設計角色先寫初稿；文字檢查角色找出第三人稱學員描述、帶課備忘或只有原作者才懂的說明；Prompt 角色確認提示詞是否完整可用；資料角色檢查起始素材是否足夠；獨立覆核角色則實際照著頁面操作。發現問題時要指出段落、影響與修正要求，再交回原負責角色處理。

多 Agent 的用途是把不同風險分開處理。原作者不容易看見自己的語氣錯置；Prompt 設計者可能低估測試資料；文字工具可能誤改關鍵條件；整合時也可能為了簡短而刪掉操作步驟。角色之間互相檢查，可以減少這些盲點。

案例：從 L0 到 L3，不要把聊天誤認成平台

AI Agent 商業平台課程把 AI 使用分成四層：L0 單次聊天、L1 可重複指令、L2 工作流程與 Skills、L3 Agent 商業平台。這個架構很適合放回課程設計。^SRC-0904

L0 是「我問一次，AI 答一次」。它適合發想，但不適合交接。L1 是「我把任務、限制、步驟、輸出格式寫清楚」。它開始有可重複性。L2 是「我把指令接上資料夾、來源、表格、Notebook 或 Skill」。它開始有工作空間與資料邊界。L3 是「多個任務串起來，有輸入、判斷、工具、輸出、紀錄與人工審核」。它才比較像可以放進組織運作的系統。

不必急著將課程提升到 L3，先確認目前所處的層級。L0 是請 AI 發想一次活動，尚不足以構成課程 Agent；即使有固定 Prompt，若缺少來源表、測試資料與交接檔，大致仍屬於 L1。當來源、Prompt、輸出、人工覆核與退件條件進入同一套流程，才開始進入 L2。L3 則需進一步納入明確的營運情境與責任設計。

從一次大型重做到可重複使用的 Skill

一個大型課程網站曾經出現幾種看似互不相關的問題：學員頁混入製作備忘、提示詞沒有提供必要脈絡、圖像文字錯誤、中文口吻不自然，以及 ZIP 缺少提示詞引用的知識。這些問題不能只靠「再仔細一點」解決，因為每一類錯誤需要不同的專業檢查。

後來的做法，是把工作拆成內容、來源、提示詞、視覺、資料、整合與獨立品管。每個角色只處理明確範圍，並在進入下一階段前通過 Review Gate。作者不能自己宣告內容已通過；來源 Agent 也不能因為找到網址，就順便決定教學上應該如何解讀。

下載多 Agent 協作與 Skills 沉澱案例包

案例包沒有放入具名企業、內部發布紀錄或原始檢討報告，只保留可遷移的方法。請先用 Agent 分工畫布設計自己的團隊，再為每個角色填上輸入、交付物、可修改範圍、不得修改範圍與 Review Gate。

接著選一項反覆發生的工作，判斷它是否適合做成 Skill。一個真正可用的 Skill 至少要有啟用條件、最小輸入、固定步驟、允許工具、輸出檔案、常見錯誤、停止條件與驗收規則。把一般說明或測試程式放進 skills/ 資料夾，並不會讓它自動變成可執行的 Skill。

Agent 執行時也要留下 execution manifest，記錄任務 ID、輸入摘要、允許工具、實際工具呼叫、輸出檔案、錯誤類型、心跳時間與下一步狀態。這份紀錄能幫助你分辨工作仍在進行、正在等待外部資源、已重複嘗試，或其實早已偏離任務。

先不用 AI

紙筆活動：先畫出你這門課的工作路線

請暫時不要開啟 AI 工具。拿一張紙，將接下來要改造的課程或教材畫成橫向流程，並標出六個節點：

1. 你要解決的課程問題。
2. 你已經有的來源。
3. 學員最後要交付的成果。
4. 你會讓 AI 協助的步驟。
5. 必須由你或同儕人工判斷的步驟。
6. 完成後要如何交接。

畫完後，在每個節點下方補一句「如果這裡出錯，會發生什麼事」。來源出錯，後面的案例會跟著錯；學員成果沒定義，活動很熱鬧卻無法評量；人工判斷沒有安排，AI 建議可能被當成結論；交接沒寫，下一位老師或助教只好重做一遍。

這張圖不必講究美觀，只要能辨識流程中斷的位置，就已達到活動目的。許多人一開始便使用 AI，卻尚未釐清流程。先將不確定的地方寫在紙上，比提出一句「幫我整理一下」更能改善後續品質。

No AI 填答區：工作路線初稿

再請 AI 進場

AI 活動：把紙筆路線改成 Codex 任務卡

現在可以使用 AI。第一份產出先設定為 Codex 任務卡，暫不撰寫教材。將剛才的紙筆填答提供給 AI，接著檢查三件事：是否自行補充未提供的來源、是否列出不可使用資料與人工覆核點，以及是否提出第一個可執行步驟。

如果 AI 直接開始撰寫教材，應先退回修正。問題通常在於任務規格不夠明確，未必是模型能力不足。可補上一句：「在我確認任務卡以前，不要開始撰寫正文。」這項限制就是 Prompt 中的檢核關卡。

下一步，把任務卡轉成 OIP 表。檢查 Output 是否具體；Input 有沒有分成可用、待查、不可用；Process 是否包含來源盤點、樣章、Prompt 測試、品管與交接。少一項，流程就還不能開工。

AI allowed 檢核區

引導式工具

這一頁使用「旗艦課程設計室」的 Codex／OIP 匯出模式，不另設第八套工具。第一次測試請使用合成資料，不要直接使用尚未整理的真實課程或企業資料。測試目的在於確認工具是否遵守來源範圍、輸出格式與人工覆核要求。

測試資料與預期輸出

請使用以下三筆測試資料檢查 Prompt 是否穩定。

如果 AI 在錯誤案例中仍接受所有資料，應修正 Prompt，而非直接修改輸出。請在 Prompt 中明確列出禁止事項，並要求 AI 先完成來源風險分類。

自助填答

你的 Agent 任務卡

你的 Review Gate 清單

完成品範例

以下提供一份可供改寫的課程專案範例。重點在於讓協作者理解目前狀態，並能立即判斷下一步。

課程單元協作工作包

任務摘要 將「AI 輔助個案討論」設計為 60 分鐘課堂活動講義。學生先在不使用 AI 的情況下閱讀個案並標出決策點，再使用 AI 產生反例、追問與可能後果，最後撰寫自己的判斷備忘錄。

Output 一份學員講義草稿、一張 Prompt 卡、一份測試資料表、一份來源表、一份交接摘要。

Input 可用來源：公開文章、已核對舊講義、去識別課堂紀錄。 待確認來源：社群貼文摘要，需回原文核對日期與全文。 不可使用：學生姓名、私訊、未公開企業資料。

Process 先完成來源盤點，再撰寫 800 字樣章；樣章通過後，補齊活動、Prompt 與填答區；使用三筆測試資料測試 Prompt；語文修正僅處理可見文字；獨立品管檢查受眾、來源、操作、Prompt 與完成證據；最後完成交接紀錄。

多 Agent 分工 來源查核 Agent：列出正式引用、待查、不可用。 活動設計 Agent：把來源轉成學習任務，不新增未核對案例。 Prompt Agent：將自然語言需求整理成可測試的任務規格，建立正常、邊界、錯誤三筆測試。 語文 Agent：修台灣繁中語氣，不改數字、Prompt、來源。 獨立檢核 Agent：依退回條件指出問題與影響，不在沒有紀錄的情況下直接改稿。

Review Gate 來源未核對，不得寫成正式主張。 Prompt 未測試，不得標示為可用。 學員填答若不能輸入，不得稱為工作表。 出現裝置路徑、個資或未公開資料，不得進入學員頁。 內容若寫成帶課備忘口吻或把學員當成被描述的對象，退回重寫。

交接摘要 目前已完成任務卡、OIP、學員講義、來源表與三筆 Prompt 測試。正常案例能產生反例與追問；邊界案例在來源不足時會先要求補充資料；錯誤案例會拒絕使用姓名、私訊與未公開企業資料。公開連結已逐一開啟核對，學員頁未出現裝置路徑或個資。下一版若更換案例，須重新執行同一組測試並記錄差異，無須重新設計整套流程。

退件案例一：看起來完整，其實沒有來源

下面是一段很常見的 AI 產出：

「本單元將帶領你理解 AI 如何重塑個案教學，並透過多 Agent 協作完成高品質教材。你將學會如何整合來源、設計活動、產生 Prompt 與完成課堂應用。」

這段文字雖然通順，仍不符合放行條件。它缺少證據、操作與完成標準：「高品質」由誰判斷？「整合來源」包含哪些來源？「完成課堂應用」需要提交什麼？這類文字看似完整，學員卻無法判斷下一步。

你可以把它退回成這樣：

「請先選一份你已核對的公開文章、一份課程紀錄與一份舊講義。把三份來源分成三欄：可直接引用、需要人工確認、不能使用。完成後，請寫下你要讓學生練習的判斷動作，例如提出反例、比較方案、標示證據或修正結論。若你無法指出來源與判斷動作，先不要請 AI 產生正式教材。」

修正後的文字未必華麗，但學員知道要完成什麼，品管者也能依據要求查核。Codex 工作流程提醒我們：文字通順只是基本條件，不能視為完成證據。

退件案例二：Prompt 很長，但沒有測試資料

另一個常見問題是 Prompt 寫得非常長，限制、角色、語氣、格式都列了，卻沒有測試資料。沒有測試資料的 Prompt，就像沒有考題的評量標準。你只能說它看起來合理，不能說它可用。

例如，你設計一張 Prompt，要求 AI 針對管理個案提出反例、利害關係人與後果推演，並註明「不要直接給答案」「請保留學生判斷空間」「請引用來源」。這些要求都合理；若缺少短個案、指定來源與錯誤案例，仍無法確認模型遇到模糊資料時是否會自行補充情節。

每一張正式 Prompt 至少配三筆測試資料：正常案例確認能否完成任務；邊界案例確認來源不足時會不會先追問；錯誤案例確認它是否避開個資、未公開資料與不存在的來源。測完再記錄輸出摘要、通過或退件、退件原因與修正句。紀錄不必長，來龍去脈得查得到。

工作流可以直接立一條規矩：沒有測試資料的 Prompt，只能叫草稿，還不能叫教學工具。

修正案例三：協作摘要寫成工作心得

交接檔最常見的失敗，是寫成「今天做了很多，也學到很多」。這種文字對下一位接手者沒有幫助。下一位接手者需要知道：哪些檔案是目前版本、哪些來源已讀、哪些來源不能用、哪些驗證已做、哪些尚未完成、下一步先做什麼。

不合格的交接：

「本次已完成課程設計初稿，整體方向是用 AI 協助教師完成教材，後續可再優化 Prompt 和活動。」

合格的交接：

「本次已完成一份 60 分鐘個案討論講義、來源表與三筆 Prompt 測試。已核對兩篇公開文章與一份授權講義；社群貼文只保留為選題線索，沒有放進正文。正常案例可產生兩個反例與三個追問；來源不足時會先追問；包含個資的輸入會被拒絕。下一版要先確認案例連結仍可開啟，再重跑三筆測試；若輸出直接替學生下結論，就退回 Prompt 卡調整禁止事項。」

兩段的差異十分明確。合格交接的價值不在篇幅，而在於接手者能辨識第一個步驟。交接檔也不應寫成課後心得，它保存的是工作狀態與責任。

你可以怎麼練習

45 分鐘活動：一個模糊需求如何變成可派工任務

這個活動可以放在 A12，也適合教師培訓或企業內訓。每組先選一個模糊需求，例如「做一份 AI 課程講義」「把學生作業整理成報告」「建立一個課程助教」「分析一次互評資料」，全組先不用 AI，在紙上寫工作路線。

前 10 分鐘，每位成員各自寫下最終交付物。同一項需求在不同人眼中往往差異很大：有人認為要製作 PDF，有人預期是網頁或表單，也有人只想到摘要。先確認這些差異，才不會迫使 AI 猜測成果形式。

第 10 到 20 分鐘，小組整併成一張任務卡。已有共識的項目列入主表，仍有歧見的項目則列為「待確認」。分歧不必當場全部解決，先明確記錄即可。

第 20 到 30 分鐘，小組把任務卡轉成 OIP。Output 寫具體作品，Input 分成可用、待查、不可用，Process 至少包含來源盤點、樣章、測試、QA、交接五段。少了 QA 或交接，全組就回到流程表補齊。

第 30 到 40 分鐘，使用 Prompt 卡請 AI 產出多 Agent 分工。每組查核兩件事：AI 是否自行補充未提供的來源？是否列出退件條件？任何一項不符合要求，都要退回修正 Prompt。

最後 5 分鐘，每組說明一個「原本可能讓 AI 自行猜測的地方」。這項分享能讓全班具體理解任務定義的重要性。

90 分鐘活動：Prompt 測試與退件會議

如果你有更多時間，可以把活動延伸成退件會議。每組先設計一張 Prompt，再和另一組交換測試。交換時不要只測正常資料，要故意放入邊界案例與錯誤案例。

測試組要記錄三件事。第一，Prompt 是否要求補資料。第二，Prompt 是否阻止不該使用的資料。第三，Prompt 是否輸出可檢查格式。若 AI 只是寫出漂亮內容，卻沒有標示來源、待查與人工覆核，測試組要退件。

被退件的小組不能直接修改輸出，必須回到 Prompt 調整。這是本活動的教學重點。許多學員看到 AI 輸出不理想，會要求它「再寫好一點」；正式工作流程不能只依賴重寫。你必須判斷失敗原因：限制是否不夠清楚、輸出格式是否不夠明確、測試資料是否不足，或任務本身尚未定義。

活動結束時，每組要提交「修正前 Prompt、失敗輸出摘要、退件原因、修正版 Prompt」。這份紀錄本身就是學習證據，比單獨呈現最後一版 Prompt，更能證明學生理解人機協作流程。

練習所需材料

入門材料

課堂要介紹 Codex 與多 Agent，不必一開始就使用大型資料集。最小資料包準備四份材料即可。

第一份是模糊需求短文。用 80 到 120 字描述一個真實但不含個資的任務，例如「我想把一堂 AI 個案討論課做成網頁講義，學生要能先紙筆判斷，再用 AI 提問，最後交一份決策備忘錄」。這份短文用來測任務卡。

第二份是來源清單。準備 5 筆來源，其中 2 筆可直接使用，2 筆需要人工確認，1 筆不可使用。不可使用的來源可以是「學生 LINE 對話截圖」或「未公開企業客戶資料」。這份清單用來測來源分級。

第三份是舊版內容。它可以是一段看似完整但口吻錯置的講義，例如把讀者寫成被管理的對象，或把課堂操作寫成帶課備忘。這份材料用來練習讀者視角檢查。

第四份是完成標準。列出 6 到 8 條，例如「直接對學員說話」「有 No AI 活動」「有 AI 活動」「Prompt 有三筆測試資料」「來源可回查」「交接檔可讓下一位接手」。這份標準用來測 QA。

有了這四份材料，你就能讓學生完整走一次從任務、來源、撰寫、測試、退件到交接的流程。

進階材料

進階資料包可以加入三種材料。第一種是衝突來源，例如舊講義和新的使用者修正互相矛盾。學生得依資料時序與權責採用最新明確修正，不能只挑自己方便的版本。

第二種是工具限制，例如 Gemini Notebook（NotebookLM） 不能直接讀某種檔案格式，必須轉成 Markdown 或其他可讀載體。學生要練習把工具現況寫進教材，不要用想像補功能。

第三種是分享邊界。例如完整工作紀錄可以支撐方法，卻不能把裝置路徑、帳號、金鑰或非公開客戶名稱放進學員頁。學生要練習把可識別資料改寫成去識別案例摘要，並把完整追溯資訊留在受控的來源表。

這些進階材料會讓活動更接近真實工作。真實專案很少同時具備乾淨來源、一致規則、完整工具支援與全數可公開的資料。學生除了按步驟完成，也要在限制裡保留判斷。

常見問題與排除

AI 未確認需求便開始撰寫正文時，如何處理？

請先檢查 Prompt 是否將「不要寫正文」列為明確規則。若只寫「請先整理」，模型可能在整理後直接開始撰寫。可改成：「在我確認任務卡以前，不要撰寫正式內容。若你準備開始撰寫，請先停下來列出需要我確認的三件事。」如此便能明確設定檢核關卡。

AI 把待確認來源寫成正式來源怎麼辦

將來源表的格式與選項明確固定。每筆來源都要有 source_status，且僅接受 可直接使用、待人工確認、不可使用；正文也只能引用 可直接使用 的來源。來源狀態不完整時，AI 應先回報資料缺口，暫不撰寫正式主張。

學生覺得交接檔很麻煩怎麼辦

不必先花時間說明交接檔的重要性，可以直接安排一次交換。A 組將進行中的任務交給 B 組接手；若缺少交接資料，B 組很快就會在來源、版本、測試狀態與不可更動項目上遇到困難。實際經歷一次接手障礙，通常比口頭說明更有效。

多 Agent 會不會讓流程變複雜

有可能，因此不必為了數量增加 Agent。當任務確實包含不同風險時再拆分角色；最小可行分工通常只有內容、測試與品管三組，任務規模擴大後，再分出來源、Prompt、語文、整合與交接。分工的價值在於及早發現錯誤，而非增加角色名稱。

課後作業：把你的流程留下來

作業一：寫一份可以交給別人的開工說明

課後請選擇一項確實會繼續執行、規模也能妥善管理的課程任務。可以是「將一週案例討論改為 No AI 加 AI 追問活動」、「將一份舊講義改為學員可填寫的工作表」，或「建立一個課程助教的來源與題庫規格」，再使用本單元的任務卡格式撰寫開工說明。

這份開工說明至少包含九項：任務摘要、最後交付物、使用對象、可用來源、待確認來源、不可使用資料、完成標準、第一個可執行步驟、退件條件。只寫大方向還不夠；另一位同事或另一個 Codex 打開後，應該知道第一步讀哪份來源、先產出什麼、何時不能繼續。

完成後進行一次獨立閱讀。暫時放下作者身分，改用下週接手者的角度檢查文件。文件必須回答三個問題：從哪裡開始？哪些資料不能使用？達到什麼條件才算完成？只要其中一題仍含糊，就應先修正開工說明，暫緩撰寫 AI 正文。

作業二：建立一份小型退件清單

請為自己的任務建立一份小型退件清單。條目不必多，但每一條都要能實際阻止錯誤進入下一階段；可以先從來源、受眾、Prompt、資料與交接五類開始。

來源退件條件可以是：沒有公開連結或可追溯證據，不得寫成正式主張。受眾退件條件可以是：文字將讀者寫成旁觀者，未直接說明讀者要完成的工作。Prompt 退件條件可以是：沒有正常、邊界、錯誤三筆測試資料，不得標示為可用。資料退件條件可以是：內容含有個資、非公開客戶資料、未公開財務或帳號資訊，一律退回進行去識別處理。交接退件條件可以是：沒有列出已驗證、尚未完成與下一步，不得交給整合者。

這份退件清單的目的，是避免團隊到了最後一天才發現整套作品無法使用。事先說明標準，前一階段的負責人知道如何完成工作，後一階段的檢核者也有明確依據可以要求修正。

作業三：做一次接手測試

找一位同學或同事，只給他看開工說明、OIP 表和交接大綱，不做口頭補充。請對方寫下他認為的下一步，再和你的預期比對。

如果對方判斷的下一步與你的預期不同，應先回頭檢查文件，而非認定對方沒有看懂。常見原因包括 Output 過於抽象、Input 未分級、Process 缺少檢核關卡，或完成標準只剩形容詞。接手測試的價值，在於找出那些作者以為已經說明清楚、實際上只有自己理解的內容。

作業四：把一次失敗寫進紀錄

請保留至少一次 AI 產出失敗的紀錄，不要只留下成功版本。失敗輸出摘要、失敗原因、修正 Prompt，以及修正後是否通過，都能成為下一次課程的教材。學生需要理解的是 Prompt 如何經過測試與修正，最後達到可用標準。

失敗類型也要標示清楚：任務理解錯誤、自行補充來源、格式不符、使用不可用資料、缺少人工覆核、語氣錯置、輸出過度自信。累積幾次後，通常會發現課程最常出錯的地方在任務界線，未必是模型能力。

評量方式

基礎通過

你已完成任務卡、OIP 表、多 Agent 分工與交接大綱，而且每一份都能被另一位同學理解。你的 Prompt 至少有一筆正常測試資料，且 AI 沒有直接跳過任務卡開始撰寫正式內容。

進階通過

你已完成三筆測試資料，包含正常、邊界與錯誤案例。AI 在邊界案例會要求補來源，在錯誤案例會拒絕使用不可公開資料。你也能說明哪一段由 AI 協助、哪一段必須人工判斷。

優良表現

你已完成可用流程，並留下失敗紀錄與修正理由。另一位接手者可以根據交接檔繼續工作，無須重新詢問背景。你的退件清單足以阻止具體錯誤，不會只停留在「內容要正確」「語氣要自然」等抽象要求。

協作摘要最低欄位

讓下一位協作者能直接接續工作

交接檔是下一位接手者開始工作的依據，不應只記錄作者自己的工作心得。最低欄位至少七項：委託人或授課者的原始需求、本輪實際完成、已讀來源、已寫入或產出的檔案、已做驗證、尚未完成、下一步建議。每一項都應寫成可執行的句子。

例如「已做驗證」不要只寫「已檢查」，要寫成可重做的紀錄：「已用正常、邊界與錯誤三組資料測試；正常資料通過，邊界資料保留不確定性，錯誤資料被拒絕。」尚未完成的項目也要直說：「Prompt 目前只有正常案例，尚未測邊界與錯誤資料，因此不能標示為可交付。」這樣下一位接手者不必猜哪些只是作者自評，哪些是真正做過的檢查。

如果只記得一項原則，請記住：交接檔要讓接手者不必再追問三件事，包括「目前版本是哪一個」「哪些來源可以使用」「下一步應先做什麼」。能清楚回答這三個問題，AI 協作才可能成為課程、團隊或組織可持續採用的工作方法。

實務補充：三項常見風險

Prompt 測試失敗案例：模型配合要求，產出方向卻有偏差

以下是一個常見失敗。你請 AI 將課程活動整理成學員講義，Prompt 也註明「不要編造來源」。輸出包含開場、活動、討論題與總結，看似完整；仔細查核後，卻發現它將「待查文章」列為正式閱讀，將「可能適合設計成活動」寫成「本課已採用」，連尚未測試的 Prompt 都標示為「可直接使用」。這類問題不一定會出現明顯錯誤，卻會將草稿包裝成定稿。

遇到這種情況，只要求 AI「更保守」並不足以解決問題。應回到測試資料，明確標示來源狀態：至少放入一筆可用來源、一筆待查來源與一筆不可用來源；正式段落只能使用第一類，待查來源列入「下一步查核」，不可用來源則排除。完成後，再檢查輸出是否遵守規則。

第二種失敗是 AI 會把「測試通過」寫得太快。你只給它一筆正常案例，它就說 Prompt 可以使用。這時要退回，因為正式教學至少要看正常、邊界、錯誤三種情境。正常案例檢查它能不能做事；邊界案例檢查它會不會追問；錯誤案例檢查它會不會拒絕不該使用的資料。三種都過，才有資格放進講義。

第三種失敗，是 AI 將輸出寫成教師備課稿。內容會描述「課堂可以安排討論」，卻沒有告訴學員此刻要完成什麼。這反映的是受眾錯置；每一段都必須改為學員當下可以執行的活動，並留下完成證據。

Agent 權責衝突案例：兩個角色都以為自己有最後決定權

多 Agent 專案最容易衝突的地方在權責。假設來源 Agent 認為某篇 vocus 文章可以支撐核心主張，活動設計 Agent 便寫進正文；獨立檢核 Agent 隨後發現來源表只有書目資訊，沒有人重新打開全文核對。這時誰說了算？事前沒有規則，三個角色都能主張自己有理。

較合適的設計，是將權責分為「建議權」「採用權」「放行權」。來源 Agent 有建議權，可以指出某項來源可能可用，也可以標示它能支撐哪一項主張。活動設計 Agent 有採用權，可以決定是否將來源改寫成活動或案例。獨立檢核 Agent 有放行權，可以要求回到原文核對，或要求將該段改列為「延伸閱讀」，不得作為核心證據。三種權責清楚區分，才能避免角色之間發生決策衝突。

另一個衝突是語文 Agent 和 Prompt Agent。語文 Agent 看到 Prompt 句子很長，想改得順一點；Prompt Agent 則擔心語文修正改掉限制條件。這時規則要很清楚：語文 Agent 可以修正文段、活動說明與學員提示，但不能改 Prompt 裡的數字、欄位、禁止事項、輸出格式與停止條件。若真的覺得 Prompt 不自然，只能提出建議，由 Prompt Agent 或主整合者決定是否採用。

第三個衝突發生在整合 Agent 與活動設計 Agent 之間。整合 Agent 為了維持頁面一致，可能會刪減段落或合併表格；學員講義中有些看似重複的內容，實際上是必要的操作條件。例如「不可使用資料」同時出現在任務卡、Prompt 與交接檔，是因為不同階段都需要提醒。整合 Agent 可以統一格式，但不能刪除會改變操作條件的句子。

退件與交接實例：一次退件要能讓下一輪變好

退件是具體的品質管理程序，不應只寫一句「重新製作」。一份有效的退件紀錄可以使用四欄：原句或原段、問題、影響、修正要求。

例如原段寫：「本活動讓學生理解 AI 在個案教學中的價值。」問題是完成證據不可觀察；影響是學員不知道要交什麼，老師也無法評量；修正要求是改成「請學生先寫三個不使用 AI 的判斷，再用 AI 產生兩個反例，最後交一份 150 字修正理由」。這樣作者知道要怎麼改，接手者也知道退件不是主觀喜好。

再例如原段寫：「使用來源包含 Facebook 貼文。」問題是沒有單篇連結、日期與全文核對；影響是不能當正式引用；修正要求是「改列為口吻素材，正文主張改由已核對文章或可追溯紀錄支撐」。這種退件不只是修字，而是保護來源等級。

交接時也要留下退件歷史，光寫「已修正」沒有辦法重做檢查。可以寫：「第一次退件是來源狀態不清與 Prompt 沒有邊界測試；第二版已把社群素材改列為選題線索，補上來源不足與個資兩個案例，並記錄模型輸出。複驗時，來源不足案例仍會補寫不存在的公司背景，因此在 Prompt 新增『沒有來源就停下來提問』，第三版才通過。」下一位看完就知道規則為什麼存在，換模型或換案例時也知道先重測哪一題。

本單元成果與下一步

完成本單元後，Codex 與多 Agent 的價值應已清楚：它們能協助你將判斷轉化為可執行、可查核的工作。若要將工作交由他人或 AI 協作，必須先寫明交付物、來源、邊界、流程、檢查與交接。AI 可以負責多個工作階段，方向、檢核關卡與放行標準仍由你決定。

下一單元會將這套方法轉用於企業訓練。大學課程可以安排 18 週，企業訓練卻可能只有 3 小時。時間縮短，仍須保留核心判斷。你會練習將一門完整課程轉化為企業現場可用的高密度判斷任務，並設計 30 天行動與成效證據。

來源與延伸閱讀

標示網路連結者可直接開啟；未附連結者為已去識別或內部教學實作紀錄，僅用來說明本頁內容依據，不提供原始學生、企業或私人資料。

^SRC-0901 Codex 四小時工作坊學員 Prompt 包，2026-05-25；收錄任務卡、來源盤點、OIP 與協作紀錄範例。

^SRC-0902 多 Agent 課程專案實作紀錄，2026-07-25；收錄 Agent 分工與獨立檢核角色範例。

^SRC-0903 企業訓練學習手冊寫作規範，2026-07-23；收錄讀者口吻、完整提示詞與退回規則。

^SRC-0904 CSKM MBA 6022 AI Agent 商業平台課程設計書，2026-07-20；可對照 L0-L3、PLAN.md、HANDOFF.md 與 Human-in-the-loop。

^SRC-0905 vocus 文章「這次，教大學生的是：Codex！」，https://vocus.cc/article/6a14e622fd89780001bb1342↗ ，2026-05-26；延伸閱讀 Codex 教學現場與工作流程轉化。

本頁圖解

本頁圖解從聊天到可交接專案圖像載入中

本頁圖解OIP 工作流程表圖像載入中

本頁圖解多 Agent 泳道圖圖像載入中

本頁圖解Review Gate 檢查關卡圖像載入中

本頁圖解交接檔的必要資訊圖像載入中