无责文化下的评审
把评审定位成共同改进代码的机制，而不是追责工具：评论谈代码不谈人，事故复盘先问机制为什么没拦住，而不是先问是谁写的。心理安全感一旦崩掉，坏消息会被推迟到无法挽回时才浮出水面，评审也就只剩下签字。
基本信息
| 核心主张 | 评论针对代码与流程，责任由团队共担 |
|---|---|
| 度量口径 | 评审时延、缺陷逃逸率等团队级指标 |
| 警戒信号 | 把评论数当绩效、复盘先问责任人 |
| 边界 | 无责不等于无标准，标准对事不对人 |
典型使用场景
- 评审记录用于改进流程：不进入个人绩效扣分项
- 事故复盘关注机制：为什么测试与灰度没有拦住
- 允许快速承认与修正错误：上报问题被鼓励而不是被追问
- 度量取团队口径：不排名个人，避免刷指标
- 新人出错时先补上下文：区分能力缺口与流程缺口
有责与无责的做法差别
| 情形 | 有责式做法 | 无责式做法 |
|---|---|---|
| 线上故障 | 先问是谁改的 | 先问监控与灰度为什么没拦住 |
| 评审发现漏洞 | 记在个人档案里 | 反查评审清单缺了哪一项 |
| 同类问题重复出现 | 强调下次注意 | 把它变成检查项或自动化校验 |
复盘提问清单
复盘提问清单
1. 触发条件是什么，当时为什么没有暴露？
2. 哪一层防线本该拦住它：测试、评审、灰度还是监控？
3. 换个人来做同样的事，会不会再犯？
4. 要补的是文档、检查项、自动校验还是培训？
结论落到具体改动上，而不是落到某个人身上。无责不等于没有标准：标准针对代码与流程，责任由团队共担，两者缺一不可。
事故后先找责任人：信息会被隐藏起来，同类问题在别的模块再发生一次。