TL;DR

Software Physics 的核心思想是把物理守恒思维搬进软件工程： 代码库的语义状态遵守守恒律，增量修改后立即检查不变量是否成立，而不是等全量测试跑完才发现问题。 Neo4j + MCP 实现里增量校验 0.1–0.3s，漏改调用点从 20% 降到 0%。

物理守恒为什么能搬进代码库

物理里的守恒律是说：某个量在封闭系统里始终不变（能量、动量、电荷……）。

Software Physics 的类比是：一个代码库的语义状态在「不改坏」的前提下也应该守恒。

具体来说，定义了三条守恒律：

守恒律 1：结构有效性（Structural Validity）

代码图的每个节点（函数、类、模块）和边（调用关系、依赖关系）在修改后仍然语法有效。比如一个函数被删除，它的签名不应该还出现在调用图中。

守恒律 2：引用一致性（Reference Consistency）

每个引用（import、函数调用、类型引用）指向的实体在修改后仍然存在且类型匹配。漏改调用点是工程里最常见的 bug 之一，这条守恒律直接对焦这个问题。

守恒律 3：语义类型正确性（Semantic Type Correctness）

跨模块的类型语义（不只是语法上的类型匹配，而是语义等价性）在修改后仍然一致。比如一个函数返回类型从 int 改成 long，所有依赖该返回值做位运算的调用点都要同步更新。

和传统测试的本质区别

传统测试是事后验证：

改代码 → 跑全量测试套件 → 等待 5-30 分钟 → 发现回归

Software Physics 的思路是即时局部检查：

改代码 → 立即检查三条守恒律是否仍成立 → 0.1-0.3 秒出结果 → 快速反馈

这不是替代测试，而是把「发现问题的时机」从「提交后 CI 跑完」提前到「改完还没离开编辑器」。

实现：Neo4j + MCP

论文给出了具体实现：代码库被建模为持久语义图，存在 Neo4j 图数据库里。MCP（Model Context Protocol）作为 agent 与图数据库之间的通信层。

架构上，每次增量修改后：

  1. Agent 发送修改增量（哪些节点/边变了）给 MCP
  2. MCP 在 Neo4j 上只检查受影响子图的不变量
  3. 增量检查耗时 0.1–0.3 秒
  4. 如果守恒律被破坏，MCP 返回具体违规信息

结果数据（论文给出的关键数字）：

指标 传统方式 Software Physics
漏改调用点比例 20% 0%
增量验证时间 分钟级 0.1–0.3s
误报率 - 极低（未给出具体数字）

20% → 0% 这个数字最值得注意：这是真实仓库上人类工程师最容易犯的错误类型之一。

为什么这个思路值得深究

和上下文租约（Context Lease）是同源的。两者都在问：agent 对代码库的理解怎么在增量修改后保持有效？上下文租约从「信息新鲜度」角度切入，守恒律从「语义不变量」角度切入，最终指向同一个问题——如何在修改过程中维持代码库的语义完整性。

比形式化验证更可落地。完全的形式化验证（TLA+、Coq、Isabelle）要求完整的规格，而守恒律只需要定义「什么东西不应该被破坏」，不需要描述「正确行为是什么样」。这是一个更弱的约束，也更容易在工业项目里落地。

是架构层的约束，不是代码层的测试。它不关心具体函数的返回值对不对，而是关心「图的结构关系」是否被尊重。这使它和单元测试/集成测试形成正交互补——测试验证「行为正确」，守恒律验证「关系不被破坏」。

批评性解读

实现成本被低估了。把代码库完整建模为语义图并维护在 Neo4j 里，这个初始成本不低。对于中型仓库可能值得，对于小型项目可能过度工程。

守恒律的定义是工程选择，不是数学必然。三条守恒律的选择是论文作者拍脑袋定的，不同团队可能有不同的 invariant 需要保护。这个框架的价值在于「有守恒律意识」，而不是「这三条守恒律是完备的」。

「0% 漏改调用点」需要看实验设计。这个数字是否在足够多样化的代码库上验证过？不同语言（动态类型 vs 静态类型）的效果是否一致？论文细节缺失，这个数字暂时只能当参考。

原论文（IEEE Xplore:11655096）