同一类事做过十几次，被问"下次怎么做得更好"，答出来的往往是"注意一点""早点介入""多想一步"。这类回答的共同点是无法反驳：没人能证明它错，也就没人能靠它改进；经验停在故事层，次数再多也不复利。
分界只有一条：有没有发生抽象，以及抽象出来的东西能不能被反驳。能被反驳，才谈得上被检验；被检验过，才谈得上复用。
1. 经验的四种形态
| 形态 | 例子 | 可迁移性 | 可反驳性 | 复用成本 |
|---|---|---|---|---|
| 故事 | "那次上线炸了，熬了一夜" | 低，靠听者自己联想 | 无 | 每次都要重讲 |
| 清单 | "上线前检查配置、日志、回滚脚本" | 中，靠覆盖度 | 弱，漏项才发现 | 要靠人记得翻 |
| 规则 | "涉及资金链路的变更必须双人复核" | 中高，边界模糊 | 中，可以问"什么算资金链路" | 需要解释边界 |
| 判据 | "若变更涉及余额字段且无对账任务，则必须双人复核" | 高，条件明确 | 强，可以直接拿反例打 | 低，可检索可执行 |
四种形态不是进步阶梯，而是四种成本结构：故事最省事但无法迁移，判据最贵但可以交给别人用。多数人的库存停在故事与清单，因为这两层不必面对"我凭什么这么判断"。
判据可以压成一句：在什么条件下、看到什么信号、就该做什么判断。触发条件写死，才能被证伪。
2. 三个层次：事件、决策、判据
| 层次 | 记录什么 | 产出物 | 三个月后还剩什么 |
|---|---|---|---|
| 事件 | 发生了什么、时间线、影响面 | 事故记录 | 只有当事人还记得 |
| 决策 | 在哪几个点做了选择、当时的信息集 | 决策日志 | 少数取舍，且容易被误记 |
| 判据 | 什么条件下该怎么判断 | 可检索的条目 | 可被他人使用 |
只做第一层是最常见的失败：记录详尽，读完仍不知下次该怎么办。第二层才是复盘真正的位置——同一件事换个人做，差别就在判断依据。
--- 三层记录：一次只填一层，别混在一段散文里
event:
what: 发布后 12 分钟错误率升到 8%
impact: 约 3% 的订单请求失败
decision:
- point: 是否立即回滚
info_at_hand: 错误率曲线、上一版本健康度、值班人力
chosen: 观察 5 分钟再决定
why: 回滚要 4 分钟，且当时看不出是配置还是代码
criterion:
- id: CRIT-014
trigger: 错误率 > 基线 3 倍且 5 分钟无回落
action: 直接回滚，不等归因
counter: 上游依赖故障时回滚无效，先切降级
3. 四步：从事件到判据
- 还原决策点：把过程切成"有别的选法"的时刻，而不是按时间流水记账。
- 找出当时的依据：写下真正看到的信息与真正相信的规律，不是事后合理化的版本。
- 检验依据是否成立：这条规律是普适的，还是只在这一次成立？有没有反例？
- 写出可执行的判据：填满四个字段，编号，放进能被检索的地方。
第 3 步最容易被跳过，因为它要求承认"我当时的依据可能错了"。跳过它的代价是塞进一批只在单次事件成立的规律，之后照做都失效。
字段分工要记清：缺 trigger 就永远想不起来，缺 action 退化成"要谨慎"，缺 counter 会被机械套用，缺 boundary 会跨场景误用。
--- 判据的最小结构：四个字段缺一个就会退化成口号
id: CRIT-014
trigger: 错误率 > 基线 3 倍，持续 >= 5 分钟，且无自愈趋势
action: 回滚到上一个已验证版本
counter: 上游依赖故障时回滚无效，应先切降级或限流
boundary: 适用于自有服务的发布；第三方接口故障不适用
evidence: INC-2211, INC-2318
4. "我当时觉得"是重要数据
"我当时觉得应该再等等"这类描述常被当成噪音清掉，因为听起来不专业。它恰恰是唯一记录可用信息集的东西：当时你只有三条指标、两个人的意见、一个模糊直觉，而不是事后全部证据。丢掉它，判据就按上帝视角写。
| 记录项 | 为什么值得记 | 记不住时的替代 |
|---|---|---|
| 当时看到哪些信号 | 决定 trigger 的强度 | 从监控截图、聊天记录反推 |
| 犹豫了多久 | 暴露决策延迟的代价 | 用操作时间戳近似 |
| 最担心什么 | 常是 counter 字段的来源 | 24 小时内补写 |
| 谁反对、理由 | 提供现成的反例候选 | 会议记录里的分歧点 |
--- 决策日志：一条不超过六行，写多了没人维护
at: 2026-10-14T21:05
saw: [错误率 8%, p99 1.9s, 上游 200 OK]
felt: 更像配置问题，因为延迟没同步恶化
waited: 5min
regret: 无；但 5 分钟的等待没有明确退出条件
felt 这一行不是抒情，它是假设声明。有了它，事后才能判断感觉准不准，而这是判据命中率的原始数据。
5. 泛化程度：过度与欠泛化
| 失败 | 症状 | 典型成因 | 修正 |
|---|---|---|---|
| 过度泛化 | 一次成功就总结成规律，换场景即失效 | 样本量 1，且没找反例 | 主动搜三个反例，找不到才升级 |
| 欠泛化 | 每次从头判断，同错重犯 | 觉得"这次特殊"，拒绝抽象 | 强制写一条候选判据，标注待验证 |
过度泛化有个识别特征：trigger 写得很宽（"涉及数据库变更时"），因为宽才显得有用。宽 trigger 会频繁误触发，然后被静默忽略。欠泛化的特征是没有库存：回答永远是"看情况"。
// 候选升主库：反例不足就先留在候选区
def promote(crit, counterexamples):
if len(counterexamples) == 0:
return "reject" // 找不到反例通常意味着没认真找
if len(counterexamples) >= 3 and all(c.matched for c in counterexamples):
return "keep_candidate" // 三个反例都成立 → trigger 太宽
return "promote"
6. 时机、版本化与淘汰
| 时机 | 可得信息 | 偏差风险 | 适合产出 |
|---|---|---|---|
| 事件后 24 小时内 | 细节完整、情绪未平 | 归因偏向自己无辜 | 事件与决策层 |
| 一周内 | 细节开始丢失 | 已被结论污染 | 判据初稿 |
| 一个月后 | 只剩结论 | 高，容易写成正确废话 | 只适合校验 |
判据需要版本化，理由和代码一样：它会错，错了要能回滚。新经验推翻旧判据时，保留旧版本并记录反证，而不是直接改掉——否则半年后无法解释"当初为什么这么定"。
| 状态 | 含义 | 允许的动作 |
|---|---|---|
| candidate | 有依据但未检验 | 在下一个相似场景里预测 |
| active | 至少命中一次且无反例 | 直接使用，定期复核 |
| disputed | 出现反例但未定论 | 标注冲突，暂停推广 |
| retired | 被新判据或新事实推翻 | 留档，注明替代者 |
─── 淘汰不是删除：retired 保留，索引指向替代条目
$ grep -n 'superseded_by' criteria/CRIT-014.yaml
superseded_by: CRIT-051
7. 检验：先预测，再对照
判据最容易得到的评价是"写得挺好"，最难得到的是"它准不准"。唯一可靠的检验方式是在使用之前写下预测：按这条判据，这个场景应该出现什么、不该出现什么。
--- 预测记录：写在使用之前，事后再补等于自证
crit: CRIT-014
scene: 2026-11-02 灰度 5% 时错误率上升
predict: 若 5 分钟内不回落则必须回滚；回滚后约 6 分钟恢复
observed: 回滚后 4 分钟恢复；错误率峰值 6.2%
verdict: hit
"无法判定"最常见，原因是场景与 trigger 不完全匹配。它同样有价值：说明 trigger 要收窄，或 boundary 要补一句。
8. 度量与反噬
| 度量 | 采集方式 | 用途 | 反噬 |
|---|---|---|---|
| 判据条数 | 目录计数 | 判断抽象是否发生 | 涨太快通常是拆分过细 |
| 被引用次数 | 判据文件里的 uses 计数 | 找出没人用的条目 | 只统计显式引用，隐性使用看不到 |
| 预测命中率 | verdict 为 hit 的比例 | 判断判据质量 | 场景选择偏差会抬高数字 |
| 失效条数 | retired 与 disputed 计数 | 判断知识半衰期 | 越诚实记录，数字越难看 |
第二项的反噬值得单说：没人引用不一定是坏判据，可能那类场景半年才出现一次。清理时要同时看场景频次，两项都低才合并。
9. 排错
| 现象 | 原因 | 处理 |
|---|---|---|
| 判据写了没人用 | trigger 太宽或太窄，检索不到 | 按实际场景里的信号词重写 |
| 用了判据反而出错 | 缺 counter，被机械套用 | 补反例，写清何时不适用 |
| 复盘越写越长 | 事件层与判据层混在一份文档 | 拆成两份，判据进库、事件留档 |
| 同一条反复被推翻 | 在补丁上打补丁，抽象层级错了 | 回到决策点重写，代价反而更小 |
| 别人的经验照搬就废 | 对方的前提条件没一起搬 | 只搬假设，在自己场景里重验 |
| 判据库无人维护 | 没有日常动作会碰到它 | 嵌进发布检查、评审、故障第一步 |
最后一条是最常见的死法：判据库作为独立项目存在，没有高频动作会碰到它。它必须挂在每天都会发生的动作上。
10. 边界
| 场景 | 为什么提炼收益有限 |
|---|---|
| 一次性场景（一辈子做一次的决定） | 判据没有第二次使用机会 |
| 随机性主导（结果与决策质量弱相关） | 从结果反推会学到噪声 |
| 无法重复、也无法观察反馈 | 没有检验手段，只能停在候选区 |
| 纯粹的知识缺口 | 需要的是输入，不是复盘 |
| 流程已被强约束 | 个人判断空间太小，判据无处落地 |
反向信号同样清楚：同类决策一年出现三次以上、结果有可观测反馈、且你有权改变做法——三条同时满足时收益最确定。
还要防一个误解：判据不是把人变成规则执行器，而是把想清楚的部分固化，省下的注意力留给新事情。库存里一半是候选与存疑条目，才是正常状态。
11. 自测
- 你能说出一条自己写下的判据吗？它的 trigger 与 counter 分别是什么？
- 为什么"找不到反例"通常意味着没认真找，而不是规律普适？
- 事件层、决策层、判据层，你的记录停在哪一层？
- 判据被推翻时，为什么保留旧版本比直接改掉更有价值？
- 预测记录为什么必须写在使用之前？
- 什么条件下，把经验判据化的收益会明显低于投入？