Codex Workflows：把常用开发流程拆成可复用步骤

适用场景

这篇手册适合想把 Codex 从“临时帮忙”变成“稳定协作流程”的团队。Workflow 的目标是让常见任务有固定阶段、固定边界和固定验证方式。

OpenAI 官方文档提供了 Codex Workflows 说明。不同团队可以根据项目类型设计自己的流程。

步骤 1：选择值得沉淀的流程

不是所有任务都需要 workflow。优先选择高频、重复、风险明确的任务。

适合沉淀：

• 写一篇新手册文章。
• 修复一个 bug。
• 做 PR review。
• 发布前检查。
• 安全扫描。
• 依赖升级。

不适合沉淀：

• 一次性探索。
• 模糊的产品讨论。
• 没有稳定验收标准的实验。

步骤 2：把流程拆成阶段

一个稳定 workflow 通常包含四段。

1. 只读分析
2. 制定计划
3. 实现修改
4. 验证和总结

对于内容站，可以这样设计：

1. 查官方来源。
2. 写 MDX 和 frontmatter。
3. 不使用非官方截图或概念图。
4. 运行 lint 和 build。

阶段越清楚，Codex 越不容易跳步。

步骤 3：给每个阶段写边界

边界要具体。

只读阶段：

只阅读文件和官方来源，不修改文件。

实现阶段：

只修改 content/manual 和 manual-sidebar.tsx。
不要修改已有文章 slug。

验证阶段：

运行 eslint 和 next build。
如果失败，先修复与本次改动相关的问题。

步骤 4：把长期流程写进 AGENTS.md 或文档

如果流程对团队长期有效，不要只留在某个聊天线程里。

可以写进：

• AGENTS.md
• docs/
• 团队开发手册
• PR 模板

例如：

## 手册发布流程

1. 只使用官方来源。
2. 没有官方截图时不配图。
3. 每篇文章必须有 source。
4. 发布前运行 lint 和 build。

步骤 5：用小任务测试 workflow

新 workflow 不要直接用于高风险任务。先用小任务验证。

示例：

请按手册发布流程新增一篇短文章。
完成后说明每一步是否执行。

如果流程跑通，再用于更复杂任务。

常见错误

不要把 workflow 写得太复杂。复杂流程会让执行者跳步骤。

不要缺少验证阶段。没有验证，流程就不闭环。

不要把一次性要求沉淀成长期流程。

不要让 workflow 和项目规则冲突。冲突时先更新规则。

小结

Codex Workflows 的价值是把常见任务变成可重复、可检查的流程。先选高频任务，再拆阶段、写边界、沉淀到项目文档，最后用小任务验证。