CodeScene 公布的一项案例显示，编码智能体在三周内重构了约 30 万行 C 代码，Token 成本约为 4,000 美元，并通过逐帧回放测试验证结果。这个数字足够吸引眼球，但更值得工程团队关注的，不是“智能体一天能改多少行”，而是它为什么敢改、如何证明没有破坏行为，以及哪些基础设施承担了真正的风险控制。
围绕这一案例，实践者也提出了几个关键疑问：30 万行究竟代表多大范围的语义变化？行数是不是合适的生产力指标？如果没有高质量回放测试，结果还能否复现？这些问题决定了这类项目是可迁移的工程方法，还是一次依赖特殊条件的展示。
30 万行是规模指标，不是价值指标
代码变更行数很容易统计，却很难说明重构质量。一次机械化的格式调整、接口迁移或模式替换，可能触及大量文件；一次修复资源生命周期错误的改动，可能只有几十行，却需要更深入的推理。
评估智能体重构时，至少要把“规模”拆成几组指标：
- 覆盖范围：涉及多少模块、调用路径和构建目标。
- 变更性质：是机械替换、结构整理，还是跨模块语义修改。
- 行为保持率：回放结果、测试输出和错误处理是否一致。
- 审查成本：人类花了多少时间检查、回滚和解释改动。
- 返工率：智能体提交中有多少因测试失败或设计偏差而重做。
- 长期收益：复杂度、重复代码、构建时间或缺陷密度是否改善。
因此，“30 万行”说明智能体能够处理很大的修改面，但单靠这个数字，不能证明它理解了 30 万行代码，更不能直接推出相同方法适用于任何 C 项目。
约 4,000 美元的 Token 支出同样只是成本的一部分。完整账单还应纳入回放环境、计算资源、工程师审查、失败重试，以及搭建验证工具的成本。反过来说，如果验证基础设施原本就存在，智能体的边际成本可能会更有吸引力。
真正的核心资产是验证闭环
案例中特别重要的条件，是逐帧回放验证工具。对具有确定性输入和可观察输出的软件，回放系统可以把“看起来没问题”转化为机器可判定的结果：输入同一段会话，记录基线版本与候选版本产生的帧，再比较每一帧是否一致。
这个机制给智能体提供了快速反馈：
- 修改一小批代码。
- 编译并运行固定回放。
- 比较输出帧。
- 失败时缩小差异、修正或回滚。
- 通过后再进入下一批修改。
这比一次性生成巨大补丁可靠得多。智能体并不是凭借一次提示完成整个项目，而是在可重复、可自动判定的反馈循环中逐步推进。
不过，回放工具也定义了验证边界。逐帧一致可以证明被录制场景中的可见行为保持稳定，却未必覆盖未录制输入、并发竞态、内存泄漏、未定义行为、性能退化或不同平台上的编译差异。因此，回放测试应当与单元测试、集成测试、Sanitizer、静态分析和性能基准组合使用。
可以这样搭建一个最小回放门禁
下面是一个可复制的帧目录比较器。它只使用 Python 标准库，逐个计算文件的 SHA-256，并检测缺失、增加或内容变化的帧。
先创建脚本：
mkdir -p tools
cat > tools/compare_frames.py <<'PY'
#!/usr/bin/env python3
import argparse
import hashlib
from pathlib import Path
def digest(path: Path) -> str:
h = hashlib.sha256()
with path.open("rb") as f:
for chunk in iter(lambda: f.read(1024 * 1024), b""):
h.update(chunk)
return h.hexdigest()
def scan(root: Path):
return {
p.relative_to(root).as_posix(): digest(p)
for p in sorted(root.rglob("*"))
if p.is_file()
}
def main() -> int:
parser = argparse.ArgumentParser()
parser.add_argument("baseline", type=Path)
parser.add_argument("candidate", type=Path)
args = parser.parse_args()
expected = scan(args.baseline)
actual = scan(args.candidate)
missing = sorted(expected.keys() - actual.keys())
extra = sorted(actual.keys() - expected.keys())
changed = sorted(
name for name in expected.keys() & actual.keys()
if expected[name] != actual[name]
)
for name in missing:
print(f"MISSING {name}")
for name in extra:
print(f"EXTRA {name}")
for name in changed:
print(f"CHANGED {name}")
if missing or extra or changed:
print(
f"FAIL: {len(missing)} missing, "
f"{len(extra)} extra, {len(changed)} changed"
)
return 1
print(f"PASS: {len(expected)} frames are identical")
return 0
if __name__ == "__main__":
raise SystemExit(main())
PY
chmod +x tools/compare_frames.py
然后把应用自己的构建和回放命令接到门禁中。以下命令中的 ./build/app、参数和测试会话文件都是示例，需要按项目实际接口替换：
set -euo pipefail
make clean
make -j"$(getconf _NPROCESSORS_ONLN)"
rm -rf artifacts/candidate
mkdir -p artifacts/candidate
./build/app \
--replay tests/sessions/main-session.json \
--dump-frames artifacts/candidate
python3 tools/compare_frames.py \
artifacts/baseline \
artifacts/candidate
对于像素输出，如果不同机器会产生抗锯齿、字体或颜色空间差异，精确哈希可能过于严格。此时可以改用像素容差、感知哈希或结构化状态快照，但必须明确允许多大差异，避免把真实回归一并忽略。
C 项目还可以在同一门禁中增加内存与未定义行为检查：
set -euo pipefail
CFLAGS="-O1 -g -fsanitize=address,undefined -fno-omit-frame-pointer" \
LDFLAGS="-fsanitize=address,undefined" \
make clean all
ASAN_OPTIONS=detect_leaks=1:halt_on_error=1 \
UBSAN_OPTIONS=halt_on_error=1 \
./build/app --replay tests/sessions/main-session.json
这段命令假设项目的 Makefile 接受 CFLAGS 和 LDFLAGS。如果不是，需要把 Sanitizer 参数放入项目实际使用的构建系统。
智能体积累的“配方”为什么重要
案例中另一个值得注意的结果，是智能体在推进过程中形成了面向该代码库的操作手册。这样的手册不是泛泛的编程规范，而应记录可重复执行的局部知识，例如：
- 修改某类结构体时必须同步哪些序列化函数。
- 哪些宏看似重复，实际上区分了平台行为。
- 哪组回放覆盖某个模块。
- 哪些目录禁止自动修改。
- 一类重构应拆成多大的提交。
- 出现特定失败信息时，优先检查哪些不变量。
团队可以把这些知识放进版本库，而不是只保留在对话上下文中。下面是一个示意性的配方文件，并非案例披露的具体格式：
id: replace-legacy-buffer-api
scope:
include:
- "src/render/**/*.c"
- "src/render/**/*.h"
exclude:
- "src/platform/**"
intent: "将旧缓冲区调用迁移到统一包装层，不改变帧输出"
constraints:
- "每次最多修改 20 个文件"
- "不改变公开头文件中的 ABI"
- "不得删除错误返回值检查"
checks:
- "make -j8"
- "./build/unit_tests"
- "./scripts/replay.sh tests/sessions/render.json artifacts/candidate"
- "python3 tools/compare_frames.py artifacts/baseline artifacts/candidate"
rollback_when:
- "任何帧发生变化"
- "Sanitizer 报告新错误"
- "性能基准下降超过团队设定阈值"
这种配方有两个作用：一是约束智能体，减少它在每轮任务中重新猜测代码库规则；二是让人类能够审查智能体的工作方法，而不只是审查最终补丁。随着配方积累，团队得到的是一套可复用的迁移系统，而非一次性的聊天记录。
采用前先检查四个条件
这项案例更适合被理解为“受强验证约束的自动化重构”，而不是无人监督的软件开发。准备在自己的代码库中尝试时，可以先检查：
- 反馈是否足够快：构建和核心验证如果需要数小时，智能体的迭代效率会急剧下降。
- 结果是否可判定：测试必须给出明确的通过或失败，而不是依赖主观观察。
- 任务是否可切片：每一批改动都应足够小，能够独立审查、验证和回滚。
- 验证是否覆盖风险：回放验证可见行为，Sanitizer 检查运行时问题，静态分析和人工审查补足剩余盲区。
更稳妥的起点不是直接交出几十万行代码，而是选择一个边界明确、基线稳定的子系统，让智能体完成一类重复性重构。记录接受率、返工次数、人工审查时间和缺陷逃逸率，再与传统流程比较。
30 万行、三周和 4,000 美元证明了大规模代理式重构在特定条件下可以执行；它们没有单独证明重构具有普遍正确性。真正可迁移的经验，是把代码库知识写成配方，把行为验证做成自动门禁，再让智能体在这个边界内高速迭代。