广告位联系
返回顶部
分享到

Codex Skill是什么?Codex Skill安装与使用的新手教程

Ai 来源:互联网 作者:佚名 发布时间:2026-07-02 22:15:30 人浏览
摘要

这篇文章是我自己学习 Codex、Skill、Plugin、MCP 过程中的一次整理。刚开始我也以为 Skill 就是提示词模板,后来发现它不只是提示词:简单 Skill 可以只写说明,复杂 Skill 还可以带 Python、Shell 脚

这篇文章是我自己学习 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()

这里有几个小白要注意的点:

  1. Python 不是必须有 main(),但建议有,这样 Codex 更容易通过命令行调用。
  2. Skill 被选中,不等于 Python 一定会自动执行。
  3. Codex 会先读 SKILL.md,再判断当前任务是否需要运行 Python。
  4. 如果你明确说“先运行这个 Skill 里的 Python 脚本”,Codex 执行概率会更高。
  5. 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 有两种方式:

  1. 显式调用:用户直接输入 $skill-name。
  2. 隐式调用:用户没点名,但任务和 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 能反复执行,靠的是四件事:

  1. 大模型:负责理解任务、判断下一步。
  2. 工具执行能力:负责读文件、改文件、跑命令、运行 Python。
  3. 观察结果:比如命令输出、报错日志、测试结果。
  4. 停止条件:任务完成、测试通过、达到限制、需要用户确认。

官方文档里也提到,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,后面就不用每次重复交代了。


版权声明 : 本文内容来源于互联网或用户自行发布贡献,该文观点仅代表原作者本人。本站仅提供信息存储空间服务和不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权, 违法违规的内容, 请发送邮件至2530232025#qq.cn(#换@)举报,一经查实,本站将立刻删除。
原文链接 :
相关文章
  • 本站所有内容来源于互联网或用户自行发布,本站仅提供信息存储空间服务,不拥有版权,不承担法律责任。如有侵犯您的权益,请您联系站长处理!
  • Copyright © 2017-2022 F11.CN All Rights Reserved. F11站长开发者网 版权所有 | 苏ICP备2022031554号-1 | 51LA统计