把Maven编译进神经网络：字节级一致，慢1.49倍

把一套构建工具的决策逻辑塞进神经网络，还能跑出和 Apache Maven 一模一样的构建产物——这件事有人真做了。JetBrains 团队把 Maven 式构建工具中负责“下一步做什么”的那部分逻辑，编译成了一张固定权重矩阵，并用它构建了一个真实的 Java 库。

结果：输出与 Apache Maven 逐字节一致。带测试的干净构建耗时，是同一套逻辑用 Python 写时的 1.49 倍（95% 区间 1.4 倍到 1.54 倍，30 组配对运行）。

每个 Java 开发者都见过 Maven“思考”的样子：解析依赖、编译、测试、打包。大部分时间花在 javac 和 JUnit 上，但穿插其中的还有一小块琐碎逻辑，决定接下来发生什么——两个模块对库版本意见不一时谁赢，哪些文件送进编译器、带什么参数，一个失败的测试是否中止构建。

他们想验证的是：这块逻辑能不能住进神经网络里。不是训练一个模型去猜 Maven 通常怎么做——那种模型大多数时候是对的，而一个大多数时候对的构建工具就是坏的。他们要的是决策逻辑本身被编译进权重，让网络要么给出完全正确的答案，要么拒绝回答。

做法来自 Handwired 的思路：先写一个程序，再设置网络权重，让这个网络就是那个程序。团队用 Python 的一个受限子集写了一个兼容 Maven 的构建控制器，把它编译成一张 29,625 × 7 的数字表，外加 7,382 个常量单元。没有训练，没有梯度下降，优化器步数为零。

运行它是一个循环：每一步，网络用两次矩阵乘法查表里的一行，在该行编码的小型寄存器文件上做算术，再把结果写回内存。网络不能打开文件，也不能启动 javac。需要时，它把请求写进内存里一个固定槽位，由一层薄桥接把请求送出去、把原始答案写回来。桥接从不做任何决定，所有选择都来自权重。

测试对象是条码库 ZXing 3.5.3，构建其父项目以及 core 和 javase 模块，执行 clean package 并开启测试。产物与 Apache Maven 逐字节一致，构建发生在一个 Maven 无法运行、网络关闭、Python 版逻辑和 Maven 自身输出都读不到的沙箱里。上游 549 个测试全部运行并通过，新构建的 JAR 在 27 项检查中全部正确完成二维码编解码。

两项检查让团队确信工作真的发生在权重里：完整构建中，网络的 CPU 版和 GPU 版做出了完全相同的 1,731 次请求，顺序也一致；而删除或损坏权重文件后，构建根本无法发生。

代价是慢，所有测量场景都慢。Python 直接执行控制器逻辑，网络则要为每条微小指令花一整轮矩阵运算，一次 ZXing 构建要消耗它 4,796,191 步。只看决策环节，网络落后很多；放进整个构建，差距缩小到约 1.5 倍，因为大部分时间归 javac 和 JUnit，两个版本用的是同一套。把网络放到 GPU 上反而更糟——一条接一条执行指令的程序，给不了 GPU 并行的事做。

团队没有动网络，而是改了编译器。他们用指令级模拟器重放一次完整 ZXing 构建，统计每条执行的指令：v1 的 4,796,191 步中，652,773 步（14%）只是把值从一个寄存器复制到另一个，另有 553,333 步（12%）是加载常量或跳回循环顶部。这些是编译器胶水，不是构建逻辑。

改法包括：结果直接落到需要的寄存器，常量随使用它的指令一起走，条件直接编译成分支，循环在底部判断而不是跳回顶部。机器、步图和 GPU 内核都没变，只有那张数字表不同，而且更小。GPU 收益更大，因为它几乎纯按步计费：决策部分 v1 用 27.97 秒，v2 用 21.61 秒，少了 23%，接近步数削减幅度，但它仍是最慢的引擎。

为确认编译器没有偷偷针对某一个程序调优，团队给了它一个无关任务：广度优先搜索的迷宫求解器，编译成 279 行权重。在 3 个 171×121 的迷宫上，纯 Python、Python 调试垫片、神经网络 CPU 版和 GPU 版产生了完全相同的事件序列——每个被访问的格子、顺序、距离都一致。第一个迷宫花了 2,572,288 个网络步；CPU 版耗时是纯 Python 的 161 到 168 倍，GPU 版是 791 到 812 倍。

所以它慢。那还有用吗？团队自己的回答是：想要更快的构建，没有，继续用 Maven；更大的 GPU 也救不了，因为网络一次执行一条指令，构建控制器里没有任何东西能摊到几千个核上。

速度从来不是有趣的部分。他们最终得到的是一个每个权重都有已知含义的神经网络，这很罕见。首先是给拆解网络的人一份答案键：可解释性研究想仅凭权重推断网络在做什么，难的是判分，因为训练过的模型没人知道真相。这个网络自带真相——除七行启动桩外，26,626 行中的每一行都属于控制器 249 个已知函数之一。如果某个工具声称找到了“依赖解析回路”，你可以去核对。

其次是给会猜的模型装精确零件：一个 99% 时候选对库版本的模型，每一百次构建就错一次；编译权重可以把精确子程序放进与学习模型相同的形式——同样的张量、运行时和硬件。团队明确表示，他们还没有把两者接起来，那是下一个实验，不是已有结果。

第三是可哈希的决策逻辑：整个策略就是一个数字文件，从 CPU 移到 GPU，它做出同样的 1,731 个决定、同样的顺序；喂给它一次录制的构建，它能精确重放。你可以对它做 diff、签名，证明某次构建出自它。

团队也划清了边界：这不是全部 Maven，只处理一个真实项目的一次 clean package 构建，跳过了 Enforcer、Checkstyle、Javadoc 和源码 JAR；签名、部署以及只在 verify 阶段运行的东西都不在范围内。插件不是神经的，javac、JUnit、bnd 和 zip 都作为普通程序运行。这也不是机器学习——权重是从程序编译来的，不是学来的。

权重、运行时和完整结果已发布在 Hugging Face 的 shirman/neural-maven 上，包括方法、全部十一个场景、内存使用、环境与证据哈希，以及原始测量数据、两套协议、分析代码和校验和。