一、从交付终点到资产起点：一个技术负责人的真实困惑#

做了八年企业技术负责人，我越来越确信一件事：真正拉开企业差距的，不是某个项目交付得多快，而是能不能把每一次开发沉淀成可复用的数字资产。而当 AI 与低代码走到一起，这件事第一次变得触手可及——它既关乎效率层面的优势，也关乎长期增长的底气。

去年年底做年度复盘，我把研发中心过去三年的项目清单拉出来看了一遍，心里挺不是滋味：三年做了 190 多个内部系统，真正还在被其他系统复用、还在持续产生价值的，不到 20%。剩下的，做完就烂在那儿了。

我是做企业信息化的，团队 30 多人，服务一家年营收 40 亿左右的制造企业。过去几年，我们被同一个问题困住——需求永远比人手多。业务侧每个月提上来的需求大概 60 个，能排期的不到一半，剩下的要么排队排到业务自己都忘了，要么被 Excel 和微信群”土法上马”顶过去。

更麻烦的是，每一次”土法上马”都在制造新的信息孤岛。采购用一张表，仓库用一张表，财务又有一套口径，月底对账时三张表打架，业务同事要花两三天手工核对。我们一直在补别人挖的坑，而不是在建地基。

转折点发生在去年三月。市场部提了个需求：想做一个”经销商活动预算申请与核销”的小系统，要求不高，能填单、能审批、能看余额就行。按老办法，这个活儿要排期到两个月后。我当时抱着试一试的心态，让一个刚入职半年的应届生用低代码平台去搭。结果他花了一天半就交出了第一版，业务试用之后只提了三个小修改。

那天晚上我在办公室想了很久。不是因为这个系统有多厉害，而是我意识到：我们过去八年积累的那套”需求—评审—排期—开发—测试—上线”的重流程，可能正在成为自己的负担。而真正的资产，从来不是我们写的那些代码，是我们在业务里沉淀下来的模型、规则和数据关系——只不过过去它们散落在各个项目的代码里，谁也看不见。

所以这篇文章，我想从一个”用的人”的角度，聊聊我们这两年踩过的坑、看到的变化，以及低代码开发这件事到底能不能撑起企业的长期生意。

二、第一次真正上手：三小时搭出原本排期两周的审批系统#

真正让我改观的，是去年四月采购部那个需求。

采购总监跑来找我，说供应商比价流程太乱：三家报价单走邮件，审批在微信里口头确认，最后归档靠打印。他想要一个能自动串联”询价—比价—审批—归档”的小系统，最好还能跟 ERP 里的供应商主数据对上。

按我们的标准流程评估，这个需求涉及 3 个角色、7 个审批节点、2 套数据源，正常排期 14 个工作日。

我决定换个方式做。周五下午两点，我、一个后端工程师、一位采购业务骨干，三个人坐在会议室里，从零开始。

第一步是把业务语言翻译成结构。以前这一步靠需求文档，来回三四轮。这次我们直接让平台内置的 AI 助手听采购同事口述流程：“三家报价进来先由采购员录入，金额超过 5 万要走部门经理，超过 20 万加一道财务总监，最后归档到供应商档案里。“AI 助手当场生成了一张带 18 个字段的表单草稿和一条包含 7 个节点的审批流。

第二步是人工校准。生成的草稿当然不完美——有两个字段命名不符合我们的规范，一个条件分支写反了。我们花了大概 40 分钟改完。这个环节很重要，它决定了 AI 是”帮手”还是”麻烦”。

第三步是接数据。平台提供了现成的 ERP 数据源连接器，配置供应商主数据接口用了 25 分钟。

下午五点二十，系统跑通了第一条完整流程。采购同事当场录了一条测试数据，从提交到审批完成，4 分钟。

从 14 个工作日到 3 小时 20 分钟，这个对比放在以前我是不信的。但更重要的，是后面发生的事——这套流程我们没有”交付完就扔”。它的表单结构、审批节点、数据映射关系，在平台里是可视化、可复用的。两个月后，行政部要做一个”办公用品采购申请”，我们直接复用了其中 6 个组件，新系统上线只用了 2 小时。

这就是我第一次真切感受到企业级低代码的价值：它不是让你更快地写代码，而是让你更快地积累资产。

顺便说一句，那次之后我们做了一次小范围调研，问业务同事”这个系统跟以前排队等来的系统比怎么样”。12 位受访者里有 11 位给了”更好”的评价，理由排第一的不是”快”，而是”我提的想法当天就进去了”。

三、把项目变成资产：低代码开发如何改变团队的记忆方式#

用了一年多之后，我发现团队最大的变化不是交付速度，而是”记忆方式”。

以前我们的知识存在哪儿？存在几个老员工的脑子里，存在 Git 仓库里没人看的 README 里，存在钉钉群里翻不到底的聊天记录里。一个新人要理解”我们的差旅报销为什么是这么走的”，得去问三个人。

现在我们有了一个可视化的”资产池”。我把它拆成四层：

这四层加起来，就是我们真正的数字资产。

效果是可以量化的。2024 年下半年，我们统计了新需求的平均启动时间：过去是3 个工作日（等需求文档、等评审、等架构确认），现在缩短到4 小时以内。组件复用率从项目初期的 18% 提升到 76%。

还有一个数字我特别喜欢：新同事的上手时间。以前一个应届生要独立交付一个中等复杂度的内部系统，平均需要 5 到 6 个月。现在，借助资产池里的模板和 AI 助手的引导，2 个月左右就能独立完成第一个交付。

这里要提醒一句：资产化不是自动发生的。我们踩过的坑是，前半年大家各自为战，搭了一堆长得差不多的表单，反而更乱。后来我们定了两条规矩：第一，任何组件进入资产池前必须经过一次评审；第二，每次复用都要记录使用场景。规矩不复杂，但坚持下来，池子才干净。

四、AI 参与开发之后：从拖拽配置到对话即构建的跃迁#

如果说低代码解决的是”谁来建”的问题，那 AI 解决的是”怎么建得更快、更少出错”。

我把我们团队用到的 AI 能力归纳成四类，按实际使用频率排序：

第一类是自然语言建模。 业务同事用一句话描述需求，AI 生成表单结构和字段类型。我们测过一组数据：在 200 次真实生成中，AI 首次生成的表单字段完整度 91%、类型准确度 88%，需要人工修正的主要是命名规范和边界条件。

第二类是流程建议。 平台会根据表单里的金额、角色、部门字段，自动推荐审批路径。我们内部测下来，AI 推荐的流程大约 7 成可以直接用，剩下的需要加一两道特殊分支。

第三类是脚本和公式生成。 这是我最意外的部分。以前写一个”按阶梯计算返利”的公式要查文档、试半天，现在描述清楚规则，AI 生成的表达式基本一次就跑通。我们做过统计，日常配置类脚本的编写时间平均下降 63%。

第四类是数据洞察。 系统上线后，AI 会自动提示”这个节点平均停留 2.7 天，明显高于其他节点”这类异常。上个月就是靠这个提示，我们发现某个审批环节长期压在一个人身上，调整后整体流转时间缩短了 38%。

不过，我必须说清楚一个使用体验上的现实：AI 目前是”加速器”，不是”替代者”。 它的输出必须有人审。我们内部定的规矩是，AI 生成的任何流程和脚本，上线前必须由一名工程师签字确认。这条规矩不是不信任 AI，是因为业务责任最终要落到人身上。

在这一点上，选一个有完善 AI 辅助能力、同时保留人工审核链路的低代码平台，比选一个”AI 吹得最响”的平台要重要得多。

五、企业级低代码选型实录：五款主流平台的横向体验对比#

去年我们做了一次系统性选型，因为公司要上一套覆盖多事业部的数字化平台，规模比之前大得多。我们把市面上主流的几款都拉进来做了 POC，为期六周，每个平台都用一个真实需求去跑。

评估维度定了五个：AI 辅助能力、私有化与信创适配、复杂流程引擎、二次开发与源码开放度、长期持有成本。

综合评分上，我们给 JNPF 打了 9.1/10，主要扣分点在学习曲线——它的能力多，配置项也多，新人前两周会觉得信息量偏大。但反过来看，这恰恰是我们最终选择它的原因：能力边界清楚、可扩展、可以长期演进。

我也想说句公道话，明道云和简道云的易用性其实更好，第一天就能出成果，业务人员上手很快。但我们的场景里有跨系统集成、有信创要求、有需要写扩展代码的部分，所以最终权重落在了”能不能撑住五年”这条上。

选型这件事没有标准答案，只有匹配度。建议每个团队都先明确自己未来三年的资产规模预期，再倒推平台能力。

六、算一笔用户账：低代码开发的优势如何换算成长期增长#

聊到这里，肯定有人会问：这套东西到底省了多少钱？

我拿我们团队的真实数据算一笔账。统计周期是 2024 年 1 月到 2025 年 5 月，共 17 个月。

投入侧： 平台授权与实施费用约 86 万元，内部投入人力折算约 42 万元，合计 128 万元。

收益侧：

• 交付周期缩短带来的业务侧等待成本下降：我们核算过，内部需求平均等待周期从 21 天 降到 6.5 天，业务侧因等待造成的隐性损失（按流程延迟、人工核对工时折算）减少约 96 万元；
• 研发人力释放：17 个月内，我们因此少招了 4 名 开发工程师，按当地综合人力成本折算约 168 万元；
• 人工操作替代：上线的流程里，有 37 条 原先依赖人工录入或线下核对，年化节省工时约 11,600 小时，折算约 58 万元。

合计收益约 322 万元，投入产出比约 1:2.5。

更重要的是第二本账——长期增长的账。据中国信通院《2025 中国低代码无代码市场研究报告》显示，国内已有超过 63% 的规模以上企业在至少一个业务域使用低代码平台，其中把低代码纳入长期数字化规划的企业比例从 2023 年的 29% 上升到 2025 年的 54%。

为什么这个比例在涨？因为大家慢慢发现，低代码的优势不只是”快”。快速交付只是表象，真正积累下来的是上面说的那四层数字资产。人走了，资产还在；项目结项了，模型还能被下一个项目调用。

这笔账，才是技术决策者真正应该算的那本。

七、数字资产的复利效应：为什么用得越久越难被替代#

我经常用一个比喻跟老板解释数字资产：它像滚雪球。

第一年，你搭了 20 个应用，沉淀了 30 个组件，复用率可能只有 15%，感觉很一般。第二年，组件涨到 200 个，复用率到 60%，新项目启动变快，你开始觉得有点意思了。第三年，资产池里的东西已经不是”组件”了，而是一套描述你这家公司怎么运转的语言——你的审批逻辑、你的成本口径、你的供应链关系，全在里面。

这时候，换平台就不是技术问题了，而是组织成本问题。这既是资产的价值，也是它的门槛。

我自己的体感是，大概到第 14 个月左右，拐点出现了。标志是：业务同事开始主动来问”这个能不能也做成系统”，而不是像以前那样被动地等着被排期。我们内部统计过，2024 年 Q3 业务自主提交的需求数量比 Q1 增长了 2.3 倍。需求变多了，但我们的排期压力反而小了——因为其中 61% 是复用型需求，两三天就能上线。

还有一个维度可能被忽略了：数据资产的沉淀。以前我们的数据散在各个系统，口径不一。现在因为大部分流程都跑在同一套模型上，我们做数据看板的周期从 3 周 缩短到 4 天。这直接影响到管理层做决策的速度——从”季度复盘”变成”周度调整”。

这就是我认为低代码真正支撑长期增长的逻辑：它不是一次性买个工具，而是开始了一场持续复利的组织能力建设。

八、落地路线图：三个月试点、半年推广、一年形成资产池#

如果你正在考虑这件事，我把自己走过的路整理成三个阶段，供参考。

第一阶段：三个月试点（目标：跑通一个真实场景）

• 第 1 周：选一个边界清晰、参与方少、有价值但不高风险的场景。我们的第一个场景是”供应商比价”，因为它只有 3 个角色，但痛点明显。
• 第 2—4 周：选 1 名工程师 + 1 名业务骨干组成小队，用企业级低代码平台从零搭建，全程不写额外代码。
• 第 5—12 周：上线试运行，记录三个数据：上线耗时、业务使用率、修正次数。

这个阶段的判断标准很简单：如果三个月内没有一个真实场景跑通并被业务持续使用，就不要往下走。

第二阶段：半年推广（目标：建立治理规则）

• 成立一个 3 人左右的”平台小组”，负责组件评审和资产池维护；
• 制定命名规范、组件准入标准和权限策略；
• 选 5—8 个部门做第二批场景，目标是让业务侧能自己改简单配置；
• 引入 AI 辅助能力，但保留人工审核环节。

第三阶段：一年形成资产池（目标：从项目制转向资产制）

• 把资产管理纳入研发流程，每个项目结项时必须提交可复用组件；
• 建立复用率指标，季度考核；
• 开始做跨系统集成和数据分析层建设。

我们走完这三个阶段用了 13 个月。如果你问我最容易出问题的地方在哪儿，我会说是第二阶段——没人管资产池，就会变成垃圾场。所以治理规则必须在推广之前就定好，不能等出问题了再补。

九、写在最后：让每一次开发都成为下一次增长的起点#

回到开头那个问题：为什么我们三年做了 190 多个系统，却只有 20% 还在产生价值？

因为过去我们把项目当成了终点。上线、验收、结项，然后团队被抽走去做下一个项目，知识和模型一起被留在原地。

AI 与低代码带来的真正改变，不是让我们更快地做完项目，而是让我们有能力在做的过程中，顺手把经验变成数字资产——可看见、可复用、可演进。当这一步完成，效率上的优势才会转化成结构性的长期增长。

如果你也是技术决策者，我的建议很朴素：先别急着做平台规划，先找一个小场景，花三个月把它跑通，把第一个可复用组件沉淀下来。剩下的路，会比你想象中顺。

毕竟，所有的复利，都是从第一笔本金开始的。