最近在使用 Codex 时，经常会看到两个概念：
刚开始很容易把它们混在一起。实际上，两者解决的问题并不一样。
简单理解：
Skill 决定“怎么干”，Plugin 决定“用什么能力干”。
Skill 可以理解成一套提前写好的“工作方法”或“操作手册”。
例如 Codex 中输入 /，可以看到：
这些通常就是 Skill。
例如：
/Frontend App Builder
相当于明确告诉 Codex：
这次任务请按照“前端应用开发”这套专业流程来完成。
Skill 里面可能包含：
Skill
├── Instructions 指令
├── 工作流程
├── 开发规范
├── 示例
├── 脚本
└── 检查规则
因此，Skill 更关注：
这件事情应该怎么做。
不一定。
例如直接告诉 Codex：
帮我按照这个原型开发一个后台管理页面。
Codex 可以自己判断是否需要使用相关 Skill。
也可以手工指定：
/Frontend App Builder
帮我按照这个原型开发一个后台管理页面。
这样就相当于明确要求：
本次任务使用 Frontend App Builder 这套工作方法。
所以可以简单理解为：
不选择 Skill
↓
Codex 自动判断怎么完成任务
手工选择 Skill
↓
明确告诉 Codex 按哪套方法完成任务
但选择 Skill 并不代表其他能力全部不能使用。
Codex 仍然可以根据任务继续调用文件、终端、测试工具等能力。
Plugin 可以理解成给 Codex 增加的一组能力。
例如在对话中可以通过：
@Presentations
明确选择 Presentations。
这时候表达的意思不是：
按 Presentations 的方法思考。
而更接近：
这次任务请使用 Presentations 提供的能力。
例如：
@Presentations
帮我制作一份 Harness 架构介绍 PPT。
执行过程可以简单理解为：
用户任务
↓
@Presentations
↓
模型理解任务
↓
使用 Presentations 提供的能力
↓
创建 / 修改 / 导出演示文稿
可以用一张表理解：
| 对比项 | Plugin | Skill |
|---|---|---|
| 主要作用 | 提供能力 | 提供工作方法 |
| 简单理解 | 工具箱 | 操作手册 |
| 常见调用方式 | @Plugin |
/Skill |
| 解决的问题 | 用什么能力做 | 应该怎么做 |
| 是否可以自动选择 | 可以 | 可以 |
最简单的记忆方式就是：
Skill
= 告诉 AI 怎么干
Plugin
= 给 AI 能力去干
例如我输入：
@Presentations
只是明确指定：
使用 Presentations。
至于真正执行时具体调用哪个工具，由模型根据当前任务决定。
例如：
@Presentations
↓
模型判断任务
↓
可能调用
├── 创建演示文稿
├── 新建页面
├── 修改页面
├── 添加内容
└── 导出文件
底层能力可能由 Tool、Connector、MCP 等方式提供。
作为普通使用者，一般不需要自己指定：
必须调用 add_slide()
必须调用某个 MCP Tool
通常只需要告诉模型：
我要完成什么任务。
模型负责选择具体执行能力。
Skill 和 Plugin 并不是二选一。
例如：
Skill
“告诉模型应该怎么设计 PPT”
↓
模型
↓
Plugin
“提供真正制作 PPT 的能力”
↓
Tool / MCP
↓
真正执行
因此，一次完整的 Agent 执行可以简单理解成：
用户任务
↓
Skill
怎么做
↓
模型规划
↓
Plugin / Tool / MCP
用什么做
↓
执行任务
我的使用习惯比较简单。
普通任务：
直接告诉 Codex 要干什么
不用特意选择 Skill，让 Codex 自己判断。
如果希望按照某套专业流程执行：
/Skill
例如：
/Frontend App Builder
如果明确需要某个外部或专业能力：
@Plugin
例如：
@Presentations
所以最后可以记成一句话：
普通任务直接说；想控制“怎么干”就选 Skill；想明确“用什么能力干”就选 Plugin。
这也是我目前理解 Codex 中 Plugin 和 Skill 最简单的一种方式。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。