Codex 官方插件(openai/plugins)是開源的

好多人第一次見到 openai/plugins，容易當咗佢係瀏覽器插件，或者當係某個 API 示例庫。其實都唔係好準確。簡單啲講就係：Plugin 係俾 Codex 呢類 AI Agent 安裝嘅能力包。

一個 AI Agent 剩係識得傾偈係唔夠㗎。佢要真係做嘢，就要知道某個領域嘅規則，可以連接到外部工具，跟住固定流程執行任務，亦都要喺需要嘅時候叫用命令。Codex 插件就係將呢啲嘢打包埋一齊，等 Codex 喺處理具體任務嘅時候唔使淨係靠通用模型記憶。

幾個概念可以咁樣理解：

• • Plugin：總包。佢聲明呢個能力包叫咩名、做啲咩、有咩入口。
• • Skill：方法。佢話俾 Codex 知遇到某類任務時應該點做，例如部署、排錯、寫 GraphQL、處理設計稿。
• • MCP 或應用連接器：連接。佢令 Codex 可以存取外部服務、私有數據或者工具，例如文檔、會議、監控系統、項目管理工具。
• • Command：固定動作。佢將常見操作做成明確入口，例如部署、檢查狀態、生成報告。
• • Agent、Hook、Asset：補充部分。前者可以定義更專門嘅代理角色，後者可以做流程檢查、提供圖標同說明素材。

所以，Plugin 同 Skill 唔係同一樣嘢。Plugin 似一個工具箱，Skill 係工具箱入面嘅操作說明；MCP 似工具箱接出去嘅電源同網線，令佢可以碰到真實系統。

我點解會關注呢個項目

我係從大神 Vaibhav (VB) Srivastav 嘅帖子留意到 openai/plugins 嘅。果條帖嘅核心意思好直接：呢啲 Codex 插件係開源嘅，而且已經覆蓋咗好多常見工作。帖入面舉咗幾個例子：Figma 做設計到代碼，Notion 將規格說明變成計劃，Vercel 負責構建同部署，Sentry 排查錯誤，Daloopa 做金融模型，Zoom 搜索會議內容，Canva 創建設計。

佢引用嘅上一條帖仲補充咗一點：用戶唔一定要先知道有邊啲插件，可以直接叫 Codex 睇 openai/plugins自己嘅倉庫同工作方式，再請 Codex 推薦應該安裝同配置邊啲插件。呢個觀點好關鍵。插件多咗之後，真正嘅問題唔係人哋背唔背得曬插件名，而係 Codex 可唔可以根據任務自己揀啱工具。

openai/plugins 入面到底有啲咩

我喺本地統計到，plugins 目錄下有 171 個插件目錄，SKILL.md 一共有 549 個。呢個規模已經說明佢唔係一個細 demo，而係展示緊 Codex 插件可以覆蓋邊啲真實工作流。

呢度有兩類插件。一類偏“連接器”，主要將外部應用接入 Codex，例如 Slack、Airtable、Google Drive、Zoom、Notion。另一類偏“工作流”，會寫好多技能，將複雜任務拆成步驟，例如 Vercel、Shopify、Expo、Zoom、Daloopa、plugin-eval。

佢嘅價值喺邊度

第一，佢將領域知識放咗入倉庫。好多任務唔係模型唔夠聰明，而係缺少具體產品、框架、命令、限制同最佳實踐。寫 Shopify 應用、調 Zoom SDK、部署到 Vercel，都有大量細節。插件將呢啲細節寫成技能同參考資料，令 Codex 做嘢嘅時候唔只靠通用記憶。

第二，佢令 Codex 更接近真實工作流。一個開發任務成日要讀設計、查 issue、睇日誌、改配置、跑測試、部署、再返到協作工具入面更新狀態。Figma、GitHub、Slack、Sentry、Vercel 呢啲插件對應嘅就係呢啲環節。

第三，佢俾第三方產品一個清晰入口。平台方如果希望 Codex 更瞭解自己嘅產品，唔使等模型更新，可以將文檔、命令、連接器同驗證方式整理成插件。Vercel、Expo、Shopify、Airtable、Zoom 都係呢種思路。

第四，佢令“選擇工具”呢件事都可以自動化。以前用戶要先知道有邊啲工具，再決定裝邊個。而家更自然嘅方式係：叫 Codex 睇你嘅倉庫、你嘅任務、你嘅工作習慣，然後推薦合適嘅插件。

幾個有代表性嘅插件

我揀呢啲插件，係因為佢哋一係被好多大V帖子點名，一係被 README 強調，一係喺本地實現入面技能多、覆蓋面廣。佢哋唔代表全部插件，但可以說明呢個項目嘅價值邊界。

Figma 係設計到代碼嘅代表。本地有 8 個技能，覆蓋設計實現、Code Connect、生成設計、生成圖表、生成組件庫、使用 FigJam 同 Slides。佢解決嘅係“開發點樣準確理解設計稿”嘅問題，令 Codex 可以按設計系統同組件規則實現界面。

Notion 代表知識同計劃類工作流。本地有 4 個技能，面向實現計劃、研究整理、會議準備同知識捕獲。好多代碼任務嘅上游材料喺文檔同會議記錄入面，Notion 插件可以將呢啲材料轉成開發計劃。

Vercel 係部署同 Web 工程平台嘅代表。本地有 47 個技能，覆蓋 Next.js、AI SDK、部署、環境變量、緩存、鑑權、支付、可觀測性、隊列等。佢犀利嘅地方係覆蓋從開發到上線嘅成條鏈，尤其係部署配置、運行時差異同線上驗證呢啲容易出錯嘅部分。

Sentry 代表線上問題排查。佢嘅目標好明確：叫 Codex 檢查最近嘅 issue 同 event。價值在於將錯誤監控入面嘅堆棧、事件同影響範圍接到修復流程入面，縮短“見到報錯”到“定位代碼”嘅距離。

Zoom 係複雜平台集成嘅例子。本地有 53 個技能，覆蓋 Zoom App、會議機器人、OAuth、REST API、Webhooks、Meeting SDK、Video SDK、Team Chat、Phone 等。佢嘅優勢係幫 Codex 先揀啱技術路徑，避免喺複雜 SDK 同授權流程入面兜路。

Canva 代表創意設計工具。本地有 3 個技能，涉及品牌演示、社交媒體尺寸適配同設計翻譯。佢說明插件唔只服務程序員，都可以將設計、內容同素材處理納入自動化。

Daloopa 代表金融分析。本地有 21 個技能，面向機構級數據同金融模型。金融分析好依賴數據口徑、術語同流程，呢類插件可以將專業步驟固定落嚟，減少通用回答嘅隨意性。

Expo 代表移動應用開發。本地有 13 個技能，覆蓋 Expo 同 React Native 嘅構建、部署、升級、調試、原生 UI 同 EAS 工作流。佢解決嘅係移動開發入面常見嘅環境、版本同構建問題。

Shopify 代表平台型電商開發。本地有 20 個技能，覆蓋 Admin、Liquid、Hydrogen、Functions、Storefront GraphQL、CLI、擴展同應用商店審核。佢嘅價值在於將平台規則前置，減少用錯 API 或者違反約束。

plugin-eval 好特別，佢唔係業務插件，而係用嚟評估 Codex 技能同插件。本地有評估、改進、指標設計等能力。佢說明插件生態唔可以剩係寫出嚟，仲要判斷係咪真係有效。

一個小案例：用插件重新審視呢篇文章嘅配圖

呢篇文章嘅配圖生成，我用咗已安裝插件暴露出來嘅 skill，將佢哋當作執行約束同 review 流程，再用本地 SVG 重新畫圖並導出 PNG。

呢度真正有幫助嘅係兩類插件能力。build-web-data-visualization:data-visualization 先將問題改成“呢張圖要回答啲咩問題”：第一張圖回答 Plugin、Skill、MCP 嘅關係，所以改成概念關係圖；第二張圖回答插件目錄入面有啲咩，所以改成文件樹解剖圖；第三張圖回答代表插件分別解決咩工作問題，所以改成場景地圖。佢仲要求檢查移動端閲讀路徑、直接標籤、顏色角色同導出後嘅清晰度。

canva:canva-resize-for-all-social-media 雖然本來面向 Canva 設計嘅社媒尺寸適配，但佢對封面好有用：先鎖定平台尺寸，再檢查標題喺信息流入面嘅可讀性、圖形會唔會搶字、導出格式係咪正確。因此封面圖單獨按公眾號 900x383 重畫，冇複用正文第三張圖。

我都睇過 Remotion、Hyperframes、Heygen 呢類插件。佢哋更偏向視頻、動態內容或者數字人視頻，唔適合呢篇以靜態公眾號長文為主嘅配圖任務，所以冇將佢哋用於正文圖設計。

呢張係之前嘅舊圖。問題唔係佢完全用唔到，而係佢似統一模板下嘅裝飾圖：橫向排布、信息密度接近，冇根據段落問題選擇最合適嘅圖形類型。係咪好樣衰？

呢個例子可以說明插件嘅一個實際價值：佢將專業判斷前置。冇插件嘅時候，Agent 都可以畫圖，但容易直接進入執行；用咗合適嘅 skill 之後，任務會先經過圖形選擇、閲讀路徑、移動端可讀性、導出尺寸同設計 review。

小結

openai/plugins 嘅重點唔止係數量多。佢真正有價值嘅地方，係將 Codex 從通用代碼助手，推向一個可以按行業、平台同團隊流程擴展嘅工程助手。

對於唔熟悉 AI Agent 嘅讀者嚟講，可以先記住一個樸素理解：Agent 要做真實工作，就需要工具、流程同上下文；Plugin 就係喺度幫 Agent 打包呢啲嘢。

當插件足夠多嘅時候，用戶唔使先記住插件名，而係可以叫 Codex 根據任務同倉庫自己判斷。對開發者同平台方嚟講，呢個倉庫亦都俾咗一個樣板：如果希望 Codex 更瞭解某個產品或者流程，就將知識、命令、連接器同驗證方式整理成插件。

模型能力好重要，但真實工作最終落在具體工具、具體流程同具體上下文入面。openai/plugins 做嘅，就係將呢啲上下文變成 Codex 可以安裝、讀取同執行嘅能力包。

很多人第一次看到 openai/plugins，容易把它理解成瀏覽器插件，或者理解成某個 API 示例庫。其實都不太準確。更簡單的說法是：Plugin 是給 Codex 這類 AI Agent 安裝的能力包。

一個 AI Agent 只會聊天還不夠。它要真正做事，需要知道某個領域的規則，能連接外部工具，能按固定流程執行任務，也要能在必要時調用命令。Codex 插件就是把這些東西打包起來，讓 Codex 在處理具體任務時不用只靠通用模型記憶。

幾個概念可以這樣理解：

• • Plugin：總包。它聲明這個能力包叫什麼、做什麼、有什麼入口。
• • Skill：方法。它告訴 Codex 遇到某類任務時該怎麼做，比如部署、排錯、寫 GraphQL、處理設計稿。
• • MCP 或應用連接器：連接。它讓 Codex 能訪問外部服務、私有數據或工具，比如文檔、會議、監控系統、項目管理工具。
• • Command：固定動作。它把常見操作做成明確入口，比如部署、檢查狀態、生成報告。
• • Agent、Hook、Asset：補充部分。前者可以定義更專門的代理角色，後者可以做流程檢查、提供圖標和說明素材。

所以，Plugin 和 Skill 不是一回事。Plugin 像一個工具箱，Skill 是工具箱裏的操作說明；MCP 像工具箱接出去的電源和網線，讓它能碰到真實系統。

我為什麼關注這個項目

我是從大神 Vaibhav (VB) Srivastav 的帖子注意到 openai/plugins 的。那條帖子的核心意思很直接：這些 Codex 插件是開源的，而且已經覆蓋了很多常見工作。帖子裏舉了幾個例子：Figma 做設計到代碼，Notion 把規格說明變成計劃，Vercel 負責構建和部署，Sentry 排查錯誤，Daloopa 做金融模型，Zoom 搜索會議內容，Canva 創建設計。

他引用的上一條帖還補了一點：用戶不一定要先知道有哪些插件，可以直接讓 Codex 看 openai/plugins、自己的倉庫和工作方式，再請 Codex 推薦該安裝和配置哪些插件。這個觀點很關鍵。插件多起來以後，真正的問題不是人能不能背下插件名，而是 Codex 能不能根據任務自己選對工具。

openai/plugins 裏到底有什麼

我本地統計到，plugins 目錄下有 171 個插件目錄，SKILL.md 一共有 549 個。這個規模已經說明它不是一個小 demo，而是在展示 Codex 插件可以覆蓋哪些真實工作流。

這裏面有兩類插件。一類偏“連接器”，主要把外部應用接進 Codex，比如 Slack、Airtable、Google Drive、Zoom、Notion。另一類偏“工作流”，會寫很多技能，把複雜任務拆成步驟，比如 Vercel、Shopify、Expo、Zoom、Daloopa、plugin-eval。

它的價值在哪裏

第一，它把領域知識放進倉庫。很多任務不是模型不夠聰明，而是缺少具體產品、框架、命令、限制和最佳實踐。寫 Shopify 應用、調 Zoom SDK、部署到 Vercel，都有大量細節。插件把這些細節寫成技能和參考資料，讓 Codex 做事時不只靠通用記憶。

第二，它讓 Codex 更接近真實工作流。一個開發任務常常要讀設計、查 issue、看日誌、改配置、跑測試、部署、再回到協作工具裏更新狀態。Figma、GitHub、Slack、Sentry、Vercel 這些插件對應的就是這些環節。

第三，它給第三方產品一個清晰入口。平台方如果希望 Codex 更懂自己的產品，不必等模型更新，可以把文檔、命令、連接器和驗證方式整理成插件。Vercel、Expo、Shopify、Airtable、Zoom 都是這種思路。

第四，它讓“選擇工具”這件事也可以被自動化。以前用戶要先知道有哪些工具，再決定裝哪個。現在更自然的方式是：讓 Codex 看你的倉庫、你的任務、你的工作習慣，然後推薦合適的插件。

幾個代表性插件

我挑這些插件，是因為它們要麼被很多大v帖子點名，要麼被 README 強調，要麼在本地實現裏技能多、覆蓋面廣。它們不能代表全部插件，但能說明這個項目的價值邊界。

Figma 是設計到代碼的代表。本地有 8 個技能，覆蓋設計實現、Code Connect、生成設計、生成圖表、生成組件庫、使用 FigJam 和 Slides。它解決的是“開發如何準確理解設計稿”的問題，讓 Codex 可以按設計系統和組件規則實現界面。

Notion 代表知識和計劃類工作流。本地有 4 個技能，面向實現計劃、研究整理、會議準備和知識捕獲。很多代碼任務的上游材料在文檔和會議記錄裏，Notion 插件能把這些材料轉成開發計劃。

Vercel 是部署和 Web 工程平台的代表。本地有 47 個技能，覆蓋 Next.js、AI SDK、部署、環境變量、緩存、鑑權、支付、可觀測性、隊列等。它厲害的地方是覆蓋從開發到上線的鏈條，尤其是部署配置、運行時差異和線上驗證這些容易出錯的部分。

Sentry 代表線上問題排查。它的目標很明確：讓 Codex 檢查最近的 issue 和 event。價值在於把錯誤監控裏的堆棧、事件和影響範圍接到修復流程裏，縮短“看到報錯”到“定位代碼”的距離。

Zoom 是複雜平台集成的例子。本地有 53 個技能，覆蓋 Zoom App、會議機器人、OAuth、REST API、Webhooks、Meeting SDK、Video SDK、Team Chat、Phone 等。它的優勢是幫 Codex 先選對技術路徑，避免在複雜 SDK 和授權流程裏繞路。

Canva 代表創意設計工具。本地有 3 個技能，涉及品牌演示、社交媒體尺寸適配和設計翻譯。它說明插件不只服務程序員，也可以把設計、內容和素材處理納入自動化。

Daloopa 代表金融分析。本地有 21 個技能，面向機構級數據和金融模型。金融分析很依賴數據口徑、術語和流程，這類插件能把專業步驟固定下來，減少通用回答的隨意性。

Expo 代表移動應用開發。本地有 13 個技能，覆蓋 Expo 和 React Native 的構建、部署、升級、調試、原生 UI 和 EAS 工作流。它解決的是移動開發裏常見的環境、版本和構建問題。

Shopify 代表平台型電商開發。本地有 20 個技能，覆蓋 Admin、Liquid、Hydrogen、Functions、Storefront GraphQL、CLI、擴展和應用商店審核。它的價值在於把平台規則前置，減少用錯 API 或違反約束。

plugin-eval 很特別，它不是業務插件，而是用來評估 Codex 技能和插件。本地有評估、改進、指標設計等能力。它說明插件生態不能只靠寫出來，還要能判斷是否真的有效。

一個小案例：用插件重新審視這篇文章的配圖

這篇文章的配圖生成，我使用了已安裝插件暴露出來的 skill，把它們當作執行約束和 review 流程，再用本地 SVG 重新畫圖並導出 PNG。

這裏真正有幫助的是兩類插件能力。build-web-data-visualization:data-visualization 先把問題改成“這張圖要回答什麼問題”：第一張圖回答 Plugin、Skill、MCP 的關係，所以改成概念關係圖；第二張圖回答插件目錄裏有什麼，所以改成文件樹解剖圖；第三張圖回答代表插件分別解決什麼工作問題，所以改成場景地圖。它還要求檢查移動端閲讀路徑、直接標籤、顏色角色和導出後的清晰度。

canva:canva-resize-for-all-social-media 雖然本來面向 Canva 設計的社媒尺寸適配，但它對封面很有用：先鎖定平台尺寸，再檢查標題在信息流裏的可讀性、圖形是否搶字、導出格式是否正確。因此封面圖單獨按公眾號 900x383 重畫，沒有複用正文第三張圖。

我也看過 Remotion、Hyperframes、Heygen 這類插件。它們更偏視頻、動態內容或數字人視頻，不適合這篇以靜態公眾號長文為主的配圖任務，所以沒有把它們用於正文圖設計。

這是之前的一張舊圖。問題不是它完全不能用，而是它更像統一模板下的裝飾圖：橫向排布、信息密度接近，沒有根據段落問題選擇最合適的圖形類型。是不是很醜？

這個例子能說明插件的一個實際價值：它把專業判斷前置。沒有插件時，Agent 也能畫圖，但容易直接進入執行；用了合適的 skill 之後，任務會先經過圖形選擇、閲讀路徑、移動端可讀性、導出尺寸和設計 review。

小結

openai/plugins 的重點不只是數量多。它真正有價值的地方，是把 Codex 從通用代碼助手，推向一個可以按行業、平台和團隊流程擴展的工程助手。

對不熟悉 AI Agent 的讀者來說，可以先記住一個樸素理解：Agent 要做真實工作，就需要工具、流程和上下文；Plugin 就是在給 Agent 打包這些東西。

當插件足夠多時，用戶不必先記住插件名，而是可以讓 Codex 根據任務和倉庫自己判斷。對開發者和平台方來說，這個倉庫也給了一個樣板：如果希望 Codex 更懂某個產品或流程，就把知識、命令、連接器和驗證方式整理成插件。

模型能力很重要，但真實工作最終落在具體工具、具體流程和具體上下文裏。openai/plugins 做的，就是把這些上下文變成 Codex 可以安裝、讀取和執行的能力包。