一个AIAgent,一次到底该做多大的任务?

GUIDED BUILD / TASK SCOPE / WECHAT

“把登录、会员、支付和后台一起做完，今晚给我一个能上线的版本。”

现在的 AI Agent 确实可能一口应下这句话。它会读项目、列计划、改很多文件，再跑上一串检查。即使没有当场报错，它也可能在忙了很久以后交回来一大包改动：每一部分都沾了一点，哪一部分算完成却说不清。

任务该切多大，不能只看 Agent 能连续工作多久。一次能跑半小时，不代表半小时里塞进去的目标都适合绑在一起。

更实用的判断是：这一段工作能不能单独得到一个看得见的结果，能不能单独验收，失败以后又能不能单独撤回。

01

SCOPE

任务太大，首先丢掉的是完成标准

一个大需求里经常混着几种不同的工作。

“做一个会员系统”可能同时包括注册登录、找回密码、会员等级、支付回调、到期处理、后台管理和旧数据迁移。Agent 可以把这些词排成待办清单，但它仍要不断替人决定：先支持哪种登录方式，支付失败后保留什么状态，旧用户怎样处理，后台能改哪些字段。

这些决定没有提前确定，代码写得越多，后面越难回答一个朴素的问题：现在到底完成了什么？

GitHub 给 Copilot coding agent 的官方建议里，把“问题描述清楚、验收标准完整、改动范围明确”列为理想任务的基本条件。它也专门提醒，跨仓库重构、依赖关系复杂、涉及大量业务逻辑或安全敏感区域的任务，不适合一开始就整包交出去。

OpenAI 分享内部使用 Codex 的经验时，给过一个很具体的参考：更适合交给 Agent 的，通常是人类同事大约一小时能完成、或者改动规模在几百行左右的任务。这个数字只适用于特定团队和当时的工具能力。它提供了一个量级信号：Agent 较稳定的工作单元仍然接近一张写清楚的工程任务单，一句包办整个产品的愿望远远不够。

02

VERTICAL SLICE

不按文件数切，按“可独立验证的结果”切

“一次只改一个文件”听起来很安全，实际常常切错位置。

一个很小的功能，也可能需要同时碰到页面、接口和数据。例如给资料工具增加“保存一条链接”，页面要有输入框，接口要接收地址，数据层要把它存下来。硬按文件分成三次，前两次都没有读者能亲手验证的完整结果。

更合适的切法叫“纵向切片”。这个词不用记太专业，意思很简单：每一片都从用户动作一直走到可见结果，只做当前这片必需的部分。

还是以资料工具为例，可以这样分：

1. 输入一条链接，点击保存，列表立刻出现标题；空地址会给出明确提示。
2. 刷新页面以后，刚才保存的内容仍然存在；重复地址不会生成两条。
3. 输入关键词，只筛出标题匹配的内容；清空关键词恢复完整列表。
4. 最后再加标签、批量导入和分享，不把它们提前塞进第一步。

第一步可能改三个文件，第三步也许只改一个文件。它们的大小不由文件数决定，而由“能否独立交付一个结果”决定。

国内作者 Leo Zhou 写过一次把会议内容交给多个 AI 开发的实践。原始转写里既有已经确认的决定，也有口误、工作假设和讨论到一半的想法。直接把转写变成任务以后，需求和验收都不可靠。后来他先把可观察的成功条件固定下来，再生成可以领取的原子任务，并要求每项工作留下实际改动、执行命令和结果证据。

这个顺序可以直接拿来用：先知道怎样判定成功，再决定切几块。

03

FOUR CHECKS

用四个问题判断这一刀切得对不对

给 Agent 开工前，可以先回答四个问题。

这一段只承诺一个什么结果？

答案最好能落到一个动作和一个结果上。

“完善用户体验”太宽；“用户提交空表单时，姓名和手机号下方分别显示错误提示，已填写内容不丢失”就能直接观察。

如果一句话里连续出现“并且、同时、顺便、全部”，通常已经装进了不止一个结果。

完成它必须依赖什么？

现有页面、测试账号、接口文档、第三方服务、设计稿和测试数据，都可能是前置条件。

依赖还没准备好时，不要让 Agent 假设它们已经存在。可以先单独安排一次只读调查：确认目前有哪些文件、真实接口能做什么、缺少哪些账号或资料，再决定是否进入实现。

哪些地方允许改，哪些地方不能动？

Addy Osmani 在总结 Agent 工作流时，把范围纪律看作改动最终能否顺利审查的重要条件。他给出的要求很直白：只碰任务要求的内容，不顺手重构相邻系统，不删除还没弄懂的代码。

普通个人项目也用得上。允许改的页面和目录可以列出来；账号、支付、真实数据、部署配置和其它已经稳定的页面，则放进“不得修改”。如果 Agent 调查后发现必须越界，它应该先停下来解释原因，扩大范围的决定留给人。

怎样算通过，怎样算失败？

“页面正常”“功能可用”仍然太虚。

合格标准可以写成：从哪个状态开始，做哪几个动作，最后看到什么；还要补一条最可能失败的路线。例如保存功能除了“正常链接能保存”，还要检查空地址、重复地址和刷新后的结果。

如果一项任务只有最后总验收，中途任何一步失败都要把整包工作翻开重查，它还是太大。

04

TASK SIZE

三种尺寸，处理方式也不一样

有些任务可以直接做。

它们通常只有一个结果，现有项目里能找到相似实现，改动范围清楚，验证命令或人工操作也已经知道。比如修改一个已有页面的表单提示、给现有列表加一种排序、补一项能复现旧 Bug 的检查。

有些任务应该先计划，再一段段做。

只要出现跨多个模块、需要改变数据结构、依赖第三方服务、包含旧数据处理，或者还有几项产品决定没定，就先让 Agent 只读项目，列出依赖顺序、每段改哪些范围、每段怎样验收。国光量子的一份公开 AI 项目教程也采用了类似节奏：跨模块改动先出计划，按纵向结果逐步实现，每一步通过小验收后再进入下一步。

还有些任务不该由 Agent 自己收口。

生产支付、身份权限、不可恢复的数据迁移、线上事故处理，以及需要深厚行业判断的业务规则，都可以让 AI 帮忙调查、列风险和准备草案，但最终方案、权限开放和上线判断要留在人手里。任务切小能降低风险，不能把高风险工作自动变成低风险工作。

05

TASK BRIEF

可以直接交给 Agent 的任务单

下面这份格式不要求会写代码。它只把结果、范围和停线条件摆在同一页上。

任务结果：
[只写一个可观察结果]

当前状态：
[页面或功能现在怎样；附地址、截图、报错或相关文件]

允许修改：
[页面、目录或模块]

不得修改：
[稳定功能、真实数据、账号权限、支付、部署配置等]

验收方式：
1. [前置状态 + 操作 + 预期结果]
2. [一条失败或异常路线]
3. [需要运行的构建、测试或人工检查]

开工前：
先只读调查，说明准备改哪些文件、依赖哪些现有能力。
如果还需要未确认的产品决定、外部账号或超出范围的改动，停止实现并列出缺口。

完成后：
列出实际修改文件、每项验证结果、仍未确认的条件。
不要顺手重构或增加未要求的功能。

这张任务单仍然可能太大。判断方法很简单：如果 Agent 在开工前列出的计划里，某一步失败后不能停在原地、不能单独验证，或者必须连带重做后面所有步骤，就再切一刀。

06

HUMAN GATE

AI 负责推进，人负责切口

Agent 很适合读项目、寻找相似实现、列出依赖关系、重复运行检查，并把一个已经确定的任务推进到结果。人需要决定的是，哪些需求现在真的要做，哪一个结果值得成为这一轮的终点，什么东西绝不能被顺手改掉。

任务拆得太大，Agent 会在长上下文里混合目标；拆得太碎，人又要不停解释和拼接。合适的中间位置落在一个能够独立验收的完整小结果上，固定行数无法代替这个判断。

手里如果正好有一条准备交给 AI 的大需求，可以先不写代码。只把它改写成三到五张任务单，每张都写出唯一结果、允许范围和验证动作。能独立通过的先做，依赖不清的留在计划里，风险太高的交回人来决定。

AI 一次做多大，最终看它能不能交回来一件完整的小事——一堆彼此绑死的半成品，不算数。

ONE RESULT · ONE CHECKPOINT · ONE ROLLBACK

能独立验收的小结果，　才算一轮完整交付。

跟着做一个 · SCOPE SMALL · VERIFY CLEAR