利用AI代理优化形式化验证项目的CI构建效率

从41分钟到12分钟：一次AI代理驱动的CI性能优化实战

持续集成（CI）是软件团队的日常节奏，但当一次构建要等上40多分钟时，这个节奏就变成了煎熬。这篇文章记录了一个Lean 4形式化验证项目如何将CI构建时间从每此提交41分钟压缩到普通提交几分钟、最坏情况12分钟的全过程。

项目中涉及的形式化验证（Formal Verification）技术对大多数读者来说可能有些陌生。简单来说，Lean 4是一个证明助手——一种能让计算机验证数学证明的程序语言，就像代码能编译验证语法正确一样，Lean能验证证明逻辑的正确性。项目里的mathlib数学库有超过150万行社区维护的代码，Lake是Lean的构建工具。整个性能优化的核心，就是让这些工具组合在一起更高效地运转。

一个典型的性能优化困境

这个名为AlgebraicArchitectureTheoryV2的项目，是一个在Lean 4中对软件架构理论进行形式化验证的代码仓库。它有一个耗时的"内核公理审计"步骤（kernel axiom audit），用于机器检查每一条定理都是真正被证明的，没有任何作弊。整个审计涵盖4000多条声明，其中有一个单独构建就要38分钟的代数几何重量级文件。

优化前的CI流程是这样的：每次拉取请求（PR）都要全量重建所有文件，即使只改了一行代码，也得等上整整41分钟。经过三轮优化，成果显著：

构建场景	优化前	优化后
内核公理审计	7分11秒	11秒
普通PR构建	41分钟（总是全量重建）	几分钟（增量构建）
最坏情况（重建最重文件）	41分钟	12分钟

这个成绩单背后有一个反直觉的规律：三轮优化，每一轮直觉指向的"罪魁祸首"最后都被证明是无辜的。真正解决问题的不是某个技巧，而是冷静的剖析过程——这也是性能优化（Performance Optimization）的正确打开方式。

第一轮：审计为什么慢？

第一次优化针对的是内核公理审计步骤。它耗时7分11秒，而构建整个项目时，核心瓶颈是把每个文件都"展开"成可检查的证明，几乎所有的Lean构建时间都消耗在这个被称为elaboration的环节上，它相当于Lean的"编译"阶段，包括类型推断、隐式参数解析和证明检查。

最初的假设是审计过程中执行了过多不必要的完整性检查，但细细追踪后发现，真相完全相反——瓶颈在于一个古老的全量文件扫描逻辑。这个逻辑在项目规模变大后已成明显的性能瓶颈，而当我们把扫描范围精确限制在受影响文件时，审计时间直接从7分11秒降到11秒。

这个发现带出一个关键认知：构建效率优化的第一原则是"尽可能缩小每次变更的影响范围"。将全量扫描改为增量扫描，就是一个典型的对症下药。在我们日常使用的CI/CD工具链中，这个原则同样适用。

第二轮：普通PR为什么每次都要全量重建？

解决了审计后，一般PR仍然维持着每次41分钟的全量重建。当你不理解一个工具的工作方式时，它看起来就像在"偷懒不做缓存"。但排查发现，Lake构建工具其实一直在生成缓存产物（.olean文件），问题出在CI工作流的配置上——每次拉取新代码后，缓存目录没有妥善保留，导致所有文件都要从头开始生成。

修复方式并不复杂：利用GitHub Actions的缓存机制，把构建产物按"改动情况"级联保存，同时优化Lake的增量构建策略。这一轮改动后，普通PR的构建时间从41分钟降到几分钟，基本实现了"改哪里就重建哪里"的预期效果。

这里要说明的是，增量构建（Incremental Build）不是简单的缓存复用，而是对构建依赖图的精细管理。任何一个项目的CI/CD效率优化，都有必要从依赖图的可视化开始做起。

第三轮：单体大文件为何如此顽固？

最硬的一根骨头是一个单独的38分钟构建文件——一个从代数几何构造schemes的复杂证明。在优化之前，这个文件无论改动多少，只要它被触及就必须整体重来，用掉将近40分钟。

这一轮的假设很直接：是不是这个文件的写法有问题，我们应该拆开它？但经过剖析后发现，这个文件的核心依赖链非常紧凑，拆分会触发大量的重复验证，反而可能更慢。文件之所以重，不是因为代码冗余，而是因为数学库自身的依赖关系很深层。

最终方案是对这个重文件做模块化重构，把它拆成多个小模块，同时严格定义这些模块之间的接口。关键点在于，这轮改动让增量构建的粒度大大变细——以前改动一个定理可能牵动整个大文件，现在只重建真正关联的一小节。该文件的重建时间从38分钟压缩到12分钟，整个CI最坏情况也降到了同一水平。

三轮优化中，每轮都涉及大量读日志、跑测试、比对构建产物、尝试不同配置的工作，这些工作技术含量不高但极其耗时。通过引入AI代理，这部分工作变得事半功倍。前两轮由人类工程师和AI在交互式会话中协同完成，第三轮则完全由AI代理根据需求文件自主完成——人类只做两件事：批准要优化的数字目标，验证最终成果。

AI代理如何避免"投机取巧"？

AI代理能高速执行分析，但这里有一个潜在的风险：AI容易用表面漂亮的指标掩盖真正的问题。比如，它可能通过"跳过必要审计"来把41分钟压到5分钟，但这违背了项目作为形式化验证（Formal Verification）项目的基本原则。为了防止AI收敛到"作弊方案"，整个流程中设置了三道防线：

• 优化后的构建必须通过完整的内核公理审计，这是不可逾越的安全底线
• 每一轮改动前后，构建产物必须保持完全一致——优化的是时间，不是正确性
• AI交付的不是一句话结论，而是详细的剖析日志和可复现的步骤说明，让人类能真正理解改动逻辑

这套机制保证了AI代理的高效转化成了真实生产力，而不是自欺欺人。

性能优化的通用方法论

回顾整个优化过程，有几个经验值得任何做CI/CD性能优化的人参考：

• 直觉往往是错的：三轮优化，三轮的初始假设都被推翻，真正的瓶颈永远藏在细节里
• 剖析比猜测重要：与其凭经验猜瓶颈，不如用工具把慢的环节一项项拆开可视化
• 增量是黄金法则：让每次构建只处理受影响的部分，是效率提升的核心杠杆
• AI是很好的执行者，但人类要定好不可妥协的验收标准

现在这份加速后的CI流程已经稳定运行一段时间。如果你也在为自己项目的构建速度烦恼，不妨先别急着加缓存策略或买更强的云服务器——先冷静地完成一轮剖析，找出真正拖慢构建的那一个环节。这一步的价值，可能比任何"最佳实践"都大得多。