# Preflight 证据闭环：66 次命中 / 31 张工单的统计

> 组织沉积教学案例；机制已入 Core，本文仅叙事。所涉机制见
> `core/rules/workflow-routing.md`（routes.{Kind}.preflight）。

## 背景

一次跨周期复盘对首轮评审 FAIL/WARN 发现做了根因归类统计：某类根因在
观察窗口内累计命中 66 次，分布在 31 张不同工单上——同一类上游失误在
评审门被反复拦截，每次拦截都支付一轮评审 + 一轮修订的双倍成本。

## 统计闭环的构造

1. **数据面**：每张多轮评审工单的首轮 FAIL/WARN 发现，按
   （维度 × 根因标签）归类。
2. **阈值判定**：命中次数与去重工单数同时过阈值的根因，成为
   pre-flight 候选（生产者侧自检项）。
3. **落点**：候选人工落入路由表 `routes.{Kind}.preflight`，由
   implement 技能在派发开发子代理前注入自检清单。
4. **老化退出**：落地后连续 N 个干净首轮 → 移除行，避免清单无限膨胀。

## 为什么有效

- 评审门的发现是**最真实的上游质量信号**——它就是下游实际会犯的错。
- 把拦截点前移到写代码之前，成本从"评审轮 + 修订轮"降到"自检一行"。
- 阈值（样本量 + 复现工单数）挡住了偶发噪声，只沉淀系统性根因。

## 教训

- 复盘的价值不在罗列问题，而在**把重复出现的问题变成机制**：
  66/31 这样的统计数字就是"这值得机制化"的证据。
- 候选必须人工落地（复盘提议、人拍板），防止复盘自身成为无人审计的
  自动改配置通道。