从一次失败的上线说起

去年夏天，我们团队负责一个客户管理模块的迭代。功能不多，就三个表单、两条审批流，开发周期估了三周。结果上线当天，系统卡在数据导入环节，整整瘫痪四个小时。

问题出在哪？

不是技术难题，不是资源不足，而是同一个错误重复出现了三次——测试环境的数据格式和生产环境不一致。第一次是前端传参多了空格，第二次是日期字段少了个时区标识，第三次……还是日期字段，但这次是小写z写成了大写Z。

会后复盘，大家说得都很认真：‘要加强沟通’‘要提前对齐文档’‘要增加联调时间’。可这些话像极了每年年终总结里的‘来年需改进项’，说完就忘。

我突然意识到：我们一直在记录‘做了什么’，却很少系统性地记下‘做错了什么’。

灵感来自女儿的数学错题本

那天回家，翻到女儿五年级的数学错题本，密密麻麻抄着算错的题，每道旁边还用红笔标了‘易错点：进位忘记加1’。她妈说，这本子比课本还厚，但期末成绩提了一截。

我盯着那本子看了十分钟，脑子里蹦出个念头：能不能给项目也建个‘错题本’？

不是那种事故报告，也不是缺陷跟踪表（JIRA里已经有），而是一种轻量、聚焦、带反思的记录方式。重点不是记录错误本身，而是提炼‘为什么这个错会犯’‘下次怎么一眼识别’。

我们是怎么做的

第一版很简单：在团队共享文档里新建一页，叫《项目错题集》。每条记录包含四个字段：

• 错题编号：比如 PM-001
• 场景还原：一句话说清在哪件事上出了错
• 根因分析：不用太深，但得具体，比如‘未确认环境变量命名规范’
• 防错口诀：一句顺口溜或检查清单，比如‘三查：查文档、查脚本、查部署包’

第一条就是那次上线事故：

PM-001｜数据格式不一致导致导入失败

场景还原：生产环境数据导入时因时区标识大小写报错

根因分析：开发自测用mock数据，未拉取最新生产样本；部署 checklist 未包含格式校验项

防错口诀：上线前必做三件事：跑一遍真实样本、对一遍字段映射、问一句‘这数据从哪来’

刚开始大家觉得麻烦，有人说‘这不是多此一举吗’。我就带头填，每次遇到小失误——比如邮件抄送漏人、会议纪要延迟发布、需求变更没同步——都记一条。

两周后，有同事主动来问我：‘上次那个接口超时的问题，能不能也记一题？我觉得新来的容易踩坑。’

那一刻我知道，这东西活了。

错题本带来的意外变化

三个月下来，我们攒了27条‘错题’。最让我意外的不是错误变少了（确实少了40%左右），而是团队讨论的方式变了。

以前开会，说到问题容易变成‘谁没做好’；现在一出状况，有人会说：‘这题我们记过吧？是不是哪个环节没走口诀？’

有一次新成员在群里问：‘这个审批流要不要加退回节点？’老员工立刻回复：‘翻一下 PM-015，上周刚栽过，客户明确说过必须可逆。’

更妙的是，这些‘口诀’开始自发传播。有人把高频错题打印出来贴在工位旁，还有人做成飞书机器人，每天推送一条‘今日错题提醒’。

从文档到系统：我们用了蓝点通用管理系统

纸面记录终究有局限。错题多了以后，检索不便，分类混乱，有些人嫌打开文档太慢。

正好那时我在研究无代码平台，发现了蓝点通用管理系统。它允许自定义数据结构和流程，界面干净，学习成本低。

我把错题本搬了进去，建了一个‘项目错题库’应用，字段扩展成：

• 分类（流程类 / 沟通类 / 技术类）
• 关联项目
• 创建人
• 解决状态
• 点赞数（用来识别高频痛点）

还设了个简单规则：每新增一条，自动通知‘项目管理’组；每周一早会前，系统推送‘上周新增错题TOP3’。

最实用的是搜索和关联功能。现在新人接手项目，第一件事就是查相关项目的错题记录。有次产品经理改需求，系统自动提示：‘该项目曾因频繁变更导致延期（见PM-008），建议冻结窗口期’。

它不是万能药，但改变了容错文化

当然，错题本治不了所有病。战略误判、资源短缺、市场突变，这些大问题靠记错题解决不了。

但它确实在微观层面改变了我们的工作习惯。以前怕犯错，因为意味着追责；现在依然怕错，但更怕‘同一个错没记住’。

有个细节：现在团队 Slack 频道里，‘/ce’ 命令能快速调出错题查询。有次我打字太快，输成 ‘/fix’，有个新人回了一句：‘别急着修，先看看有没有现成的错题答案。’

我觉得挺好。