Codex 使用指南：从写代码助手，到长期协作的开发工作流

很多人第一次用 Codex，通常只会让它做三件事：检查代码、生成 diff、跑测试。

这当然没问题，写代码依然是 Codex 最直接的使用场景。但如果只把它当成”帮我补代码”的工具，其实有点可惜。真正好用的方式，是把 Codex 当成一个可以长期跟进任务的开发协作入口。

它不只是写代码，还可以帮你跑命令、查资料、读文档、整理反馈、生成文件、审查页面，甚至在同一个工作流里持续推进一个任务。

这篇指南不讲概念堆叠，只讲一件事：怎样把 Codex 用得更顺手。

1. 不要每次都开新对话：给重要任务保留固定线程

如果一个任务不是一次性完成的，就不要每次重新开一个新对话。

比如这些场景，很适合保留固定线程：

这样做的好处是，Codex 不需要每次重新理解背景。它可以沿着之前的上下文继续工作，包括你的偏好、已经做过的决定、当前卡点和后续计划。

我的建议：只要一个任务会持续超过一天，就给它单独开一个固定线程。

2. 语音输入适合”还没想清楚”的需求

很多时候，我们不是不会描述需求，而是还没整理好。

这时不要急着写一段完美 Prompt，可以直接用语音把想法说出来。语音输入的价值，不是让表达更正式，而是先把脑子里的原始信息倒出来。

比如你可以这样说：

我现在想做一个机器人控制 skill 的优化，主要问题是用户连续控制体验不好。现在每次只是调用一次接口然后 stop，感觉很机械。你先帮我从产品体验角度拆一下，不要急着写代码。

这类输入看起来很散，但对 Codex 反而有用——因为它能从你的描述里提取目标、约束和上下文。

适合语音输入的场景：

不要把语音输入当成正式文档，它更像草稿入口。

3. 学会中途纠偏，而不是等它做完再骂

用 Codex 做长任务时，不要一直等到最后才看结果。更好的方式是：边看边纠偏。

这里有两个核心概念：

举个例子：你让 Codex 改一个页面，它做到一半时你发现方向不对，可以直接说：

先停一下，不要继续改样式。现在的问题不是颜色，而是信息层级太乱。你先把页面结构重新拆一下。

这就是 Steering。

如果它正在跑测试，你不想打断它，可以说：

测试跑完后，顺便把这次改动整理成一份 review 说明。

这就是 Queuing。

两者的区别很简单：Steering 是改当前方向，Queuing 是安排下一步。这也是 Codex 和普通代码补全工具最大的不同之一——它不是一次问答，而是一个可以被你持续调度的工作线程。

4. 工具连接决定了 Codex 能做多远

只让 Codex 看代码库，它就是代码助手。让它连接浏览器、MCP、外部系统、桌面环境，它才会变成工作流助手。

所以，使用 Codex 时要先问一个问题：

这个任务需要它看到什么、操作什么、调用什么？

如果只是改代码，给代码库就够了。如果是做完整任务，就要把相关工具也接上。

5. 把重复流程沉淀成 Skill

如果一个流程你已经让 Codex 做过三次，就应该考虑把它写成 Skill。

比如：

• 代码 Review Skill
• 接口文档生成 Skill
• 发布说明生成 Skill
• 数据库变更检查 Skill
• 机器人控制能力检查 Skill
• PR 风险扫描 Skill

Skill 的价值不是”让 Codex 更聪明”，而是让它少猜。

好的 Skill 应该明确告诉 Codex：

• 这个 Skill 解决什么问题
• 输入是什么
• 操作步骤是什么
• 输出格式是什么
• 哪些事情不能做
• 出错时怎么提示

例如代码 Review Skill 不应该只写”帮我 Review 代码”，而应该写成：

检查安全风险、并发问题、数据库事务、错误处理、日志、接口兼容性和测试覆盖。输出按 P0/P1/P2 分级，并给出修复建议。

6. 自动化适合”需要定期回来看看”的任务

有些任务不需要你一直盯着，但需要定期检查。

比如：

• 每天生成项目日报
• 每小时检查 PR 是否有新评论
• 定期查看 CI 是否失败
• 定期汇总 Slack / Gmail 里待处理事项
• 部署后每隔一段时间检查状态

这类任务适合用 Automation。

自动化分两种：

举个例子：

每 30 分钟检查一次这个 PR。如果有新评论，先分析评论内容，再基于当前代码给出修改建议，但不要直接提交。

这类任务就很适合 Thread Automation，因为它需要记住之前做了什么。

7. Goals 适合有明确终点的长任务

不要把 Goals 用成”大愿望”。

❌ 不好的目标：

帮我把这个项目优化一下。

✅ 好的目标：

直到 npm test 全部通过，并且首页 Lighthouse Performance 不低于 90，才算完成。

Goals 的关键不是任务大，而是终点清楚。

适合 Goals 的验证标准：

一句话：没有验证器的 Goal，本质上只是一个愿望。

8. 侧边栏适合做”边看边改”的工作

侧边栏的价值在于：你不用在聊天窗口、编辑器、浏览器、文件预览之间来回切。

它适合处理这些内容：Markdown 文档、表格、PDF、幻灯片、网页预览、代码 diff、生成的 artifacts。

比较推荐的侧边栏使用场景：

尤其是前端页面，侧边栏会让反馈效率高很多。你可以直接说：

这里信息密度太高，先别改颜色，把卡片层级重新拆一下。

这种反馈比”帮我优化页面”有效得多。

9. 共享记忆不要只依赖聊天记录

长期任务最怕的问题是：上下文丢了。

所以重要信息不要只留在对话里，最好沉淀到一个可读、可维护的地方。比如建一个简单的知识库：

vault/
├── TODO.md
├── people/
├── projects/
├── decisions/
├── notes/
└── drafts/

然后在项目或知识库根目录放一份 AGENTS.md，告诉 Codex 应该怎么维护这些信息。可以这样写：

# AGENTS.md

把 ~/vault 作为长期工作记忆区。

当你了解到新的项目进展、关键决策、负责人、待办事项或阻塞问题时，
请更新对应文件。

要求：
- 不要随意创建碎片化文件
- 重要决策写入 decisions/
- 项目进展写入 projects/
- 待办事项写入 TODO.md
- 没有实质性变化时，不要修改文件

这一步很关键——真正长期使用 Codex 时，你会发现最贵的不是”让它写代码”，而是**“让它重新理解背景”**。

10. 推荐的一套 Codex 日常工作流

可以按这个顺序用：

1. 开一个固定 thread
    ↓
2. 用语音或文字把需求先倒出来
    ↓
3. 让 Codex 先整理目标、约束、风险和执行计划
    ↓
4. 确认后再让它改代码 / 写文档 / 跑测试
    ↓
5. 执行中随时 Steering 纠偏
    ↓
6. 当前任务结束后 Queuing 安排下一步
    ↓
7. 重复流程沉淀成 Skill
    ↓
8. 长期跟进任务交给 Automation
    ↓
9. 有明确验收标准的任务使用 Goal
    ↓
10. 关键上下文写入 AGENTS.md / vault

这套流程的核心是：不要把 Codex 当成一次性问答工具，而是把它当成一个可以持续协作的开发线程。

11. 最容易踩的坑

坑 1：一上来就让它改代码

更好的方式是先让它理解：

• 当前目标是什么
• 哪些文件相关
• 不能改什么
• 成功标准是什么
• 怎么验证

坑 2：Prompt 太空

❌ “优化一下这个项目。”

这类指令很容易跑偏。改成：

✅ “先检查接口层错误处理、日志、事务和单元测试覆盖，不要改业务逻辑。输出问题清单和修复计划。”

坑 3：没有验证标准

Codex 做完后，如果没有测试、命令、指标或人工验收标准，就很难判断它是不是真的完成了。

坑 4：所有任务都开新对话

这会导致上下文反复丢失。长期项目应该固定 thread。

坑 5：重复流程不沉淀

同样的 Review、部署检查、文档生成，如果每次都重新描述，就是浪费。

总结

Codex 的重点已经不只是”帮我写一段代码”。

更好的用法是：让它围绕一个真实任务，持续读取上下文、调用工具、产出文件、接受反馈、完成验证。

对于开发者来说，真正值得沉淀的不是某一个 Prompt，而是一套工作方式：

• 固定 thread 保存上下文
• 用语音捕捉原始想法
• 用 Steering 及时纠偏
• 用 Queuing 安排下一步
• 用 Tools 扩展操作范围
• 用 Skills 固化重复流程
• 用 Automation 定期回来检查
• 用 Goals 处理有明确终点的长任务
• 用侧边栏边看边改
• 用共享记忆保存长期上下文

当这些能力组合起来，Codex 就不只是代码生成器，而是一个可以参与完整开发流程的协作工具。