Codex 写作工作流：从研究笔记到审稿、配图与发布

这是 Codex 系列的第 15 篇。

前一篇完成了一份可引用的 research note。资料已经按 Claim 和 Evidence 整理好以后，下一步看起来很自然：

让 Codex 根据这些资料写一篇文章。

这句话能得到草稿，却很难稳定得到一篇可以公开的技术教程。

原因并不神秘。调研、搭结构、解释技术、校验事实、保持作者语气、设计配图、检查页面和执行部署，本来就是不同性质的工作。把它们塞进一个 Prompt，Codex 往往会优先完成最显眼的目标，也就是“产出一篇读起来完整的文字”；证据范围、失败路径、移动端图片和线上资源是否真的可用，则容易被流畅感盖过去。

这一篇解决的问题更具体：

怎样把一份 research note 交给 Codex，经过可检查的起草、审稿、配图和发布门禁，最终得到一篇读者能跟做、作者敢署名、上线后可以验证的技术文章？

贯穿全文的案例，就是这个系列刚刚发布的第 14 篇《Codex 做资料调研》。我会把它从研究笔记到 Cloudflare 上线的过程拆开，并保留一次真实的 Windows 部署失败，而不是给一条从不出错的理想流程。

下载 codex-writing-pipeline-kit 示例包

示例包包含 Brief、语气、配图和发布模板，8 组可复制 Prompt，以及一份能检查 Markdown frontmatter、占位符、本地资源和长文结构的 Node.js 脚本。

版本说明

Codex 的入口、Skills、Slash Commands 和 Browser 能力仍在变化。本文涉及当前产品功能时，以 2026-07-22 的 OpenAI 官方文档为准；仓库命令和部署结果只代表这个博客项目。以后复用时，先重新读取项目 AGENTS.md、package.json 和托管配置，不要照抄部署命令。

一分钟概览

整条写作流水线可以压缩成八个有明确交付物的阶段：

Article Brief
    ↓  文章承诺、读者、边界
Research Handoff
    ↓  Claim、Evidence、未验证项
Executable Outline
    ↓  每节问题、动作、输出
Section Drafts
    ↓  分段正文与真实案例
Three-pass Review
    ↓  事实 / 读者 / 作者声音
Visual Plan
    ↓  截图、结构图、信息图或生成图
Preview & Gates
    ↓  内容检查、Lint、Build、桌面/手机
Publish & Smoke Test
       正文、资源、RSS、Sitemap、版本

图 1：Codex 技术文章从 Brief 到生产环境的交付流水线

移动端可打开图 1 原始 SVG放大查看。

图 1 最重要的不是阶段数量，而是每个阶段都落盘一个产物。这样可以判断问题出在研究、结构、表达、视觉还是部署，不必在一篇不断被覆盖的“大草稿”里猜。

第一次阅读可以这样选：

• 只想把 AI 草稿变得更可靠：重点看第 2、5、6 节。
• 已经在代码仓库里写博客：重点看第 3、7、8 节。
• 配图经常和内容脱节：重点看第 7 节。
• 想直接复制工作流：下载示例包，再看第 9、11、13 节。

1. 先改变完成定义：不是“写完”，而是“发布后可验证”

如果任务目标只是“生成一篇 Markdown”，Codex 写到最后一个段落就完成了。博客作者真正需要的完成定义至少还包括：

文章承诺与正文一致；
时效性事实有日期和直接来源；
命令包含起点、预期输出和失败信号；
下载包与图片真的存在；
桌面和手机都能读；
构建没有把草稿意外放进公开路由；
部署完成后，正文、资源、RSS 和 Sitemap 都能访问；
作者本人确认观点、语气和公开边界。

所以我给 Codex 的目标不会是“写一篇高质量长文”，而会更像：

把 research note 整理成一篇面向已经会使用 Codex 的读者的实用教程。

读者在 45-60 分钟内应能完成一份最小可审稿的 Markdown 样稿：
它有完整骨架，并写完最关键、最容易失败的两个章节，
并使用模板跑通事实审查、配图规划、本地构建和部署前门禁。

最终交付：
1. draft: true 的文章；
2. 可下载的模板和检查脚本；
3. 内容专属白底配图；
4. 预检、Lint、Build 和读者审稿记录；
5. 未经作者确认，不执行部署。

这段话把“文字”降回了交付物的一部分。Codex 才会为下载包、测试和发布边界留出注意力。

2. 一次性 Prompt 为什么容易得到“完整但不可靠”的文章

常见的一次性 Prompt 是：

参考这些链接写一篇 5000 字 Codex 教程，技术笔记风，
加入例子、图片、总结和参考资料，不要像 AI。

它同时要求了资料选择、事实判断、结构设计、长文起草、风格模仿、配图和引用，却没有为任何一项定义验收标准。最后经常出现五类问题：

“不要像 AI”也不是可执行的写作规范。它没有说明哪些句式、段落和判断不属于作者，只会让模型随机降低某些高频表达。

更稳妥的做法是把任务拆成多个上下文角色，并让每个角色只回答一个问题：

作者上下文：我想说什么，我愿意承担什么判断？
研究上下文：哪些主张有证据，适用范围是什么？
编辑上下文：读者能否看懂、跟做和验收？
视觉上下文：哪种图能减少当前认知负担？
工程上下文：文件、构建、页面和部署是否真的工作？

这里不一定需要五个模型或五个 Agent。关键是不同阶段使用不同输入、输出和验收，不让“继续润色”成为万能指令。

3. 把规则放在正确的位置

写作工作流会同时用到 AGENTS.md、Article Brief、Voice Guide、Skill 和脚本。它们不是同一种文件的不同写法。

图 2：项目规则、文章合同、审稿 Skill 与确定性脚本的职责分层

移动端可打开图 2 原始 SVG放大查看。

OpenAI 当前文档说明，Codex 会按全局、项目根目录到当前工作目录的顺序读取 AGENTS.md，越靠近当前目录的指导越晚加入，也就能覆盖较早的规则。OpenAI：Custom instructions with AGENTS.md

Skills 则适合可重复调用的工作流。一个 Skill 可以包含 SKILL.md 以及可选的 scripts/、references/ 和 assets/；Codex 先看到名称、描述和路径，匹配到任务后再加载完整内容。OpenAI：Build skills

这也是为什么我把“技术文章审稿”做成仓库级 review-technical-article Skill，却没有把整篇文章的资料全部塞进 Skill：

审稿步骤会重复，所以做成 Skill；
文章事实会变化，所以留在 research note；
博客规则长期有效，所以放进 AGENTS.md；
是否发布影响外部状态，所以保留人工门禁。

容易混淆的一点

Codex CLI 当前内置的 /review 主要用于审查工作树改动；本文的“文章审稿”使用的是项目自定义 Skill，不要把两者当成同一个功能。OpenAI：Developer commands

4. Article Brief：动笔前先写一页文章合同

Brief 不需要漂亮，但必须能回答六个问题：

1. 这篇只解决什么问题？
2. 谁能在没有隐藏前提的情况下跟做？
3. 读者最终得到什么文件、配置或结果？
4. 哪些事实需要证据和日期？
5. 哪些内容明确不讨论？
6. 发布后怎样确认结果正确？

第 14 篇的 Brief 核心可以压缩成：

这里的“非目标”非常重要。没有它，后面的写作阶段很容易为了完整感，擅自补上并未验证的 MCP 或 provider 结论。

示例包里的 article-brief-template.md 还包含一个 Claim Register：

| ID | 准备写进正文的主张 | 需要什么证据 | 当前状态 | 范围 / 日期 |
| --- | --- | --- | --- | --- |
| C01 | 常规本地会话的 Web Search 默认使用 cached | 当前官方配置文档 | supported | 2026-07-22 |
| C02 | 所有 provider 下 `--search` 表现一致 | 跨 provider 官方承诺或测试 | unverified | 不进入结论 |

这张表让“写不写”在起草前就有答案。Codex 不必到了正文里才临时决定一句话应该有多确定。

4.1 先让 Codex 填 Brief，不要直接写长文

根据现有 research note 填写 article-brief-template.md。

要求：
- 用一句话说明读者在 45-60 分钟内能完成什么；
- 把时效性主张列成 Claim Register；
- 区分官方事实、社区观察、作者判断；
- 明确不讨论的范围；
- 证据不足时标记 unverified，不补写结论。

先提交 Brief 给我检查，不要直接起草文章。

作者在这里需要做第一次人工判断：主题是否值得写，承诺是否过大，案例是否真的能公开。这个判断没有必要自动化。

5. Research Handoff：不要让草稿重新发明一次调研

上一阶段已经有 research note，起草时就不应该再次从搜索结果开始。交接包至少包含：

Article Brief
Claim Register
Evidence Ledger
可引用表述
未验证项
真实实验记录
需要脱敏的原始材料

我会给起草阶段这样的约束：

只使用 research note 中 supported 或 partially_supported 的 Claim。

partially_supported 必须保留范围词；
unverified 只能进入“尚未确认 / 限制”部分；
不得只根据搜索摘要补充新事实；
如果正文需要 note 中没有的事实，先回到研究阶段追加证据，
不要在草稿里留下一句看起来合理的答案。

这样做还有一个容易忽略的好处：可以判断哪一次修改改变了事实。

如果编辑阶段只是把一句话写得更顺，就不应改变 Claim 状态；如果它删掉了“在本文环境中”“截至 2026-07-22”这类范围词，就已经不是语言修改，而是事实范围扩大，必须退回事实审查。

6. 大纲不是目录，而是文章的测试计划

我以前也会让 Codex 先给“详细大纲”，结果经常得到：

1. 背景介绍
2. 核心概念
3. 实践方法
4. 最佳实践
5. 总结与展望

这只说明文章有五个容器，没有说明读者怎样前进。

可执行大纲要求每一节补齐五个字段：

例如本文的“发布与线上验证”不是一个抽象章节，而是：

Reader Question：Build 通过是否等于发布成功？
Evidence：Cloudflare 部署输出、生产 URL、资源响应、RSS、Sitemap。
Action：部署后分别请求五类资源。
Expected Output：全部 200，正文包含标题，RSS/Sitemap 包含 slug。
Failure Signal：Worker 成功但资源 404，或 RSS 仍没有文章。

这时大纲已经像测试计划。正文只是在解释为什么做、怎样做和遇到失败怎么办。

7. 分段起草：让事实、例子和语气都能追踪

长文不适合一次生成后不断“整体润色”。更可控的方式是按大纲逐节起草，每一节只带必要上下文：

本文 Brief
本节对应的 Claim 与 Evidence
上一节结尾
Voice Guide 中与本节有关的规则
本节需要展示的真实文件或命令

Prompt 可以写成：

只起草第 6 节“发布门禁”。

先解释 Build、Deploy 和 Production Smoke Test 的区别，
再使用本博客的 npm scripts 给出命令、预期输出和停止条件。

不要虚构成功输出。只能使用我提供的运行记录；
如果记录不足，保留“尚未运行”状态。
延续现有技术笔记语气，不写营销式结尾。

7.1 第一人称只能来自真实记录

下面两句看起来都自然，但证据地位完全不同：

我部署时遇到了 `.open-next` 被占用的 EPERM。
你在 Windows 上部署时一定会遇到 `.open-next` 被占用。

第一句是一次可展示的本地经历；第二句把局部观察扩大成普遍规律。

第 14 篇真实发布时，OpenNext 在清理旧 .open-next 目录时收到 Windows EPERM。检查后发现本地预览留下的项目 Node / Workerd 进程仍占用目录；停止这些项目进程后重试，构建和上传成功。这个案例能支持的结论是：

Windows 上若 OpenNext 在初始化输出目录时出现 EPERM，先检查同一项目的预览进程和文件占用；它不是 Cloudflare 已经上传一半的证据。

它不能支持“OpenNext 在 Windows 上无法部署”或“所有 EPERM 都来自预览进程”。把边界写清，真实经历才有教程价值。

7.2 为命令同时写成功和停止条件

只给命令：

npm run build

读者不知道怎样判断完成。更完整的写法是：

工作目录：博客仓库根目录
命令：npm run build
成功信号：退出码 0，新文章 slug 出现在生成路由中
停止条件：TypeScript、内容检查或静态页面生成报错
下一步：成功后进入浏览器预览；失败时不执行 deploy

这四行比再增加三个“提升写作效率”的段落更值得收藏。

8. 三遍审稿：不要让同一遍同时修事实、读者和语气

图 3：事实、读者与作者声音三遍审稿及其发布门禁

移动端可打开图 3 原始 SVG放大查看。

一篇技术文章至少需要三种镜头。顺序也有意义：先确保没有把错误写得更漂亮，再处理阅读体验，最后校准作者声音。

8.1 第一遍：事实与复现审稿

这一遍只提取可验证主张：

• 产品名称、入口和可用范围；
• 版本、日期、命令和配置字段；
• 权限、网络、部署和删除行为；
• “已经测试”“可以复现”“所有用户”一类强表述；
• 引用是否直接支持旁边的句子。

输出不是一版润色稿，而是按严重程度排列的发现：

[P1] C02 仍为 unverified，但正文写成了全局结论。
[P2] npm run build 缺少工作目录与成功信号。
[P2] GitHub issue 只证明有人报告，不能单独证明官方缺陷。
[P3] 同一条官方链接在相邻两段重复。

本博客的 review-technical-article Skill 还会先运行结构预检，再检查文章合同、事实、复现、实用价值和阅读结构。Skill 能让审稿步骤稳定，但不能自己证明外部事实；时效性结论仍要回到官方来源。

8.2 第二遍：无上下文读者测试

作者和起草 Agent 都知道太多背景，容易自动补全文章没写的步骤。读者测试应尽量使用新任务或干净上下文，只提供：

文章正文
下载包
目标读者定义

然后让它回答：

1. 开始前要准备什么？
2. 45-60 分钟后应该得到什么？
3. 最可能卡在哪一步？
4. 哪些命令缺少输入、输出或失败信号？
5. 哪些段落读完不会改变行动或判断？
6. 收藏后，实际会回来复用哪一项？

Anthropic 开源的 doc-coauthoring Skill 也把 Reader Testing 单独作为一个阶段，强调让没有前文上下文的读者检查盲点。Anthropic：doc-coauthoring Skill

这里真正可迁移的不是某个 Claude 命令，而是用新上下文暴露作者脑内补全。Codex 完全可以采用同样的方法。

8.3 第三遍：Voice Audit

Voice Audit 不负责“把所有句子改得像某位作者”，而是检查：

• 套路化开头和总结；
• 连续使用同一种对仗句式；
• 没有证据的强确定语气；
• 为了显得个人化而虚构经历；
• 模仿参考文章，却不属于当前作者的口头禅；
• 本来有具体选择，却被改成了抽象方法论。

Ruben 的两篇写作指南提供了一个有用启发：把语气偏好、厌恶表达、Good / Bad 示例和判断规则整理成可复用文本。Anthropic 的开源 Skills 仓库则展示了另一层做法：把会重复执行的流程组织成包含 SKILL.md、references 和脚本的目录。Ruben：I can be you、Ruben：It's not [X], it's [Y]、anthropics/skills

这两者不应混成一个巨大的“作者人格文件”。表达偏好可以先做成仓库中的最小 Voice Guide；只有当审稿步骤稳定、会在多篇文章里重复时，再把流程封装成聚焦的 writing / review Skill。

我不会直接复制这个做法的全部强度。一个包含完整身份、联系人、私人经历和表达特征的文件，也会提高泄露和冒充风险。博客仓库里更适合保存的是最小 Voice Guide：

文章如何开头；
哪些句式经常被我删掉；
怎样表达不确定性；
什么样的例子算具体；
3-6 组来自自己旧文的 Good / Bad 对照；
哪些私人材料绝不进入仓库。

语气文件应帮助作者少做重复纠正，而不是把作者变成一套永远不变的句式。

8.4 修改顺序

三遍审稿发现不要混在一起修改：

P0 / P1 事实与安全
    ↓
影响复现和读者行动的 P2
    ↓
结构与删减
    ↓
语气和局部表达
    ↓
重新跑事实与结构检查

如果 Voice Audit 改变了范围词、命令或结论，就必须回到第一遍，不应把它当作纯语言修改。

9. 配图：先写 Visual Plan，再调用作图 Skill

“文章都是文字，加几张图”会得到装饰图；“把文章内容画成一张流程图”会得到拥挤框图。更有效的问题是：

读者在这一段为什么需要图？

示例包的 visual-plan-template.md 要求每张候选图先填写：

9.1 先选媒介，不要默认生成图

OpenAI 当前的 Codex 用例建议先用 ImageGen 探索视觉方向，再把最终图片作为附件交给 Codex；实现页面后，再用 Playwright 在真实浏览器中验证。OpenAI：Get from idea to proof of concept

这套顺序同样适合文章配图：

Visual Plan → 生成 / 绘制 → 插入正文 → 浏览器查看 → 针对问题迭代

不要在图片生成后才临时寻找一个可以塞进去的段落。

9.2 给作图 Skill 的输入应该包含什么

无论使用 baoyu infographic、ImageGen、tldraw 还是手写 SVG，Prompt 至少包含：

用途：技术文章正文图 2，不是封面。
读者问题：AGENTS.md、Brief、Skill、Research Note 和脚本怎样分工？
核心信息：长期规则、单篇合同、可重复流程、证据和确定性检查属于不同层。
画布：16:9，白色背景，桌面和手机都要可读。
风格：技术笔记信息图，深色正文，蓝 / 绿 / 橙只表示职责层。
必须出现：五种载体、输入输出关系、人工发布门禁。
避免：深色底、渐变光效、同构卡片、装饰机器人、无法校验的小字。
输出：SVG 或高分辨率 PNG；同时给 Alt 和图注草稿。

9.3 图片也要验收

图片进入文章前至少检查：

• 技术文字、版本和箭头是否正确；
• 是否真的与邻近段落互相引用；
• 手机宽度下还能看出核心结构；
• Alt 描述信息，而不是写“配图如下”；
• 图注解释这张图为什么值得看；
• 截图是否泄露账号、Token、路径或未公开内容；
• 如果是生成图，是否出现错误文字、重复图标或不可能的连接。

正文里的结构图还提供原始 SVG 链接，是因为文章列宽中的缩略图不一定适合阅读全部小字。这个小动作比继续增加分辨率更直接。

10. 发布门禁：把主观确认和确定性检查分开

图 4：从草稿到线上文章的四层发布门禁

移动端可打开图 4 原始 SVG放大查看。

发布不是最后一个按钮，而是四层不同性质的门禁。

10.1 第一层：作者确认

这几项必须由作者本人确认：

我是否同意文章的核心判断？
第一人称经历是否真实？
是否公开了不该公开的个人或项目信息？
引用和图片来源是否可接受？
标题、摘要和封面是否准确代表正文？

在作者确认前，文章保持：

draft: true

10.2 第二层：仓库检查

这个博客的命令来自 package.json，不是通用 Codex 命令：

# 博客仓库根目录
npm run content:check
npm run lint
npm run build

三者检查的对象不同：

示例包的脚本还可以单独运行：

node examples/codex-writing-pipeline-kit/scripts/check-article.mjs `
  content/blog/your-post.md `
  --json

准备公开时增加 --publish。它会要求 draft: false，并把未清理占位符作为错误：

node examples/codex-writing-pipeline-kit/scripts/check-article.mjs `
  content/blog/your-post.md `
  --publish `
  --json

脚本不会判断引用是否真实，也不会给“文章质量 92 分”。确定性检查通过，只说明文件结构一致。

10.3 第三层：浏览器预览

Build 通过仍不能发现所有阅读问题。启动项目预览后，至少检查两个视口：

桌面：1440 × 900
手机：390 × 844

需要看：

• 标题、摘要和元数据是否拥挤；
• 表格和代码块是否横向截断；
• SVG、PNG、GIF 是否空白或被裁切；
• 图片小字是否在正文列宽中仍可辨认；
• 目录锚点、内部链接和下载按钮是否可点击；
• 控制台是否出现与当前文章相关的错误。

这里适合使用 Playwright，因为它能在真实浏览器中固定视口、截图和检查链接。视觉“舒服不舒服”仍要人看，但页面是否溢出、资源是否 404 可以重复验证。

10.4 第四层：部署与生产冒烟

部署会改变外部状态。即使 Codex 已经有执行权限，也应该先汇总：

本次公开哪些文章；
哪些文件会被上传；
预检、Lint、Build 是否通过；
还有哪些 warning；
目标域名和回滚入口；

作者明确确认后，再执行项目真实部署命令。OpenAI 的安全文档把 Sandbox 与 Approval 分开处理：本地可写范围和高影响动作是否需要确认，是两个控制面。OpenAI：Agent approvals & security

第 14 篇部署成功后，我没有停在 Wrangler 的 Current Version ID，而是继续检查：

$article = Invoke-WebRequest 'https://example.com/article/your-slug' -UseBasicParsing
$asset = Invoke-WebRequest 'https://example.com/media/your-kit.zip' -UseBasicParsing
$rss = Invoke-WebRequest 'https://example.com/rss.xml' -UseBasicParsing
$sitemap = Invoke-WebRequest 'https://example.com/sitemap.xml' -UseBasicParsing

[pscustomobject]@{
  ArticleStatus = $article.StatusCode
  TitlePresent = $article.Content.Contains('你的文章标题')
  AssetStatus = $asset.StatusCode
  AssetBytes = $asset.RawContentLength
  RssHasSlug = $rss.Content.Contains('your-slug')
  SitemapHasSlug = $sitemap.Content.Contains('your-slug')
}

这里故意同时检查状态码和内容。一个返回 200 的错误页，仍然不是文章上线成功。

11. 八组阶段 Prompt 怎样使用

示例包的 prompts.md 已经给出完整版本。这里保留使用顺序和每组 Prompt 的停止条件：

这套 Prompt 不追求“万能”。它的价值是让每个阶段都有可观察的退出条件，不会因为 Codex 还能继续写，就一直在同一任务里滚动修改。

12. 哪些步骤适合沉淀成 Skill，哪些不要

OpenAI 当前 Best Practices 建议：当同一个 Prompt 或同一种纠正不断重复时，可以把它整理成 Skill；每个 Skill 聚焦一个工作，先从少数真实用例开始，再逐步增加脚本和资源。OpenAI：Best practices - Turn repeatable work into skills

在这条写作流水线中，我会这样划分：

我不会急着做一个“自动写完并发布博客”的巨型 Skill。它把研究、创作、审稿、视觉和部署耦合在一起，一旦失败，很难知道是 Skill 触发、事实证据、文章判断还是发布权限出了问题。

更好的演进路线是：

先手动跑通一篇真实文章
    ↓
记录反复出现的纠正
    ↓
把一个稳定环节做成 Skill 或脚本
    ↓
用下一篇文章验证
    ↓
再决定是否需要更上层的编排

13. 常见失败，以及应该退回哪一层

13.1 “同一个对话审自己”为什么不够

同一任务中的 Codex 已经知道作者意图、资料来源和曾经删掉的内容。它可能像作者一样自动补全缺失步骤。至少在读者测试阶段，使用新任务或明确的无上下文输入更有效。

13.2 “所有 warning 都清零”也不是目标

外部站点可能因登录、403、限流或反爬无法自动检查。合理做法是记录 warning、判断它是否影响核心主张，并在必要时手动打开。为了让 CI 变绿而删除重要引用，反而损害文章。

13.3 “自动部署”应该最后考虑

当文章仍在频繁修改，自动部署只会放大错误。先稳定内容合同、检查脚本和回滚路径，再讨论定时发布或无人值守流程。下一篇团队化教程会继续讨论共享规则和权限，而不是在这里提前把全部外部动作自动化。

14. Claude 与 Codex：相通的是工作流，不是文件名

Claude 的项目指令和 doc-coauthoring Skill，与 Codex 的 AGENTS.md、Skills 和项目任务不是逐项同名映射，但底层问题相通：

真正可迁移的是四个原则：

1. 长期规则与单篇上下文分开；
2. 主观写作与确定性检查分开；
3. 起草者与无上下文读者分开；
4. 生成内容与公开发布权限分开。

因此不需要先决定“Claude 更会写”还是“Codex 更会写”。如果文章本身就存放在代码仓库、需要生成资源、运行脚本、检查页面并部署，Codex 的工程上下文会很自然；如果团队已经在 Claude Projects 中积累了风格和资料，也可以继续使用，然后把结构化产物交回仓库。接口可以变化，交付物不要只存在聊天记录里。

15. 45-60 分钟跟做练习

目标：把一份已有资料或一次真实踩坑，整理成一篇 draft: true 的最小可审稿样稿，并停在部署前。这里的“最小”指完整大纲已经建立，但正文只要求写完最关键、最容易失败的两个章节；其余章节保留 Reader Question、Action、Expected Output 和 Failure Signal，便于下一轮继续扩写。

0-10 分钟：填写 Brief

复制 article-brief-template.md，只填写：

• 问题；
• 读者；
• 一句话承诺；
• 真实案例；
• 3 个 Claim；
• 一个明确非目标。

验收：一句话承诺必须包含时间、产物和确认方式。

10-20 分钟：做可执行大纲

规划 4-6 节。每节写 Reader Question、Action、Expected Output 和 Failure Signal。

验收：删除章节标题后，仅看这四个字段也能理解操作顺序。

20-35 分钟：起草最关键的两节

不要从背景开始。优先写：

1. 读者真正要执行的一节；
2. 最常失败的一节。

验收：命令或操作包含起点、预期结果和停止条件。

35-45 分钟：做两遍审稿

先做事实与复现审稿，再开一个新任务做无上下文读者测试。

验收：至少修复一个证据范围问题和一个隐藏前提。

45-52 分钟：填写 Visual Plan

只规划 1-2 张必要图片。允许结论是“这篇不需要生成图”。

验收：每张图有一个 Reader Question、Alt 和移动端检查方式。

52-60 分钟：运行发布前检查

node examples/codex-writing-pipeline-kit/scripts/check-article.mjs `
  path/to/your-post.md `
  --json

再运行项目自己的内容检查和 Build。此练习保持 draft: true，不执行部署。

最终应留下：

1 份 Article Brief
1 篇最小 draft（完整骨架 + 两个关键章节）
1 份审稿 findings
1 份 Visual Plan
1 次结构 / 构建检查记录

16. 收藏清单

写之前

• 问题、目标读者、时间成本和可带走产物明确。
• Article Brief 写清非目标和发布验收。
• Claim Register 区分 supported 与 unverified。
• 项目规则来自当前 AGENTS.md，命令来自当前仓库。

写的时候

• 大纲按读者动作排列，不使用空泛容器标题。
• 分段起草，只携带本节需要的证据和语气规则。
• 第一人称经历来自真实记录。
• 命令包含工作目录、预期输出和停止条件。

审稿

• 事实与复现审稿先于语言润色。
• 用无上下文任务测试隐藏前提。
• Voice Audit 不改变事实范围。
• P0 / P1 清零，重要 P2 已处理。

配图

• 每张图先填写 Reader Question 和 One Message。
• 真实界面用截图，精确流程用结构图，生成图不承担复杂小字。
• Alt、图注、来源、脱敏和移动端检查完整。

发布

• 作者确认后才把 draft 改为 false。
• 内容检查、Lint、Build 和浏览器预览通过。
• 部署前明确目标、影响和回滚入口。
• 线上检查正文、资源、RSS、Sitemap，并记录部署版本。

写在最后

Codex 最有价值的地方，不是替我跳过写作，而是把原本散落在脑子里的工作变成可以检查的文件：Brief 说明承诺，research note 约束事实，大纲定义读者路径，review findings 暴露盲点，Visual Plan 解释为什么需要图，脚本和浏览器证明页面能够工作。

这条流程确实比一句“帮我写一篇长文”慢。但它把时间花在了以后最难补救的地方：错误事实、隐藏前提、虚构经验、无效配图和发布事故。

一篇值得收藏的教程不只是信息多。它应该让读者下次遇到同类问题时，能拿出一个模板、一条命令或一个判断标准，少重新摸索一次。

下一篇会进入系列第 16 篇：Codex 团队化：怎样共享 AGENTS.md、Skills、项目规则与发布边界。重点不再是个人怎样跑通流程，而是多人怎样避免规则漂移、Skill 失控和“每个人都有一套 Prompt”。

参考资料

OpenAI 官方

• Build skills
• Custom instructions with AGENTS.md
• Best practices：Turn repeatable work into skills
• Developer commands
• Agent approvals & security
• Get from idea to proof of concept
• openai/skills

Claude / Anthropic 对照

• Anthropic：doc-coauthoring Skill
• anthropics/skills

写作方法参考

• Ruben Hassid：I can be you
• Ruben Hassid：It's not [X], it's [Y]

Ruben 的文章用于参考“把风格偏好写成可复用文本”和“识别 AI 高频句式”这两个选题，不作为 Codex 产品行为的证据；本文的工作流、案例、发布记录和模板均按当前博客实践重新组织。