SeigRobotics1. 架构逆转向量：从"代码为源"到"规范为源"的决策反转
1.1 一次架构复盘撕开的裂缝
去年年中，我们团队做了一次大型架构复盘，结论让我特别不安：架构文档里画的模块边界，和代码仓库里真实存在的依赖关系，已经有超过四成的出入。更讽刺的是，这份架构文档是我自己三个月前刚画的，当时还花了不少精力去核对。
我仔细追踪了这些出入的来源，发现它们几乎全部发生在同一个环节——开发人员基于代码做局部重构时，顺手把接口改了、把常量移到别处了，但没有任何机制强制他们把这种变更同步回架构层面。代码是活的，文档是死的，这在传统开发模式下几乎是必然的宿命。
但这一时期正好赶上我们在深度使用AI辅助编程。团队里有几个人用AI生成代码的效率已经到了令人惊讶的程度——原来三天写完的CRUD接口，现在三个小时能搞定。可我很快发现一个更隐蔽的问题：AI生成代码的速度越快，代码和规范之间的裂缝就被撕得越大。因为AI每次生成，都会基于自己的语言模型理解产生一套"看起来合理但未必符合我们既有约定"的实现。代码生成得越多，架构的形状就越不可控。
后来我在调整整个团队的开发流程时，逐渐意识到一个关键点：当AI把"写代码"这件事的成本压缩到趋近于零时，系统架构的真正约束力必须从代码本身前移到代码上游——也就是规范（Spec）层。我给这个转变起了一个名字：架构逆转向量。
1.2 逆转向量的定义与三个演进阶段
所谓"向量"，在物理直觉里有两个属性：方向和大小。放在软件架构语境下，方向指的是架构演进的主导路径，大小指的是这个路径上叠加的工作量偏移。过去二十年，软件开发里架构演进的主导方向是"自底向上的涌现"——代码写多了，自然长出来一些模式，架构师再从这些代码里抽象出架构。方向是：实现 → 架构。
架构逆转向量，就是指这个方向被反转过来，变成：规范 → 架构 → 实现。架构不再是从代码中"提纯"出来的副产品，而是从规范中"铸造"出来的初始条件。AI不是这个反转的原因，但它是让这个反转变得划算的关键变量——因为只有AI能低成本地把规范快速翻译成实现，这种反向路径才具备工程上的可行性。
我们可以把软件开发的演进分成三个阶段，每一个阶段的"向量方向"都不同：
- 第一阶段：代码涌现架构。架构是开发的产物，依赖人的脑内抽象和经验积累后期沉淀。这个阶段里，代码是唯一事实源，文档永远慢于代码。
- 第二阶段：AI加速实现，但架构仍由人设计。AI只是把实现成本降低了，人在架构层的智力负担没有被化解，甚至被放大了，因为你要想的接口、数据、约束越多，AI生成的代码越容易脱轨。
- 第三阶段：规范承载架构，AI负责实现。架构表达为规范，规范是源头，AI将规范翻译成代码、测试、文档、配置。人直接操作的产物从"代码"变成了"规范"。
一个很直观的例子：以前我们要在代码里定义一个订单查询接口，需要写Controller、Service、DAO、DTO、Mapper、单元测试，每个文件都要考虑架构分层。到了第三阶段，我们只需要在OpenAPI规范里定义/orders/{id}的语义、参数和返回结构，AI就能在几十秒内生成一整套符合分层约束的实现。人做的事情是确保规范定义正确——这个工作本质上是一种"元架构"工作。
1.3 为什么说向量方向反转是AI时代的分水岭
我见过不少团队，AI编程用了，效率也提升了，但代码库的熵增速度反而变快了。原因就在于这些团队还是沿着"实现 → 架构"的老路径在走：AI负责快速生成代码，人负责review代码、整理代码，架构边界在高速代码生产中被冲垮。
关键在于，"架构逆转向量"并不是一个修辞性的比喻，而是一个可靠的工程策略：当AI具备了快速生产代码的能力之后，系统的稳定性反而更加依赖规范层的收敛性。你用代码去约束AI，永远约束不住——模型生成本质上是统计性的，每句话都可能不一样。但你用规范去约束AI，约束的是输入和判定标准，这是可以在编译期、测试期、评审期反复对齐的。
我在实践中最深刻的感受是：AI时代的架构师，交付物不是PPT、不是代码骨架，而是一套规范。规范有多清晰，AI生成出来的实现就有多可控；规范有漏洞，AI就会用你完全想不到的方式填补那些漏洞，而这些填补绝大多数是错的。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 规范驱动开发为什么前三十年火不起来
2.1 老选手们：MDA、BDD、契约式设计、API-First
严格来说，"规范驱动开发"（Spec-Driven Development，SDD）并不是AI时代才出现的新词。软件工程历史上至少已经有四波运动试图回答同一个问题：怎样让"先定义、后实现"成为主流的成事路径。
第一波是模型驱动架构（MDA）。它设想用平台无关模型（PIM）描述业务系统，再用工具把它转换成平台相关模型（PSM）和具体代码。理论上很美，实际操作中模型往往写得比代码还抽象，转换规则也极其复杂，最后只有像电信、航空这样预算充足的领域用得起，普通业务团队根本负担不起那个建模成本。
第二波是行为驱动开发（BDD）。它把Gherkin这种准自然语言作为行为规范，把验收标准写得像业务人员能读懂的剧本。BDD的问题在于：写Gherkin的收益大概率要等到自动化测试阶段才能兑现，而Gherkin和真实代码之间的"步骤定义"（Step Definitions）仍然需要手工编写，本质上没有摆脱"人肉翻译规范"这座大山。
第三波是契约式设计（Design by Contract），它把前置条件、后置条件、不变式作为规范和约束，直接嵌入到可执行代码里。这套思路在核心库、框架层面非常有效，但要把它推广到业务系统，需要团队具备很强的形式化思维，大多数人做不到。
第四波是API-First / Spec-First。这是离我们最近的一次浪潮——用OpenAPI / Swagger定义接口契约，然后从契约生成文档、Mock、客户端SDK。它原本是打破前后端协作链条的好实践，但受限于代码生成器的能力：生成的Stub骨架常常需要大量手改，否则离生产可用相距很远。
这些运动的共同命运是：先驱技术方向正确，但受制于"规范到实现的转换器"太弱，最终沦为少数团队的精益实践。我自己也经历过MDA时代的噩梦——那时候我们为了把PIM模型