批量任务结束后，最重要的页面不是成功数量，而是「我的任务」留下的执行记录。Ainnc 会保留批次、账号、平台、设备、状态和执行时间，让团队能从结果回到任务条件。正确使用方式不是看到失败就点重跑，而是先确认哪些账号真的失败、为什么失败以及修复后该重跑谁。
先把结果分成三类
成功表示任务记录完成，但重要发布仍应抽查公开页面和内容；失败表示系统或平台返回了明确终止状态；待确认则包括连接中断、页面未核验或结果尚不清楚。把待确认直接并入失败，可能让已经上线的账号产生重复内容。
| 状态 | 第一项检查 | 是否立即重跑 |
|---|---|---|
| 成功 | 抽查账号、内容和公开结果 | 否 |
| 失败 | 保存错误、阶段与关联条件 | 否，先分类 |
| 待确认 | 核对真实页面和账号状态 | 否 |
例如 20 个账号中有 13 个成功、5 个失败、2 个待确认时，新的任务对象最多先从确认失败的 5 个中产生；那 2 个未知账号必须先查清真实状态。这个场景与数量只是方法演示。
从任务记录比较失败共同点
在「我的任务」中记录原任务 ID、账号、平台、设备、状态和时间，再补充素材版本与参数。例如 8 个失败账号中有 6 个共享同一素材时，就应优先核对素材条件。Ainnc 的一体化价值就在这里：结果不是孤立红点，而是可以沿着账号、环境和素材继续查找。
如果所有失败账号共享同一素材，而不同设备上的其他素材正常，先检查素材和参数；如果失败集中在刚变更环境的一组账号，就优先核对设备与代理关系。完整的分层方法可参考批量发布部分失败排查。
判断错误是否适合重跑
短暂连接中断、任务服务明确返回可恢复提示，才可能适合有限重试；账号权限变化、素材被拒、参数不完整或原因未知，都不应自动重复。团队需要根据实际错误和平台当前要求判断，不能使用一个通用“最多重试三次”的规则覆盖所有场景。
自动重试为什么会放大问题，可阅读自动任务重试风险。Ainnc 提供记录和任务入口，但是否重试、改变什么参数以及何时停止，仍是运营负责人需要做出的决定。
修复后只创建最小验证任务
先修复已经获得证据支持的条件，例如替换错误素材、补齐参数或恢复必要权限。然后从失败组选择 1—2 个低风险账号创建新任务，其他条件尽量保持不变。一次同时更换账号、素材、环境和时间，即使成功也无法说明原因。
新任务备注应引用原任务 ID、失败原因、修复内容和验证目标。这样「我的任务」中会保留修复前后的两条记录，团队可以比较条件和结果，而不是让原失败状态被新一次执行覆盖。
逐批恢复并设置停止条件
最小验证成功后，再把剩余确认失败的账号分批恢复。例如先验证 2 个账号，再处理其余 6 个；每一批都检查页面、状态和是否出现重复发布。若同类错误再次出现，立即停止扩大，并回到原因判断。批量任务停止条件的设计可以参考发布暂停规则。
已成功账号不应进入重跑组，待确认账号也不能为了方便被直接加入。分组时最好由另一位成员核对账号数量和构成，尤其是客户活动或高价值账号，避免修复任务本身制造第二次事故。
用失败记录改进下一次任务
处理完成后，把原因、修复、验证结果和新的预防检查写回团队流程。例如某次失败来自旧素材，下一次就在任务提交前增加版本核对；若来自环境变更，就让变更账号先进入独立验证组。日志只有改变下一次动作，才真正产生价值。
Ainnc「我的任务」解决的是批量执行后的可追踪性，不承诺所有任务都会成功，也不会替运营判断平台规则。一个失败批次是否处理完成，不看最终状态是否全部变绿，而看团队能否说明失败发生在哪些账号、修复改变了什么、下一次为什么不再重复同样错误。
常见问题
Ainnc 任务显示失败后可以直接重跑吗？
不建议直接重跑。先确认公开结果、保存失败条件并判断原因是否可恢复；权限、素材或未知错误都需要先处理。
为什么重跑要创建新任务而不是覆盖原记录？
新任务可以保留修复前后的条件与结果，避免原始错误被覆盖，也便于团队判断究竟是哪项变化解决了问题。