这两年用 AI 工具的人越来越多，但许多人的使用方式还停留在一个阶段：

每次打开对话
重新解释背景
重新贴一遍要求
重新告知它输出格式
重新纠正它哪里不符合自己的习惯

这就很累。

尤其是做数据治理、写方案、处理文档、生成代码、做网页测试这些工作，许多流程实则是重复的。

列如你每次写数据标准，都要告知 AI：

• 先看业务背景。
• 不确定的地方写“需确认”。
• 字段定义不要瞎编。
• 输出要有 Owner、质量规则、审核流程。
• 最后要能落到模板和 SQL。

如果每次都从头讲一遍，AI 的确能帮你，但效率没有被真正释放出来。

这时候，Skill 就有用了。

图 1：Skill 是什么

---

01 什么是 Skill？

先说一句大白话：

Skill 就是给 Codex 准备的一份“专业工作说明书”。

它不是单纯的一段提示词，也不是传统意义上的插件按钮。

它更像是一个小型工作包，里面告知 Codex：

什么场景下要用这个 Skill
这类任务应该怎么做
有哪些步骤不能跳
需要参考哪些资料
可以复用哪些脚本或模板
最后如何检查结果

如果普通提示词像是你临时交代一句“帮我做这个事”，那 Skill 更像是你把一套成熟流程写成了操作手册。

下次再遇到类似任务，Codex 不需要重新猜你的习惯，它可以直接按这套手册办。

Skill 里面一般有什么？

一个 Skill 最核心的是 SKILL.md。

这个文件里一般包括两部分：

1. 前置信息：Skill 名称、什么时候应该使用
2. 正文说明：具体工作流程、注意事项、资源使用方式

除了 SKILL.md，Skill 还可以带一些资源：

资源 作用 举例 scripts 放稳定可复用的脚本 批量处理 PDF、生成数据字典、校验文件 references 放参考资料 业务口径、数据模型、API 文档、方法论 assets 放素材模板 Word 模板、PPT 模板、图片、字体 agents 放界面展示信息 名称、简介、默认提示语

所以，Skill 本质上不是“让 AI 更神秘”，而是让 AI 更稳定。

它解决的是什么问题？

我觉得主要是 4 个问题：

许多任务不是一次性任务，而是反复做。Skill 可以把背景、流程、格式沉淀下来。

重复交代背景

今天输出表格，明天输出散文，后天又变成 PPT 大纲。Skill 可以把输出约束固定住。

输出不稳定

列如数据治理里“需确认”“Owner”“质量规则”“审核流程”这些东西，Skill 可以反复提醒 Codex。

专业细节容易漏

有些事光靠聊天不够，列如批量生成、文件处理、校验脚本。这类动作适合放进 Skill 的 scripts 里。

工作可以工具化

---

02 Skill 适合哪些场景？

不是所有事都需要 Skill。

如果你只是问一句“帮我润色这段话”，没必要专门做一个 Skill。

但如果一件事符合下面几个特点，就很值得做成 Skill：

高频重复
流程相对固定
容易遗漏细节
需要固定输出格式
有公司/行业专属知识
需要配合脚本、模板或资料

列如这些场景就很适合：

• 写数据治理方案。
• 生成数据标准和数据字典。
• 做 PDF、Word、Excel 的批量处理。
• 自动化网页测试和截图。
• 写固定风格的公众号文章。
• 生成某类汇报 PPT。
• 审查 SQL 命名、字段口径、质量规则。
• 按公司模板生成项目周报。

反过来，下面这些场景不太适合：

• 一次性闲聊。
• 没有固定流程的创意发散。
• 需求还没想清楚，只是随意问问。
• 纯粹靠模型通用能力就能处理的简单问题。

Skill 最适合的不是“万能”，而是“稳定复用”。

---

03 如何使用现成的 Skill？

使用 Skill 的方式很简单。

你不必定需要记住什么复杂命令。许多时候，你只要把任务说清楚，Codex 会根据任务自动判断是否需要调用某个 Skill。

列如：

帮我把这个 PDF 提取成结构化 Markdown。

这类任务可能会触发 PDF 相关 Skill。

再列如：

帮我用真实浏览器打开这个页面，检查移动端布局有没有问题。

这类任务可能会触发 Playwright 相关 Skill。

如果你想明确指定，也可以直接说：

使用 playwright 这个 Skill 帮我检查页面。

或者：

使用 skill-creator 帮我创建一个数据治理 Skill。

我个人更提议这样表达：

我要完成什么任务
希望使用哪个 Skill
输入材料在哪里
最终要交付什么结果
有什么限制条件

例如：

使用 skill-creator，帮我设计一个“地产项目主数据治理”的 Skill。

这个 Skill 主要用于：
1. 生成项目主数据标准
2. 生成数据字典
3. 生成质量规则
4. 生成治理方案

输出请包括 SKILL.md 的草稿、目录结构提议和验证清单。

这样比只说“帮我创建 Skill”要好许多。

---

04 如何安装 Skill？

安装 Skill 可以分成两类：

1. 安装官方或精选列表里的 Skill
2. 从 GitHub 仓库安装别人写好的 Skill

在 Codex 里，这类事情一般交给 skill-installer 来处理。

图 2：安装 Skill 的基本路径

你可以直接这样说：

帮我列出可以安装的 Skill。

如果你已经知道名称，也可以说：

帮我安装 xxx 这个 Skill。

如果 Skill 在 GitHub 上，可以说：

从这个 GitHub 地址安装 Skill：
https://github.com/xxx/xxx/tree/main/skills/xxx

安装后要做什么？

有一个小细节很重大：

安装完新的 Skill 后，一般需要重启 Codex，让它重新发现这些 Skill。

由于 Skill 不是你粘贴到当前对话里的一段文字，它是放在本地目录里的能力包。重启后，Codex 才会把新的 Skill 纳入可用范围。

默认情况下，安装的 Skill 会进入类似这样的目录：

$CODEX_HOME/skills

如果没有设置 CODEX_HOME，一般会落到：

~/.codex/skills

安装前要注意什么？

我提议别一口气装太多。

Skill 不是浏览器收藏夹，不是越多越好。

比较好的方式是：

先装 2-3 个高频场景
用真实任务跑一跑
确认的确   节省时间
再继续补充

尤其是从第三方仓库安装 Skill 时，要稍微看一下它要做什么、会不会带脚本、脚本是否会改文件。

---

05 我推荐先关注哪些 Skill？

我会把 Skill 分成两类：

一类是“基础能力型”
一类是“工作流增强型”

基础能力型，解决的是文件、网页、数据这些通用工作。

工作流增强型，解决的是“如何把某类任务做得更稳定”。

图 3：推荐 Skill 卡片

1. skill-creator

这是创建 Skill 最重大的一个。

如果你想把自己的经验沉淀成可复用能力，列如：

• 数据治理方案写作。
• 地产项目主数据治理。
• 公众号选题和排版。
• 公司内部周报生成。
• SQL 评审规范。

都可以先用它来搭框架。

2. skill-installer

这个负责安装 Skill。

你可以让它列出可安装的 Skill，也可以让它从 GitHub 指定路径安装。

对普通用户来说，不需要关心太多安装细节，只要告知 Codex 你要安装什么即可。

3. playwright

如果你做网页、小程序后台、数据看板、可视化页面，这个很有用。

它适合做：

• 打开真实网页。
• 模拟点击和输入。
• 截图。
• 检查移动端布局。
• 验证页面元素是否正常显示。

这比“凭感觉看代码”靠谱许多。

4. pdf / documents / spreadsheets

这类 Skill 很适合办公场景。

列如：

• 读取 PDF。
• 生成 Word。
• 处理 Excel。
• 校验表格。
• 做报告。
• 批量整理文档。

如果你常常做资料整理、项目报告、数据治理文档，这类 Skill 很值得放进日常工作流。

5. data-analytics

这个适合数据分析和报告类任务。

列如：

• 分析一份 CSV。
• 做指标看板。
• 写经营分析报告。
• 找指标波动缘由。
• 做图表和结论摘要。

它和数据人的工作很贴近。

6. openai-docs

如果你常常研究 OpenAI 产品、API、Codex 使用方式，这个很有价值。

由于这类信息更新快，用本地旧知识容易过时。让它优先查官方资料，答案会稳许多。

7. imagegen

适合生成文章配图、产品概念图、封面图、信息图。

但我提议：如果是严肃流程图、思维导图、架构图，最好用可控的方式生成，不要完全依赖随机图片。文字多的图尤其要注意，AI 生成图很容易出现错字。

---

06 一个 Skill 长什么样？

一个典型 Skill 目录可以这样理解：

图 4：Skill 目录结构

最小可用结构实则很简单：

my-skill/
└── SKILL.md

如果只是沉淀一套工作流程，一个 SKILL.md 就够了。

如果任务更复杂，可以逐步加：

my-skill/
├── SKILL.md
├── agents/
│   └── openai.yaml
├── scripts/
├── references/
└── assets/

SKILL.md 最关键

许多人第一次做 Skill，容易一上来就纠结脚本和目录。

实则最关键的是 SKILL.md。

由于 Codex 是否会使用这个 Skill，主要看前面的描述是否清楚。

一个好的描述要讲清楚：

这个 Skill 做什么
什么时候应该使用
适合哪些任务
不适合哪些任务

不要只写：

description: 用于数据治理

这太泛了。

更好的写法是：

description: Create and review real estate project master data governance deliverables, including project data standards, data dictionaries, data quality rules, governance plans, and review checklists. Use when Codex needs to help with real estate master data, project code standards, project status definitions, organization mapping, or data quality SQL for project master data.

这段不必定要很长，但要够具体。

正文不要写成百科全书

Skill 不是给人看的长篇教程，而是给 Codex 用的工作说明。

所以不要塞太多常识。

列如你不需要在 Skill 里解释“什么是数据治理”解释 2000 字。

更应该写：

处理地产项目主数据标准时，必须输出：
1. 项目定义
2. 编码规则
3. 项目状态枚举
4. 组织归属关系
5. 面积口径
6. Owner 和审核流程
7. 待确认问题

这才是 Codex 真正需要的。

---

07 如何创建属于自己的 Skill？

创建 Skill 不难，难的是别一开始就写成大而全。

我提议按 6 步来做。

图 5：创建 Skill 的 6 步流程

第一步：先想清楚真实任务

不要从“我要创建一个很厉害的 Skill”开始。

要从真实任务开始。

列如：

我常常要写地产项目主数据标准。
我常常要根据 DDL 生成数据字典。
我常常要把质量规则转成 SQL。
我常常要把治理方案整理成可汇报版本。

这就是很好的 Skill 候选场景。

你可以先列 3-5 个真实请求：

1. 根据项目主数据表结构，生成数据字典。
2. 根据项目状态口径，生成项目主数据标准。
3. 根据项目字典，生成质量规则清单。
4. 根据质量规则，生成 Spark SQL 检核脚本。
5. 根据以上材料，生成项目主数据治理方案。

真实请求越清楚，Skill 越容易写稳。

第二步：规划哪些内容该放进 Skill

你要判断哪些东西是每次都会重复用到的。

列如“地产项目主数据治理”这个 Skill，可能需要：

内容 放在哪里 说明 工作步骤 SKILL.md 每次处理都要遵守 项目状态枚举 references 作为参考口径 组织层级说明 references 区域公司、城市公司、项目公司 数据标准模板 assets 或 references 固定输出格式 批量生成脚本 scripts 从 DDL 生成字典或规则 审核清单 SKILL.md 或 references 结果交付前必须检查

一个简单原则：

每次都要读的，放 SKILL.md；不是每次都要读的，放 references；可以自动跑的，放 scripts；要复制使用的模板，放 assets。

第三步：取一个好名字

Skill 名称提议：

• 全小写。
• 用短横线连接。
• 不要太长。
• 尽量动词或任务导向。

列如：

real-estate-master-data
data-standard-writer
sql-quality-rules
wechat-article-layout

不要用：

我的超级无敌数据治理知识库
Data Governance V2 Final Final

名字越朴素，越好维护。

第四步：初始化 Skill

你可以直接让 Codex 用 skill-creator 帮你创建。

列如说：

使用 skill-creator，帮我创建一个 real-estate-master-data Skill。

用途：
1. 生成地产项目主数据标准
2. 生成项目主数据字典
3. 生成质量规则
4. 生成 SQL 校验
5. 生成治理方案

请放到默认 Skill 目录，并带 references 和 scripts 目录。

skill-creator 的提议流程一般是：

理解任务
规划资源
初始化目录
编辑 SKILL.md
添加脚本/参考资料/素材
验证 Skill
真实任务试跑

这一步不要急着写太多内容，先把骨架搭起来。

第五步：写 SKILL.md

一个最小版 SKILL.md 可以像这样：

---
name: real-estate-master-data
description: Create and review real estate project master data governance deliverables, including project data standards, data dictionaries, data quality rules, governance plans, and review checklists. Use when Codex works on real estate project master data, project code standards, project status definitions, organization mapping, or project data quality SQL.
---

# Real Estate Master Data

Use this skill when the user needs help with real estate project master data governance.

## Workflow

1. Clarify the business object: project, phase, region company, city company, or project company.
2. Inspect available materials: DDL, data dictionary, business notes, current standards, sample records.
3. Produce a structured draft: standard, dictionary, quality rules, SQL checks, or governance plan.
4. Mark unknown facts as "需确认"; never invent source systems or business ownership.
5. Add a review checklist before final delivery.

## Required Checks

- Project code uniqueness
- Project status enum validity
- Organization mapping validity
- Area field consistency
- Owner and approval process
- Sensitive business data redaction

这只是一个简化示例。

真正使用时，可以继续补：

• 输入材料要求。
• 输出模板。
• 字段命名规则。
• 数据质量规则分类。
• SQL 风格要求。
• 审核清单。

第六步：验证 Skill

Skill 写完后，不要直接当成正式版本。

至少要做三件事：

看 SKILL.md 的前置字段是否正确，名称是否符合规则。

结构验证

用真实请求试一次，列如“根据这张项目表生成数据字典”。

任务试跑

看它有没有真的减少解释成本，有没有固定住输出质量。

结果复盘

如果一次试跑之后，你发现 Codex 还是常常漏掉“需确认”“Owner”“审核流程”，那就把这些要求写得更明确。

Skill 不是一次写完的。

它更像一个工作流版本库，用得越多，越知道该怎么改。

---

08 用一个完整例子串起来

假设我要做一个“地产项目主数据治理”的 Skill。

我会这样设计。

图 6：自定义 Skill 示例

1. 这个 Skill 解决什么问题？

解决地产项目主数据治理中反复出现的几类工作：

• 项目编码标准。
• 项目状态标准。
• 区域公司、城市公司、项目公司归属关系。
• 项目名称、分期、期区口径。
• 面积、权益比例、拿地时间、交付时间等字段定义。
• 数据字典。
• 数据质量规则。
• SQL 检核脚本。
• 治理方案和 RACI。

2. 它应该准备哪些参考资料？

可以准备这些文件：

references/
  project_status.md
  organization_hierarchy.md
  area_definition.md
  data_quality_rule_types.md

列如 project_status.md 里写：

RESERVE：储备项目
ACQUIRED：已拿地
UNDER_CONSTRUCTION：在建
ON_SALE：在售
DELIVERED：已交付
SETTLED：已结转
TERMINATED：终止

这样 Codex 后来生成项目状态规则时，就不会每次都重新猜。

3. 它可以有哪些脚本？

如果常常批量处理表结构，可以放脚本：

scripts/
  ddl_to_dictionary.py
  rules_to_sql.py
  validate_dictionary.py

脚本不是必须的。

但一旦某个动作你发现自己重复做三次以上，就可以思考脚本化。

列如：

• 从 DDL 批量抽取字段。
• 按模板生成数据字典。
• 把质量规则 CSV 转成 SQL。
• 校验字典里是否缺少中文名、Owner、枚举值。

这类事情让脚本做，比每次让 AI 现场发挥更稳定。

4. 它的输出应该长什么样？

提议固定 5 类输出：

1. 数据标准 Markdown
2. 数据字典 Markdown / Excel
3. 质量规则 CSV
4. SQL 检核脚本
5. 治理方案 Markdown / PPT 大纲

每一类输出都要有审核状态：

草稿
待业务确认
待技术确认
已确认

这样它才不是“生成一堆文档”，而是真的接近治理流程。

---

09 创建 Skill 时最容易踩的坑

坑 1：把 Skill 写成百科全书

许多人一上来就想把所有知识都塞进 SKILL.md。

结果文件很长，Codex 读起来也累。

更好的做法是：

核心流程放 SKILL.md
详细资料放 references
稳定动作放 scripts
模板素材放 assets

坑 2：description 写得太虚

description 是触发 Skill 的关键。

不要只写“用于数据治理”。

要写清楚：

做什么
什么时候用
适合哪些具体任务

坑 3：没有真实例子

没有真实任务，Skill 很容易写成口号。

创建前最好先列 3 个真实请求。

坑 4：没有验证

Skill 写完后必定要试跑。

能不能触发，输出是否稳定，是否减少沟通成本，都要用真实任务验证。

坑 5：什么都想自动化

Skill 可以帮你沉淀流程，但不能替代业务判断。

尤其是数据标准、合规、安全、财务口径，最后还是要人审核。

坑 6：装太多不用

Skill 装了不用，就只是目录里的文件。

真正有价值的是把它接进你的日常工作流。

---

10 我自己的使用提议

如果你刚开始用 Skill，我提议按这个顺序来：

第一步：先用现成 Skill
第二步：观察自己重复解释最多的任务
第三步：把这个任务整理成流程
第四步：用 skill-creator 做成自己的 Skill
第五步：用真实任务跑 3 次
第六步：边用边改

不要一开始就追求“完美 Skill”。

先做一个小的。

列如：

公众号文章排版 Skill
数据治理方案 Skill
地产项目主数据 Skill
Excel 清洗 Skill
SQL 评审 Skill

只要它能让你少解释 30%，就已经值得。

最后用一句话总结：

Skill 的价值，不是让 AI 看起来更高级，而是把你的经验变成可复用、可触发、可验证的工作流。

这才是它真正有意思的地方。

---