案例：织信 x WorkBuddy 实战系列（一）

环境：织信低代码平台 × WorkBuddy（AI Agent）

需求：工程变更与质量整改闭环，需要有一套数据可回滚的系统

文中企业信息已脱敏，下称 A 公司；截图数据均为测试数据。

一、导语：让 AI "全权负责"

作为技术人，对低代码平台一直有个刻板的判断：拖拽建表不难，难的是把一个真实且复杂的业务闭环装进去——表单、流程、事件、外部系统、逻辑等等复杂要素一旦叠加，很难想象低代码如何能够实现。

这次我们另辟蹊径，换一种做法：我们不再参与低代码的配置开发，而是让 AI（WorkBuddy）通过平台开放的接口，从需求分析开始，把整个应用建出来、跑起来、再返工修好，直接交付可用版本。让AI“全权负责”整个过程。

结果比预期有趣：AI在短短十几分钟内就完成了系统搭建，令我们惊讶的是，它在"数据可回滚"这个极具挑战的需求上，能够自行通过实践不断优化自身的方案，在bug调试和程序修改中，逐步找到了最优解。

二、需求分析：挖掘深层需求

A 公司是功率电子元器件制造企业，质量部门每天在跟来料检验、客诉、8D 报告、工程变更打交道。调研下来的结论很有意思：

系统并不缺。缺的是系统之间的缝隙。

• 检验数据有了，但整改逾期没人盯，要靠人翻表；
• 工程变更走了流程，但状态变了下游不知道；
• 客户档案天天改，但改错了没有任何办法退回去。

所以这个应用的真正需求，不是表面的"录入数据"，而是更深层次的数据处理：数据留痕、事件驱动、定时巡检、可回滚。

三、建应用：AI远比我们想象中聪明

把整个应用搭出来，我们一共进行了 4 组对话。 原话和落地物对照如下：

#	我说的原话	AI 回的关键内容	落地成什么
1	「A 公司数字化的需求有哪些」	结论：不缺系统，缺系统之间的缝隙。ERP / MES / PLM / QMS 都已上线，真正的痛点在 4M 变更断链、审厂整改靠 Excel 追、8D 跨部门难闭环	一份三层需求分析，圈出第一个切入点
2	「基于织信创建相关的应用」	没有直接开建。先给 7 张表的结构：表名、关键字段、关联设计（1:N / M:N）摆出来等确认	一份可确认的表结构方案
3	「在应用分组 A 公司下面创建应用」	建 7 表 + 1 条审批流 + 1 块看板，发布前自检返回空清单，给出应用访问地址	一个能点开的应用
4	「插入一些测试数据」	71 条互相咬合的数据：8D 指向具体料号、该料号的赔付挂在损失台账、一条 ECN 正卡在质量评估中	看板上来就有内容的演示环境

可以看出来真正沟通需求的只有第一组对话，而后面3组都是确定性的常规要求。

通过织信平台+AI的开发方案，用户不用太在意需求要写到多细才能落地开发，只需要把你的业务层面的诉求讲清楚，AI 会自行理解，并且出方案。一句话：相信AI的技术能力。

对话原文节选（

我： A 公司数字化的需求有哪些

AI： 先说结论：这家公司不缺系统。ERP、MES、PLM、SRM、CRM、QMS 全部上线，如果还去推销 MES 或 QMS，很难找到切入点；真正没被满足的需求全在系统之间的缝隙——4M 变更在 PLM→MES→SRM 之间断链、客户审厂整改还在 Excel 里追、8D 的客户回复版本管理靠人工。

我： 基于织信创建相关的应用

AI： （先给表结构，不写一行配置）7 张数据表：客户档案、产品料号、客户特殊要求 CSR、工程变更单 ECN、客诉 8D、审核整改、损失台账。关联方式不是一律 N:1——客户与料号是多对多，料号与变更/客诉是 1:N 查找列表，其余 N:1。确认后我再开始建。

我： 在应用分组 A 公司下面创建应用

AI： 建完了，已发布。7 张表、1 条工程变更审批流（工艺评估 → 质量评估 → 批准生效，质量节点可转客户确认）、1 块质量与变更运营看板（7 张卡）。发布前自检返回空清单。

AI 通过平台接口完成的骨架：

层	内容
业务对象	产品料号、客户档案、CSR 要求、工程变更（ECN）、8D 报告、整改措施、质量损失
流程	工程变更审批工作流（质量 → 生产 → 客户确认）
看板	质量总览仪表盘（来料 / 过程 / 客诉 / 损失）
自动化	每日 09:00 扫描逾期整改；监听 ECN 状态变更自动通知
对外	4 个 REST 接口 + 定时同步任务 + 第三方数据库对接底座

真实界面长这样——客户档案表，工具栏上已经有 AI 加的「查看变更历史」按钮：

质量与变更运营看板，统计卡、分布图、透视表全部由 AI 配置：

应用首页没用手动排版，AI 直接生成了一个深浅双主题的网站首页，数据全部来自接口实时取数，投到大屏就能当质量晨会看板：

这两块的启动语同样短得离谱：

• 「你可以用 AI 网站模板做一个仪表盘首页漂亮一点的」——它先去确认平台有没有网站模块、读对接文档，再生成页面和取数接口，而不是上来就写 HTML；
• 「我要跟第三方系统对接」→ 我补一句「第三方数据库」→ 它建了 4 张对接配置表、同步脚本、4 个对外 API 和 1 个定时任务。

如果只看这一步，你可能会觉得"AI 建低代码应用，不过如此"。真正的考验在下一节。

四、核心难点：客户档案"改错了能退回去"吗

这是业务方一句随口的提问，也是最难的一问：

客户档案表，我希望可以支持数据变更后回滚，怎么做？

平台自带的"变更记录"只能看（哪个字段从什么改成了什么），没有查询接口，更没有"恢复到某个版本"的动作。于是方案只能自己造——业内常用的全量快照 + 差异回滚：

1. 有人改了档案（表单提交、工作流流转都算）；
2. 监听器捕获 新建 / 修改 / 删除 之后 的事件；
3. 快照脚本写一条历史：版本号 + 人话版变更摘要 + 全量字段 JSON；
4. 需要时选中历史版本，点「回滚到此版本」；
5. 弹窗先列差异（现值 → 目标值），确认才写；
6. 回滚本身也生成一条新版本——退错了还能再退回来。

并且AI在业务实践上也有很完备的考量：

• 只回写差异字段，不整行覆盖。整行覆盖会把别人刚改的内容一起冲掉；归属人、编号、序号不动，三个子表刻意排除——它们是独立业务对象，不该跟着主表翻回去。
• 删除也能救回来。删除事件同样写快照，对已删除记录回滚 = 按快照重建一条新记录。现实中最需要回滚的场景，往往就是"误删"。

就这样，跑起来之后，每次变更都会在历史表里留一条记录，类型用彩色标签区分 新建 / 修改 / 回滚 / 删除，摘要写的是人话（"备注：（空）→ …"）：

五、上线实测：用户仅提出问题，让AI自行解决

上线后第一次实测，我改了一条客户档案，回头打开历史表——一条变更记录都没有。原话反馈给 AI 的只有这么一句：

不对啊，变更后看不到变更历史。

排查过程踩出的三个坑，每一个都很有代表性：

坑 1：监听器绑了一个不存在的表 ID。 配置里填的表 ID 在应用里根本不存在，监听器从未生效。把配置原样写回时平台直接报错，才暴露出来。教训：AI 写配置也要"回读校验"——把配置写回去，让平台自己告诉你哪里不认。

坑 2：脚本里多余的白名单校验。 事件里传的表标识和脚本里校验的别名不一致，每次都被判成"非本表事件"然后静默 return。这种静默跳过是最阴的 bug：不报错、不留痕、看起来一切正常。修复方式是删掉这层二次校验——监听器已经限定了表，脚本不用再防一次。

坑 3：JSON.stringify 比较字段值直接抛异常。 平台返回的记录字段是 Java 包装对象，不是纯 JS 对象，JSON.stringify 遇到就抛 TypeError。更隐蔽的是，这个异常被自动化的"异常兜底"配置吞掉了，界面上毫无提示。修复是统一先归一化成字符串/数组再比较。

调这类问题的方法论就一句话：别信中间层，把事件体手工投给脚本复现——绕过自动化的事件包装，直接看脚本输入输出，问题当场现形。

修完上面三个 bug，再改档案，历史表正常多出「修改」记录。但点「查看变更历史」，弹窗长这样——我当时只甩过去一张截图，配了五个字：

为啥不显示出来？

标题是「变更历史（共 2 个版本）」——动态变量解析成功了，说明取数、计算、变量传递全部正常；正文却一片空白。

原因出在最后一步：展示组件配了 stringValueFormat: "markdown"，但这个枚举值平台并不认（文档里只写"值格式"三个字，没给合法取值），渲染组件静默挂掉——不画内容，也不报错。

把弹窗换成平台明确支持的富文本组件（OutputRichtext），脚本改为输出一份带样式的 HTML 表格，一次到位：

这一坑的教训：在低代码平台里，"跑通"和"看得见"是两件事。排查时先确认变量有没有解析（标题渲染出来就是证据），再怀疑渲染容器的格式枚举。

七、复盘：AI + 低代码，到底改变了什么

整个过程中，AI 真正的价值不是"手快"，而是三件事：

1. 大胆提需求，相信AI理解能力。业务方说的是"客户档案要能回滚"，这种极其模糊的需求，AI也能够去理解需求、设计方案、进行开发——这套结构化能力 AI 做得又快又稳。
2. AI开发不一定完美无暇，最终也需要参与验证。初上线的版本，AI由于无法实现真正的场景化理解，所以还是需要用户亲自参与测试，发现问题。但是不用担心，只需要把错误原本交给AI，它会试着搞定。
3. 积累经验，AI会越用越聪明。目前织信+AI还是初步尝试，AI在一开始的开发中，对于织信平台的文档和产品理解不一定到位，随着我们多次开发，AI自身也会是了解什么是坑，然后积累更多的经验，在后续的开发中就会越来越聪明了。