Codex 封装 Skill 三步法：从一次性对话到可复用自动化工作流

为什么要把重复流程做成 Skill？

你有没有遇到过这种情况：

每周一都要写周报，每次都要重新描述格式、粘贴素材、调整排版
每次分析竞品视频都要打开浏览器、复制数据、再写分析报告
每次配置 MCP 服务器都要翻文档、查配置格式、改配置文件

这些场景的共同点是：你做了一次，然后下次还要再做一遍。

Skill 的本质就是把「一次性的重复劳动」打包成「一句话就能触发的能力」。做完第一次，以后每次只说一个关键词。

第一步：完成第一次手工流程并记录结果

先做一遍你想要自动化的完整流程，不要急着封装。第一步的目标是让 Codex 跑通一次、产出满意的结果，同时把过程中的关键决策记录下来。

以一个「周报生成」为例：

打开 Codex，切换到目标项目目录
告诉 Codex 本周做了什么、有哪些数据、需要汇报给谁
Codex 生成初稿，你可能需要调整格式、补充内容
反复修改直到满意，最后把成稿保存下来

⚠️ 关键洞察：这一步花费的时间是值得的——因为后续 Skill 的质量完全取决于你对「满意结果」的理解有多清晰。

第二步：把流程沉淀为 SKILL.md

当一次手工流程跑通后，进入封装阶段。在 Codex 的输入框里输入 @llc（Skill Creator），唤醒 Codex 的 Skill 封装指南功能。

Skill 文件的标准结构

---
name: weekly-report
description: 根据本周工作记录自动生成周报，支持Markdown和Word格式
triggers:
  - "写周报"
  - "生成周报"
  - "周汇报"
---

一个完整的 SKILL.md 包含四个核心部分：

1. 输入信息定义

告诉 Codex 调用这个 Skill 时需要哪些材料：

## 输入要求
- 本周工作记录（文字描述或文件路径）
- 关键数据（如完成率、客户数、收入等）
- 汇报对象（技术总监/项目经理/全员等）

2. 触发关键词设定

定义什么时候自动激活这个 Skill：

## 触发条件
当用户提到以下关键词时激活：
- "写周报"
- "生成周报"
- "周汇报"
- "本周工作总结"

3. 模板与参考资料

指定参考素材，让输出格式保持一致：

## 参考资料
- 模板文件：./templates/weekly-report-template.md
- 历史周报：./references/past-reports/

4. 输出检验规则

设定质量标准，避免 Codex 自由发挥：

## 输出要求
1. 按「本周进度」「遇到问题」「下周计划」三段式结构
2. 数据部分必须来自用户提供的记录，不编造数字
3. 字数控制在 500-800 字，简洁为主
4. 最终输出为 Markdown 格式，保存到 ./output/ 目录

完整的 SKILL.md 示例

---
name: weekly-report
description: 根据本周工作记录自动生成周报，支持Markdown和Word格式
triggers:
  - "写周报"
  - "生成周报"
  - "周汇报"
---

# 周报生成助手

## 触发条件
当用户提到「写周报」「生成周报」「周汇报」时激活。

## 输入信息
- work_log: 本周工作记录（文字或文件路径）
- metrics: 关键数据（可选）
- audience: 汇报对象（可选，默认技术总监）

## 工作流程
1. 读取 work_log，提取关键事项
2. 按三段式结构组织内容
3. 如有 metrics，插入数据支撑
4. 输出 Markdown 文件到 ./output/ 目录
5. 如请求 Word 格式，调用脚本转换

## 输出格式
# 周报 YYYY-MM-DD
## 本周进度
- 事项1
- 事项2
## 遇到问题
- 问题描述及解决方案
## 下周计划
- 计划1
- 计划2

## 注意事项
- 不编造用户未提供的数据
- 技术问题用客观描述，不推卸责任
- 控制在 800 字以内

第三步：回归测试与迭代优化

Skill 创建完成后，进入实际使用阶段。把新的工作记录丢给 Codex，触发 Skill，观察输出是否符合预期。

验证清单

[ ] 触发词能正确激活 Skill
[ ] 输出格式符合要求
[ ] 不包含编造的数据
[ ] 文件保存到正确位置

迭代优化

如果某次输出不满意，直接让 Codex 修改 Skill 本身，而不是每次都重新解释需求：

"上周报里漏掉了'客户会议'这个板块，请在 SKILL.md 的工作流程里增加一步：检查是否有会议记录，如有则单独列出一个'客户沟通'章节。"

封装好的 Skill 不是成品，而是起点。随着使用次数增加，持续修改优化，它会越用越顺手。

Skill 的目录结构解析

Codex 生成的 Skill 通常是一个 .skill 文件夹，标准结构如下：

.weekly-report.skill/
├── SKILL.md          # 核心文件：触发条件、流程、输出规范
├── reference/        # 参考资料：模板、示例输出、校验规则
│   ├── template.md
│   └── example.md
├── scripts/          # 可执行脚本（可选）
│   └── to_word.py
└── config.json       # Skill 配置（可选）

SKILL.md 是最重要的文件，定义了 Skill 的"性格"和"行为边界"。写好这一步，后续维护成本会大幅降低。

什么时候该做 Skill？

并不是所有重复任务都值得封装成 Skill。一个简单的判断标准：

如果一个任务你在过去两周做了三次以上，就该考虑做 Skill。

太频繁的手工操作说明你有优化空间，而 Skill 的价值就在于把「隐性经验」变成「显性资产」——下次新人来也可以用同样的方式干活。

常见坑与排查

现象	原因	解决
Skill 不触发	触发词写得太宽泛或太窄	检查 triggers 字段，添加更多变体
输出不符合预期	提示词不够具体	在工作流程里增加步骤说明
引用文件找不到	路径写错了	用绝对路径或相对于项目根目录的路径
脚本执行失败	缺少依赖	在 SKILL.md 的说明里标注前置依赖

总结

Skill 封装的本质是经验固化。你把一次成功的实践写成文档，以后每次调用都按这个标准执行，不再需要重新思考"这次该怎么做"。

记住：Skill 不是一劳永逸的，它需要在使用中持续迭代。每一次不满意都是优化 Skill 的机会。

来源：编程知识网站《Codex封装Skill三步法：从一次性对话到可复用自动化工作流》（hqwc.cn，2026-10）

资料最后核对日期：2026-10-03 · 内容整理自 CodexGuide 社区公开教程