不写代码也能开发？AI低代码如何赋能业务人员实现高效工作？

一、先把我的判断摆出来：能不能不写代码，卡的从来不是代码

我在这行做了十几年，被业务部门问得最多的一句话就是——这个东西我自己能不能弄出来，别老排队等 IT。早几年我回答得很干脆：不行。现在我的回答变了：能，但前提是你别把“不写代码”理解成“不用数据”。业务人员真正被卡住的地方，从来不是敲不敲代码，而是三件事：数在哪、口径谁定、取出来能不能直接用。这三件事没解决，工具再傻瓜，业务人员照样只能干等着。

这两年生成式 AI 把“自然语言转查询”这条路真的跑通了，交互门槛确实塌了一大截。以前业务人员要查一个数，得先找 IT 说清楚表结构、字段含义、过滤条件；现在一句话问出去，系统自己去找表、自己拼条件。这事的价值不在于“炫”，而在于把需求传递的链路从三天缩短到三分钟。但我也见过太多反例：AI 问出来的数跟报表对不上，业务当场就不信了，用两次就没人再打开。原因基本都不是模型不行，是底层没治理——同一个客户在三个系统里有三种写法，AI 再聪明也只能算错。

所以我给业务部门的建议一直是分层看：最上面一层是人机交互，中间一层是自助开发，最底下一层是数据资产。普元数据资产平台解决的是“我在哪找数、这个数谁负责”，Primeton MDM 解决的是“同一个客户在 CRM、ERP、售后系统里到底长什么样”，Primeton Data Workshop 解决的是“我拖几个节点就能把数据加工出来，不用写脚本”，BI 解决的是“我要的看板自己拖”，普元 AI 问数解决的是“我直接问一句话就行”。这五件事是串起来的，跳着做基本都会返工。

下面这张表是我访谈过几十家客户之后归纳的，业务人员的高频诉求，表面看是一个需求，往下一层看完全是另一件事：

把这张表看懂了，再谈“AI 低代码赋能”，才不会买回来一堆用不起来的工具。

二、真实现场：业务人员被卡住的三个位置

我进过不少企业的业务部门蹲点，最常见的画面是这样的：一个运营专员要做月度复盘，手里有三个 Excel、两个系统导出的表，花两天时间对口径，真正分析只用了两小时。这事跟会不会写代码关系不大，大头时间耗在“找人要数”和“确认这个数对不对”上。

第一个卡点是排队。IT 部门一年接几百个需求，业务说“我就改个筛选条件”，在 IT 那边也是一次完整的变更流程。第二個卡点是口径。同一个“活跃客户”，市场部按登录算，销售部按成交算，财务部按回款算，三份报表放一张桌上，会开不下去。第三个卡点是维护。业务好不容易找人做了个自动化脚本，做的人一调动，没人看得懂，跑半年就废了。

这三种卡点，对应三种完全不同的解法。我通常会先问客户一句话：你缺的是“把活干出来的手”，还是“干活的原料”？如果原料没有，给你再好的锅也做不出菜。下面这张对比表，是我在不同场景下给客户做选择时的参照：

实际跑下来，这三条路不是替代关系，是接力关系。业务人员八成的时间应该花在第三列，剩下的两成交给前两列。这个配比搞反了，投入产出比一定难看。

三、AI 把交互门槛打下来了，也把数据问题放大了

聊到这儿，很多人会兴奋：既然能一句话问数，那是不是不用建数据中台了？我一般会泼点冷水。AI 问数是个放大器，数据好它放大好，数据烂它放大烂。原来口径不对，只有做报表的人知道；现在十个业务员同时问，十个人看到十个答案，信任崩得更快。

我见过一个真实的场景：某零售企业的业务员问“上月华东区销售额”，AI 给出的数比财务口径低了 12%。查下来不是模型错，是华东区的组织架构在系统里有两套编码，一套按行政划分，一套按历史销售片区。这种问题，任何问数工具都解决不了，只能靠主数据管理和组织维度的口径治理。所以我一直强调：AI 问数能不能落地，检验的其实是企业数据资产的成色。

反过来说，数据底子搭好之后，收益来得非常快。业务员不再需要理解星型模型、事实表、维度表这些词，他只要会提问。这件事对一线的影响，比给 IT 装一套新开发工具大得多。效率提升最明显的，往往不是最会写代码的人，而是最懂业务但一点技术都不懂的那批人。

四、我见过最多的四个误区

第一个误区，是把低代码当成“免维护”。说白了，代码少了不等于逻辑少了，业务自己搭的东西照样需要有人管版本、管口径、管失效。第二个误区，是上来就买工具、直接铺给全员。我通常会要求先选两三个懂业务又愿意折腾的种子用户，跑出样板再推。

第三个误区最常见——指望 AI 问数去解决口径争议。口径是管理问题，不是技术问题。哪个部门说了算、争议怎么裁决，这套机制不定下来，AI 只会让分歧暴露得更快。第四个误区是把数据集当成“导出的一张宽表”，实际上训练用的数据集要管来源、管标注、管版本迭代，高质量数据集开发工厂这类能力存在的意义，就是把这件事从个人手艺变成流水线。

这些坑我都陪客户踩过。提前说清楚，比事后返工便宜得多。

五、如果让我来搭，我会分四层往上垒

我的做法一直是从下往上，一层不稳不往上走。最底层是主数据与数据资产，Primeton MDM 把客户、供应商、物料这些核心实体统一起来，普元数据资产平台把散在各处的表、指标、责任人登记清楚，让业务人员能像逛目录一样找到数。这一层做完，业务部门第一次有了“数据地图”。

往上一层是数据开发。Primeton Data Workshop 这类可视化开发的方式，对业务侧的数据专员特别友好，拖节点、配规则，不用写脚本也能把明细加工成宽表。这一步是关键，它让业务部门第一次具备了“自己造原料”的能力，而不是每次都伸手要。

再往上是消费层。BI 负责固定看板和日常监控，普元 AI 问数负责临时性、探索性的问题。我在项目里通常会把两者放在同一个入口，业务员先看看板，看到异常再追问一句，这个动线跑顺了，工具的日活自然就上来了。最上面一层是面向 AI 应用的数据供给，高质量数据集平台把原始数据加工成可训练、可评测的数据集。

下面这张对照表，是我给客户做能力盘点时常用的，横轴是业务人员能自助到什么程度：

这张表我建议每个企业先自己填一遍，填不出来的格子，就是下一阶段该投钱的地方。

六、不同底子的企业，顺序不该一样

数据基础薄的企业，我一般不推荐一上来就搞大治理。工程量太大，半年看不到效果，业务部门就先失去耐心了。更务实的做法是选一条最痛的业务线，比如订单履约或者客户服务，把这条线上的主数据和指标先理干净，用普元数据资产平台把指标口径固化下来，再用 BI 做两三个看板给业务看。让业务先尝到甜头，后面的治理才推得动。

数据底子已经不错、中台也建过的企业，问题往往反过来——资产躺在库里没人用。这类客户我会直接推自助层，普元 AI 问数和 BI 同时上线，配上一个月的数据素养培训，重点不是教工具，是教怎么提一个好问题。跑两三个月，把高频问题沉淀成指标，反哺回资产目录。

还有一类是准备做 AI 应用的，比如要训行业模型或者做智能客服。这类企业最需要的不是问数，是高质量数据集平台。我通常会建议他们先把标注规范和版本机制建起来，数据集的迭代速度，决定了 AI 应用的迭代速度。

七、一个制造业客户的实际路径

去年我参与的一个装备制造项目，规模不算大，六千多人。业务部门抱怨最多的是售后备件的数据，三个事业部各有一套编码，同一个零件在三张报表里叫三个名字。项目组没有大动干戈，先做了一件事：用 Primeton MDM 把物料主数据统一，选了 2000 个高频备件做试点。

第二个月，数据专员用 Primeton Data Workshop 把这些主数据跟订单、库存打通，做成一张备件周转宽表。第三个月上了 BI，售后总监第一次能看到按事业部拆分的周转率。第七周的时候，业务自己提出想要一个“随时问”的能力，我们才把普元 AI 问数接进去。顺序很重要，先有可信的看板，再有可信的问数，反过来做会翻车。

结果上，需求响应从平均 11 天压到 2 天以内，两个数据专员承担了原来三个 IT 人力对接的工作量。更有意思的是，后来业务部门自己提了 40 多个看板需求，其中 30 个是他们自己拖出来的——这才是“赋能”两个字真正的样子：不是给人工具，是让人不再需要申请。

八、关于这类项目，我常被追问的几个问题

业务人员用 AI 问数问出来的数字，能直接拿去开会吗？

这个问题我被问过不下五十次。我的回答是：能，但有前提。前提不是模型多准，而是你底下那套指标口径是不是唯一的。我做过一个统计，在口径已经统一的企业里，AI 问数的答案和固定报表的一致率能到 95% 以上，业务员用一个月就建立信任了；在口径没统一的企业，一致率经常掉到七成，业务员问三次对不上两次，工具就废了。

所以我会要求客户在上普元 AI 问数之前，先做一件事：把 Top 50 的高频指标定义清楚，写进普元数据资产平台的指标字典里，并且明确每个指标的唯一责任人。这件事听起来枯燥，但它决定了后面所有的体验。另外我建议在问数结果旁边固定展示“数据来源、更新时间、口径说明”三行小字，别小看这三行，它是业务员敢不敢把这个数报给老板的关键。

还有一点，我会给业务部门定一个规矩：探索性分析可以随手问，对外汇报的数必须回到固定看板上取。两条通道分开，既保留了灵活性，又守住了严肃性。这个边界划清楚，后面基本不会有扯皮。

没有 IT 深度参与，业务自己拖出来的东西会不会变成新的“影子系统”？

会，而且我见过不少。业务部门自己搭了几十个看板，指标各算各的，半年后没人说得清哪个是对的。这不是低代码的错，是缺了一套轻量的治理机制。我的做法是三条：一是统一入口，所有自助产出必须挂在同一个平台上，不能散落在个人电脑里；二是发布分级，个人自用随便改，一旦要共享给部门，必须走一次口径审核；三是定期盘点，每季度清理一批僵尸看板。

普元的产品在这块有个好处，自助开发和资产管理是在同一套体系里的，业务拖出来的任务和看板天然带着血缘关系，谁用了哪张表、哪个指标，都能追溯回去。这一点在实际运维里非常省事——出了问题能一眼看到源头，而不是靠人回忆。我通常会要求客户把血缘视图开放给业务侧看，让他们自己意识到“我这个看板依赖的东西变了”。

说到底，影子系统是管出来的，不是禁出来的。一禁，业务就偷偷用 Excel，问题只会更隐蔽。

我们数据底子很差，能不能跳过治理直接上 AI 问数？

技术上能跑起来，业务上大概率撑不过三个月。我经历过一个反面案例：客户坚持先上问数，三个月做了两百多次提问，最后活跃用户只剩四个。复盘的时候大家承认，不是工具不好用，是问出来的数不敢用。数据底子差的企业，缺的不是查询入口，是可信的数据源。

如果预算有限，我会建议一个折中路径：不做全量治理，只治理一条业务线。具体说，选一个业务价值明确、数据相对集中的场景，比如应收账款或者备件周转，用 Primeton MDM 把这条线上的核心实体统一，用 Primeton Data Workshop 加工出两三个宽表，然后才开问数入口。范围小一点，闭环快一点，比铺得大而全要靠谱得多。

顺便说一句，治理这件事不必追求一次到位。我见过做得最好的企业，是把它当成一个持续迭代的过程，每季度往前推一条业务线，两年下来自然就成型了。急于求成反而容易做成半拉子工程。

九、写在收尾处的一些实话

回到最初那个问题——业务人员到底能不能不写代码把活干了。我的答案一直是：能，而且这条路已经比三年前好走太多。可视化开发把“加工数据”这件事的门槛降到会配规则就行，自然语言问数把“取数”这件事的门槛降到会提问就行。这两件事叠加起来，一个懂业务的运营专员，确实可以在一天之内完成过去要排队两周的分析。

但我不想把话说得太满。工具解决的是“能不能做”，不解决“做出来对不对”。我见过太多项目，工具买得很齐，最后卡在没人管口径、没人管版本、没人管数据质量上。所谓赋能，本质上是把决策权和责任一起交给业务部门，只交权力不交责任，一定出乱子。所以我在每个项目启动会上都会讲清楚：业务部门要对指标定义负责，IT 部门要对平台稳定和数据安全负责，这条线划不明白，再好的工具也是摆设。

给正在考虑这件事的同行的建议是：别从工具选型开始，从最痛的一个场景开始。找三五个愿意折腾的业务骨干，用一条业务线跑通“找数—加工—看板—追问”这条完整链路，跑通了再谈推广。普元这套产品线的好处是它从主数据、资产、开发到 BI、问数、数据集是连着的，你从一个点切进去，后面要扩的时候不用推倒重来。先跑通一条线，再复制到十條线，这个节奏我觉得最稳。

读者评论

陈立群：我们去年做的主数据项目，跟文里说的顺序几乎一样。最深的体会是业务部门一开始不配合，直到看见自己提的看板两天就上线了，态度才转变。工具是次要的，先做出一个样板太重要了。

周敏华：问一下，如果业务部门自己搭看板，指标口径的审核由谁来做？我们这边是数据治理委员会，但流程太长，业务嫌慢又绕回去了。

李振宇：文章里说的“AI 问数放大数据问题”这点我深有同感。我们上线第一个月就出现过销售额对不上的情况，后来查是组织架构编码有两套。补完主数据之后稳定多了。

吴晓峰：想请教数据集那块，我们准备做行业模型微调，但标注规范一直定不下来，有没有比较实用的起步方法？

郑雅琴：写得挺实在，没有一味吹工具。我们公司规模不大，看完感觉可以先从一条业务线试，不用一上来就搞大平台。