这篇文章是我自己学习 Codex、Skill、Plugin、MCP 过程中的一次整理。刚开始我也以为 Skill 就是“提示词模板”,后来发现它不只是提示词:简单 Skill 可以只写说明,复杂 Skill 还可以带 Python、Shell 脚本、模板文件,甚至配合 MCP 调外部系统。
一、先说结论
如果只用一句话解释:
Codex 是一个能动手干活的 AI 智能体,Skill 是给 Codex 安装的一套“做事方法和工具包”。
再通俗一点:
- Codex:像一个会看项目、会跑命令、会改文件、会看报错再调整的 AI 技术同事。
- Skill:像给这个技术同事准备的一份操作手册,里面还可以带脚本、模板、参考资料。
- Plugin 插件:像一个可安装的大礼包,里面可以包含 Skill、App 集成、MCP 配置等。
- MCP:像连接外部系统的标准接口,比如连 GitHub、数据库、Figma、公司内部系统。
官方文档里也说,Codex Skill 可以把说明、资源和可选脚本打包起来,让 Codex 更稳定地执行某类重复工作;Plugin 是 Codex 里可安装的分发单元,可以打包 Skill、App 集成和 MCP Server。
二、Codex 是什么?
Codex 不是普通聊天机器人。
普通聊天机器人一般是:
Codex 更像:
|
1
2
3
4
5
6
7
8
9
10
11
|
你交代一个任务
↓
Codex 制定计划
↓
读文件 / 改文件 / 执行命令 / 调用脚本
↓
观察执行结果
↓
如果失败,就根据报错继续修正
↓
直到完成,或者遇到需要你确认的问题
|
官方 Codex CLI 文档也说明,Codex CLI 可以在终端里运行,并且能读取、修改、运行你选定目录里的代码。
三、Codex 怎么安装?
如果是 macOS / Linux,官方文档给出的 Codex CLI 安装方式是:
|
1
|
curl -fsSL https://chatgpt.com/codex/install.sh | sh
|
安装后运行:
第一次运行时,会提示登录。登录完成后,就可以在终端里使用 Codex。
如果你已经安装了 Codex,就不用重复安装,直接进入你的项目目录执行:
注意:Codex 版本更新比较快,安装命令和目录规则可能会调整,实际以官方文档和你本机 Codex 提示为准。
四、Skill 到底是什么?
刚开始我理解 Skill,就是“固定提示词”。这个理解对一半。
简单 Skill 确实可以只是一个 SKILL.md 文件,里面写规则,比如:
|
1
2
3
4
5
|
遇到日报时:
1. 语言自然,不要太官方。
2. 不要夸大工作量。
3. 按 1、2、3 分点输出。
4. 适合发领导或客户群。
|
这种 Skill 就像一个固定的系统提示词。
但是复杂 Skill 还可以带:
|
1
2
3
4
5
|
SKILL.md 说明书,告诉 Codex 什么时候用、怎么用
scripts/ Python、Shell 等脚本
references/ 参考文档
assets/ 模板、图片、示例文件
agents/ 依赖配置,比如 MCP 等
|
所以更准确地说:
Skill = 做事说明书 + 可选脚本 + 可选模板 + 可选参考资料。
官方文档里也说明,一个 Skill 是一个目录,里面必须有 SKILL.md,并且 SKILL.md 需要包含 name 和 description,同时可以带可选脚本、参考资料和资源文件。
五、我本地 Skill 目录长什么样?
我一开始进入本机的 Skill 目录时,看到的是这样:

可以看到,当时目录下只有一个:
这里要注意:自己新建的 Skill 不要放进 codex-primary-runtime 里面,而是和它平级。
也就是类似这样:
|
1
2
3
4
|
~/.codex/skills/
├── codex-primary-runtime
└── daily-report-polisher
└── SKILL.md
|
不过这里要补充一句:不同版本 Codex 的 Skill 路径可能不一样。新文档里也提到过用户级 Skill 路径可以是:
我这里是按我本机当时实际识别到的目录 ~/.codex/skills 测试的。最稳妥的方式是:看你本机 /skills 能不能识别到。
六、手动创建一个最简单的 Skill
比如我想创建一个日报优化 Skill,可以这样操作:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
|
cd ~/.codex/skills
mkdir -p daily-report-polisher
cat > daily-report-polisher/SKILL.md <<'EOF'
---
name: daily-report-polisher
description: 用于优化中文日报、周报、客户群回复、工作进展说明。适合把粗糙工作内容改成自然、简洁、适合发领导或客户群的表达。
---
# 日报和工作说明优化 Skill
## 适用场景
当用户提供日报、周报、客户沟通内容、工作进展说明、领导汇报草稿时,帮助用户优化表达。
## 输出要求
1. 语言自然,不要太官方。
2. 不要写得太复杂。
3. 不要夸大用户没有做过的工作。
4. 适合发领导、客户群或工作群。
5. 优先按 1、2、3 分点输出。
6. 如果是客户群回复,语气要稳妥,不要指定某一个人回复。
7. 如果涉及技术可实现但管理规则待确认,要体现“需要业务/管理侧确认规则”。
## 输出风格
简洁、稳妥、像正常工作沟通,不要像宣传稿。
EOF
|
然后启动 Codex:
进入 Codex 后,可以输入:
或者直接用 $ 调用:
|
1
|
$daily-report-polisher 今天看了AIP部署文档,改了架构图,和测试环境升级,解决登录问题。
|
我测试后,Codex 回复里出现了蓝色的 Daily Report Polisher 标签,说明 Skill 已经被调用到了:

这里就能直观看到:安装前只是普通对话;安装后,Codex 可以识别并调用这个 Skill,用我们提前写好的规则来整理日报。
七、带 Python 的 Skill 是什么样?
很多人会以为 Skill 就是提示词,其实不是。
如果 Skill 里面有 Python,它就更像:
- SKILL.md:告诉 Codex 什么时候运行脚本、脚本是干什么的
- Python 脚本:真正做拆分、统计、读取文件、生成初稿等机械活
- Codex:拿到脚本结果后,再进行理解和润色
比如一个工作记录整理 Skill 可以这样设计:
|
1
2
3
4
|
work-log-python-helper/
├── SKILL.md
└── tools/
└── worklog_report.py
|
SKILL.md 里可以写:
|
1
2
3
4
5
6
7
8
9
10
11
12
|
---
name: work-log-python-helper
description: 用 Python 拆分和分类中文工作记录,适合把杂乱工作流水整理成日报初稿。
---
# 工作记录整理 Skill
当用户提供一段杂乱工作记录,并要求整理日报时,优先运行:
python3 tools/worklog_report.py --text "用户输入内容"
运行脚本后,根据脚本输出继续润色成自然的日报。
|
Python 脚本可以简单写成:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
|
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
import argparse
import re
DONE_KEYWORDS = ["完成", "处理", "解决", "整理", "更新", "修改", "测试", "验证", "部署"]
ISSUE_KEYWORDS = ["问题", "报错", "异常", "失败", "无法"]
PLAN_KEYWORDS = ["后续", "计划", "继续", "明天", "下一步"]
def split_items(text: str):
parts = re.split(r"[。;;\n]+", text)
return [p.strip() for p in parts if p.strip()]
def classify(item: str):
if any(k in item for k in PLAN_KEYWORDS):
return "后续计划"
if any(k in item for k in ISSUE_KEYWORDS):
return "问题处理"
if any(k in item for k in DONE_KEYWORDS):
return "今日完成"
return "今日完成"
def main():
parser = argparse.ArgumentParser(description="工作记录整理工具")
parser.add_argument("--text", required=True, help="需要整理的工作记录文本")
args = parser.parse_args()
groups = {
"今日完成": [],
"问题处理": [],
"后续计划": [],
}
for item in split_items(args.text):
groups[classify(item)].append(item)
for title, items in groups.items():
if not items:
continue
print(f"## {title}")
for i, item in enumerate(items, 1):
print(f"{i}. {item}")
print()
if __name__ == "__main__":
main()
|
这里有几个小白要注意的点:
- Python 不是必须有 main(),但建议有,这样 Codex 更容易通过命令行调用。
- Skill 被选中,不等于 Python 一定会自动执行。
- Codex 会先读 SKILL.md,再判断当前任务是否需要运行 Python。
- 如果你明确说“先运行这个 Skill 里的 Python 脚本”,Codex 执行概率会更高。
- Python 能不能跑,取决于当前环境有没有 python3 和相关依赖。
八、Codex 为什么能执行 Python?是在本地执行还是远端执行?
Codex 能执行 Python,不是因为大模型自己在脑子里运行代码,而是因为 Codex 客户端有执行本地命令的能力。
简单理解:
- 大模型:判断应该执行什么命令
- Codex 客户端:把命令交给当前环境执行
- Python 解释器:真正运行 .py 文件
- Codex:读取命令输出,再决定下一步
如果你是在本机终端里运行 Codex CLI,那么 Python 通常就是在你的本机执行。比如:
|
1
|
python3 ~/.codex/skills/work-log-python-helper/tools/worklog_report.py --text "今天处理AIP环境升级"
|
这条命令是在你当前 Codex 所在的环境里执行的。
但如果你用的是远程环境、服务器、Codex Cloud,那么执行位置就可能是对应的远程环境或云端容器。
更准确地说:
Python 在 Codex Agent 当前所在的运行环境执行。
九、依赖包会不会冲突?磁盘会不会越来越大?
会有这个风险。
因为如果 Codex 执行了:
|
1
2
|
pip install pandas
pip install openpyxl
|
就可能把依赖装到当前 Python 环境里。
如果装到系统 Python,可能导致依赖冲突;如果每个项目都创建 .venv,不容易冲突,但磁盘可能慢慢变大。
所以建议在 Skill 里写清楚:
|
1
2
3
4
5
6
7
|
## Python 依赖规则
1. 不允许使用 sudo pip install。
2. 不允许向系统 Python 全局环境安装依赖。
3. 如需安装依赖,优先使用当前项目的 .venv。
4. 如果当前项目没有 .venv,先询问用户是否创建。
5. 优先使用 Python 标准库。
6. 不要重复创建多个虚拟环境。
|
对于简单 Skill,尽量只用 Python 标准库,比如:
argparse
re
pathlib
json
这样最安全。
十、Codex 为什么会自动选择不同 Skill?
Codex 启动后,会扫描已安装的 Skill。
但它不会一开始把所有 Skill 的完整内容都塞进上下文里,而是先看每个 Skill 的:
name
description
file path
官方文档把这个叫做 progressive disclosure(渐进式加载)。
也就是说:
|
1
2
3
4
5
6
7
|
先看 Skill 名称和描述
↓
判断任务是否匹配
↓
匹配后才读取完整 SKILL.md
↓
需要时再读取参考资料或运行脚本
|
所以 description 特别重要。
比如这个描述就比较容易触发:
|
1
|
用于优化中文日报、周报、客户群回复、工作进展说明。
|
如果只写:
Codex 就很难判断什么时候该用。
Codex 调用 Skill 有两种方式:
- 显式调用:用户直接输入 $skill-name。
- 隐式调用:用户没点名,但任务和 Skill 描述匹配,Codex 自己选择。
十一、Codex 为什么能反复执行直到成功?
这也是我最开始最困惑的地方。
后来我发现,Codex 的核心不是“特别能循环”,而是一个带反馈的智能循环。
可以记成:
|
1
|
目标 → 计划 → 执行 → 观察 → 修正 → 再执行 → 停止
|
比如你让 Codex 修复一个项目启动问题:
|
1
2
3
4
5
6
7
8
9
10
11
|
第 1 轮:运行 npm run dev
结果:报错,缺少 axios
第 2 轮:安装 axios
结果:又报端口占用
第 3 轮:检查端口
结果:发现 8080 被占用
第 4 轮:修改端口并重新启动
结果:启动成功
|
它不是死循环。
死循环是:
Codex 的循环是:
|
1
2
3
4
5
|
执行
看结果
判断哪里错了
换办法
再执行
|
所以 Codex 能反复执行,靠的是四件事:
- 大模型:负责理解任务、判断下一步。
- 工具执行能力:负责读文件、改文件、跑命令、运行 Python。
- 观察结果:比如命令输出、报错日志、测试结果。
- 停止条件:任务完成、测试通过、达到限制、需要用户确认。
官方文档里也提到,Codex 使用沙箱和审批机制来控制它能做什么:在默认权限下,它可以在当前 workspace 里读写文件、运行常规命令;需要越界、联网或高风险操作时,会走审批流程。
十二、Skill、Plugin、MCP 到底有什么区别?
这个地方很容易混。
我现在的理解是:
| 概念 |
小白理解 |
作用 |
| Skill |
做事说明书 + 小工具箱 |
告诉 Codex 按什么流程干活,可以带脚本 |
| Plugin |
可安装的大礼包 |
可以打包 Skill、App 集成、MCP Server |
| MCP |
外部系统连接接口 |
让 Codex 连接 GitHub、数据库、Figma、内部系统等 |
举例:
如果我要优化日报,只需要 Skill:
|
1
|
日报 Skill:规定输出风格、格式、注意事项
|
如果我要根据 GitHub 提交记录生成日报,就可能需要 MCP 或 GitHub 插件:
|
1
2
|
GitHub MCP / 插件:拿到提交记录
日报 Skill:把提交记录整理成日报
|
所以最简单的区分是:
Skill 解决“怎么做”,MCP 解决“连谁、查谁、调用谁”,Plugin 解决“把一套能力打包安装”。
下面这个截图就是 Codex 里的插件页面,里面可以看到 GitHub、Google Drive、PDF、Spreadsheets 等能力:

十三、Dify 工作流能不能复刻 Codex Skill?
能实现一部分,但不是一回事。
Dify 工作流里也有:
|
1
2
3
4
5
|
LLM 节点:相当于写提示词规则
Code 节点:可以执行 Python / JavaScript
Tool 节点:可以调用外部工具或 API
Agent 节点:可以让模型自主选择工具
Loop 节点:可以做循环和多轮修正
|
Dify 官方文档里也说明,Agent 节点可以让 LLM 自主控制工具并迭代决定什么时候用工具;Code 节点可以执行 Python 或 JavaScript;Loop 节点可以做多轮循环。
但是 Dify 和 Codex 的差别是:
Codex 天然支持 Skill 文件夹机制;Dify 更像可视化流程编排。
简单 Skill 可以在 Dify 里用一个 LLM 节点复刻。
复杂 Skill 如果硬拆到 Dify,工作流可能会变得很大:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
开始节点
↓
分类节点
↓
Code 节点
↓
工具节点
↓
LLM 润色节点
↓
循环判断节点
↓
结束节点
|
所以更合理的方式是:
|
1
2
3
4
|
简单规则:放 Dify 提示词节点
复杂处理:封装成 API 或工具
Dify:负责调用和编排
Codex Skill:更适合本地、代码、文件处理类自动化
|
十四、我现在对 Codex Skill 的理解
经过这次测试,我觉得可以这样总结:
1. Skill 不是神秘功能,本质是把重复做事方法沉淀下来。
比如日报、客户群回复、部署文档整理、Excel 统计,都可以做成 Skill。
2. 简单 Skill 像固定提示词。
一个 SKILL.md 就能完成。
3. 复杂 Skill 像一个能力包。
可以带 Python、Shell、模板、参考资料。
4. Codex 不是盲目执行。
它会根据 Skill 的 description 判断是否使用,使用时才读取完整内容。
5. Python 不是自动 乱跑。
Skill 被选中后,Codex 会根据 SKILL.md 和当前任务判断是否需要执行 Python。
6. Codex 的核心是智能循环。
不是普通死循环,而是:计划 → 执行 → 看结果 → 修正 → 再执行
7. 用 Codex 跑代码要注意安全。
不要随便让它全局安装依赖,不要轻易使用 sudo pip install,最好使用项目 .venv。
十五、最后一句话
如果你是小白,可以先不要想太复杂。
先记住这个版本:
Codex 是会动手干活的 AI 智能体;Skill 是给它安装的做事方法;Python 脚本是 Skill 里的小工具;MCP 是连接外部系统的接口;Plugin 是把一整套能力打包安装。
真正用起来以后,你会发现 Skill 最适合沉淀那些每天都重复说的要求,比如:
|
1
2
3
4
5
|
帮我优化日报
帮我改客户群回复
帮我整理部署文档
帮我检查项目目录
帮我把杂乱工作记录生成周报
|
这些东西只要写成 Skill,后面就不用每次重复交代了。