保留被否决方案的证据

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

团队优化一个长列表后撤回了 memo 方案；下一会话可能再次提出它。教学记录中，同一 2000 行负载的交互时间中位数从 250ms 到 246ms，重复测量波动约 ±12ms，调用分析显示瓶颈仍在列表遍历。数字是虚构材料，不是本篇实测。

具体做法

保存尝试的想法、代码/环境版本、负载、基准与结果、噪声范围、处理决定和证据入口，即使实现已撤回也保留记录。下次先比较当前负载与旧背景；相同条件下不要把它当未探索方案。背景改变时可以重测，但说明新理由，而不是把拒绝写成永久禁止。

反例

撤回上述 memo 改动后删除全部尝试记录。下一会话重新推荐 memo，并把 250 到 246ms 写成已证实优化。

改进写法

把上述 memo 尝试留在优化台账：2000 行、相关版本、250→246ms、波动±12ms、分析中的遍历瓶颈、撤回决定和原记录位置。说明差异不足以支持这次优化主张。下次相同背景先读台账，选择尚未测试的假设；负载或代码变化时可重新尝试，但记录为何旧结论不再直接适用。不删除撤回方案的证据。

为什么这样改

代码撤回会让实现消失，证据一起丢失则无法区分没试过与已试过。保留上下文和拒绝理由能避免重复探索，也防止把测量噪声包装成收益。

如何验证

示意台账应写“撤回：4ms 差异在观察波动内，仍有遍历瓶颈”，并保留源记录。后续建议应能指出新假设，或说明为何新的负载值得再试 memo。

检查是否有负载、版本和结果入口；仅写“memo 无效”没有适用条件，或声称确定变快，都不满足本例。

适用边界

拒绝是特定背景下的判断，新的代码、设备或负载可能改变结果。噪声范围不代替完整统计设计，也不证明方案永远无效。本篇数字仅用于展示记录和解释方式。