我们团队上个月上线了一个新功能，结果刚推到灰度阶段就崩了。不是服务器宕机那种轰动性崩溃，而是用户操作路径断在某个环节，数据卡住不动。客服收到几条投诉，技术查日志，产品看埋点，最后发现是一个看似无关紧要的字段校验逻辑被改错了。

这种问题说大不大，说小不小。按常规流程，我们会开个复盘会，拉上开发、测试、产品，走一遍‘谁在哪一步疏忽了’的流程。但这次我没这么做。

我建了个‘错题本’。

不是纸质的，也不是共享文档里随便记一笔的那种。而是在我们一直用的蓝点通用管理系统里，新建了一个叫‘线上事故错题集’的数据表。每一行代表一次生产环境的问题，字段包括：发生时间、影响范围、根本原因、责任人（可多选）、修复耗时、是否重复发生、关联需求编号，还有一个必填项——‘如果重来一次，哪个环节能拦住它？’

最开始大家觉得我在玩形式主义。‘这不就是事故记录吗？还起个学生时代的名儿。’

但我坚持了一件事：每次出问题，不追责，先填表。而且必须由当事人自己填写，尤其是最后一栏。

两周后，这个‘错题本’有了8条记录。我做了个简单的统计视图，发现有5条问题都指向同一个环节：需求评审时，对边界条件的讨论太潦草。比如上次那个字段校验，其实开发以为前端会处理，前端以为接口会兜底，结果两边都没做。

更关键的是，有两条问题的原因一模一样：某个老接口在特定参数组合下返回异常格式。这已经是第二次踩同一个坑。

我把这个数据视图投在会议室屏幕上，一句话没说。团队安静了几秒，然后测试组长主动提了一句：‘要不我们把高频错误写成自动化检查脚本？’

后来我们真的做了一个‘上线前自检清单’，集成到发布流程里。每条 checklist 都来自‘错题本’里的真实案例。比如：‘涉及老接口调用的，必须确认异常格式处理逻辑’，‘多角色权限变更需二次确认’。

这个清单现在是发布流程的强制节点。我们用蓝点系统的流程引擎把它串进去了，不到这一步，发布单就过不去。

有意思的是，自从‘错题本’成了固定动作，团队对犯错的态度变了。以前出问题，第一反应是‘别说是我说的’；现在反而有人主动来说：‘这个可能是个错题苗子，要不要记一条？’

有一次，一个开发在联调时发现设计稿漏了个状态，他顺手在错题本里新建了一条，状态标为‘未发生’。他说：‘虽然这次发现了，但下次不一定这么幸运，记下来提醒自己。’

我没想到，一个模仿学生时代的学习方法，居然慢慢改变了团队的反馈文化。

其实‘错题本’的核心不是记录，而是建立一种可追溯的认知闭环。大多数团队都有事故记录，但往往止于归因。而错题本逼你回答：‘怎么避免再错？’ 它把一次性的教训转化成了可执行的预防机制。

后来我翻了一些管理类书籍，才发现这其实暗合了‘第二类错误’（Systemic Error）的管理思路——不把问题归于个人疏忽，而是看作系统缺陷的暴露。每一次错误，都是给系统打补丁的机会。

我们还在错题本里加了个新字段：‘衍生改进’。用来记录由这个错误引发的流程或工具优化。比如最近一条写着：‘因图片上传超时问题，推动CDN缓存策略优化，预计降低30%同类报错。’

这个字段让改进变得可见。以前很多优化是隐形的，做了也没人知道。现在团队能看到，一个错误不仅能被拦截，还能催生更好的基础设施。

说实话，蓝点系统帮了大忙。它不像传统项目管理工具那样只盯着进度和工时，而是允许我们用极低的成本搭建这种‘反脆弱’的管理组件。一个数据表+一个流程节点，就能把经验沉淀成机制。而且可以随时调整字段，比如我们最近发现‘影响范围’描述太模糊，就拆成了‘受影响用户量级’和‘核心路径阻断程度’两个维度。

有次老板问：‘你们团队最近线上问题少了很多，用了什么高招？’

我说：‘没什么高招，就是开始像背英语单词一样，把bug当错题背。’

他笑了，说听起来挺傻的。

但傻办法，有时候最管用。