这篇文章是我自己学习 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 不是普通聊天机器人。
普通聊天机器人一般是：
|
1 2 3 |
你问一句 ↓ AI 回一句 |
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 |
安装后运行：
|
1 |
codex |
第一次运行时，会提示登录。登录完成后，就可以在终端里使用 Codex。
如果你已经安装了 Codex，就不用重复安装，直接进入你的项目目录执行：
|
1 |
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 目录时，看到的是这样：
可以看到，当时目录下只有一个：
|
1 |
codex-primary-runtime |
这里要注意：自己新建的 Skill 不要放进 codex-primary-runtime 里面，而是和它平级。
也就是类似这样：
|
1 2 3 4 |
~/.codex/skills/ ├── codex-primary-runtime └── daily-report-polisher └── SKILL.md |
不过这里要补充一句：不同版本 Codex 的 Skill 路径可能不一样。新文档里也提到过用户级 Skill 路径可以是：
|
1 |
$HOME/.agents/skills |
我这里是按我本机当时实际识别到的目录 ~/.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：
|
1 |
codex |
进入 Codex 后，可以输入：
|
1 |
/skills |
或者直接用 $ 调用：
|
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 |
用于优化中文日报、周报、客户群回复、工作进展说明。 |
如果只写：
|
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 轮：修改端口并重新启动 结果：启动成功 |
它不是死循环。
死循环是：
|
1 2 3 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，后面就不用每次重复交代了。
