用 Codex Skills 复用博客写作与内容核查流程

2026年10月4日

你每周都用 AI 写文章，却总要重新说明文风、如何核实来源，以及发布前要检查什么？Codex Skills 可以把这些重复的指令整理成可复用的流程。大约 20 分钟内，你将创建一个用于起草和检查博客文章的小型 Skill，再用一个示例主题试运行。你需要一个工作文件夹，以及一个有权读取该文件夹的 Codex 会话。

Skill 帮助 Codex 记住流程；最终结果仍需由你检查。

准备工作

你需要 OpenAI Codex、一个项目文件夹或测试文件夹，以及一篇你认可其质量的旧文章。如果没有旧文章，只需写下三件事：读者是谁、希望采用什么文风，以及发布前的检查标准。本文以面向初学者的 AI 科普文章为例，你也可以换成产品介绍、使用指南或内部简报。

如果你刚入门，可以阅读如何写出目标和输出明确的提示词和什么是氛围编程。

分步操作

1. 选择一项具体的重复任务

不要一开始就创建名为“制作所有内容”的 Skill。选择一项输入和结果都容易辨认的任务：根据提供的来源起草博客文章，再列出需要人工检查的地方。输入包括主题、读者、来源链接和预计篇幅。输出包括草稿、已用来源清单，以及需要核实的表述。

创建文件前，先为自己写下初始要求：

目标：为[读者群体]撰写一篇关于[主题]的博客文章。
输入：[来源链接]、[产品笔记]、[范文]。
输出：包含引言、各节和结论的草稿。
检查：指出哪些表述没有来源；不要猜测功能、价格或发布日期。

AI 产品信息变化很快。流程应指出到哪里核实事实，不能把猜测写成断言。

2. 创建 Skill 文件夹

按照 OpenAI 的示例，一个 Skill 有独立的文件夹，以及一个包含名称、描述和指令的 SKILL.md 文件。在测试项目中，你可以将它放在 .codex/skills/blog-review/SKILL.md。如果想在自己电脑上的多个项目中使用，OpenAI 文档也给出了 ~/.codex/skills/ 这个示例位置。根据你希望共享的范围选择合适的位置。在使用别人发来的 Skill 前，请阅读其中的文件和附带的程序。

创建一个包含以下示例内容的文件。描述说明 Codex 何时应该使用 Skill，正文说明要做什么：

---
name: blog-review
description: 当用户提供主题、读者和参考来源时，起草并检查博客文章。
---

收到起草或检查博客文章的请求时：
1. 确认主题、读者、目标以及允许使用的来源。
2. 写作前先阅读来源。如果来源缺失或无法打开，明确说明缺少什么。
3. 引言直接回答核心问题；按照读者的问题组织正文。
4. 标记需要核实的价格、日期、功能和可用范围方面的表述。
5. 返回草稿和文末检查清单。不要自行发布文章。

blog-review 这个名称只是示例。如果流程只需要文字指令，就不要添加可执行代码或访问密钥。

3. 用真实请求调用 Skill

OpenAI 建议通过直接提及 Skill 名称来测试它。在包含 Skill 的文件夹中打开 Codex，给出一项简短任务：

使用 $blog-review 为[读者]起草一篇关于[主题]的文章。
只使用以下来源：[链接 1]、[链接 2]。
篇幅约为[词数]词。暂不发布。

第一次测试最好选择你熟悉的主题，以便发现来源被误用或步骤被跳过。如果 Codex 没有识别 Skill，请检查文件位置、SKILL.md 文件名、描述，以及文件夹的读取权限。不同 Codex 环境中的 Skill 调用方式可能有所不同。

4. 像编辑一样审读输出

不要只问“文章读起来好不好”。要逐项对照最初的目标。引言回答了问题吗？每一项具体断言都有来源支持吗？有没有重复的段落？文章是否区分了假设性示例和真实事实？待核实清单是否准确指出仍缺少证据的表述？

为了便于审查，请 Codex 在文章后面再添加一个简短表格：

在草稿之后列出：
1. 三项重要断言及其对应来源。
2. 尚未核实的信息。
3. 发布前需要编辑决定的两处问题。

这个表格只能辅助你。请打开原始来源直接核对。涉及 OpenAI 产品时，优先使用官方文档；如果来源注明了发布状态，也要明确写出。

5. 试运行一次后修改流程

如果 Codex 的引言太长，就把 Skill 改成“引言最多三句”。如果它写了价格却没有核实日期，就加入“每个价格都需要来源和查阅日期”。如果它加入宣传性用语，就要求避免推销口吻。修改规则，然后用同一项任务重试，以便看清发生了什么变化。

把重复使用的规则放在 Skill 中，把单次任务的要求放在提示词中。例如，“始终核实来源”属于 Skill；“向八年级学生解释”属于当前文章的要求。

6. 检查 Skill 是否在适当的时候被调用

一次运行成功还不够。再试三个请求：一个明确提及 $blog-review，一个只说“帮我检查博客文章”，还有一个无关的请求，比如“修复 CSS 错误”，此时不应使用这个 Skill。根据 OpenAI 的测试指南，名称和描述是 Codex 决定是否使用 Skill 的重要信号。如果 Skill 被过于广泛地触发，就让描述更具体；如果该触发时没有触发，就更清楚地说明使用场景。

保存这三项任务，以便每次修改 Skill 后重新运行。

示例结果

假设你提供了某个 AI 工具的两页官方文档，并要求写一篇面向初学者的文章。使用 Skill 后，预期结果不只是一篇草稿，还应包含如下检查部分：

草稿：介绍这个工具能帮助读者做什么、如何开始，以及需要了解的限制。
已用来源：用户提供的两页文档。
待核实：支持的国家或地区以及账户类型。
编辑决定：是否需要加入实际操作的截图？
状态：草稿，尚未发布。

如果来源没有提到价格，就写**“价格尚未核实”**，不要猜测。

获得更好结果的技巧

围绕使用场景写描述。“有参考来源时起草并检查博客文章”比“帮助写好文章”更有用。Codex 需要知道何时打开这个流程。

**保持 SKILL.md 简洁。**如果你有较长的标准表格、文章模板或已获批准的示例，可以把它们放进 Skill 的参考资料文件夹，并说明何时阅读。OpenAI 文档允许 Skill 包含 references/、assets/ 和 scripts/，但只有它们确实有助于任务时才添加。

**把高风险操作分开。**起草、核实来源和公开发布是不同的步骤。示例 Skill 在草稿阶段停止。真正需要发布流程时，应明确访问权限和确认步骤，而不是让一条笼统指令自行决定。

**用真实任务评估。**选择一篇简单文章、一篇来源不足的文章，以及一个范围之外的请求。观察 Codex 是否会在适当的时候说“目前还不知道”。AI 智能体与聊天机器人有何不同一文解释了为什么能执行多个步骤的助手仍然需要边界。