上个月上线的新功能，客户反馈了一个奇怪的问题：某个按钮点了没反应。技术老李查了两小时，最后发现是前端传参时少了个字段——这已经是这个字段第三次出错了。

团队开会复盘时，产品经理小林突然说：‘要不咱们搞个错题本？像上学那会儿那样，把犯过的错记下来，提醒自己别再踩坑。’

我们都笑她太学生气，但确实没什么更好的办法。于是就在蓝点通用管理系统里建了个新模块，名字就叫‘错题集’。

最开始只是简单记录：哪次发布出了什么问题、原因是什么、谁负责改的。后来发现光这样不够，因为很多人根本不会主动去看。于是我们加了一条规则：每次提交代码前，必须去错题本里搜索相关模块，确认有没有历史类似问题。

更绝的是测试组的改进。他们给每个已知缺陷设了‘触发关键词’，比如‘参数为空’‘权限校验缺失’，然后把这些关键词和任务单关联。现在只要新建一个涉及用户权限的功能，系统就会自动弹出过去所有相关的错题提醒。

渐渐地，错题本不再只是记录错误，反而成了新人培训的重要资料。上周实习生小周接手一个老模块，第一件事就是翻出对应的错题记录，直接避开了三个经典坑。

最有意思的是，运维组看到后也搞了个‘故障应对锦囊’，把过去两年所有线上事故的处理步骤标准化存档。现在半夜报警电话响了，值班人员打开系统就能看到‘上次这么办搞定的’。

其实这类知识沉淀很多公司都试过，用Wiki、共享文档、甚至微信群接龙。但我们之前最大的问题是信息散、更新慢、没人看。现在的关键是把错题本嵌入到工作流里——不是让你额外多做一件事，而是让这件事自然发生。

比如每次关闭一个bug工单，系统会提示：是否要为此问题创建一条错题记录？填几个字段就行，还能上传当时的日志截图。如果选择‘是’，这条记录就会自动归类到对应模块下，并通知该模块的负责人确认。

最让我们意外的改变，是大家对待错误的态度。以前遇到重复问题总有人甩锅，现在反而会说：‘这题我们记过了啊，怎么又错了？’语气里更多是无奈而不是指责。慢慢地，写错题记录从一种追责证据，变成了团队共有的防坑指南。

最近销售部听说了这事，跑来问能不能做个‘客户拒绝原因库’。他们每次被客户拒绝后，就把原因分类记录，比如‘价格太高’‘缺少XX功能’。现在新来的销售代表谈客户前，都会先看看历史上哪些理由出现最多，提前准备话术。

其实工具本身不复杂，关键是怎么用。我们在蓝点系统上搭这个错题模块，前后不到半天，主要是设计字段和设置提醒规则。但它串起了开发、测试、运维好几个环节，让隐性经验变成了可传递的资产。

昨天站会上，老李笑着说：‘我现在写代码，脑子里就像有张错题清单在飘，到哪个环节自动弹窗。’

或许好的管理就是这样：不靠大会小会反复强调，而是把教训变成系统里的一个小提示，在你最容易犯错的时候，轻轻拉你一把。