智能体用三周重构老游戏代码，全程靠逐帧回放验收
CodeScene 发布案例研究：一个编码智能体在三周内重构了《街头霸王 III：三度冲击》开源反编译项目约 30 万行 C 代码，消耗 token 约 4000 美元，覆盖 726 个文件、2903 次提交、252055 行改动，Code Health 从 5.6 升至 10.0。保障机制包括 CodeHealth MCP Server 的确定性评分，以及逐帧比对回滚状态哈希的回放轨迹测试框架；智能体还自行整理出含 22 个方案、82 条辅助说明的重构手册。
编辑标为信号级，适合持续跟踪。
本页目录11 节
记录
信号正文
#CodeScene 发布了一项案例研究：一个编码智能体在三周内重构了规模达 30 万行 C 代码的代码库，token 消耗约 4000 美元。过程中共涉及 726 个文件、产生 2903 次提交、改动 252055 行代码，Code Health 评分由 5.6 提高到 10.0。该代码库源自《街头霸王 III：三度冲击》的一个开源反编译项目。
CodeScene 创始人 Adam Tornhill 在文中表示，从事大型系统开发 30 年来，他头一回见到他所说的大规模超人类 AI 表现。
两项支撑机制
其一，CodeHealth MCP Server 给智能体提供了一个可优化的确定性评分，这个评分既是质量信号，也用来判断某次转换是否带来正面效果。
其二是正确性保障：回放轨迹测试框架逐帧比对回滚状态哈希，于是每次改动之后都能检验系统行为。
智能体自己写出的重构手册
更新颖的地方在于智能体工作中自行积累的内容。它们并未套用固定的重构目录，而是边做边攒出一套重构手册，最后得到 22 个方案、82 条辅助说明，其中既有 Extract Function、Guard Clauses 这类常见转换，也有专门针对该代码库的方案：
- Shared Index Range：应对只有起止范围不同的重复循环
- Action Parameter：应对主要差异在于所调用函数的重复控制结构
- Uniform Step Table：把异构调用转成表驱动分派
那些失败的尝试同样被记了下来，包括导致 Code Health 评分下滑的转换。
模型选择
团队最后让 Claude Opus 承担了大部分工作，并称在识别与记录逐步成形的模式上，搭配 Opus 的 Claude Code 比搭配 Sol 的 Codex 明显更强。换用较小模型执行任务时，文件评分往往停滞不前，看上去像是撞上了无法再突破的局部最优点。
从业者的分歧
LinkedIn 上的反馈分歧明显，争论焦点不是事情有没有发生，而是这一结果究竟能说明什么。
Paolo Perrone 主张认真对待：他读过的大多数重构成果都以测试套件全部通过为前提，可这只能证明测试没失败；而针对格斗游戏做轨迹回放，门槛要高得多。Omda Response 首席技术官 Mats Iremark 说自己做过类似的事，并形容 CodeScene MCP 加当前智能体的组合几乎等同于作弊。
怀疑者更在意适用范围。技术负责人 Konrad Otrębski 追问这些更改是否已经合并、是一次大合并还是分多次完成，以及这是否只是拿开源代码做的实验。参与该工作的两名工程师之一、NeoSee 首席技术官 Daniel Webb 答复说，更改经由 54 个拉取请求合入了一个分支版本的 main 分支。Otrębski 接着抬高门槛：真正的考验是把这种重构服务交给 Grafana 这类知名开源项目，并以合入 master 分支作为完成的定义。
Tracy Bannon 不认同把结果说成完美。Denis Baltor 则对智能体给出的方案本身存疑：DRY 针对的是知识与意图层面的重复，而非一模一样的代码行，若把仅范围不同的循环当作重复，可能把两者混为一谈。Asko Nõmm 提出方法论层面的疑问：Claude Code 与 Codex 各自针对自家模型调优，因此很难分清结果有多少衡量了模型、多少衡量了测试框架，成本也会以同样方式变动；此外架构并未被衡量，代码看着健康，根本性问题或许日后才浮现。
尚未解答的问题
Marc Bouvier 问非功能行为有没有改善，毕竟帧率、内存占用和输入延迟对游戏都关键，Webb 说他们正请一位性能专家加入。有人问测试框架能否捕捉细微的帧时序回归，他答可能没有明确答案，因为该框架以提交前钩子方式运行，有些故障在被观察到之前就已修复。谈到差异规模，他同样直白：若不熟悉代码、又不再逐行审查，一次差异能有多大？他没有下结论。
回放轨迹测试框架之所以奏效，是因为反编译游戏能提供确定性的逐帧回放。多数遗留系统没有与之对等的判定手段，这也正是重构它们风险所在。Tornhill 写道，自动化测试与等价性检查是绝对必要的保障，而这恰好把担子压在不健康代码库通常最缺的东西上。
团队自己的取舍也印证了这点。Webb 表示他们考虑过他用过的 Gov.UK 海事许可代码库，但它健康程度过高，不适合后续研究；选这款游戏，部分原因是团队自己也玩它，因而也是它的用户。
下一步
这次改进产出了同一系统的两个功能等价版本，Code Health 分别为 5.6 和 10.0。团队将与隆德大学合作研究，让学生用前沿模型在两个版本中各自实现功能，再比较成本与质量。
另两个抢眼的数字属于未来研究，而非本次案例研究：CodeScene 预计该改进能让 AI 引入的缺陷减少约 70%、token 浪费减少约 45%，但两者都是依据其早期研究推算，并非本次实测所得。真正实测的只有 4000 美元成本与三周用时。
为什么是现在
为什么重要
#这条信号展示了一条可复制的路径：用确定性质量评分和逐帧行为比对作为智能体的验收信号，让大规模重构从「跑测试」升级到「行为等价」。但它同时暴露了前提条件——反编译游戏能逐帧回放，而多数遗留系统没有等价判定机制。工程团队应该关注的是，自己的代码库能不能造出这种判定信号。
背景
技术背景
#Code Health 是 CodeScene 提出的代码可维护性评分，把复杂度、重复、耦合等结构问题折算成一个可比较的数值，便于智能体朝确定目标优化。回放轨迹测试是确定性系统里常见的手段：在每次更改后重放固定输入序列，逐帧比较状态哈希，任何行为偏移都会导致哈希不一致。MCP 是让模型调用外部工具和数据的协议，这里用来把质量评分暴露给智能体。
关注人群
谁该关注
#下一步
学习路径
#- 先读 CodeScene 的原始案例研究，弄清 Code Health 评分口径和回放轨迹测试框架各自衡量什么，避免把评分提升直接等同于质量提升。
- 再对照自己团队的代码库，问一个具体问题：是否存在一种确定性、可自动比对的行为判定，能在每次改动后回答「行为没变」。
- 然后阅读关于「完成判定与验收信号」的背景知识，理解为什么长时程智能体最难的不是执行而是知道何时算完成。
- 最后选一个中等规模的重构任务做小范围试点，记录评测信号是否真的能拦住一次错误改动，再决定是否扩大。
关系网络
在技术网络中的位置
#当前技术与相邻技术、技能和背景知识的连接，点击节点可继续探索。
延伸思考
后续问题
#- 同样的方法迁移到没有逐帧回放能力的业务系统时，什么可以替代状态哈希作为行为等价的判定信号？
- 54 个拉取请求中，有多少改动经过人类逐行审查，有多少只依赖自动化验收？
- Code Health 从 5.6 到 10.0 之间，架构层面的问题是否也被解决，还是只被移到了评分看不见的地方？
- 团队报告的 4000 美元只是 token 成本，人工审查、测试框架搭建和失败尝试的工程时间成本是多少？
发布记录
收录于
#收录这条信号的技术简报，新的在前；最后一行是它那一周的周回顾。标签是它在那一期所在的栏目。
来源参考