总结 - 人类会犯的错误

这不是“更聪明”的清单，而是“更少后悔”的做法。 你会看到：每一类错误都有一个真实场景、几条简单对策，以及可以立即尝试的小动作。

TL;DR — 三个总原则

• 让关键决策“慢一点”：停 10 秒，问 3 个问题（证据？基线？反例？）
• 把脑内转为外部：写下来、画出来、样例化，降低记忆负担
• 让错误“做难”：双签、限权、沙箱、冷却期、对手评审

认知偏差

我们天生会“看见想看的”。常见的三兄弟：确认偏误、可得性偏差、沉没成本。

• 对策：
  • 先写“判输标准”，不达标就回滚；避免事后改口
  • 数据看齐全：给每张图配上时间窗、样本量、基线对照
  • 专门找反例：列 3 条可能推翻结论的证据来源

• 对策：
  • 固定频率复盘“接近事故”的弱信号，记录未遂事件
  • 用“滚动 12 个月”基线，而不是“最近几周的感觉”

• 对策：
  • 设“弃案条件”和“再投入门槛”，到点就强制评审
  • 把“停止”视作成功策略的一部分，并公开表扬理性止损

判断与决策

• 案例：新功能“感觉”会带动留存，直接全量上线。一个月后留存无变化，但客服工单暴增。
• 对策：
  • 三问：基准概率是什么？最小可行试点？失败如何退出？
  • 用“决策记录”取代口头拍板：要点、备选、风险、跟踪指标、复盘时间

立刻可做：本周所有“重要但不紧急”的决策，写 5 行“决策记录”。

记忆与注意

• 案例：会议边回私信边改文档，结果把“草稿”发到了外部群。
• 对策：
  • 单任务窗口：高代价动作启用“请勿打扰”30 分钟
  • 外部化检查：发送前自检清单（收件人、附件、权限、版本）
  • 建“安全默认”：客户端默认“仅内部可见”，需要外发时显式提升

沟通与协作

• 案例：产品一句“尽快搞个 MVP”，工程按“最小功能”理解，设计按“最小体验可用”理解，三方各做各的，集成翻车。
• 对策：
  • 三要素模板：背景/目标、范围内/范围外、验收标准（样例最好）
  • 任务拆一层：把“看似显然”的词（快、简单、可用）写成可验证的条件
  • 读回确认：重要结论让对方复述一次；“以为都懂”往往是误会起点

示例模板：

[目的] 本周内上线注册页 A/B 试验，验证手机号一键注册是否提升首日注册率 ≥2%。
[范围] 仅 Web；不含短信通道优化；不改推荐逻辑。
[验收] 实验看板含样本量/显著性；达标阈值写明；失败即回滚。

情绪与压力

• 案例：客户投诉来得猛烈，负责人连夜改阈值“止血”，第二天造成更大范围误杀。
• 对策：
  • 设“红色按钮”剧本：谁能改阈值、改多大、回滚路径
  • 10/10/10 法：10 分钟、10 个月、10 年后回看，还会做同样选择吗？
  • 复盘情绪：复盘记录里单列“当时情绪/触发信号/身体感受”

学习与知识

• 案例：“看懂了”新工具，但换到自己场景就用不起来。
• 对策：
  • 费曼法：写一段 200 字的“给新人看的解释”，暴露不懂处
  • 迁移练习：把范例改造成“我的一个真实问题”，当天产出一个小成果
  • 反馈回路：每学一项，设置“1 周后我能在哪用到它”的闹钟

伦理与合规

• 案例：为了赶进度，临时用生产数据做本地调试，“就这一次”。半年后合规审计暴雷。
• 对策：
  • 让违规“做难”：默认不落地、脱敏镜像、审批留痕
  • 同行提醒：把“合规阻止了我”写成成功故事，正向激励
  • 渐进滑坡警示：在流程里加入“如果大家都这样做会怎样”的显眼提示

安全与健康

• 案例：线上告警太吵，大家学会了“忽略”。真正的事故到来时，没有人被吵醒。
• 对策：
  • 噪声治理：给每条告警配置责任人、去重规则、升级路径
  • 疲劳管理：排班可持续、重大变更避开深夜、强制交接
  • 清单化：发布、回滚、数据变更都有“停—查—问”三步自检

金融与消费

• 案例：被“原价 1999，现价 999”的锚定吸走，忽略了“我是否需要”。
• 对策：
  • 三报价规则：同类商品至少比较 3 家，记录总拥有成本
  • 冷却期：金额超过 X，就设置 24 小时再决策
  • 自动化：定投、自动转存，把情绪踢出场

时间与执行

• 案例：估一个需求“最多两天”，结果 6 天还没完（计划谬误 + 切换成本低估）。
• 对策：
  • 参考类比：找 3 个相似任务的实际用时，取 P80 作为估算
  • 限定变更半径：一次迭代只动一处关键路径，剩余放入下一迭代
  • 任务粒度：>1 天的任务继续拆直到可见产出

小工具：一页项目 Brief

目标/不做什么/里程碑/风险与对策/退出条件/复盘时间

社交与关系

• 案例：同事没回消息→“他不重视我”；轮到自己时却会解释“我在开会”。这就是基本归因错误。
• 对策：
  • 用 CNBR 框架表达：观察(Concrete) — 感受(Need) — 需要(Belong) — 请求(Request)
  • 约定响应协议：紧急用电话/红色标记；普通消息 24 小时内回复
  • 期望对齐：开始合作前，对齐“完成的定义”和失败的处理方式

技术与信息

• 案例：看到某博主“实测效果拉满”的评测就上生产；没验证边界条件，最终把冷门机型全伤到了。
• 对策：
  • 证据三件套：断言—证据—反例。上线前列出会失败的 3 种情况
  • 输入校验：对外部数据一律不信任；参数校验、限流、超时、断路器
  • 环境隔离：先沙箱/灰度/影子流量，观察一周再全量

领导与管理

• 案例：只奖励“结果”，团队开始追逐漂亮指标，过程质量被稀释（指标替代/目标漂移）。
• 对策：
  • 设“过程 + 结果”的双指标：既看交付，也看工程卫生与复盘质量
  • Premortem：事前写“这个项目失败的 5 个原因”，提前布防
  • 公开奖励“正确停止”“暴露问题”的行为，免得人人学会掩盖

让错误变成资产

• 建“可复用教训库”：一页一错，包含场景、信号、决策、后果、补救、复发预警
• 复盘四步：事实/原因/改进/跟进人—时间—成功标准
• 每月分享一例“差点出事”，把羞耻改造成集体免疫