破解长时演化下的“AI失控”困局：EZDML模型驱动 + 若依框架 + AI MCP的确定性软件工程实践

当前生成式 AI 辅助软件研发已经从初期的“代码补全”走向“端到端生成”，但在企业级业务系统的实际落地中，普遍面临“前三天惊艳，第三周崩盘”的困境——随着业务需求的长时演化与持续迭代，AI 盲目直接修改源代码极易引发上下文爆炸、跨层修改不一致、逻辑破坏及无法回滚等“AI 失控”问题。本文基于 EZDML 若依开发平台（EZRY）的工程实践，详细阐述如何通过 EZDML 模型驱动（单一事实来源）、RuoYi 模块化代码框架（物理隔离与受控扩展） 以及 原生 AI MCP 协议（原子操作、静态校验与快照回滚） 的三位一体架构，为 AI 构筑坚实确定性的工程围栏，彻底破解长时演化中的失控风险，实现高可靠、可持续迭代的现代软件工程范式。

一、引言：AI 辅助编程的“甜蜜期”与“第三周崩盘法则”

过去一年多里，几乎所有研发团队都体验过大语言模型（LLM）带来的效率震撼：在聊天窗口中输入一段提示词，AI 就能在几秒钟内生成一段逻辑完整的 Controller、CRUD 接口，甚至一个完整的前后端系统。

然而，当兴奋的开发者试图将这种模式真正引入企业级严肃业务系统的持续演化时，却往往会撞上一堵无形的墙。业内开发者常常戏称之为**“第三周崩盘法则”**：

• 第一周（蜜月期）：从零起步，功能简单，AI 生成的初始设计和 CRUD 代码让人惊呼生产力飞跃。
• 第二周（复杂期）：业务需求开始追加，增加了状态机、复杂外键关联、按组织/部门的数据权限隔离、明细行的级联计算以及多端校验，代码行数迅速突破数万行。
• 第三周（崩盘期）：长时演化下的迭代真正到来——用户要求“把某个选填字段改为根据角色动态必填，且在保存时扣减库存并触发审计日志”。此时让 AI 修改代码，灾难接踵而至：AI 改了 Java 实体却漏了 MyBatis XML；改了前端页面却忘了在后端加安全校验；为了修一个 Bug 顺手重构了一个公共方法，导致另外三个业务模块悄然报错；最致命的是，AI 面对庞大的代码库产生了严重的上下文幻觉，前言不搭后语，甚至进入无限循环。

最终，工程师只能把 AI 改乱的代码彻底推倒重来，或耗费数倍的人工精力去排查暗病。

为什么 AI 辅助编程在单次任务中表现惊艳，但在长时演化与持续迭代中却极易失控？

二、深度剖析：长时演化下“AI 失控”的四大本质根因

企业级业务系统从来不是“一锤子买卖”，它具有极高的生命周期长度与变更频次。在持续演化中，让 AI “像人一样直接在源文件上改代码”的模式存在四大根本性缺陷：

1. 散弹式修改（Shotgun Surgery）与跨层不一致

在典型的企业应用开发中，同一个业务事实往往被机械地分散在 6~8 个不同技术层中重复表达：

• 数据库 DDL（字段类型、长度、非空、索引、外键）；
• ORM 映射与实体（JPA、Java Domain Entity、MyBatis XML / ResultMap）；
• 数据访问与业务层（Mapper 接口、Service、ServiceImpl）；
• 控制器与协议层（Controller、REST DTO、Swagger 描述、权限注解）；
• 数据与字段权限（Shiro 权限字、数据范围过滤、行级 SQL 拼接）；
• 业务校验（前端 JS 校验、后端 Bean Validation / 规则拦截）；
• 用户交互界面（Thymeleaf / Vue 表单元素、列表表格、搜索区）。

当需求发生微调时，人类开发者都需要小心翼翼地同步修改这 8 处代码。而把这个任务交给 AI 时，AI 常常“按倒葫芦浮起瓢”——修了 Java 实体却遗漏了数据库约束，改了前端表单却遗忘了后端防篡改校验，造成严重的安全隐患和业务逻辑断层。

2. 局部视野导致的“上下文爆炸”与“认知漂移”

大模型的有效注意力和上下文窗口是有限且昂贵的。当系统经过多轮迭代后，几十个表、几百个文件，源码 Token 动辄数百万。AI 无法把整个代码库的细节全部塞进上下文，只能管中窥豹。失去了全局约束和架构大局观的 AI，其输出必然退化为局部妥协，产生严重的“认知漂移”和事实幻觉。

3. 代码生成与手工代码混杂引发的“破窗效应”

许多传统的代码生成工具是一次性的，生成完脚手架后，开发者和 AI 开始直接在生成文件上修修补补。随着时间推移，生成的标准代码和手工定制逻辑紧密交织在一起。当下一次业务结构变迁时，没有人敢重新生成代码（因为会覆盖已有定制），也不敢轻易让 AI 大面积重构代码（因为无法预测会破坏什么）。系统迅速陷入“改不动、不敢动”的死锁状态。

4. 缺乏契约验证与不可逆操作风险

传统的“聊天窗口让 AI 给出一段代码，人或 Agent 盲目打补丁替换源文件”的操作方式，缺乏严格的工程闭环，导致不可逆的操作风险。

三、破局之道：EZRY 的三位一体确定性软件工程范式

要彻底解决 AI 在长时演化中的失控问题，思路绝不是“祈祷大模型智商爆发”，而是改变 AI 的工作界面与协作协议：

核心破局思想：

1. 抽象提升（模型驱动）：将 AI 从琐碎、散落的低层源码中解放出来，将开发焦点提升到以高维模型为“单一事实来源（SSOT）”；
2. 工程物理防护（代码框架）：通过严密的分层架构，将生成代码与底座物理隔离，确立严格受控的三层插槽扩展体系；
3. 协议围栏与沙箱控制（AI MCP）：通过 Model Context Protocol 限制 AI 的行动自由度，提供乐观锁、变更预览、原子提交、静态自检与历史快照回滚。

这种三位一体的组合，构建了一条**“需求变更 => 模型微调 => 规则校验 => 代码自动发布 => 编译运行与验证 => 回到模型”**的确定性闭环。

四、支柱一：EZDML 模型驱动 —— 打造长时演化的“单一事实来源”

在 EZRY 体系中，模型不是绘图板上的死图纸，而是系统全生命周期的“可执行业务契约”。

1. 一个模型承载全栈语义

一张 EZDML 业务表或业务视图，在定义时就内嵌了系统的全景信息：

• 存储语义：字段名、中文标签、物理类型、长度、精度、可空、主键、外键、索引；
• 界面语义：字段编辑器类型（文本、数字、富文本、单图、多文件、下拉字典）、显隐策略、表单分组（sheetGroup）、列表列宽、多维搜索与导出设置；
• 校验语义：必填（required）、最大长度、数值极值区间、格式正则，自动驱动前端与后端两次校验；
• 权限与范围：操作权限、字段级访问权限（运行时 PURVIEW 过滤）、租户隔离（org_id）、逻辑删除（del_flag）与角色数据范围；
• 动态行为与生命周期：挂载在模型节点上的 ScriptRules 后端事件规则。

当字段属性或业务规则变化时，开发者或 AI 只需要在模型中修改一次，平台即可自动将变更精准同步至数据库、后端 Entity、Mapper XML、Service、Controller、校验规则、前端页面以及 REST 接口文档，从源头消灭了“散弹式修改”导致的代码撕裂。

2. 高密度 Describe 描述字：让 AI 远离上下文爆炸

传统将上百张表的 DDL、实体代码喂给 AI 会迅速吃满 Context Window，且信息充斥着数据库方言与样板代码的噪声。
EZDML 独创的 Describe 描述字 是一种接近 Markdown 的高信息密度表结构语言：

mes_work_order(生产工单)
-------------------------------------
work_order_id(工单ID)       PKInteger   //<<自增长>>
order_no(工单编号)          String(32)  //<<非空>>
product_id(产品ID)          FKInteger   //<<关联:mes_product.product_id>>
plan_qty(计划生产数量)      Float(18,4) //<<非空>>
actual_qty(实际完成数量)    Float(18,4) //<<缺省值:0>>
status(工单状态)            Enum        //<<缺省值:0>>状态(0待排产 1生产中 2已完成 3已取消)
dept_id(车间部门)          FKInteger   //<<关联:sys_dept.dept_id>>
remark(工单备注)            String(500)

通过 Describe 语法，数十张表复杂的外键关系、字段语义和约束可以在极少的 Token 消耗下被 AI 瞬间理解。AI 面对的是紧凑清晰的领域语义，而不是浩瀚的代码海洋。

3. 物理存储与业务视图解耦

实际业务演进中，业务逻辑经常不同于物理表结构。EZRY 允许模型层将二者彻底解耦：

• 同表多业务视图：同一张物理商品表，可以派生出“管理员全量管理视图”、“销售员端我的商品视图（自动带本人过滤）”以及“前台选品视图”，各自配置独立的表单字段、查询条件与权限规则，物理表保持单一稳定；
• ListSQL / ViewSQL：面对多表连接、复杂统计报表，直接在模型中声明 SQL 视图，同时无缝复用框架的分页、多字段搜索与权限过滤；
• 只读伪表承载纯接口：借助系统伪表 ez_dual 作为元数据锚点，将非 CRUD 的复杂纯接口（如多步结算、第三方数据推送）统一纳入标准 Controller、鉴权与规则上下文生命周期。

五、支柱二：RuoYi 代码框架 —— 物理隔离与三层受控扩展体系

为了防止 AI 在长时演化中将代码改乱，EZRY 在后端工程结构上做出了精妙的架构隔离设计。

1. 业务生成代码的“物理隔离”与“无痛再生”

EZRY 采用清晰的多模块组织方式：

[!IMPORTANT]
“生成物即消耗品”原则：
ruoyi-ezpub 目录下的所有 Entity、Controller、Service、Mapper、Rule、XML 和后台 HTML/Vue 代码，均被视作模型的生成物。开发者或 AI 绝不应直接在 ruoyi-ezpub 源码文件中手动涂抹业务逻辑。
只要模型完备，即使把 ruoyi-ezpub 整个清空重新发布，系统依然能无损重建。这种设计让系统在演进迭代中彻底甩掉了历史包袱。

2. 井然有序的“三层扩展防护网”

那么，当系统面临标准 CRUD 无法满足的复杂定制需求时，代码应该写在哪里？
EZRY 建立了严格的三层递进扩展机制，引导开发者和 AI 选择“最小影响半径”的实现方式：

第一层：ScriptRules（运行期后端业务事件规则，绝对首选）

业务逻辑不应散落在 Service 的各处代码中，而是绑定在模型的生命周期事件上：

• 完整生命周期：
  • 进入新增页：BEFOREADD => ADD
  • 新增保存：PREADDSAVE => ADDSAVE => INSERT => ADDSAVED
  • 进入编辑页：BEFOREEDIT => EDIT
  • 修改保存：PREEDITSAVE => EDITSAVE => UPDATE => EDITSAVED
  • 动态交互联动：CELLCHANGE（单元格联动查库回填）、BEFORERESSEL（关联资源动态过滤）
• 上下文强隔离：规则发布为独立的 Rule 方法，由 Controller 上的 @EzRule 统一拦截调度。
• 安全不变量保障：所有的用户信息、部门信息强制从服务端可信上下文（USERID、ORGID）获取，严禁采信前端提交的身份字段；“前端负责交互体验，后端规则负责终极事实”。

第二层：UILogic（前端视图插槽）

在页面模板的固定插槽（如表单底部脚本、自定义按钮区）增补 HTML/JavaScript，不破坏主框架结构。

第三层：BusinessLogic（后端模板精确插槽）

当必须扩展 Service 内部私有方法或替换特定 Mapper XML 时，通过模型中的精确命名插槽写入，代码生成器在编译期原样注入到特定位置。

六、支柱三：原生 AI MCP —— 给大模型戴上“紧箍咒”

为什么在 EZRY 项目中，严禁 AI 直接编辑项目源码，也严禁直接用文本编辑器改写 .dmj 模型文件？
因为缺乏校验机制的文本篡改，分分钟会破坏模型的内部对象引用标识，导致代码生成模板报错崩溃。

EZDML 原生提供了基于标准 Model Context Protocol (MCP) 的智能体交互管道。AI 扮演的不再是一个漫无边际的代码打字员，而是一个被放置在安全沙箱中的**“受控专业建模师”**。

AI MCP 的五大安全控制环（Guardrails）

1. Revision 乐观锁机制：AI 发起的一切读取与操作均绑定当前模型的 Revision 版本号。若工程师在图形界面中手动改动了模型，AI 的旧请求会被立即判定为冲突阻断，彻底消除“代码被旧认知覆盖”的灾难。
2. Changeset Preview 机制：AI 提出的任何变更，必须首先在内存副本中演练，输出详尽的 Diff 预览清单。在未经过明确的审查通过前，绝不对真实模型动哪怕一个字段。
3. Atomic Apply 原子提交：不管是创建 16 张表的大型子系统，还是调整 10 个字段的关联，所有变更要么全部生效，要么全部撤销，绝不留下畸形的半拉子结构。
4. 自动化静态校验网关：MCP 在正式持久化前，强制调用 EZDML 底层的规则自检引擎：
   • 表名、字段名是否重名或包含非法字符；
   • 字段长度、数据类型与数据库方言是否匹配；
   • 外键引用的目标表和目标字段是否存在；
   • 字段删除或重命名是否导致其他视图、规则产生悬空引用（Dangling Reference）。
     只有当自检结果达到“0 错误、0 警告”时，才允许写入。
5. Checkpoint 快照时光机：每一次正式修改落地前，系统自动保存完整的历史 Checkpoint。任何一次不满意的演化，都可以随时一键回滚到任意历史时间点，试错成本被降为零。

七、实战长时演化：以商城与交易订单系统为例

为了验证该架构在真实世界演化中的抗失控能力，我们以一个典型的商业系统长时演进过程为例：

阶段一：初始建模 —— 基础表结构与若依权限绑定

• 需求：构建商品表（trade_product）、交易订单表（trade_order）与订单明细表（trade_order_item）。
• AI MCP 动作：

  1. 读取本地若依核心权限模型，引用现有的 sys_user 与 sys_dept；

  2. 使用 Describe 语法提交三张核心实体，挂载外键关系；

  3. 执行网状布局算法，自动计算外键权重拓扑并排列连线；

  4. 静态校验通过后，自动驱动代码发布，生成初始的 Controller、Entity、Mapper 及后台管理页面。

阶段二：长时演化 1 —— 页面语义丰富与前后端校验加固

• 需求追加：商品增加图集（images）、富文本详情（detail）；库存为必填且必须大于等于 0；销售价格必须在 0.01 到 999999 之间；商品名称不允许重复。
• 失控防范表现：
  • AI 无需修改任何 Java 或 HTML 文件，直接通过 MCP 为 trade_product 字段配置 required、valueMin、Editor=RichText；
  • AI 在模型的 ScriptRules 中添加 TradeProductRule_SaveCheck 规则，挂载到 ADDSAVE,EDITSAVE 事件，使用参数化 SQL 查询同名记录；
  • 重新发布后，系统自动在前端生成即时校验，并在后端保存时自动拦截非法请求，数据库唯一约束同步兜底。

阶段三：长时演化 2 —— 跨表联动（CELLCHANGE）与行级数据权限隔离

• 需求追加：
  1. 录入订单明细选择商品后，界面必须自动联动查库带出商品的最新单价，并计算小计金额；
  2. 普通销售员只能查看并维护自己创建的商品与订单，经理可查看本部门所有数据，管理员可看全量数据。
• 失控防范表现：
  • 动态联动受控实现：AI 通过 MCP 在明细表上配置 CELLCHANGE 规则，由后端 Java 规则根据传入的 productId 查询真实单价并回填，避免了在前端 JS 中写死价格可能导致的“客户端随意篡改订单金额”的致命漏洞；
  • 四层权限自动编织：AI 将商品表配置为启用 RuoYi 角色数据范围（dataScope），生成器自动在 MyBatis XML 的 selectTradeProductList 中注入动态部门/用户过滤条件，无需人工手工拼接 SQL 片段。

【实战演进结果对比】：
在经历多达 12 轮的需求变更与规则追加后：
- 传统 AI 代码直改模式：第 4 轮出现 Mapper XML 语法错误，第 7 轮丢失了前端校验，第 9 轮导致 Shiro 权限注解失效，系统陷入混乱；
- EZRY 模型驱动模式：全过程代码库保持纯净，模型自检始终保持 0 错误，所有业务规则完整沉淀在模型元数据中，随时可一键重新编译运行，系统具备极高的演进韧性。

运行结果示例：

八、总结与启示：迈向确定性的智能软件工程

长久以来，业界对大模型的工程化应用存在一种认知误区：认为 AI 越自由、越无拘无束，展现出的创造力就越强。

但在严肃的企业级软件工程中，不可预测的自由往往等同于灾难。软件系统的长时演化，其本质是一场与“熵增”和“系统腐化”对抗的长期战争。

EZRY（EZDML + 若依 + AI MCP）的实践为我们揭示了一条行之有效的路径：

1. 让模型成为单一事实来源：提升抽象层级，把多技术栈的离散代码收敛为一份高维可执行契约，彻底摆脱上下文爆炸与跨层撕裂；
2. 让生成代码保持物理隔离：把生成物当成随时可抹去的流水线产品，让所有定制业务通过生命周期规则沉淀，绝不污染系统基底；
3. 让 AI 在协议围栏内行动：通过本地原生 MCP 协议，赋予 AI 读懂现状、预览差异、原子提交、静态检查与一键撤销的能力。

让大模型专注于逻辑推断与模型设计，让代码框架保障底座稳定，让建模工具看守安全边界——这才是企业级软件开发在 AI 时代穿越长时演化周期的确定性破局之道。