GPT-5-Codex、Claude Sonnet 4.5 与 Kimi K2 在真实重构任务中谁更强？

在这次单次真实重构案例中，GPT-5-Codex 完成范围最完整，Kimi K2 的实现较简洁但漏掉一个构建目标，Claude Sonnet 4.5 最快却残留旧引用且没有补测试。这个结果只适用于该大型单仓库、同一提示和当次运行，不能据此认定某款模型在所有编程任务中更强。

重构任务包含哪些要求

任务不是生成一个孤立函数，而是把紧耦合的数据库操作收拢到单一包中，为 INSERT 加入基于时间的批处理，并把若干存储过程改写成原生 Go。仓库包含多个构建目标，因此完成度取决于跨目录引用、构建配置和测试是否同步更新。

这种任务最容易出现“新包已经创建，但旧路径仍在使用”的半完成状态。评价时应先检查所有调用点和构建目标，再看代码风格，不能用改动文件数量直接代表质量。

三款模型当次表现

模型与环境	改动范围	原帖观察
GPT-5-Codex medium	23 个文件	最慢，但覆盖构建目标、说明文件和既有测试，任务完成最全面
Claude Sonnet 4.5	11 个文件	最快，创建了新包，但遗留旧引用且没有处理测试
Kimi K2 / OpenCode Zen	15 个文件	实现简洁，漏掉一个构建目标，作者估计约四分之一范围未完成，单次成本为 4.11 美元

这里的文件数只描述修改面。23 个文件可能意味着完整覆盖，也可能意味着不必要扩散；11 个文件可能是精准修改，也可能遗漏范围。原帖之所以判断 Codex 更完整，是因为它同时更新了构建目标和测试，而不是因为文件数最多。

为什么跨仓库覆盖决定结果

数据库层重构会影响包引用、初始化、迁移、测试夹具和多个二进制入口。模型若只搜索最明显的调用点，新实现可能在一个目标通过，却让其他目标继续依赖旧包。构建矩阵与全仓搜索因此是完成条件的一部分。

rg "旧包路径|旧存储过程名" .
go test ./...
go vet ./...
git diff --stat
git diff --check

命令需要按仓库实际工具链调整。成功标志不是命令曾被执行，而是旧引用只在明确保留的迁移资料中出现，所有构建目标和测试均通过，批处理行为也满足数据一致性要求。

批量 INSERT 要验证什么

基于时间的批处理不能只验证吞吐量。还要测试批次大小、定时刷新、关闭时清空、事务失败、部分写入、重复提交和并发调用。若服务在计时器触发前退出，缓冲数据必须有明确的 flush 或回滚语义。

• 空批次不会产生无意义事务。
• 达到数量或时间阈值都能刷新。
• 写入失败不会静默丢失数据。
• 关闭流程等待最后批次完成。
• 存储过程迁移后的约束、默认值和事务边界保持一致。

成本与速度怎样公平比较

原帖只给出 Kimi K2 的 4.11 美元成本，并用快慢描述另外两款模型，没有统一记录 Token、墙钟时间、订阅配额和人工修订成本。因此不能从这次案例推导稳定的价格排名。

更实用的指标是“达到同一验收状态的总成本”：模型运行费用加上人工补测试、清理旧引用、修复构建和复查差异所需时间。一个更快但只完成一半的结果，最终可能比慢而完整的结果更昂贵。

如何复现更可信的对比

1. 固定同一提交，分别创建干净工作树。
2. 提供完全相同的任务说明、工具权限、推理档位和时间上限。
3. 预先写好覆盖所有构建目标的验收脚本。
4. 每款模型至少重复运行多次，记录完成率而非最佳一次。
5. 由盲评人员检查测试、残留引用、数据语义和维护性。
6. 同时统计模型费用、耗时和人工修订时间。

这次案例支持的窄结论是：GPT-5-Codex 在当次大范围重构中覆盖最完整，Kimi K2 提供了较干净但不完整的方案，Claude Sonnet 4.5 速度快却遗漏迁移收尾。真正选型时，应以自己的仓库和自动化验收重复测试，并把任务拆分策略、提示质量与工具环境一并纳入结果。