Codex 插件实战手册:6 组核心能力的完整教程

Codex 现在已有数百个插件和相关扩展能力。第一次打开插件目录，很容易被名称和分类淹没：Browser、Chrome、GitHub、Figma、Documents、Spreadsheets、Notion、Hugging Face……每一个似乎都有用，真正轮到自己动手，却不知道第一条任务该怎么写。

这份手册把最常用、也最容易被低估的能力整理成六张任务卡。每张卡只解决一个问题：装好以后，怎样让它完成一件可以检查的工作。

ChatGPT 与 Codex 当前从同一个公共插件目录发现插件。在桌面端打开 Plugins Directory，选择需要的插件并安装；在 Codex CLI 中，也可以用 /plugins 浏览已经安装或可发现的插件。具体能否安装和调用，仍会受到产品表面、计划和工作区设置影响。

安装后，新建一个任务，直接描述想得到的结果。Codex 会根据当前可用工具选择合适能力；需要明确指定时，可以点名插件，例如 @Browser。

先记住一个通用句式。对象、范围、产物和验收，也是后面所有任务卡的共同骨架：

图 1｜把插件任务写成对象、范围、产物和验收四个槽位

它可以改写成财报分析、网页调试、代码审查、知识库整理或者模型实验。对象、范围、产物和检查方式越清楚，插件就越容易从“能连接”变成“能交付”。

查找公开资料、读取动态网页、复现网页故障、检查前端实现、在登录后的页面完成操作。

Browser 和 Chrome 都能接触网页，但它们解决的问题不完全相同。Browser 更适合在 Codex 内打开、浏览和检查页面；Chrome 更适合任务依赖你已有的浏览器状态，例如已经登录的账号、现成标签页或扩展。涉及登录态和页面操作时，优先从最小必要范围开始，关键写入动作仍应由你确认。

很多人只让浏览器插件“总结这个网页”。更有价值的用法，是让它保留证据位置，或者把页面问题与本地代码连起来。

在开发者模式下，Browser 还能读取页面状态、控制台与网络请求。这意味着它不只是替你点击，也能帮助判断：按钮没有响应，是事件没绑定、请求失败，还是接口返回了错误数据。

这项任务最值得保留的是“原文位置”和“仍缺失字段”。前者方便复核，后者防止模型用推断补齐空白。

如果它只给总结，补上“逐条保留来源位置”；如果它在页面上漫游，限定域名、页面和时间范围；如果它直接修改代码，改成“先复现并报告证据，确认后再改”。

Excel 数据清洗与建模、Word 报告撰写、PPT 汇报制作，以及三者之间的连续交付。生成的 .xlsx、.docx 和 .pptx 也可以在兼容这些格式的软件中继续使用；如果最终要用 WPS，交付前应再检查公式、字体和版式兼容性。

这组插件的价值不止是“帮我做个表”或“帮我写份报告”。它们可以把计算层、解释层和展示层拆开：先保留原始数据和公式，再生成报告，最后把经过确认的结论变成演示文稿。

一个可靠的工作簿至少应让人看得出：原始数据、清洗规则、公式与分析判断各自在哪里。

图 2｜Office 文件从计算层、解释层到展示层依次交付

工作簿确认后，再继续生成解释层：

最后把已经确认的结论转成展示层：

出现“数字看起来对，但不知道怎么算”时，要求把派生值改成公式并补 assumptions；报告太空泛时，规定每个结论引用工作表；PPT 太拥挤时，限制“一页一个结论”，并要求渲染后逐页检查。

理解仓库、检查 PR、处理未解决的 review thread、定位 CI 失败、实施修改并准备 draft PR。

“帮我看这个 PR”通常只会得到一次宽泛的代码评论。更完整的 GitHub 工作流应该同时读取PR 描述、变更文件、未解决评论和失败 checks。修复以后，还要回到同一条验收链验证。

把“读”和“写”拆成两步也很重要。先获取上下文和修改计划，再授权改文件、提交或创建 PR，可以显著降低跑偏的概率。

确认计划后：

如果它泛泛评论代码，要求“只看未解决 thread 和失败 checks”；如果修改过多，限定允许改动的文件；如果只修代码不复测，把原始失败命令直接写进完成条件。

把选中的设计实现为网页、检查设计系统、从代码生成可编辑画布、在设计与实现之间来回校正。

Figma 插件并不只提供一张截图。它能够给 Codex 更具体的设计上下文，例如当前 selection、层级结构、样式和相关素材。官方公开的工作流还支持把运行中的网页回送到 Figma，形成代码与画布之间的往返。

因此，“根据这个 Figma 写页面”还不够。真正关键的是同时读取目标 selection、已有组件和渲染结果。

先在 Figma 里选中目标 frame，再提交：

如果页面“像，但不像同一个产品”，让它先盘点设计 token 和已有组件；如果代码重复严重，明确优先复用；如果桌面端正常但移动端崩坏，把两个 viewport 写进完成条件。

搜索云端资料、汇总多份文档、建立研究页、维护项目知识库、把结论写回指定位置。

知识库插件的强项在于跨页面寻找证据、保留来源关系，并把结果写成一个之后还能更新的对象。

Notion 官方 MCP 的使用建议尤其强调具体页面和明确动作。Google Drive 则适合把 Docs、Sheets、Slides 和文件检索连接起来。无论使用哪一个，读权限和写权限都应分别确认。

如果要把研究结果持续维护，可以追加一条更新规则：

如果它只搜到标题，要求打开正文并记录定位；如果综合结论失去出处，规定“一条结论至少对应一个链接”；如果知识库越来越乱，固定目标 database、字段和命名规则。

发现模型或数据集、检查 model card / dataset card、准备训练或评估脚本、提交远端任务、记录实验产物。

Hugging Face 的相关 skills 不只是搜索 Hub。官方公开示例把数据集创建、训练、评估和作业提交拆成可复用的步骤。真正有价值的是把版本、切分、参数、指标和产物位置一起留下。

选定后：

如果结果无法复现，补齐 revision、seed 和切分；如果成本不可控，先规定样本规模和运行上限；如果模型分数无法解释，要求同时保存基线、指标定义和错误样本。

六张任务卡可以独立使用，也可以按工作内容组合。

图 3｜金融分析、网页开发、数据库治理和模型实验的常见插件组合

Supabase 这一类场景值得单独提醒：数据库权限不只看 RLS。公开文档指出，Data API 的 table-level grants 与 RLS 是两层控制；设计或审查迁移时，应分别检查 exposed schema、角色 grants、RLS policy 和 security advisors。生产环境的迁移与修复需要明确批准，并保留回滚与验证路径。

第一次使用时，不需要同时装满六组。选择本周会重复发生的一件事，先完成一条最短闭环：一个明确对象、一份产物、一次验证。

插件真正替你省下的，既有某一次点击，也包括把“我上次是怎么做的”变成下一次可以直接复用的工作方式。