从80%到38%：我在代码库长期演进测试中发现的AI编程真相
三年前，我第一次用AI写函数，感觉找到了编程的终极武器。
今年，当我试图让同一个AI系统维护一个持续演进三个月的代码库时，它把整个项目搞崩了。
为什么独立测评高分，真实场景却集体翻车
EvoClaw基准测试揭示了一个残酷事实：顶尖AI在独立任务中得分80%+，进入长周期真实场景后，ClaudeOpus4.6仅获得38.03%分数。这个断崖式下跌不是个别现象，而是行业普遍困境。
问题根源在于评测范式本身。传统benchmark聚焦静态代码快照，AI完成修复即告成功。但真实开发是动态演进的——数月前的微小bug经版本迭代后像滚雪球一样越来越大，最终导致系统崩溃。
我测试过多个主流框架，发现一个共同规律：任务执行顺序越靠后、所处DAG层级越深，分数和解决率就越低。饱和函数外推结果证明，即便最优的Opus4.6，累计分数也会被卡死在45%左右的渐近线上。
DeepCommit自动化流水线的技术突破
研究团队提出的DeepCommit框架解决了关键问题：通过Agent驱动的自动化流水线，将嘈杂的Git开发记录重构为可验证、功能内聚的里程碑任务依赖图。
核心设计包含三个阶段：Git历史预处理、Agent驱动的DAG构建、里程碑环境配置与验证。迭代式修复循环确保了可执行性——当commit无法应用、接口对不齐、编译大面积报错时，Agent主动分析报错日志、动态修改Dockerfile。经过反复迭代，最终实现正确收集87.1%的原有测试用例。
这个框架的创新点在于引入了里程碑概念，对软件演进历史进行语义完整性重构，兼具依赖关系保留能力。
召回率上升、精确率崩溃：技术债的本质
拆解分数后发现一个反直觉现象：召回率几乎呈线性增长，AI始终擅长实现新目标功能。真正的瓶颈在于精确率——Agent难以维护现有系统，回归错误积累速度远超修复速度。
错误链分析框架揭示了失控的底层逻辑：新问题产生速度不会加快，模型甚至会被动修复部分历史错误，但前置错误累积速度远超修复速度。这种不对称性最终导致技术债破产。
实践应用：如何正确使用AI进行长周期开发
基于上述发现，我总结出三条关键原则。第一，降低单次任务复杂度，将长期项目拆解为独立可验证的里程碑单元。第二，建立回归测试防护网，在每个里程碑节点强制执行完整测试套件。第三，监控精确率指标而非仅关注召回率，当精确率开始下滑时立即介入而非继续迭代。
AI编程正从写代码向系统治理转折。理解这个范式转变，才能真正用好AI工具。
