OpenAI 發佈 12 個 Codex 官方案例庫，手把手教到你會為止
OpenAI 的開發者關係負責人 Romain Huet 宣佈 Codex 上線了一個官方案例庫。
12 個實打實的使用場景，每個都帶完整的操作步驟、Prompt 範本，甚至可以一鍵在 Codex 應用裡打開。
“
我們剛剛發佈了 Codex 案例庫！這是一個涵蓋程式設計和非程式設計任務的實用案例集合，展示了 Codex 的真實使用方式。我特別喜歡的一點是：如果你安裝了 Codex 應用，可以直接一鍵打開每個案例的 Starter Prompt！
這 12 個案例覆蓋了從程式碼審查到做 PPT、從資料分析到做遊戲的各種場景，有些確實刷新了我對「AI 程式設計工具」邊界的認知。
逐個來看。
PR 自動審查
第一個案例是 GitHub PR 審查，也是上手門檻最低的一個，難度標註為 Easy，耗時大約 5 秒。
做法很直接：把 Codex 接入你的 GitHub 倉庫，它會在每個 PR 提交後自動掃一遍，找出潛在的回歸問題、缺失的測試、以及文件漏洞。
你也可以選手動模式，在 PR 評論裡 @codex review，它就來了。
發現問題之後呢？直接在評論裡回一句 @codex fix it，Codex 會啟動一個雲端任務自動修復。
這裡面有個細節值得一提：你可以在倉庫裡放一個 AGENTS.md 檔案，定義審查規則。比如「拼寫和語法錯誤標為高優先順序」「缺少測試覆蓋標為中優先順序」，Codex 會根據離每個檔案最近的 AGENTS.md 來調整審查策略。
Starter Prompt：
“
@codex review，檢查安全回歸、缺失測試、以及有風險的行為變更。
算是把 Code Review 這件事從「等同事有空」變成了「提交即審查」。
截圖變頁面
第二個案例是前端開發：把截圖和設計稿直接變成響應式 UI 程式碼。
難度中等，大約需要 1 小時。
流程是這樣的：你把設計參考圖（桌面版、移動版、各種互動狀態的截圖）丟給 Codex，同時告訴它你項目裡已有的設計系統、元件庫、色彩 token、排版規範。
Codex 會用你現有的元件和設計 token 來實現，而不是另起爐灶搞一套新的。
然後用 Playwright 打開瀏覽器，逐個螢幕尺寸對比。不對？繼續調。
Starter Prompt：
“
用截圖和說明作為參考，在當前項目中實現這個 UI。要求：復用現有設計系統的元件和 token，把截圖翻譯成倉庫裡的工具類和模式，匹配間距、佈局、層級和響應式行為，相容桌面和移動端。
這個案例的關鍵在於「復用」二字。Codex 會基於你已有的設計體系來寫程式碼，復用現成的元件和 token，這一點倒是和真人前端工程師的工作方式一致。
資料分析全流程
第三個案例，也是我覺得最適合非程式設計師的一個：資料分析。
難度中等，大約 1 小時。
這個案例的完整度讓我有點意外。它不只是「幫我畫個圖」，而是從資料匯入、清洗、合併、建模到最終報告，一條龍。
具體的步驟：
先定義問題。 比如「高速公路附近的房子，房價是不是更低？」問題越具體，Codex 越好辦事。
再設定環境。 在 AGENTS.md 裡定義項目規則：用什麼 Python 環境，資料夾結構怎麼放，原始資料放 data/raw/，清洗後的放 data/processed/，永遠不覆蓋原始檔案。
然後讓 Codex 自己看資料。 它會檢查檔案格式、編碼、每個資料集代表什麼、有那些候選主鍵、明顯的質量問題。
接著合併和建模。 在合併之前先做資料畫像，測試主鍵的唯一性和空值率，用試探性 join 看匹配率。建模則從可解釋的基線模型開始，statsmodels 和 scikit-learn 為主。
最後輸出報告。 可以是 Markdown 給同事看，Excel 給營運看，PDF 或 .docx 給老闆看。
這套流程其實就是一個標準的資料分析 pipeline，只不過以前是人寫程式碼跑，現在是 Codex 幫你寫幫你跑。
Starter Prompt：
“
我在這個工作區做資料分析項目。目標：搞清楚高速公路附近的房子是否估值更低。先讀 AGENTS.md 瞭解 Python 環境，載入資料集，描述每個檔案的內容、可能的 join key 和資料質量問題，然後提出一個可復現的工作流程。約束：優先用指令碼而非 notebook 狀態，不要編造缺失值或合併鍵。輸出：環境配置計畫、資料清單、分析計畫、第一批要建立的命令或檔案。
做 ChatGPT 應用
第四個案例是高級玩法：把你的產品做成一個 ChatGPT 應用。
難度標註為 Advanced，大約 1 小時。
一個 ChatGPT 應用由三部分組成：
• MCP 伺服器：定義工具、返回資料、處理認證
• 可選的 Widget：一個在 ChatGPT 內渲染的 Web 元件（React 或原生 HTML/CSS/JS）
• 模型整合：ChatGPT 根據你的工具中繼資料來決定何時呼叫
Codex 在這裡的角色是幫你規劃工具介面、搭建 MCP 伺服器和 Widget 腳手架、配置本地 HTTPS 測試環境、實現認證流程。
工作流程分七步：先規劃（別一上來就寫，先想清楚核心使用者場景），然後選技術堆疊，搭腳手架，測試，迭代核心功能，最後才加認證和部署。
Starter Prompt：
“
用 $chatgpt-apps 和 $openai-docs 為 [你的場景] 規劃一個 ChatGPT 應用。要求：從一個核心使用者場景開始，提出 3-5 個工具及其名稱、描述、輸入輸出，建議 v1 是否需要 Widget，TypeScript 做 MCP 伺服器，React 做 Widget。輸出：工具規劃、檔案樹、測試 Prompt 集、風險和待定事項。
官方文件裡還貼心地列了常見坑：
別一開始就想把整個產品搬過來，先做一個核心功能。別寫一個巨大的 Prompt，拆成「規劃 → 搭建 → 認證 → 部署 → 稽核」五步。
別先做 UI，先把工具介面定義清楚。別跳過在 ChatGPT 開發者模式裡的實際測試。
iOS 和 macOS 開發
第五個案例面向 Apple 生態的開發者：用 Codex 搭建 SwiftUI 應用。
難度 Advanced，大約 1 小時。
核心思路是 CLI 優先。用 xcodebuild 命令列工具，不走 Xcode GUI，保持終端化的工作流程。如果覺得 xcodebuild 太繁瑣，可以用 Tuist 來簡化項目生成。
對於已有的 Xcode 項目，可以接入 XcodeBuildMCP 工具來做 Scheme 檢查、模擬器控制、截圖捕獲和 UI 自動化。
官方還提供了一系列專項 Skill：SwiftUI 專家、Liquid Glass 專家、性能審計、並行專家、檢視重構……每個都是一個可以載入的專項能力包。
Starter Prompt：
“
搭建一個 SwiftUI 啟動應用，並加入一個建構和啟動指令碼，我可以把它繫結到本地環境的 Build 操作上。
瀏覽器遊戲
第六個案例畫風突變：做遊戲。
難度中等，但官方標註為「長時間運行任務」，因為大量素材生成可能需要幾個小時。
流程值得展開說說。先寫一份遊戲策劃文件 PLAN.md，定義玩家目標、核心遊戲循環、操作方式、勝負條件、難度遞進、視覺風格、技術堆疊和開發里程碑。
然後在 AGENTS.md 裡配置 Codex 的行為規範：遊戲名稱、類型、技術堆疊（推薦 Next.js + Phaser 或 PixiJS 做渲染），以及要用到的 Skill。
這裡用到三個關鍵 Skill：
• Playwright Interactive：在真實瀏覽器裡測試遊戲，調整操控和 UI
• ImageGen：生成概念圖、精靈圖、背景、各種視覺素材
• OpenAI Docs：查最新的 API 文件
Codex 根據計畫生成第一版，然後你截圖反饋，它再調整，如此迭代。
Starter Prompt：
“
用 $playwright-interactive、$imagegen 和 $openai-docs 來規劃並建構一個瀏覽器遊戲。實現 PLAN.md，並在 .logs/ 下記錄工作日誌。
從寫策劃到出成品，一個人就能做一款瀏覽器小遊戲……
這也算是 Vibe Coding 的最佳註腳了。
自動做 PPT
第七個案例回到職場剛需：做 PPT。
難度 Easy，大約 30 分鐘。
用的是 PptxGenJS 庫來操作 .pptx 檔案，配合 ImageGen 生成視覺素材。
幾個關鍵原則：
先看再改。 改已有的 PPT 之前，先讓 Codex 檢查現有的幻燈片結構，匹配寬高比，對照渲染截圖來調整。
保持可編輯。 文字保留為 PowerPoint 文字對象，簡單圖表用原生 PowerPoint 圖表，不要把整張幻燈片柵格化成圖片。
驗證流程。 渲染成每頁 PNG 再檢查，檢測文字是否溢出畫布邊界，報告缺失或被替換的字型。
Starter Prompt：
“
用 $slides 和 $imagegen 編輯這個幻燈片：在每頁右下角加 logo，把文字左移並在指定頁面生成抽象數字藝術插圖，保持文字可編輯，按現有品牌風格新增幻燈片，渲染成圖片稽核，檢查溢出和字型替換問題，保存可復用的生成 Prompt。
30 分鐘，即可做一套品牌風格統一的 PPT 出來。
死磕難題
第八個案例的思路和其他的都不一樣：它教你怎麼讓 Codex 反覆迭代，死磕那些一次搞不定的難題。
這個案例的核心概念是「評估驅動的改進循環」。
很多任務並非「做了就對」，需要反覆最佳化。Codex 的做法是：檢查輸出 → 打分 → 決定下一步改動 → 再檢查再打分，循環往復，直到達標。
打分機制分兩層：確定性檢查（程式碼能不能跑、測試過不過）和 LLM 評審（可讀性好不好、輸出有沒有用）。
Starter Prompt：
“
這個工作區裡有個棘手的任務，我想讓你用評估驅動的改進循環來做。開始之前：讀 AGENTS.md，找到給當前輸出打分的指令碼或命令。迭代循環：每次只做一個聚焦的改進，每次有意義的改動後重跑評估，記錄分數和改動內容，直接檢查生成的產物，持續迭代直到總分和 LLM 評審平均分都超過 90%。約束：不要在第一個可接受的結果就停下來，除非新結果明顯更差否則不要回退，遇到瓶頸時說明卡在那裡。
這其實是把「進化演算法」的思路用到了 AI 程式設計裡，通過反覆評估和微調來逼近最優解，不追求一步到位。
Slack 發任務
第九個案例走的是整合路線：直接在 Slack 裡給 Codex 派活。
難度 Easy，5 分鐘搞定。
裝好 Slack 應用，連接倉庫和環境，把 @Codex 加到頻道里。然後在任何一個 Slack 對話線程裡 @Codex，附上你的需求，它就會啟動一個雲端任務。
做完之後會線上程裡貼回結果連結，你也可以去 Codex 雲端面板查看詳情。
Starter Prompt：
“
@Codex 分析這個線程裡提到的問題，並在 <環境名稱> 中實現修復。
官方建議：請求要具體，指明用那個倉庫和環境，大型程式碼庫的話還要引導 Codex 去看那些檔案或目錄。
這其實是把 Codex 變成了一個隨時待命的遠端程式設計師。產品經理在 Slack 裡描述 bug，@Codex，然後去喝杯咖啡回來看結果。
Figma 變程式碼
第十個案例是設計師和前端的橋樑：把 Figma 設計稿直接變成程式碼。
難度中等，大約 1 小時。
和第二個案例（截圖變頁面）的區別在於，這個直接從 Figma 的結構化資料入手，而不是從截圖。
流程分幾步：
先在 Figma 裡做好準備工作。用 Variables/Design Tokens 管理顏色、排版、間距，建構可復用的元件，別用散落的圖層，用 Auto Layout 實現響應式行為，命名規範清晰。
然後用 Figma Skill 的幾個關鍵命令：get_design_context 獲取節點的結構化設計資訊，get_metadata 獲取更詳細的中繼資料，get_screenshot 獲取精確的視覺參考。
最後用 Playwright 做視覺驗證，對比實際渲染效果和設計稿。
Starter Prompt：
“
實現這個 Figma 設計……先用 get_design_context 獲取目標節點或畫面……復用現有設計系統的元件和 token……桌面和移動端都要做響應式……用 Playwright 檢查 UI 是否匹配參考設計。
讀懂大型程式碼庫
第十一個案例特別適合新人：快速理解一個陌生的程式碼庫。
難度 Easy，5 分鐘。
你要做的就是問 Codex：這個系統的請求是怎麼流轉的？那些模組負責什麼？資料在那裡做校驗？改程式碼之前有什麼坑要注意？最後推薦我下一步該讀那些檔案？
Starter Prompt：
“
解釋程式碼庫中 <系統區域> 的請求流轉過程。包括：那些模組負責什麼，資料在那裡做校驗，改程式碼前有那些注意事項。最後告訴我接下來應該讀那些檔案。
還可以追問更深的問題：
• 那個模組負責業務邏輯，那個負責傳輸層，那個是 UI？
• 校驗邏輯在那裡執行，有那些隱含的假設？
• 如果我改了這個流程，那些關聯檔案和後台任務容易被忽略？
• 改完之後應該跑那些測試？
對於新入職的工程師來說，這相當於一個隨時線上的「程式碼庫導遊」。
5 分鐘就能對一個模組建立起初步認知，比翻文件快太多了。
升級 API 整合
最後一個案例是 API 遷移：把現有的 OpenAI API 整合升級到最新版本。
難度中等，大約 1 小時。
這個案例直面一個現實問題：換模型不是改個模型名就完事的。API 參數可能變了（比如 GPT-5.4 新增了 phase 參數），模型行為可能不同導致 Prompt 需要調整，還需要建評估流水線來防止回歸。
Codex 的做法是先盤點：當前用了那些模型、那些 endpoint、那些工具呼叫假設。然後製訂最小遷移計畫，只改必須改的。更新 Prompt 時參考最新的模型指南。最後標記出所有需要人工稽核的 Prompt、工具或響應格式變更。
Starter Prompt：
“
用 $openai-docs 將這個 OpenAI 整合升級到最新推薦的模型和 API 特性。具體來說，尋找最新的模型和 Prompt 指南。盤點當前的模型、endpoint 和工具假設，制定最小遷移計畫，保留現有行為（除非新 API/模型要求改變），根據最新指南更新 Prompt，標記所有需要人工稽核的變更。
◇ ◆ ◇
回過頭來看這 12 個案例，有幾個觀察。
Codex 應該是在有意模糊「程式設計工具」和「通用工作工具」之間的界限。做 PPT、分析資料、做遊戲，這些案例裡有一半和寫程式碼沒什麼直接關係。
另一個值得注意的是 AGENTS.md 的檔案。它在幾乎每個案例裡都出現了，承擔的角色類似於「給 AI 的工作手冊」。
定義好規則，Codex 按規則辦事。
這本質上是一種新的協作範式：你只需要定義規則和目標，剩下的讓 AI 自己去執行。 (AGI Hunt)