在 MineExplorer 里判断分钟级任务“算不算完成”，通常不由主观感觉决定，而由三件事共同决定：任务说明里写的成功条件、这次尝试的执行轨迹、以及你统计时采用的判定口径。建议的判定顺序是：先确认成功条件写在哪里，例如任务描述、配置阈值、页面状态还是日志中的结束事件；再看这一次是首轮通过还是重试后通过；最后把只做了一半的执行单独归类。重试本身不会让成绩增加，它改变的是这次尝试的触发原因，不改变成功条件的标准。

适用场景：分钟级任务批量跑完，需要对账、汇报进度或判断是否要再补跑时。操作动作：把“成功条件来源、每次尝试的触发原因、部分完成如何归属”写成固定字段，再统计结果。验证方式：随机抽一条记录，按字段回放日志和页面状态，看记录结论与实际是否一致。风险边界：不同任务的判定字段可能不同；找不到明确条件时应标注为假设，不要当成已确认的判定口径对外使用。

先找到任务的成功条件写在哪里

分钟级任务的“完成”通常有两层含义：执行层结束，即进程退出或页面进入结束态；业务层成功，即产出数量、目标字段或校验结果满足要求。这两层不一致，就是“跑完了但不算通过”最常见的来源。

成功条件通常出现在以下几处，建议按顺序检查：任务说明或描述文本里的验收描述；任务配置里的阈值、目标数量、超时时间；结果页面的状态标签，例如完成、失败、部分完成；执行日志里的结束事件与汇总行；任务返回值，或产出文件、记录条数。如果几处说法冲突，以更接近业务结果的那一处为准，并把冲突点一并记录。

找不到明确条件时，不要凭感觉认定通过。可以先写下自己的假设，标注“假设/待确认”，附上依据和核对人，之后再用页面状态或产出核对一次。例如把假设放在执行记录的开头配置里：

assumption:
  task_id: mt-xxx
  assumed_success_condition: "日志出现 summary 汇总行，且产出条数大于 0"
  evidence: "logs/run-<id>.log 末尾 summary 行"
  status: 待确认
  verify_by: 页面状态标签 / 产出条数

这样做的用处是：假设被验证后可以直接升级为口径，被推翻时也能追溯到当时依据的是哪条日志，而不是事后凭印象改结论。

每次重试单独记一条并写清触发原因

重试是否计入完成，取决于你怎么记录。把重试合并进原记录，等于把两次尝试压成一条，之后便分不清是首轮通过还是补救后才通过，也无法解释通过率为什么波动。建议每次尝试单独一行，用同一个 task_id 串起来，用 attempt_no 递增。

重试记录建议包含这些字段，并按规则填写：task_id（原任务标识，重试不改）；attempt_no（从 1 开始递增）；start_time 和 end_time（这次尝试自己的时间）；trigger_reason（固定前缀区分，例如 env:、policy:、manual:）；error_signature（错误摘要或退出码，便于判断是否重复）；failed_step（失败发生在哪个步骤）；env_snapshot（依赖服务、资源、网络等环境说明）；status（pass / partial / fail）；evidence（日志片段路径或页面截图标识）。

两类失败的判定线索可以这样区分：环境导致的失败，往往表现为同一时段多个任务一起报错、错误集中在连接超时或限流或资源不足、依赖恢复后同参数重跑能通过；策略导致的失败，往往表现为同一 error_signature 在同参数下反复出现、换时间段仍然复现、失败固定在同一个步骤，并且调整阈值或任务拆分方式后行为随之变化。判断不确定时，优先记录成“待归类”，不要硬塞进某一类。下面是可以直接追加写入的记录样例：

{"task_id":"mt-001","attempt_no":1,"trigger_reason":"first-run","failed_step":"fetch","status":"fail","evidence":"logs/mt-001-a1.log"}
{"task_id":"mt-001","attempt_no":2,"trigger_reason":"env:timeout","failed_step":"fetch","status":"fail","evidence":"logs/mt-001-a2.log"}
{"task_id":"mt-001","attempt_no":3,"trigger_reason":"manual:after-dependency-recover","failed_step":null,"status":"pass","evidence":"logs/mt-001-a3.log"}

填写规则只有一条需要坚持：trigger_reason 必须是可复核的事实描述，例如超时、依赖不可用、参数修正，不要写“再试一次”这类无法归因的词。

把部分完成单独成一列记录

分钟级任务常带检查点或分批产出，跑到一半失败时产出并不为零。把半程结果混进通过率会让统计偏高，全算成失败又会低估实际进度。建议在记录里把 status 固定成四个值：pass、partial、fail、skipped，partial 单独占一列。

部分完成的判定依据通常是：检查点或已完成分片的计数、产出条数与目标数量的比例、日志里最后一条成功步骤。与完全通过的区分写法是：pass 必须同时满足“执行结束”和“成功条件成立”；partial 写成“执行中断或结束 + 部分产出 + 缺少哪一段”。例如“完成 3 个分片中的 2 个，第 3 个分片在 fetch 步骤超时”，比只写一个 partial 更有用。

汇总时的口径建议一并注明：通过率是按 pass 除以 pass 与 fail 之和，还是把 partial 计入分母，两种算法得到的数字不同。把 partial 计入分母时，结论里要写明“包含部分完成”，否则读者会默认分母只有成功和失败两类。

汇总时回看执行轨迹而不是最后一步

只看最后一步状态，会丢掉重试原因分布和部分完成的量，结论容易失真。建议的回看顺序是：先看任务定义里的成功条件以及它有没有改过版本；再看每个 attempt 的起止时间与触发原因；然后看关键检查点和中间产物；最后才看最终状态。这个顺序的作用是，在结局异常时能立刻定位是环境波动还是口径问题。

记录是 JSONL 时，可以先按任务聚合看一眼尝试次数与通过分布，再决定要不要逐条回看：

jq -s 'group_by(.task_id) | map({task_id: .[0].task_id, attempts: length, pass: (map(select(.status=="pass"))|length), partial: (map(select(.status=="partial"))|length)})' records.jsonl

结论段落建议写清口径、尝试次数和未覆盖的部分，而不是只写一句“基本都过了”。例如：“在‘日志出现 summary 行且产出条数大于 0’这一假定口径下，mt-001 共 3 次尝试，前两次为环境类失败，第 3 次满足成功条件；另有 2 个任务为部分完成，未计入通过数；该口径尚未与页面状态核对。”需要提醒的边界是：假定口径未被确认、环境类失败占比又偏高时，这些数字适合内部排查使用，不宜直接当作对外结论。