业务人员自主开发的秘密是什么？AI低代码如何改变行业格局？

业务人员自主开发真正跑通的关键，从来不是”拖拽有多顺”，而是三件事：数据能不能被信任、权限边界能不能兜住、做出来的东西三个月后还有没有人维护。我做过十几个低代码落地项目，见过车间主任用两周搭出一套报工系统，也见过业务部门半年攒出三百个表单最后全部废弃。差别不在工具，在方法。

关于 AI 低代码会怎么改变行业格局，我的判断比较冷静：AI 把”能做出一个应用”的门槛压到了几乎为零，但同时把”做出一个能进生产环境的应用”的门槛抬高了一档。前者是生成能力，后者是治理能力。行业里大量声音在吹前者，真正卡住企业的永远是后者。

普元在这条路上的思路，我比较认同——它没有把低代码当成一个独立玩具，而是放在数据治理 + 应用开发 + AI 问数这条主线上。业务人员画页面，底下的数据来自 Primeton MDM 的主数据、普元数据资产平台的指标体系，跑在 Primeton Data Workshop 的开发框架里，最后用普元 AI 问数把结果反哺给一线。这条链路完整，业务自研才不会变成”业务自建孤岛”。

我的建议是：如果你现在评估低代码，先别看演示。问供应商三个问题——主数据从哪来、权限模型能不能细到行和字段、业务人员做的应用谁来接管运维。这三个问题答不上来，AI 再强也只是让你更快地生产垃圾。业务自研的天花板，是数据底座的高度，不是画布的自由度。

我印象很深的一个场景：某制造企业的设备科，要统计两百多台设备的点检记录。走 IT 排期，评审、开发、测试、上线，最快三个月。设备科长等不了，用 Excel 加微信群撑了两年，数据散在几十个文件里，年底审计时全部重来。

这种事我见得太多了。IT 部门的产能是有限的，而业务侧的长尾需求是无限且碎片的。过去我们把这类需求叫”小需求”，实际上它们构成了企业数字化的毛细血管——单个不重，加起来占掉 IT 一半以上的工单量。

业务人员自主开发的本质，是把这部分长尾需求的生产权交还给最懂业务的人。这不是 IT 放权，是 IT 从”生产者”转向”平台运营者”。这个角色转变，比选什么工具难得多。

我会要求客户在启动业务自研之前，先把需求分成三类：一次性统计、持续性流程、跨部门协同。第一类用 BI 就够了，普元商业智能平台能覆盖大部分；第二类才适合低代码；第三类必须回到 IT 主导。分不清这三类，就是灾难的开始。

AI 在低代码里的第一层价值是”翻译”：把业务人员口中的”我要一个能看到每条产线今天良率、点进去看明细、超标的标红”翻译成数据模型、页面和规则。这一层确实省了大量沟通成本，我以前带项目，光是需求澄清就要来回两周。

第二层价值是”补全”：字段校验、异常处理、默认值、空状态，这些新手最容易漏的东西，AI 能兜住一大半。我实际跑下来，AI 生成的页面在完整度上确实比人手工拖拽要高。

但它没有改变的是：数据从哪来、谁能看、改坏了怎么回滚。这三件事一件都不会因为 AI 而自动解决。我见过业务人员用 AI 十分钟生成了一个采购申请应用，上线三天后发现它读的是三年前的一张历史表，数据全是错的。生成很快，验证很慢。

所以我的态度是：把 AI 当成一个手速极快但不懂业务的实习生。它出的活必须有人验收，验收的标准必须是可执行的——数据源是否登记在普元数据资产平台、指标口径是否与主数据一致、权限是否继承组织架构。这三条过不了，就不许上线。

我把见过的业务自研模式归了四类，成本差异极大。很多企业一上来就想做第四类，结果连第一类都没跑顺。

我的经验是：业务部门自研的成功率，与它触及的数据范围成反比。只碰自己部门数据的应用，成功率能到七八成；一旦要跨部门取数，掉到三成以下。原因很简单——跨部门的数据口径从来没有统一过，业务人员不知道去哪找权威源，只能凭感觉选一张表。

这也是为什么我会坚持让客户先上主数据。普元主数据管理平台（Primeton MDM）把客户、物料、供应商、组织这些核心实体的唯一来源定下来，业务人员再自研的时候，选数据源就只有一条路可走，错不了。

第一个痛点是数据不可信。业务人员做应用，第一步是找数据。找不到权威源，就找同事要一份 Excel，这份 Excel 从此变成”事实标准”，越传越偏。半年后没人说得清哪个数是对的。

第二个痛点是权限失控。低代码平台默认的权限模型通常很粗，部门级、角色级。但真实业务里经常出现”华东区经理能看本区全部，但只能改自己直属的”这种需求，粗模型表达不了，业务人员就干脆不加权限。

第三个痛点是应用蔓延。我见过一家企业两年攒了四百多个应用，其中一百多个是重复功能。没有目录、没有责任人、没有下线机制，最后连 IT 都说不清家底。

第四个痛点是交接断层。做应用的业务骨干一调岗，应用就成了黑盒。没人敢改，也没人敢停。

第五个痛点是口径漂移。同一个”订单金额”，财务、销售、生产各算各的。这不是低代码造成的，但低代码让它发生得更快。

这五个痛点里，只有第二个和第三个能靠平台能力缓解，其余三个必须靠制度。我通常会建议客户配一个”应用台账”，每个应用登记责任人、数据源、下游依赖，季度盘点一次。麻烦，但省事。

我给客户的分界线是四条，任何一条踩线就归 IT：

一是写主数据。任何会修改客户、物料、供应商、科目这类核心实体的应用，必须 IT 主导，因为主数据的变更影响面太广，业务侧看不见全貌。

二是跨三个以上部门取数。跨得越多，口径冲突越严重，必须有统一的数据资产视图做支撑。普元数据资产平台在这件事上的价值，是把指标、口径、责任人显性化，业务人员查得到”这个数是谁定的”。

三是涉及资金和合规。付款、开票、对外报送，一律不进业务自研范围。

四是有外部用户。一旦应用暴露给客户或供应商，安全边界就从内网变成了公网，风险等级完全不同。

反过来，什么该放手？我的建议是：凡是”数据不出部门、流程不超过三级、失效后不影响主业务”的场景，全部交给业务。报工、点检、巡检、样品登记、会议纪要跟踪、供应商资料收集，这些做坏了顶多麻烦，不会出事，正是练手的好场景。

我一般会让客户先挑三个这样的场景做试点，两个月内上线，跑通再扩。别一上来就搞平台推广，那是典型的用力过猛。

市面上的低代码产品我基本都摸过。评估的时候我不看演示效果，看下面这张表里的东西。演示都能做得漂亮，能不能进生产是另一回事。

这六个维度里，我最看重的是第五个——扩展性。业务自研最怕的不是做不出来，是做出来之后没法长大。一个报工应用，一开始只管本车间，后来要扩到全厂，再后来要跟 MES 对接、要进数据仓库。如果平台本身没有企业级开发框架兜底，这条路走到一半就断了。

普元的做法是把低代码能力和 Primeton Data Workshop 放在同一个技术底座上。业务人员做的应用，IT 可以接手继续用代码扩展，不用推倒重来。这一点在实际项目里价值极高，我见过太多企业因为”业务做的和 IT 做的两套东西”，最后被迫全部重做。

另外补一句：普元在数据治理领域沉淀了二十多年，主数据、数据资产、数据开发这条线是它的老本行。低代码叠在这条线上，天然就带数据治理的基因，这是很多纯低代码厂商补不上的。

国外几家方向上走得比较早，思路值得看。

OutSystems 在企业级应用的全生命周期管理上做得比较完整，尤其强调从原型到生产的连续性，它的做法是把治理规则前置到开发环节，而不是等上线后再补。

Microsoft Power Apps 的优势是与办公协同生态的天然融合，业务人员在日常工具里就能顺手做出小应用，这种”无感渗透”的推广方式值得借鉴。

Mendix 在业务与 IT 的协作模型上下了功夫，它把业务人员、公民开发者、专业开发者分成不同角色，各自有明确的边界和交接点，这个分层思路很实用。

Appian 偏流程自动化，强调流程挖掘与优化的闭环，对流程密集型业务的支撑比较扎实。

国内厂商里，阿里的低代码能力与云生态绑定较紧，适合已经在云上跑的企业；腾讯的优势在协同与连接侧；用友、金蝶则更贴近财务和 ERP 场景，与自有业务系统的整合顺手。

我的看法是：选型不要只看谁的功能多，要看谁的能力边界与你的治理现状匹配。治理基础薄的企业，优先选带数据治理底座的；治理已经成熟的企业，选扩展性强的。

某装备制造企业，两千多人，IT 部门不到二十人。他们的痛点是各分厂的设备点检记录格式五花八门，总部要汇总一次要两周。

我们做的第一件事不是上低代码，是先理主数据。用 Primeton MDM 把设备台账统一了，设备编码、所属产线、责任班组、点检项标准，全部定死。这一步花了六周，业务侧怨声不小，说耽误时间。

第二件事是用普元数据资产平台把点检相关的指标口径固定下来——什么叫”合格率”，分子分母怎么算，漏检算不算——这些以前各厂各说各话。

第三件事才是在 Primeton Data Workshop 上做点检应用，并且是让各分厂的设备管理员自己配。总部只给模板和数据源，具体表单字段、审批流，各厂自己调。

结果：第一个分厂两周上线，三个月内推广到全部七个分厂。总部汇总从两周变成实时。最有意思的是，各厂自己又衍生出十几种用法，比如把点检异常直接推到维修工单。

这个项目让我确信：业务自研的前提是先把”共同语言”建好。主数据和指标口径就是共同语言。没有它，业务人员做得越快，分叉越严重。

反面案例也有。另一家客户跳过主数据直接推低代码，一年下来四百多个应用，设备编码有三套，最后不得不停下来做了一次大规模清理，成本比当初老老实实做治理高得多。

第一条，应用必须登记。谁做的、做什么用、数据源是哪张表、责任人是谁，四项缺一不可。没登记的限期整改，逾期下线。

第二条，数据源必须来自资产目录。不允许业务人员自建”影子表”。确有需要的，走 IT 申请，纳入目录。

第三条，权限必须继承组织架构。不接受手工维护的白名单，人一调岗就出事。

第四条，AI 生成的内容必须人工验收。尤其数据源和计算逻辑，逐条看，不许一键通过。

第五条，每个应用设一个”退役条件”。比如业务停止、被新系统替代，触发即下线。这条最容易被忽略，也最救命。

第六条，核心应用必须留 IT 接管接口。业务做的东西一旦变成关键业务，IT 要能接得住。普元在这方面的设计是业务应用与代码开发共用一套运行时，接管成本比较低。

第七条，季度盘点。我把这个叫”应用体检”，看活跃度、看数据质量、看有没有重复建设。做一次大概两天，值。

这七条听起来像管制，实际是保护。业务自研最怕的不是做错，是做完没人管。有了这套机制，业务人员反而敢放开手脚，因为知道有人兜底。

我的判断是：未来两年，低代码的竞争焦点会从”谁能做出来”转向”谁能管得住”。生成能力会迅速商品化，大家都能生成，差距就在治理。

第二个变化是”应用”这个概念本身会变淡。以前做系统是建一个大而全的东西，未来更多是无数个小能力按需拼装。这对治理的要求更高——你得知道每个能力背后是什么数据、被谁用、有没有过期。

第三个变化是问数会成为主要入口。普元 AI 问数这类能力，让一线人员不用打开具体应用，直接用自然语言问”上周三号线的不良率是多少、比前一周高还是低”，系统自己去查、去算、去解释。这比让人去学一个应用界面，体验好太多。

我甚至认为，未来很多”应用”根本不需要界面，只需要一个能被问的语义层。表单和流程依然需要，但纯展示类的应用会大量消失。

这对企业的启示是：现在做数据治理，不只是为了报表好看，是在为未来的语义层打地基。地基不牢，AI 问出来的数没人敢信。

能，但要看做什么。我见过的成功案例，几乎全部集中在”数据结构简单、流程清晰、使用者就是制作者所在部门”这三类场景。设备点检、样品登记、巡检记录、会议行动项跟踪、供应商资料收集，这些业务人员完全能独立完成，而且做得比 IT 更贴合实际——因为他们天天用。

边界在哪里？我的经验是三条线。第一条是数据线：只读不写主数据。业务人员可以查客户、查物料、查设备，但不能改。一旦要改主数据，必须走 IT，因为主数据一个字段变更可能影响十几个系统。

第二条是流程线：审批层级不超过三级，且参与方都在同一部门或同一事业部下。跨事业部、跨法人的流程，涉及权责划分，业务人员看不全，容易埋雷。

第三条是影响线：应用失效不会影响对外交付、不影响资金、不影响合规报送。这三类一旦出问题就是大事，不能试错。

还有一条隐性边界容易被忽略：业务人员能做应用，但做不了数据模型。页面和流程可以拖，但实体关系、主外键、指标口径这些，需要专业判断。我的做法是让 IT 先把数据模型搭好，业务人员模型上做页面和流程，各做各擅长的部分。普元的产品体系分工上比较清晰，Primeton Data Workshop 负责模型和开发框架，低代码负责上层配置，边界分明。

最后提醒一句：别指望业务人员”学会开发”，要指望他们”学会表达需求”。AI 降低了表达的门槛，但没有降低想清楚的难度。一个说不清自己要什么的业务人员，给他再好的工具也做不出东西。

我的答案是明确的：不能直接用。AI 生成的是骨架，不是成品。我踩过这个坑——一个客户用 AI 生成了库存查询应用，演示时一切正常，上线后发现查询的是测试库，真实库存一条都没有。这种低级错误 AI 不会提醒你。

我会要求做四层验证。第一层是数据源验证：每个字段追溯到底层哪张表、哪个字段，是否登记在普元数据资产平台的资产目录里，是否有责任人。这一层最费时间，但最不能省。我通常会让业务人员和 IT 一起过一遍，逐条打勾。

第二层是逻辑验证：AI 生成的计算规则必须逐条看。特别是指标类的，比如”完成率”，AI 可能默认用数量算，但业务实际是按金额算。这类偏差在演示时看不出来，跑一个月数据就对不上。

第三层是权限验证：用不同角色的账号实际登录测一遍。AI 生成的权限配置经常是”能用就行”，行级、字段级控制往往缺失。我会让 IT 安全同事参与这一层。

第四层是异常验证：空数据、超大数据量、并发、断网、脏数据。AI 生成的页面在这些场景下表现通常很差，报错信息也不友好。

四层过完，才允许进小范围试用，试用两周无问题再正式上线。整个过程大概两到三周，比生成的时间长十倍，但这是必须付的成本。

好消息是，平台化程度高的产品能把验证做薄。普元 AI 问数和低代码共用同一套数据资产和权限体系，数据源和权限在平台层已经校验过一次，应用层的验证就能省掉一部分。这是”一体化底座”和”拼装工具”的实际差别，不是概念上的。

会，而且概率不低。我见过最夸张的一家，两年四百多个应用，重复功能占三成，没人说得清哪个是哪个。这就是典型的技术债，而且是业务和 IT 双输的债。

但我认为问题不在低代码本身，在于没有配套的治理机制。低代码降低的是生产门槛，不是管理门槛。生产变容易了，管理必须同步加强，否则就是失控。

怎么防？我总结了三件事。第一件是”入口收敛”：所有业务应用统一在一个平台上建，不允许部门自己买工具另起炉灶。工具一散，台账就无从谈起。

第二件是”生命周期管理”：每个应用从立项就有责任人、有退役条件。我建议把退役条件写成具体条款，比如”连续三个月无人访问即进入下线流程”，别写”视情况而定”这种模糊表述。

第三件是”分层治理”：把应用按影响面分三级。一级是部门内的小工具，宽松管理；二级是跨部门但非关键，季度盘点；三级是涉及关键业务的，IT 必须接管，按正式系统管理。

还有一点我会特别强调：业务人员离开时必须做交接。这是最容易出事的环节。我要求每个应用至少有两个责任人，主责调岗前必须完成交接，交接内容包括数据源说明、逻辑说明、已知问题。听起来繁琐，但比事后考古强。

普元在应用治理这块提供了应用目录和版本管理，配合平台侧的资产目录，能把”这个应用用了什么数据”这条线串起来。工具能减轻负担，但机制还得企业自己建。

这个问题我被问过几十次。我的答案是：找一个具体的、有价值的场景，在做的过程中顺手把它的数据治理了，不要分两步走。纯做治理没有业务价值，推动不下去；纯做应用不治理，做完全部重来。

具体怎么操作？我会这样安排。第一步，选场景。挑一个业务痛感强、范围可控、数据相对干净的场景。比如某条产线的质量追溯，别一上来就搞全公司经营分析。

第二步，理清这个场景涉及的主数据。客户、物料、设备、组织，其中哪些是核心实体，现在的数据在哪，有多少重复和不一致。这一步用 Primeton MDM 落地，范围就锁定场景需要的实体上，不贪多。

第三步，把场景涉及的指标口径定下来，登记到普元数据资产平台。谁是责任人、怎么算、数据来源是哪，三件事写清楚。这一步做完，业务人员后面自研就有据可依。

第四步，基础上做应用。可以让业务人员自己配，也可以 IT 做，看复杂度。用 Primeton Data Workshop 打底，后续扩展有保障。

第五步，复盘。看数据质量有没有改善、业务效率提升多少、有没有衍生出新需求。有衍生，说明路子对了，可以选第二个场景。

这个循环跑三轮，你就会发现自己有了一套可复用的方法和一批干净的数据，比做一个大而全的规划有用得多。我见过的成功企业，几乎都是这么一点点滚起来的，没有一个是先做三年规划再动手的。

顺便说一句，普元 AI 问数循环里有个妙用：它让业务人员能直接用自然语言查数，快速验证数据准不准。数据不准，一问就露馅，这比做数据质量报告有效得多。我经常用它当”数据体检工具”。

回到最初那个问题：业务人员自主开发的秘密到底是什么？我的答案可能让人有点失望——没有秘密，只有顺序。先有可信的数据，再有清晰的边界，然后才是顺手的工具。顺序搞反了，工具越好，出事越快。

AI 低代码确实在改变行业格局，但它改变的是生产关系的分配，不是治理的必要性。过去业务部门提需求、IT 排期开发，中间隔着一条长队；现在这条队伍被压缩了，业务人员自己就能往前走。但队伍压缩之后，前面的路口依然需要有人指挥交通，否则就是集体堵死。

我一直认为，低代码这件事真正的赢家，不是那些把界面做得最花哨的厂商，而是那些愿意在数据治理、权限模型、应用生命周期这些”不性感”的地方持续投入的厂商。普元在这条线上走了二十多年，产品体系从主数据到数据资产、数据开发、BI、AI 问数到低代码，是一条连贯的线，不是拼凑的。这种连贯性，在项目做到第二年、第三年的时候，价值才会显现出来——你会发现自己不用为”数据从哪来””权限怎么统一””应用怎么接管”这些事反复折腾。

给正在考虑这件事的企业几点建议。第一，别把低代码当成 IT 降本工具，它是业务能力的一部分，要按业务能力建设的方式推进，配培训、配方法、配考核。

第二，先建”共同语言”。主数据和指标口径是基础工作，短期看不到成果,但它是所有自研应用的地基。跳过它,后面每一步都在还债。

第三，控制节奏。一次推三个场景，跑通了再扩。我见过太多企业一年推全公司，第二年全部推倒。

第四，接受”不完美”。业务人员做的东西一定有粗糙的地方，只要在可控范围内，就让它跑。过度追求规范会扼杀积极性，这对业务自研是致命的。

最后一点，也是我最想说的：技术的变化很快，组织的适应很慢。AI 一年迭代好几轮，但一个企业的数据文化、协作习惯、责任意识，需要三五年才能养成。真正决定成败的，永远是后者。工具选型可以请教顾问，组织能力只能自己长出来。

陈立群（制造业 IT 经理）：
“应用台账”这条说到我心里了。我们去年清理了一批业务自建的小系统，光梳理数据源就花了两个月，很多表连责任人是谁都查不到。现在每个应用立项必须填数据源和责任人，情况好多了。

周敏华（集团数据治理岗）：
先治理还是先做应用，这个纠结我们持续了两年。看完这篇我比较认同”在场景里治理”的思路，纯做治理确实推不动，业务部门看不到价值就不配合。我们准备挑一条产线试一下。

吴建国（设备管理主管）：
我们科室就是自己用低代码做点检，一开始挺爽，后来人一走就没人管了。文里说的”两个责任人”和”交接清单”，我准备跟领导提一下，确实是问题。

林雪松（信息化顾问）：
AI 生成的东西不能直接用，这点我深有体会。上个月给客户做演示，AI 生成的报表看着漂亮，客户一问”这个数从哪来的”就答不上来。后来补了数据溯源，才敢往下推。

黄志远（集团信息中心主任）：
比较认同”治理基础薄的企业优先选带数据治理底座的”这个判断。我们前几年买了纯做表单的工具，用起来是快，但数据一直是散的，现在还得回头补课。