Codex 新增 /goal 后，AI 编程更像带人干活了

Codex 新增 /goal，表面上只是多了一个斜杠命令。 但它真正代表的是：AI 编程助手正在从“回答你这一轮问题”，变成“围绕一个目标持续推进”。 以后开发者的核心能力不只是会写代码，而是能不能把任务定义成 AI 可以执行、验证、收敛的目标。

如果你现在用 AI 写代码，经常有一种很矛盾的感觉：它明明很强，却还是需要你一直盯着。

你让它修 bug，它修一版。测试失败了，你提醒它看日志。改动变大了，你提醒它保持最小修改。接口被影响了，你提醒它不要破坏兼容。上下文变长了，你还得提醒它别忘了最初目标。

最后看起来是 AI 写了不少代码，但任务推进的主线，还是你在维护。

这篇文章想解决的，就是这个问题。

读完之后，你可以直接拿走三件东西：

1. 你会知道 Codex 新增的 /goal 到底解决了什么痛点。它的重点不是“自动继续”，而是把一个临时指令，变成可以持续推进的任务目标。
2. 你会拿到一套写 /goal 的基本结构。以后不要只写“帮我优化一下”，而是能写清楚目标、范围、约束、验证和输出。
3. 你也会知道哪些任务适合交给 /goal，哪些任务必须先让人判断。AI 可以持续执行，但方向、边界、风险和验收，仍然要由人负责。

这篇讲的不是一个新命令本身。我更想借 /goal 讲清楚一件事：AI 编程正在从“会不会写 prompt”，进入“会不会定义目标”。

/goal 解决的，是长任务主线问题

根据 OpenAI Codex CLI 0.128.0 的 release 说明，/goal 对应的是 persisted workflows：它让目标可以在当前工作流里被创建、暂停、恢复、清除，并配合 runtime continuation、model tools 等能力持续推进。

这句话有点技术。换成更直白的话，就是：

过去目标只是你在聊天里说过的一句话。

现在目标开始变成当前线程里更明确的任务状态。

过去你说：

帮我修这个 bug。

AI 会修一轮。但后面要不要继续看日志、要不要跑测试、要不要控制改动范围、要不要总结风险，很多时候还要靠你一轮一轮提醒。

而 /goal 更像是你正式给它挂了一条任务主线：

/goal 修复登录模块里导致 auth 测试失败的问题。保持现有 API 兼容，不引入新依赖。每次只做一个最小修改，修改后运行相关测试。最后输出修改文件、验证结果和剩余风险。

这就不只是“修一下”。

它有目标，有范围，有约束，有验证，也有交付结果。

这也是 /goal 值得关注的地方。它的价值不只是少问几次“是否继续”，更在于把 AI 编程从一轮一轮的聊天，推向更明确的目标式执行。

好的 /goal，要像一份小任务说明书

很多人写 prompt 的习惯是：

帮我优化一下这个模块。

这句话对人都不够清楚，对 AI 更容易跑偏。

优化什么？性能、可读性、结构、测试覆盖，还是依赖关系？

什么叫优化完成？跑哪些测试？哪些文件不能动？能不能引入新依赖？是否要保持旧 API 兼容？

这些不说清楚，AI 只能自己猜。

AI 一旦开始猜，就很容易出现一种熟悉的结果：看起来做了很多，方向却不对。

所以，一个好用的 /goal，至少要写清楚五件事。

目标：到底要完成什么。

不要写“优化登录模块”。可以写成：

把 src/auth 目录下重复的参数校验逻辑抽成公共函数。

范围：哪些地方可以动，哪些地方不要碰。

比如：

只处理 src/auth 目录，不扩散到用户模块、订单模块和公共中间件。

约束：必须遵守什么。

比如：

保持现有 API 兼容。
不引入新依赖。
优先最小改动。
不要改变数据库结构。

验证：怎么判断它真的做完了。

比如：

先运行 auth 相关测试，再运行 npm run typecheck。
如果测试失败，先定位原因并修复，不要直接跳到下一个任务。

输出：最后要交付什么。

比如：

输出修改文件列表、每个改动的原因、验证命令和结果，以及仍然存在的风险。

这五点合起来，其实就是一份压缩版任务说明书。

你已经不只是在许愿“帮我搞定”，而是在把一个工程任务设计成 AI 可以持续执行、可以验证、可以收敛的目标。

不要一上来就挂大目标

这里有一个容易踩的坑。

很多人看到 /goal，第一反应可能是把大任务直接丢过去：

/goal 帮我把整个登录系统重构好。

这句话太虚。

“重构好”是什么意思？是拆文件、抽公共逻辑、改接口设计，还是补测试？做到什么程度算结束？哪些历史兼容不能动？

更稳的方式，是先让 Codex 分析当前项目，给你一份方案。

比如：

先分析当前项目的登录模块，找出重构风险，给我一份最小改动方案。重点关注 API 兼容、测试覆盖和依赖影响。先不要修改文件。

你确认方案之后，再挂 /goal：

/goal 按确认后的方案重构登录模块。保持现有 API 兼容，不引入新依赖。每次只做一个最小修改，修改后运行相关测试。最后输出变更总结、验证结果和剩余风险。

这更接近真实研发流程。

先让 AI 看清楚局面，人来判断方案是否合理；再让 AI 围绕确认后的目标持续推进。

不要把 AI 当许愿池。要把它当成一个需要任务边界、验收标准和工作节奏的执行者。

/goal 适合什么，不适合什么

我不会把 /goal 神化。

它不是全自动项目经理。你不能随便扔一句话，然后去喝咖啡，回来整个项目就自动上线。

复杂项目里的隐含约定、历史包袱、线上风险、权限边界，都需要人来判断。

如果目标写得很模糊，AI 还是会跑偏。

如果没有验收标准，它可能给你一个“看起来完成了”的结果。

如果不限制范围，它可能为了通过测试改出一堆奇怪补丁。

所以 /goal 更适合这些任务：

• 修复一组测试失败。
• 补齐一份技术文档。
• 重构一个边界清楚的小模块。
• 完成一个小功能闭环。
• 迁移一个配置项。
• 把某个脚本改到可复用。

它们有明确边界，有验证反馈，也有收敛标准。

不适合的，是那种一上来就说：

帮我把整个系统优化一下。

对 AI 来说，模糊目标不是自由度，很多时候是风险源。

开发者的差距，会从“会问”变成“会定义”

我关注 /goal，不是因为它现在已经完美。

它还只是一个早期信号。

但这个信号很清楚：AI 编程工具正在从聊天式协助，走向目标式执行。

以前你每一轮都要提醒它继续。

现在你开始可以给它一个持续目标，让它围绕目标推进。

以前目标藏在上下文里，AI 靠猜。

现在目标有机会变成线程状态，配合工具、验证和恢复机制一起工作。

如果这个方向继续走下去，后面很可能会接上更清晰的里程碑、更稳定的恢复机制、更细的任务预算、更完整的测试和审计闭环。

到那时候，Codex 可能就不只是一个“帮你写代码的工具”。

它会更像一个研发工作台。你在里面定义目标。

它拆任务、跑命令、改代码、查文档、修测试、记录状态、输出结果。

人负责判断方向、设定边界、做关键决策和最终验收。

这也是我觉得开发者接下来要补的一课：

当 AI 开始能“接目标”，你还只会给它派零碎指令吗？

会写 prompt 只是开始。

会定义目标，才是 AI 编程进入 Agent 阶段后更值得练的能力。

我整理了一份 /goal 长任务提示词包

如果你想直接上手，我整理了一份《Codex /goal 长任务提示词包》。

里面包括 7 个常见工程场景：修复测试失败、修复 CI、小型模块重构、补 README / 架构文档、阅读仓库并生成 onboarding guide、迁移配置项、完成一个小功能闭环。每个模板都按“目标、范围、约束、验证、输出”这五个维度写好。

有兴趣可以私信关键词获取提示词模板：goal

最后我想说的是模板只是起点。更要练的，是把自己的工程任务定义成 AI 能持续推进、能验证、能收敛的目标。

参考资料

• OpenAI Codex Changelog：Codex CLI 0.128.0 新增 persisted /goal workflows https://github.com/openai/codex/releases/tag/rust-v0.128.0
• OpenAI Codex Best Practices：Plan mode 与复杂任务实践 https://developers.openai.com/codex/best-practices
• OpenAI Developers Blog：Run long horizon tasks with Codex https://developers.openai.com/codex/long-horizon