乐于分享
好东西不私藏

AI 编程的下一步,是给 AI 设目标

AI 编程的下一步,是给 AI 设目标

过去一年,很多人用 AI 写代码的方式,其实都很像聊天。

你说一句,它写一段。它报错了,你把错误贴回去。它改完一轮,你继续看哪里不对,再说一句“继续”。

短任务这样没问题。改一个按钮、写一个小脚本、补一段样式,来回几轮就能结束。

但任务一长,问题就出来了:你会发现自己不是在管理项目,而是在 陪 AI 加班

它每次都看起来在推进,可你很难判断它到底离完成还有多远。它修了这个 bug,又可能改坏另一个地方。它说“完成了”,但你还得自己去看有没有跑测试、有没有漏边界、有没有把不该动的地方也动了。

所以我越来越觉得,AI 编程的下一步,不是更会写 prompt,而是更会写目标。

你以为在推进,其实是在陪它加班

Vibe Coding 没死,但它不适合长任务

Vibe Coding 最大的价值,是探索。

你还不知道要做什么,不知道界面长什么样,不知道方案是否可行,这时候当然可以边聊边试。AI 像一个很快的搭子,你丢一个想法,它马上给你一个可见的反馈。

但探索和交付不是一回事。

探索阶段,你需要的是灵感、方向、试错速度。交付阶段,你需要的是 稳定收口

很多人卡住的地方就在这里:明明已经进入交付阶段,还在用探索阶段的方式工作。

“帮我优化一下。”“这里有 bug,继续改。”“再检查一下。”“还有问题,继续。”

这些话都能让 AI 动起来,但它们并没有定义什么叫做完。

没有完成定义,AI 就会一直在局部修补;没有边界,它就可能顺手改掉别的东西;没有验证方式,它说完成了,你也不敢信。

真正变化的是:先定义什么叫做完

OpenAI Codex 的官方文档里,`/goal` 被描述为一个持久目标:适合让 Codex 围绕一个长期任务持续工作,直到达到可验证的停止条件、暂停,或者需要更多输入。

Claude Code 的 `/goal` 也有类似思路:你写下完成条件,系统会在每轮之后评估条件是否满足。

这两个工具的机制不完全一样,但方向是一致的:把 AI 从“等你下一句指令”推进到“围绕一个完成条件持续工作”。

这背后的关键,不是某个命令本身,而是工作方式变了。

以前你告诉 AI 下一步做什么。现在你要告诉 AI:终点在哪里

从一句句推进,变成围绕目标交付

一个好目标,至少写清四件事

我现在更愿意把 goal 看成一份小合同。

它不需要写得很长,但必须让 AI 知道四件事:结果、边界、证据、停止条件。

  • 结果
    :最后要交付什么,做到什么程度才算完成。
  • 边界
    :哪些模块、文件、体验、数据不能乱动。
  • 证据
    :用什么测试、截图、构建、基准或人工可查产物证明完成。
  • 停止条件
    :什么情况下继续修,什么情况下停下来汇报。

比如“帮我优化这个页面”就太虚了。

更好的写法是:

把这个页面的首屏加载体验优化到可感知变快;保持现有布局和核心交互不变;改动前先读相关组件和性能问题;每次改完运行构建和现有测试;如果出现回归,先修回归;最后给出改动摘要、验证命令和剩余风险。

这段话不神秘,但它把任务从“愿望”改成了 验收条件

把愿望改成验收条件

Goal Coding 拼的不是放手,而是验收能力

很多人听到“让 AI 自己干几个小时”,第一反应是兴奋。

但我觉得真正重要的不是省事,而是验收。

如果目标写得很虚,AI 只是更长时间地虚;如果验证方式不清楚,它会用看起来像完成的东西糊过去;如果边界不清楚,它可能为了达成一个局部目标,把别的地方改得更复杂。

所以 Goal Coding 不是“我不管了”。

它更像把人的工作前移:你少盯每一步,多花时间定义什么叫做完。

你要先想清楚:

  • 这个任务到底是一件事,还是一堆没关系的愿望?
  • 哪些检查结果能证明它真的完成?
  • 哪些地方即使能改,也不应该改?
  • 如果跑不通,应该继续修,还是停下来说明卡点?

这些问题越清楚,AI 越不容易跑偏。反过来,如果你自己都说不清完成状态,就算换成再强的模型,也只是把混乱执行得更快。

不是所有任务都该用 goal

我不觉得一问一答会消失。

刚开始探索一个想法,还是应该聊天。你可以让 AI 给几个方向,做一个粗糙 demo,快速验证这个东西有没有价值。

但当任务开始变长,尤其是涉及代码迁移、性能优化、批量清理、测试修复、复杂页面实现、资料整理这类可验证工作时,就应该从“继续”切到“目标”。

判断标准很简单:

如果你能说清楚 结果、边界、证据和停止条件,就可以用 Goal Coding。

如果你还说不清,那就先别急着交给 AI 长跑。先把问题拆清楚,把完成标准写出来,再让它执行。

人的角色变了

以前会用 AI 的人,像一个会问问题的人。

接下来更重要的能力,是像产品经理、工程负责人、测试负责人那样定义交付。

你不只是写 prompt,而是在写一份小型任务契约。你要告诉 AI 要去哪里,哪些路不能走,拿什么证明已经到达,什么时候必须停下来。

这也是我觉得“AI 编程下一步”的真正变化:

不是从不会写代码变成会写代码,也不是从短 prompt 变成长 prompt。

而是从 许愿式协作,走向 目标式交付

Prompt 是开口,Goal 是合同

下次把一个长任务交给 AI 前,先别急着说“继续”。

先写一句更关键的话:

做到什么状态,我才算满意?

这句话越清楚,后面的返工越少。

Prompt 是开口,Goal 才是合同。