用一句需求搭建进销存：REBUILD AI 实测与边界分析

只用一句话描述业务需求，AI 能否直接搭出可用的进销存系统？为了确认这类能力究竟是演示效果还是生产工具，我在 REBUILD 中从计划模式开始，实际完成实体、字段和引用关系的创建，并继续检查触发器、权限、布局、执行确认与失败处理等关键环节。

一句话让 AI 建一套进销存，我拿 REBUILD 试了一遍

先说结论。REBUILD 的 AI 搭建能用一句话建出一套进销存的骨架，实体、字段、引用关系、主子表都建对了，建完就能录数据。但它交付的是结构，不是成品系统。表单布局、权限、审批流还得人工过一遍，触发器也不自动建，要一个个确认。

拿它做原型和初版配置很省时间，拿它当交付工具会踩坑。下面是完整过程。

测试准备

REBUILD 从 V4.1 开始带 AI 助手，V4.5 补齐了技能、知识库和工具体系，搭建能力就在工具这一层。

配置只有一处，管理中心 - AI 助手，填三个东西：API 地址、秘钥、模型名。任何兼容 OpenAI 调用的服务都行，我用的阿里云百炼，地址填 https://dashscope.aliyuncs.com/compatible-mode/v1。页面右侧有个近 90 天的 Token 用量统计，费用能自己估。

模型选择上有个坑要提前说。我先用了一个便宜模型试，AI 在字段类型上反复改口，一轮工具调用下来什么也没建成。换成强模型才一次过。官方文档在这点上说得很直白，弱模型适合查数据、做统计这种单步操作，搭建类任务容易出错或反复重试。我认可这个判断，别在这上面省钱。

还有一个前置条件，搭建类工具只有管理员能用。普通账号问同样的话，AI 会告诉你权限不够。

实测过程

对话窗口在顶部菜单，快捷键 Shift+/。输入框支持三个斜杠命令，/new 开新会话，/ref 引用当前会话，/plan 是计划模式。搭建系统我建议一律先走 /plan。

计划模式的逻辑是，AI 只能用查询类工具收集信息，看现有实体、查记录，禁止任何写操作。它把方案写完，前端检测到方案标记后弹出确认框，问你是否执行。你点确认，它才真正动手。点"修改需求"就继续聊。

我的输入是这么一句：

/plan 帮我建一套进销存，要有客户、供应商、物料，采购单和销售单都带明细，库存能自动算

AI 先调了一次实体列表查询，确认系统里没有重名实体，然后给出规划表。它列了 7 个实体，每个实体下面把字段名和类型都标了出来，采购单明细标了主实体是采购单，物料编码这种引用字段标了引用哪个实体。表格最后附了几条触发器建议，比如采购单审批通过后回写库存数量。

这一步值得多看两眼。它没有直接建，而是把清单摊开让你核对。我改了两个字段的类型，把"数量"从小数改成整数，重新确认后它才开始执行。

执行阶段大概一分钟，中间能看到工具调用的进度提示。结束后返回一张清单，每个实体名都是可点链接，直接跳到实体管理页。汇总写的是成功创建 7 个实体、43 个字段。

触发器确实没建。返回结果里明确写了有 4 条触发器建议，需要逐个创建，每个还要单独确认。我建了其中的库存回写那条，AI 先去取了触发器的配置结构定义，又单独校验了一遍公式语法，然后才提交。这种顺序让我比较放心，它不是凭印象拼 JSON。

拆开看它怎么建的

看完界面行为，我翻了它的实现，几个设计值得说。

搭建类工具是分层的一组，不是一个大模型硬猜：

工具	干什么
BuildApp	整包搭建，规划加批量创建实体和字段
BuildEntity	建实体，可同时带名称字段和自动编号字段
BuildField	加字段，20 多种类型
BuildTrigger	建触发器，字段更新、汇总、通知、自动审批
BuildTransform	建记录转换，源实体按字段映射转到目标实体
BuildFormLayout	建表单布局
BuildListLayout	建列表布局
BuildNavMenu	建左侧导航菜单
BuildReportTemplate	建网页报表模板
BuildFilter	建常用查询条件，列表页直接选用
BuildSkill	建 AI 技能
BuildAviatorFormula	查阅函数、校验公式语法、按描述推荐模板

所有写操作都是两段式。第一次调用只返回改动清单和一个待确认标记，不动数据。用户明确同意后用同样参数加 confirmed=true 再调一次才执行。工具返回的提示语里写死了"用户未确认或要求调整时不得执行创建"，这是给模型的硬约束。

批量创建时它做了依赖拓扑排序。被引用的实体先建，引用方后建，明细实体排在主实体之后。中文标签会被换成系统里的真实实体名再传给下一步。碰到循环引用不会死循环，按原顺序建，然后让字段归属校验去报错。

防幻觉这块做得比较细。系统提示词里要求调用任何涉及字段名的工具前必须先查实体真实字段定义，禁止编造字段名。用户说中文标签也行，工具会自己转。实体名支持模糊匹配，匹配出多个歧义时直接报错而不是随便挑一个，匹配不到会提示"你是否想用 XXX"。还有一个我觉得考虑得挺周到的地方：如果计划里的某个实体没建成功，依赖它的引用字段会直接失败，而不是拿中文名去模糊匹配到系统里一个无关的既有实体上。

批量执行是逐项容错的。单个字段建失败不会中断整批，失败项单独收集，最后在结果里列出失败数量和原因。这比整批回滚实用，因为建到一半的实体你通常想留着。

配触发器这类结构化配置，AI 不是靠记忆拼参数。它先调 GetConfigSchema 取对应的 JSON Schema，触发器、审批流、表单布局、导航菜单、图表、记录转换、高级过滤条件、前端扩展 API 都在里面，取到再按结构生成。涉及计算公式时先用 BuildAviatorFormula 的 validate 校验语法和字段变量是否真实存在，通过了才填进配置。

工具调用有 30 轮上限，超了会终止本次回答并提示你发送"继续"。系统提示词里还要求给最终回答预留 3 轮，也就是工具调用不超过 27 轮。大系统一次说不完，分批来。

边界和限制

这部分是我最想写清楚的。

开源版和商业版差别很大。 开源版里 AI 能建实体、加字段、建常用查询条件、建技能。触发器、记录转换、表单布局、列表布局、导航菜单、报表模板、整包搭建这些都在商业版里，开源版调用会直接返回"此功能为商业版功能"。这个判断在后端做，不是前端隐藏按钮，绕过界面调接口也拦得住。免费版还有个限制，一个主实体只能挂一个明细实体。

建完之后必须人工过一遍。 AI 建实体成功后返回的提示语里就写着，请核对并配置表单和布局。默认布局是全字段平铺，字段一多表单就很长。权限、审批流、导航菜单也都要自己配。它省掉的是重复点击，不是配置决策。

没有回滚。 建错了只能删。删除实体的工具是强制删除，连带数据、字段和相关配置一起清掉，这个不可逆。所以计划模式那个确认框别急着点。

Token 消耗不低。 一次整包搭建走下来，查实体、取 Schema、校验公式、逐个建字段，十几轮工具调用是常态。系统提示词里专门有一段讲预算，要求合并调用、禁止重复查询、单次参数不要贪多。即便如此，搭建类任务的开销还是明显高于日常问答。

适合谁用

适合的场景很具体。需求还在变的阶段，先让 AI 出一版结构，边用边改，比在纸上画完再动手快得多。管理员要建十几个实体、上百个字段的时候，逐个点鼠标是纯粹的体力活，交给 AI 更划算。给不熟悉系统的同事做演示，当场按需求建一套出来，效果比 PPT 好。

不适合的是把它当交付工具。生产环境的表单布局、字段权限、审批链路都需要人做判断，AI 给的是初稿。

我的用法是，/plan 出方案，逐条核对实体和字段，确认后执行，然后自己花半小时调布局和权限。这套流程下来，一套进销存的初版配置大概一小时能落地，纯手工我估计要一下午。

工具能查到系统里的实体结构和业务数据，全程受当前用户的数据权限约束，AI 只能碰你有权碰的数据。系统还能作为 MCP 服务端接到 WorkBuddy、QoderWork 这类 AI 客户端，用个人秘钥认证，不开界面也能查数据、走审批。

想自己试的，在线体验环境在 nightly.getrebuild.com/ ，配好自己的模型秘钥就能跑。搭建记得先打 /plan。