如何给 AI 编程 Agent 下任务，才能减少返工
核心结论：AI 编程 Agent 返工，大多数不是模型不够强，而是任务边界不清、验收标准不清、上下文不完整。
1. 一句话结论
如果我要让 AI 编程 Agent 真正稳定产出，我最该优化的不是提示词花样，而是任务定义方式。
最有效的做法只有五件事：
- 先讲清楚目标，不要只讲动作。
- 明确允许修改和禁止修改的范围。
- 给出验收标准，而不是只说“改一下”。
- 补足上下文，让 Agent 少猜。
- 每次只交付一个清晰闭环，不把多个问题揉成一句话。
很多返工，本质上都来自一句模糊指令：
帮我优化一下这里
这句话对人都不够清楚，对 Agent 更不够。
2. 背景
现在很多 AI 编程 Agent 已经不只是补全代码，而是会：
- 读项目文件。
- 搜索代码。
- 修改实现。
- 运行构建和测试。
- 根据结果继续调整。
问题也正出在这里。
Agent 一旦能自己行动，模糊指令造成的损失就会被放大：
- 它可能改对了方向，但改多了。
- 它可能修了一个点，却破坏了另一个点。
- 它可能为了“看起来更稳”，擅自补一堆兜底逻辑。
- 它可能猜错你的真实目标，然后在错误方向上非常努力。
所以，AI 编程最关键的能力，不是“会不会提问”，而是“会不会下任务”。
3. 核心观点
3.1 不要只说怎么做，要先说为什么做
很多人给 Agent 的输入只包含动作，不包含目标，例如：
把这个表单拆成组件
这句话的问题是，Agent 不知道你为什么要拆。
真实目标可能完全不同：
- 为了复用。
- 为了缩短页面文件长度。
- 为了隔离权限逻辑。
- 为了让测试更好写。
如果目标不同，拆分方式就不同。
更好的写法：
目标：把页面里的“筛选区”抽成独立组件，减少页面文件复杂度。
约束：只处理筛选区，不调整表格和请求逻辑。
验收：页面交互不变，筛选参数透传，构建通过。
重点不是“更长”，而是“更清楚”。
3.2 任务边界不清，是返工的第一来源
Agent 和新人开发很像：你不说边界，它就会自己补边界。
最常见的失控方式有三种：
- 改动范围扩大，把无关文件一起重构了。
- 为了通过构建，顺手改了公共类型或公共工具。
- 为了避免报错，增加了不必要的空值兼容和兜底逻辑。
所以我现在更推荐这种任务描述：
允许修改：
- src/views/order/List.vue
- src/components/OrderFilter.vue
禁止修改：
- 请求层
- 路由定义
- 全局组件
只要范围清楚，返工概率会明显下降。
3.3 验收标准比“实现思路”更重要
很多人会给 Agent 很多实现建议，但不给验收标准。
例如：
用 hooks 重构一下，顺便优化性能
这种描述很容易让 Agent 自由发挥，最后你只能重新 Review 一大轮。
更合理的写法应该是：
验收标准：
- 保持现有页面行为不变
- 首次加载请求次数不增加
- 不新增全局状态
- `pnpm build` 通过
对 Agent 来说，验收标准就是收敛条件。没有收敛条件，它就容易在“看起来合理”的方向上不断扩展。
3.4 上下文越缺，Agent 越爱猜
Agent 做错很多时候不是能力问题，而是信息不够。
尤其在这些场景里，缺上下文几乎必然返工：
- 老项目里存在历史约定。
- 组件库已经有现成模式。
- 某个模块有隐式业务规则。
- 仓库里有
AGENTS.md、README.md、设计约束或目录约定。
所以我更建议直接把关键上下文前置，而不是等 Agent 自己搜半天：
背景：
- 这是一个中后台项目
- 技术栈是 Vue 3 + TypeScript + Vite
- 当前页面沿用组合式 API
- 不接受为兼容旧逻辑新增兜底分支
这类信息看起来简单，但对结果影响非常大。
4. 具体方法
4.1 我现在常用的任务模板
下面这个模板，基本已经够覆盖大多数代码类任务：
背景：
- 这是一个什么项目
- 当前模块负责什么
目标：
- 这次到底要完成什么
范围：
- 允许修改哪些文件或模块
- 不允许碰哪些部分
约束：
- 技术栈约束
- 风格约束
- 不接受的实现方式
验收标准：
- 功能结果
- 构建/测试要求
- 性能或行为约束
输出要求：
- 是否需要补文档
- 是否需要说明风险
- 是否需要提交 commit
这个模板的好处是，它不是为了“写得专业”，而是为了减少猜测空间。
4.2 四类常见任务，应该怎么下
场景一：修 Bug
错误示范：
这个页面有问题，你修一下
推荐写法：
背景：订单列表页切换分页后，筛选条件被重置。
目标：修复分页切换时筛选条件丢失的问题。
范围：只允许修改订单列表页和筛选参数同步逻辑。
验收：切分页后筛选条件保持不变，返回第一页时仍正确，`pnpm build` 通过。
场景二：做重构
错误示范：
把这块代码优化一下
推荐写法：
目标：把页面内超过 300 行的筛选区逻辑抽成独立组件，降低主页面复杂度。
范围：只拆 UI 和事件透传，不改接口层。
约束：不新增状态管理，不改现有接口字段，不补兜底逻辑。
验收：页面行为一致，代码职责更清晰，构建通过。
场景三：新增功能
错误示范：
加一个导出按钮
推荐写法：
背景：订单列表页需要支持按当前筛选条件导出。
目标：增加“导出当前结果”按钮。
范围：允许修改列表页、导出按钮组件、导出请求封装。
约束：导出参数必须复用当前筛选条件，不单独维护第二份状态。
验收：筛选后导出参数正确，未筛选时使用默认查询条件，构建通过。
场景四：写文章或文档
错误示范：
帮我写一篇总结
推荐写法：
目标：写一篇适合公开发布的知识库文章。
读者：有 3 到 5 年经验的前端工程师。
风格：结论先行，少空话，多方法。
结构：背景、核心观点、具体方法、常见问题、结论。
4.3 交付闭环不要过大
Agent 擅长的是“一个闭环一个闭环地推进”，不擅长在一句话里同时完成五种目标。
例如下面这种任务就很危险：
顺便把页面重构一下，再优化请求层，再补几个测试，然后把 UI 改漂亮一点
这类需求混合了：
- 架构调整
- 功能修复
- 工程验证
- 视觉改造
对人来说都应该拆，对 Agent 更应该拆。
更合理的方式是：
- 先修行为问题。
- 再做结构重构。
- 再补测试。
- 最后做视觉优化。
每一步都能验证，每一步都能回滚。
5. 常见问题
5.1 为什么我已经写得很长了，Agent 还是做错？
因为“长”不等于“清楚”。
很多长提示的问题在于：
- 背景很多，但目标不清楚。
- 限制很多，但验收标准没有量化。
- 说了很多偏好，却没说这次到底不能碰什么。
判断标准很简单：
如果把这段任务描述给团队里的新同事，他仍然会追问，那给 Agent 也一样不够清楚。
5.2 我要不要把实现细节全部规定死？
不用。
如果你已经非常确定实现路径，可以明确约束；如果你只是要结果，不一定要把过程锁死。
更实用的原则是：
- 目标和边界要明确。
- 关键约束要明确。
- 非关键实现细节可以留给 Agent 发挥。
不要把任务写成“只允许按我脑子里的每一步执行”，否则 Agent 的价值会被你自己抵消掉。
5.3 为什么我总感觉 Agent 喜欢过度设计？
因为很多指令里隐含了错误激励，比如：
- “顺便优化一下”
- “尽量写稳一点”
- “把能处理的边界都处理了”
这类话很容易诱导 Agent 主动增加抽象、兼容分支和兜底逻辑。
如果你追求的是代码质量和一致性，反而应该说得更硬一点：
- 不增加无关抽象。
- 不补兜底兼容。
- 不改无关模块。
- 不猜不存在的业务分支。
6. 我的结论
AI 编程 Agent 的上限，越来越像“团队里一个执行力很强但需要被清楚管理的工程师”。
所以真正决定结果质量的，不只是模型能力，而是我有没有把任务定义清楚。
我的当前做法很简单：
- 先写目标，不先写动作。
- 先定边界，不让 Agent 自己扩散。
- 先定验收，不让任务无限延伸。
- 先补上下文，不让它靠猜。
- 一次只交付一个闭环。
如果这五点做好，返工会明显下降，Review 成本也会一起下降。
7. 可直接复用的任务模板
背景：
-
目标：
-
允许修改：
-
禁止修改：
-
约束：
-
验收标准：
-
输出要求：
-