别再凭感觉说做完了：vibe 项目的 agent 任务验收清单实战

“做完了”这句话，为什么最不可信

你把任务交给 agent，半小时后它说“已完成”。你点开一看：页面确实多了一个按钮，功能好像也能点，但你不知道它有没有真的修掉那个 bug，也不知道它顺手改坏了什么别的东西。你问它“你确定吗”，它会非常自信地再说一遍“已完成”。这不是 agent 在撒谎，而是你们两个人对“完成”的定义根本不一样：你以为的完成是“用户的问题解决了，而且没有引入新问题”，它理解的完成是“代码写完了，而且能跑起来”。定义不一样，验收就一定会吵架。

这篇指南要解决的就是这个定义问题：在任务开始之前，先把“什么算做完”写成一张任何人都能照着打勾的验收清单。任务结束时，不看 agent 的自我评价，只看清单上的每一项有没有拿出证据、够不够通过线。清单通过，任务才算完成；清单没通过，退回重做，不争论、不凭感觉。

先划清边界，因为站内已经有几篇容易混淆的邻近指南。回归验证基线六层法讲的是“改完之后怎么系统地回归验证”，面向的是已经发生的变更；本篇讲的是“动手之前先定好验收标准”，面向的是任务开始的那一刻。AI 代码评审二次验证讲的是“怎么复核 AI 评审的结论”，本篇不评审别人的评审结论，只验收你自己的任务。agent 交接包七件套讲的是“人与人、轮次与轮次之间怎么交接”，本篇讲的是“单个任务怎么判定完成”。agent 改坏代码后的冻结分级抢救讲的是“已经改坏了怎么抢救”，本篇讲的是“怎么在改坏之前就拦住它”。agent 花费硬上限讲的是“花多少钱就停手”，本篇不管钱，只管“做完没有”。AI 功能降级与兜底策略讲的是“功能出问题时怎么降级保底”，本篇讲的是“正常任务的完成标准”。agent 数据访问护栏、agent 代操作权限契约讲的是“agent 能碰什么、不能碰什么”，本篇默认权限已经谈好，只谈“做出来的东西合不合格”。上线前 60 分钟手册讲的是“发布当天的执行流程”，发布说明写作指南讲的是“怎么向用户交代更新”，本篇都不讲：验收清单用在每一次任务结束时，而不是只用在发布那一天。

核心方法：验收先行五步法

验收清单不是任务做完后补写的总结，而是任务开始前就写好的合同。顺序不能反：先写清单，再让 agent 动手。五步如下。

第一步：写用户看得见的结果。不要写“优化登录模块”这种只有开发者看得懂的话，要写“用户在忘记密码时，能在 60 秒内收到重置邮件并完成重置”。结果必须用用户的语言写，因为最终为结果买单的是用户，不是代码。如果一句话里没有主语、没有动作、没有可观察的现象，这句话就不合格，重写。

第二步：把结果拆成可验证项。一个结果通常对应三到六个验收项。拆分的标准是：每一项都能独立回答“是或不是”，不能出现“基本完成”“大体正常”这种无法判定的词。比如“用户能完成重置”可以拆成四项：重置邮件能发出去；重置链接在有效期内能打开；过期链接会明确报错而不是白屏；重置成功后旧密码立即失效。每一项都是是非题，不是论述题。

第三步：给每一项配证据。证据就是任务结束时 agent 必须交出来的东西，具体有哪五种、每种长什么样，下一节会讲清楚。没有证据的验收项等于没有验收项：agent 说“我测过了”不算证据，贴出命令输出、接口返回或操作录屏才算。

第四步：给每一项定通过线。通过线是数字，不是形容词。“页面加载变快了”不是通过线，“列表页在 4G 弱网模拟下 3 秒内出现首屏内容”才是。“bug 修掉了”不是通过线，“连续输入 20 组历史问题数据，复现率为 0，且 5 组边界数据不报错”才是。通过线越具体，验收时的争论就越少。

第五步：写退回规则。提前写好：哪几项不过就整体退回，哪几项不过可以带问题通过、但必须记入待办并注明下次任务。没有退回规则的清单会在验收时变成讨价还价：agent 会说“就差这一项，下次再说吧”，而你会在压力之下点头。规则写在前面，验收时只执行，不谈判。

五种证据：每种都要有“合格长什么样”

证据分五种，任务不同，证据组合不同，但“合格长什么样”必须事先写清，否则 agent 交上来的证据你还是没法判断。

第一种是命令输出：测试命令、构建命令、检查脚本的完整输出。合格的样子是：命令本身可见、退出码可见、关键行没有被截断。只贴“测试通过”四个字不合格，只贴最后三行也不合格，因为你不知道它到底跑了哪些用例、有没有跳过失败项。

第二种是页面证据：改动前后同一页面、同一操作路径的截图或录屏。合格的样子是：改动前和改动后成对出现，操作路径写清楚（从哪个入口进、点了什么、填了什么），异常状态也要有（比如空数据、超长标题、网络失败时的样子）。只有“成功状态”的截图不合格，因为成功状态最容易伪装。

第三种是接口返回：关键接口的请求与返回示例。合格的样子是：请求参数可见、返回体关键字段可见、错误情况的返回也要有一例（比如未登录、参数缺失、额度用完）。只给成功返回不合格，因为真实用户一定会撞上错误情况。

第四种是数据证据：数据库或后台里真实存在的一行数据。合格的样子是：能指出是哪条记录、关键字段值是多少、关联关系对不对。比如“订单状态流转”任务，证据应该是某一笔测试订单从下单到完成每个状态的时间戳，而不是一句“流程跑通了”。

第五种是人工走查记录：你本人或另一位协作者按清单走一遍的记录。合格的样子是：写清谁在什么时间、用什么账号、走了哪条路径、结果是什么。人工走查不是“感觉一下”，而是按清单逐项打勾，勾完签字。关键任务必须有这一项，因为自动化证据只能证明“机器认为对了”，人工走查才能证明“人用起来对了”。

验收矩阵模板：直接抄

把五步法落到一张表上，就是验收矩阵。每个任务一张表，放在任务单的最前面，agent 动手前你先签字。模板如下：

任务名称：________________ 提出人：________________ 日期：________________

用户看得见的结果（一句话）：________________________________________________

验收项一：________________ 证据类型：________________ 通过线：________________ 实际结果：________________ 结论：通过 / 带问题通过 / 退回

验收项二：________________ 证据类型：________________ 通过线：________________ 实际结果：________________ 结论：通过 / 带问题通过 / 退回

验收项三：________________ 证据类型：________________ 通过线：________________ 实际结果：________________ 结论：通过 / 带问题通过 / 退回

验收项四：________________ 证据类型：________________ 通过线：________________ 实际结果：________________ 结论：通过 / 带问题通过 / 退回

退回规则：以下验收项不过则整体退回：________________；以下验收项不过可带问题通过，但必须记入待办：________________。

验收人签字：________________ 验收时间：________________

这张表看起来笨拙，但它的笨拙正是价值所在：它把“你觉得”和“我觉得”都赶出去了，只剩下“证据说”和“通过线说”。一人团队尤其需要这张表，因为你没有同事帮你复核，表就是你的第二双眼睛。

三个示例：修 bug、加功能、改样式各一张

示例一：修 bug。任务是“修复优惠券叠加计算错误”。用户看得见的结果是：用户结算时，优惠券按规则叠加后，实付金额与手工计算一致。验收项包括：复现用例 20 组全部通过（证据是测试命令输出，通过线是 20 组零失败）；边界用例 5 组（券过期、券已用完、金额刚好等于门槛）不报错且金额正确（证据是接口返回）；旧订单不受影响（证据是数据证据，抽查 10 笔历史订单金额不变）；结算页展示的明细与实付一致（证据是页面截图，改动前后成对）。退回规则是：复现用例有一组失败就整体退回；页面展示问题可以带问题通过，但必须当天记入待办。

示例二：加功能。任务是“给文章列表加收藏功能”。用户看得见的结果是：登录用户能收藏文章，下次打开时在收藏夹里找到它，退出登录后收藏不丢失。验收项包括：收藏与取消收藏即时生效（证据是页面录屏）；刷新后收藏状态还在（证据是接口返回与数据证据）；未登录用户点击收藏会引导登录而不是静默失败（证据是页面截图，含错误状态）；收藏夹为空时有明确文案而不是空白页（证据是页面截图）。退回规则是：数据丢失类问题整体退回；文案问题可以带问题通过。

示例三：改样式。任务是“把首页标题在手机上改小一号”。用户看得见的结果是：手机上首页标题不再换行溢出，阅读顺序不变。验收项包括：三档常见手机宽度（360、390、430 像素）下标题均不溢出（证据是页面截图，每档一张）；桌面端标题样式不变（证据是改动前后成对截图）；长标题、短标题、无副标题三种情况均正常（证据是页面截图）。退回规则是：任一宽度溢出就退回；因为样式任务的通过线本身就是“全部宽度都正常”，没有带问题通过的余地。

三个示例的共同点是：验收项都不超过六项，证据都具体，通过线都有数字或明确条件，退回规则都写在前面。你可以直接把示例里的句式换成你自己的任务内容，不用重新发明格式。

验收执行流程：自验、复验、结论三态

清单写好后，执行分三步。第一步是 agent 自验：agent 按清单逐项交证据，自己先打一遍勾。自验的意义不是信任 agent，而是逼它在交给你之前先过一遍清单：很多低级问题在自验时就会被它自己发现，你就不用再当第一道防线。

第二步是你复验。复验不用逐项重做，那样太贵。用抽查法：关键项（涉及钱、数据、登录、删除的项）全量复验，非关键项抽查三分之一。抽查时重点看两类东西：一是证据是不是真的对应这项任务（有没有拿别的任务的截图充数），二是证据有没有被截断、美化或只挑成功部分。

第三步是下结论。结论只有三种：通过、带问题通过、退回。带问题通过必须同时满足三个条件：问题不涉及钱、数据丢失、安全；问题已经记入待办并注明下次任务；你本人签字确认。三个条件缺一个，就只能是退回。没有第四种结论，尤其没有“差不多通过了”这种结论：结论一旦含糊，下次验收就会更含糊。

退回话术模板：不吵架，只对清单

退回最容易变成争论，因为 agent（以及被 agent 带偏的你自己）会把退回听成否定。话术的作用就是把争论对象从“人”换成“清单”。三种情况各给一句模板：

证据缺失时说：“验收项二要求贴出完整命令输出，目前只有结论没有输出，请补交后重新验收。”不说“你没认真测”，只说“清单要求什么、目前缺什么”。

通过线未达时说：“通过线是 20 组零失败，目前 20 组里有 2 组失败，请修复后重新跑 20 组。”不说“你怎么连这个都做不对”，只说“通过线是多少、目前是多少”。

范围蔓延时说：“本次任务的验收项里没有改动登录页，登录页的变化请单独开任务、单独验收，本次先回滚这一处。”范围蔓延是最常见的“顺手改坏”，处理原则是：不在本次验收里顺便接受它，单独开任务、单独列清单。

还有三句禁止说的话：第一句是“差不多就行了”，它会把通过线变成橡皮筋；第二句是“你看着办”，它会把清单变成废纸；第三句是“下次再补证据”，证据一旦允许后补，就永远不会补。清单的权威来自每一次都不打折执行，打折一次，后面每一次都会有人要求打折。

七条反模式：清单写了也白写的七种死法

第一，验收项写成形容词：“提升体验”“优化性能”“更加稳定”都不能验收，改成数字和条件才能用。

第二，证据只写成功状态：不写错误状态、不写边界状态的清单，等于只验收了一半的世界。

第三，清单写在任务做完之后：事后补的清单一定会按已做出来的东西去写，通过率永远是百分之百，等于没验收。

第四，清单只有 agent 自己签字：没有你的复验签字，清单就是自我证明，约束力为零。

第五，带问题通过不记待办：口头说的“下次再说”一定会被遗忘，带问题通过的问题必须当天落进待办清单。

第六，清单越写越长：超过八项的清单没人愿意执行，拆成两个任务、两张清单，比一张超长清单有效。

第七，用清单代替沟通：清单管的是“做完没有”，不管“做得对不对方向”。方向错了，清单全过也是错的：方向问题要在任务开始前谈，不在验收时谈。

一人团队落地：一周就能跑起来的节奏

第一周不用搞系统，只做三件事。第一，把验收矩阵模板存成一个固定文件，每个新任务复制一份放在任务单顶部，agent 的第一条指令就是“先读验收矩阵，再动手”。第二，给历史任务补一次清单：挑最近三个已完成的任务，按本篇方法反推它们的验收项，你会立刻发现至少有一个任务其实是不合格的——这个发现本身就是清单的价值证明。第三，定一条自己的铁律：没有验收矩阵的任务不开工，没有复验签字的任务不上线。铁律坚持三周，就会变成习惯；习惯之后，清单的成本会降到每次任务十分钟以内，而它帮你拦住的返工，远不止十分钟。

最后回到开头那句话：agent 说“做完了”的时候，你不需要怀疑它，也不需要相信它。你只需要打开清单，一项一项问：证据呢？通过线达到了吗？退回规则触发了吗？三个问题问完，结论自己就出来了。验收清单不是对 agent 的不信任，而是把信任从“感觉”搬到“证据”上——而证据，是唯一不会在半夜改口的东西。

附：验收清单总表（每次任务前逐项打勾）

结果是不是用用户语言写的一句话？验收项是不是三到六项、每项都是是非题？每项有没有配证据类型？每项有没有数字化的通过线？退回规则是不是写在前面？关键项是不是全量复验、非关键项是不是抽查了三分之一？结论是不是三种之一、有没有签字？带问题通过的问题是不是当天记入了待办？八项全是“是”，这张清单才能用；有一项是“否”，先补清单，再开工。