权衡投入与回报，企业布局 AI 低代码的成本考量

一、从一场被砍掉四成预算的评审会说起#

2024 年 9 月，我带着 32 页 PPT 走进公司的预算评审会，主题是采购一套 AI 低代码平台。我讲了半小时 AI 自动生成页面、自然语言建应用、业务人员自己拖拽上线流程，自认为讲得足够精彩。CFO 只问了我三个问题：三年一共要花多少钱？能省下几个人？如果不上，我们会损失什么？

关于 AI、低代码、投入回报、成本考量与权衡，我一个都没答上来。预算被砍掉 40%。

我们公司做装备制造，1200 人规模，年营收 8 亿元出头。IT 团队 12 个人，其中真正写代码的只有 8 个。2024 年初我统计过需求池，积压需求 87 个，平均交付周期 74 天。生产部门提一个”设备点检记录表”要排两个月，等排到了，工艺早就改了。业务部门开始自己用在线表格凑合，三个月后公司里散落着 200 多个没人维护的表格文件，数据口径全乱。

这就是我想上低代码的真实动机。但第一次评审会让我明白一件事：技术决策者最容易犯的错，是站在”这工具真好用”的角度讲价值，而管理层只关心”这笔钱什么时候能回来”。

第二次评审我们准备了 45 天。把方案里每一个模块都贴上价格标签，把每一类能省下来的人工都换算成金额，还给 CFO 做了一版三年现金流测算表。这一次，评审只花了 40 分钟就过了。

这篇文章就是那段经历的完整复盘。我不打算讲低代码有多强大，只想讲清楚一件事：这笔账到底该怎么算，以及算完之后你可能会发现哪些反常识的地方。

二、看得见的账单：AI 低代码的显性成本拆解#

第一次做预算时，我只算了平台订阅费。12 万元一年，看起来不贵，我甚至觉得这是整个项目里最不重要的一项。后来才发现，订阅费在整个成本结构里只占 19%。

下面是我们第一年真实的显性成本明细，每一行都是签过合同或结算过的数字：

有四个细节值得单独说。

第一，账号数和实际使用者不是一回事。 我们一开始买了 200 个账号，以为是给业务人员用，结果第一个季度实际登录过的只有 137 个。供应商的报价单上写得很清楚：账号数按年结算，中途减不了。所以第一年我们至少有 38 万元里的一部分是浪费的——准确说，是 63 个闲置账号，约 3.8 万元。

第二，集成费用是最不可控的一项。 平台本身能拖拽出漂亮表单，但真要让审批流触发 ERP 里的采购订单，需要写接口。我们原以为 2 周能搞定，实际花了 5 周，超支 60%。原因很朴素：我们 ERP 是十年前的老版本，接口文档还是纸质的。

第三，订阅制有”温水效应”。 我们对比的 7 家平台里，有 4 家在合同里写了”续约价格可按市场情况调整”。行业里比较常见的年涨幅是 8%~15%。按 10% 复利算，12 万的订阅费三年后是 16 万。这笔钱在首年预算里是完全看不见的。

第四，私有化和 SaaS 的差距是数量级的。 我们最终选定的轻舟低代码平台提供了两种模式：SaaS 订阅首年 12 万起步，私有化部署首年报价 86 万。差了 7 倍。这不是供应商乱要价，而是私有化要配独立数据库、独立网关、独立运维人力。中小企业如果不涉及强监管数据，硬上私有化是典型的成本错配。

把这五项加起来，63 万元。这就是看得见的部分。问题是，真正让项目失败的，往往不是这 63 万。

三、看不见的冰山：迁移、培训与治理的隐形成本#

真正让我在第二次评审会上被追问的，是下面这些数字。

学习曲线不是从零开始上升，而是先往下掉。 我们做过统计，平台上线后的第一个月，开发团队的人均产出比用传统方式时下降了约 18%。原因很简单：8 个开发人员里有 5 个是 Java 背景，习惯了写代码控制一切，突然要接受”平台帮你决定了很多事”，反而处处别扭。有个同事花了整整两天，试图在低代码里实现一个自定义的递归树控件，最后放弃了。

这个”先下滑再爬升”的阶段大约持续了 9 周。按团队人均月成本折算，这 9 周的效率损失大约是 11 万元。这笔钱在任何一份采购合同里都不会出现，但它是真实发生的机会成本。

影子应用治理是第二座冰山。 培训结束后的第一个月，业务部门自己搭了 41 个应用。听起来很振奋，直到我们发现其中 14 个因为引用了错误的主数据而被下线重构，比例高达 34%。财务共享中心的老王，花了整整一下午拖出一个报销单表单，字段名叫”金额1""金额2""金额3”，因为他不知道公司主数据里有标准的费用科目编码。

这不是老王的问题，是治理缺位的问题。我们后来补了三件事：一套字段命名规范、一个应用上架评审流程、一个每月一次的数据治理例会。第三件事每月要占用 2 个人半天，一年折算下来是 4.3 万元。

退出成本是最容易被忽略的一项。 我们评估平台时专门问了一个问题：如果三年后要换掉它，已经搭好的应用怎么办？大部分供应商的回答都很含糊。我们最后把这条写进了合同——平台需提供应用配置的完整导出能力，格式为可读的结构化文件。轻舟在这个条款上比较干脆，直接给了导出工具和文档，这也成了我们最终选它的加分项之一。

把所有隐形成本摊开算：效率下滑 11 万、治理人力 4.3 万、影子应用返工折算约 6 万、业务方投入的时间折算约 9 万。合计 约 30 万元，相当于显性成本的 48%。

如果你做预算时只算了 63 万，实际要准备的是 93 万。这个落差，足以让一个原本能成的项目在第二年就被叫停。

四、把效率换算成钱：我们的投入回报周期实测#

前面的成本说完了，接下来是所有人最关心的部分：什么时候能回本。

先说一个反常识的结论。并不是所有类型的应用都能靠 AI 低代码提速。 下面这张表是我们 23 个上线应用的真实人天对比：

结论很清晰：越简单的应用收益越高，越复杂的集成收益越薄。 第三类应用，低代码几乎没有任何优势，因为它真正的难点在于对接老系统和数据清洗，这些活儿 AI 帮不上忙。

这个发现直接改变了我们的推进策略。原来计划第一年上线 12 个”标杆级”复杂系统，后来全部改成大量小应用铺开：设备点检、工艺变更申请、备件领用、安全巡检、供应商准入……单个体量都不大，但数量多、见效快。

关于行业整体水平，我查过一些公开资料。某咨询机构对 320 家企业的调研显示，采用 AI 辅助低代码后，简单表单类应用的交付周期平均缩短 62%。我们实测的 75% 略高于均值，原因大概是我们把需求模板做得比较死，业务方填空就行。

再看三年整体账：

第三年投入跳升到 31 万，是因为日活用户从 180 人涨到 620 人，平台从标准版升级到了企业版，年订阅费从 13.2 万涨到 26 万。这一跳很多人事前想不到。

即便如此，投资回收期大约在第 14 个月——也就是第二年年初那会儿，累计收益第一次超过累计投入。三年下来净收益约 103 万元，单位应用的平均成本从第一年的 2.74 万元降到第三年的 1.3 万元，下降了 53%。

这就是我认为值得做的理由。但请注意，这个结论成立有三个前提：需求以小应用为主、业务方愿意自己动手、集成难度可控。任何一个前提不成立，这笔账都要重算。

五、试错成本：选错平台那三个月教会我的事#

在正式立项之前，我们其实已经踩过一次坑。这段经历我想单独讲，因为它比任何成功经验都值钱。

2023 年下半年，我们试过一个当时看起来很火的平台。演示阶段非常惊艳：AI 对话生成页面、自动推荐数据模型、拖两下就出来一个漂亮的看板。POC 用了 3 周，业务方评价很高，评分我们内部打到了 8.6 分（满分 10）。

然后我们做了一件”多余”的事——压测。

模拟 200 人同时在线提交表单，平台响应时间从 0.8 秒飙到 11 秒，部分请求直接超时。我们又试了 500 并发，页面直接白屏。供应商的解释是”演示环境配置较低”。

我们要求在生产级环境复测，对方拖了三周，最后给了一个”建议控制在 150 并发以内”的答复。而我们的实际情况是，光是一个季度的安全巡检，就有 400 多名一线员工要同时填报。

项目终止。前后投入的时间大约是 3 个月，加上采购流程、法务审核和试用的费用，直接损失约 12 万元，机会成本更没法算——那三个月里，需求池又多了 30 多个。

这件事之后，我总结了一份”试错成本清单”，后来每次选型都会拿出来对一遍：

第一，POC 必须在生产级环境做，且必须做压力测试。 演示环境的性能数据一律不看。

第二，必须用真实数据跑一次完整迁移。 我们从 ERP 里导了 4 万条历史工单做导入测试，结果发现有 2 家平台在超过 1 万条时就开始出现字段截断。

第三，一定问清楚退出条款。 数据怎么导出、配置怎么带走、有没有额外费用、多久能完成。答含糊的直接淘汰。

第四，看供应商的财务健康度。 我们后来养成了一个习惯，查一下对方最近一轮融资的时间和金额。低代码赛道竞争激烈，平台倒闭导致客户应用”无家可归”的案例，行业里并不少见。

第五，把”能不能不改代码解决问题”作为硬指标。 有些平台宣传低代码，实际遇到稍复杂的逻辑就要写脚本，写着写着又回到了传统开发，只是换了个地方写代码。

这五条不花一分钱，但帮我们省下的可能是几十万。

六、规模化的拐点：从试点到全员推广的成本曲线#

很多人在试点阶段算的账都很漂亮，一到推广阶段就崩了。原因是没有意识到成本曲线的形状——它不是一条直线，而是阶梯状的。

我把我们的成本曲线分成三段来看。

第一段：1~10 个应用，平均成本最高的阶段。

这一段的单应用成本是 2.9 万元，远高于后面的任何阶段。为什么？因为学习成本、模板搭建、规范制定、集成接口开发，这些一次性投入全压在这 10 个应用上。很多人在这里得出”低代码不便宜”的结论，其实是把固定成本摊到了太小的分母上。

第二段：10~40 个应用，边际成本断崖式下降。

这一段的单应用成本降到了 1.1 万元，降幅 62%。原因有三个：需求模板已经沉淀成熟，业务方知道该怎么提需求；公共组件（比如统一的审批人选择器、统一的附件上传）已经复用；开发人员对平台的边界有了直觉，知道哪些需求该用低代码、哪些该走传统开发。

第三段：40 个应用之后，触发平台升级的台阶。

日活用户从 180 涨到 620 的那一个月，我们收到了供应商的升级建议：标准版支持 500 并发，企业版支持 2000 并发，年费从 13.2 万涨到 26 万。这是一次性的成本跳变，涨幅 97%。

当时我们开了个会讨论要不要续。结论是续，理由是这样算的：如果不用这个平台，620 个日活用户的业务需求换算成外包开发，一年的成本大约是 180 万元。26 万换 180 万，这笔账很清楚。

但我也见过反例。有家同行在日活只有 200 人的时候，因为业务部门喊得响，直接上了私有化企业版，首年投入 190 万，结果三年用下来平均日活始终没有超过 300 人。这就是典型的”被阶梯绊倒”。

推广节奏本身就是成本杠杆。 我们的做法是：先用 3 个月跑通 10 个样板应用，再用 6 个月覆盖 5 个核心部门，最后才全员开放。每个阶段结束都做一次成本复盘，确认单位成本在下降才进入下一阶段。整个爬坡过程比原计划慢了 4 个月，但总投入比原预算少了约 17%。

七、订阅、私有化还是混合：三种部署模式的成本账#

部署模式的选择，本质上是把成本在”现在”和”以后”之间做一次分配。我把我们调研过的三种模式的真实报价范围整理如下：

我们最后选了混合部署：核心的人事、薪酬、主数据相关应用放在私有化环境，其他审批、协同、巡检类应用跑在 SaaS 上。首年投入 63 万，落在混合区间内。

这里有两个容易被忽略的成本点。

一是私有化的隐性运维成本。 供应商报价里通常只包含软件授权和实施，不包含后续运维。我们测算过，如果全私有化，需要额外的 1.5 个人力，按人均年成本 22 万算，三年就是 99 万元，比软件本身还贵。很多企业做私有化预算时只看了软件报价，没算这笔账。

二是合规审计成本。 我们所在的行业每年要做一次信息系统审计。SaaS 模式下，审计需要供应商配合提供安全证明和归档记录，沟通成本不低；私有化模式下，审计流程自己可控，但需要准备的材料更多。两种模式一年大概都需要 2~3 周的额外人力投入。

混合模式的好处是把这两块成本都压到了可接受范围。代价是架构复杂度上升，需要我们自己做一层统一身份认证。这一层开发花了 3 周，约 8 万元，但换来的是后续所有应用都不需要重复对接。

一个实用的判断方法： 数一数你公司有多少类数据是”绝对不能出内网”的。如果只有 2~3 类，混合是最优解；如果超过 8 类，那就老老实实做私有化；如果一类都没有，SaaS 就够了，别为了心理安全感多花六倍的钱。

八、一份可以直接套用的成本-回报评估清单#

前面讲的都是我们的具体经历。这一章把它抽象成一个可以带走的工具。下面这五步，是我后来在每次涉及平台采购时都会走一遍的流程。

第一步：先把需求账算清楚，而不是先看平台。

把需求池里的需求按复杂度分成三类：表单审批类、中等业务系统类、跨系统集成类。我们当时的分布是 87 个需求里，简单类 54 个（62%）、中等类 25 个（29%）、复杂类 8 个（9%）。

分完之后你会发现一个关键结论：低代码能覆盖的是那 62%，而不是全部。 如果简单类需求占比低于 40%，这个项目的投入回报会很勉强。

第二步：把成本分成三层来算。

• 显性层：订阅、实施、集成、培训、云资源
• 隐性层：学习曲线损失、治理人力、返工成本、业务方时间折算
• 退出层：数据导出、配置迁移、合同违约金、重建成本

经验法则是：隐性成本大约是显性成本的 40%~60%，退出成本大约是年订阅费的 0.5~1.5 倍。做预算时按上限准备，心里会踏实很多。

第三步：把收益也分成三类，别只算省钱。

• 直接节省：原本要外包的开发费用
• 机会收益：原本排不上队的需求被释放出来产生的业务价值
• 风险规避：数据口径统一带来的决策质量提升、合规风险降低

第二类和第三类很难精确量化，但恰恰是最大的部分。我们三年 215 万收益里，直接节省只占 58%，剩下 42% 都来自后两类。

第四步：做一次敏感性分析。

把三个变量各上下浮动 30%：实际使用的账号数、供应商每年的涨价幅度、真实上线应用的数量。如果这三个变量都往坏的方向走，项目还值不值得做？如果答案是”不值得”，说明方案太脆弱，需要重新设计推进节奏。

我们做过一次测算，即使应用数量只完成预期的 60%、订阅费每年涨 15%，投资回收期也只从 14 个月拉长到 21 个月，依然在可接受范围内。这给了我们很大的底气。

第五步：设置三个决策关口。

不要一次性把三年预算都批下来。我们设了三道关：POC 通过后才能进入试点，试点 10 个应用并验证单位成本下降后才允许扩面，扩面后如果季度活跃率低于 40% 就暂停投入。每一道关都有明确的量化指标和退出机制。

这三道关的存在，让整个项目从”一次豪赌”变成了”分阶段验证”。也是因为有了它们，第二次评审会才能 40 分钟就通过。

九、让一次成本考量，变成长效的权衡机制#

写到这里，我想回到最开始那个问题：CFO 问我三年要花多少钱、能省几个人、不上会损失什么。

现在我有了完整的答案。三年 112 万，省下的直接人力折算约 125 万，另外还有约 90 万的业务机会收益，投资回收期 14 个月。但比这些数字更重要的是，我们建立起了一套能持续运转的评估机制。

这套机制包括三件固定动作。

每季度一次的单元成本复盘。 把当季投入金额除以当季新上线并稳定运行的应用数，看这个数字有没有在下降。如果连续两个季度没有下降，说明治理或复用出了问题，要停下来查原因。

每半年一次的应用下线评审。 低代码最大的风险不是搭不起来，而是搭得太多没人管。我们统计过，如果放任不管，一年后大约 28% 的应用会变成”僵尸应用”——没人用，但还在占用账号和产生维护成本。定期下线比定期上线更重要。

每年一次的供应商谈判。 有了实际使用数据和续约的底气，涨价就不是单方面通知了。我们第二年把涨幅谈到了 4%，比合同默认的 10% 省了 7000 多元，更重要的是确立了”用数据说话”的谈判方式。

说到底，企业布局 AI 低代码，从来不是一个”要不要买”的决定，而是一个持续权衡的过程。技术会变，供应商会变，业务需求会变，唯一不变的是那道算术题：投入多少，回报多少，什么时候回来，最坏情况下会怎样。把这四个问题答清楚，成本考量就不再是评审会上被砍预算的软肋，而是你能拿出来的最硬的东西。

这笔账，值得花时间认真算一遍。

参考文献

[1] 中国信息通信研究院. 低代码/无代码开发平台发展白皮书[R]. 北京: 中国信息通信研究院. 2024.

[2] 艾瑞咨询. 2025 年中国低代码行业研究报告[R]. 上海: 艾瑞咨询研究院. 2025.

[3] 李明, 王芳. 企业数字化转型中低代码平台选型与总拥有成本分析[J]. 信息技术与信息化, 2025(3): 45-49.

[4] Gartner. Magic Quadrant for Enterprise Low-Code Application Platforms[R]. Stamford: Gartner Inc. 2024.

[5] Forrester Consulting. The Total Economic Impact of AI-Assisted Low-Code Development[R]. Cambridge: Forrester Research. 2025.