Codex 插件入门：技能、脚本和工具的打包方式

先分清四种东西

层	它是什么	什么时候用
规则文件	每次会话都要遵守的底线和偏好	「永远别动这个目录」这类要求
技能	一类活的做法，写成一份说明	步骤固定、会重复出现的任务
脚本	确定性的动作，跑一次得一个结果	检查状态、批量改名、生成文件
MCP 服务器	给模型的新工具接口	要查外部数据、调外部系统
插件	把上面几样打包的盒子	要复用、要分发、要版本管理

判断顺序是从上往下的：先问这是不是规矩，再问是不是做法，再问要不要新工具，最后才问值不值得打包。多数需求停在技能这一层就够了。

盒子里长什么样

一个最简单的插件，目录结构大致是这样：

my-plugin/
├─ .codex-plugin/
│  └─ plugin.json        # 名字、版本、说明、入口
├─ skills/
│  └─ my-skill/
│     └─ SKILL.md        # 这类活怎么做
└─ scripts/
   └─ status.py          # 可选：确定性的动作

plugin.json 里最要紧的是三项：名字、版本、技能目录。名字决定装好以后怎么被引用，版本决定更新时会不会换成新内容。

如果插件还需要给模型新工具，就在清单里指向一份 MCP 配置；不需要的话，完全可以不写。一个只有技能的插件也是完整合法的。

安装与查看

codex plugin list                    # 看有哪些可用、哪些已装
codex plugin add 名字@市场            # 安装
codex plugin remove 名字@市场         # 卸载
codex plugin marketplace list        # 看配置了哪些市场

装好之后，插件里的技能会出现在新会话的技能列表里，名字通常是「插件:技能」两段式。这个命名方式本身就在提醒你：盒子有盒子的名字，手有手的名字。

什么时候值得打包

同一套做法要在多个项目里反复用。
要装到另一台机器，或者给别人用。
需要版本管理，改了之后能回退。

反过来说，如果只是自己这台机器上偶尔用一次，写一份技能就够了。打包本身不产生能力，只产生便利。

三个实际会踩的坑

装完没反应。插件配置在应用启动时读取，装完要重启应用；命令行的「已安装」不等于当前会话已加载。

改了内容却没变化。安装是把文件复制到缓存目录。改了源码必须升版本号再装一次，同版本重装不会换文件。

把私有信息打进包里。插件会被复制、被分享。路径、账号、内部地址在打包前就该清掉。

一个小例子

假设你有一套「把课程整理成笔记」的流程：先采集，再转写，再摘要，最后入库。流程是固定的，但每一步用什么工具会变。

合理的拆法是：技能里写五步流程和判断标准；脚本只做「查进度」这种确定性动作；真正需要连外部服务时，再单独做一个 MCP 服务器。三样东西各归各位，谁也不替谁干活。

五问收尾

这是每次都要遵守的规矩吗？写进规则文件。
这是一类活的做法吗？写成技能。
这是确定性的动作吗？写成脚本。
需要新工具、新数据源吗？才上 MCP。
要装给别人、要版本管理吗？最后才打包成插件。

五问走完，答案通常会自己浮出来。