别急着装插件:先画权限边界图

我这两天看 OpenAI 的插件说明时，差点又犯一个老毛病：看到“插件目录”，第一反应就是问哪些插件最值得装。

但插件不是“能力越多越好”的玩具箱。它可能带来 Skill，也可能带来 App，还可能牵到外部数据、写入动作、工作区角色、地区限制和管理员设置。你不先画边界，很容易把“我能装”误会成“我该装”。

所以今天做一次小白实验：不推荐插件，不排名，不做清单。

我只验证一件事：

在给 Codex 装插件之前，怎么先画一张权限边界图。

先分清四层能力

实验背景：插件目录变成主入口

OpenAI Help Center 在 2026-07-09 更新了一篇说明：app directory 已迁移到 Plugin directory。插件成为 ChatGPT 和 Codex 里发现 workflow capabilities 的主要入口。

但同一篇说明里还有几句更重要：

•插件可以包含 Skills、Apps 和 App templates。

•Existing app connections remain unaffected。

•Workspace admins 在 Workspace settings > Plugins 里管理插件安装。

•底层 App 的 access 和 permissions 仍然在插件配置或 Workspace settings > Apps 里管理。

翻译成普通人能用的话：

插件更像一个工作流包装盒。盒子里可能有流程说明、外部系统连接、配置模板。真正碰到外部数据和动作的，通常是 App 或工具连接。

我一开始想错的地方就在这里。我把“安装插件”想成了“打开一个能力”。更准确的说法是：安装插件只是把一组 workflow 能力放到你面前，真正能不能用、能不能写入数据，还要看底层 App、角色、工作区设置和连接授权。

实验目标：给插件画 4 层边界

这次我没有拿真实账号做演示，只拿一个常见内容工作流做假设：

我想让 Codex 帮我整理选题、读取资料、生成发布素材，必要时同步到文档或项目管理系统。

如果不画边界，我很容易说：那就把所有内容、文档、项目管理、消息类插件都装上。这就是翻车入口。

我把它拆成 4 层：

1.Plugin：我想完成的工作流能力是什么？

2.App：它会连接哪个外部系统，能读什么、写什么？

3.Skill：它只是提供流程说明，还是会触发外部动作？

4.MCP：它提供的是上下文、工具，还是可执行动作？

画完这 4 层，问题就从“装不装”变成了“这个工作流需要哪些最小能力”。

权限边界图

实验过程：我怎么筛一个插件

第一步，我先问它解决什么工作。

如果只是“以后可能有用”，我先不装。

这句话听起来小气，但很有效。没有工作流时装插件，最后会变成一堆看起来很厉害、实际没人用的入口。

我给自己的标准是：今天如果说不出一个具体产物，就不安装。比如“整理发布素材并保存到指定目录”是具体产物，“提升效率”不是。

第二步，我看它是否需要 App。

OpenAI 的说明里讲得很清楚：App 连接的是系统、数据和动作。连接 App 往往还涉及用户认证、工作区允许、角色允许、地区和计划支持。

所以我不会只看插件名字。我会继续问：

•它需要连接哪个外部系统？

•是只读，还是可以写入？

•写入动作包括创建、发送、删除、修改权限吗？

•如果管理员关掉底层 App，这个插件还能做什么？

这里最容易翻车的是“读写混在一起”。一个文档插件如果只是搜索资料，风险很低；如果能创建、移动、共享、删除文档，风险就完全不一样。

第三步，我看 Skill 和 App 的关系。

Skill 很有用，但它不是账号授权。它更像一份可复用工作说明：遇到这种任务怎么拆、读哪些文件、用什么格式输出、怎样验证结果。它能让 Codex 更稳定，但不能绕过 App 的访问控制。

我以前容易把 Skill 想成“自动化能力”。现在会更保守一点：Skill 负责怎么做，App 和工具负责能不能碰外部系统。这两个要分开看。

第四步，我看 MCP 或外部工具。

MCP 很像给 Codex 加工具和上下文入口。它可以很强，所以更要问边界。

我会先问三句：

•这个 server 是谁提供的？

•它能读哪些资源？

•它能执行哪些动作？

如果一个 MCP 只是查文档、读公开资料，风险相对低。如果它能连生产数据库、发消息、改项目状态、执行命令，就不能只看“好不好用”。

翻车点：我差点把“能装”当成“该装”

这次实验最明显的翻车点，是我的第一反应太像工具控。看到插件目录迁移，我脑子里马上出现一串问题：

•有哪些插件？

•哪个最强？

•哪个能省时间？

•有没有推荐组合？

这些问题不是不能问，但顺序错了。真实工作里，插件不是先从列表里挑，而是先从任务里倒推。

比如内容创作这件事，我真正需要的是：

•查官方资料；

•读取本地历史产物；

•生成 Markdown、图片、视频包；

•在安全时保存公众号草稿；

•小红书和 B站只生成素材，不公开发布。

这里面有些动作适合 App，有些适合 Skill，有些根本不需要插件，靠本地文件和脚本就够了。如果我为了“看起来全能”一口气装一堆插件，反而会让边界变模糊。到最后出问题时，你很难回答：

到底是哪个插件、哪个 App、哪个工具、哪条 Skill 指令做了这个动作？

这就不适合交给自动化。

修正方法：安装前写一张小表

我现在会在安装插件前写一张很小的表。

不需要复杂，5 行就够：

1.我要完成的任务是什么？

2.需要读取哪些数据？

3.会写入、发送、删除或改权限吗？

4.哪些动作必须人工确认？

5.完成证据是什么？

安装前问 5 句

比如今天这个内容工作流，我会这样写：

任务：每天生成一篇 Codex / 氛围编程内容，并拆成公众号、小红书、B站素材。

读取：本仓库历史内容、Obsidian 旧笔记、OpenAI 官方文档、公开网页。

写入：本地文件、Obsidian 笔记、公众号草稿箱。

禁止：公开发布小红书和 B站；未经确认不群发公众号；不展示密钥、Cookie、验证码。

完成证据：article.md、article.html、qa.md、小红书卡片、B站 publish.mp4、verification.md。

这张表写完，再看插件就清楚很多。需要官方资料，就优先用浏览或文档检索。需要外部文档，就看文档类 App 是否只读够用。需要发布草稿，就单独确认账号配置、封面、正文图片上传和草稿返回结果。没有这些证据，就不能说完成。

一个可复用的安装前 Prompt

下次准备装插件前，我会先这样问 Codex：

这段 Prompt 的重点不是让 Codex 变谨慎一点。

重点是把“插件很强”改成“插件为哪个工作流服务”。

这次实验结论

插件目录变成主入口，会让更多工作流更容易被发现和安装。但对普通用户来说，真正重要的不是“装了多少插件”，而是“每个插件到底碰到了哪一层权限”。

我这次的结论很简单：

插件安装前，先画权限边界图。Plugin 是工作流容器，App 连接外部数据和动作，Skill 提供流程说明，MCP 提供工具和上下文入口。不要把它们混成一个“AI 可以随便干活”的开关。

如果你以后也准备用 Codex 插件做内容、产品或项目管理，我建议第一步不要打开插件目录。

先写清楚那 5 句话：任务是什么，数据从哪里来，会写到哪里去，谁批准高风险动作，完成证据是什么。