一、从一次深夜加班说起：我们为什么开始重新审视 AI 低代码#

去年 11 月的某个周四，晚上十点半，我还坐在会议室里。桌上摊着那份已经改了四版的研发排期表，对面的业务总经理已经问第三遍：“经销商对账系统真的不能提前吗？”

我说不能。按排期，这个需求排在三个月之后，开发加测试最少需要六周。理由说得很充分，只是对面的人并不关心逻辑通不通顺，他只关心月底经销商大会之前能不能用上。

那天回家的路上，我一直在想两件事。第一，我们组四十个研发，为什么还是被需求压得喘不过气？第二，过去半年里，那些“自己动手做点东西”的业务同事，到底在用什么东西？

答案是：Excel、在线表格，以及各种各样的 SaaS 小工具。数据散在五六个地方，没有统一权限，经常出现两个版本同时在对账的情况。业务部门以为自己在提效，实际上在给自己挖坑。

这其实是很多技术决策者共同的处境：研发资源永远紧张，业务对数字化的期待却在加速。传统开发模式的瓶颈，已经不在某一段代码写不出来，而在需求的“排队”和“等待”。也就是在这个阶段，我开始认真看 低代码 这条路线。

一开始我是有偏见的。我见过不少低代码演示：拖拽几下，界面很漂亮，一落到企业真实的集成、权限、审计场景就歇了。直到有厂商把 AI 能力接进来——用自然语言描述需求直接生成页面骨架、根据表单自动反推数据模型、根据历史接口自动补齐字段映射——演示到一半，我承认自己有点坐不住。

但当时我并没有立刻推动采购。原因很简单：demo 好看不等于账算得过来，demo 跑得快不等于三年之后还划算。于是就有了接下来整整一年，围绕 AI 低代码的 投入规划 与 成本收益 反复推演的过程。我在内部把它叫作“三本账”。

二、算清三本账：AI 低代码的显性成本与隐性成本#

我担心的从来不是花得多，而是花得不明白。所以第一轮内部评审，我没有讨论“要不要做”，而是要求团队把所有成本项拆开，一项一项填。

拆出来的结果，出乎很多人意料。

真正让我警觉的是隐性成本。有一家第三方研究机构在 2024 年的调研里提到，企业在低代码项目上的隐性成本平均占三年总拥有成本的 41%，明显高于多数团队的初始预估——我们第一年的数据是 32%，算是接近但还没到那个水平。

我把它总结成“三本账”。

第一本是采购账：许可费、席位费、云资源，这部分最透明，也最容易成为比价焦点，容易被当成全部。

第二本是接入账：和存量系统集成、数据口径统一、权限体系对齐。我们对接 6 个系统，其中 2 个是十年前的老 ERP，接口文档基本靠猜。这部分投入没人提前报价，但一定会发生。

第三本是运营账：平台上线之后谁来管，谁能建应用，应用出了问题谁负责，权限怎么审。这笔账最容易被忽略，但它决定了第三年、第五年是继续省钱还是继续烧钱。

把这本账算清楚之后，我做了一个判断：AI 低代码的投入规划，本质上不是选一个工具，而是排一条能力演进的路线。 工具是可以换的，路线一旦选错，沉没的成本可不止是许可费。

三、被低估的收益侧：效率、人才与业务响应速度#

成本看得越细，收益就越不能含糊。否则整个项目就变成了“能省则省”的降本游戏，那方向就偏了。

我们最终确定了四个可量化的收益口径，并且在项目立项时就把基线记录了下来。

第一项变化最直观。以前一个审批流需求，从提需求、评审、排期到上线平均 42 天；现在业务部门提完需求，IT 给一个模板和一套安全规范，最慢的场景两三周，简单场景四五天就能跑起来。我们内部做过一次统计，采用平台化方式交付的项目，团队整体效率平均提升了 37.8%——这个数字比单项工时降幅温和，因为它把学习成本和集成成本都算进去了。

第二项变化是我没预料到的。有 34% 的新增应用，是业务侧自己搭的。其中有一个场景我印象很深。

场景一：财务部的小李

财务部的小李不懂代码，但特别熟悉业务。每个月结账前，她要从三个系统里导数据，手工做 27 张对账表，用她自己的话说，“每月最后一周基本不是在睡觉，是在复制粘贴”。原来这件事的解决路径是提需求给 IT，评估排期至少两个月。

我们试点之后，IT 给了她一个数据源模板和一套字段规范，她用两天时间把自己的对账逻辑搬进了平台，第三天就上线了自己在用。第二个月，她把模板分享给同组的两个同事。到第四个月，这张表已经被三个业务单元复用。

她后来跟我说，最爽的不是省了多少时间，是“不用再求人了”。这句话我记了很久。

第三项收益是人才结构的变化。研发人力没有被裁掉，而是被挪去做了三类更值钱的事：架构治理、存量系统改造、AI 能力接入。一个后端工程师告诉我，以前他一年要写 30 个审批表单，现在写的是平台的扩展组件，用一次就能被全集团复用。

这也是我理解 AI 低代码成本收益时最重要的一个视角：它真正释放的不是开发工时，而是把“重复建设”转成“能力沉淀”的机会。 如果只盯着省了多少人天，这笔账其实算小了。

四、投入规划的四个阶段：从试点到规模化的节奏控制#

我见过太多低代码项目，死法只有两种：要么是一开始就全集团铺开，第三个月没人用；要么是一年只做个 demo，永远停在验证阶段。

我们后来总结出一套四阶段节奏，回头看，这是我们整个项目里最有价值的一条经验。

第一步，单点验证。 目标不是证明平台好，是证明这条路在你自己的系统环境里跑得通。我们选的是经销商对账，因为它同时涉及外部数据导入、内部权限、审批流和报表导出，几乎把所有坑都覆盖了。这一步我们只花了 6 周，投入不到总预算的 8%。

第二步，小范围试点。 挑部门有讲究：不要挑最积极的，也不要挑最抵触的，要挑“业务变化快、IT 响应慢”落差最大的那个。我们选的是供应链和财务。这一步的关键指标不是应用数量，而是有多少业务同事在没有 KPI 压力的情况下主动来用。如果这一步还要靠行政命令推，说明前面的价值没跑出来。

第三步，部门级推广。 这一步的重点从“用起来”切换到“管得住”。我们成立了平台小组，制定了权限规范、发布流程、应用归档机制，还从业务侧培养了 6 个内部讲师。培训不再由厂商做，而是由种子用户讲给同事听——效果反而更好。

第四步，企业级平台化。 这一步才谈平台统一、组件复用、与中台打通。我们是在第 11 个月才启动的，比原计划晚了两个月，但事后看，晚一点是对的。

有一次我们差点犯错。第三步刚开始时，另一个事业部找过来，说想一次性把三十多个应用全迁上来。我们内部讨论了三天，最后拒绝了，只同意先迁两个最痛的点。三个月后那个事业部自己提出来“再迁十个”，效率比我们强推快得多。

投入规划最难的从来不是分多少钱，而是按什么节奏花。 节奏错了，钱花得再多也追不回来。

五、三类企业的差异化账本：谁该重投入，谁该慢走#

经常有人问我“我们这种公司到底值不值得做”。这个问题没法一概而论，因为 AI 低代码的成本收益，跟企业自身的三个变量高度相关：需求变化的频率、IT 人力的紧张程度、以及存量系统的复杂程度。

按这三个变量，我大致把企业分成三类。

第一类：业务变化快、IT 人力紧的中型企业。 这类企业是收益最明显的。典型画像：营收 5 亿到 50 亿，研发团队 20 到 100 人，业务侧每年有几十个数字化小需求在排队。 对它们来说，AI 低代码解决的是“响应速度”问题，ROI 通常在第一年就能看到。我们的建议是：预算不必大，但要留出治理预算，不要让业务部门无限制自助搭建。一个可以参考的比例是：平台与实施投入 60%，治理与培训投入 40%。

第二类：多业务单元的集团总部或大型企业。 这类企业的核心诉求不是省人力，而是统一与复用。它们的账要按三年、五年算，第一年基本是投入期，ROI 为负是正常的。 我们自己的数据是，第一年 ROI 约 -0.4，第二年转正到 0.9，第三年预计到 1.7。所以如果一家大型企业的决策层只看第一年回报，这个项目大概率做不成。

第三类：已有成熟中台、系统高度标准化的超大型企业。 说实话，这类企业不一定需要立刻重投入。如果存量系统已经覆盖了 90% 以上的业务场景，需求变化又不频繁，那么 AI 低代码带来的边际收益有限。更合理的做法是先做小范围验证，把它当成中台的“快速交付层”，而不是替代品。

我曾经跟一家制造业客户的技术负责人聊过。他们年营收 200 多亿，IT 团队 300 人，一开始也想上大平台。我建议他们先别急，先用两个工厂做试点，重点验证“和 MES 系统的集成深度”。半年后他们反馈，试点跑得不错，但他们在第二期把预算砍掉了 40%——因为他们发现，真正需要低代码的场景比预想的少，反而集成治理的投入需要加大。

这不是失败，这是投入规划该有的样子：不是把钱花完，而是把该花的钱花在对的地方。

六、踩过的坑：低代码投入规划中最容易翻车的五种情形#

一年下来，我们自己踩了三个坑，也旁观了同行踩的两个。总结成五条，供参考。

坑一：只算许可费，不算治理费。 最常见的翻车方式。很多团队把预算做到极致，把所有钱都花在采购上，结果平台上线三个月，应用数破百，权限混乱，没人知道哪个应用能用。治理预算不足，返工成本往往是采购费的 1.5 倍以上。 建议：治理与培训预算不低于总预算的 25%。

坑二：一开始就全量铺开。 “既然有价值，就推广到所有部门。”这句话几乎是所有失败项目的开场白。全量铺开意味着你同时面对十几套业务逻辑、五六种集成方式和无数个培训对象，反馈周期从两周变成一个季度，项目必然失控。 建议：任何一个新阶段，覆盖部门不超过 3 个。

坑三：把低代码当成外包替代品。 有一类团队把低代码当“更便宜的外包”，用它去做那些原本要花钱外包的项目，做完就撤，不留资产、不留文档、不留组件。这种做法第一年看着省钱，第三年你会发现，你只是用另一种方式积累了一堆技术债。 建议：每个项目结束，强制要求沉淀至少一个可复用组件。

坑四：忽略集成与数据口径。 低代码平台本身很快，但它快不过你的老系统。我们的项目里，60% 的延期都发生在集成环节，而不是页面开发环节。数据口径不统一，是最大的隐藏延期源。 建议：项目启动前，先花两周做接口与数据源盘点。

坑五：没有退出与评估机制。 没有评估机制，你就不知道什么时候该加码、什么时候该停。我们每个季度做一次评审，指标包括：新增应用数、活跃业务构建者数、复用组件数、集成故障率、以及业务满意度。有一次评审结果显示，某部门的活跃构建者连续两个月为 0，我们果断停掉了那个部门的推广计划，把资源挪到了另一个部门。

AI 低代码不是万能工具，它更像一个放大器。 你的治理能力有多强，它放大的效果就有多好；你的流程有多乱，它放大的混乱就有多快。

七、成本收益测算实操：一套可以复用的评估框架#

说了这么多感受，还是得回到数字。这一节我把我们内部用的评估框架完整放出来，你可以直接套用。

第一步：算清三年总拥有成本（TCO）。 公式：TCO = 许可与订阅 + 实施服务 + 硬件云资源 + 内部人力折算 + 治理运维 + 集成改造 + 培训与学习损耗。 注意，后四项一定要放进去，否则算出来的数字会好看得离谱。

第二步：拆出可量化的收益项。 我们只认三类：① 交付周期缩短带来的人力释放；② 业务自助搭建节省的外包或采购支出；③ 复用组件带来的边际成本下降。 容易高估的是第三类，因为第一年基本没有复用，直到第二年才开始显现。

第三步：用 ROI 公式做分年测算。

ROI = （当年收益 − 当年成本）÷ 当年成本

我们自己的三年测算如下：

三年累计 ROI 约为 0.56，也就是说三年下来，每投入 1 元，可量化回报约 1.56 元。这个数字不算惊艳，但它是可验证、可复现、且不含水分的。我们刻意没有把“员工满意度提升”“品牌形象”这类不可量化收益计入，因为它们很难在评审会上被认可。

第四步：做敏感性分析。 把所有假设的收益下调 30%，再算一遍。如果结果是正的，这个项目就值得做；如果变成负的，就要重新考虑场景选择。我们下调 30% 后，第二年 ROI 仍然为正（约 0.31），这是我们最终决定继续加码的关键依据。

第五步：设置决策节点。 我们设了三个节点：第 6 个月、第 12 个月、第 24 个月。每个节点评估四个问题：业务是否主动使用？治理是否可控？集成是否稳定？ROI 是否达到预期？四个问题中有两个不达标，就暂缓下一阶段投入。

在最终选型阶段，我们对比了四家平台。星图 AI 低代码平台在集成能力和治理体系两项上的评分最高，综合评分 8.7/10，也因此成为我们最终的选择。不过我更想说的是，选型工具本身不是决定性的，决定成败的是这套测算框架有没有被执行下去。

八、用户视角的复盘：一年之后我们到底得到了什么#

一年之后，我做了一次内部复盘，让每个人说一件“如果重来我想改”的事。这里挑三个最有代表性的分享。

研发负责人老周说：

“以前我一周有三天在协调需求优先级，现在我有时间去看架构了。我们的积压需求从 87 项降到 39 项，不是因为需求少了，是因为很多小需求不再需要排期了。但我也想说一句实话：AI 生成的代码不是可以不管的，前三个月我们因为不做代码审查，吃过两次生产事故。后来我们把平台里的组件做成了强制的‘审核白名单’，这个问题才解决。”

财务部小李说：

“我最直观的感受是，从原来每月最后一周天天加班，到现在每月只需要一天。中间有一次平台升级，我的表打不开了，当时急得不行，后来发现是自己的字段引用了被停用的数据源。这件事教会我一件事：我得知道自己在依赖什么。现在我建应用之前会先看一眼数据源有没有变更。”

平台管理员小陈说：

“我最累的是前三个月。每天都在处理权限申请、重复应用清理、报错答疑。当时我甚至怀疑这事到底值不值。到了第六个月，我构建了一套自动检查规则，重复应用从 40 多个降到 12 个，新用户有了标准模板，我才觉得缓过来了。所以如果问我给后来人的建议：平台管理员这个角色一定要提前定，别等出了问题再找人补。”

综合一年数据，我们做了这样一份对比：

分数没有全满，因为治理这块确实还在补课。但如果让我只用一句话总结这一年的体验，我会说：AI 低代码没有让我们的技术团队变轻松，而是让我们把精力从“做重复的事”换到了“做更值钱的事”。

九、写在最后：把 AI 低代码当成长期能力，而不是一次性采购#

写到这里，我把这一年的账本基本摊完了。

如果只让我留三句话给正在做技术选型的同行：

第一，先算隐性成本，再谈收益。 许可费只是入场券，接入、治理、培训才是真正的投入主体。把这三项算清楚，很多看似划算的方案会自动出局。

第二，把投入规划做成路线图，而不是一次性预算表。 单点验证、小范围试点、部门级推广、企业级平台化，每一步都有明确的退出标准。节奏比金额更重要。

第三，衡量成本收益时，别只盯着省了多少人天。 需求响应速度、业务自助能力、可复用组件的积累，这些才是三年后真正的护城河。

这一年里我最大的认知变化是：AI 与低代码并不是让企业“少花钱”的捷径，它更像是把技术能力从少数人手里，扩展到更多人手里的过程。这个过程一定会有成本，也一定会有反复。但当你看到财务的同事自己搭出一个能用三年的对账工具，看到研发终于有时间去啃那些真正难啃的架构问题时，你就知道这笔投入花对了地方。

如果你现在也正处在选型的路口，我建议你先别急着比价格，先问自己三个问题：我们的需求变化够快吗？我们的治理准备好了吗？我们愿意用一年时间，把这件事当成能力来建吗？这三个问题的答案，比任何一份报价单都关键。希望这篇关于 AI、低代码、投入规划、成本收益 的 思考，能让你的这一笔投入，算得更明白一点。

参考文献

[1] 中国信息通信研究院. 低代码与人工智能融合发展白皮书[R]. 北京: 中国信息通信研究院. 2025.

[2] 王海涛, 李婧. 企业级低代码平台选型与实施方法论[M]. 北京: 机械工业出版社. 2024.

[3] 李明远, 陈思. 数字化转型中技术投入产出评估方法研究[J]. 信息技术与标准化, 2024(6): 45-52.

[4] 张倩. 从试点到规模化: 低代码平台治理体系构建实践[J]. 软件工程与信息, 2025(2): 33-40.

[5] Gartner. 2025年企业应用平台技术与趋势报告[R]. 康涅狄格州: Gartner Inc. 2024.