把Maven的决策逻辑压进权重表：ZXing构建产物与Apache Maven逐字节一致
核心概要
一个Maven风格构建工具的决策部分被编译成固定权重矩阵，在沙箱里真实构建了ZXing 3.5.3，产出的JAR与Apache Maven逐字节一致，549个上游测试全部通过。它没有经过训练，也没有梯度下降，权重由程序编译而来；代价是更慢，完整带测试的干净构建耗时约为同一逻辑Python版本的1.42倍。
深度剖析
构建工具中决定下一步做什么的那部分逻辑，现在可以整体放进一张固定的权重表里运行，而不是由一个训练出来、只求大概率正确的模型来猜。 此前的做法是训练模型去预测Maven通常怎么做，这类模型多数时候正确，但构建工具只要错一次就是坏的。 在Maven无法运行、网络关闭、Python版逻辑与Maven自身输出都不可读的沙箱中，网络构建ZXing 3.5.3的父工程及core、javase模块，产出的JAR与Apache Maven逐字节一致，549个上游测试全部运行并通过。
运行方式是查表加算术的循环：每一步用两次矩阵乘法定位权重表中的一行，在该行编码的小型寄存器上做运算，再把结果写回内存。 这套权重由一段受限Python子集写成的构建控制器编译而来，第一版为29625×7的数字表外加7382个常量单元，优化后缩减为26626行，全程零优化器步数。 网络本身不能打开文件或启动javac，需要时把请求写入内存中的固定槽位，由一层不做任何决定的桥接程序带出并写回原始结果；CPU与GPU两个版本在完整构建中发出完全相同的1731次请求且顺序一致，删除或损坏权重文件后构建完全无法进行。
把编译器的胶水代码去掉后，权重表变小、步数变少，但端到端收益有限。 第一版4796191步中，652773步（14%）只是寄存器间复制，另有553333步（12%）是加载常量或跳回循环顶部，这些属于编译器胶水而非构建逻辑。 在指令级模拟器中重放完整ZXing构建后重写编译策略，机器、步图和GPU内核均未改动；仅决策部分从4.15秒降到3.40秒，完整带测试构建从23.12秒降到21.09秒，约为Python的1.42倍（95%区间1.40至1.43）。
启示与展望
演示范围是一个真实项目的一次干净打包构建，即ZXing 3.5.3的父工程与core、javase模块，且跳过Enforcer、Checkstyle、Javadoc与源码JAR；签名、部署以及只在verify阶段运行的内容不在范围内，javac、JUnit、bnd和zip仍作为普通程序运行。作者明确表示，需要更快构建或在意毫秒级延迟时应继续使用Maven，增加GPU也无济于事，因为网络一次只执行一条指令。作者把最有价值的方向列为用这个带已知答案的网络检验解释性工具，并称把编译权重接入训练模型是下一个实验而非已有结果。
作者说明这不是完整的Maven，也不是机器学习：权重由程序编译而来而非学习得到，他们没有尝试训练版本，并预计训练版本会在没见过的项目上失败。迷宫求解的对比每次只运行一次，作者自己提示这些倍数应视为粗略值。优化后的收益在端到端层面有限，因为完整构建的大部分时间仍归javac和JUnit。