分工扯不清，多数不是态度问题，而是开工前没人把“做到什么算完成”写成两栏。左栏写 EvoX 要执行的动作，右栏写你验收时能看到的证据，两栏对齐同一件事、各写一行，然后再开工。少了这一步，执行方按自己的理解收尾，你按脑子里的印象验收，返工只是早晚。
适用场景：把一段可自动化的工作交给 EvoX 执行，但你不确定哪些环节必须自己盯。操作动作：开工前拆两栏——左栏是执行动作，右栏是对应的可检查证据，一行对一行；同时写下一条完成定义，包含产出物和通过条件。验证方式：每完成一行，右栏必须能在文件、日志或状态页里指到具体位置，指不到就不算完成。风险边界：验收标准只能约束你观察得到的部分；涉及外部系统的副作用，要留人工确认点，不能默认自动放行。
把目标改写成可验收的完成定义
写完成定义时，最容易混的是动作和结果。左栏可以写“运行导入脚本处理 input 目录”，右栏不能只写“导入完成”，而要写“output/ 下生成同名结果文件，行数与输入一致，可用 wc -l 核对”。动作属于执行方，结果和证据属于验收方，两栏分开写，才好在出问题时判断该改哪一栏。
一条能直接用的完成定义骨架，可以先按下面格式落到任务描述里，把占位内容换成本次真实对象：
目标：把 X 从 A 状态推进到 B 状态
产出物：
- 位置：具体路径或页面入口
- 形态：文件 / 表记录 / 状态字段
通过条件（全部满足才算完成）：
- 命令检查：执行的命令 + 期望输出形态
- 抽样检查：抽取若干条记录，字段非空且取值在约定范围内
- 边界声明：不覆盖哪些数据、不动哪些目录
归属约定：
- 输出不符：执行方修
- 需求含糊：提出方澄清后再跑通过条件要写成“可执行”的，不要写成“质量良好”“基本正确”这类无法判断的表述。凡是没法用命令、日志或页面行为验证的条目，要么删掉，要么把它降级成人工检查点，而不是留在完成定义里当摆设。
列出执行过程中会产生哪些中间产物
中间产物的作用只有一个：出错时能定位到哪一步、哪一批数据，不是拿来当验收结论的。开工前把这些位置写清楚，验收时你才知道往哪里看。
| 中间产物 | 说明 | 在哪里查看 |
|---|---|---|
| 输入快照 | 本次任务实际读到的原始输入 | 任务工作目录下的输入目录，或配置里指定的临时路径 |
| 执行日志 | 标准输出和错误输出的重定向文件 | 工作目录下的 run.log，或平台运行详情页的日志面板 |
| 状态变化 | 任务从待运行到运行中再到成功或失败的流转 | 任务列表页的状态列，或状态查询接口返回的状态字段 |
| 变更清单 | 本次改动了哪些文件或记录 | git status / git diff，或数据表的更新时间字段 |
| 重试与跳过记录 | 哪些条目被重试、哪些被跳过 | 日志里的关键词检索，按行号定位 |
验收只看产出物和通过条件，中间产物用来解释“为什么没通过”。如果你的任务连日志都不落盘，那第一步是把日志打开，再谈验收标准，否则检查点只能靠猜。
设人工检查点：什么时候必须停下来确认
人工检查点不是每步都停，而是只在错误会被放大的地方停。判断依据通常是三条：动作不可逆、有外部副作用、失败会成批出现。满足任意一条，就停下来确认一次再放行。
| 触发条件 | 确认内容 | 不通过时的处理 |
|---|---|---|
| 步骤要删除或覆盖已有文件、数据 | 备份是否已存在，覆盖范围是否只限本次目标 | 停止执行，先恢复或补齐备份，把范围写窄后重跑 |
| 步骤会对外部系统产生副作用，如发通知、写外部库 | 当前指向测试还是正式对象，参数里的目标标识是否正确 | 拦截该步，改配置或关掉开关，确认后再放行 |
| 同一任务反复重试或跳过大量条目 | 是输入格式问题，还是执行逻辑问题 | 不让它继续自动重试，取一条样本手工跑通再回到批量 |
| 产出物进入抽样检查环节 | 抽到的记录字段是否完整，取值是否符合约定 | 判定本次不通过，退回执行方，并把现象记进偏差清单 |
| 任务耗时或产出规模明显偏离预估 | 是否卡在循环，是否重复处理同一批输入 | 终止任务，看日志最后一条正常记录，从断点续跑 |
表格里的“明显偏离”“大量”这类词，开工前最好换成你能观测的判据，比如日志里出现连续报错、同一条记录被写两次、单批处理条数远高于预期区间。判据越具体，检查点越不需要临场拍脑袋。
跑一次后按偏差更新验收标准
第一遍跑完，验收标准一定会有对不上的地方，这很正常，关键是把它记下来并改掉，而不是每次靠人回忆。偏差记录建议单独一行一条，写清现象、原标准和修订后的条目。
| 偏差现象 | 原标准 | 修订后的条目 |
|---|---|---|
| 日志里出现跳过记录，但没说能不能跳过 | 最终文件生成即通过 | 跳过条目需逐条可解释，无法解释的退回 |
| 文件存在但编码不对，下游读不了 | 只检查文件是否存在 | 增加一条：文件可被目标程序直接读取，编码符合约定 |
| 重试次数偏多，最终仍成功 | 只看最终状态 | 重试次数需在日志中可查，超出开工前设定的上限要在任务备注里说明原因 |
| 抽样只抽了一条，恰好是好的 | 随机抽一条检查 | 改为按固定规则抽样，覆盖首尾和中间若干条 |
每轮修订只改真正出现过的偏差，不要凭想象往里加条目，标准越堆越厚反而没人执行。改完的标准和两栏表放同一处，下次开工先看它，再让执行方动手。