从 Prompt 到 Goal

以下来自 @ZeroZ_JQ 的长文。作者越来越觉得，使用 coding agent 时，最危险的一句话不是"帮我写代码"，而是：

"继续。"

继续改。继续查。继续跑测试。继续修刚才那个错误。

这句话太顺手了，顺手到我们经常忘了，它其实暴露了一个问题：很多时候，我们自己也没有想清楚，这件事到底应该做到哪里。

所以 Codex 的 /goal 出现时，作者第一反应不是"又多了一个命令"，而是：如果 AI 已经开始学会自己继续，人类还剩下什么工作？

"继续"这句话，本来就有问题

过去我们和 AI 写代码，默认是人负责节奏：AI 停下来，人说继续；AI 跑偏了，人把它拉回来；AI 没跑测试，人提醒它跑一下。这套方式能用，但它有一个隐含前提：人必须一直站在旁边——人负责记住目标、判断方向、提醒边界、决定什么时候算完成。

AI 虽然执行了很多动作，但真正维持任务连续性的，还是人。这也是为什么很多 coding agent 看起来很强，用起来却依然很累：它很容易丢掉主线——改了一个文件，又顺手动了另一个不该动的地方；修了一个问题，却没有回到最初的目标。

/goal 真正有意思的地方：它不是让 Codex 更会写代码，而是让"继续"这件事，从一句人工指令，变成系统可以管理的状态。

如果只把 /goal 看成一个 slash command，那它没什么可讲的。但它背后的变化很大：

这才是变化。以前 AI 停下来，你说继续；以后 AI 可以围绕一个 goal 自己继续。

这听起来像是人轻松了，实际不是——一旦"继续"变成系统能力，人就不能再用模糊需求糊弄过去。你不能只说"帮我优化一下""帮我整理一下""帮我重构一下"：优化什么？整理到什么程度？能不能改 API？能不能动历史逻辑？要不要补测试？跑到什么结果才停？

这些问题如果一开始不说清楚，AI 不会因此停下来思考人生，它会继续干，而且干得很积极。这才是最危险的地方。

以前给 AI 一个模糊问题，最多得到一个模糊回答。现在不一样了：当 AI 能读项目、改文件、跑命令、继续修复，一个模糊目标就不只是模糊了，它会变成一串真实修改。

比如你说"帮我优化用户模块"，它可能会开始重构组件、改请求逻辑、顺手整理类型、移动文件——把一个本来很小的问题扩成一次结构调整。最后它告诉你：完成了。问题是，你根本没有定义什么叫完成。

这不是模型邪恶，也不是模型乱来，它只是在认真执行一个坏目标。

过去讲 prompt，关心的是怎么表达：语气怎么写、角色怎么设定、上下文怎么补、示例怎么给。这些仍然有用，但在 coding agent 场景里已经不够了——因为复杂工程任务不只是"说清楚"，而是要"交付清楚"。

所以，一个能交给 /goal 的任务，至少要有四个东西：目标、上下文、约束、完成条件。很多 AI 任务失败，问题就出在这里：目标写得像愿望，上下文给得像谜语，约束几乎没有，完成条件全靠感觉。然后我们怪 AI 跑偏——其实它不是跑偏，它只是没有路。

最该写清楚的不是"做什么"，而是"做到哪里"

目标告诉它往哪里走，完成条件告诉它什么时候停。没有完成条件，AI 容易出现两种毛病：一种是太早停（改出一个能跑的版本就认完成），另一种是停不下来（补边界、补文档、顺手重构，任务越滚越大）。

所以写给 AI 的，不应该只有一句需求，至少要加一句："什么情况下，你可以认为这件事做完了？"

不是所有任务都适合 /goal。它适合那些已经想清楚方向、边界相对明确、结果可以验证的任务：

• 修一组相关 bug；补一批测试；完成一个小功能；
• 做一次受控重构；整理一套文档；执行一轮迁移。

不适合一上来就交的：重新设计核心架构、探索产品方向、做一次"全面优化"、定义新的业务流程、处理安全边界不清的任务。这类任务要先讨论、拆解、比较方案，等方向清楚了，再变成一个个小目标。

真正被考验的，是项目本身有没有工程感

AI 会放大项目原有的工程习惯：有清晰的 README、测试命令、目录约定、架构说明、边界规则，AI 进入后很快找到路；全靠老员工脑子里隐性知识的项目，AI 只能猜——不知道哪个模块不能动、哪个接口历史包袱重、哪些测试必须跑。人可以靠经验弥补文档缺失，AI 只能靠上下文推断，而推断越多，错误越多。

所以项目文档不只是写给新人看的，也是在写给 AI 看的。AGENTS.md、开发说明、测试命令、架构边界、历史坑位，会越来越像项目的"AI 可读层"。这不是文档洁癖，这是给未来的执行者修路。

开发者的位置上移 + goal review

执行层（查文件、改代码、跑测试、修报错）AI 会承担更多；人更重要的事变成：判断值不值得做、把模糊需求拆成清晰目标、定边界、设计验收、判断方案是否过度、复盘。AI 越像执行者，人越要像负责人——这要求人更懂工程，因为你要知道什么可以交给 AI、什么不能交。

团队很可能多出一个动作：goal review。过去 review 代码，以后先 review 任务本身：目标是不是太大？上下文够不够？有没有不该碰的范围？完成条件能不能验证？如果目标本身是错的，代码 review 已经太晚了——因为 AI 已经把错误目标执行成了一堆修改。

以下来自原文附录"如何写一个好 Goal"，全文保留。先记住五标准与一句话公式：

1. 目标明确：知道要解决什么问题；
2. 范围清楚：知道改哪里、不改哪里；
3. 上下文足够：知道项目背景和相关文件；
4. 验收可验证：知道什么情况算完成；
5. 风险有边界：知道哪些地方不能乱动。

最小版 Goal 模板

复制# Goal
<一句话说明本次要完成什么>

## Context
<项目背景、相关文件、当前问题>

## Scope
Include:
- <允许修改的范围>
Exclude:
- <不允许修改的范围>

## Constraints
- <必须遵守的规则>
- <不能做的事情>

## Plan
1. <第一步>
2. <第二步>
3. <第三步>

## Done When
- [ ] <功能验收>
- [ ] <技术验收>
- [ ] <回归验收>
- [ ] <输出验收>

## Review
完成后请说明：
- 修改了什么
- 运行了什么验证
- 是否还有风险

完整版 Goal 模板（10 节）

复制# Goal: <用一句话写清楚本次目标>

## 1. Background / Why
为什么要做这个任务？
当前遇到的问题是什么？
这个问题造成了什么影响？

## 2. Objective / What
本次任务要完成什么？
只写具体目标，不写泛泛愿望。
差：优化用户模块。
好：优化用户列表页在大数据量场景下的筛选、分页和渲染性能。

## 3. Scope / Where
本次任务允许修改哪些范围？
### Include
- 允许修改的文件、目录或模块
- 允许新增的测试
- 允许更新的文档
### Exclude
- 不允许修改的模块
- 不允许重构的历史逻辑
- 不允许改变的接口、数据结构或行为

## 4. Context / Existing Information
AI 执行前需要知道哪些上下文？
包括：
- 当前项目结构
- 相关文件
- 相关业务规则
- 已知问题
- 依赖关系
- 之前踩过的坑

## 5. Constraints / Rules
执行过程中必须遵守哪些约束？
示例：
- 不要改变现有 API 返回结构
- 不要引入新的大型依赖
- 不要做无关重构
- 不要改动权限逻辑
- 不要删除已有测试
- 所有新增代码必须通过 TypeScript 检查
- 如果发现目标范围外的问题，只记录在 Review 中，不要直接修改

## 6. Plan / Suggested Steps
建议 AI 按什么顺序执行？
示例：
1. 阅读相关代码，确认问题来源
2. 检查当前实现路径
3. 制定最小修改方案
4. 修改核心逻辑
5. 补充或更新测试
6. 运行验证命令
7. 输出修改说明和遗留风险

## 7. Done When / Acceptance Criteria
什么情况才算完成？这是整个 goal 最重要的部分。
### Functional Acceptance
- [ ] 核心用户流程正常
- [ ] 空状态、加载状态、错误状态正常
- [ ] 相关边界场景正常
### Technical Acceptance
- [ ] pnpm lint 通过
- [ ] pnpm typecheck 通过
- [ ] pnpm test 通过
- [ ] pnpm build 通过
### Regression Acceptance
- [ ] 相关旧功能不受影响
- [ ] API 调用方式不破坏兼容性
- [ ] 不引入无关重构
### Output Acceptance
- [ ] 最终说明修改了哪些文件
- [ ] 最终说明运行了哪些验证命令
- [ ] 最终说明是否还有遗留风险
- [ ] 如果无法完成，说明阻塞原因和下一步建议

## 8. Risks / Watch Out
这次任务最容易出问题的地方是什么？
示例：
- 过度重构导致旧功能回归
- 只解决表面问题，没有解决根因
- 引入缓存后造成数据不同步
- 改动公共逻辑导致其他页面受影响

## 9. Out of Scope
明确哪些事情本次不做。
示例：
- 本次不重构整个模块
- 本次不修改后端接口
- 本次不重新设计 UI
- 本次不引入大型新依赖，除非现有方案无法满足验收标准

## 10. Review Requirement
完成后需要输出什么复盘？
请在最终回复中包含：
1. 修改摘要
2. 修改文件列表
3. 验证命令与结果
4. 未完成项
5. 风险和后续建议

好 Goal 检查表（六维）

不要只写"完成登录功能"，而要写清"什么情况下你可以认为做完了"（来自原文的例子）：

• 用户能登录；
• 错误密码有提示；
• token 过期会回登录页；
• 不影响注册流程；
• 类型检查通过；
• 核心测试通过；
• 最终说明改了哪些文件、跑了哪些命令、还有什么风险。

这不是形式主义，这是刹车。

收束：学会让它停

/goal 看起来在解决"继续"的问题，但它真正提醒的是"停止"的问题。AI 已经越来越会继续：继续读文件、继续改代码、继续跑测试、继续修失败。可真正的工程判断，往往不在"继续"里，而在"停在哪里"：哪里不能动、哪里要等人确认、什么结果才算完成、什么风险必须留下来、什么任务根本不该开始。