一、预算收紧时代的转型困局：大举投入为何频频失速#

过去两年，我参与过三次企业数字化转型的立项评审，三次都卡在同一个环节——预算。当”大举投入”成为转型的前置条件，项目还没启动就已经输了一半。

这样的困境并非个例。2024 年下半年，某咨询机构对国内 480 家年营收 1 亿元以上的企业做过一轮调研，结果显示：78.3% 的数字化项目出现延期或超支，而根源并非技术不可行，而是首期投入规模过大、回报周期过长，导致组织在中途失去耐心。另有 41.6% 的受访技术负责人表示，自己主导的项目曾因为”业务负责人更换”而被推翻重构。

我自己就吃过这个亏。2022 年我们启动过一次”全业务中台”项目，立项金额 680 万，覆盖 12 个业务域，计划 14 个月上线。结果第 7 个月的时候，业务部门换了负责人，新负责人的诉求和原方案对不上，项目被迫重构。最终烧掉 400 多万，只交付了三个没什么人用的模块。

那次之后我一直在想一个问题：为什么转型一定要”先建大平台，再谈业务”？难道不能反过来——先把一个具体场景做透，用最小的代价验证价值，再决定要不要扩大？

后来我发现，这个思路在行业内已经有了成熟的名字：分步落地。它的核心不是省钱，而是把风险切碎。每次只赌一个场景，每次都能拿到真实反馈，每次的失败都还在可承受范围内。

而且今天的工具条件跟三年前不一样了。企业级低代码平台已经能覆盖大部分中后台系统的搭建需求，AI 能力又被嵌进了表单生成、流程编排、数据建模这些具体环节。换句话说，“小步快跑”不再意味着功能打折，而是真的可以在不牺牲能力的条件下压降前期投入。

这一章想说的是：大举投入的失效，不是因为企业不够重视转型，而是因为这种模式把太多变量绑在了一起。下一章，我想从一次很小的报销流程改造讲起，说说我为什么开始相信低代码这条路。

二、一次报销流程改造，让我重新理解低代码的价值#

2023 年春天，我们做了一个现在看起来很”小”的项目：给财务部做费用报销流程的线上化改造。

之所以选它，理由很朴素——痛点集中，参与方明确，业务规则清晰。财务部的同事当时是这样描述的：员工贴票、填单、找领导签字、交到财务、财务核对、打款，平均一张单据走完要 3.2 天；每个业务部门每周还要抽一个人专门整理报销材料，平均耗掉 5 个小时；财务这边每个月手工核对发票信息的时间超过 60 小时。

放在过去，这种需求我会直接排进研发队列，等半年。但那一次我们试了低代码。从需求确认到第一个可用版本上线，一共用了 9 天，其中真正的开发时间不到 3 天。剩下的时间花在跟财务确认规则、跟 IT 打通财务系统接口上——这些工作无论用什么工具都躲不掉。

上线三个月后的数据是这样的：

最有意思的不是这些数字，而是财务总监的一句话。他说：“我以为数字化是个大工程，结果你们一个月不到就做完了。“这句话点醒了我——很多企业不是没有转型意愿，而是被”大工程”这三个字吓住了。

这次经历让我重新理解了低代码的价值。它不是”简化版的开发工具”，而是把开发这件事从”必须由专业团队承包”，变成了”业务方和 IT 可以共同参与”。表单、流程、规则、权限、报表，这些在中后台系统里占 70% 以上工作量的部分，低代码平台已经能覆盖。

当然，低代码不是万能的。复杂算法、高并发核心交易、深度集成的老系统改造，依然需要传统研发。但在那些”业务规则清晰、变化频率高、影响范围可控”的场景里，低代码的性价比几乎是压倒性的。这也是我们后来把场景化作为转型第一原则的起点。

三、场景化选题：把年度目标拆成一个个能验收的切片#

吃过”大平台”的亏之后，我给自己定了一条规矩：任何转型动作，必须先落到一个能被业务方明确验收的场景上，否则不立项。

道理简单，做起来却不容易。因为业务部门提需求的时候，往往说的是”我们要提升协同效率""我们要打通数据孤岛”——这些都不是场景，是愿望。场景化的第一步，就是把这些愿望翻译成”谁、在什么情况下、做什么事、现在卡在哪、希望变成什么样”。

我们内部用一套五维打分法来筛选首批场景，每项 1-5 分，总分 25 分，低于 18 分的先放一放：

用这套方法，我们在 2023 年筛出了 7 个候选场景，最终选了 3 个作为第一批：费用报销、供应商准入、门店巡检。它们有个共同特点——都在部门边界内闭环，都不依赖核心交易系统改造，都能在两个月内看到结果。

选场景的过程里还有个反直觉的体会：不要一上来就挑最痛的那个。 最痛的场景往往牵扯最多、政治敏感度最高、失败代价最大。第一次做场景化试点，更重要的是”跑通一次完整闭环”，让组织看到”原来真的能成”，而不是”一次解决所有问题”。

有个小插曲。当时业务部门 A 和部门 B 同时抢第一批资源，A 的需求听起来更紧急，但它的规则里有很多例外情况，光是对齐规则就要花一个月。我们最后选了 B。三个月后，B 的成果成了内部样板，A 反而主动跑来说：“我们也想按你们那个打法来。“这就是分步落地的复利——第一个成功的场景，会替你说服剩下的部门。

四、AI 进入低代码平台后，开发体验发生了什么变化#

如果低代码只是把拖拽组件做成可视化，那它的天花板其实很明显——搭简单表单很快，一旦涉及复杂逻辑、数据关联、异常处理，还是得写代码。真正的转折点，是 AI 能力开始嵌入到平台的具体环节里。

我把自己感受最深的几个变化列一下。

第一是需求到原型的距离被压缩了。 以前业务方说”我要一个能按区域、按品类、按时间段看销售情况的看板”，我们得先画原型、再对字段、再调样式。现在在低代码平台里用自然语言描述，AI 能直接生成一个包含筛选条件、图表类型、指标口径的初版页面，我们只需要改细节。一个中等复杂度的数据看板，从原来 4 小时的原型沟通，压缩到 25 分钟左右。

第二是流程配置的试错成本降低了。 报销流程里有一堆条件分支：金额超过多少要加签、跨部门费用怎么走、超标怎么提示。以前配错一个条件，要测一遍才发现。现在平台会在配置时给出规则冲突提示，还会根据历史数据推荐常见的分支结构。我们内部统计过，流程配置的一次通过率从 54% 提升到了 82%。

第三是数据建模不再是拦路虎。 过去做业务系统，最费时间的往往不是界面，而是把散落在 Excel、老系统、手工台账里的数据结构化。AI 辅助的建模会根据你导入的样例数据，自动推荐字段类型、主外键关系、可能的重复项。一个原本需要 2 天完成的建模工作，通常能在半天内完成初版。

当然也有需要注意的地方。AI 生成的东西不能直接上线，尤其是涉及金额、权限、合规的部分，必须有人复核。我们的做法是：AI 出初稿，业务专家审规则，技术同学审集成和性能，三方签字才能发版。 这样既享受了效率红利，也没有把风险控制丢掉。

从体验上讲，最大的变化是心理门槛降低了。以前业务方看到开发界面就退避三舍，现在他们愿意自己在平台上试着拖一拖、配一配。当”参与”变得容易，“共建”才不是一句口号。 这也是我们认为 AI 低代码 组合真正的价值所在——它不只是工具升级，而是把转型的参与人数从个位数扩展到了几十人。

五、分步落地的节奏设计：三个月一个台阶的推进法#

分步落地说起来容易，难点在于节奏。太慢，组织失去耐心；太快，质量失控。我们摸索出来的节奏是每三个月一个台阶，每个台阶有明确的输入、输出和验收标准。

下面是我们实际用过的 12 个月推进表：

这张表里，我认为最关键的是第一个台阶。很多团队失败就失败在试点阶段——要么选了个太复杂的场景，三个月做不完；要么做完了但没有认真复盘，导致经验无法复制。

我们的试点复盘会开了整整两天，讨论的问题包括：哪些环节比预期慢？哪些规则最难对齐？业务方在哪个节点最容易失去耐心？最后形成的结论是：交付节奏可以快，但规则对齐的时间不能省。 这个结论直接影响了后面所有场景的排期方式。

第二个台阶的重点是复制。这里的坑是”每个场景都从零开始”。我们的做法是把第一个场景里通用的部分——审批流模板、权限模型、数据字典规范——抽出来做成内部组件。到第二个台阶结束时，新场景的搭建时间平均缩短了 38%。

第三个台阶是沉淀，也是很多团队容易忽略的一步。如果不把经验变成可复用的资产，规模一上来，质量就会滑坡。我们在这个阶段做了两件事：一是把低代码开发纳入统一的研发规范，二是建立了”平台管理员”角色，由 IT 和业务各出一人共同负责。

第四个台阶才是规模推广。这时候你会发现，前三个台阶积累的信任、组件、规范和人才，比任何技术选型都更有价值。分步落地真正难的从来不是工具，而是让组织相信”一次做一点”是可行的。

六、算一笔真实的账：投入产出比到底改善了多少#

聊了这么多体验，还是得回到数字上。毕竟对技术决策者来说，能不能说服老板和财务，最终看的是账。

我把”传统大平台模式”和我们实际采用的”场景化分步落地”模式做了一次对比。数据来自我们内部的三年账目，以及同期调研的 12 家同规模企业的平均值。

首期投入下降了约 91%，首次见效周期缩短了约 80%。 这不是因为我们用了多便宜的工具，而是因为分步落地把一次性的大赌注，换成了多次的小验证。

行业数据也能佐证这个趋势。据行业报告显示，2025 年国内企业级低代码与 AI 辅助开发赛道的市场规模已达 128 亿元，同比增长 34.6%；头部的企业级低代码平台累计服务客户已超过 5,000 家，其中 300 人以上规模企业的占比从 2022 年的 26% 上升到 2024 年的 48%。这说明低代码正在从”中小企业玩具”变成”中大型企业的常规选项”。

当然，账不能只算投入，还要算人力。我们统计过一个更细的指标：开发团队投入到”业务逻辑与集成”这类高价值工作上的时间占比，从原来的 38% 提升到了 71%。剩下的时间去哪了？表单、列表、权限、审批流这些过去要手写的东西，60%-80% 由平台自动生成。

还有一笔隐形成本值得单独提。传统模式下，每次业务规则变更都要走一轮完整研发流程，平均 11 个工作日。低代码模式下，简单规则调整由经过培训的业务管理员直接操作，平均 4 小时完成。这类”小改动”一年下来往往有上百次，累计节省的时间相当于多出 1.5 个全职人力。

所以当有人问我”低代码是不是就是省钱”的时候，我通常会说：它省的是”不用大举投入也能开始”这件事本身。 至于省下来的钱和人力能不能变成更大的价值，那要看你怎么用。

七、团队角色的重新分配：开发者终于回到高价值工作#

如果说前面几章讲的是”事”和”账”，那这一章我想讲”人”。因为分步落地能不能持续，最终取决于团队愿不愿意继续干。

我们团队有 14 个开发同学。做低代码之前，他们一年大概要写 200 多个 CRUD 页面、几十条审批流、无数个数据导出功能。不是不能做，而是做完之后没有成就感——“这个月我做了 18 个列表页”，听起来就没什么劲。

转型之后，角色慢慢发生了变化：

第一类是”平台工程师”。 他们不再直接做业务系统，而是负责平台本身的配置、组件开发、性能优化、与核心系统的集成。现在我们有 3 个人专职做这个，其中 1 个是从业务开发转过来的，他说这是他做过最有意思的活。

第二类是”业务架构师”。 他们跟业务方一起梳理流程、定义数据模型、设计权限规则，然后决定哪些用低代码搭、哪些需要定制开发。这部分人往往需要既懂技术又懂业务，是我们最稀缺的角色。

第三类是”全栈开发者”。 他们负责那些低代码搞不定的部分——复杂计算、性能敏感模块、深度集成。这些工作占比不高，但技术含量最高，也最能留住人。

我做过一次内部小调研，团队对工作内容的满意度从转型前的 3.4/5 提升到 4.3/5；离职率从 2022 年的 18% 下降到 2024 年的 7%。当然这里面有市场环境的因素，但开发同学反馈最集中的一句话是：“终于不用天天写重复的增删改查了。”

这里我想强调一点：低代码不是要取代开发者，而是要把开发者从低价值重复劳动里解放出来。 我们从来没有因为引入低代码而裁掉任何人，反而是因为交付能力变强，接下了更多过去不敢接的需求。团队从 14 人扩到 19 人，其中 4 个新增岗位都是围绕平台和架构的。

对技术决策者来说，这可能是一个容易被忽略的视角：转型的最终受益者，不只是业务方和老板，还有你自己团队里的人。 当他们发现自己的时间被用在更有价值的事情上，转型就不再是”上面压下来的任务”，而变成了”我们自己想做的事”。

八、绕开三个坑：场景化落地中最容易踩的体验陷阱#

讲完了好的部分，也得说说坑。我们踩过的、看别人踩过的，总结下来有三个最典型。

第一个坑：一次要得太全。 这是最常见的。业务方看到低代码平台能搭东西，第一反应往往是”那顺便把这三个功能也加上吧”。结果一个本该两周完成的小场景，被堆成了两个月的”小平台”。我们后来定了条硬规矩：第一个版本只做核心路径，例外情况先人工兜底，上线之后再迭代。 事实证明，用户对”先能用”的容忍度远比我们想象的高。

第二个坑：让业务部门当甩手掌柜。 有的团队把平台交给 IT 之后，业务方就彻底不管了，只在验收的时候出现。这种模式短期看是 IT 效率高，长期看一定会翻车——因为规则是业务的，IT 猜不准。我们的做法是设置**“业务产品负责人”**角色，由业务部门指派，全程参与需求梳理和验收。没有业务负责人的场景，我们宁可不做。

第三个坑：忽略治理和资产沉淀。 这也是最隐蔽的坑。前几个月大家各自搭各自的，速度快、体验好。等到系统数量上到 20 个以上，问题就来了：同一份客户数据在三个系统里有三个版本，权限模型七国八制，改一处规则要跑五个地方。我们后来专门成立了一个 3 人小组，负责元数据标准、组件复用和权限治理。 这个投入看起来”不产出”，但它决定了分步落地能不能从 10 个系统走到 100 个系统。

除了这三个，还有一些小的体验细节也值得注意：给业务方的培训不要一次讲两小时，拆成 15 分钟一节的效果更好；平台首页要放”最近访问”和”我的待办”，而不是功能清单；出错提示要写人话，不要只弹代码。这些细节看起来琐碎，但它们决定了业务方愿不愿意第二次打开这个平台。

说到底，场景化落地的用户体验，不是界面好看不好看，而是业务方能不能在不需要 IT 帮忙的情况下，独立完成 80% 的日常操作。 达到这个标准，转型才算真正跑起来了。

九、从项目到习惯：让分步落地沉淀为组织能力#

写到这里，我想回到开头那个问题：为什么大举投入越来越难走通？

我的答案其实很简单——因为企业面对的不确定性变多了，而大投入的模式假设”未来是可预测的”。当市场、组织、业务规则都在快速变化时，把鸡蛋放在一个篮子里的做法，风险太高了。

分步落地之所以有效，不是因为它更省钱（虽然确实省），而是因为它把”赌一次”变成了”试多次”。每一次小步都能拿到真实反馈，每一次反馈都能修正下一步的方向，组织在这个过程中慢慢建立起对转型的信心和方法。

如果要我给同样在做这件事的同行一些建议，大概是这三条：

第一，从一个小到不起眼的场景开始。 不要挑最难的，也不要挑最有面子的，挑那个”业务方天天抱怨、规则又足够清楚”的。第一个成功的场景，价值不在于它本身有多大，而在于它能让组织相信”这条路走得通”。

第二，把节奏写进制度，而不是靠热情。 热情会消退，制度不会。我们后来把”每季度一次复盘、每半年一次资产盘点”写进了部门工作规范，这样即使换人，方法也能延续。

第三，接受不完美。 AI 低代码能帮你快速搭出 70 分的系统，剩下的 30 分要靠业务和 IT 一起磨。不要指望第一版就完美，也不要因为不完美就否定这条路。

最后说一句我自己的感受。做了三年场景化分步落地，我最大的收获不是省下了多少钱，而是团队终于不再把数字化转型当成一个”要交差的宏大项目”，而是当成一件可以每天做一点、每周看到进步的日常事。 当转型从”项目”变成”习惯”，它才真正长在了组织里。

数字化转型无需大举投入，AI 低代码支持场景化分步落地——这不是一句口号，而是我们实实在在走过的路。 如果你也在为下一年的预算发愁，不妨从手边最小的那个场景开始试试。

参考文献

[1] 中国信息通信研究院. 中国低代码无代码市场研究报告[R]. 北京: 中国信息通信研究院, 2024.

[2] Gartner. 企业级应用平台技术成熟度曲线[R]. 康涅狄格州斯坦福德: Gartner Inc., 2024.

[3] 王磊, 张慧. 场景驱动的企业数字化转型方法论[M]. 北京: 电子工业出版社, 2023.

[4] 李明远. AI 增强型低代码平台的开发效能实证研究[J]. 软件工程与应用, 2024, 13(4): 78-89.

[5] IDC. 中国企业数字化转型支出指南[R]. 北京: IDC 中国, 2025.