去年我们团队上线了一个内部工具，结果上线三天就崩了两次。不是因为代码写得烂，也不是服务器扛不住——而是我们漏掉了两个关键场景，而这两个场景，在最初的会议记录里明明提过。

这已经不是第一次了。每次出问题，大家第一反应都是：‘我当时说了啊！’可翻记录，要么语焉不详，要么压根没记。于是我们开始琢磨：能不能像学生时代那样，搞个‘错题本’？

不是比喻意义上的，是真建了个叫‘错题本’的模块。

我们用的是蓝点通用管理系统，它的好处是能快速搭出一个自定义的数据结构，不用写代码。我们就建了个‘问题条目’表，字段包括：发生时间、涉及模块、问题描述、根本原因、谁负责、是否归档、关联项目。每个问题都必须填‘根本原因’，不能写‘配置错了’，得写‘张三在部署时未核对环境变量，因缺乏检查清单’。

每周五下午，所有人打开这个列表，一条条过。最开始大家觉得尴尬，像是在公开检讨。但几周后，氛围变了。有人主动说：‘这周我差点又犯老错误，看了错题本才想起来要加日志埋点。’

有意思的是，这个‘错题本’慢慢演变成了知识资产。新来的同事第一周任务就是读最近20条记录。他们很快就能摸清哪些坑最容易踩。有次产品经理提了个需求，新人直接说：‘这个逻辑和去年七月那个并发问题很像，要不要先评估一下？’——那一刻，我觉得这东西真的活了。

后来我们加了个‘高频词云’功能，系统自动分析‘根本原因’里的关键词。有段时间‘沟通遗漏’四个字特别大，我们意识到不是流程问题，是信息传递方式出了问题。于是引入了‘决策快照’机制：只要开完会，负责人必须在两小时内发布一条结构化摘要，包含三个要素：做了什么决定、谁负责、截止时间。不发不算数。

这个‘错题本’还意外促成了跨组协作。有一次运维发现一个问题，查了我们的记录，发现三个月前我们遇到过类似的，只是当时没通知他们。现在我们设了共享标签，一旦问题涉及其他团队，必须打标签并@对方成员。有次财务部看到一个数据异常，顺手搜了下，发现是技术侧的缓存策略导致，他们直接在条目下留言，第二天就解决了。这种被动联动，比开协调会高效多了。

其实很多管理工具失败，是因为太追求‘完美流程’。我们这个‘错题本’从一开始就没想做成标准文档，反而鼓励口语化表达。有条记录写的是：‘别再相信凌晨两点的大脑，它只会让你删错库。’底下还有人评论：‘已收藏，准备当签名档。’

现在它不只是记录错误，还开始收录‘侥幸逃脱’的案例。比如某次上线前五分钟发现配置文件少了个字段，虽然没出事，但也被记进去，标题叫：‘一次没发生的事故比十次成功上线更有价值。’

我们甚至给它设了个‘遗忘周期’。每条问题满90天后，系统会自动提醒相关人：‘这个坑你还记得吗？’如果连续三次都能正确回答应对方式，这条就可以申请归档。否则，继续留在待复习列表里。

有个细节挺打动我。有次我去盯另一个项目的进度，随口问他们怎么避免重复犯错。对方说：‘我们有 checklist 啊。’我说我们也有，但我们更依赖那个错题本。他想了想说：‘checklist 是告诉你该做什么，你们那个本子，是告诉你为什么要做。’

可能这就是差别。制度让人遵守规则，而记忆让人理解后果。

最近我们把这个模式复制到了客户反馈处理上。以前投诉来了，解决就关单。现在每条都会进‘服务错题库’，分析是不是流程漏洞。有次连续三条都指向同一个操作指引不清，我们干脆重画了整个用户引导流程。

没人逼我们这么做。是那个小小的‘错题本’让我们尝到了‘把教训变成免疫力’的甜头。它不漂亮，也不智能，但它真实地长在了我们的工作肌理里。