第一次用 WorkSwarm，建议先跑一个半天内能验收、失败也能回退的小任务，不要一上来就把跨系统、长链路、要写正式数据的任务交出去。重点不是看 WorkSwarm 能不能全自动，而是看三件事：哪些步骤它自己完成了，哪些步骤需要你补信息，哪些节点会停下来要求确认。把这三点记录下来，再改成模板，第二次同类任务就有对照。

首次试跑 WorkSwarm，适合选一个可回退、能人工验收的小任务，跑一遍并记录自动完成段、人工补充段和确认时机。判断依据不要看像不像自动，而要看日志或页面行为里是否每一步都能找到归属；涉及写外部系统、发消息、改数据时，先停在人工确认点。若任务目标、验收标准或回退方式说不清，先不跑，回去拆任务。

选一个半天内能验收的小任务

试跑范围要控制在可回退的规模内。通常可以先选一个输入固定、输出格式明确、不直接触碰正式数据的任务，例如整理一份内部草稿、把若干条文本归类后输出到临时目录。创建任务前，先把任务目标、判定完成的依据、出错时的影响范围写清楚，这三项缺一项，后面记录确认次数就会失去参照。

任务目标：把输入文件中的记录按给定规则归类，输出到临时目录
完成依据：输出文件条数与输入记录条数一致，每行包含原文摘要和分类
影响范围：只写临时目录，不调用外部发送接口，不改原始输入文件
回退方式：删除输出文件；原始输入和正式系统不受影响

这里的判定依据要能被人工验收，不要写成效果更好或准确率更高。影响范围则用来决定确认点放在哪里：如果任务只读不写，确认可以少一些；如果要写回外部系统，建议在写入前保留确认点。

记录它自己完成的步骤和需要你补的步骤

跑第一次时，逐步骤标注归属。归属可以分三类：WorkSwarm 自动完成、你人工补做、需要你确认后才继续。每标一步，都写明补做时缺少的是什么信息，例如缺少字段口径、缺少目标路径、缺少权限、缺少业务规则。不要只写某一步失败了，要写到能复现问题的那一层。

如果 WorkSwarm 提供运行日志，优先按日志时间线对照步骤；如果只有页面行为，就在每一步操作后立刻记下页面显示了什么。自动完成段通常表现为连续执行且中间无等待；人工补充段通常出现在信息不足、权限不足或规则冲突的位置。

统计这次任务里被叫去确认的次数和时机

确认次数不是越少越好，关键是确认发生在什么步骤。建议每次确认都记四件事：发生在哪一步、WorkSwarm 当时给出了什么、你需要补充什么、确认后任务是否继续。这样能看出确认是集中在开头信息收集，还是卡在外部写入前，还是散落在中间规则判断里。

常见确认时机包括：缺少必填参数、权限不足、写入外部系统前、规则冲突、输出格式不确定。如果同一类确认重复出现，说明模板里缺少默认约定；如果确认集中在外部写入前，属于风险控制点，不建议为了减少次数而直接去掉。

把步骤清单改成下次可复用的模板

第一次跑完后，把步骤清单改成模板。模板里固定三样东西：任务描述怎么写、确认点放在哪里、产出按什么标准验收。任务描述要写到输入、操作范围、输出位置和回退动作；确认点要绑定到具体步骤，不要只写需要确认；验收标准要能人工逐项勾选。

任务名称：
输入位置：
操作范围（可写 / 不可写）：
任务描述模板：
  1. 读取【输入】并校验【字段】；
  2. 按【规则】生成【中间产物】；
  3. 在【确认点】停下，等待人工确认【内容】；
  4. 确认后输出【最终产物】到【位置】。
自动完成段预期：
人工补充段预期：
确认点位置：
  - 确认点 1：
  - 确认点 2：
验收标准：
回退动作：

模板不要写得太满，留出说明业务口径的位置。可复用的部分尽量是步骤顺序、确认点位置和验收标准；每次变化的输入路径、接收方和规则参数，单独列成待填项。

第二次跑同类任务做对比

第二次跑同类任务时，用同一张模板记录，再和第一次做对比。重点看三个差异：确认次数有没有变化、补做步骤数有没有变化、总耗时有没有变化。确认次数没降但确认点前移了，通常也算有效改善，因为问题更早暴露；补做步骤数没降，则要看是不是同一类信息仍然缺失。

对比时注意边界：如果第二次换了输入规模、换了外部服务状态或换了验收人，总耗时差异不能直接归因于模板。只有任务类型、输入规模和验收标准大体一致时，确认次数和补做步骤数的对比才更有参考价值。