如果让我形容过去大半年里最有意思的一次内部验证一定是这个把一句人话丢给 AI让它自己把一张表、两个页面、三个状态按钮的小型业务系统直接搭出来。不是生成代码片段也不是给开发者的脚手架而是完完整整地生成一个能跑、能点、能录数据、能看统计图表的业务应用。做完这条链路之后我对“低代码”和“AI 生成”各自的天花板都有了更具体的感受——低代码负责把“后端逻辑 前端页面 数据库结构”的复杂度封装成元数据AI 负责把“业务需求 → 元数据”这最后一公里的翻译工作接手过去。这篇就把这条链路的开源实现思路和源码细节完整拆开适合正在评估 AI低代码方案的开发者也适合想自己动手把类似能力做进内部工具平台的团队参考。1. 先梳理清楚一句话生成应用难点到底在哪很多人第一次看到“一句话生成业务应用”的 Demo第一反应是这不就是个 Prompt 套壳吗。真正把链路跑一遍就会发现难点根本不在“AI 能不能理解人话”而在底下那一大堆工程问题理解完之后怎么落成数据结构数据结构怎么变成页面页面怎么接上后端接口接口变动时数据库怎么迁移。任何一个环节掉链子AI 生成得再好也只是一堆无法运行的静态文本。1.1 从传统开发流程看机会点传统业务应用的开发流程哪怕是一个最简单的“客户订单管理”都包含这样一串重复劳动先建数据库表再写后端 CRUD 接口再写列表页、表单页、详情页还要处理枚举字典、分页、弹窗确认这些交互细节。一个熟练的开发者做一套也得大半天如果需求变化两三次工作量直接翻倍。机会点在于这整条链路里的大部分工作其实高度结构化。数据库字段类型就那么几种常见业务对象无非是客户、订单、商品、员工、审批单页面形态也就列表、表单、详情、仪表盘几种操作逻辑无非增删改查加状态流转。既然结构化程度这么高就存在一套形式化描述的中间表示——业界通常把它叫做应用描述 DSL。低代码引擎本质上就是 DSL 的解析器和渲染器AI 要做的就是把人话翻译成这套 DSL。1.2 AI低代码的含义再定义这里所说的“AI低代码”不是让 AI 当搜索引擎帮你在低代码平台上找组件也不是让 AI 直接输出一整份传统前端代码。真正的组合方式是AI 负责自然语言到结构化 DSL 的映射低代码引擎负责 DSL 到运行系统的映射。AI 不关心渲染细节低代码引擎不关心语义理解各干各的活。这样做的好处非常实际。DSL 是 JSON 或 YAML格式严格、字段可控AI 输出这类结构化内容远比输出整份 Vue/React 工程代码可靠。低代码引擎对 DSL 的解析结果是确定的不存在 AI 那种“这次生成的结果和上次不一样”的随机性。第一层把不确定性关进笼子里第二层保证确定性用户感知到的就是“一句话生成稳定可用”。1.3 这套方案能做什么、不能做什么先给期望管理打个底。基于 AI低代码架构搭建的“一句话生成”能力最擅长的是管理类业务应用数据录入、查询筛选、列表展示、简单的统计图表、基础的状态流转。它有边界不适合承载高频复杂交互的 C 端页面也不适合需要高度定制视觉风格的产品页更不适合连需求本身都非常模糊的探索型系统。适合的使用场景我总结成三类内部运营后台的快速搭建、业务部门打完草稿后的正式化、系统原型的秒级生成。尤其是第一类大量公司内部的 CRM、库存登记、报销记录、排班表本质上都是表单加表格加状态这类需求用这套方案生成效率极高。2. 开源方案选型为什么是 AI 解析器 低代码引擎的架构定下“AI 翻译到 DSL引擎渲染 DSL”的基调之后下一个问题就是技术选型。市面上开源的方案不少有的偏重可视化拖拽有的偏重代码生成有的把 AI 完全当作黑盒插件。我对比了一圈之后确定的架构策略是自研一层薄薄的 AI 解析器复用一个稳定的低代码渲染引擎。2.1 为什么不自研完整低代码引擎低代码引擎这个领域看着简单做起来极其庞杂。光是渲染层就要处理布局系统、组件体系、事件绑定、数据绑定、权限控制、主题换肤。这些能力如果全部自己从零实现工作量至少是以月计的。而开源社区里已经有一些引擎做得比较成熟DSL 结构清晰、渲染性能稳定、支持自定义组件扩展。我的建议是把低代码引擎当作“数据库”一样对待——选择一个成熟的底座重点攻克它上层的 DSL 设计和 AI 接入层。把精力花在真正决定产品体验的两件事上DSL 的业务语义覆盖程度以及 AI 解析的准确率。2.2 自研 AI 解析器的必要性为什么不直接拿通用大模型“裸聊”让 AI 一口气输出配置因为通用大模型没有领域约束你今天问它生成客户管理它给你一套字段明天问它生成订单审批它又给你一套完全不同的结构。没有 Schema 约束的生成结果后续根本无法被引擎稳定消费。自研 AI 解析器这层薄薄的服务本质上做两件事。第一维护一份严格定义的 DSL Schema作为输出约束第二设计一套 Prompt 模板加后处理管线让模型的自由发挥被限制在 Schema 允许的范围内。输出结构不稳的问题靠工程手段解决而不是靠换更大的模型解决。2.3 整体架构分层这套开源工程的整体架构我按四个模块划分每个模块承担单一职责模块职责输入输出AI 解析器自然语言理解与结构化用户一句话 约束上下文应用 DSLJSONDSL 校验器语法与业务规则校验应用 DSL校验通过的 DSL代码生成器元数据到业务代码应用 DSL后端路由 前端页面运行时引擎渲染与数据接入生成的工程代码可用的 Web 应用开发语言上AI 解析器用 Python 写因为生态方便DSL 校验器和运行时引擎更适合 Node.js 或 Java 这类强类型语言。如果团队以 Java 为主把解析器做成独立微服务单独调用也行。我这边实践下来模块之间只用 JSON 通信语言异构完全没有问题。3. 从一句话到可运行应用完整链路逐段拆解下面进入最硬核的部分——完整走一遍“一句话”到“能点能用的系统”是如何实现的。我会用一个具体例子贯穿全程用户输入“帮我做一个客户订单管理系统要能记录客户和订单订单能关联客户还要能看到每个客户的订单总金额”。3.1 第一步意图识别与需求结构化AI 解析器收到自然语言后第一步不是急着生成 DSL而是先做意图梳理。这一步会调用大模型执行一个结构化抽取任务识别出业务对象有哪些、对象之间的关联关系是什么、需要哪些操作动作、有哪些展示类诉求。以“客户订单管理系统”为例解析器需要抽取出业务对象客户Customer、订单Order对象关系Order 属于 Customer外键关联数据字段客户名称、客户等级、订单编号、订单金额、订单状态功能诉求订单需要选择客户关联录入、按客户维度统计金额汇总展示默认能力列表查看、新增、编辑、删除管理系统的隐含前提这个步骤的 Prompt 设计很关键我在工程里的做法是给模型一个“先填分析卡再写 DSL”的两段式指令。让模型先输出 JSON 形式的分析结果再基于分析结果生成 DSL。两段式能显著降低“一步到位”时的字段遗漏率实测下来字段完整度能提升百分之二三十。3.2 第二步应用 DSL 的生成与校验分析结果确定后AI 解析器会组装出一个完整 DSL。以下是简化版的 DSL 示例{ app: { name: 客户订单管理, platform: web }, entities: [ { name: customer, label: 客户, fields: [ { name: name, label: 客户名称, type: string, required: true }, { name: level, label: 客户等级, type: enum, options: [A, B, C], default: C }, { name: phone, label: 联系电话, type: string, pattern: phone } ] }, { name: order, label: 订单, fields: [ { name: orderNo, label: 订单编号, type: string, unique: true }, { name: customerId, label: 所属客户, type: ref, target: customer, required: true }, { name: amount, label: 订单金额, type: decimal, precision: 2 }, { name: status, label: 订单状态, type: enum, options: [待付款, 已付款, 已发货, 已完成] } ] } ], features: { dashboard: [ { type: sum, entity: order, field: amount, groupBy: customer.name } ] } }DSL 生成之后不能直接信任要经过一层严格的校验器。校验器分两层第一层是 JSON Schema 语法校验检查字段类型是否合法、引用对象是否存在第二层是业务规则校验例如 ref 字段指向的目标实体是否存在、枚举类型的 options 是否非空、必填字段有没有设置默认值。校验不通过就带着错误信息回传给 AI 解析器重跑修正。3.3 第三步代码生成器的模板化展开DSL 校验通过后就进入代码生成阶段。这里的代码生成不同于“AI 写代码”而是模板化展开将 DSL 中每个实体映射为一套预定义的 CRUD 代码片段将每个页面映射为一个页面模板实例。以 Customer 实体为例代码生成器会产出四条后端路由和一个前端页面文件// 生成物摘要routes/customer.js router.get(/api/customer, listHandler(customer)); router.get(/api/customer/:id, detailHandler(customer)); router.post(/api/customer, createHandler(customer)); router.put(/api/customer/:id, updateHandler(customer)); router.delete(/api/customer/:id, deleteHandler(customer));前端页面则基于实体字段描述自动生成表单控件。字符串类型渲染成输入框枚举类型渲染成下拉选择框ref 类型渲染成远程搜索选择器decimal 类型渲染成数字输入框并保留精度。这套“字段类型到组件类型”的映射表是整个代码生成器最核心的资产。3.4 第四步运行时引擎与数据链路打通代码生成完成后运行时引擎负责两件事加载数据库 Schema启动开发服务器。引擎会根据 DSL 自动建表并生成初始数据字典例如把枚举类型转换成可查询的数据字典表方便后续下拉选项做动态加载。数据链路按以下顺序打通页面组件从 API 获取数据 → API 从数据库读写 → 数据库结构由引擎按 DSL 自动迁移。为了降低用户心智负担引擎在开发模式下会直接读取 DSL 生成数据库表结构不需要手写任何 SQL。整个链路跑到这一步用户面前出现的就是一个可点击的实际系统。4. 源码核心模块解读AI 解析器、DSL 与代码生成器完成了整体链路的描述接下来深入源码细节把每个模块的关键实现思路讲清楚。这部分我尽量结合代码片段说即使是没看过这套工程源码的人也能照着思路自己实现。4.1 AI 解析器的 Prompt 工程骨架AI 解析器是本方案的核心也是调优空间最大的模块。它的实现本质上是“约束性生成”核心代码如下SYSTEM_PROMPT 你是一名业务应用架构师负责理解用户用自然语言提出的业务系统需求。 你的任务是输出符合应用描述DSL Schema的JSON结构不要输出任何解释性文字。 DSL Schema关键约束 1. 必须识别出所有业务实体entities每个实体至少有name、label、fields。 2. 字段类型必须是string、integer、decimal、boolean、date、datetime、enum、ref。 3. ref字段必须声明target且target必须是已定义的另一个实体。 4. 所有实体首字段建议为主标识字段name字段建议设置为必填。 5. 如果用户提到管理、记录、统计等动词短语请推断出CRUD和对应的列表功能。 6. 直接输出JSON禁止输出Markdown代码块标记。 解析器后处理管线还有一道关键防线JSON 清理与修复。大模型偶尔会在输出外面包上 json 代码块标记或者加一段“好的我已生成以下结构”这种多余内容。后处理管线会把这类噪声剥离再尝试解析 JSON。如果解析失败会进入一种重试策略将错误信息拼回 Prompt 重新调用一次。这个机制很简单但效果很好。4.2 DSL 校验器的设计原则DSL 校验器写起来不难但设计原则值得展开。我遵循的是“三层校验”原则第一层结构性校验检查 JSON 结构完整性例如 app 对象是否存在、entities 是否非空数组。第二层引用完整性校验所有 ref 字段的 target 必须指向存在的实体所有页面引用的实体必须存在于 entities 列表。第三层业务合理性校验例如日期字段不应设置 unique 约束统计图表的 groupBy 字段必须是实体真实存在的字段。三层校验之外我额外加了一个“名称冲突检测”。AI 生成实体名时偶尔会用英文复数形式比如 customers、orders这会导致后续表名与前端变量名不一致。校验器会做一次命名规范化把复数转单数、驼峰转下划线并生成一张别名映射表供代码生成器使用。4.3 代码生成器的模板引擎与字段映射代码生成器的实现比很多人想象中要“笨”很多但恰好这种笨是优势。它不依赖大模型生成代码而是基于 Jinja2 模板引擎做结构化展开。每个实体有几个字段、什么类型对应什么组件都是通过一张映射表硬编码实现的DSL 字段类型后端取值前端组件校验规则示例stringString 类型属性Input 输入框最大长度 255integerInteger 类型属性InputNumber 数字输入整数范围检查decimalBigDecimal 属性InputNumber 小数模式精度保留 2 位booleanBoolean 属性Switch 开关默认值处理enum字符串字典引用Select 下拉框选项来自字典表ref关联实体主键RemoteSelect 远程搜索关联实体存在性校验dateLocalDate 属性DatePicker 日期选择格式 yyyy-MM-dddatetimeLocalDateTime 属性DateTimePicker 日期时间格式 yyyy-MM-dd HH:mm:ss这张映射表决定了系统的表达上限。想支持更丰富的业务场景就往表里加行——例如增加 file 字段类型对应上传组件增加 tags 类型对应标签选择器。每加一行等于扩展一类业务能力这种做法比写复杂规则更可控。4.4 前端页面模板的结构前端页面模板是代码质量的关键。列表页、表单页、详情页三套模板分别独立但共享一套布局基础。以表单页为例核心逻辑是根据字段定义循环渲染表单项并自动生成提交校验template el-form :modelform refformRef :rulesrules label-width100px el-form-item v-forfield in formFields :keyfield.name :labelfield.label component :isfield.component v-modelform[field.name] v-bindfield.props changehandleFieldChange(field.name, $event) / /el-form-item /el-form /template script setup // 根据字段类型的组件映射生成 rules const rules computed(() buildRules(formFields)); /script这里值得注意的一点是我把表单联动逻辑也纳入 DSL 表达范畴。例如“选择了客户等级为 A自动设置订单折扣为 0.9”这类规则可以在 DSL 中声明为 fieldEffects。代码生成器负责把声明转换成表单的 watcher 行为。这个设计让“动态表单”从配置中自然生长出来而不是靠使用者后期手改代码。5. 实测阶段踩过的坑自然语言不可控性的收敛办法任何 AI 产品跑 Demo 都很美好真正进入实测阶段才会暴露问题。这套“一句话生成应用”的方案我整理了三个最典型的坑以及对应的收敛策略希望能帮后来者少走弯路。5.1 自然语言的二义性用户的模糊远比你想象得多真实用户在描述需求时不会像 Prompt 示例那样规范。有人说“订单能关联客户”也有人说“客户下面有订单”——两种说法一个强调订单侧一个强调客户侧但对需求方来说含义完全相同。AI 解析器如何统一我的第一版方案试图让模型自己做语义归一化结果不稳定。后来调整了策略解析器只负责识别实体和关联关系关系的方向由字段语义决定也就是把“客户下面有订单”这种描述统一映射为“订单实体包含客户外键”因为“一个客户可以有多条订单一条订单只属于一个客户”这种基数关系很容易从业务常识推断出来。规则就是无论用户侧重哪一侧外键永远落在多的一端也就是订单表。5.2 数据库迁移与存量数据的兼容问题生成一个全新的应用简单难的是在应用上线后迭代需求。用户说“帮我再加一个订单备注字段”AI 重新生成 DSL 后数据库要怎么迁移如果简单重建表已有订单数据全部丢失如果手动改表结构又回到传统开发的老路。我的方案是生成一套内置的迁移引擎每次 DSL 变更后对比新 DSL 与旧数据库 Schema生成增量迁移语句。新增字段自动 ALTER TABLE ADD COLUMN删除字段则先做数据备份再删除列枚举选项变更则生成字典表数据同步脚本。这套机制本质上是低代码场景下的“数据库版本管理”目前还有很多边界情况但已经能覆盖绝大多数“加字段”类需求迁移脚本的正确率在实测中达到了八九成。5.3 AI 生成质量不稳定一次对话只能决定一次结果这个坑可能最让人头疼。同一句需求描述AI 可能这次生成 8 个字段下次生成 10 个字段再下次多出一个奇奇怪怪的统计图表。不稳定意味着产品没法承诺用户体验。我采用的收敛手段是“解析前补全 解析后固定”。解析前系统会在用户输入之后自动追加一组默认需求模板比如“需要支持分页查询”、需要支持删除确认弹窗”这些是管理类系统的隐含默认。解析后DSL 一旦通过校验就立即落库并生成一个“应用版本号”。后续用户的每次修改请求只做增量更新不做全量重生成。用户表达的只是“加一个字段”系统就只变更这个字段相关部分避免了整盘推倒重来。5.4 上下文太长时的截断处理用户描述一段 50 个字的复杂需求时很容易超过模型输入窗口的有效范围。更麻烦的是当用户基于已生成应用迭代修改时我们会把旧 DSL 塞进上下文这就直接挤压了自然语言描述的可用空间。我的解法是做一个“分档压缩”第一档只保留用户新输入的需求不携带任何历史 DSL第二档保留最近一次 DSL 的关键摘要只带实体名和字段名列表去掉类型和校验规则第三档才带上完整 DSL。优先级由用户操作触发判断比如是“创建新应用”还是“修改已有应用”。这样既保证了上下文有效又不丢失历史信息。6. 把这套能力接进团队内部平台一些落地建议如果你的团队正准备把“一句话生成应用”做成内部开发工具或者正在评估开源方案最后这部分落地经验应该对你有用。6.1 接入前先定义好业务应用的范围边界和任何 AI 工程一样定义好边界比做无限泛化更重要。建议把“一句话生成应用”定位成长尾需求承接器那些不值得投入专职开发、但是业务确实需要的小型应用交给这套工具。而不是试图让它替代核心业务系统的开发能力。我在实际接入内部平台时定义了三类可用场景部门内部的轻量数据收集、核心系统的外围辅助管理、项目原型的快速搭建。其中第二类最有价值因为它不需要触碰核心系统数据只需要把外围流程管理起来就能显著提升一线团队的效率。6.2 人工确认环节不能省就算 AI 解析器做得再好“生成后人工确认”这个环节也必须保留。我的做法是生成 DSL 之后先渲染出一个“需求确认页”把识别到的实体、字段、页面清单用可读性极强的方式展示出来而不是直接生成可运行系统。确认页上不懂技术的业务人员也能看懂“你正在创建一个包含两个实体、三个页面、一个统计图的系统”并且可以打回修改。这个环节看起来多一步操作实际上节省了大量返工时间。因为 AI 生成的应用需要落到数据库万一生成错了重建数据库和清理数据的成本是几十倍的确认时间。把确认放在生成之前是把问题拦截在代价最小的地方。6.3 模型选择与成本控制的一些实测数据关于模型选型我的经验很直接任务执行速度比聪明程度重要。意图抽取和 DSL 生成这类高度模板化的任务通用模型和顶级模型的表现差异大概只有几个百分点但响应延迟和控制成本差异很大。我建议先拿一个中等规模模型跑通闭环发现质量瓶颈后再针对性地升级特定环节而不是每一步都上最贵的模型。实测下来生成一个包含两个实体的管理应用单次调用的 Token 消耗大约在 4000 到 6000 之间按照中等规模模型的定价成本完全可以接受。而且有了 DSL 版本管理机制后增量修改只需要几百 Token比全量重生成便宜一个数量级。这套工程做下来我最深刻的体会是AI 生成应用这件事其实不是在赌模型的智商上限而是在赌系统的工程下限——DSL 定义得越清晰、模板覆盖得越完善、校验逻辑越严密AI 在这个框架里翻车的空间就越小。开源项目的价值恰恰在于把这条经验沉淀成了一套可复用的工程骨架。
如果让我形容过去大半年里最有意思的一次内部验证一定是这个把一句人话丢给 AI让它自己把一张表、两个页面、三个状态按钮的小型业务系统直接搭出来。不是生成代码片段也不是给开发者的脚手架而是完完整整地生成一个能跑、能点、能录数据、能看统计图表的业务应用。做完这条链路之后我对“低代码”和“AI 生成”各自的天花板都有了更具体的感受——低代码负责把“后端逻辑 前端页面 数据库结构”的复杂度封装成元数据AI 负责把“业务需求 → 元数据”这最后一公里的翻译工作接手过去。这篇就把这条链路的开源实现思路和源码细节完整拆开适合正在评估 AI低代码方案的开发者也适合想自己动手把类似能力做进内部工具平台的团队参考。1. 先梳理清楚一句话生成应用难点到底在哪很多人第一次看到“一句话生成业务应用”的 Demo第一反应是这不就是个 Prompt 套壳吗。真正把链路跑一遍就会发现难点根本不在“AI 能不能理解人话”而在底下那一大堆工程问题理解完之后怎么落成数据结构数据结构怎么变成页面页面怎么接上后端接口接口变动时数据库怎么迁移。任何一个环节掉链子AI 生成得再好也只是一堆无法运行的静态文本。1.1 从传统开发流程看机会点传统业务应用的开发流程哪怕是一个最简单的“客户订单管理”都包含这样一串重复劳动先建数据库表再写后端 CRUD 接口再写列表页、表单页、详情页还要处理枚举字典、分页、弹窗确认这些交互细节。一个熟练的开发者做一套也得大半天如果需求变化两三次工作量直接翻倍。机会点在于这整条链路里的大部分工作其实高度结构化。数据库字段类型就那么几种常见业务对象无非是客户、订单、商品、员工、审批单页面形态也就列表、表单、详情、仪表盘几种操作逻辑无非增删改查加状态流转。既然结构化程度这么高就存在一套形式化描述的中间表示——业界通常把它叫做应用描述 DSL。低代码引擎本质上就是 DSL 的解析器和渲染器AI 要做的就是把人话翻译成这套 DSL。1.2 AI低代码的含义再定义这里所说的“AI低代码”不是让 AI 当搜索引擎帮你在低代码平台上找组件也不是让 AI 直接输出一整份传统前端代码。真正的组合方式是AI 负责自然语言到结构化 DSL 的映射低代码引擎负责 DSL 到运行系统的映射。AI 不关心渲染细节低代码引擎不关心语义理解各干各的活。这样做的好处非常实际。DSL 是 JSON 或 YAML格式严格、字段可控AI 输出这类结构化内容远比输出整份 Vue/React 工程代码可靠。低代码引擎对 DSL 的解析结果是确定的不存在 AI 那种“这次生成的结果和上次不一样”的随机性。第一层把不确定性关进笼子里第二层保证确定性用户感知到的就是“一句话生成稳定可用”。1.3 这套方案能做什么、不能做什么先给期望管理打个底。基于 AI低代码架构搭建的“一句话生成”能力最擅长的是管理类业务应用数据录入、查询筛选、列表展示、简单的统计图表、基础的状态流转。它有边界不适合承载高频复杂交互的 C 端页面也不适合需要高度定制视觉风格的产品页更不适合连需求本身都非常模糊的探索型系统。适合的使用场景我总结成三类内部运营后台的快速搭建、业务部门打完草稿后的正式化、系统原型的秒级生成。尤其是第一类大量公司内部的 CRM、库存登记、报销记录、排班表本质上都是表单加表格加状态这类需求用这套方案生成效率极高。2. 开源方案选型为什么是 AI 解析器 低代码引擎的架构定下“AI 翻译到 DSL引擎渲染 DSL”的基调之后下一个问题就是技术选型。市面上开源的方案不少有的偏重可视化拖拽有的偏重代码生成有的把 AI 完全当作黑盒插件。我对比了一圈之后确定的架构策略是自研一层薄薄的 AI 解析器复用一个稳定的低代码渲染引擎。2.1 为什么不自研完整低代码引擎低代码引擎这个领域看着简单做起来极其庞杂。光是渲染层就要处理布局系统、组件体系、事件绑定、数据绑定、权限控制、主题换肤。这些能力如果全部自己从零实现工作量至少是以月计的。而开源社区里已经有一些引擎做得比较成熟DSL 结构清晰、渲染性能稳定、支持自定义组件扩展。我的建议是把低代码引擎当作“数据库”一样对待——选择一个成熟的底座重点攻克它上层的 DSL 设计和 AI 接入层。把精力花在真正决定产品体验的两件事上DSL 的业务语义覆盖程度以及 AI 解析的准确率。2.2 自研 AI 解析器的必要性为什么不直接拿通用大模型“裸聊”让 AI 一口气输出配置因为通用大模型没有领域约束你今天问它生成客户管理它给你一套字段明天问它生成订单审批它又给你一套完全不同的结构。没有 Schema 约束的生成结果后续根本无法被引擎稳定消费。自研 AI 解析器这层薄薄的服务本质上做两件事。第一维护一份严格定义的 DSL Schema作为输出约束第二设计一套 Prompt 模板加后处理管线让模型的自由发挥被限制在 Schema 允许的范围内。输出结构不稳的问题靠工程手段解决而不是靠换更大的模型解决。2.3 整体架构分层这套开源工程的整体架构我按四个模块划分每个模块承担单一职责模块职责输入输出AI 解析器自然语言理解与结构化用户一句话 约束上下文应用 DSLJSONDSL 校验器语法与业务规则校验应用 DSL校验通过的 DSL代码生成器元数据到业务代码应用 DSL后端路由 前端页面运行时引擎渲染与数据接入生成的工程代码可用的 Web 应用开发语言上AI 解析器用 Python 写因为生态方便DSL 校验器和运行时引擎更适合 Node.js 或 Java 这类强类型语言。如果团队以 Java 为主把解析器做成独立微服务单独调用也行。我这边实践下来模块之间只用 JSON 通信语言异构完全没有问题。3. 从一句话到可运行应用完整链路逐段拆解下面进入最硬核的部分——完整走一遍“一句话”到“能点能用的系统”是如何实现的。我会用一个具体例子贯穿全程用户输入“帮我做一个客户订单管理系统要能记录客户和订单订单能关联客户还要能看到每个客户的订单总金额”。3.1 第一步意图识别与需求结构化AI 解析器收到自然语言后第一步不是急着生成 DSL而是先做意图梳理。这一步会调用大模型执行一个结构化抽取任务识别出业务对象有哪些、对象之间的关联关系是什么、需要哪些操作动作、有哪些展示类诉求。以“客户订单管理系统”为例解析器需要抽取出业务对象客户Customer、订单Order对象关系Order 属于 Customer外键关联数据字段客户名称、客户等级、订单编号、订单金额、订单状态功能诉求订单需要选择客户关联录入、按客户维度统计金额汇总展示默认能力列表查看、新增、编辑、删除管理系统的隐含前提这个步骤的 Prompt 设计很关键我在工程里的做法是给模型一个“先填分析卡再写 DSL”的两段式指令。让模型先输出 JSON 形式的分析结果再基于分析结果生成 DSL。两段式能显著降低“一步到位”时的字段遗漏率实测下来字段完整度能提升百分之二三十。3.2 第二步应用 DSL 的生成与校验分析结果确定后AI 解析器会组装出一个完整 DSL。以下是简化版的 DSL 示例{ app: { name: 客户订单管理, platform: web }, entities: [ { name: customer, label: 客户, fields: [ { name: name, label: 客户名称, type: string, required: true }, { name: level, label: 客户等级, type: enum, options: [A, B, C], default: C }, { name: phone, label: 联系电话, type: string, pattern: phone } ] }, { name: order, label: 订单, fields: [ { name: orderNo, label: 订单编号, type: string, unique: true }, { name: customerId, label: 所属客户, type: ref, target: customer, required: true }, { name: amount, label: 订单金额, type: decimal, precision: 2 }, { name: status, label: 订单状态, type: enum, options: [待付款, 已付款, 已发货, 已完成] } ] } ], features: { dashboard: [ { type: sum, entity: order, field: amount, groupBy: customer.name } ] } }DSL 生成之后不能直接信任要经过一层严格的校验器。校验器分两层第一层是 JSON Schema 语法校验检查字段类型是否合法、引用对象是否存在第二层是业务规则校验例如 ref 字段指向的目标实体是否存在、枚举类型的 options 是否非空、必填字段有没有设置默认值。校验不通过就带着错误信息回传给 AI 解析器重跑修正。3.3 第三步代码生成器的模板化展开DSL 校验通过后就进入代码生成阶段。这里的代码生成不同于“AI 写代码”而是模板化展开将 DSL 中每个实体映射为一套预定义的 CRUD 代码片段将每个页面映射为一个页面模板实例。以 Customer 实体为例代码生成器会产出四条后端路由和一个前端页面文件// 生成物摘要routes/customer.js router.get(/api/customer, listHandler(customer)); router.get(/api/customer/:id, detailHandler(customer)); router.post(/api/customer, createHandler(customer)); router.put(/api/customer/:id, updateHandler(customer)); router.delete(/api/customer/:id, deleteHandler(customer));前端页面则基于实体字段描述自动生成表单控件。字符串类型渲染成输入框枚举类型渲染成下拉选择框ref 类型渲染成远程搜索选择器decimal 类型渲染成数字输入框并保留精度。这套“字段类型到组件类型”的映射表是整个代码生成器最核心的资产。3.4 第四步运行时引擎与数据链路打通代码生成完成后运行时引擎负责两件事加载数据库 Schema启动开发服务器。引擎会根据 DSL 自动建表并生成初始数据字典例如把枚举类型转换成可查询的数据字典表方便后续下拉选项做动态加载。数据链路按以下顺序打通页面组件从 API 获取数据 → API 从数据库读写 → 数据库结构由引擎按 DSL 自动迁移。为了降低用户心智负担引擎在开发模式下会直接读取 DSL 生成数据库表结构不需要手写任何 SQL。整个链路跑到这一步用户面前出现的就是一个可点击的实际系统。4. 源码核心模块解读AI 解析器、DSL 与代码生成器完成了整体链路的描述接下来深入源码细节把每个模块的关键实现思路讲清楚。这部分我尽量结合代码片段说即使是没看过这套工程源码的人也能照着思路自己实现。4.1 AI 解析器的 Prompt 工程骨架AI 解析器是本方案的核心也是调优空间最大的模块。它的实现本质上是“约束性生成”核心代码如下SYSTEM_PROMPT 你是一名业务应用架构师负责理解用户用自然语言提出的业务系统需求。 你的任务是输出符合应用描述DSL Schema的JSON结构不要输出任何解释性文字。 DSL Schema关键约束 1. 必须识别出所有业务实体entities每个实体至少有name、label、fields。 2. 字段类型必须是string、integer、decimal、boolean、date、datetime、enum、ref。 3. ref字段必须声明target且target必须是已定义的另一个实体。 4. 所有实体首字段建议为主标识字段name字段建议设置为必填。 5. 如果用户提到管理、记录、统计等动词短语请推断出CRUD和对应的列表功能。 6. 直接输出JSON禁止输出Markdown代码块标记。 解析器后处理管线还有一道关键防线JSON 清理与修复。大模型偶尔会在输出外面包上 json 代码块标记或者加一段“好的我已生成以下结构”这种多余内容。后处理管线会把这类噪声剥离再尝试解析 JSON。如果解析失败会进入一种重试策略将错误信息拼回 Prompt 重新调用一次。这个机制很简单但效果很好。4.2 DSL 校验器的设计原则DSL 校验器写起来不难但设计原则值得展开。我遵循的是“三层校验”原则第一层结构性校验检查 JSON 结构完整性例如 app 对象是否存在、entities 是否非空数组。第二层引用完整性校验所有 ref 字段的 target 必须指向存在的实体所有页面引用的实体必须存在于 entities 列表。第三层业务合理性校验例如日期字段不应设置 unique 约束统计图表的 groupBy 字段必须是实体真实存在的字段。三层校验之外我额外加了一个“名称冲突检测”。AI 生成实体名时偶尔会用英文复数形式比如 customers、orders这会导致后续表名与前端变量名不一致。校验器会做一次命名规范化把复数转单数、驼峰转下划线并生成一张别名映射表供代码生成器使用。4.3 代码生成器的模板引擎与字段映射代码生成器的实现比很多人想象中要“笨”很多但恰好这种笨是优势。它不依赖大模型生成代码而是基于 Jinja2 模板引擎做结构化展开。每个实体有几个字段、什么类型对应什么组件都是通过一张映射表硬编码实现的DSL 字段类型后端取值前端组件校验规则示例stringString 类型属性Input 输入框最大长度 255integerInteger 类型属性InputNumber 数字输入整数范围检查decimalBigDecimal 属性InputNumber 小数模式精度保留 2 位booleanBoolean 属性Switch 开关默认值处理enum字符串字典引用Select 下拉框选项来自字典表ref关联实体主键RemoteSelect 远程搜索关联实体存在性校验dateLocalDate 属性DatePicker 日期选择格式 yyyy-MM-dddatetimeLocalDateTime 属性DateTimePicker 日期时间格式 yyyy-MM-dd HH:mm:ss这张映射表决定了系统的表达上限。想支持更丰富的业务场景就往表里加行——例如增加 file 字段类型对应上传组件增加 tags 类型对应标签选择器。每加一行等于扩展一类业务能力这种做法比写复杂规则更可控。4.4 前端页面模板的结构前端页面模板是代码质量的关键。列表页、表单页、详情页三套模板分别独立但共享一套布局基础。以表单页为例核心逻辑是根据字段定义循环渲染表单项并自动生成提交校验template el-form :modelform refformRef :rulesrules label-width100px el-form-item v-forfield in formFields :keyfield.name :labelfield.label component :isfield.component v-modelform[field.name] v-bindfield.props changehandleFieldChange(field.name, $event) / /el-form-item /el-form /template script setup // 根据字段类型的组件映射生成 rules const rules computed(() buildRules(formFields)); /script这里值得注意的一点是我把表单联动逻辑也纳入 DSL 表达范畴。例如“选择了客户等级为 A自动设置订单折扣为 0.9”这类规则可以在 DSL 中声明为 fieldEffects。代码生成器负责把声明转换成表单的 watcher 行为。这个设计让“动态表单”从配置中自然生长出来而不是靠使用者后期手改代码。5. 实测阶段踩过的坑自然语言不可控性的收敛办法任何 AI 产品跑 Demo 都很美好真正进入实测阶段才会暴露问题。这套“一句话生成应用”的方案我整理了三个最典型的坑以及对应的收敛策略希望能帮后来者少走弯路。5.1 自然语言的二义性用户的模糊远比你想象得多真实用户在描述需求时不会像 Prompt 示例那样规范。有人说“订单能关联客户”也有人说“客户下面有订单”——两种说法一个强调订单侧一个强调客户侧但对需求方来说含义完全相同。AI 解析器如何统一我的第一版方案试图让模型自己做语义归一化结果不稳定。后来调整了策略解析器只负责识别实体和关联关系关系的方向由字段语义决定也就是把“客户下面有订单”这种描述统一映射为“订单实体包含客户外键”因为“一个客户可以有多条订单一条订单只属于一个客户”这种基数关系很容易从业务常识推断出来。规则就是无论用户侧重哪一侧外键永远落在多的一端也就是订单表。5.2 数据库迁移与存量数据的兼容问题生成一个全新的应用简单难的是在应用上线后迭代需求。用户说“帮我再加一个订单备注字段”AI 重新生成 DSL 后数据库要怎么迁移如果简单重建表已有订单数据全部丢失如果手动改表结构又回到传统开发的老路。我的方案是生成一套内置的迁移引擎每次 DSL 变更后对比新 DSL 与旧数据库 Schema生成增量迁移语句。新增字段自动 ALTER TABLE ADD COLUMN删除字段则先做数据备份再删除列枚举选项变更则生成字典表数据同步脚本。这套机制本质上是低代码场景下的“数据库版本管理”目前还有很多边界情况但已经能覆盖绝大多数“加字段”类需求迁移脚本的正确率在实测中达到了八九成。5.3 AI 生成质量不稳定一次对话只能决定一次结果这个坑可能最让人头疼。同一句需求描述AI 可能这次生成 8 个字段下次生成 10 个字段再下次多出一个奇奇怪怪的统计图表。不稳定意味着产品没法承诺用户体验。我采用的收敛手段是“解析前补全 解析后固定”。解析前系统会在用户输入之后自动追加一组默认需求模板比如“需要支持分页查询”、需要支持删除确认弹窗”这些是管理类系统的隐含默认。解析后DSL 一旦通过校验就立即落库并生成一个“应用版本号”。后续用户的每次修改请求只做增量更新不做全量重生成。用户表达的只是“加一个字段”系统就只变更这个字段相关部分避免了整盘推倒重来。5.4 上下文太长时的截断处理用户描述一段 50 个字的复杂需求时很容易超过模型输入窗口的有效范围。更麻烦的是当用户基于已生成应用迭代修改时我们会把旧 DSL 塞进上下文这就直接挤压了自然语言描述的可用空间。我的解法是做一个“分档压缩”第一档只保留用户新输入的需求不携带任何历史 DSL第二档保留最近一次 DSL 的关键摘要只带实体名和字段名列表去掉类型和校验规则第三档才带上完整 DSL。优先级由用户操作触发判断比如是“创建新应用”还是“修改已有应用”。这样既保证了上下文有效又不丢失历史信息。6. 把这套能力接进团队内部平台一些落地建议如果你的团队正准备把“一句话生成应用”做成内部开发工具或者正在评估开源方案最后这部分落地经验应该对你有用。6.1 接入前先定义好业务应用的范围边界和任何 AI 工程一样定义好边界比做无限泛化更重要。建议把“一句话生成应用”定位成长尾需求承接器那些不值得投入专职开发、但是业务确实需要的小型应用交给这套工具。而不是试图让它替代核心业务系统的开发能力。我在实际接入内部平台时定义了三类可用场景部门内部的轻量数据收集、核心系统的外围辅助管理、项目原型的快速搭建。其中第二类最有价值因为它不需要触碰核心系统数据只需要把外围流程管理起来就能显著提升一线团队的效率。6.2 人工确认环节不能省就算 AI 解析器做得再好“生成后人工确认”这个环节也必须保留。我的做法是生成 DSL 之后先渲染出一个“需求确认页”把识别到的实体、字段、页面清单用可读性极强的方式展示出来而不是直接生成可运行系统。确认页上不懂技术的业务人员也能看懂“你正在创建一个包含两个实体、三个页面、一个统计图的系统”并且可以打回修改。这个环节看起来多一步操作实际上节省了大量返工时间。因为 AI 生成的应用需要落到数据库万一生成错了重建数据库和清理数据的成本是几十倍的确认时间。把确认放在生成之前是把问题拦截在代价最小的地方。6.3 模型选择与成本控制的一些实测数据关于模型选型我的经验很直接任务执行速度比聪明程度重要。意图抽取和 DSL 生成这类高度模板化的任务通用模型和顶级模型的表现差异大概只有几个百分点但响应延迟和控制成本差异很大。我建议先拿一个中等规模模型跑通闭环发现质量瓶颈后再针对性地升级特定环节而不是每一步都上最贵的模型。实测下来生成一个包含两个实体的管理应用单次调用的 Token 消耗大约在 4000 到 6000 之间按照中等规模模型的定价成本完全可以接受。而且有了 DSL 版本管理机制后增量修改只需要几百 Token比全量重生成便宜一个数量级。这套工程做下来我最深刻的体会是AI 生成应用这件事其实不是在赌模型的智商上限而是在赌系统的工程下限——DSL 定义得越清晰、模板覆盖得越完善、校验逻辑越严密AI 在这个框架里翻车的空间就越小。开源项目的价值恰恰在于把这条经验沉淀成了一套可复用的工程骨架。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
