去年夏天，我负责公司新上线的会员积分系统。项目不大，但涉及财务、用户行为、第三方接口等多个模块，团队里有开发、测试、运营，还有临时抽调的设计。按理说这种中等复杂度的项目，走标准流程应该没问题。可我们前两周就卡住了——不是技术难题，而是同样的错误反复出现。

比如，测试反馈某个用户积分没到账，开发查日志说是接口调用失败，结果一查是运营配置的活动规则写错了阈值；过两天又出问题，这次是前端展示异常，追到最后发现还是同一条规则在不同端的解析方式不一致。我们开了三次站会专门复盘，每次都说‘下次注意’，可‘注意’根本没落地。

直到有天晚上加班，我翻女儿的书包，看到她语文试卷上的‘错题本’——每道错题旁边都写着错误原因和正确思路，还用不同颜色标出知识点类别。我突然意识到：我们团队缺的不是流程，而是一个能沉淀‘错误认知’的机制。

第二天晨会，我提了个建议：建个共享文档，叫‘项目错题本’。不是记录bug，而是记录‘决策偏差’或‘认知盲区’。比如：

• 错题：认为‘用户不会在意积分有效期’，结果上线后收到大量投诉
  归因：仅参考了历史数据，未做小范围用户调研
  纠正动作：所有涉及用户感知的变更，必须附带最小化验证方案

• 错题：默认第三方接口响应时间小于200ms
  归因：未在压测环境中模拟弱网场景
  纠正动作：接口对接必须包含性能边界测试用例

  

起初大家觉得麻烦，像在写检讨。我就带头填了两条自己犯的错，还把其中一条设为‘高亮案例’，配上表情包：‘以为懂了，其实没懂’。慢慢地，有人开始主动往里面加条目。测试小张写了一条：‘别相信开发说“这个逻辑很简单”’，后面跟了个狗头。气氛轻松了，但内容越来越扎实。

一个月后，我们发现‘错题本’不只是纠错工具，它开始影响我们的设计评审。每次讨论新功能，有人会问：‘这有没有可能变成下一条错题？’然后翻记录找类似模式。有一次，产品提了个‘自动清零过期积分’的功能，刚说完，技术负责人就说：‘等等，上次我们因为没通知用户被投诉，这条在错题本第7条。这次清零要不要加前置提醒？’——问题还没发生，就被拦截了。

后来我把这个做法分享给其他项目经理，有人尝试用Confluence建类似页面，但反馈说太重，更新麻烦；也有人用Excel，但权限混乱，版本对不上。直到我接触到蓝点通用管理系统，才发现有个更合适的载体。

我在蓝点上搭了个轻量级‘错题库’应用。它有几个关键优势：

1. 自定义字段灵活：可以设置‘错误类型’（流程/技术/沟通）、‘影响等级’、‘关联模块’等标签，支持下拉、日期、附件上传；
2. 流程自动化：当新增一条高影响等级的错题时，自动触发提醒给相关模块负责人；
3. 视图筛选自由：按人、按阶段、按关键词快速检索，还能生成月度‘认知改进报告’；
4. 权限精细控制：实习生可以查看但不能修改历史条目，避免误删。

最让我满意的是它的无代码特性。我不用求开发排期，自己拖拽半天就搭好了。后来运营团队看我们用得顺，借去改造成‘活动复盘库’，客服团队拿去做了‘典型客诉应对指南’。同一个底层系统，不同团队按需定制，反而促成了跨部门的经验流动。

现在我们每个项目启动时，第一件事不是画甘特图，而是打开‘错题库’，花半小时读最近十条记录。新人入职培训里也加入了‘从错题学决策’的环节。有个新来的开发笑着说：‘你们这团队，好像特别喜欢翻旧账。’我说：‘不是翻旧账，是把摔倒的地方标成地图，下次绕着走。’

上周复盘会上，测试主管提议把‘错题本’升级成‘经验资产库’，加入正向案例，比如某个优化让加载速度提升40%。我觉得挺好，错误值得记录，但经验和洞察更值得沉淀。系统可以简单，但思维要持续进化。