去年夏天，我们团队接手了一个客户定制开发项目。一切看起来都挺顺利：需求明确、排期合理、每周站会也没人迟到。可到了交付前两周，问题像雨后蘑菇一样冒出来——某个接口突然不兼容，测试环境数据混乱，前端组件版本对不上……最离谱的是，这些问题我们三个月前在另一个项目里全遇到过。

当时项目经理老陈拍着桌子问：‘这些明明总结过，怎么又犯？’

没人回答。会议室安静得能听见空调滴水的声音。

散会后，我在翻上一次项目的复盘文档，密密麻麻十几页PPT，写得认真，归档整齐，然后就被所有人忘得干干净净。我突然意识到：我们不是没有经验，而是‘经验’太重了，重到没法随身带着走。

第二天，我在组里提了个建议：不如我们搞个‘错题本’吧。

不是开玩笑。就是像学生时代那样，把踩过的坑、出过的错、绕过的弯，一条条记下来，配上原因分析和应对方案。不追求格式统一，不用写成正式报告，甚至可以带点情绪——‘别再让张工改数据库结构还不通知后端！’‘测试环境每次上线前必须清缓存，血的教训！’

最开始大家觉得有点傻。但当第三次有人想动核心表结构时，新人小李翻出错题本第7条念出来，整个技术组都笑了。笑完之后，没人再提修改的事。

这个‘错题本’一开始是存在共享文档里的，后来我们把它搬进了蓝点通用管理系统。你可以说我们‘杀鸡用牛刀’，但它的灵活自定义能力确实帮了大忙。

我们在蓝点里建了一个叫‘项目雷区档案’的数据模型，字段很简单：问题描述、发生项目、根本原因、解决方式、关联责任人、标签（比如‘部署’‘沟通’‘权限’）。每条记录都能上传截图、链接到任务单，还能设置提醒周期——比如每季度自动推送一次‘历史同期高发问题清单’。

更妙的是流程自动化。每当新建一个项目时，系统会自动匹配过去类似类型项目中的‘高频错题’，生成一份专属的风险提示清单，附在立项文档后面。有次市场部同事看到清单里写着‘合同模板未更新导致发票信息错误’，立马去核对，果然发现法务刚换了新版模板。

这玩意儿渐渐成了团队的‘反向知识库’——不教你怎么赢，只告诉你别怎么输。

我们还玩了个小游戏：谁成功规避了一个曾被记录的‘错题’，就能在系统里点亮一颗星。三个月下来，运维组攒了9颗星，换了一顿火锅。技术组长说，这比KPI考核让人记得住。

其实‘错题本’的本质，是对‘经验管理’的一次轻量化改造。传统复盘往往追求完整闭环，最后变成仪式性文书；而错题本只关心‘这个坑我能不能绕开’。它不要求深刻，但要求可检索、可触发、可传承。

有一次客户临时变更需求，产品经理正准备硬着头皮接下，突然想起错题本里有一条：‘模糊需求口头确认后未留痕，导致验收争议’。他立刻拉群、发纪要、让对方确认，三天后客户果然反悔，我们拿聊天记录一怼，对方哑口无言。

现在新员工入职，HR不再只给员工手册，还会递上一份打印装订的《近三年错题精选》。有位实习生看完感慨：‘原来公司最宝贵的资产不是代码，是这些挨过的打。’

最近我们把这个模式推广到了其他部门。客服团队开始记录‘话术雷区’，比如‘千万别说“这不是我们的责任”’；行政组建了‘活动翻车档案’，从音响设备没电到签到二维码扫不出来，一条不落。

上周五下班前，我在系统里收到一条自动提醒：‘您参与的项目中，有2条历史错题临近高发期（季末数据备份），建议检查。’我顺手点了‘已处理’，顺手加了一句评论：‘这次提前做了异地备份，没踩坑。’

那条记录下面，已经积了6个点赞。