当我跨过沉沦的代码：Codex Goal 模式生存指南

公众号名称：陈大黄

作者名称：陈蛋黄

发布时间：2026-05-27 00:00

我年轻的时候，总觉得世上的事情大体可以分为两类：有趣的，和无趣的。

写代码这件事情，原本是有趣的，但如果你要在几千行混杂着各种逻辑的屎山里重构，或者去排查一个时好时坏的不稳定测试，这就变成了一件极其无趣且让人感觉荒诞的事情。

在手工古法编程的年代，面对荒诞，人只能苦笑。但现在有了 AI，情况发生了一点变化。

最近，Codex 的 Goal 模式堂而皇之地进入了我的写代码主工作流。

很多人刚碰到 /goal 指令，本能地以为这无非是给机器套上磨盘，让它自己转圈去干活。这种想法实在太天真，把一件很有智力含量的事情想得和喂猪一样简单。

王小波曾写过：“当我跨过沉沦的一切，向着永恒开战的时候，你是我的军旗。”

在编程这门行当里，如果把日常那些繁杂、琐碎、令人绝望的代码重构与性能排查比作“沉沦的一切”，那么 Goal 模式就是插在执行线程最前方的那面军旗。

聊到这里，我觉得有必要把Claude Code 的 Plan Mode 拉出来遛遛。

我总觉得 Claude 身上有种知识分子的穷酸气，做事情讲究“谋定而后动”。

它的官方文档里极力推崇 plan before editing，主张动刀子前先审阅图纸，它甚至建议你把项目级标准、架构决策都供奉进 CLAUDE.md 里，好让这些规矩进入上下文。Claude 喜欢先探索代码，写好计划，等你点个头再干。

而 Codex 的 Goal 模式就带着点破釜沉舟的莽劲：图纸一旦敲定，挂上这个持续目标，它就顺着道一路杀下去，全靠验证和停止条件来判断该不该收手。

这两者放在一起简直绝配：先用 /plan 在沙盘上把目标盘明白，再用 /goal 挂上帅印让 Codex 去长线卖命。

基于此，我在实际使用 Goal 的时候，一般喜欢先把需求想清楚写到文档，方案也顺带写一下，然后验证环境准备好了，我再开启 Goal 模式，让 Codex基于这些东西把代码一把头干完。

普通的 prompt 像极了毫无灵魂的应答，你拨一下，它转一下。就像一个做一天和尚撞一天钟的摸鱼打工人。你跟它说前进一步，它就前进一步，然后等你的指示，是要迈左脚呢？还是要迈右脚呢？

Goal 模式就不一样了，他给战士们立下了Flag，势必要拿下那座山头。所有的动作都要朝着这个结果死磕，兄弟们，给我冲！

只要终点清晰，Goal 就能发挥最大威力。

不过，凡事都有个度。你要是让它干一些不知所云的事情，比如“帮我做一个 AI 工具站”，这就等同于把方向盘交给一个疯子。

它会用无穷无尽的登录、支付和历史记录把你淹没。

再比如“优化页面体验”，这种没有任何度量衡的鬼话，只会让它在代码里随地大小便。

没有验证环境更是要命，它会在一片虚无中极其自信地宣布成功。

最可怕的是那种没有尽头的指令，比如“持续优化这个项目”，它会像推石头的西西弗斯一样永远转下去，顺便烧光你的 API 额度。

所以，写一个好 Goal，是一件需要理智和逻辑的事情。你得盯着目标、证据、边界和停止条件这四个东西。

• 目标要像小和尚的头一样硬。
• 证据要像数学公式一样严谨，机器自己喊出的“已完成”连个屁都不算。
• 边界是你给它戴上的枷锁，省得它自作多情给你惹祸。
• 停止条件，就是勒在它脖子上的缰绳，一旦局面开始魔幻，得赶紧收紧目标，得得得，停停停。

我们可以看几个极其现实的例子。假设我手头已经写好了 docs/features/ai-tech-research-tool.md，里面把第一版的规矩定得死死的。我绝对不会只对它喊一句“帮我做完”，我会这么写：

/goal 按照 docs/features/ai-tech-research-tool.md 实现 AI 技术调研工具第一版。

执行前要求：
1. 先阅读 docs/features/ai-tech-research-tool.md。
2. 再阅读 AGENTS.md。
3. 输出你对第一版目标、不做事项、实施阶段、验收标准的理解。
4. 如果发现需求冲突，先暂停并说明，不要直接实现。

完成标准：
1. 页面可以输入技术名称、项目背景、约束条件。
2. API 可以返回结构化调研报告。
3. 前端展示 summary、适用场景、不适用场景、替代方案、风险点、最小 Demo 建议。
4. 不做登录、历史记录、支付、用户中心。
5. 不引入未经确认的新依赖。
6. pnpm typecheck 通过。
7. pnpm lint 通过。
8. 使用浏览器验证主流程。
9. 验证通过后提交 git commit。
10. 最后输出修改文件、验证结果、commit hash、遗留风险。

停止条件：
1. 全部验收标准通过。
2. 遇到需要人工确认的危险操作。
3. 同一个 blocker 连续出现两次。
4. 验证环境不可用，且无法自行恢复。

这就好比给一头蛮牛套上了极其精密的犁。它知道去哪儿看地图，知道什么能碰什么不能碰，知道怎么证明自己把地耕完了，也知道碰到石头该停下来。

性能优化也一样。你不能对着机器发泄情绪说“优化一下”，你得用理性的光辉照耀它。我会告诉它把 Lighthouse Performance 提升到 90 分以上，绝不能改核心功能，也不能瞎加依赖。用 pnpm lint 和跑分脚本去压榨它，只要分数达标，或者连续两轮优化连 2 分都提不上去，立马给我停下。

/goal 排查并修复 tests/research.spec.ts 中间歇性失败的问题。

目标：
让该测试连续运行 10 次全部通过。

执行要求：
1. 先复现失败，不要直接猜原因。
2. 记录失败日志。
3. 分析可能原因。
4. 每次只修一个可验证假设。
5. 不要为了通过测试修改测试目标。
6. 不要跳过测试。
7. 不要扩大修改到无关模块。

验证方式：
1. 连续运行 pnpm test tests/research.spec.ts 10 次。
2. 记录每次结果。
3. 如果修复涉及异步等待、mock、时间、网络请求，要说明原因。

停止条件：
1. 连续 10 次通过。
2. 连续两轮无法复现失败。
3. 同一个 blocker 出现两次。
4. 需要用户提供外部服务或密钥。

先复现，再记日志，然后提假设，一次只动一个地方。连续 10 次跑通，这事儿才算完。这才是对待一门科学应有的态度。

当然，机器跑起来以后，你也不能去睡大觉。

我总会要求它在完成每个阶段后输出个状态，告诉我它干了啥、改了啥、下面要干啥。长任务跑到最后，一定得做最终审计。

机器的记性有时候比鱼还差，跑得久了，上下文一压缩，它可能看最后一次 lint 过了就以为天下太平。

GitHub 上早有人骂过这事儿，说 agent 弱化了原始 Goal 里的 audit 要求，早早地就打卡下班了。所以我现在逼着它在交差前，重新读一遍文档，逐条对齐验收标准，把 git status 拍在我脸上。盲目的自信在工程里一文不值，我们要的是铁证。

这套把戏玩多了，坑也就见得多了。如果这机器要删文件、改支付逻辑，必须马上勒令它暂停。遇到缺密钥这种没法靠努力解决的 blocker，或者权限卡住了，连续出现两次就得停，千万别让它在一个死胡同里一遍遍地假装真诚，那是一件十分无趣且浪费金钱的事情。

我现在干代码，先写实施方案，把规矩定在 docs/features/xxx.md 和 AGENTS.md 里。搭好从 typecheck 到日志的验证环境。最后，把包含目标、证据、边界和停止条件的 Goal 甩给它，听它阶段性汇报，结束前狠狠地审计一番。

Goal Mode 确实是个有意思的发明，赋予了硅基生命惊人的长跑能力。

但如果这长跑没有明确的终点，没有不可逾越的护栏，那它跑得越欢，灾难就越大。

它存在的意义就是让 AI 像个被理性锁死的清教徒，死死盯着唯一的验收标准去卖命。

一份写得好的 Goal，本质上就是你和一台没有感情的机器签下的一纸残酷契约。

交代好你要什么，什么碰不得，什么时候滚回来见我。

只有在这个框架里，Goal Mode 才有它存在的价值。

否则，你只是给了一个不知疲倦的蠢汉一张乱七八糟的草图，任由他在你的代码库里彻夜狂欢。

他确实很努力，但你的世界也随之毁了。

参考资料

• OpenAI Codex Changelog：2026-05-21，Goal 模式不再是 experimental feature，并在 app、IDE extension、CLI 中可用。
• OpenAI Cookbook：Using Goals in Codex。
• OpenAI Codex：Follow a goal。
• OpenAI Codex：Commands，/plan 与 /goal。
• OpenAI Codex：Iterate on difficult problems。
• Claude Code Docs：Common workflows，Plan before editing。
• Claude Code Docs：Memory / CLAUDE.md。
• Claude Code Docs：VS Code integration，review and edit plans before accepting。

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