Codex 的 10 个工作流用法

许多人第一次用 Codex，都是这样开始的：

打开一个项目，丢一句话进去。

“帮我修这个 bug。”

“帮我写个页面。”

“帮我跑一下测试。”

这当然没错。Codex 本来就是从写代码、改代码、跑命令这条路长出来的。

但如果你只把它当成一个“会写代码的聊天框”，就有点可惜了。

目前真正拉开差距的，不是你会不会多写几个提示词，而是你会不会把一个模糊任务，交代成 Codex 能持续推进、能看现场、能跑工具、能被你中途纠偏、最后还能验收的工作流程。

大白话讲：

新手把 Codex 当码农。

老手把 Codex 当工作线程。

真正会用的人，是在训练自己当“任务设计师”和“验收人”。

这篇不讲玄乎的。我就按普通用户最容易用起来的顺序，讲 10 个 Codex 用法。你不用今天全部掌握，先挑其中 2 个用起来，就已经比只会“帮我写代码”的阶段往前走了一大步。

Codex 的 10 个工作流能力

一、先固定线程：别每次都重新开一个临时工位

许多人用 Agent 有个坏习惯：

每来一个任务，就新开一个对话。

短任务还好。列如让它解释一段代码，问完就走。可一旦你做的是长期项目，新开线程就像每天换一个新同事上班。

昨天刚交代过项目目标，今天又要重讲。

昨天刚说过哪些文件不能乱改，今天又要提醒。

昨天刚踩过的坑，今天又可能踩一遍。

固定线程的价值，不是“聊天记录更长”，而是给同一类任务一个长期工位。

你可以先建 3 个最简单的线程：

【项目维护线程】
专门处理这个项目的改代码、跑测试、看 diff。

【文档审查线程】
专门检查 README、教程、文章草稿、发布说明。

【每日整理线程】
专门整理收件箱、待办、网页资料、消息摘要。

就像厨房里切菜、炒菜、洗碗各有地方。你不要每次做饭都把锅碗瓢盆重新摆一遍。

Codex 也一样。固定线程跑顺后来，它更容易记住这个任务的上下文，你也更容易回头检查它之前做过什么。

固定线程就是长期工位

二、先让它看现场：别再靠嘴描述半天

以前用 AI 最累的一件事，是描述现场。

网页哪里挤？

按钮怎么错位？

报错弹窗长什么样？

后台表格哪一列不对？

你要么复制一堆文字，要么截图后来再补一句“你看右上角那个地方”。说的人累，听的 Agent 也容易猜错。

目前 Codex 已经越来越像一个能看现场的工作台。列如 Appshots 可以把当前应用窗口交给 Codex，让它看到截图和窗口里能读取的文字；浏览器工具可以看网页渲染效果；Computer Use 可以在 Mac 上点击、输入、滚动，处理一些必须在真实桌面里看的任务。

新手第一步不要急着让它操作。

先让它复述现场。

可以直接复制这段：

请先看当前窗口，不要点击、不要输入、不要修改任何内容。

请只做三件事：
1. 复述你看到了哪些主要区域；
2. 指出你认为最可能有问题的 3 个地方；
3. 告知我下一步如果要检查，应该点哪里，但先不要点。

这句话很重大。

你不是一上来就把鼠标交出去，而是先让它像新同事一样站在你旁边，把现场说清楚。

它说对了，再让它继续。

它说错了，你马上纠正。

这比你凭感觉甩一句“帮我优化这个页面”稳多了。

三、用 /goal：不要只说“帮我改好”，要说“怎样算做好”

许多人听到 /goal，会以为它就是“自动继续”。

这个理解太浅了。

/goal 真正改变的是：你不再只给 Codex 一个动作，而是给它一个完成标准。

普通提示词是：

帮我优化登录流程。

这句话听起来没问题，但 Codex 很难知道什么叫“优化完了”。

更好的写法是：

/goal 让登录流程对新用户稳定可用。

范围：
- 只检查登录、注册、找回密码这三个页面；
- 不重构用户系统；
- 不改数据库结构。

完成标准：
- 新增或修复必要测试；
- 本地登录主流程能通过；
- 失败状态有明确提示；
- 输出改动摘要和剩余风险。

暂停条件：
- 需要删除数据；
- 需要改生产配置；
- 需要输入密码、密钥或付款信息。

你看，差别出来了。

前一句像许愿。

后一句像交活。

Agent 最怕的不是任务大，而是任务没有终点。没有终点，它就像在雾里开车，看起来一直在努力，实际不知道什么时候该停。

后来你写 /goal，记住 4 个词：

目标 / 范围 / 验收 / 停止

这 4 个写清楚，Codex 才有机会真的替你跑长任务。

好目标要能验收

四、学会中途打方向：Steering 和 Queue 比多骂两句有用

Agent 跑偏的时候，许多人第一反应是等它做完，然后说：

“不是这个意思。”

这就像你坐出租车，司机已经开过三个路口了，你才说刚才应该左转。

中途看见方向不对，就要早点打方向。

Steering 适合改当前重点。

列如：

先停一下，当前重点不是重构组件。

请只检查首页按钮、间距、移动端换行。
不要继续改数据结构。

Queue 适合交代下一步。

列如：

当前这一步完成后，请不要直接继续。

请先输出：
1. 改了哪些文件；
2. 跑了哪些验证；
3. 哪些地方还需要人工确认。

一个管“目前别跑偏”。

一个管“下一步别忘”。

用好了后来，你会发现自己不用一直重新开骂，也不用等它跑完一大段再返工。

五、分清 Browser、Chrome、Computer Use：别把所有网页任务都塞给一个入口

这点许多新手最容易乱。

看到 Codex 能用浏览器，就觉得什么网页都让它打开。

看到能用 Chrome，就觉得所有网页都应该进自己的登录态。

看到 Computer Use，就想让它到处点。

先别急。

你可以用这张表判断：

场景	更适合的入口	新手提醒
公开网页资料	内置浏览器	适合读页面、截图、检查公开信息
本地网页预览	内置浏览器	适合看 UI、点按钮、做前端检查
已登录后台	Chrome	先限制范围，不要授权太多
Gmail、内部系统	Chrome	只读优先，不要自动发送
桌面软件、系统窗口	Computer Use	先让它复述现场，再批准点击
密码、付款、删除、生产环境	人工处理	不要交给 Agent 自动操作

大白话讲：

内置浏览器像公共阅览室。

Chrome 像你的私人办公室。

Computer Use 像你把同事请到电脑前。

三者能做的事不一样，风险也不一样。

Browser、Chrome、Computer Use 怎么选

新手最稳的原则是：

公开、低风险、可重复的任务，先给 Codex 做。
登录态、隐私、付款、删除、发送消息这类动作，必须先停下来问人。

这不是胆小。

这是长期使用 Agent 的基本安全感。

六、把重复流程做成 Skill：别再复制一大段祖传提示词

如果你有一段提示词，已经复制过 3 次，就该思考做成 Skill。

许多人以为 Skill 是插件。

实则更像一张“标准作业卡”。

列如你常常让 Codex 做文章审查，每次都要说：

请检查这篇文章是不是太空，标题有没有痛点，正文有没有可复制步骤，
不要只夸优点，要指出可改的地方，最后给我一个改稿清单。

这段每次复制，迟早会漏。

更好的办法是沉淀成一个 Skill。

你可以让 Codex 帮你写一个最小版：

请把我刚才这套文章审查流程整理成一个 Skill。

要求：
1. 触发场景写清楚；
2. 执行步骤写成编号；
3. 禁止事项写明；
4. 输出格式固定成：问题 / 缘由 / 修改提议 / 可复制示例。

Skill 的价值不是花哨。

它是让 Agent 每次按同一套流程干活，少一点随机发挥。

就像餐厅后厨的出餐单。你不可能每来一份菜，都重新教厨师盐放多少、先炒什么、什么时候出锅。

七、把规则写进 AGENTS.md：别让 Codex 每次都像第一天上班

许多项目最怕的不是 Agent 不机智。

而是它不知道规矩。

列如：

哪些文件不能随意动？

测试命令是什么？

提交前必须跑什么？

UI 风格有什么禁忌？

涉及外部消息、删除、上传时要不要停？

这些东西不要每次靠嘴说。

可以写进项目规则，列如 AGENTS.md。

一个最小模板长这样：

# 项目规则

## 常用命令
- 安装依赖：npm install
- 本地启动：npm run dev
- 最小测试：npm test -- --runInBand

## 修改边界
- 不要改数据库 schema；
- 不要删除用户数据；
- 不要修改 .env 和密钥文件；
- 大改动前先输出计划。

## 完成要求
- 每次改完先看 git diff；
- 能跑测试就跑最小相关测试；
- 输出改动摘要、验证结果、风险点。

## 必须暂停
- 需要付款；
- 需要登录新账号；
- 需要发送外部消息；
- 需要删除文件或数据。

这不是给 AI 写作文。

这是给它贴一张办公室规章制度。

有了这张纸，它下次进项目，至少知道哪些门不能乱开。

八、用 Automations：不是让 Codex 没事骚扰你，而是让它定时检查

自动化也很容易被误用。

许多人一听 Automations，就想：

那我让它每 10 分钟帮我干一堆事。

结果不是省事，是制造噪音。

真正适合自动化的任务，一般有三个特点：

固定时间出现；
输入来源稳定；
结果需要你审一眼。

列如：

每天早上整理昨天的 issue 和失败 CI。
每周五生成项目进展摘要。
每天下午检查一次收件箱里有没有需要处理的反馈。
每次发布后检查日志里有没有新增错误。

注意，不是让它直接替你拍板。

更稳的做法是让它整理成“待审结果”。

可以这样写：

每天上午 9 点检查项目 issue 和失败测试。

只做整理和归类，不要修改代码。
输出：
1. 最紧急的 3 件事；
2. 每件事的证据链接；
3. 提议下一步；
4. 需要我确认的地方。

自动化不是把方向盘拆掉。

它更像早上有人把报纸、待办和风险点放到你桌上，你喝口水就能开始判断。

自动化任务真实素材示例

九、质量门要前置：高级用法不是放手，而是会验收

用 Codex 最危险的阶段，不是它不会写。

恰恰是它写得太快。

它三分钟改完一堆文件，给你一段很顺的总结。你一看“测试通过”，心里就想：那应该没问题吧。

别急。

Agent 的总结不是证据。

真正的证据是 diff、测试、截图、日志和可重复步骤。

后来每次让 Codex 改东西，最后都可以加这一段：

完成后请先过 5 道质量门：

1. 列出 git diff 中真正改动的文件；
2. 说明每个改动为什么必要；
3. 跑最小相关测试，并贴出命令和结果；
4. 检查是否改了依赖、密钥、权限、删除逻辑；
5. 给出剩余风险和需要人工确认的地方。

不要只写“已完成”。

这段很朴素，但很管用。

它会把你从“听 Agent 自述”拉回“看真实证据”。

会用 Agent 的人，不是最敢放手的人，而是最会设置验收门的人。

完成后先过 5 道质量门

真实 diff 证据图示例

十、人的角色变了：你不是遥控器，你是验收人

最后说最重大的一点。

Codex 这些功能加起来，不是在告知你：

后来什么都不用管了。

正好相反。

它是在逼你换一种工作方式。

以前你像遥控器：

做这一步。
再做下一步。
这里错了。
继续。
再继续。

目前你更像一个小项目负责人：

目标是什么；
边界在哪里；
看到什么现场；
允许用哪些工具；
成功怎么验收；
什么时候必须停。

这才是 Codex 真正厉害的地方。

它不只是帮你写代码。

它把“如何把事情交代清楚”这件事，摆到了你面前。

你越会定义目标，它越能持续推进。

你越会提供现场，它越少猜。

你越会写边界，它越不容易乱动。

你越会验收，它交付的东西越可信。

给新手的一条最小上手路线

如果你目前只会让 Codex 改代码，不用焦虑。

今天先做这 4 步就够了：

第一步：固定一个项目维护线程。
第二步：每次开始前，让 Codex 先复述目标和限制。
第三步：涉及页面或桌面，先让它看现场但不要操作。
第四步：完成后必须过 5 道质量门。

等这 4 步顺了，再加 /goal、Skill、Automations。

不要一上来把所有高级功能全打开。

工具越强，越需要顺序。

就像刚拿到一把很锋利的菜刀，不是马上表演花活，而是先学会怎么拿、怎么切、怎么收刀。

Codex 当然会写代码。

但真正让人变强的，是它让你开始学会设计任务、控制风险、保留证据、复用流程。

这一步走过去，你用的就不只是一个代码助手了。

你是在给自己搭一个可以长期工作的 AI 工作台。

请你今天就试一个最小动作：

找一个正在做的项目，建一个固定线程，然后把这段发给 Codex：

这个线程作为【项目维护线程】长期使用。

每次开始任务前，请先复述：
1. 当前目标；
2. 你能改的范围；
3. 不能碰的文件或动作；
4. 你准备怎么验证。

每次完成任务后，请输出：
1. 改动摘要；
2. 验证命令和结果；
3. 风险点；
4. 需要我确认的下一步。

涉及密码、付款、删除、上传、外部消息发送、生产环境操作时，必须先停下来问我。

这段不复杂。

但用上后来，你会明显感觉到：Codex 不再只是“我说一句，它答一句”。

它开始像一个有工位、有规矩、有工具、有验收标准的长期工作伙伴。