OpenAI 發佈 12 個 Codex 官方案例庫,手把手教到你會為止

作者:AGI Hunt
日期:2026年3月28日 上午6:03
來源:WeChat 原文

整理版優先睇

速讀 5 個重點 高亮

OpenAI 推出 Codex 官方案例庫:12 個真實場景,手把手教你用 AI 做嘢

整理版摘要

呢篇文章係由 OpenAI 開發者關係負責人 Romain Huet 宣佈 Codex 上線咗一個官方案例庫。佢包含12個實打實嘅使用場景,每個都有完整嘅操作步驟同Prompt模板,仲可以直接喺Codex應用入面一鍵打開。呢批案例覆蓋咗程式碼審查、前端開發、數據分析、做PPT、做遊戲、Slack集成、Figma轉代碼等範疇,有啲仲刷新咗我哋對「AI編程工具」邊界嘅認知。

整體嚟講,呢個案例庫展示咗Codex點樣由一個編程助手演變成一個通用工作工具。其中一個核心設計係AGENTS.md文件,佢就好似一本畀AI嘅工作手冊,你只要定義好規則同目標,AI就會自動執行,係一種新嘅協作模式。呢批案例嘅另一個重點係「評估驅動嘅改進循環」——透過反覆檢查、打分、改進,死磕難題,體現咗AI編程唔再追求一步到位,而係逐步逼近最優解。

  • Codex 官方案例庫證明咗 AI 編程工具可以擴展到非編程任務,模糊咗工具邊界。(結論)
  • 每個案例都有完整步驟同 Starter Prompt,可以一鍵打開直接試用,降低學習成本。(方法)
  • 有別於一般簡單示範,案例包括 PR 自動審查、數據分析全流程、死磕難題等,體現深度同真實應用。(差異)
  • AGENTS.md 作為 AI 工作手冊,定義規則後 AI 自動執行,啟發我哋用新嘅協作模式。(啟發)
  • 你可以立即打開 Codex 案例庫,選擇一個案例一鍵嘗試,或者參考 AGENTS.md 喺自己項目實施。(可行動點)
值得記低
連結 developers.openai.com

Codex 官方案例庫

OpenAI 推出嘅12個使用場景案例庫,每個都有完整操作步驟同Prompt模板。

整理重點

案例庫發佈背景

OpenAI 開發者關係負責人

Romain Huet

宣佈 Codex 上線咗一個官方案例庫,收錄咗12個實戰場景,每個都有完整步驟同 Starter Prompt,仲可以一鍵打開。呢批案例涵蓋咗代碼審查、做PPT、數據分析、遊戲製作等範疇,一半以上同編程冇直接關係。

  • 案例庫首頁顯示12個案例,由簡單到進階,包括 PR 自動審查、截圖變頁面、數據分析全流程、做 ChatGPT 應用、iOS/macOS 開發、瀏覽器遊戲、自動做 PPT、死磕難題、Slack 集成、Figma 變代碼、讀懂大型代碼庫、升級 API 集成。
  • 每個案例標註咗難度同預計時間,例如 PR 審查係 Easy 5秒,做遊戲係 Medium 幾個鐘。
整理重點

幾個關鍵案例剖析

PR 自動審查

係上手最易嘅案例,你只需要喺 GitHub 倉庫裝好 Codex,佢就會喺每個 PR 提交後自動掃描,仲可以喺評論度 @codex fix it 自動修復。關鍵係可以透過 AGENTS.md 定義審查規則,例如拼寫錯誤標高優先級。

數據分析案例係非程式員最啱用,佢唔只係畫圖,而係由導入、清洗、建模到出報告一條龍。核心係先定義問題,再設定 AGENTS.md 規則,然後讓 Codex 自己睇數據。

先定義問題,再設定規則,最後讓 Codex 自己睇數據

PPT案例用 PptxGenJSImageGen,30分鐘就整到一套品牌風格統一嘅簡報,重要係保持文字同圖表可編輯。做遊戲案例展示咗一個人由策劃到成品嘅能力,用咗三個關鍵 Skill:Playwright Interactive、ImageGen 同 OpenAI Docs。

Vibe Coding 最佳示範

整理重點

從案例中睇到嘅趨勢

回顧12個案例,有幾個明顯觀察。第一,Codex 正在模糊「編程工具」同「通用工作工具」嘅界線,一半案例同寫程式冇關。

模糊編程工具同通用工作工具嘅界線

第二,AGENTS.md 幾乎每個案例都用,係一種新協作模式:你定義規則同目標,AI 自己執行。

另外,每個案例都有配套嘅 Starter Prompt 同操作流程,降低咗試用門檻。對於開發者嚟講,呢個案例庫係好好嘅參考資源。

OpenAI 嘅開發者關係負責人 Romain Huet 宣佈 Codex 上咗一個官方案例庫。

圖片

12 個真實嘅使用場景,每個都附有完整嘅操作步驟、Prompt 模板,甚至可以一鍵喺 Codex 應用入面打開。

我哋啱啱發佈咗 Codex 案例庫!呢個係一個涵蓋程式同非程式任務嘅實用案例集合,展示咗 Codex 嘅真實用法。我最鍾意嘅一點係:如果你裝咗 Codex 應用,可以直接一鍵打開每個案例嘅 Starter Prompt!

Codex 案例庫首頁
Codex 案例庫首頁

呢 12 個案例涵蓋咗由程式碼審查到做 PPT、由數據分析到整遊戲嘅唔同場景,有啲真係刷新咗我對「AI 編程工具」邊界嘅認知。

逐個睇睇。

PR 自動審查

PR 自動審查案例頁面
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 案例頁面
截圖轉前端 UI 案例頁面

第二個案例係前端開發:將截圖同設計稿直接變成響應式 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 應用案例頁面
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 開發

iOS 和 macOS 開發案例頁面
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 案例頁面
自動生成 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 集成案例頁面
Slack 集成案例頁面

第九個案例行嘅係集成路線:直接喺 Slack 入面叫 Codex 做嘢。

難度 Easy,5 分鐘搞掂。

裝好 Slack 應用,連接倉庫同環境,將 @Codex 加入頻道。然後喺任何一個 Slack 對話線程度 @Codex,附上你嘅需求,佢就會啟動一個雲端任務。

做完之後會喺線程入面貼返結果連結,你都可以去 Codex 雲端面板睇詳細。

Starter Prompt:

@Codex 分析呢個線程入面提到嘅問題,並喺 <環境名稱> 中實現修復。

官方建議:請求要具體,指明用邊個倉庫同環境,大型程式庫嘅話仲要引導 Codex 去睇啲咩文件或目錄。

呢個其實係將 Codex 變成一個隨時待命嘅遙距程式員。產品經理喺 Slack 入面描述 bug,@Codex,然後去飲杯咖啡返嚟睇結果。

Figma 變程式碼

Figma 轉代碼案例頁面
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 升級案例頁面
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 自己去執行。

◇ ◆ ◇

相關連結:
  • Codex 案例庫:https://developers.openai.com/codex/use-cases
  • Romain Huet 推文:https://x.com/romainhuet/status/2037604733847003367

OpenAI 的開發者關係負責人 Romain Huet 宣佈 Codex 上線了一個官方案例庫。

圖片

12 個實打實的使用場景,每個都帶完整的操作步驟、Prompt 模板,甚至可以一鍵在 Codex 應用裏打開。

我們剛剛發佈了 Codex 案例庫!這是一個涵蓋編程和非編程任務的實用案例集合,展示了 Codex 的真實使用方式。我特別喜歡的一點是:如果你安裝了 Codex 應用,可以直接一鍵打開每個案例的 Starter Prompt!

Codex 案例庫首頁
Codex 案例庫首頁

這 12 個案例覆蓋了從代碼審查到做 PPT、從數據分析到做遊戲的各種場景,有些確實刷新了我對「AI 編程工具」邊界的認知。

逐個來看。

PR 自動審查

PR 自動審查案例頁面
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 案例頁面
截圖轉前端 UI 案例頁面

第二個案例是前端開發:把截圖和設計稿直接變成響應式 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 應用案例頁面
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 開發

iOS 和 macOS 開發案例頁面
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 案例頁面
自動生成 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 集成案例頁面
Slack 集成案例頁面

第九個案例走的是集成路線:直接在 Slack 裏給 Codex 派活。

難度 Easy,5 分鐘搞定。

裝好 Slack 應用,連接倉庫和環境,把 @Codex 加到頻道里。然後在任何一個 Slack 對話線程裏 @Codex,附上你的需求,它就會啓動一個雲端任務。

做完之後會在線程裏貼回結果連結,你也可以去 Codex 雲端面板查看詳情。

Starter Prompt:

@Codex 分析這個線程裏提到的問題,並在 <環境名稱> 中實現修復。

官方建議:請求要具體,指明用哪個倉庫和環境,大型代碼庫的話還要引導 Codex 去看哪些文件或目錄。

這其實是把 Codex 變成了一個隨時待命的遠程程序員。產品經理在 Slack 裏描述 bug,@Codex,然後去喝杯咖啡回來看結果。

Figma 變代碼

Figma 轉代碼案例頁面
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 升級案例頁面
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 自己去執行。

◇ ◆ ◇

相關連結:
  • Codex 案例庫:https://developers.openai.com/codex/use-cases
  • Romain Huet 推文:https://x.com/romainhuet/status/2037604733847003367