性能修复先问六个问题

性能修复最容易“看起来快了”就放行。上线前用六个问题查它有没有砍掉保护、改漏地方、没法观测

一句话规则

性能修复上线前先答完六个问题，答不出就不上线

发生了什么

这张卡不对应某一次事故，是我从几次性能修复的复盘里攒出来的一张检查单。

性能修复有个特点：“变快了”是能量出来的，基准数字一好看，审查就容易放行。而它可能带来的问题，比如拿掉了某个保护、引入了竞态、只改了一处，都不在那个数字里。让 agent 做性能优化时更要小心：它会如实报告耗时下降，却不一定主动说明为此改变了什么。

快和对是两个维度。很多优化手段本身就是在拿安全换速度：缓存可能读到旧数据，并发可能出现竞态，跳过校验或去掉锁等于直接砍掉保护，批处理一旦失败影响面更大。

测试通常只回答“功能还对不对”，回答不了“保护还在不在”“别处是不是也该改”“上线后怎么知道它在生效”。这些得靠人在上线前主动问。

把下面六个问题写进 PR 模板，性能相关的改动逐条回答：

问题	要回答什么
① 修 bug 还是砍保护	变快是因为去掉了多余的工作，还是去掉了校验、锁、重试、限流
② 有没有竞态	引入了缓存、并发或异步吗；两个请求同时到会怎样
③ 覆盖范围	同样的慢写法在代码库里还有几处，改全了吗（先搜一遍再回答）
④ 能观测到生效吗	上线后看哪个指标、哪条日志，能确认新逻辑真的在跑
⑤ 边界情况	空值、超大输入、unicode、错误输入，分别测过吗
⑥ 怎么失败	失败时是报错、变慢还是静默返回错误结果；谁、多久能发现

审查时，让另一个模型家族的 agent 拿着这六问逐条核对 PR，而不是只看 diff 顺不顺。任何一条答不出来，就不上线。