架构图3个月变废纸，这个编译器让CI提前拦错|ci|代码|工作流|架构图|电子表格|编译器|调用

Neal Ford和Mark Richards的新书还没上市，一个 side project 已经跑在了前面。作者花了很长时间以为这是纪律问题——团队只要更严谨就行。后来发现是工具问题：架构从来都不是机器可读的产物。

你的 Miro 板不会报警，Confluence 不会阻断合并请求。当实现偏离设计时，唯一的反馈机制是「三个月后发现这坨代码看不懂」。

「架构即代码」卡在最后一公里

Ford 和 Richards 在 O'Reilly Radar 的文章里提出了「fitness functions」——针对架构关注点的自动化治理检查，类似单元测试，但测的是架构。他们引用的工具 ArchUnit、NetArchTest、PyTestArch 都是 solid 的实现。

但所有这些工具都作用于「已经存在的代码」。

作者想做的不是事后检查，而是事前拦截。干预点不同，修复成本天差地别。生产代码里改架构，跟设计阶段改架构，代价可能是 100 倍 vs 1 倍的关系。

编译器设计里有个概念叫 IR（intermediate representation，中间表示）——介于源码和目标输出之间的稳定层，机器可读，验证、优化、代码生成都在这层跑。同样的输入，同样的输出，每次如此。

架构为什么不能有这东西？

不是图，不是文档，是一个有结构的图——节点和边——确定性编译器能读取、验证、编译成可运行代码。CI 能在服务仓库存在之前就拦住问题。

一个最小示例：支付 API 直连数据库

作者放了一段 JSON 配置：payment-api 节点直接连到 user-db 节点。运行 `archrad validate` 后，输出很直白：

「⚠️ IR-LINT-DIRECT-DB-ACCESS-002：API 节点直接连接数据存储节点。修复建议：在 HTTP 处理器和持久层之间引入服务或领域层。影响：测试、存储替换、不变量强制都会更难。」

这条规则的名字很技术，但问题很常识。只是常识在没有工具时，要靠 code review 去抓，靠文档去记，靠项目经理去催。

现在变成了一条可自动执行的 lint 规则。

作者的原话是：「The intervention point is different — and so is the cost of fixing what you find.」干预点不同，发现问题的修复成本也不同。这不是换个说法，是两种完全不同的工作流。

从「应该」到「必须」的管道化

现有架构治理的痛点在于，它活在「应该」的维度。应该更新文档，应该遵循设计，应该做架构评审。但「应该」在 deadline 面前弹性很大。

编译器把「应该」变成「必须」。不是通过文化建设，而是通过把架构描述变成 CI 能 gate 的 artifact。

作者没有展开讲实现细节，但给出了关键线索：确定性编译、中间表示、图结构验证。这三个词组合起来，指向的是一个可复现的构建流程——就像你用 Terraform 定义基础设施，现在用类似的思路定义系统架构。

区别是 Terraform 管的是「有什么」，这个工具管的是「怎么连」。

一个有趣的观察：作者提到「A cache layer gets added. A direct DB call sneaks in. The agreed service boundary dissolves over three sprints.」缓存层加了，直连数据库的调用溜进来了，约定的服务边界在三个冲刺里消融。这三句话没有主语，因为主语是「系统」本身——没有约束的系统会自发熵增。

工具的价值在于对抗这种熵增，而不是指望人凭意志力对抗。