Codex 插件:产品经理的实用清单与工作流

2026 年 3 月，OpenAI 给 Codex 上了插件市场，Codex 从"写代码工具"变成了能跑完整工作流的 agent。

推荐阅读Codex   window电脑下载Codex，连接飞书CLI

要说清一件事：这不是 OpenAI 首创，而是补课。Claude Code、Gemini CLI 都比它更早做了插件，三家现在的结构也基本一样。所以真正的看点不是"谁领先"，而是——很多工作流跟写代码无关，正好是 PM 的日常：起草 PRD、汇总讨论、验证原型、搬运信息。

下面只讲对 PM 有用的部分。

插件是什么

一句话：一个插件 = 三样东西打包在一起。

装一次，Codex 自动把三者接好。这三样由项目里的 plugin.json 声明。

[图 1：插件 = 技能 + 应用 + MCP]

二、该装哪些

按 PM 的场景挑，不用把目录里所有插件都装上。

先记一个区分：官方 = Codex 目录里开箱即用；社区 = 得从 GitHub 仓库装、自己先验证。

[图 2：PM 插件全景]

两点提醒：

三、怎么装

方式一 · App（推荐） 侧栏点 Plugins → 找到插件 → 点 Add to Codex → 开新会话就能用。最省心。

四、旗舰用法：会议纪要 → PRD

一句话：把散落在各处的讨论，变成一份能查到出处的 PRD 草稿。

这是 OpenAI 官方给的用例。好处不是"生成得快"，而是每条需求都能追到来源，发出去之前还能自查。

五步：内部来源（Linear、Slack、Notion、Drive、会议纪要）→ $documents 汇总 → 出 PRD 草稿（自带来源附录）→ 让它列出证据薄弱的需求 → 确认后导出 DOCX。

[图 4：会议纪要 → PRD 的五步]

起草提示词，可直接用：

用 $documents 为【功能模块】起草 PRD，
来源取自 @linear、@slack、@notion。
包含：问题、用户、目标、需求、交互、指标、风险、开放问题、来源附录。
对需求标注来源，有冲突就点出来。只出草稿，别回写 Linear。

发出前自查：

在我分享前，帮我列出：
证据薄弱的需求、没负责人的开放问题、你当成已确认的决策。

五、怎么落地

一句话：分三层推进，别一次全上。

[图 5：分层落地]

两条避坑：

关于文中那些"每周省几小时""半天顶三天"的说法：那是作者的体感，不是实测，你自己跑一周才作数。

参考来源