34 lines
1.6 KiB
Markdown
34 lines
1.6 KiB
Markdown
# 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 这样的统计数字就是"这值得机制化"的证据。
|
||
- 候选必须人工落地（复盘提议、人拍板），防止复盘自身成为无人审计的
|
||
自动改配置通道。
|