AI 编码进入「放手」时代：Codex 的 -goal 模式正式毕业，设定目标后它自己干到完

公众号名称：程叙架构与AI.

作者名称：AI兴观点

发布时间：2026-05-22 15:49

原文链接：https://x.com/openaidevs/status/2057530209470210453

✅点击上方🔺公众号🔺关注我✅

用 AI 写代码最让人抓狂的是什么？

不是 AI 写得不够好，是你得像盯着实习生怕他删库一样坐在旁边看着每一步输出。

写个小函数还行。但凡是个正经任务——重构模块、迁移代码库、修一串 bug——你就得端着咖啡守在终端前，时不时敲个 yes，看一眼进度，再告诉它「下一步」。

开发者时间最值钱的部分不是写代码，是沉浸在大任务里不被打断。而过去的 AI 编程助手，本质上是把打断当功能卖的。

今天 OpenAI 把一个叫 /goal 的东西从实验状态「毕业」了——Codex 能自己盯着一个目标干到完，跨小时、跨天。你在旁边看着就行。或者不看。

你终于不用当那个「盯着 AI 干活的人」了

先看官方演示——90 秒感受一下这种「设完目标就走开」的体验。

如果你是第一次用，场景大概是这样的：

你给 Codex 一个目标：「把这个代码库从 JavaScript 迁移到 TypeScript，编译模式开 strict，不允许用 explicit any。」

然后 /goal。走人。

回来的时候，它可能已经干完了。你检查 diff，review 关键改动，有问题就 steering 一下。全过程不需要你坐在旁边逐行看。

原理很简单：goal 文本既是指令也是完成标准。Codex 用自己的判断决定下一步做什么、什么时候算做完。中间你可以随时检查进度（用 side chat，不影响主任务）、暂停、调整约束、再继续。

说白了，就是从「你指挥 AI 每步做什么」变成了「你告诉 AI 最终要什么」。

从「看着 AI 写代码」到「给 AI 分派任务」

这两个状态的区别，是 AI 编码工具走到今天最大的一个拐点。

过去一年，AI 编程助手的进化路径大致是这样的：

阶段	代表	工作模式	你需要做的
补全	Copilot / Tabnine	你写一行，它补下一行	持续编码
对话	ChatGPT / Claude	你问一句它写一段	引导+复制粘贴
代理	Cursor / Windsurf	你描述意图，它执行	盯着+纠正
自主目标	Codex /goal 🆕	你设目标，它自己规划执行	走开就行

第四阶段才是真正的「放手」。

前面三个阶段，不管多智能，本质上你还是肉身上班——人在机在，人走机停。/goal 模式把「需要你持续在场」这个前提给去掉了。你可以在 code review、开会、甚至睡觉的时候，让 Codex 把活干完。

对于独立开发者、创业团队、或者任何一个「只有一个人但活是一个团队的量」的场景，这个区别是根本性的。

🎯 官方截图 /goal 模式界面

怎么上手

配置 /goal 很简单。

首先确认你用的是支持 goal 的 Codex 版本（App、IDE Extension、CLI 都可以）。如果 slash 命令列表里没有 /goal，在 config.toml 里打开功能开关：

[features]
goals = true

或者直接在命令行跑：

codex features enable goals

然后在 App 里，/goal 后面跟上你的目标。写目标有一些讲究：

好的 goal 长这样：

Migrate this codebase from JavaScript to TypeScript. The app should compile in strict mode without explicit any type definitions.

它包含三个要素：

具体 outcome（迁移到 TypeScript，不是「优化代码」）
可衡量标准（strict 模式下编译通过）
边界条件（不能用 any）

如果你的目标比较复杂，可以用 /plan 让 Codex 先出一个方案，你再确认。甚至可以直接让 Codex 采访你，帮你把 goal 写清楚——对话式的，不是填表式的。

几个实操技巧：

用 side chat 查进度。在 Codex 工作的时候开一个新对话问「它干到哪了」，不影响主线程
想修改方向？直接发一条 follow-up：「用 React 18 的 API，不要用 class component」
长时间任务前先 pause，防止断连
同一个 thread 支持多轮 /goal——先写功能，再追加加测试

本质是信任问题

我一直在想，这项能力背后藏着的变化可能比功能本身更大：AI 编码工具正在从「工具」变成「队友」。

工具需要人操作。队友可以接任务自己推进。

你给一个初级工程师一个任务，你不会 5 分钟 check 一次。你会告诉他目标是什么、验收标准是什么，然后去做自己的事。中间发现方向偏了，给个 correction。

/goal 模式做的事情，本质上是同一套管理逻辑。区别在于它不需要睡觉、不会摸鱼、也不会有状态不好的一天。

但开发者不会因此变得不重要。 其实反过来——设定目标、定义完成标准、做 steering 决策，这些比以前「写代码」本身更值钱。

以前你会因为「谁会写这行语法」而有价值。未来你会因为「谁能定义什么算做完」而有价值。

一些值得注意的细节

从 OpenAI 官方文档里摘几个我实际用过之后觉得重要的点：

Cloud threads：如果你把代码推到 GitHub，可以在云端跑目标，然后本地继续干别的事。适合需要多设备同步工作的人
Context compaction：超长任务下，Codex 会自动压缩上下文，把不相关的细节摘要化，让任务可以延续几百步
多线程并行：你可以同时跑多个 thread，但官方提醒别让两个 thread 改同一个文件
Side chats 默认不影响主任务状态，放心用

最后说两句

我其实不太喜欢每次写 AI 工具更新都要带一句「程序员是不是要失业了」的讨论。

/goal 模式给我的感觉正好相反。

它不是在替代你写代码。它是在让你从「看 AI 干活」里解放出来，去干真正需要你干的事——设计架构、做技术决策、跟业务兜在一起。

以前你是 AI 的保姆。现在 AI 是你的实习生，慢慢在变正式员工。

如果觉得这篇文章有帮助，欢迎点赞、在看、转发！你有没有试过让 AI 自己跑一个几小时的任务？来评论区聊聊体验！

cover_image

Original AI兴观点程叙架构与AI.

内容效果不满意？点此反馈