我们团队上个月上线了一个客户管理模块，结果刚发布三天就崩了两次。问题出在一个接口超时设置被漏掉了——这已经是今年第三次因为‘低级错误’导致线上事故了。

我坐在会议室里看着故障报告，心里挺不是滋味。这些问题都不是技术难题，而是‘明明知道该做，却忘了做’。比如环境配置检查、边界值测试、日志埋点规范……这些事在文档里写得清清楚楚，可一到交付压力上来，就被选择性忽略了。

那天晚上，我翻着自己孩子的小学数学错题本，突然有了个念头：能不能给我们的开发流程也建个‘错题本’？

我不是第一个想到复盘的人。我们早就有了周会、迭代回顾、事故分析会。但问题是，这些会议常常流于形式。大家坐在一起说‘下次注意’，然后继续犯同样的错。为什么？因为‘注意’太抽象了，而‘错题本’不一样——它具体、可视、可追踪。

我第二天就在蓝点通用管理系统上搭了个‘研发错题库’。这个系统的好处是不用写代码，拖拖拽拽就能建表单和流程。我设计了几个字段：问题描述、发生场景、根本原因、影响范围、整改措施、关联项目、责任人、复查状态。

最关键是加了一条规则：每次提交代码前，必须手动勾选‘是否查阅本周错题库’。这听起来有点强制，但正因如此，它才有效。我们不再依赖‘自觉’，而是把经验沉淀变成了流程节点。

刚开始大家觉得麻烦。有人说：‘我又不是新人，干嘛老看这些？’我就把最近那次接口超时的记录贴出来——那正是一个资深工程师漏掉的配置。我说：‘这不是惩罚，是帮我们所有人绕过坑。’

一个月后，变化悄然发生。有次晨会，一个新人主动提醒：‘这个定时任务是不是该加熔断？上次错题库里有个类似案例。’那一刻我知道，这个机制开始起作用了。

更意外的是，运维团队看到后，也申请开通了权限，把自己的故障案例加了进去。他们还加了个‘高频关键词’标签，比如‘磁盘满’、‘连接池泄漏’，方便快速检索。现在这个错题库已经成了跨部门的知识中转站。

我们还玩了个小花样：每月评选‘最有价值错题’。不是嘲笑谁犯了错，而是奖励那些暴露了系统性漏洞的案例。比如有一次，某个‘参数未校验’的问题，反过来推动了我们统一校验组件的落地。

其实‘错题本’的本质，是把隐性经验显性化。很多管理工具失败，是因为它们试图控制人，而真正有效的工具是帮人减少认知负担。我们不需要记住所有细节，只需要养成‘查一下’的习惯。

上周，销售系统要做一次大版本升级。部署前，我在群里问：‘谁去更新错题库？’话音刚落，三个成员同时回复：‘我已经补充了缓存穿透的预防措施。’

那一刻，我觉得比任何KPI达成都让人踏实。