“修了一个空指针”可以写得更清楚，但不该被改写成“阻止了一场P0事故”。后一句多出来的不是文采，而是需要证据的新事实。模型能把句子写得有气势，不负责替我们承担这些事实。
我希望读完一份排障周报的人，能知道改动解决了什么、怎样验证、还欠什么，而不是靠一串百分比判断工作是否重要。
先说改了哪里，再说为什么改
以下是构造示例，不是本账号经历：一个订单查询分支在地址缺失时抛空指针。合理的记录可以是：明确该分支允许地址为空，增加边界处理，并为缺地址输入补充回归测试。
这里可以写“新增了这个回归用例”，前提是确有代码和结果；不能顺势写“稳定性提升99.8%”，因为单元测试没有提供线上失败率的分母。更不能补出某位领导的表扬，作为效果证据。
三种改动，三种证据
| 构造案例 | 可以记录的事实 | 尚不能直接宣称的收益 |
|---|---|---|
| 修复空值分支 | 差异、用例输入、运行结果 | 防住多少生产事故 |
| 调整调用超时 | 配置前后值、测试场景和返回状态 | 可用性必然提高 |
| 增加联合索引 | DDL、目标查询、执行计划及实测条件 | 所有查询均加速 |
比如把等待从1秒改成3秒，可能增加成功等待，也可能占用更多连接；没有到达率、并发、排队和失败分布，无法给它贴“提升韧性”的标签。DDL执行成功同样不等于索引对全部SQL都有价值。
MySQL官方死锁处理资料建议缩短事务、保持一致的访问顺序并准备重试，但不能把一项措施写成所有工作负载的无死锁保证。官方手册可用于解释判断依据，不代替本业务回归。
收益要有可回查的分母
如果有数据，记录环境、窗口、采样方法、总请求数、失败定义及变更期间其他影响。只有一条Trace，就写这个样本的观察；没有对照，不把时间先后当因果。
Prometheus的窗口增量是监控估计，离线请求明细又是另一种口径。两者能相互检查，但不应为了图好看而悄悄换分母。函数文档提供计算语义，实际收益仍来自真实记录。
未知项也值得交接
一份有用的结尾可以写：“已验证空地址输入不再走异常分支；未做生产回放，尚不清楚历史请求中这类输入的占比；下一步核对脱敏样本与接口契约。”这段话没有战果数字，却让下一个人知道怎样继续。
本文是写作与证据整理的方法，没有执行数据库变更、在线测量或模型调用。之后发生的排障，只能在真实记录产生后再写进去。
