1. 为什么需要把业务建模和 AI 编程助手放在一起先说一个我观察到的现象最近两年团队里用 GitHub Copilot 的人越来越多但同样是用了 AI 辅助编程产出质量的差距却大到离谱。有的人用 Copilot 一个下午能把一个带校验、带事务、带异常处理的模块搭得整整齐齐有的人用 Copilot 半小时就生成了看起来像模像样、一跑全是 bug 的代码Debug 的时间比手写还长。差别不在打字速度也不在 Prompt 写得漂不漂亮而在一个很朴素的前提——AI 编程助手需要足够好的上下文才能生成足够靠谱的代码。而绝大多数团队恰恰在最该给 AI 提供上下文的地方什么都没准备。我自己在做应用开发的时候一直在用一套叫 BMADBusiness Model Architecture Design的业务建模方法目前迭代到 v6 版本。这套方法的核心很简单在写代码之前把业务模型拆成角色、服务、数据、事件、规则这些最小单元再把这些单元固化成契约。过去这套契约主要拿来给架构师评审、给开发人员对齐口径但现在我发现它的价值被大大低估了——BMAD v6 产出的结构化契约正好是 GitHub Copilot 最缺的东西。Copilot 不是没有能力它缺的是可靠的、机器可读的上下文约束。拿日常开发里最常见的一个痛点来说需求文档写的是用户下单时锁定库存支付成功后扣减库存超时未支付释放库存。这句话听起来很清楚但代码层面涉及的问题一个都没说清——锁定的粒度到底是 SKU 级别还是订单级别扣减是同步还是异步释放库存时如果订单已经部分支付怎么办这些模糊地带人类开发者在评审时可能还能凭着经验察觉但 Copilot 不会替你想。它只会在你的上下文里找线索有什么用什么。你的注释、接口签名、DTO 结构、枚举定义、异常类型共同决定了它生成代码的上限。所以这篇内容我想换个角度来聊不是单纯讲 Copilot 怎么用也不是单讲建模方法怎么画图而是把 BMAD v6 和 Copilot 放在同一条流水线上讲清楚业务模型如何变成 AI 能消费的约束约束如何变成高质量代码这整条链路是怎么跑通的。适合正在带团队做应用开发的架构师、被 AI 生成代码折磨过的一线开发以及想搞明白到底该怎么给 AI 提供上下文的人。2. BMAD v6 到底产出了什么东西和写需求文档有什么区别先说个容易被误解的地方。很多人一听到业务建模第一反应就是画流程图、画用例图、写一堆 UML 文档然后这些东西评审完就吃灰了。BMAD v6 从一开始就不想往这个方向走。它强调的是产出可执行的契约而不是描述性的说明。2.1 契约和文档的边界在哪里描述性的说明长这样用户可以通过手机号登录登录成功后进入首页。这种描述是人类友好、机器无感的Copilot 看到这句话基本不会有什么正向反应它没法从里面推断出登录接口的入参校验规则也没法知道验证码错误和账号不存在的错误码应该怎么区分。BMAD v6 的契约长什么样呢。简单来说它把业务模型拆成四个层级的产物层级核心内容对应开发阶段的用途全局上下文层业务边界、角色清单、核心领域对象确定模块划分和代码结构接口契约层每个业务动作的入参、出参、校验规则、错误码生成 Controller、Service 方法签名核心实现层业务规则、状态流转、事务边界、并发约束生成 Service 内部逻辑和分支判断领域装饰层事件、消息、定时任务、外部系统依赖生成 MQ 生产者消费者、Job 定义和适配器用登录这个例子对应过去全局上下文里定义用户这个核心领域对象归属账号域接口契约层定义 login 动作的入参是手机号验证码或手机号密码出参是会话 Token校验规则包括手机号格式、验证码有效期核心实现层定义密码错误连续五次锁定账号、锁定后 15 分钟不可登录领域装饰层定义登录成功之后要发送一条登录通知消息。这四层合起来才算一条完整的、可以被消费的契约。2.2 为什么 v6 对 AI 尤其友好BMAD 能迭代到 v6说明它不是一个空中楼阁式的理论框架而是被真实项目反复打磨过的东西。v6 相比早期版本有三个特点和 Copilot 协作特别契合。第一个特点是决策可编码。v6 不再满足于把这个规则描述清楚而是要求把每个决策落到具体的枚举值、阈值、状态机上。比如库存锁定超时 30 分钟自动释放写成契约字典就变成 LockTimeout1800秒状态机出现 ORDER_PAID/STOCK_LOCKED/STOCK_RELEASED 这些显式节点。对 Copilot 来说这种内容是金子——它不需要猜测超时该用多长也不需要自己发明状态名。第二个特点是全局上下文与局部上下文的分离。v6 明确区分了哪些约束是全局生效的比如整个系统统一错误码格式、统一鉴权方式、统一返回结构哪些约束是模块内生效的比如订单模块的库存规则。这个分离太重要了。因为 Copilot 的上下文窗口是有限的你不可能把整个系统的模型全丢给它它看不完也没必要。BMAD v6 已经帮你切好了哪些东西是每个模块生成代码时都要带的哪些东西只有特定模块才需要。我的做法就是把全局上下文单独抽成一份 stable.md作为所有 AI 会话的固定背景模块级契约按需注入缺哪块带哪块。第三个特点是契约的各层粒度适合增量开发。Copilot 这种工具最适合的工作方式是分片战斗——一次只生成一个文件、一个方法、一个测试用例而不是让你一个提示词里塞超长需求让它一次输出整个系统。BMAD v6 的四层结构天然就提供了这个切片依据先按接口契约层生成 DTO 和接口签名再按核心实现层补 Service 逻辑最后按装饰层补事件和集成代码。每一片都足够小、足够明确正好落在 AI 能够稳定发挥的工作区间里。所以 BMAD v6 和普通需求文档的第一个本质区别在于:文档写给人看重点是传达意图契约写给机器和 AI 看重点是消除二义性。第二个本质区别在于文档是一次性的、评审完就过期契约是活的、可以逐层消费的。把这套契约整理好之后Copilot 就不再是一个需要在真空里脑补业务的自动补全器而是一个能踩着结构化定义干活的实现者。3. GitHub Copilot 的能力边界以及它真正需要的输入是什么想把 Copilot 用好第一步不是学提示词的技巧而是搞清楚它的能力边界是什么。这一点上我踩过不少坑也走了不少弯路。早期我以为 Copilot 是个什么都能干的 AI 程序员后来发现这么说太笼统了——它更像一个上下文驱动的联想引擎。它的核心机制是从你正在编辑的上下文里提取线索推断你接下来大概率要写什么。这个机制决定了它的强和弱都非常鲜明。3.1 Copilot 擅长什么、不擅长什么我总结了一张表直接说清楚它在应用开发里的能力边界任务类型Copilot 表现原因标准 CRUD 代码很强模式非常固定训练数据充足DTO、VO 之间的字段转换很强纯机械映射几乎没有业务歧义单元测试骨架、测试用例生成较强能根据函数签名推断边界情况前端组件、接口调用封装较强依赖本地上下文看得见接口定义就没问题脚手架、基础配置、模板代码很强高度模板化复杂业务规则的多分支处理不稳定需要理解规则之间的优先级和互斥关系跨模块的数据一致性保障很弱只能看见当前文件看不见别的模块领域模型的抽象和边界划分几乎不擅长这是架构决策不是代码生成这个表格其实揭示了一件事Copilot 对局部确定性强的任务表现好对全局判断型的任务表现差。CRUD 之所以强是因为字段、表名、接口签名摆在眼前模式又高度雷同它只需要做填空而跨模块一致性之所以弱是因为它压根没有另一边的上下文。3.2 给 Copilot 喂上下文的正确姿势既然边界清楚了接下来的问题就是在我们控制得了的范围内要把什么喂给它喂到什么程度。我现在的做法总结下来是三条红线。第一一定给目标不给方案。很多开发者让 Copilot 写代码时喜欢在注释里写请实现一个库存扣减的逻辑考虑并发使用乐观锁然后让 AI 自由发挥。这个 Prompt 其实是个陷阱。考虑并发是一个方案级别的暗示但到底用乐观锁、悲观锁还是分布式锁取决于业务场景和已有技术栈。更好的做法是描述目标库存扣减必须满足库存量不小于请求量才允许扣减扣减后剩余量回写库存表扣减操作与订单状态更新在同一事务内。至于怎么锁、锁粒度多大让实现者根据约束自己选——而 Copilot 在有明确约束的前提下选出来的方案通常不会太离谱。第二把隐性的规则变成显性的上下文。这是 BMAD 契约介入的最关键位置。业务规则经常散落在代码注释、需求文档、IM 聊天记录里Copilot 完全感知不到。比如优惠券和满减活动互斥这个规则如果不写到当前文件的上下文里Copilot 生成的结算逻辑里就会出现两个折扣叠加的问题。BMAD 契约里的核心实现层专门把这些规则抽成显性条件在开发时注入到相关文件。规则在上下文里AI 看到了生成的代码就会自然带上这些分支。第三按文件粒度组织上下文。我见过最典型的问题是一个开发者为了让 Copilot 生成一个服务类的完整实现把一个包含十几个接口、几千行代码的文件整个粘进了对话结果 Copilot 生成的代码风格混乱、上下文互相干扰产出质量直线下降。正确的做法是把上下文切成背景信息和当前任务两部分。背景信息全局稳定一段话带过当前任务精确到具体的类、方法、字段定义。BMAD 的四层契约天然可以做这个切分全局上下文层和接口契约层是背景核心实现层的规则和领域装饰层的事件定义是当前任务每次带一小块生成一块验收一块。这里我想强调一下Copilot 的输入不是越多越好而是越准越好。上下文越聚焦输出越稳定。这一点在我把 BMAD v6 的契约引入到工作流之后体会特别深刻——以前我为了一次生成搞半天的 Prompt 优化现在百分之七八十的时间花在整理契约和质量校验上Prompt 本身反而变得特别简单基本就是背景 接口签名 规则列表 输出要求四件套。真正把质量拉起来的不是魔法咒语而是背景知识的结构化程度。4. 协同落地的四层路径从业务契约到代码生成的完整流水线前面说的都是为什么要这样接下来进入正题在实际项目里我是怎么把 BMAD v6 的契约文件和 Copilot 组装成一条可复用的开发流水线的。整个过程可以拆成四层每一层对应一种不同类型的输入和组织方式。4.1 第一层契约注册——让 AI 有据可查万事开头难第一层要做的事情是建立契约目录。我的做法是在项目仓库里建一个 contracts 目录按域来组织比如 order_contracts.md、user_contracts.md、payment_contracts.md。每个文件的结构是固定的包括领域概述、角色清单、核心对象定义、接口契约、规则清单、状态机、错误码、领域事件。这一层不需要给 Copilot 看它是给人看的也是后续各层取材料的源头。关键点在于契约文件必须保持与代码同步更新。只要契约和代码不一致了后续所有 AI 生成的内容都会建立在错误信息的沙子上。为了维护同步我有一个笨但有用的习惯每个契约文件顶部都写上最近更新日期和修改原因任何一次需求变更先改契约再让 Copilot 改代码。顺序不能反。先让 Copilot 改了代码再来补契约大概率补出来的东西跟实际行为对不上。4.2 第二层全局上下文注入——每个会话的固定背景有了契约目录之后第二层要做的是给 Copilot 建一份全局上下文文件我一般叫它 ai_context.md。这份文件不用长通常控制在 300 到 500 字之间但必须包含以下内容项目技术栈语言、框架、ORM、消息队列、缓存中间件代码风格约定分层结构、命名规范、异常处理方式、统一返回格式全局错误码规范通用错误码的枚举和含义鉴权与上下文获取方式当前用户怎么获取、权限怎么校验这份文件的作用是省流。在 Copilot 的上下文窗口有限的情况下把它作为每次会话的固定背景就不用每个文件里反复粘贴同样的技术栈信息了。我实测下来的效果是这一步能让 Copilot 生成的代码风格和项目现有代码的吻合度显著提高尤其是命名和包结构这两个重灾区。实际操作的时候我不是每次都手动粘贴 ai_context.md 的内容而是把它配置成项目级注释说明文件放在 .github/copilot/instructions/ 下面。GitHub Copilot 的官方机制支持给仓库配置自定义指令这样它会自动读取这些说明文件作为全局上下文。每个会话、每个文件生成时这些背景约束都会被考虑进去。不需要每个开发者重复粘贴团队里其他人也能享受到同样的上下文红利。4.3 第三层模块任务切片——一次只喂一小块第三层是实际生成代码时最重要的一步。我称之为任务切片。拿到一个 BMAD v6 契约文件后不要试图让 Copilot 一口气生成整个模块而是把它切成五类小任务任务类型输入材料期望输出DTO/入参校验接口契约层的字段与校验规则请求/响应结构体、校验注解数据访问核心对象定义、仓储接口Mapper 或 Repository 实现业务逻辑契约规则清单、状态机Service 方法实现事件集成领域事件定义、消息通道生产者和消费者测试代码接口签名、正常/异常分支单元测试与边界用例每次任务只喂一份材料。比如做订单的 DTO 时我会把接口契约里 createOrder 的字段定义直接当作输入加上一句请按照字段定义生成请求 DTO校验规则以注释行的形式标注。这个任务非常聚焦Copilot 基本不会跑偏。做业务逻辑时我会有意识地给出状态机的显式定义比如订单状态CREATED - PAID - SHIPPED - COMPLETED其中 CANCELLED 可由 CREATED 和 PAID 转移。有了这个定义Copilot 生成的 Service 会自然包含状态流转的合法性校验而不是放一个处处可改的 status 字段。4.4 第四层约束回写——让生成代码反向校验契约这层是我最想强调的因为我们一般说模型生成代码是单向的但 BMAD v6 和 Copilot 的协同应该是双向的。Copilot 生成代码之后我的流程不是直接进 Code Review而是有一个契约校验的环节。具体做法是把契约文件里的规则清单逐条列成表格然后拿生成的代码逐条打勾。像库存扣减必须校验库存充足优惠券与满减互斥锁定超时释放这样的规则在代码里都应该能找到对应的 if 判断、状态判断或事务注解。找不到的那一条就是需要手工修正或者补充提示词的地方。这一步的好处是它把AI 生成代码的正确性这个问题变成了一个可验证的清单问题。你不需要靠运气去碰代码质量你可以拿着契约逐条核对哪条没实现一目了然。我在实际项目中还会把这份校验清单提交到代码评审的附件里评审的人不需要重新读一遍需求文档只需要对着清单看代码效率显著提高了。5. 从契约元素到代码结构的映射关系用一个订单模块讲透要想理解 BMAD v6 和 Copilot 的协同光知道流程还不够最关键的是要掌握一张映射表——契约里的每个元素最终会落到代码的哪个位置。我拿订单模块举个例子因为订单几乎包含了应用开发里所有典型的业务复杂度而且大家都有体感。5.1 六种典型映射关系BMAD v6 契约元素代码落点举个例子业务角色Controller、鉴权注解买家、卖家、管理员 --PreAuthorize(hasRole(BUYER))业务动作Service 方法createOrder、cancelOrder、payOrder业务对象Entity、DTOOrderEntity、CreateOrderRequest业务规则Service 内部 if、校验、事务库存校验、优惠互斥、金额计算状态机状态枚举、状态转换方法OrderStatus、transitionTo领域事件事件类、发布器、消费者OrderPaidEvent、OrderEventListener这张表的价值在于它可以被直接变成 Copilot 的生成指令。比如我让 Copilot 生成订单服务时不是泛泛地写实现一个订单服务而是把表格里对应的内容全部列出来它会非常自然地按契约元素落位生出来的代码分层清晰、结构统一。5.2 完整示例库存锁定与积分发放的约束注入直接看一段实际工作中的例子。假设 BMAD 契约里有这样两条规则规则 A下单时锁定库存锁定数量等于订单商品数量支付成功后才真正扣减库存。规则 B支付成功后发放用户积分发放档位按实付金额计算不足 100 元不发放满 100 元发放 10 积分每再满 100 元增加 10 积分。在没有 BMAD 契约的情况下我给 Copilot 的提示词可能是请实现用户下单和支付成功的相关逻辑。这个提示词太弱了Copilot 生成的代码大概率只有 CRUD锁定库存、扣减库存、判断积分门槛这些规则全都要靠人工后期去补。在引入 BMAD v6 契约模板以后我的一个典型任务提示词会是这样背景订单模块开发技术栈 Spring Boot MyBatis-Plus Redis。 业务规则来自 BMAD v6 契约 order_contracts.md 1. 下单时锁定库存LockTimeout1800秒超时释放 2. 支付成功后扣减库存并向 user_contracts.md 中定义的积分服务发送积分发放命令 3. 积分发放档位实付金额满100元发10积分每增加100元多10分不足100元不发放 4. 库存扣减与订单状态更新必须在同一事务内 5. 优惠券与满减互斥CF_RULE_001。 请实现 OrderServiceImpl 中 createOrder 和 handlePaidEvent 两个方法 事务边界按照规则4设计积分计算用单独方法封装并附单元测试。这个提示词本身不花哨但信息密实。Copilot 生成的代码里createOrder 会带上库存锁定逻辑和 Redis 过期键handlePaidEvent 会带上事务注解和积分计算分支还会自动生成一个 calculatePoints 的私有方法。效果稳定得相当明显——这份代码拿回来基本不用大改评审清单也容易勾。5.3 为什么状态机定义对生成质量影响这么大代码生成过程中我观察到一个特别有意思的现象只要我在上下文里明确定义了状态机Copilot 生成的代码质量会明显上升一个档次。原因其实也好理解——状态机是一个强约束它同时约束了状态字段的类型定义、各种状态转移的合法性判断、非法操作的异常类型。有了状态机AI 不需要臆测订单是否能从 CANCELLED 变成 PAID这种问题它只需要忠实地把状态转移图翻译成代码。这类强约束越多AI 发挥的自由空间就越小出错的可能性也越低。我还发现一个优化技巧把状态机定义在注释里而不只是放在需求文档里。比如在 OrderStatus 枚举的文件头部写上// 状态流转约束CREATED - PAID - SHIPPED - COMPLETED // CREATED - CANCELLED买家取消或超时未支付 // PAID - CANCELLED仅限退款场景 // 其余状态转移均不合法这个注释既是写的给人看的也是写给 Copilot 看的。每次在这个文件里补充逻辑Copilot 都能读到状态约束生成代码时就会自动带上 while 条件判断、IllegalStateException 抛出逻辑不需要额外提示。这件事给我的启发是把契约里最关键的规则同步复写到对应代码文件的注释里是最省 token 又最有效的上下文注入方式。6. 验收环节怎么把关面向约束的评审清单替代凭感觉的 Code Review有了 BMAD v6 的契约和 Copilot 生成代码之后最后一个绕不开的问题是怎么保证质量说实话早期我对 AI 生成代码的态度是看得过去就收下过不了就手动改后来发现这种凭感觉的评审方式效率很低。因为 Copilot 生成的代码表面上的规范程度往往很高——命名统一、缩进对齐、异常处理完整——很容易给人一种代码没问题的错觉但深层业务规则到底有没有实现光看代码很难看出来必须对着契约逐条核对。所以我现在参与评审的时候换了一套做法——面向约束的评审清单。步骤如下第一步从契约文件里抽出规则清单。比如订单模块可能就是上面提到的规则 A、规则 B再加上退款不能超过实付金额取消订单只能由买家操作等。第二步把清单逐条带入生成的代码里找对应实现。规则 A 找库存锁定和扣减逻辑规则 B 找积分计算的阈值和循环退款规则找金额上限校验取消权限规则找角色判断。找到了打勾找不到或代码里逻辑不一致标记出来。第三步对没实现或实现错的规则分两类处理。第一类是 Copilot 没看到约束导致的处理方式是把约束更显式地补充到上下文里重新生成第二类是规则本身在契约里就模糊的这往往不是代码的问题而是建模的问题需要回到 BMAD 契约层把定义补充清楚再生成。下面是我实际用过的一份订单模块评审清单可以做个参考契约规则代码对应实现状态下单锁定库存1800秒超时释放OrderServiceImpl.lockStock() Redis TTL通过支付成功扣减库存与状态更新同事务handlePaidEvent() 中 Transactional通过积分满100发10分每增100加10分calculatePoints() 中 while 循环通过优惠券与满减互斥未找到对应条件判断未通过已补充上下文重新生成取消订单仅限 CREATED 状态StateValidator 中有状态判断通过这份清单可以直接附在评审记录里。团队里其他人看到这份清单不需要重新翻需求文档也能理解评审结论。而且它还会反过来促进契约质量的提升——如果连续几次评审都发现某条规则在代码里反复找不到那大概率说明这条规则在契约里定义得不够清晰需要回炉重写。把质量校验和建模本身连接起来这件事以前靠人力评审很难做到因为人对于规则没实现和规则写得不清楚的边界往往得过且过。但现在有了一份可以逐条打勾的清单这个问题就变的很直白。7. 这几个踩坑场景基本覆盖了协同过程中的大多数意外再好的流程设计实际跑起来也难免遇到各种意外。我在这个组合工作流里踩过不少坑下面挑几个有代表性的说说每一个都是真实发生的不是凭空编的。第一个坑契约写得像需求文档AI 自由发挥的空间太大。刚开始做契约文件时我写规则习惯了用一句话描述比如下单时需要校验库存然后把这个丢给 Copilot 生成代码。结果 Copilot 生成的代码确实校验了库存但用的是直接查库存表的方式完全没有锁定机制。后来我把规则改成两条定义明确的描述——锁库存必须写入 Redis键名 pattern 为 lock:sku:{skuId}:order:{orderId}和锁库存数量必须等于商品购买数量——AI 的生成结果立刻就不一样了。这件事给我的教训是规则描述和 Copilot 的代码生成质量是直接相关的。你用自然语言给它留一毫米的缝隙它就能在里面开出一条自由发挥的大路你把约束写到一百二十分细它反而能交出高度符合预期的产物。第二个坑想让 Copilot 一次生成的东西太多结果人格分裂。有几次我想偷懒在一个提示词里塞了订单创建、订单取消、订单退款三个方法的完整实现要求。Copilot 给出的结果表面上看三个方法都写全了但细看会发现风格极不统一校验逻辑前一个方法用 if 抛异常后一个方法用断言事务一个方法加在类上另一个方法加在方法上。这个问题的根源还是我前面说的任务切片。Copilot 适合在单个文件的局部上下文里做高度聚焦的生成你给它多任务它就会在多个模式间跳来跳去。后来我严格按 BMAD 的切片原则——一次一个方法、一次一个场景——再也没出现过这种问题。第三个坑契约更新后上下文没有同步更新。这可能是最隐蔽的坑。有一次我们改了契约里的积分发放规则从满100发10积分改成满200发20积分但负责生成代码的开发者没有同步更新自己的上下文还是用旧规则去生成结果新代码全是旧规则。这个问题靠 AI 技术本身是没法解决的纯粹是流程纪律问题。后来我把契约文件放在项目仓库里凡是改动必须走 MRMR 描述里必须标注契约变更生成代码时需使用最新版本才算把这个问题压下来。第四个坑也是最容易被忽视的业务团队和开发团队的语言不一致导致 AI 吃到的上下文是变味的。BMAD 契约如果由业务人员写术语可能非常贴近业务语言如果由开发人员转述术语可能偏技术化。两者的差异会直接影响 Copilot 生成的代码风格和准确性。比如业务人员说冻结库存开发人员转述成标记库存状态为锁定这两句话在 BMAD 契约里是有语义差别的。为了避免这个问题我在团队里要求契约文件的措辞保持统一术语定义不能随意替换并且任何一次新增术语都要经过建模评审不能开发人员自己拍板就写进去。8. 从工具协同到团队效率整体工作流的最终形态聊完踩坑我把整个协同工作流串起来说说它在实际项目里最终长什么样。我们现在跑得比较顺的开发路径是这样的需求评审结束后建模负责人先用 BMAD v6 产出契约文件提交到 contracts 目录开发者拿到契约后把全局上下文文件配置好按任务切片生成代码每生成一个方法或一个文件就对着规则清单打一次勾最后代码入库前附上一份约束验收清单。这一套流程跑通之后我的感受是过去很多纯粹的开发时间本质上都花在了猜测和确认上——猜需求里的模糊点确认规则的优先级确认状态转移的边界。现在这些模糊点都前置到了契约设计环节AI 生成的代码天然带着约束分支人力和提醒都省了一大截。我自己体验下来一个中等复杂度的业务模块从契约完成到代码评审通过时间大概是传统写法的三分之一到二分之一。对于一个每周要交付好几个模块的团队来说这个提升非常可观。当然也不是说这套流程没有成本。最大的成本是学习曲线——熟悉 BMAD v6 的建模理念需要时间让团队新人理解契约不是文档而是约束也需要时间。但我觉得这笔投入是值得的因为它换来的不是一个看似强大的开发助手而是一套可以让 AI 稳定发力的工作秩序。往后的扩展方向我也在琢磨两个点。一个方向是把这些契约文件直接转化成更严格的机器可读格式比如 JSON Schema 或 OpenAPI 定义让 Copilot 生成代码之前能先通过轻量校验确保契约结构没问题。另一个方向是把约束验收清单自动化抽取规则描述和代码实现之间的对应关系做成半自动的静态检查工具。这两件事都不难但都需要把 BMAD 契约的粒度再往细里打磨。从 v1 到 v6 的过程里我最深刻的体会是建模方法不是用来画漂亮的图让人欣赏的它的终极价值就是成为人和 AI 之间一门共同讲得清楚的语言。
