最近整理了一些自己使用 Codex 完成的專案實作： https://ai.duncan.tw/codex/
這些內容原本是準備拿來跟單位內的同事分享、討論。一開始，我把每個專案整理成獨立的 Markdown 文件，但後來發現，不同專案之間要來回切換、查找與分享，其實有些繁瑣。既然內容都已經整理好了，我乾脆把它們封裝成一個互動式 HTML 教案網站，再部署到自己的網站上。現在可以依照專案編號、標題、類型或關鍵字搜尋，也能直接切換不同教案，閱讀和分享都方便許多。
這次整理的不是 24 個單純的成果展示，而是 24 個真實專案的執行紀錄。內容涵蓋網站建置與修復、系統開發、內容產製、文件分析、市場與產業研究、活動及旅程規劃、Skill 開發、教學設計、證據整理與資料驗證等不同工作情境。
每個 Case 都會盡量保留完整的工作脈絡，包括：
‧ 一開始想解決什麼問題。
‧ 如何把模糊需求整理成 AI 可以執行的工作。
‧ 提示詞與角色指派如何影響結果。
‧ 如何建立規劃書與工作 List。
‧ 哪些工具可以授權 AI 使用，哪些動作仍要由人核准。
‧ 執行過程發生了哪些偏差。
‧ 每一輪修正 Loop 改善了什麼。
‧ 最後如何用文件、數據、畫面或實際環境驗證成果。
‧ 如果重新執行，可以怎麼改寫提示詞與檢查清單。
網站也分成初學者、管理者與技術人員三種閱讀視角。同一個專案，不同角色關心的事情其實不太一樣：初學者需要先理解工作怎麼拆解，管理者會在意範圍、風險與驗收，技術人員則比較關心工具、系統邊界與測試證據。
我自己使用 Codex 時，非程式開發工作，通常不會一開始就建立很長的 AGENTS.md。我的習慣是先讓 Codex 理解問題，再共同建立幾份會隨專案持續變動的文件：
‧ 規劃書：負責專案方向、工作範圍、限制與重要決策。
‧ 工作 List：負責進度、驗收條件、待辦事項與人工停止門。
‧ 交接文件：負責在對話太長或更換新 Chat 時，恢復目前狀態、既有決策、已知問題與下一步工作。
‧ AGENTS.md：視需要使用，而且盡量保持很短，只負責告訴新的 Chat 應該先讀哪些文件、閱讀順序，以及哪些規則不能跳過。
也就是說，我不會讓 AGENTS.md 取代規劃書、工作 List 或交接文件。真正持續更新的專案狀態仍然放在前三者；AGENTS.md 比較像一張入口說明，幫助新的 Chat 找到正確的專案脈絡。
只有在程式開發，或製作需要跨裝置、跨專案，甚至跨不同 AI 框架使用的 Skill 時，我才會更固定地加入這類通用宣告，避免每次更換環境都要重新解釋使用方式。
我一直覺得，使用 AI 工具本身其實沒有那麼困難。真正困難的是：我們掌握的知識有多廣、能不能把問題說清楚，以及最後知不知道該如何驗證 AI 給出的結果。
AI 確實放大了我們原本的能力，但前提是我們本來就得有一些東西可以被放大。如果原本的能力是零，那再怎麼乘、怎麼放大，最後還是零啊！
最近不少分享文章都提到，現在提示詞已經沒那麼重要了，只要把具體的工作交給 AI，它自然就能完成。這個說法不能算錯，但也沒有那麼簡單。
問題是，我們怎麼知道自己認為「夠具體」的任務描述，AI 真的看得懂？我們有沒有交代正確的背景、輸入資料、限制條件與驗收方式？當 AI 做出一個看起來很完整的結果時，我們又有沒有能力判斷它是真的完成，還是只是把答案包裝得很像完成？
我覺得真正值得討論的地方，其實就在這裡。所以這套教案不只展示成功結果，也保留了不少描述不精確、方向偏移、工具受限、資料不足、驗證失敗，以及後續如何修正的過程。因為真正能被重複使用的，往往不是最後那個檔案，而是我們如何發現問題、修正假設，並建立證據確認成果的整套方法。
既然這些內容都已經整理過，也移除了不適合公開的敏感資訊，我就乾脆一併分享出來。或許能提供一些不同的 Codex 實作思路，也讓大家看到 AI 進入真實工作後，實際會遇到哪些問題。
題外話，我們最近也在規劃一個付費的實作工作坊，目前正在招募有興趣的參與者。如果你也想實際動手做做看，可以點擊每份教案左上角的「WORK WITH AI LAB」，了解相關資訊： https://ai.duncan.tw/
回應管理, Pingbacks:
這篇文章還沒有 回應管理/Pingbacks ...
讀者回應:
