把错误写进账本：用 Mistake Log 让团队不重复摔同一跤

上周我们复盘一个上线事故，发现同一个配置参数在三个月内踩了三次坑。第一次是 A 同事，第二次是 B 同事，第三次是我们自己。每一次都"修好了"，但经验只停留在事故群聊的滚动消息里，没人沉淀，更没人接住。

这就是大多数团队的真实状态：踩坑的成本付了，学习的收益没拿到。

什么是 Mistake Log

Mistake Log（错误账本）就是一个公开文档，只记录"我们犯过的错"，不追责个人。每条记录只回答四个问题：

1. **现象**：用户或系统看到了什么

2. **根因**：为什么会发生（不是"谁手滑"，而是哪个环节缺了防护）

3. **修复**：这次怎么解决的

4. **防再犯**：加了什么规则、检查或自动化，让下一次不会重复

注意第四条是核心。没有"防再犯"字段的错误记录，只是事故日记。

什么时候用它

- 团队超过 3 个人，记忆开始不可靠

- 同一个问题被不同人重复问或重复犯

- 新成员入职，想让他少走弯路

- 出过线上事故，需要制度化复盘

什么时候别用

- 一次性的小项目，沟通成本高于维护成本

- 团队文化还靠"甩锅"运转——先解决信任问题，再开账本

- 把它当绩效考核工具。一旦记错=扣分，账本三天内就会变成空文档

最小可用格式

每条记录控制在 200 字以内，够用就行：

[日期] [标题]
现象：xxx
根因：xxx
修复：xxx
防再犯：xxx（对应哪条检查/文档/自动化）

格式越长，填写率越低。200 字是实践中的甜蜜点。

使用清单

- [ ] 错误账本放在全团队可见的位置，和任务看板同层

- [ ] 每条记录必须有"防再犯"字段，否则打回补全

- [ ] 每周站会用 2 分钟过一遍本周新增条目

- [ ] 新人入职第一周，通读一遍账本

- [ ] 每季度清理一次：把已被自动化覆盖的条目标记为"已固化"

- [ ] 只写系统层根因，不写人名

常见坑

1. **写成追责工具**：标题里出现人名，贡献率立刻归零。规则写死：标题只写问题，不写人。

2. **只记不闭环**："防再犯"写了"加强注意"等于没写。注意不是机制，检查项和自动化才是。

3. **搜索性为零**：标题写"周二那个 bug"，半年后没人搜得到。标题要写现象关键词，让未来的你能搜到过去的你。

4. **写得像小说**：500 字的事故故事没人读。压缩到四行以内，细节放事故群的原始记录里，账本里贴个链接。

5. **只记技术错误**：需求理解偏差、流程沟通失误同样是高频坑，而且往往损失更大，一并记。

两周能落地的路径

第一天建文档、定格式；第一周每次复盘后顺手记一条；第二周站会开始例行过账本；一个月后你会发现，新人的问题清单明显变短了——因为答案都在账本里。

错误本身不可怕，可怕的是每次都把学费交一次。

一句话总结

Mistake Log 的门槛极低：一个文档、一个格式、每周两分钟。它的价值在于把"个人的教训"变成"组织的资产"——今天你踩过的坑，明天接手的同事不必再踩一遍。先写下一条，比想好标准更重要。