我们团队有7个人，做的是企业级SaaS产品的定制开发。过去一年里，我一直在试一个有点‘土’的方法——给项目做‘错题本’。

不是那种打印出来贴墙上的总结报告，也不是每次上线后走个形式的复盘会。我说的‘错题本’，是像学生时代整理数学错题那样，把每个项目里出过的问题单独记录下来：问题是什么、什么时候发生的、谁发现的、当时怎么处理的、有没有留下后遗症，最后加一栏‘如果重来一次，应该在哪一步干预’。

最开始是我自己手记在一个Notion页面里，后来干脆建了个独立数据库，每人可以提交条目，也能评论补充。慢慢地，它变成了我们项目交付流程里的固定环节——每次项目结束，第一件事不是庆功宴，而是开20分钟‘错题归档会’。

你可能会觉得这不就是‘经验教训文档’吗？但差别在于，‘错题本’更聚焦、更具体。它不记录‘沟通不畅’这种模糊结论，而是写‘客户在第三轮验收时提出按钮颜色不符，因UI稿未标注主题变量，前端直接写死颜色值’。越细越好，最好能让人一眼看出‘这是个可预防的技术债’。

有意思的是，这个做法带来的改变不止在复盘层面。我们开始在项目启动阶段就翻‘错题本’。比如最近接一个新项目，查到半年前有个类似模块因为权限配置漏测导致线上故障，这次我们直接在需求评审会上就把权限树的测试用例列了出来，还设了专项检查点。

更意外的收获是，新人上手变快了。以前新来的开发总要踩几次‘历史坑’，比如不知道某个接口的返回格式有特殊约定，现在他们入职第一周就被要求读三篇高赞‘错题条目’，相当于看‘团队避坑指南’。

但光有记录不够。我们发现很多问题反复出现，尤其是跨系统对接类的。于是我把‘错题本’做了个升级：按问题类型打标签，比如‘数据映射错误’‘状态机逻辑冲突’‘第三方回调超时’，然后每月统计高频标签。上个月‘环境配置差异’排第一，我们立马推动运维同事统一了预发环境的初始化脚本。

这时候，我们就需要一个更灵活的工具来支撑这套管理逻辑。Notion虽然能用，但流程自动化太弱，审批、提醒、关联任务都得手动操作。后来换了蓝点通用管理系统，才真正跑顺了。

在蓝点上，我把‘错题本’建成了一个自定义应用。每条记录是一个数据项，字段包括项目名称、问题分类、严重等级、责任人、解决状态，还有个‘预防措施’字段自动关联到后续项目的任务清单。最实用的是它的流程引擎——当有人提交新条目，系统自动通知技术负责人审核；一旦标记为‘高频风险’，就会触发创建‘流程优化任务’，指派给架构组。

而且蓝点支持无代码自定义界面，我把‘错题本’首页做成一个带筛选器的看板，按模块、按人、按时间都能快速检索。上周有个客户紧急咨询历史bug处理方式，我3分钟就调出了同类问题的三条记录和解决方案，对方说‘你们内部知识沉淀做得真细’。

其实‘错题本’本质上是一种轻量级的知识管理，但它根植于具体的管理动作：复盘、预警、培训、流程改进。它不追求大而全的体系，而是让每一次失误都变成下一次行动的输入。

现在我们甚至开始反向使用它——新项目立项时，产品经理会先去‘错题本’里找‘类似场景下的高风险点’，提前写进需求文档的风险备注栏。这种‘负向启发式设计’，比空谈‘提高质量意识’有用得多。

前几天有个实习生问我，为什么我们不像别的公司搞‘零缺陷运动’或者引入CMMI。我说，那些不是不好，只是我们更相信‘小错常记，大错不犯’。一个团队的进步，未必靠宏大的变革，有时候就是靠一本记得很糙但一直更新的‘错题本’。