从 Grill 到 Goal：AI 编码的完整工作流

我最近一直在想 AI 编码工作流里的两个环节：先用 grill 把需求问透，再用 goal 让 agent 自主循环执行。

这个方向真正重要的，不是某个新命令，而是 AI 编码正在发生的一次范式变化：

从“让 AI 帮我写一段代码”，变成“把一个工程任务交给可托管的执行系统”。

它比单纯模型升级重要得多。

以前的问题：AI 很会动手，但不一定知道该往哪动手

很多人用 AI 编码工具，最常见的流程是这样：

1. 写一个大概的 prompt。
2. Agent 开始改代码。
3. 人看结果，发现方向不太对。
4. 继续补充要求，让它再改。
5. 来回几轮，最后勉强能用。

这个流程的问题不在于 AI 不够努力。恰恰相反，它太容易动手了。

需求没想清楚，它也会动手。边界没卡住，它也会动手。验收标准没定义，它也会动手。它不会因为你的目标模糊而停下来，它会根据当前上下文补全一个它认为合理的世界，然后开始执行。

这在小任务里还好。变量名改错了，再改回来就行。可一旦任务跨文件、跨模块、跨接口，跑偏的成本会迅速放大。

真正贵的不是 AI 多跑了几轮，而是它在错误方向上跑得太快。

Grill 解决的是对齐问题

grill-me 这类流程的价值，不是让 agent 显得更聪明，而是强迫人和 agent 在动手前把问题讲清楚。

一个好的 grill 不是泛泛地问“你想怎么做”，而是沿着决策树往下追：

• 这次任务的终点是什么？
• 哪些东西明确不做？
• 哪些假设如果错了，整个方案会翻车？
• 现在的代码结构支持这个方向吗？
• 失败时怎么判断是方案问题、数据问题，还是第三方依赖问题？
• 什么证据能证明任务真的完成了？

这些问题听起来像是在拖慢速度，但在真实项目里，它其实是在前置返工成本。

我越来越觉得，AI 协作里最重要的不是“模型能不能写”，而是“动手之前有没有对齐”。

没有对齐，agent 就是一个更快的打字机。有了对齐，它才有机会变成一个工程协作者。

Goal 解决的是持续执行问题

但只对齐还不够。

以前即使把需求讲清楚，后面仍然需要人不断推着 agent 走：

你：跑一下测试。
你：继续修。
你：再查一下这个失败。
你：把刚才的改动整理一下。

这就像你把需求给一个同事讲清楚之后，每十分钟还要走到他工位旁边问一句：“干完了吗？”

/goal 想解决的是这个问题：人不再逐步驱动 agent，而是给它一个明确目标，让它自己循环执行，直到目标达成或遇到阻塞。

一个弱目标是：

修复搜索 bug

一个强目标是：

修复中文搜索“机器学习”返回空结果的问题。
验证标准：所有搜索相关测试通过，且中文搜索“机器学习”返回至少 3 条结果。
只改搜索服务相关代码，不动其他模块。
如果问题来自第三方分词库，停止并报告依赖版本和可选方案。

两者的差异不在措辞，而在可执行性。

强 goal 里至少有四个关键要素：

1. 完成状态：什么叫修好了。
2. 验证证据：用什么证明修好了。
3. 执行边界：哪些地方不能碰。
4. 阻塞条件：什么时候不要硬跑，应该停下来报告。

这才是 agent 能自主循环的前提。

真正的工作流：Grill → Goal → Loop → Evidence

我更愿意把这套流程理解成四段：

1. Grill：把问题问透

这一段的目标不是产出代码，而是产出判断。

你要把模糊愿望变成明确任务，把隐含假设变成显性约束，把“差不多”变成“可以验收”。

比如“给搜索加模糊匹配”不是一个足够清楚的任务。至少还要继续问：

• 是中文、英文都支持，还是只支持中文？
• 容错是一个字符、一个词，还是语义近似？
• 是召回更多结果，还是重排已有结果？
• 响应时间上限是多少？
• 高亮、排序、分页是否受影响？

问完这些，任务才开始从愿望变成工程对象。

2. Goal：把判断写成可托管目标

Grill 完之后，不要直接说“按刚才讨论的做”。

要把讨论结果压缩成一个可执行目标：目标、验收、边界、策略、阻塞条件一次性写清楚。

这一步很重要，因为 agent 执行时读到的不是你脑子里的上下文，而是你交给它的目标描述。

如果目标写得松散，agent 会补全空白。如果目标写得精确，agent 才能沿着你定义的轨道跑。

3. Loop：让 agent 自主推进

进入执行阶段后，agent 应该自己完成一组循环：

读取现状 → 做一个有界动作 → 运行验证 → 根据结果调整 → 再验证

人不应该再充当每一步的按钮。

当然，这不代表完全不管。更好的方式是让 agent 在三种情况下停下来：

• 遇到目标外决策。
• 验证手段缺失。
• 继续执行会明显扩大风险。

这时候需要人介入，因为这已经不是执行问题，而是判断问题。

4. Evidence：用证据判断是否完成

最后一步最容易被忽略。

Agent 不能因为自己说“完成了”就算完成。真正的完成应该依赖证据：

• 测试结果
• benchmark 结果
• git diff
• 页面截图
• 日志输出
• API 响应
• 复现步骤是否消失

没有证据的“完成”，只是一次语言输出。

这也是 /goal 这类机制真正值得期待的地方：它把完成从“模型自我声明”拉回到“外部证据判断”。

这不是更快的代码生成，而是更完整的工程系统

很多人会把 AI 编码理解成效率工具：以前写一小时，现在十分钟。

但我越来越觉得，更大的变化不在这里。

真正重要的是，我们开始围绕 agent 设计一套工作系统：

• 怎么输入任务
• 怎么对齐目标
• 怎么限制边界
• 怎么提供上下文
• 怎么让它持续执行
• 怎么观察过程
• 怎么验证结果
• 怎么把经验沉淀到下一次

这已经不是 prompt engineering，而是 agent workflow design。

模型能力当然重要，但模型只是底盘。真正决定上限的，是外面那层 harness。

没有 harness，agent 会动；有了 harness，agent 才开始能工作。

我的实践倾向

我现在更愿意采用这样的节奏：

先讨论 → 再 grill → 写 goal → 放手跑 → 看证据 → 沉淀经验

简单任务不需要这么重。改一个文案、加一个字段、查一个函数，普通 prompt 就够了。

但只要任务具备这些特征，就值得进入这套流程：

• 下一步取决于执行中发现什么。
• 涉及多个文件或模块。
• 失败原因不确定，需要探索。
• 有明确验证方式。
• 跑偏成本明显高于前置对齐成本。

比如 debug、性能优化、依赖迁移、架构调整、测试修复、长期自动化任务，都很适合。

相反，如果没有验证手段，或者项目本身混乱到 agent 无法判断什么叫完成，直接上 goal 反而危险。它会很努力地跑，但你不知道它跑向哪里。

写在最后

Grill 和 Goal 放在一起，代表的是 AI 编码工具的一条清晰演进线：

• Grill 让任务被想清楚。
• Goal 让任务被持续推进。
• Evidence 让完成变得可信。
• Harness 让这一切可以重复发生。

这套东西的重点不是“让 AI 更快写代码”。

它真正改变的是协作结构：人不再逐句遥控 agent，而是负责定义目标、做关键判断和验收结果；agent 则在清楚边界内自主推进。

也就是说，AI 编码的核心能力正在从“生成代码”转向“执行工程任务”。

这可能才是 agent 真正进入工作流的开始。