一句话生成一块工业大屏：myBuilder AI 智能体生成看板演示

⚠️能力状态声明（请先读这段）

AI 辅助设计（含 AI 生成报表、AI 智能体精确修改报表、AI 智能体生成看板）已在内部开发完成，但目前尚未对外发布上线。本文是 myBuilder AI 实验室的成果演示，用于说明该能力的技术路线与设计取向，不代表当前发布版本已包含此功能。

当前通过任何渠道获取的 myBuilder 版本，均不包含这些 AI 能力。功能何时上线、以什么形态上线，以官方发布公告为准。请勿依据本文安排采购或生产计划。

摘要：这是 myBuilder AI 实验室成果演示的第三篇。第一篇讲从零生成报表，第二篇讲精确修改报表，这一篇换了个对象——大屏看板。

我用一句话「我在纺织印染行业的一家染整加工企业，帮我设计一个定型车间生产数据监控大屏看板」，让 AI 生成了一块 1920×1080 的工业大屏：5 张 KPI 卡 + 4 个图表 + 1 张明细表 + 仪表盘与能耗趋势，7 个区块在一张画布上排布完成，全程约 1 分半。

这篇想讲的重点不是"AI 会画大屏了"，而是：当 AI 面对的不是一段能顺着排下去的文字，而是一张固定尺寸的画布时，它要同时满足哪三类约束——几何、组件、业务与数据。以及它自己做的那个动作：验算两块内容会不会重叠。

一、先分清：报表和大屏，是两种完全不同的难题

前两篇讲的是报表。这次讲看板，第一件事得说清楚——这两件事在技术上根本不是同一类问题，别被"都是生成一个页面"骗了。

最后一行是分水岭。报表少排一个组件，页面往下顺一顺就行；大屏上两个元素坐标算错，它们会直接叠在一起，视觉上就是事故。

所以大屏生成要额外解决三件事：

1. 几何——在固定画布上把 N 个元素摆开，不许重叠、不许越界，缩放到别的屏幕还要不走形
2. 组件——只用平台组件库里真实存在的组件，并且按平台的数据契约把数据接进去
3. 业务与数据——这块屏该监控哪些指标？指标之间的数值关系对不对得上？

这三件事，恰好构成了本文第三节。

二、演示：一句话 → 一块 1920×1080 的工业大屏

演示环境是内部开发版 myBuilder IDE（本地部署）。

先说清一个容易混的点：大屏看板在平台里是一种「页面类型」，设计器里叫「看板页」。所以这次入口不是报表设计管理，而是页面设计管理 → 新增页面定义 → 页面类型选「看板页」，得到页面编码demo.aiDesignDashboard2。

2.1 操作就五步

2.2 我输入的需求（一字未改）

我在纺织印染行业的一家染整加工企业，帮我设计一个定型车间生产数据监控大屏看板

一句话。没给尺寸、没给字段、没给配色、没说要几个图表、更没给数据。

2.3 它在「结果返回」区做了什么

点执行后，AI 的思考过程流式输出。这段过程本身很有信息量，摘几条我印象最深的：

① 它先把"定型车间该监控什么"列出来。

这是最早出现的一段，也是最像"行业老师傅"的一段。它自己拆出了这些指标：

烘干和幅温度 (oven zone temperatures) · 定型时间 (setting time) · 门幅/幅宽 (fabric width) · 超喂率 (Overfeed rate) · 张力 (Tension) · 落布温度 (fabric drop temperature) Quality metrics: 一次合格率 (First-pass yield) · 质量异常 · 克重 (Gram weight/GSM) · 手感 (Hand feel) Energy consumption: 电力、天然气、蒸汽 · 吨布能耗 Equipment status: 各机台状态（运行/停机/待机/故障）· 机台效率 OEE

然后它把这些归纳成五大监控维度：产能达成、工艺参数、设备状态、质量、能耗。

值得说一句的是："定型（热定型）是染整后整理的关键工序"这个判断是它自己下的，需求里没提。

② 它在做像素级布局规划。

接下来这段是纯几何计算：

KPI cards: Card i at x = 25 + i*380 (since 350+30=380): x: 25, 405, 785, 1165, 1545 （text region 33.3%~66.6%：33.3% of 1920 = 639，66.6% = 1279） chart: x=240, height=350 … y=268 w580 h318

1920 宽的画布，5 张卡各 350 宽、间隔 30，首卡左边距 25——这是一套能自己算得通的栅格。它还在算标题居中区域该落在哪一段，避免和左右两侧的信息打架。

③ 它自己验算了两块内容会不会重叠。

这条是我认为最值得单独拎出来的细节。在拼装组件 JSON 时，它写了这么一句：

Component 4: time label { "text":"=updateTime", "x":1560, "y":6, "width":335, "height":36, "horizontalAlign":"right" } Wait time label overlaps main title region? main title label 660-1260, time 1560-1895. fine.

它在自己检查坐标区间有没有交叠——主标题占 660–1260，时间占 1560–1895，不相撞，放行。

这句fine.很轻，但它是大屏生成和报表生成最本质的区别所在：报表可以"往下顺"，大屏必须"算得清"。

④ 它自己算平了数据的账。

布局定了之后是造数。它先定了今日产量 86.5 万米，然后去设计"各机台产量对比"这个分组柱形图：

Let me group by bar: 计划 vs 实际. Let me make it 6 groups (6 定型机). 计划: 24, 20, 18, 18, 10, 8 (total 98) 实际: 22.5, 18.6, 15.2, 16.8, 8.1, 5.3 (total 86.5) matches 今日产量 86.5万米. Good.

6 台设备的实际产量合计 = 指标卡上的今日产量。指标卡与图表不是两组互不相干的数字，是能对上的。

还有一段更细的取舍：做"设备运行状态分布"时它发现设备太少，饼图撑不起来：

machineStatus … (total 30 machines? but we have 6 定型机…) Let me say the workshop has 定型机 6 台 + 预缩机/呢毯机等其他 6 台 = 12 台. Status: 运行 9, 待机 2, 故障 1. Good enough.

它意识到"6 个数据画饼图太单薄"，于是主动扩大了统计范围，并把数字配平。这是个设计判断，不是文本补全。

⑤ 最后它照着平台的数据契约把组件拼成 JSON。

它明确说了图表组件是怎么接数的：

the chart component binds data via dataField / nameField / valueField / groupField and merges into jsOption series

2.4 它交付的是一份「设计说明书」

设计完成后，AI 没有只丢一堆 JSON 出来，而是给了一份结构化说明。核心是这张表：

而且它写明了三条自己遵守的规范：

• 画布规范：1920×1080、等比例缩放、30 秒自动刷新
• 数据规范：每个图表/表格的dataField / nameField / valueField / groupField均与页面 data 样例数据严格匹配，数值符合染整业务常识（门幅 140–168cm、车速 36–48 m/min、定型温度 180–195℃）
• 组件规范：全部使用组件知识中支持的组件

2.5 落地结果：画布上直接出一块完整大屏

点确认后，画布直接渲染出了成品。运行时打开这块屏，7 个区块全部到位：

• 顶部：左侧企业名，中间大标题「定型车间生产数据监控大屏」，右侧实时时间2026-10-12 17:51:44
• KPI 指标带：今日产量86.5万米 ｜ 计划完成率92.3% ｜ 设备综合效率OEE85.6% ｜ 一次合格率98.2% ｜ 平均车速45.8m/min
• 各机台产量对比：计划/实际分组柱形图，1#–6# 定型机，单位万米
• 定型机温区温度监控：温区 1–8 温度曲线，纵轴 140–200℃
• 设备运行状态分布：环形图，运行中 / 待机 / 故障
• 机台生产实时明细：6 行数据，状态列按字典着色（运行绿 / 待机黄 / 故障红）
• 质量指标监控：98.2% 仪表盘
• 今日综合能耗趋势：08:00–19:00 面积图，单位 kgce

明细表长这样（截自运行态大屏）：

🔴这些数字全部是 AI 生成的演示数据，不是任何企业的真实生产数据。品种、门幅、车速这些字段的业务合理性是 AI 按"染整常识"配的，仅用于展示能力。

耗时：视频时间轴 00:30 点执行 → 02:03 画布渲染完成，约 1 分半。

三、技术关键：一次要同时满足三类约束

第一节说大屏要额外解决几何、组件、业务与数据三件事。这一节把演示里的证据对上去。

3.1 几何约束：它算的是坐标，而且会自查重叠

大屏的元数据和报表完全不同——每个元素带绝对定位。视频里能看到它写的组件 JSON 长这样：

// 主标题文本标签（节选） { "id": "lbl1000000000000000000000000003", "type": "label", "text": "定型车间生产数据监控大屏", "x": 660, "y": 2, "width": 600, "height": 44, "horizontalAlign": "center", "verticalAlign": "middle", "fontColor": "#FFFFFF", "fontSize": "28px", "fontBold": true, "fixed": true }

两个细节值得看：

• 32 位组件 id（lbl+ 28 位）——和报表篇里组件的 id 规则一致。这不是 AI 随手编的字符串，是引擎的 id 规范。
• 布局参数是显式的：x / y / width / height+ 对齐方式 + 字号字色。所以它能被算、能被校验、能被设计器拖拽。

然后是那个我觉得最漂亮的动作——它自己在验算重叠：

Wait time label overlaps main title region? main title label 660-1260, time 1560-1895. fine.

它是把两个元素的 x 区间拿出来做了个区间相交判断。做报表生成时不需要这一步（流式排布天然不重叠），做大屏必须做。

至于"换块屏幕会不会走形"，平台层给了答案——根配置里写死了这三个字段：

{ "type": "h5dashboard", "designWidth": 1920, "designHeight": 1080, "fitMode": "contain", // 等比例缩放适配 "backgroundColor": "#0a1230", "timerEnabled": true, "timerDuration": 30000 // 30 秒自动刷新 }

设计按 1920×1080 算，运行时按contain等比缩放适配实际屏幕。也就是说 AI 只需要把"设计态那一块画布"算对，适配交给引擎——这是把几何问题关进了一个有限范围的框里。

3.2 组件约束：它只能用手上有的组件

这一点在演示里很明显：AI 全程用的是看板组件库里的组件，而不是自己写 HTML + CSS 画一个大屏。

从 JSON 里能读到的组件类型：label（文本标签）、borderBox系列（边框容器，带bbl / bbc / bbr / bbt / bbg这类方位变体）、chartBar/chartLine/chartPie/chartGauge（图表）、table（表格）、装饰性标题组件（@main-title/@sub-title这类）。

注意它是怎么组织一个"图表面板"的——三层套：

borderBox「bbl」x25 y220 w610 h380 ← 外框容器（装饰 + 定位） └ borderBox8-image「subL」x40 y228 w300 h30 ← 标题条装饰图 └ label「各机台产量对比」 ← 标题文字 └ chartBar「chartBar」x40 y268 w580 h318 ← 图表本体

组件是复用的、有命名规范的、成体系的。AI 做的是"在既有组件库里选型 + 摆位 + 接数"，不是"从零造一个页面"。

而且它接数走的是平台的数据契约，不是自己往图表里塞 ECharts option：

the chart component binds data via dataField / nameField / valueField / groupField and merges into jsOption series

也就是说：AI 只负责把 data 里的字段名填到组件的绑定属性上，由引擎去组装成 ECharts 配置。这是一条重要的边界——AI 不直接产出渲染层代码，它产出的是"这个组件的值字段绑到 data 的哪个 key"。

至于视觉风格，配色也在元数据里：背景#0a1230、主文字#cfe8ff、标题#7ce7fd、表格表头底#12244d，状态三色#67C23A（运行）/#E6A23C（待机）/#F56C6C（故障）。暗色大屏的一整套视觉规范，最终都落在元数据的色值字段上。

3.3 业务与数据约束：它得知道这块屏该看什么，还得让数字自洽

前两条是"能不能摆上去"，这条是"摆上去有没有用"。

业务侧，它自己完成了从行业到指标的拆解（定型时间、超喂率、门幅、克重、OEE、吨布能耗……再收敛成五大维度）。这不是通用常识能做到的密度，说明它拿到的不是"大屏"这个词的字面理解，而是平台知识库里关于看板设计技能与组件 Schema 的规范——第 1 轮它调用的就是ide_aiResourceConfig_api_loadByCode，先把技能和知识加载进来再动手。

数据侧，它自己把账算平了：

• 6 台定型机实际产量合计 86.5 万米 = 指标卡"今日产量"86.5 万米
• 分组柱形图的系列（计划/实际）与图例、单位（万米）自洽
• 饼图数据太少 → 主动扩大统计范围到 12 台设备，并重新配平为 9/2/1
• 明细表的门幅、车速、温度都落在染整工艺的合理区间

这一条我认为是"大屏生成"和"图表堆砌"的真正分界。一张漂亮的屏，如果指标卡说产量 86.5 而图表加起来是 120，懂业务的人一眼就废了——因为它连"数对得上"这关都没过。

3.4 补一个细节：它自己判断了"这次是新建还是修改"

这个点很小，但它把前两篇和这篇串起来了。

AI 在动手前做了个判定：

技能与组件知识已学习完毕。当前看板定义为空，判定为新建看板。

它是先读了当前的看板定义，发现是空的，才判定"新建"。反过来，如果定义非空，它就走的应该是修改流程——也就是第二篇里那套「变更清单」（改了什么位置、改前是什么、改后是什么）。

同一个智能体，两个分支：定义空 → 生成；定义非空 → 修改并交变更清单。这也是为什么这一篇的最终交付物是一份设计说明书（说明我要摆什么、摆在哪），而上一篇的交付物是一份变更清单（说明我动了什么）——交付物的形态，取决于它是从"零"出发还是从"已有"出发。

反过来看那些只会"重新生成一版"的工具：它们没有第一个分支的判定，所以每次都是推倒重来，用户也没法核对自己原来的东西有没有被改动。

四、三个场景连起来看：是同一套机制在复用

把三篇放到一张表里，会看到一件比"AI 能干什么"更重要的事：

三件事的共同点只有一句话：AI 的输出始终落在引擎的元数据里。

这正是我最想说的那个判断——这不是"模型变强了"，是"元数据架构给的红利"。

如果 AI 面对的是裸代码或一张截图，它会遇到三个过不去的坎：

第三行这次体现得最直观——视频里有一个镜头，选中 KPI 组件后右侧属性面板直接列出 X 坐标、Y 坐标、宽度、高度、文本绑定=todayOutput、字号、字色。

也就是说：AI 画完的东西，用户能接着改，改的方式跟人自己画的完全一样。AI 不是吐出一个"能看不能碰"的成品，它交的是半成品，只不过这个半成品已经是能跑的了。

五、安全机制还是同一套

第三篇了，机制没变，只对一下号：

另外值得留意的一点：AI 每次换一个设计器，就要按那个设计器的规范干活。报表的绑定语法是 HTML 模板里的${startDate}，看板的绑定语法是=todayOutput。两套语法、两套 Schema、两个保存接口——而它都按各自的规矩来。这恰好说明它不是在"猜"，是在读平台的规范。

六、能力规划全貌（截至本文）

AI 辅助设计仍是三大类里最先落地的一类（因为它产出的东西元数据结构化程度最高、最易校验）。目前进度：

说明：「AI 智能体精确修改报表」不单独计为规划外的新能力——它是"AI 生成报表"这个场景下的第二个验证维度（生成 + 修改），三大类的 14 项口径不变。截至目前，内部跑通的是**报表（生成/修改）与看板（生成）**这两个对象上的三个场景。

回头看这三篇的顺序，其实是照着"对象的结构化程度"走的：

• 报表——元数据最规整、校验规则最明确 → 最先跑通，且顺手把"修改"这个更难的场景也验了
• 看板页——多了绝对定位、装饰组件、深色主题，几何约束变重 → 第二个跑通
• 流程 / H5 / 打印格式——交互逻辑与排版约束更复杂 → 还在规划中

先挑"最容易校验的"落，不是挑"最炫的"落。这是这套规划里唯一一条我觉得没得商量的原则。

七、诚实边界：这次演示没有证明什么

八、现在能用上吗？——还不能

结论：不能。AI 辅助设计当前处于内部开发完成、尚未上线的状态。本文是成果演示，不是交付说明。

如果你看完本文去自己环境里找「AI辅助设计」没找到——那是正常的，不是你操作错了。

那现在发这篇的意义？建议你带走两样可迁移的东西：

1. "AI 生成的东西能不能被接管"这个判断标准：看它产出的是不是可以被原生工具继续编辑的结构。AI 画完一块屏，你选中一个卡片就能改 X/Y/宽高，和改自己画的一样——这才叫生成，否则只是出了一张图。
2. "数值自洽"这个验收点：以后拿到任何 AI 生成的数据看板，第一件事就是加总核对——指标卡的数字和图表能不能对上。这一关过不了，后面全是白搭。

如果你关心的是平台本身怎么获取（这部分现成可用，与 AI 无关）：产品发布与下载页可获取当前主推版本；12 元为 1 天下载会员，当天下载的版本永久授权使用（含私有化部署，不分版本）；企业版 3,980 元一次买断 366 天会员服务，会员期内新版本均可下载、可开票，服务支持不中断。

⚠️再次提示：以上对应的是平台现有能力，AI 辅助设计不在其中。现在开通下载会员，拿到的版本同样没有这些 AI 功能。

九、最后

三篇写下来，我发现自己反复在回答同一个问题：AI 在系统里干活，凭什么能被信任？

第一篇的答案是"它输出的东西有结构"。
第二篇的答案是"它把改动讲清楚了"。
这一篇的答案有点不一样——它自己会验算。

Wait time label overlaps main title region? ... fine.

这句fine.其实是一个信号：AI 在动手之前，先给自己立了规矩，然后按规矩自检。不许重叠、数值要对得上、只能用组件库里的组件、绑定要走平台契约。

让 AI 在系统里干活的难点，从来不是它会不干，而是它干得没有边界。而边界这件事，靠提示词是划不出来的——得靠系统本身有结构、有规范、有可校验的地方。

元数据就是这个"可校验的地方"。

互动提问：你们公司现在有几块大屏在跑？做一块大屏，最耗时间的到底是"想清楚该看什么指标"，还是"把这些图对齐摆好看"？——我猜是后者占了七成，而后者恰恰是最应该被机器接管的那部分。评论区说说你们的屏是找谁做的、花了多长时间。

附件：B站演示视频

myBuilder AI实验室：AI智能体生成看板