重构前让新旧函数跑同一批输入

重构时，改动行数少，不代表行为就安全。dev.to 的这篇文章提出一套验证流程：保留新旧函数，让它们处理同一批输入，记录输出差异，逐项排查后再切换。AI 可以协助改代码、补样例，但代码看起来合理，不能证明替换前后的行为一致。

目前能确认什么

作者建议收集约 200 个贴近真实场景的输入，用 JSONL 保存，每行一个样例。同时把时钟、随机种子等不确定因素变成显式参数，避免两次执行因为环境不同而产生差异。

接着保留旧函数体，通过一个入口委托调用；新实现使用相同签名，每次拆分或改写后，都运行新旧版本比较。这属于差分测试（Differential Testing）：通过实现之间的结果差异寻找问题。

比较前还要统一结果格式，例如集合排序、浮点数精度处理，并把异常转成可比较的值。作者要求先用同一个函数测试比较器，再确认它确实能报告失败，之后才信任通过结果。

样例全部通过后，作者建议切换入口，并将旧实现保留一个发布周期，方便恢复调用。

我的判断

差异为零，只能证明这批输入下的结果一致。

对程序员而言，这套方法适合给遗留逻辑重构加一道验证，尤其是代码绕、边界多、难以直接写出完整预期结果的函数。旧实现可以提供行为参照，但旧实现里的错误也可能被保留下来；有意修正的行为，需要单独记录对应样例和理由。

比较规则同样需要审查。浮点数取整可能掩盖业务关心的差异，不能为了让测试通过不断放宽规则。

有副作用的函数，不能直接执行两遍。

写库、发邮件等操作应先隔离，只比较纯计算核心，或将副作用重定向到测试接收端。节选也披露了 MonkeyCode 推广背景，其中免费模型和服务器的可用条件并未交代完整，不能当作稳定承诺。这套流程的价值，在于可检查的输入和差异记录，并不依赖某个 AI 产品。