去年夏天，我接手了一个屡次延期的内部系统升级项目。团队士气低落，每次周会都像在听‘问题汇报大会’——bug反复出现，需求变更频繁，测试轮次不断延长。我意识到，我们不是缺流程，而是缺一种真正能让人记住教训的方式。

就在这时，我女儿小学老师发来一张照片：孩子们在用‘错题本’整理数学作业中的错误。突然灵光一闪——我们能不能也给项目建个‘错题本’？

我不是指简单的bug记录表或事故报告。我想要的是一个结构化的、可检索的、带‘解法标注’的知识沉淀工具。比如有一次，数据库迁移失败，原因看似是脚本执行顺序不对，但深层原因是环境配置没同步更新。我把这个案例记进‘错题本’，不仅写清现象和解决步骤，还加了标签：#环境管理 #配置漂移 #跨团队协作，并附上当时沟通记录的链接。

最开始团队觉得这是多此一举。直到两周后，另一个模块遇到几乎一模一样的问题。新人小李翻了翻‘错题本’，十分钟就定位到了症结，避免了一次通宵排查。从那以后，大家开始主动往里面添内容。

我用的是蓝点通用管理系统搭的这个‘错题本’。它的好处是不用写代码就能自定义字段和流程。我设了几个关键项：问题分类（技术/沟通/流程）、影响等级、根本原因、解决人、预防措施。还能关联到具体的项目任务和文档。最贴心的是支持富文本和附件，能把报错日志截图直接贴进去。

渐渐地，这个‘错题本’演变成了我们的‘反模式库’。新成员入职，我会让他先看最近十条记录；每次迭代评审前，我们也会快速过一遍相关类别的历史问题。有次产品经理提了个新功能，老张一看就说：‘这不就是上次支付超时那个逻辑吗？我们已经在‘错题本’里标记过这种并发场景要加锁。’当场省下至少两天的设计返工。

有意思的是，这个做法还改变了团队的沟通氛围。以前出问题容易互相推诿，现在反而抢着‘认领错题’——因为记录得清楚，反而能体现解决问题的能力。甚至有人开玩笑说：‘你这bug解得漂亮，够资格上‘错题名人堂’了。’

后来我把它推广到了其他项目。销售团队用它记录客户拒绝的典型理由，客服团队用来归类高频投诉场景。形式可以变，核心逻辑不变：把失败当成可管理的数据，而不是情绪负担。

上周复盘会上，测试组长说：‘我们现在不是没有问题，而是问题越来越‘眼熟’。’我觉得这就是最好的评价。当错误变得可预期、可检索、可预防，管理才真正从救火走向防火。