商城已经接入了 AI 助手。让它查一件商品、修改一个字段，通常不难看出有没有成功：打开商品详情，核对一下就知道了。
当任务变成一批商品，问题就不一样了。
把这20件准备好的商品上架。需要审批的按原流程提交，有问题的列出来，已经上架的不用重复操作。
过了一会儿，助手回复：“已处理，大部分商品上架成功。”
运营人员接下来还是要打开后台，一件件查：究竟成功了几件？哪几件没动？有没有漏掉某一页？再次说“继续处理”，会不会把已经完成的商品又操作一遍？
批量任务的交付，既要证明完成了什么，也要交代清单里的每一项去了哪里。
本文用一批合成商品说明这个问题。示例假设商城已经开放商品查询、上架和所需的审批能力；这些是接入设计与验收示例，不是客户运行记录，也不假设任何工具能绕过商城原有规则。
一、先确定“这20件”到底是哪20件
“上架这20件商品”和“把符合条件的商品全部上架”，实际上是两种不同的请求。
第一种有明确清单。第二种需要先查询，再确定范围。
假设运营人员说：“把夏季配件分类里已经审核通过的草稿商品上架。”助手调用商品列表接口，第一页返回20条，并不意味着商城里只有这20条符合条件。
这时需要看业务接口的真实含义：有没有下一页？总数是否准确？过滤条件是否真的生效？返回的是商品，还是商品规格？
如果接口只提供有上限的结果，就应说明当前只拿到了这一批，不能直接宣布“已找到全部商品”。翻页过程中数据还可能变化；要对已取得的对象去重，遇到不能确认完整性的情况，就把本次范围限定为已明确列出的清单。
正式执行前，至少要确认这些信息：
| 需要确认的内容 | 在商城场景里的含义 |
|---|---|
| 目标系统与授权 | 使用哪一个商城、哪一份已选授权 |
| 商品清单 | 本次处理的具体商品标识，必要时包括规格 |
| 动作 | 上架商品，还是仅提交上架审核 |
| 条件 | 商品需要满足哪些既有上架规则 |
| 例外 | 已经上架的跳过，资料不全的列出原因 |
清单可以来自用户选择，也可以来自一次已核对范围的查询。并非每批都必须额外加一次确认弹窗：用户已经明确给出对象和动作、原规则也允许直接执行时，可以继续。范围模糊、数量超出预期或命中原审批规则时，再按对应规则确认。
清单一旦确定，后续结果就应按这份清单核对。不能在执行中偷偷换成“当前最新搜索到的一批”，然后还把两次结果算作同一项任务。
二、把完成单位定成“一个商品的上架目标”
接入团队很容易拿工具调用次数衡量进度。
但查商品详情、检查上架条件、发起上架、读取结果，可能是四次调用，实际只完成了一件商品。反过来，一个批量接口也可能一次接收20件商品，却只成功了其中12件。
所以，这个任务的完成单位应当是“某个明确商品已经完成本次要求的上架”，而不是“调用过一次工具”。
每一项至少保留：商品身份、要做的动作、当前结果、支持这个结果的依据。有真实调用时，再关联它的原调用记录和审批记录。
比如：
- C-101：本次上架完成，可以找到原执行结果。
- C-102：上架申请已提交，仍在等原业务审批。
- C-103：开始处理时已是上架状态，本次跳过，没有重复执行。
这三件商品都已经得到说明，但只有第一件可以计入“本次新完成上架”。
第二件的申请提交成功，不等于商品上架成功。第三件满足用户希望看到的状态，也不代表这次 AI 改变了它。
当统计单位明确以后，模型就不应再把“查过详情”“申请已提交”“本来就上架了”混在一个成功数字里。
三、20件清单，最终也必须交代20件
假设本次确认的20件商品，最终得到下面这份结果：
| 当前状态 | 数量 | 用户能据此知道什么 |
|---|---|---|
| 本次上架完成 | 10 | 有原执行结果，可核对商品状态 |
| 待审批 | 3 | 尚未上架，等待原业务审批 |
| 明确失败 | 2 | 商城明确拒绝，例如主图或规格资料不完整 |
| 结果待确认 | 1 | 请求已经尝试发送，暂时无法确定最终结果 |
| 已跳过 | 2 | 开始处理时已经上架，本次没有重复操作 |
| 尚未尝试上架 | 2 | 本次执行在处理到这两件之前结束 |
| 合计 | 20 | 与原始清单一致 |
这里的数量是合成示例，不是一次实际执行的统计。
这份表有两个作用：先让运营人员看清整体进度，再让开发者检查有没有丢项。每个商品在当前汇总里只进入一个最终状态；例如“待审批”的商品不能同时算进“已完成”。
表格下面还应能展开具体商品及原因。只给“失败2件”，却没有告诉用户是哪两件，仍然无法交接工作。
“尚未尝试”尤其容易被遗漏。执行被取消、预算耗尽或会话结束，都可能留下还没走到上架步骤的商品。它们既不是成功，也不是业务拒绝。如果汇总只统计已经产生调用的对象，这些商品就会从结果里消失。
一个更清楚的回复可以是：
本次清单共20件：10件上架完成，3件待审批，2件因资料问题被拒绝，1件结果待确认，2件原本已上架而跳过，另有2件尚未尝试上架。
完成项、待办项及原因已按商品列出。本次任务尚未全部完成。
这比一句“大部分处理成功”更容易判断，也方便下一位运营人员接手。
四、“继续处理”需要先分清是哪几项
用户看到结果后，很可能只说一句：“那剩下的继续。”
这时不能把原清单里的20件商品重新上架一遍。不同状态需要不同的下一步：
- 已经完成或已跳过的：保留原结果，不重复发起相同操作。
- 待审批的：继续查看原审批和原调用，不能再提交一份相同申请。
- 明确失败的：说明需要补哪些资料；问题解决后，按原规则重新核对对象和条件，决定是否发起新的操作。
- 结果待确认的：先查询、恢复或人工核对原调用结果，不能因为没有收到成功回包，就认定业务没有执行。
- 尚未尝试的：重新确认当前授权、商品状态和剩余范围，再决定继续处理。
尤其要区别“重新发现工具”和“重新执行业务”。工具定义没有加载，可以按当前目标重新寻找；上架请求已经发出但结果未知，则应围绕原执行记录核对。换一个工具名称、换一份授权，或者改用浏览器点一次，都不能消除原请求可能已生效的事实。
如果系统支持按原调用标识查询结果，就沿用原标识。若恢复能力不能跨进程保留，重开客户端也不能假装自动接上了全部待办；应明确说明恢复边界，并由后台记录或人工核对接续。
清单让人知道“还剩什么”，可靠的调用记录才让系统知道“能怎样继续”。两者需要一起设计。
五、查后台时，要核对状态，也要核对这次操作
看到商品已经上架，只能说明它现在处于上架状态。
它可能是这次 AI 操作完成的，也可能在任务开始前就已上架，或者被另一位运营人员刚刚处理过。因此，“现在上架了”和“本次成功上架”需要不同的证据。
验收时，可以把三份信息放在一起看：
- 原始清单：本次究竟要处理哪些商品。
- 执行记录：用了哪份授权，尝试了什么动作，返回什么结果。
- 商城当前状态：哪些商品现在已经上架，哪些仍在草稿或审核中。
如果三者对不上，就保留差异。例如，原执行返回成功，但商品后来又被下架，可以说明“本次上架曾成功，当前状态已变化”，并提供后续核对入口。
这张对账表适合由业务系统或客户端根据真实记录生成，助手再把它解释给用户。不要只依靠模型回忆前面聊过什么来计算完成数量。查询工具本身也要明确分页、筛选、商品与规格层级，否则再漂亮的汇总也可能从一份不完整清单开始。
六、第一次先用三件测试商品验收
不必一开始就放几十件真实商品进去。
先在测试环境准备三件合成商品：
- 一件符合条件，允许直接上架。
- 一件明确不满足业务条件，应返回具体原因。
- 一件按既有规则需要审批，应保持待审批。
让助手处理这三件，再核对它有没有做到：清单仍是原来的三件；每件都有结果；完成数量准确；被拒绝和待审批的商品没有被说成成功；商城后台与原执行记录能够对应。
随后再增加一个分页场景，确认“只拿到第一页”不会被写成“全部完成”。最后，在隔离环境模拟确认回包丢失，检查系统是否只核对原调用，没有重复写入。
批量接口如果提供逐项返回，应按逐项结果汇总。只有一个整体响应、无法说明部分成功范围的接口，需要先补足结果查询或业务记录，不能由模型猜出每个商品的状态。
这几项验收通过，批量任务才有一个可以交付的结果，而不只是一次看上去流畅的对话。
