AI * 低代码登场，搭建业务系统，像搭积木一样简单

一、从一个三天上线的需求说起：我为何重新审视低代码#

上周三下午四点半，采购部的王姐跑到我工位旁边，说想做一个设备巡检记录的小工具。放在三年前，这句话后面跟着的是需求评审、排期、开发、测试，一套流程走下来大概六周。而这一次，我第一次真切地感受到，AI + 低代码正在让搭建业务系统这件事变得像搭积木一样简单——从她描述需求到第一版能用，我们花了不到一个下午。

先做个自我介绍。我在一家年营收约 8 亿元的装备制造企业做信息化负责人，带一支 6 人的开发小组，服务集团 1200 多名员工、14 个业务部门。我们这个规模的 IT 团队有个典型困境：ERP、MES、PLM 这些核心系统由厂商实施，动不了；而业务部门源源不断冒出来的”小需求”——巡检记录、样品借还、供应商打分、售后工单——既不够大到立项，又确实拖慢了业务。

2023 年我做了一次内部统计，全年收到 47 个轻量级需求，平均交付周期 48 天。拆开看更有意思：真正写代码的时间只占 22%，剩下 78% 消耗在需求澄清、跨部门确认、排期等待和反复修改上。也就是说，我们的瓶颈从来不是”写不出来”，而是”排不上、等不起、改不动”。

这也是我后来认真研究低代码的原因。不是因为它新，而是因为它把”等待”这个环节压缩掉了。而当 AI 能力接进来之后，压缩的幅度又往前走了一大步——以前是业务人员把需求讲给你、你来搭；现在是他讲一遍，系统先帮你搭出个七七八八。

这一篇我不打算讲技术架构，只讲体验：我踩过哪些坑，看到哪些真实变化，以及作为技术选型负责人，我会用什么标准来判断一个平台值不值得用。

二、传统业务系统搭建的真实体验：排期、沟通与漫长等待#

要讲清楚”变了什么”，得先把”原来什么样”说透。

我们内部把传统流程拆成七步：业务提需求 → 产品经理访谈 → 出原型 → 部门确认 → 开发排期 → 开发测试 → 上线验收。听起来很正常，但每一步都会掉时间。最典型的一次，行政部要做一个”办公用品领用登记”，需求从 3 月 6 日提出，到 5 月 12 日上线，整整 67 天。中间有 11 天是在等原型确认——因为行政部经理出差，来回邮件改了四版字段。

第二层痛点在”改”。业务人员看到真实界面之前，往往说不清自己要什么。第一次上线后，行政部又提了 9 处调整：加一个审批节点、把”部门”字段改成下拉、领用数量要能校验库存。这 9 处改动，我们前后又花了 6 个工作日。事后复盘，其中 7 处是”看到界面才想到”的——如果业务方能自己拖着看、边看边改，这部分成本几乎为零。

第三层痛点在”维护”。这些年我们用 Excel 加 VBA、用钉钉宜搭、也自己写过轻应用，留下的”影子系统”有二十多个。散落在不同人手里，谁离职了就没人敢动。去年一次审计，我们花了两周才把某条采购数据的来龙去脉理清楚。

我印象最深的是仓库管理员老陈。他为了记录每天出入库的批次，自己用 Excel 做了个带宏的表格，每天下班前录 40 分钟。我跟他说”给你做个系统吧”，他第一反应不是高兴，而是问：“要等多久？改一次要多久？“——这个问题我当时答不上来，因为它确实很久。

这就是真实的起点：不是技术不够强，而是供给速度跟不上业务变化的速度。低代码之所以在我们这种规模的企业里站得住脚，本质上是因为它把”供给”这件事，从 IT 部门手里分了一部分出去。

三、AI 进入低代码之后，搭积木这件事到底变了什么#

低代码本身不是新东西。我们 2021 年就试过一轮，当时的体验是：确实比写代码快，但”搭”的门槛仍然存在——你得理解什么是数据模型、什么是主外键、什么是流程分支条件。业务人员上手两小时就放弃了，最后还是 IT 部门的人在搭。

AI 的介入改变的是这个”翻译”环节。我把它归纳为四个具体变化：

第一，从”描述需求”到”生成初稿”。 以前业务方说”我要一个设备巡检表”，你得追问：巡检项有哪些、频次怎么定、异常怎么上报、谁审批。现在把这段话原样输进去，AI 会生成一版带字段、带校验规则的表单原型。我们在内部做过一次小测试：让 5 位非技术岗位的同事用自然语言描述自己的需求，AI 生成可用原型的平均耗时是 6 分钟，而过去产品经理手工画原型平均需要 40 分钟。

第二，数据模型的自动推断。 这是我认为最有价值的一点。AI 会根据你描述的实体关系，建议怎么拆表、哪些字段做关联、哪些做枚举。我们做供应商评价系统时，AI 直接把”供应商—评价批次—评分项”拆成了三张关联表，并提示了重复评价的风险。老实说，这个建议比我们组里新人给的还规范。

第三，流程逻辑的半自动生成。 比如”金额超过 5 万要走总经理审批”，AI 会把它翻译成流程条件节点。这类规则的覆盖率不是 100%，我们实测大概 七成 能一次生成正确，剩下的需要手动调。

第四，文档与测试的自动补齐。 这个是给 IT 团队省事的。以前最烦的是上线后没人写说明文档，现在平台能根据表单结构自动生成字段说明和操作手册初稿。

需要泼一盆冷水：AI 不是万能的。它对”行业黑话”的理解仍然有限，比如我们说”工单挂起”，它未必知道这是指暂停 SLA 计时。所以我的用法是——让 AI 出初稿，人做审核。这个分工目前最稳。

四、第一次上手实录：从拖拽表单到跑通审批流用了多久#

真正让我下决心的，是一次完整的亲手实操。那天我给自己定了目标：不写一行代码，把王姐要的设备巡检系统做出来。

9:20 登录平台，我先用自然语言把需求敲进去：“设备巡检记录，包含设备编号、巡检人、巡检时间、检查项（温度、噪音、油位）、是否异常、异常照片、处理状态。“系统在十几秒内生成了表单骨架，字段类型基本对，只有”检查项”被识别成了单行文本，我改成了多选。

9:35 第一张表单可用。这里我用了 JNPF 的表单设计器——我们团队在 2024 年底做过一轮选型，最终选的就是它，主要原因是可视化拖拽的颗粒度比较细，而且支持私有化部署，符合我们对数据不出内网的要求。拖拽调整字段位置、设置必填和默认值，全程鼠标操作。

10:10 配置审批流。规则是：无异常直接归档；有异常则流转到设备主管，主管 4 小时内未处理自动升级到生产经理。三级条件分支，用可视化连线画出来，中间试错了两次——一次是分支条件写反了，一次是超时提醒的计时起点选错。

11:00 做数据看板。拖了两个图表：按周的异常数量趋势、按车间的巡检完成率。这里 AI 帮了个忙，我选了”异常分布”，它自动建议按设备类型做维度拆分，比我原本想的按车间更有洞察。

11:40 配权限，巡检员只能看自己的、主管看本车间、厂长看全部。这块是拖拽勾选，不需要写 SQL。

13:30 把链接发给王姐，她用手机打开试录了两条，提了三个修改意见：照片要能多张、异常描述要能语音转文字、导出 Excel 要带车间名称。前两个当天下午就改了，第三个因为涉及关联字段，第二天上午完成。

总计：第一版 4 小时 10 分钟上线，全部修改意见闭环用了 1.5 个工作日。 对比过去 48 天的平均周期，这个差距不是”快一点”，而是量级的变化。当然我也得说清楚——这是轻量系统的数据，复杂业务逻辑依然要开发介入，后面第六章会讲。

五、三个场景的前后对比：采购、巡检与客户线索流转#

单点案例说服力有限，我把过去一年真正落地的三个场景做了横向对比。这三个系统的共同点是：都不大，但都很烦，都属于过去”排不上队”的类型。

表格之外，有两个细节值得展开。

第一个是采购申请。 这个系统的特别之处在于，它不是 IT 搭的，是采购部一位叫小周的专员在 IT 指导下用了两天搭出来的。她不懂数据库，但她最清楚流程卡在哪里。上线后她自己又加了个”超时未审批自动提醒到部门群”的小功能——这个需求 IT 从来没听她提过，因为过去她认为”提了也没用”。

第二个是客户线索。 销售助理搭完第一版之后，销售总监提了个要求：线索分配要按区域 + 产品线双维度自动路由。这个逻辑超出了她的能力范围，最后由我们 IT 用平台的脚本能力补上。这件事让我确认了一个判断：低代码不是取代 IT，而是把 IT 从 80% 的重复劳动里解放出来，去做那 20% 真正需要工程能力的事。

顺带说一句成本。三个系统如果走传统开发外包，按我们当地的报价粗算约 18—24 万元；实际投入是 IT 累计约 26 人时 + 三个业务部门各约 40 人时的搭建与调试。这个账，任何一位技术决策者都会算。

六、技术负责人关心的边界：能力上限、集成与治理成本#

前面讲的都是好话，这一章讲讲让我睡不着的部分。作为要对系统稳定性负责的人，我必须知道边界在哪。

边界一：复杂业务逻辑的处理上限。 我们试过用低代码做一个”多工序成本分摊”的模块，涉及七层嵌套计算和跨表批量回写，最后放弃了，还是回到代码。我的经验判断是：单表数据量在百万级以内、业务规则分支不超过 20 条、不涉及复杂算法的场景，低代码完全够用；再往上就要谨慎评估。

边界二：集成能力。 这是我们选型时的第一权重。业务系统不可能孤立存在，必须能打通 ERP 的主数据、能对接企业微信的通讯录、能调用第三方的电子签章。我们在选型时测试了 6 个平台的 API 开放程度，最终选择 JNPF 的一个重要原因是它提供开放的接口编排能力，能把 ERP 的物料主数据同步做成定时任务，不需要额外写中间件。这一点在私有化环境下尤其重要。

边界三：性能与并发。 我们做过一次压测：某审批类应用在 200 人同时在线时，页面响应中位数 380 毫秒，可以接受；但报表类查询在数据量超过 80 万行后明显变慢，需要做索引优化或预聚合。这类问题低代码平台不会自动帮你解决，仍要人懂。

边界四：治理成本，这是最容易被低估的。 业务人员能自己搭系统，意味着三个月后你可能面对 40 个应用、200 张表单、一堆重复的数据字典。我们踩过这个坑：两个部门各自建了”供应商”表，字段定义不一致。后来我们定了三条规矩：统一主数据由 IT 维护、应用上线必须登记、每季度做一次应用盘点下线。没有这三条，低代码会从效率工具变成技术债制造机。

边界五：供应商锁定。 这是我给所有同行的提醒。选平台时要问清楚：应用能否导出、数据能否完整迁移、私有化部署的升级路径是什么。我们内部的要求是”任何一个系统，必须能在两周内迁走”。

七、六款主流平台实测：体验维度上的差异与取舍#

2024 年底到 2025 年初，我们因为集团数字化规划，对市面主流平台做了一轮为期六周的实测。测试方法是同一套需求（就是前面那个采购申请 + 设备巡检）在四个平台上各搭一遍，记录耗时、卡点和最终完成度。参与人包括 2 名 IT 工程师和 2 名业务骨干。

需要说明三点，避免误读：

第一，评分只反映我们这套需求的匹配度，不代表产品优劣。 比如简道云在数据收集类场景的体验明显好于我们的评分结果，只是它的强项不是我们要的重流程 + 私有化。

第二，AI 能力的实际差距比宣传小。 六个平台都能做到”自然语言生成表单”，差异主要在生成后的可编辑性和字段类型准确率上。我们实测生成准确率大致在 65%—82% 之间，其中 JNPF 和明道云在高复杂度表单上的表现更稳一些。

第三，选型的决定性因素往往不是功能，而是部署方式和交付模式。 我们是制造业，数据不出内网是硬约束，这一条直接筛掉了大部分纯 SaaS 产品。这也是最终选择 JNPF 的核心原因——不是说它每一项都最强，而是它在”私有化 + 可视化 + 开放接口”这个组合上最贴合我们的现实。

最后给一个务实的建议：别只看演示，一定要用自己最复杂的一个真实需求去试。 演示环境里所有平台都很丝滑，真实需求才是照妖镜。

八、写给决策者：什么样的团队适合现在开始搭积木#

写了这么多体验，最后回到决策问题。

第一类，强烈建议现在就动手：IT 团队 3—15 人、年营收 5—50 亿、业务部门轻量需求积压超过 10 个的企业。 你们的痛点和我们一样，投入产出比最容易算清楚。我们的实测数据是：上线 9 个月，累计交付 34 个应用，IT 投入约 420 人时，若按传统方式估算需要 2800 人时 以上，效率提升约 85%。这个数字我在内部汇报时被追问过三次，最后是拿需求台账一条条对出来的。

第二类，可以试点但要控节奏：集团型、多子公司、已有成熟中台的企业。 你们的风险不是做不出来，而是做出来太多、管不住。建议先定治理规则，再放开权限。

第三类，建议再等等：核心业务强合规、强审计的行业。 不是能力不够，而是验证成本太高，先做非核心场景更稳。

如果决定开始，我给三条落地建议。

一是从”最烦但不关键”的场景切入。 别一上来就做核心业务。用设备巡检、办公用品领用这类场景跑通流程、建立信心，比什么都重要。

二是人比工具重要。 我们内部设了 4 名”业务搭建员”，都是各科室的骨干，培训了两天。他们后来贡献了 60% 以上的应用。这才是低代码真正的杠杆所在。

三是先定规矩再放开。 主数据统一、应用登记、季度盘点，这三条必须在第一周就定下来。

回到开头那个下午。王姐的系统上线三周后，我收到她一条消息：“现在车间主任每天自己看板，不用我催了。“就这么一句话，比任何效率数据都让我踏实。AI + 低代码真正的价值，不是让我们少写几行代码，而是让那些被”等不起”三个字消磨掉的小改进，重新变得值得去做。搭建业务系统像搭积木一样简单，这句话在今天已经不算夸张——前提是，你选对了积木，也想清楚了要搭什么。