夜雨聆风AI 编程助手的下一步，不是更会回答，而是更会围绕一个目标持续推进。
以前让 AI 帮你改一个复杂项目，最烦的地方，往往不是它不会写代码。
而是它写着写着就停了。
你让它改一个登录流程，它先分析一堆，写了两个文件，然后开始等你确认。你让它继续，它又忘了刚才为什么这么改。你再补上下文，它可能又换了一个思路。
一来一回，最后会有一种很荒诞的感觉：
明明是我找 AI 来帮忙，怎么现在变成我在带一个记性不太好的新人？
所以我看到 Codex 的 /goal 结束实验、变成稳定功能这个消息时，第一反应不是“又多了一个命令”。
我觉得这事儿还挺关键。
据宝玉在 X 上整理的公开信息，Codex 现在可以在应用、IDE 扩展和 CLI 里使用 /goal。它的重点不是让你多打一行斜杠，而是让你给 Codex 设定一个明确目标，然后让它围绕这个目标持续推进。过程中你可以查看进度，可以调整方向，也可以暂停。
从当前公开信息看，它适合处理更长一点、更连续一点的任务。
当然，这句话不能理解成“你把电脑交给它，它就能替你把公司项目全写完”。真这么理解，迟早要翻车。
但它确实在改变一件事。
过去我们跟 AI 写代码，大多数时候是在对话。你问一句，它答一句。你再问一句，它再答一句。哪怕它很聪明，整个节奏还是被切得很碎。
/goal 更像是你把一个阶段性目标交给它。
比如，不是说“帮我优化一下这个项目”。
而是说：目标是把登录流程里的错误处理统一起来。先梳理现在有哪些错误分支，再给出修改方案，确认后实现，最后运行相关测试，并说明还有哪些风险。
这两种说法给 AI 的压力完全不一样。
前一种听起来很舒服，但其实很空。优化哪里？改到什么程度？怎么判断改好了？哪些地方不能碰？都没说。
后一种就不一样了。它有目标，有边界，有检查点，还有验收方式。Codex 能沿着这个方向往前走，你也能在关键地方把它拉回来。
我一直觉得，很多人用 AI 效果不好，不是因为不会写复杂指令，而是不会定义一个靠谱的目标。
这话听着有点刺耳，但挺真实。
尤其是写代码这件事，它不是生成一段文本就完了。一个改动要看上下文，要看旧逻辑，要看测试，还要看是否影响其他模块。越是复杂的项目，越不能只靠一次回答。
/goal 适合的，正是这种需要连续性的事情。
比如项目重构。
你想把一批旧组件迁移到新结构里，要求行为不变，样式不乱，测试还能过。如果你只让 AI “重构一下”，它很容易直接开改，改到一半才发现旧组件里有一堆历史包袱。
更稳的方式，是先让它盘点现状，再列迁移顺序，再改一小块，再跑测试，再继续。每一步都不算神奇，难的是不要断线。
再比如排查 bug。
很多 bug 不是看一眼报错就能解决的。日志里有一个线索，复现路径里有一个线索，最近的改动里还有一个线索。普通对话里，AI 很容易给出一个看似合理的猜测。你去试，发现不对，又回来重新讲一遍。
如果用 /goal，你可以让 Codex 围绕一个复现路径持续定位：确认现象，查调用链，缩小范围，提出修复方案。它不一定每次都对，但至少更像是在沿着同一条线往下挖，而不是每一轮都重新开一局。
还有一个我觉得被低估的场景，是文档和规范整理。
很多项目最痛苦的不是没代码，而是没人愿意补 README，没人愿意整理接口说明，没人愿意把变更记录写清楚。让 AI 一次性生成一篇文档当然可以，但真正麻烦的是它要通读项目，理解目录结构，找到缺口，再把内容补齐。
这类事情很碎，很烦，但边界相对清楚，也容易人工检查。
说实话，我反而觉得这会是 /goal 比较早被大量使用的地方。不是上来就让它改核心业务，而是先让它处理那些你一直想做、但每次打开项目都懒得做的整理工作。
那怎么用会比较稳？
我自己的建议是，不要把 /goal 当成许愿池。
不要写这种话：
“帮我把这个项目变好。”
这句话对人都不算一个好需求，对 AI 就更不算了。
你可以换成更清楚的说法：
目标：统一登录流程的错误处理，让用户看到的错误提示更一致。
范围：只改登录、注册、找回密码相关代码，不碰支付和用户资料模块。
检查点：先梳理现有错误分支，再给出改动计划，等我确认后再实现，然后运行相关测试。
验收：列出改了哪些文件，哪些测试通过，哪些地方还需要人工复核。
限制：涉及删除文件、改环境变量、发布操作时，必须先停下来确认。
这就够了。
不用追求华丽，也不用写得像合同。你只要把目标、范围、检查点、验收方式说清楚，Codex 就更不容易跑偏。
这里面最重要的是检查点。
很多人一用 AI 就想完全放手，我能理解，毕竟我们都想省事。但长周期任务有一个问题，方向一旦错了，它会错得更远。AI 不是不犯错，只是它犯错的时候也能很勤奋。
这就很危险。
所以我觉得 /goal 最好的用法，不是无人看管，而是少打扰，但关键处介入。
你不用每五分钟问它“进展如何”。那样反而会把节奏打碎。但你应该要求它在方案确定前停一下，在高风险改动前停一下，在测试失败后说明原因，在结束时给出清晰的变更和风险。
也就是，把人从“每一步都盯着”的位置，挪到“在关键节点做判断”的位置。
这个变化其实挺大。
过去会用 AI 的人，常常被理解成会写很长、很复杂的指令。以后可能不是这样了。以后更重要的是，你能不能把一件事定义清楚，能不能把它拆成几个可检查的阶段，能不能知道什么时候该放手，什么时候必须介入。
回到 Codex /goal 这件事。
我不觉得它会一下子让 AI 编程进入什么全自动时代。生产代码、权限操作、数据处理、发布上线，这些地方该谨慎还是要谨慎。尤其是涉及密钥、删除、迁移、线上变更的事情，最好永远保留人工确认。
但我觉得它确实指向了一个很清楚的方向。
AI 编程助手正在从“回答问题”变成“持续做事”。
这中间差的不是聪明程度，而是目标感、连续性和验收机制。
以后真正会用 AI 的人，不一定是会写最长指令的人，而是会定义目标、拆出检查点、知道什么时候介入的人。
如果你现在手上有一个一直懒得整理的项目，你会愿意先拿哪件事试试 /goal？
