案例复审清单
要点
- 案例复审清单用于检查案例是否完整、可判断、可复用
- 复审不是挑错，是帮助作者完善案例
- 清单分两部分：写作时自检、复审时检查
- 复审的重点是：背景是否清楚、约束是否完整、决策是否有理由、结果是否有证据
1. 适用场景
案例复审清单用于：
- 作者写完案例后自检
- 复审者检查案例质量
- 团队建立案例质量标准
- 新人学习如何写好案例
2. 写作自检清单
作者写完案例后，逐项检查：
背景
- 是否说明了系统背景和业务场景
- 读者能否判断「这个案例和我的场景有多接近」
- 是否说明了触发这次工作的原因
约束
- 是否列出了时间约束
- 是否列出了人力/团队约束
- 是否列出了兼容性约束
- 是否列出了风险约束
决策
- 是否说明了选择了什么方案
- 是否说明了放弃了什么方案
- 是否说明了取舍理由
- 决策是否有证据支撑（数据、日志、案例）
结果
- 是否有量化指标（性能、成本、效率）
- 是否说明了用户影响
- 是否说明了残留问题
复盘
- 是否提炼了可复用的原则
- 是否列出了后续行动项
- 行动项是否具体（谁、什么、截止时间）
写作质量
- 是否先讲场景和约束，再讲方案
- 判断是否绑定到证据
- 是否承认了取舍和局限
- 结论是否可判断（适不适合某个场景）
- 案例长度是否合适（1000-2000 字）
3. 复审检查清单
复审者检查案例时，逐项检查：
可理解性
- 背景是否清楚——不了解该系统的人能否理解
- 术语是否解释——专业术语是否有说明
- 逻辑是否连贯——从背景到决策到结果是否流畅
完整性
- 五个核心部分是否齐全（背景、约束、决策、结果、复盘）
- 约束是否完整——有没有遗漏的关键约束
- 决策是否有对比——只写了一个方案，还是对比了多个方案
可判断性
- 结论是否可判断——读者能否判断是否适合自己的场景
- 取舍是否清楚——代价和收益是否明确
- 适用范围是否说明——什么场景适用，什么场景不适用
证据充分性
- 判断是否有证据——「性能好」有多少据支撑
- 结果是否量化——指标是否具体
- 失败案例是否分析——只写了成功，还是也分析了失败
可复用性
- 是否提炼了可复用的原则
- 原则是否具体——「要注意性能」不具体，「P99 延迟 < 200ms」具体
- 是否有代码示例或配置示例
时效性
- 技术栈是否过时——案例提到的工具版本是否还有效
- 前提条件是否还成立——业务场景是否变化
- 是否需要更新——是否有新的发现或改进
4. 复审流程
复审前
复审者：
- 阅读案例 2-3 遍
- 标记不清楚、不完整、不可判断的地方
- 准备具体的改进建议
复审中
- 先肯定案例的优点
- 逐项讨论检查清单中的问题
- 给出具体的改进建议（不是泛泛而谈）
复审后
- 作者根据反馈修改
- 复审者再次检查
- 确认案例达到质量标准
5. 常见复审问题
背景不清楚
问题：读者无法判断案例是否适用于自己的场景。
建议：补充系统规模、业务场景、技术栈。
约束不完整
问题：决策看起来不合理，但其实是约束下的最优解。
建议：补充时间、人力、兼容性等约束。
决策没有对比
问题：只写了选择的方案，没有写放弃的方案。
建议：补充对比方案，说明取舍理由。
结果没有量化
问题：「效果不错」不是结论。
建议：补充量化指标（性能、成本、效率）。
结论不可判断
问题：读者看完不知道是否适合自己的场景。
建议：明确说明适用场景和不适用场景。
案例太长
问题：超过 3000 字，读者读不完。
建议：精简背景，重点写决策和取舍。
6. 复审示例
案例原文（节选）
我们把订单系统拆分为微服务，效果很好。
复审意见
- 背景不清楚：什么订单系统？多大规模？为什么要拆分？
- 约束不完整：团队规模？时间要求？兼容性要求？
- 决策没有对比：为什么选微服务？对比了单体、模块化单体吗？
- 结果没有量化：「效果很好」是多少？延迟？吞吐量？开发效率？
- 结论不可判断：什么场景适合拆微服务？什么场景不适合？
总结
案例复审清单分两部分：写作自检（作者用）、复审检查（复审者用）。重点是背景清楚、约束完整、决策有对比、结果有证据、结论可判断。复审不是挑错，是帮助作者完善案例。