从背锅到避坑：开发者错题本实战指南

为什么开发者需要一本错题本

大多数开发者都有过类似经历：凌晨被告警叫醒，发现是同一个空指针；代码评审第三次因为「缺少幂等设计」被打回；上线后才想起某个边界条件没处理。我们习惯于修复当下的问题，却很少追问：为什么同类错误会反复出现？

学生时代我们都用过错题本——把做错的题抄下来，标注错误原因，定期回顾。这个朴素的方法在编程工作中同样有效，甚至更加重要。因为线上事故的代价远高于一次考试扣分，而评审被拒背后暴露的认知缺口，如果不被显性化，就会在未来某个项目里以更昂贵的方式重演。

开发者错题本不是事故报告（Postmortem）的重复。事故报告面向团队，关注时间线、根因和改进项；错题本面向自己，关注**「我当时是怎么想的，为什么会做出那个判断」**。前者是组织资产，后者是个人能力的复利账户。

错题本该记什么：两类高价值素材

线上事故：从「我修了什么」到「我漏了什么」

事故记录最容易写成流水账：几点告警、几点回滚、改了哪行代码。这些信息复盘文档里已经有了。错题本要记录的是事故背后属于你个人的认知盲区，例如：

• 我以为这个接口调用量很小，没必要加缓存，结果大促时被打到限流；
• 我知道要做参数校验，但默认上游传过来的数据「应该是干净的」；
• 我写了重试逻辑，却没意识到重试本身会放大下游故障。

注意这些句子的共同点：它们描述的是当时的心智模型，而不是事后的正确答案。只有还原「我以为」，才能校准「实际是」。

评审被拒：被拒绝的意见比通过的代码更值钱

代码评审（Code Review）是另一个富矿，但很多人只把它当成流程。评审意见被接受后，代码改完就翻篇了，同样的问题在下个 Merge Request 里再次出现。

值得入本的评审意见通常具备以下特征之一：评审者指出的是你完全没考虑过的维度（并发、安全、可观测性）；你们对同一个方案有不同判断，且对方的理由让你信服；这个问题你已经被指出过不止一次。第三类尤其重要——重复出现的评审意见，就是你当前最确定的能力短板。

一套可落地的错题本结构

不建议把错题本写成长篇散文。结构化模板能降低记录成本，也方便后续检索和回顾。下面这个模板经过实践打磨，每条记录控制在十分钟内可以写完：

## 错题编号：024
- 日期：2024-06-18
- 类型：线上事故 / 评审被拒 / 设计返工
- 场景：一句话描述发生了什么（订单回调重复消费，导致库存扣了两次）
- 当时的判断：我以为消息中间件不会重复投递，所以消费端没做幂等
- 实际情况：网络抖动下 MQ 的至少一次投递语义必然产生重复消息
- 根因归类：分布式系统基础假设错误（可复用标签）
- 纠正动作：消费端用业务唯一键 + 去重表实现幂等
- 提炼成检查项：凡是写消息消费逻辑，先问自己「重复来了怎么办」
- 关联错题：011（重试导致重复下单）

最后两个字段是精华。「检查项」把一次具体事故抽象成一条可以在未来复用的规则；「关联错题」则让你逐渐看到孤立事件背后的共同模式——比如编号 011 和 024 都指向同一个主题：分布式环境下「恰好一次」是奢望，幂等是基本功。当某类关联错题积累到三五条，就说明该系统性地补一块知识了。

从零散记录到能力提升清单

记错题本本身不产生成长，定期的回顾与归类才会。建议建立两个节奏。

周度回顾花十五分钟翻一遍本周新增条目，问自己：这条的检查项能不能加到我常用的代码自查清单或设计评审清单里？比如把「消息消费是否幂等」「接口超时是否配置」沉淀为提交代码前的固定动作，让错误在发生前被拦截。

月度归纳则按根因标签统计。如果你发现一个季度里有六条错题都贴着「对下游能力想当然」的标签，这比任何绩效反馈都更精确地告诉你：下一阶段该提升的是方案设计阶段的依赖分析与容错思维。此时可以给自己安排针对性输入——读一篇一致性协议的文章、做一次 Chaos Engineering 演练，或在下次设计文档中强制写「外部依赖失败矩阵」。错题本就这样从「事后账本」变成了「能力提升清单」。

工具选择上不必纠结：Markdown 文件加 Git 仓库、Notion 数据库、甚至 Obsidian 加标签都可以。关键是记录门槛足够低、检索和关联足够方便。

避坑总结：实践中最容易犯的四个错误

第一，把错题本写成检讨书，只记录情绪不记录认知。 常见错误现象是满篇「我当时太粗心了」「下次一定注意」。这类记录无法指导未来，因为「粗心」不是根因。修正方法是强迫自己写出具体的错误假设：不是「没考虑空指针」，而是「我假设查询结果一定存在，因为上游刚写入，但忽略了读写分离的主从延迟」。可被检验的假设，才能被纠正。

第二，只在出大事时记录，忽略高频小错。 线上 P0 事故几个月才一次，但评审被拒、测试反复打回、自测时发现低级 bug 几乎每周都有。真正决定能力下限的是这些高频小错。建议把「评审中我认可但没主动想到的意见」也纳入记录，门槛低、素材多、反馈快。

第三，记完不回顾，错题本变成电子坟场。 很多人热情高涨地记了两个月，再没打开过。修正方法是把回顾绑定到已有习惯上：每周五下班前、每次写季度自评前翻一次。同时控制单条记录的篇幅，如果写一条要半小时，一定坚持不下去。

第四，追求客观正确，回避暴露自己的真实想法。 错题本是私人文档，但很多人下笔时仍下意识地美化当时的判断，写成「由于经验不足」这种安全而无用的话。请记住这份文档唯一的读者是未来的自己，诚实的错误推理比正确的废话有价值得多。可以考虑不放在公司文档系统，降低心理负担。

结语：错误是最公平的成长资源

开发者的能力差距，很多时候不在于谁遇到的问题更少，而在于谁能让同一个错误只付一次学费。线上事故和评审被拒对所有人都会发生，这是行业里最公平的一类成长资源——它不挑公司、不挑职级，只区分那些复盘后改变行为的人，和反复掉进同一个坑里的人。

一本持续维护的错题本，本质上是在为自己构建一套越来越密的「错误免疫系统」。当你攒下上百条检查项，你会发现新人还在踩的坑，在你这里早已成为下笔前的本能。这，就是复盘真正的复利。

免责声明

本工具与文章内容仅用于学习测试场景，优化建议仅供参考，请勿直接用于生产环境，由此产生的风险自行承担。