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模型转成Java代码，定制了一堆模板，维护模板的时间和写代码的时间差不多，这个账怎么都算不过来。
2.2 阻力的本质：规范的"编译成本"
为什么规范驱动开发长期叫好不叫座？核心原因不在于人们不认同"先想清楚再动手"，而在于把规范转换成可靠实现的过程，需要消耗的智力资源太大了。
我把这个成本称作"规范的编译成本"。任何规范，哪怕写得再精确，最终都要有一个转换器把它变成可运行的代码。传统代码生成器有个致命缺陷：它们只能识别规范中"显式"的部分，无法处理隐含语义、上下文信息、领域惯例、演化意图。比如你写了一条业务规则"满300减50"，这个规则不可能靠简单的模板生成器去实现，因为它会牵涉到促销叠加、商品类型、用户等级、订单状态机等等。你必须在生成器里配置大量规则才能达到预期效果，而这些配置的成本并不比手写代码低。
换句话说，传统SDD把"规范"做成了另一种编程语言，只是这种语言更抽象、更难调式、更难测试。它没有消除复杂性，只是把复杂性从代码文件搬到了模型文件里面。这也是为什么大多数团队尝试了一两个迭代之后，就立刻退回到"直接写代码"的舒服区。
但AI的出现改变了这个等式。大语言模型本质上是一个能够理解自然语言、行业术语、场景背景、设计意图的"通用规范编译器"。它不再需要你显式地把每条规则翻译成代码逻辑，它能够从你规范里的一句话、一个词、一段上下文里推断出通用的实现方式。这导致"规范的编译成本"从"极高"降低到了"接近零"。
2.3 AI作为"通用规范编译器"如何打破僵局
我用一个生活类比来解释这个变化：传统代码生成器像一台只能识别标准键盘指令的自动翻译机，你只能输入代码；AI更像一位熟悉你所在行业术语的同声传译，它能听懂你没说出口的潜台词。你说"订单超过1000元要走人工审核"——传统的生成器只会把这当作文本注释，而AI会把这句话理解为一个状态机的分支条件，并且自动画出流程图来跟你确认。虽然你仍然需要给AI讲清楚上下文，但它的"理解能力"已经让"规范 → 实现"这道工序变得极其廉价。
在我实测过的OpenAPI → Spring Boot生成链路里，传统代码生成器（比如OpenAPI Generator）可以生成Controller和DTO骨架，但无法处理好统一响应结构、异常映射、分组校验、鉴权注解等工程细节，需要人工大量修改。换成AI来做同样的事情，我只需要在Prompt中附上"本项目统一返回Result
所以，AI时代的规范驱动开发，并不是把几十年前的老实践原封不动地捡起来，而是在"规范"和"实现"之间装了一台全新的、强大的编译器。这台编译器的存在，才让范式重构成为可能。
3. 范式重构的四个支点：定义、抽象、架构、协作的全链条换轨
3.1 单一事实源从代码移到规范：一次定义、处处生成
过去我们默认"代码是唯一真相源"。在AI时代，这个默认假设是危险的：AI每生成一次代码，就有可能产生一个包含轻微差异的新版本，你无法判断哪个版本是权威的。这时，需要把所有"事实"集中到一个可审查、可版本控制、可用于再生成的地方——规范。
所谓单一事实源（Single Source of Truth），我理解下来需要满足三个条件：第一，它必须能回答"系统应该做什么"的所有问题；第二，它必须可以被AI作为输入直接消费，从而生成实现；第三，它必须是权威的——任何实现上的分歧都以其为准。
在实践中，这种规范不是一个大而全的单体文档，而是有层次结构的规范栈。我习惯把它分成四层：
| 规范层 | 典型载体 | 描述 | 主要消费方 |
|---|---|---|---|
| 业务行为层 | Gherkin / 用户故事验收标准 | 描述业务行为与业务规则，可自动生成验收测试 | 产品、测试、AI |
| API契约层 | OpenAPI / AsyncAPI | 定义接口的语义、请求/响应结构、错误码，可生成服务端实现、客户端SDK、Mock | 前后端、AI |
| 数据契约层 | JSON Schema / DDL | 定义数据结构、校验规则、约束关系，可生成数据模型校验逻辑、数据库迁移 | 后端、数据团队、AI |
| 架构约束层 | ADR / 架构测试规则 / 自定义规则 | 定义模块边界、依赖方向、技术选型、安全约束，可检查实现是否越界 | 架构师、AI、CI |
这四层规范各有不同的生命周期和变更频率。业务行为层最频繁，架构约束层最稳定。它们之间要建立引用关系，而不是各自独立孤立。比如OpenAPI中引用的数据模型，最好是从JSON Schema里复用的同一个定义，这样只要改了一处，AI生成、Mock服务、校验逻辑都会跟着同步变化。
3.2 先抽象后实现——架构设计顺序的倒置
传统开发流程里，抽象是在实现过程中逐步浮现的。你需要先写几个具体类，才能发现它们之间的共性，才能提炼出基类、接口、设计模式。这其实是一种"后置抽象"：先有事实，后有抽象，属于归纳法。
AI时代，这种归纳法的效率变得不够了。既然AI生成具体实现已经毫无压力，那么瓶颈就变成了"你有没有把该有的抽象想清楚"。所以在规范驱动开发中，抽象必须前置：先定义模块边界、依赖方向、数据关系，再用AI去填充每个抽象的内部细节。这个过程是演绎式的——从规范推导出实现。
我在实践中的一个很典型的感受是：以前做一个新模块，我习惯先写一个Spring Boot的启动类，跑通一个Hello World，再一点点往里面填充业务。这套逻辑在AI时代完全反过来了，我现在会让AI直接根据OpenAPI定义生成Controller、Service、Repository的骨架，然后我只review关键的业务逻辑分支和异常路径，因为那些才是真正的智力投入。边界和依赖关系已经在规范里定义死了，AI生成出来的代码天然符合结构约束，不需要我再做大量的重构。
3.3 人机分工：人是规范架构师，AI是系统架构师
这个话题在社区里争议很大：AI到底能不能做架构设计？我的观察是：在规范足够清晰的前提下，AI生成的架构是高度可预测的、可审查的；但"规范本身长什么样"这件事，AI很难替你做好。
举个例子，你要让AI设计一个支付流程的系统架构，如果你只是说"帮我设计一个支付系统架构"，AI会给你一套通用答案——不差，但没用。但如果你在规范里写清楚：支持哪些支付渠道、结算周期如何、对账口径是什么、分布式事务的取舍倾向、幂等键的定义策略，那么AI生成的架构就是一个有血有肉的、完全符合你业务实际的设计。
所以我的结论是：人应该做"规范架构师"——负责定义问题空间的语义、边界、约束、优先级；AI可以做"系统架构师"——负责把问题空间映射到技术方案空间。这个分工并不会让架构师失业，反而把架构师从"绘图员"的角色解放出来，让你真正去思考业务本质。
3.4 团队阅读对象从代码变成规范
这一点对团队协作形态的影响正在显现。以前团队里来了新成员，最好的上手方式是让他读代码——从入口一路跟到SQL。但在规范驱动开发的团队里，第一件要做的事情变成了读规范——看OpenAPI定义了解系统对外提供哪些能力，看Gherkin了解业务行为有哪些分支，看ADR了解架构决策背后的动机。代码反而是按需查阅的。
这不只是阅读材料的变化，还改变了评审机制。传统的Code Review，很多时候是在Review"实现是否符合架构"；在规范驱动开发中，评审重心变成了Review"规范是否表达清晰、完整、无歧义"。代码质量交给AI生成后的自动化检查（单元测试、契约测试、架构守护测试），人工评审聚焦在规范的语义正确性上。
我们团队现在的新人培训路径也因此改了：第一周不碰代码库，专门读规范和契约文件；第二周开始用AI根据规范生成一个小的需求；第三周才允许打开代码仓库，但目标是找到一个"规范和实现不一致"的Bug。这套路径走下来，新人上手速度反而比原来两周读代码更快。
4. 实操图谱：搭建一条"规范生成实现"的流水线
4.1 规范栈选型：OpenAPI、JSON Schema、Gherkin、ADR怎么组合
落地规范驱动开发，第一件事不是写Prompt，而是搭规范栈。我建议不要贪多，从一个贯穿全流程的最小组合开始：
- OpenAPI 3.x：所有HTTP接口的定义载体。它同时是前后端协作的契约、AI生成服务端和客户端的基础输入、Mock服务的数据源。
- JSON Schema：所有跨服务数据结构的定义载体。尤其推荐作为OpenAPI中
components.schemas的引用源，这样可以做到一份数据定义，多处复用。 - Gherkin：核心业务行为和验收标准的载体。不是所有功能都需要写Gherkin，只写那些有复杂业务分支、容易出回归缺陷的核心链路。
- ADR（架构决策记录）：所有"为什么这样做"的载体。用Markdown格式，放在
docs/adr/目录下，编号递增。这些记录让AI在生成代码时能够理解和遵循你的架构偏好。
这套组合不需要额外的重型平台，只要有Git仓库就够了。我推荐把所有规范文件放在同一个Monorepo中的specs/目录，和代码仓库放在一起，实现规范与代码的版本同步，避免"规范在A仓库、实现在B仓库"导致的漂移问题。
目录结构可以参考：
code复制workspace/
├── specs/
│ ├── openapi/
│ │ └── order-service.yaml
│ ├── schemas/
│ │ └── order.json
│ ├── features/
│ │ └── order-flow.feature
│ └── adr/
│ ├── 0001-use-postgres-for-orders.md
│ └── 0002-event-driven-order-status.md
├── services/
│ ├── order-service/
│ └── payment-service/
└── contracts/
└── pact/
4.2 用规范驱动AI生成代码：一次完整演示
我拿一个真实场景演示整条链路：定义一个订单查询接口。
第一步，在specs/openapi/order-service.yaml里写接口规范：
yaml复制openapi: 3.0.3
info:
title: 订单服务
version: 1.0.0
servers:
- url: http://localhost:8080
paths:
/orders/{id}:
get:
summary: 根据ID查询订单
operationId: getOrderById
parameters:
- name: id
in: path
required: true
description: 订单ID
schema:
type: string
format: uuid
responses:
'200':
description: 成功返回订单
content:
application/json:
schema:
$ref: '#/components/schemas/Order'
'404':
description: 订单不存在
content:
application/json:
schema:
$ref: '#/components/schemas/ApiError'
components:
schemas:
Order:
type: object
required: [id, status, amount, createdAt]
properties:
id:
type: string
format: uuid
status:
type: string
enum: [CREATED, PAID, SHIPPED, COMPLETED, CANCELLED]
amount:
type: number
minimum: 0
createdAt:
type: string
format: date-time
ApiError:
type: object
required: [code, message]
properties:
code:
type: string
message:
type: string
第二步，把规范和约束一起交给AI。我用的Prompt大致长这样：
code复制请根据以下OpenAPI规范生成一个Spring Boot 3.x的服务端实现：
- 项目路径：services/order-service
- 使用Java 21，Maven构建
- 返回结构统一使用Result<T>包装
- 使用全局异常处理器，将业务异常转换为规范中的ApiError结构
- 使用参数校验注解，path参数校验格式
- 不生成Controller以外的Service/Repository实现代码，仅生成接口骨架
规范文件：
[粘贴上面的order-service.yaml]
第三步，AI生成的代码会包含：OrderController、Result<T>包装类、GlobalExceptionHandler、ApiError的对应DTO。这一整套在传统开发模式下至少要半天的工作量，AI几分钟就完成了。
第四步，人工检查的要点不是"代码风格是否统一"，而是"规范的语义是否被AI正确翻译"。比如status字段以及枚举值的含义是什么、404场景在什么条件下触发。这些部分是AI最容易犯错的地方，也是最值得投入人工精力的地方。
4.3 验证闭环：规范漂移检测与契约测试
规范驱动开发没有验证闭环，就跟没有编译器的编程语言一样不可信。我强烈建议在CI流水线中加入三道验证关卡：
第一道是规范漂移检测。AI生成的代码，以及后续开发人员的手改，都可能让实际实现跑偏于规范。最简单有效的方式是：在CI中跑一次"实现与规范的差异检查"——比如用openapi-diff工具对比代码中标注的Spring注解路径与OpenAPI定义路径，只要不匹配，构建直接失败。这会倒逼团队在改接口时先改规范，而不是先改代码。
第二道是契约测试。我推荐使用Pact，或者Spring Cloud Contract。消费者（比如前端、另一个微服务）通过契约测试断言调用方期望的请求/响应结构与服务端实现是否一致。契约文件可以从OpenAPI规范中自动生成，减少人工编写测试代码的负担。
第三道是架构守护测试。用ArchUnit写一些断言，比如"Controller不得直接访问Repository""所有Service类必须实现接口""不允许出现System.out.println"。这些规则本质上是架构约束层的可执行版本。在规范驱动开发中，这些规则也是从ADR中派生出来的，比如你定了"订单状态流转必须通过状态机，禁止直接修改status字段"，那么ArchUnit可以进一步检查是否有代码直接调用了order.setStatus()。
4.4 团队协作与评审流程的重新设计
流程变革可能是整个落地过程里最难的一环。我分享几个实际有效、又不用太多行政成本的流程约定：
- 任何新接口、任何接口变更，都必须在开写代码之前先提交OpenAPI改动PR。CI中的规范lint和API diff检查会先跑一遍。代码实现PR可以紧随其后，但前端、测试、Mock都可以基于规范先行启动。
- 核心业务行为的验收标准，必须用Gherkin写进
specs/features/，由AI将Gherkin翻译成测试步骤定义。不建议让AI直接生成测试代码，而是生成"步骤定义骨架"，让测试人员填充业务断言。 - 每次迭代结束时，增加一个"规范同步检查"任务：用AI将代码库中实际路径与OpenAPI定义做差异比对，对于任何不一致，必须修复规范或修改代码，不允许带着差异进入下一个迭代。
- 新增架构决策时，必须用ADR记录，并让AI基于所有ADR的上下文生成实现代码。这样，ADR就成为了AI的行为指南，而不是被遗忘在文档库里的一堆Markdown。
5. 落地过程中的五个深坑与完整排查链路
5.1 坑一：规范写得太宏观，AI自己补脑业务规则
我最早犯的错误是觉得规范写得越"高屋建瓴"越好。结果我用一句话定义了"支持订单取消"这个需求，让AI去生成实现，它自己脑补出了整套取消流程：哪些状态可以取消、退款怎么处理、消息怎么通知。看起来都对，但和我们业务真实要求完全不一致。
排查链路是这样的：我先在代码里发现了一个订单状态枚举里有REFUNDING，但我们的OpenAPI规范里没有这个状态；我沿着这个枚举反查，发现是AI在生成状态机时自己加的；再回到我的Prompt，发现我确实没有定义"哪些状态允许取消""取消后是否退款"这些关键约束。问题根源不在AI，而在规范表达不够精确。
现在我的做法是：每条规范语句必须可以映射到至少一个验收条件。如果一句话无法落地为"当X时应该Y"的可测试断言，那就说明这句话还不够精确。比如"订单取消"要写成"当订单处于CREATED或PAID状态时，用户可以发起取消；取消后订单状态变为CANCELLED；若订单已支付，则创建一个退款记录，退款金额等于订单总金额，状态为PENDING"。
5.2 坑二：手改代码绕过规范，覆盖式生成酿成冲突
AI生成代码之后，开发人员还是会有改动的需求——可能是发现了性能问题，可能是想用更优雅的方式实现。但问题在于，如果这些改动没有同步回规范里，下一次AI再根据规范重新生成时，这些手改内容就会被直接覆盖。
我第一次踩这个坑的排查链路：开发同学在代码里加了一个额外的缓存注解，用来提升查询性能；下次AI重新生成的时候，基于旧规范，把控制器、服务层全部重写了一遍，缓存加注就全部丢失了。更麻烦的是，这丢失并不在编译层面暴露出来，只会在压测时暴露。
解决思路有两个：一是在流程上规定，"任何手改必须对应规范变更"，每次手改代码都要更新ADR或OpenAPI，让AI未来生成时有据可依；二是在工具链上把AI生成的范围进行划分——稳定的领域逻辑由AI生成，不稳定的性能优化、特殊分支、应急修复，全部放在独立的扩展层代码中，用配置开关或者接口实现分离，避免被覆盖式生成吞掉。
5.3 坑三：规范孤岛化，OpenAPI和JSON Schema各说各话
一开始我们没有把JSON Schema和OpenAPI打通，OpenAPI里直接内嵌了Order结构，JSON Schema也定义了同样的Order，两边写的内容还不完全一样。结果就是AI在生成代码时，一会儿跟随OpenAPI，一会儿跟随JSON Schema，产生了两套Order映射，还因为校验规则不同导致线上数据解析错误。
排查链路：我先从报错信息里看到某字段在一种写法下允许为空、在另一种写法下不允许为空；对比之后发现OpenAPI里的定义已经更新了，但JSON Schema还是旧版本。关键教训是：规范之间必须建立引用，而不是复制粘贴。
规范化做法是：在OpenAPI的components.schemas里直接引用JSON Schema文件，OpenAPI原生支持这个能力。这样数据定义只有一个事实源，修改也只需要改一处。
5.4 坑四："合规"但"不正确"的AI生成代码
AI生成代码最容易陷入的误区是"看起来完全符合规范，但业务逻辑根本不对"。举一个我实际遇到的情况：规范里写了"按创建时间倒序返回订单列表"，AI生成的分页查询确实按创建时间倒序排了，但它是在应用层做的内存排序——因为AI觉得这样最直接。数据量小的时候没问题，一旦量大，直接内存溢出。
这个问题的排查链路很长，我花了三天才定位到是AI在PageHelper分页插件和Stream.sorted()之间选择了后者，原因是我的Prompt里没有提到"排序必须下沉到数据库层，应用层禁止大集合排序"。
这类问题没法靠"让AI更聪明"来解决，只能靠两条路：一是在规范层就写清楚约束，把性能、安全、事务边界这些非功能性需求作为显式规则输入给AI；二是引入架构守护测试，把"应用层禁止全量加载集合后排序"这类规则变成自动检查。
5.5 坑五：把新范式塞进旧工具链
最后一个坑比较隐晦，但杀伤力极大。我们尝试在现有项目里推行规范驱动开发，结果发现老项目的代码库结构、依赖关系、权限体系完全不是规范能直接覆盖的。AI根据新规范生成的代码，和旧代码库里的全局配置、公共包、日志规范互相冲突，导致整个分支合并一团糟。
排查下来，核心问题不是AI不行，而是新范式需要新的基础设施。老代码库是在没有"规范为源"的前提下演进多年的，它的结构本身充满了历史包袱和隐性约定，不可能靠AI拿一份新规范就重写干净。
我的建议是：不要在老系统里硬推规范驱动开发。选择一个新模块、新微服务、新项目作为实验田，从零开始搭规范栈、设计流水线，跑通后再逐步把周边系统迁移过来。这个"增量式替换"的策略比"一次性重构"要稳妥得多，也让团队有时间适应新的协作方式。
我自己的实践路径是：用一个全新的订单查询服务做了三个月的试点，跑通之后，再把原来老服务中的接口按规范重写，一点点迁移流量。这种渐进式打法最大的好处是：每次失败的影响范围都能被控制在最小，而团队能从每轮实践中积累专门的Prompt模板和规范模板。
6. 我踩过之后最终沉淀下来的操作习惯
这套模式跑到现在，我手上已经沉淀出一套固定的操作习惯，分享出来给准备尝试的朋友参考。
第一个习惯：规范的粒度永远跟团队对AI的信任度挂钩。最开始，建议把规范写得非常细，细到每个字段、每个分支、每个异常分支都写清楚；等团队熟悉了AI的生成风格，再逐步放宽。不要一上来就走"极简规范"的路线，那等于把大量未定义的业务决策交给了模型，事后追责都找不到源头。
第二个习惯：Prompt中的工程约束不要每次手敲，而是写成一个固定的上下文文件。我会维护一份SPEC_CONTEXT.md，里面包含通用的项目约定：统一返回结构、异常处理方式、日志规范、事务边界、分页策略、安全要求。每次让AI生成代码时，把这个文件作为固定上下文附上。这样既保证了AI生成的代码风格一致性，也避免在每次对话中重复表述相同约束。
第三个习惯：把规范当作代码一样Review，而且Review标准比代码Review更严格。代码Review错了，最多改一行；规范Review错了，AI会把错误放大到整个系统里。流程上，我要求所有规范的变更必须经过至少两个不同角色的确认——一个懂业务的（最好是产品）和一个懂技术的（通常是架构师），任何一方说"不明确"就必须打回修改。
第四个习惯：每个迭代结束，用AI做一次"规范和实现的自动差异审计"。我的做法是让AI读取OpenAPI定义和代码仓库中的所有Controller路径，列出不一致的地方。这个审计不需要额外开发，AI直接就能做，成本极低，但能坚持暴露规范漂移问题。跑过几轮之后，团队意识会发生明显变化：大家会主动去维护规范，而不是把规范当作可有可无的文档。
这套方法不一定适合所有团队、所有项目，但如果你正在被"AI生成代码太快、架构失控更快的"问题困扰，我建议你认真考虑"架构逆转向量"这条路。把原来花在读懂代码上的精力前置到定义规范上，把原来花在重复劳动上的精力留给真正的业务瓶颈设计。方向对了，向量的大小才有意义。