当前位置：

社区首页

文化娱乐

在线教育

软件技能

文章详情

拒绝无效对话！一个 Skill 文件，让 AI 彻底记住你的工作流

如果你每周都要把同一段要求重新发给 CodeX，这篇文章就是写给你的。

比如每周五，你都要告诉 CodeX 助手：

先整理本周成果，再提炼问题和经验，最后列出下周行动。不要编造数据，每个行动都要有完成标准。

一次这样写，叫提示词。

每周都这样写，背后其实已经有了一套固定工作流。

把这套工作流整理成一个文件夹，让 CodeX 以后遇到类似任务就知道什么时候接手、按什么步骤执行、结果达到什么标准，这就是 Skill。

Skill 的本质，是把你脑子里的做事方法沉淀成一套可以重复执行的系统。

下面我会用“每周复盘”作为贯穿示范，带你走完这条路线：

找到工作流 → 拆解工作流 → 创建 Skill → 测试 → 上传代码仓库

你不需要先会编程。

一、先理解：什么是 Skill？

你可以把 CodeX 想成一位能力很强、但刚入职的新同事。

它懂写作、代码、表格和分析，但不知道：

你在什么情况下会启动某项工作；
你习惯先做什么、后做什么；
哪些规则不能违反；
输出必须包含哪些栏目；
做到什么程度才算合格。

Skill 就是你交给这位新同事的：

岗位说明书 + 标准作业流程 + 必要工具和资料

一份 Skill 通常会告诉 CodeX 四件事：

什么时候使用：哪些任务和说法应该触发它；
怎么执行：收到任务后按什么步骤工作；
可以用什么：脚本、参考资料或模板放在哪里；
什么算完成：最终输出必须满足哪些标准。

普通提示词通常只服务当前对话。

Skill 会保存在固定目录中。之后你可以用 $skill-name 点名，也可以让 CodeX 根据任务自动判断是否使用。

提示词解决一次任务，Skill 固化一类任务。

二、什么工作流值得做成 Skill？

不要看到任何提示词都急着做 Skill。

先用下面四个问题筛选：

这件事是不是会重复发生？
它有没有相对稳定的输入和输出？
中间是否存在固定步骤、规则或判断标准？
如果换一个 CodeX，你是不是还要重新解释一遍？

其中三个回答“是”，通常就值得沉淀。

✅ 适合做成 Skill 的例子

每周把零散记录整理成复盘和下周计划；
每次写长文的提示词技能，或者按照同一套标准起标题；
发布产品前执行固定的检查清单；
审核合同时检查相同的风险项；
根据品牌规则回复客服消息；
把固定格式的会议记录整理成任务清单；
重复处理同一类 PDF、表格或接口数据。

❌ 不适合的例子

只会发生一次的临时任务；
一句话就能说明白的简单操作；
完全依赖临场创意、没有稳定步骤的任务；
“帮我处理所有内容”这种没有边界的大目标。

这里最容易犯的错误，是一上来就做“全能内容助手”。

范围越大，触发越模糊，执行越不稳定。

“帮我做内容运营”不适合作为第一个 Skill。

“把访谈记录整理成一篇符合固定结构的长文”就清楚得多。

好的 Skill，不是无所不能，而是能把一件具体的事稳定做好。

三、第一步：把脑子里的工作流写到纸面上

选一件你最近一个月重复做过至少两次的工作，然后写出下面这张“工作流卡片”：

工作流名称：什么时候启动：用户会提供什么：执行步骤： 1. 2. 3. 最后输出什么：什么结果算合格：信息不足或出错时怎么办：

以“每周复盘”为例：

工作流名称：把一周的零散记录整理成复盘什么时候启动：用户提出周报、每周复盘、一周总结或工作回顾时用户会提供什么：一周内完成的事情、问题、数据和下周计划执行步骤： 1. 提取事实和数据 2. 分类为成果、进展、问题和经验 3. 合并重复内容 4. 把未完成事项转成下周行动 5. 检查是否存在编造或空话最后输出什么：结构化周复盘和下周行动表什么结果算合格：保留原始数据；不虚构；行动有优先级和完成标准信息不足时怎么办：标记“待补充”，最多提出 3 个问题，不要猜

这张卡片很重要。

因为 Skill 的 description、工作流程和质量标准，基本都来自这里。

如果你填不完，说明这件事可能还没有形成稳定工作流。

这时先多做几次，记录自己每次如何判断，再回来做 Skill。

不要把混乱包装成 Skill，先把工作流本身想清楚。

四、第二步：准备 3 个真实触发案例

接下来写三句用户可能真的会说的话。

第一句是明确点名：

请使用 $weekly-review 整理这周的记录。

第二句是自然表达：

帮我把这些流水账整理成周报，再列出下周优先级。

第三句是信息不完整的边界情况：

这周主要在做支付功能，帮我复盘一下。

这三句话分别测试：

点名后能不能正确执行；
没点名时能不能自动触发；
信息不足时会不会乱编。

很多人只写“这个 Skill 能做什么”，却没有想过“用户会怎么说”。

结果就是文件写得很长，但 CodeX 根本不知道什么时候应该使用。

触发案例不是宣传文案，而是 Skill 的入口测试。

五、第三步：决定 Skill 里要放什么

一份 Skill 最小只需要一个文件：

your-skill/ └── SKILL.md

比较完整的结构是：

your-skill/ ├── SKILL.md ├── agents/ │ └── openCodeX.yaml ├── scripts/ ├── references/ └── assets/

每个部分解决的问题不同：

SKILL.md：必需，写触发条件、工作步骤和质量标准；
agents/config.yaml：推荐，控制界面里的名称、简介和默认提示；
scripts/：放需要稳定执行的代码，例如格式转换和数据校验；
references/：放规则、术语、接口文档等长资料；
assets/：放最终交付会用到的模板、图片、字体等素材。

怎么判断要不要增加目录？

只有文字流程：先写一个 SKILL.md；
同一段代码每次都要重写：放进 scripts/；
背景资料很长，不是每次都要读：放进 references/；
每次交付都要套相同模板：放进 assets/。

不要为了显得专业，先建立一堆空目录。

Skill 会占用上下文，应该只保留完成任务真正需要的内容。

先做最小可用版本，用到什么再增加什么。

六、第四步：让 CodeX 初始化 Skill

Skill 名称只使用：

小写英文字母；
数字；
连字符。

不要使用空格和中文，文件夹名称要和 Skill 名保持一致。例如：

weekly-review x-article-writer check-release contract-risk-checker

新手最简单的做法，是直接让 Codex 调用自带的 skill-creator。把前面完成的工作流卡片发给 Codex：

请使用 skill-creator，把下面的工作流做成一个 Skill。 Skill 名称：weekly-review 工作流： [粘贴你的工作流卡片] 要求： 1. 先创建在当前项目中； 2. 只创建真正需要的文件； 3. 完成后验证 Skill； 4. 告诉我如何测试和安装。

skill-creator 会使用初始化脚本，生成符合结构要求的文件夹。这次实际生成的是：

weekly-review/ ├── SKILL.md └── agents/ └── openCodeX.yaml

看到 SKILL.md 和 agents/config.yaml，说明初始化完成。

但这时只是有了空房子，真正决定 Skill 是否好用的，是接下来写进去的内容。

七、第五步：写好 SKILL.md

SKILL.md 分为两部分：

YAML 头部；
Markdown 正文。

1. YAML 头部决定“什么时候触发”

文件开头必须是：

--- name: weekly-review description: 将一周的零散记录整理成结构化复盘和下周行动计划。用户提到周报、每周复盘、一周总结、工作回顾、学习复盘，或要求从流水账中提炼成果、问题、经验和下一步行动时使用。 ---

这里最重要的是 description。

它必须同时回答两个问题：

这个 Skill 能做什么？
用户在什么场景下应该使用？

不要只写：

帮助用户复盘。

这句话没有具体场景。

应该把“周报、每周复盘、一周总结、流水账”等真实触发方式写进去。

CodeX 会先读取 name 和 description 判断是否触发，然后才会读取正文。

所以“什么时候使用”要写在 description 中，不要藏在正文最后。

2. 正文决定“触发后怎么做”

正文不需要介绍 Skill 有多厉害。

它是给另一个 CodeX 实例看的执行说明。

可以使用这套通用结构：

# Skill 名称用一句话说明目标。 ## 工作流程 1. 收集并检查输入 2. 按固定规则处理 3. 生成结果 4. 检查结果 ## 信息不足或异常时 - 缺少重要信息时怎么处理 - 哪些内容不能猜测 - 什么时候应该停止并询问用户 ## 输出格式 [固定栏目、顺序或模板] ## 质量标准 - 必须包含什么 - 不能出现什么 - 怎么判断已经完成

这次的每周复盘 Skill，核心流程是：

## 工作流程 1. 提取事实：识别已完成事项、进展、数据、问题和未完成事项。 2. 分类整理：归入本周成果、关键进展、问题与原因、经验与洞察。 3. 提炼重点：合并重复内容，不编造用户没有提供的事实。 4. 制定行动：把未完成事项和问题转成下周行动。 5. 检查输出：行动不超过 5 个，最高优先级不超过 3 个。 ## 信息不足时 - 缺少日期、数据或负责人时，标记为“待补充”，不要猜测。 - 记录过少时，先输出可确认的内容，再提出最多 3 个问题。 ## 质量标准 - 使用具体动词，避免“持续优化”“积极推进”等空话。 - 区分事实与推断。 - 每个行动都要有可以检查的完成标准。

写正文时记住三条：

只写完成任务必须知道的内容；
越容易出错的环节，规则越要具体；
能用 30 行说清楚，就不要写 300 行。

Skill 不是知识百科，而是执行手册。

八、第六步：验证并安装

写完后，不要直接宣布完成。

先让 skill-creator 验证：

请使用 skill-creator 验证 ./weekly-review。如果发现格式、命名或 YAML 问题，直接修复后重新验证。

验证器会检查：

文件夹名称和 Skill 名称是否一致；
YAML 格式是否正确；
name 和 description 是否存在；
名称是否符合规则。

成功时会看到类似 Skill is valid! 的通过提示（具体文案以你本地 skill-creator 版本为准）。

然后把整个 Skill 文件夹安装到 CodeX 的 Skill 目录。

默认通常是：

~/.codex/skills/

Codex 不同版本/文档里也出现过 .agents/skills 的写法，本质一样，选一个保持前后一致即可；本文沿用 .codex/skills/。

macOS 或 Linux 可以执行：

cp -R ./weekly-review ~/.codex/skills/

也可以直接告诉 Codex：

请把 ./weekly-review 安装到我的 Codex Skills 目录。

截图要点：skill-creator 验证通过的终端输出，以及 ~/.codex/skills/weekly-review 安装后的目录结构。

如果安装后没有立刻出现，新开一个 Codex 任务；仍然没有，再重启 Codex。

结构校验通过，只能证明文件格式正确。

它还不能证明这套工作流真的好用。

九、第七步：拿真实工作测试

回到前面准备的三个案例，逐个测试。

测试 1：明确点名

请使用 $weekly-review 整理下面的记录。

检查是否按照 Skill 规定的栏目和顺序输出。

测试 2：不点名

把这些流水账整理成周报，再列出下周优先级。

检查 description 是否足够清楚，能让 Codex 自动识别。

测试 3：信息不完整

这周主要在做支付功能，帮我复盘一下。

检查它是否明确标记缺失信息，而不是虚构日期、数据和负责人。

我实际测试时，输入了首页上线、支付联调故障、证书过期、页面修复和下周 A/B 测试等零散记录。

Skill 自动整理出了：

本周成果；
关键进展；
问题与原因；
经验与洞察；
带优先级和完成标准的下周行动；
需要补充的信息。

如果结果不理想，不要马上推翻整个 Skill。

先判断问题发生在哪里：

没有自动触发：改 description；
执行顺序不稳定：改工作流程；
总是出现空话：增加质量标准；
信息不足时乱编：增加异常处理规则；
同一段代码反复生成：把它放进 scripts/；
SKILL.md 越写越长：把长资料放进 references/。

测试的目的不是证明第一版正确，而是找到下一次应该改哪里。

十、第八步：上传到代码仓库

Skill 在本地跑通后，再上传代码托管平台（如 GitHub / Gitee）。

代码仓库能帮你：

备份自己的工作流；
记录每次修改；
在多台设备之间同步；
分享给团队或粉丝；
出问题时回到旧版本。

先在代码平台创建一个空仓库。

⚠️ 如果 Skill 包含公司流程、客户案例或内部规则，选择 Private。

公开之前，检查并删除：

API Key；
Token；
密码和账号；
客户数据；
公司内部地址；
未公开的业务规则。

然后在本地项目目录执行：

git init -b mCodeXn # 需要 Git ≥ 2.28；老版本用 git init && git branch -m mCodeXn git add . git commit -m "feat: add my first Codex skill" git remote add origin <你的仓库地址> git push -u origin mCodeXn

以后每次修改，只需要：

git add . git commit -m "docs: improve skill workflow" git push

上传前可以用：

git status git diff --cached

确认即将提交的文件中没有敏感信息。

到这一步，你完成的已经不只是一段提示词。

你拥有了一套可以安装、测试、修改、同步和分享的个人工作流。