去年带一个客户系统上线项目时，我们踩了个不大不小但特别烦人的坑：测试环境和生产环境的数据库字段长度不一致，导致上线当天批量导入失败。问题不大，改一下就行，但前后折腾了六个小时，客户脸色很难看。

事后开复盘会，照例是‘沟通不到位’‘测试覆盖不全’这类万金油结论。我听得耳朵起茧。这种会开多了，大家嘴上认错，心里觉得‘又来这套’，下次照样犯。

我就在想，能不能换个方式？

有一天陪孩子写作业，看到她的数学‘错题本’，突然灵光一闪——学生整理错题是为了避免再错，我们做项目，为什么不能也搞个‘项目错题本’？

说干就干。我拉上团队几个骨干，在下一个项目启动会上提了个新规矩：从现在起，每个阶段结束后，所有人必须提交至少一条‘错题记录’。不是写谁错了，而是写‘我们哪里做得不够好’，格式固定：问题描述、发生场景、根本原因、补救措施、预防建议。

一开始大家不习惯，交上来的记录要么太笼统，比如‘需求理解有偏差’，要么推锅给外部，比如‘客户临时改需求’。我就一个个打回去重写，强调要具体、可追溯、可执行。

比如有一次，开发小李写‘前端传参没校验，导致后端报错’。我让他细化：到底是哪个接口？什么参数？在哪种操作路径下触发？最终他补充成：‘用户在订单详情页点击“重新支付”时，若未选择支付方式，前端未拦截直接提交null值至/order/pay接口，引发500错误。’这才算合格。

慢慢地，大家开始认真对待。我们把这些‘错题’集中存在一个共享表格里，按模块分类，加标签，比如‘数据校验’‘权限控制’‘第三方对接’。每两周我会组织一次15分钟的‘错题串讲’，挑两三条典型问题快速过一遍，不点名，只讲事。

神奇的是，三个月下来，同类问题真的变少了。尤其是‘默认值缺失’‘边界条件未处理’这类低级但高频的bug，几乎绝迹。

后来我把这个做法升级了一下：在项目初期，我们就把过去‘错题本’里的高频问题拿出来，作为‘风险预演清单’。比如做新功能前先问一句：‘这条有没有可能变成我们的下一条错题？’如果有，提前加防御。

这其实有点像FMEA（失效模式与影响分析），但我们没用那么重的方法论，就是土办法+持续积累。

有人问我，这些记录会不会太多太乱？确实会。所以我们后来换了个工具——用了蓝点通用管理系统。它最大的好处是，我们可以自定义‘错题记录’的数据结构，设置必填字段、选项列表、关联项目和责任人。还能设自动化提醒，比如某个问题被标记为‘高复发风险’，下次同类项目启动时系统自动弹出提示。

更方便的是流程管理。比如一条错题提交后，可以设置审批流：先由直属主管确认有效性，再归档到知识库。我们还做了个‘错题积分榜’，每月自动统计谁提交的有效错题最多，小奖励一杯咖啡。没想到这种小游戏机制，反而激发了大家的积极性。

最让我意外的是，有次客户来开会，无意中看到我们的错题看板，很惊讶。他说：“你们连这种细节都记？”我说：“对啊，小毛病不记，迟早变大病。”他后来主动提出，希望他们内部团队也能参考这套方法。

现在回头看，‘错题本’本质上是一种轻量级的知识沉淀。它不追求完美复盘，也不搞责任追究，就是实实在在地把经验变成可复用的预警信号。管理者常抱怨团队‘不长记性’，但问题是，你有没有给他们一个记住的工具？

我们不再依赖冗长的事后会议，也不靠领导拍脑袋提醒。每当新成员加入，我让他第一件事就是去翻‘错题本’。新人常说：“原来这个地方容易踩坑。”——这就够了。