夜雨聆风最近，OpenAI 在 Codex 文档里更新了一篇非常值得看的文章，主题是：Follow a goal。
如果翻译成更直白的话，就是：
给 Codex 一个长期目标，让它持续推进，直到完成一个可验证的结果。
这和我们平时使用 AI 写代码的方式完全不一样。
过去很多人用 Codex、Claude Code、Cursor，大概都是这样：
帮我改一下这个 Bug； 帮我写一个函数； 帮我解释一下这段代码； 帮我把这个页面样式调一下； 帮我补几个测试用例。
这种用法当然有价值，但它本质上还是“问一句，做一步”。
而 Goals这个功能想解决的是另一类问题：
当一个任务不是一两轮对话能完成，而是需要 Codex 持续阅读、修改、测试、复盘、再修改时，怎么办？
比如代码迁移、大型重构、原型开发、部署重试、Prompt 优化、游戏迭代、实验性功能开发……这些任务都有一个共同特点：
它们不是“写一段代码”就结束，而是需要不断循环：
改代码 → 跑测试 → 看结果 → 修问题 → 再验证。
这时候，如果还把 Codex 当成一个普通聊天助手，就会很累。
你要不停提醒它：下一步做什么、检查哪里、什么时候停、什么叫完成。
而 Goals 的意义，就是把这些要求提前写成一个“长期任务契约”。
让 Codex 不再只是接一句指令，而是围绕一个明确目标，自己持续推进。
一、Goals 到底是什么？
OpenAI 对 Goals 的定义很清楚：
当任务需要 Codex 跨多轮持续工作，并朝着一个可验证的停止条件推进时，就应该使用
/goal。
简单说，Goals 就是给 Codex 一个“耐久目标”。
普通提示词像是：
1 帮我修一下这个错误。
Goals 更像是：
1 /goal 完成这个项目的 React 18 迁移，确保所有页面视觉保持一致，所有测试通过，并保留回滚路径。
差别在哪里？
普通提示词强调“眼前这一步”。
Goals 强调“最终完成什么、如何验证、什么时候停止”。
这其实非常重要。
因为 AI 编程工具最容易出问题的地方，不是不会写代码，而是容易在长任务里迷路：
做着做着忘了最初目标； 改了很多文件但没有验证； 解决了局部问题却破坏了整体； 每轮都看似有进展，最后却不知道到底完成没有。
Goals 要解决的，就是这个问题。
二、为什么 Goals 很重要？
我觉得 Goals 最重要的价值，是把 Codex 从“代码助手”往“工程队友”推进了一步。
因为真实开发任务很少是一次性完成的。
大多数工程任务，都是长链路任务。
比如：
代码迁移
你要把一个旧项目从老框架迁移到新框架。
这不是改一个文件，而是要：
理解现有结构； 找到迁移边界； 分批替换旧逻辑； 保证行为一致； 跑测试； 做视觉回归； 保留回滚方案。
大型重构
你想把一个臃肿模块拆成多个小模块。
这也不是简单“帮我重构一下”。
你需要 Codex 知道：
哪些行为不能变； 哪些 API 不能破； 每个阶段如何验证； 如果测试失败，要退回哪一步。
Prompt 优化
你有一套 eval 测试集，希望 Codex 持续优化 prompt，直到分数达到目标。
这也非常适合 Goals。
Codex 可以：
查看失败样本； 修改 prompt； 重新跑 eval； 对比结果； 保留有效修改； 直到达到目标或判断需要人工决策。
这些任务都不是一次回答能解决的。
它们需要的是一个可以持续推进的工作循环。
而 /goal正是为这种任务设计的。
三、一个好 Goal，必须有“完成标准”
OpenAI 这篇文章里最关键的一句话是：
Codex 在开始之前，应该知道什么叫“完成”。
这句话非常重要。
很多人用 AI 失败，不是因为 AI 不强，而是因为目标写得太虚。
比如你说：
1 /goal 优化这个项目。
这就很差。
“优化”是什么意思？
提升性能？ 改善 UI？ 减少代码重复？ 修复 Bug？ 增加测试？ 降低打包体积？
Codex 不知道。
于是它只能猜。
更好的写法应该是：
1 2 3 4 /goal 将登录页首屏加载时间降低到 2 秒以内。
先阅读 performance.md 和当前 Lighthouse 报告。
每次修改后运行 npm run build 和 npm run lighthouse。
停止条件：Lighthouse performance 分数超过 90，且所有现有测试通过。
这就是一个清晰的 Goal。
它包含四个要素：
- 目标是什么： 降低登录页首屏加载时间；
- 先读什么： performance.md 和 Lighthouse 报告；
- 如何验证： 运行 build 和 lighthouse；
- 什么时候停： 分数超过 90 且测试通过。
Codex 最怕的是“你随便看着办”。
它最需要的是：
明确目标 + 明确边界 + 明确验证方式 + 明确停止条件。
四、Goals 最适合哪类任务？
不是所有任务都适合 /goal。
如果只是让 Codex 改一个函数、写一个小组件、解释一段代码，用普通对话就够了。
Goals 更适合下面几类任务。
1. 长周期代码迁移
比如：
1 2 3 4 /goal 将项目从 Vue 2 迁移到 Vue 3。
保持现有页面视觉和行为一致。
每完成一个模块后运行测试和构建。
停止条件：所有核心页面迁移完成，npm test 和 npm run build 均通过。
这种任务非常适合 Goals。
因为它有明确目标，也有验证方式。
Codex 可以自己拆成多个 checkpoint，一步步推进。
2. 大型代码重构
比如：
1 2 3 4 /goal 将 payment 模块拆分为 service、controller、validation 三层。
不要改变外部 API。
每次提交前运行相关单元测试。
停止条件：payment 相关测试全部通过，且公共接口保持兼容。
重构最怕“越改越乱”。
所以 Goal 里一定要写清楚：
哪些不能变； 哪些必须验证； 如何判断没有破坏旧逻辑。
3. 原型开发
比如你有一个 PLAN.md，里面写了想做的产品原型。
可以这样给 Codex：
1 2 3 /goal 根据 PLAN.md 完成一个可运行的 MVP。
每个里程碑都创建测试或可视化验证。
停止条件：应用可以本地启动，核心流程可点击，README 中写明运行方式。
这类任务特别适合 side project、小游戏、内部工具、前端 Demo。
你不用每一步都盯着 Codex，只需要让它按计划推进，并定期汇报 checkpoint。
4. Prompt 优化和评测循环
这是一个非常有意思的用法。
如果你有一套 eval，可以让 Codex 持续优化 prompt：
1 2 3 4 /goal 优化 prompts/customer-support.md，直到 eval 通过率达到 85%。
每次修改后运行 npm run eval。
只允许做最小必要修改。
如果进一步提升需要产品策略判断，请暂停并汇报。
这就不是“让 AI 写 prompt”，而是让 Codex 进入一个工程化优化循环。
它会不断查看失败案例、修改、评估、再修改。
这非常像一个初级工程师在跑实验。
五、如何写一个真正好用的 Goal？
可以直接套这个公式：
1 2 3 4 5 6 /goal 完成 [具体目标]，不要改变 [边界约束]。
开始前先阅读 [文件/文档/issue/log]。
每个阶段运行 [验证命令]。
按 checkpoint 推进，并记录简短进展。
停止条件：[可验证结果]。
如果遇到 [阻塞条件]，暂停并汇报。
比如：
1 2 3 4 5 6 /goal 修复移动端商品详情页布局问题，保持桌面端视觉不变。
开始前先阅读 issue #238、src/pages/ProductDetail.tsx 和现有 CSS。
每次修改后运行 npm run test 和 npm run build。
使用 Playwright 检查 375px、768px、1440px 三种宽度。
停止条件：移动端布局不再溢出，桌面端截图无明显变化，测试全部通过。
如果需要改动设计规范，请暂停并说明原因。
这个 Goal 就很强。
因为它没有让 Codex 自由发挥，而是给了它一个清晰工作边界。
好的 Goal，本质上就是一份“小型任务合同”。
六、使用 Goals 时，最容易踩的坑
1. 目标太大
比如：
1 /goal 重构整个项目。
这太大了。
Codex 不知道从哪里开始，也不知道什么时候结束。
更好的方式是拆小：
1 /goal 只重构 user-auth 模块，保持外部接口不变，相关测试全部通过后停止。
2. 没有验证命令
如果你不告诉 Codex 怎么验证，它很可能只会“看起来完成了”。
但工程任务不能只靠感觉。
要写清楚：
运行哪个测试； 构建命令是什么； 是否需要截图； 是否需要跑 eval； 是否需要检查日志。
3. 没有停止条件
很多人会说：
1 /goal 持续优化这个页面。
问题是，优化到什么程度算完？
更好的写法是：
1 停止条件：Lighthouse performance 超过 90，且无 layout shift 警告。
AI 需要明确的“终点线”。
4. 把无关任务塞进一个 Goal
比如同时让 Codex：
修 Bug； 改 UI； 写测试； 升级依赖； 优化文档； 重构架构。
这很容易跑偏。
一个 Goal 最好只围绕一个中心目标。
如果任务很多，就拆成多个 Goal。
七、Goals 背后的真正变化
我觉得 /goal最值得关注的地方，不只是一个命令，而是它代表了一种新的 AI 编程方式。
以前我们用 AI，是不断发指令：
你做这个。然后做那个。再检查一下。再改一下。
现在更像是：
我定义目标、边界和验收标准，你自己推进，中途只在需要时汇报。
这其实非常接近真实工程管理。
你不是把每一行代码都交代清楚，而是定义：
目标； 约束； 验收； 节奏； 停止条件。
Codex 则负责在这个框架内持续执行。
这也是为什么我觉得 Goals 的出现很关键。
它让 Codex 更像一个可以独立工作的工程队友，而不只是代码补全工具。
八、写在最后：真正会用 Codex 的人，已经开始管理目标了
很多人还停留在第一阶段：
让 Codex 写一段代码。
但更高阶的用法，是让 Codex 围绕一个长期目标持续推进。
这时候，你的核心能力也会变化。
你不再只是会写 prompt，而是要会写：
目标； 约束； 任务边界； 验证命令； 停止条件； checkpoint； 异常处理规则。
也就是说，未来真正厉害的开发者，不一定是每行代码都自己写的人，而是能把复杂工程任务定义清楚，并让 AI 稳定执行的人。
Codex Goals 给我们的启发是：
不要只把 AI 当成一次性助手，要学会把任务变成可验证、可持续、可交付的目标。
当你会写 Goal，Codex 才真的能从“帮你写代码”，变成“帮你推进工程”。
这可能就是 AI 编程工具下一阶段最重要的变化。
可直接复制的 Goal 模板
最后放一个通用模板，建议收藏：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 /goal 完成 [具体目标]。
范围：
- 只修改 [允许修改的文件/模块]
- 不要改动 [禁止改动的内容]
开始前先阅读：
- [文档/issue/log/PLAN.md]
验证方式：
- 每个 checkpoint 后运行 [测试命令]
- 如涉及 UI，使用 [截图/Playwright/Lighthouse] 验证
进展要求：
- 按 checkpoint 推进
- 每次汇报当前完成内容、验证结果、剩余问题
停止条件：
- [明确可验证的完成标准]
暂停条件：
- 如果遇到 [需要人工判断/权限/产品决策]，暂停并说明原因。
有了这个模板，你再用 Codex，体验会完全不一样。
不是“让它试试看”，而是“让它按目标推进”。