一、三个月等来一个审批流：我亲历的交付周期之痛#

2023年3月6日，采购部提交了一份需求：供应商准入审批流。需求本身并不复杂——供应商在线提交资质材料，采购、质量、法务、财务四方会签，通过后自动进入合格供应商名录。

6月12日，这个流程正式上线。从提出到上线，98天。

我把这98天的账摊开来看：需求调研和澄清 3 周，方案设计与评审 2 周，开发 6 周，测试 2 周，UAT 和试运行 1 周，剩下的是各种等待和插队。中间开了 11 次跨部门会议，产出了 47 页需求说明书，写了 8600 多行代码。而这 8600 行里，后来我让架构师做了一次粗略盘点，大约 60% 是表单渲染、字段校验、审批节点流转、权限控制、消息通知这类”每个系统都要重做一遍”的东西。

真正属于”供应商准入”这个业务本身的逻辑——比如资质证书的有效期计算、分级授权规则、与 ERP 供应商主数据的对接——占比不到四成。

更难堪的是等待期。4月中旬的一个下午，采购经理在企业微信群里发了一张截图：一个供应商的准入材料在纸质流转环节卡了 9 天，原因是有位负责人出差，签字单压在抽屉里。他在群里问：“陈工，系统还要多久？”

我盯着屏幕，一时不知道怎么回。

那段时间我每周要参加 4 场排期协调会，业务部门负责人轮流来”催单”。我手里的需求池排到了 4 个月后，排期表上的每一条后面都标着”高优先级”。团队不是不努力，我们两个后端、两个前端几乎满负荷，但需求进来的速度是交付速度的 2.6 倍。

我第一次意识到，问题不在于团队效率不够高，而在于我们用定制开发的方式，去解决大量本不需要定制开发的问题。

二、漫长定制开发背后的六个时间黑洞#

冷静下来之后，我让团队做了一次复盘：把一个中等规模的企业内部应用，从需求到上线，时间到底花在哪儿了？

我们用过去两年 20 个已交付项目做了加权平均，结果如下：

看完这张表，我心里基本有数了。真正难啃的是”业务逻辑与系统集成”这 23%，它压缩不了多少——每个企业的业务规则都不一样，和历史系统的对接也躲不掉。但前面那 43%（环境搭建 + 通用功能编码）以及需求澄清、测试返工里的相当一部分，本质上都是重复劳动。

我把这些重复劳动归纳成六个”时间黑洞”：

第一，需求转译损耗。 业务方说”我要一个供应商评级”，经过需求文档、原型、评审、开发理解，到最终交付时常常变成另一个东西。每一层转译都在丢信息。

第二，脚手架成本。 新起一个项目，建库、搭框架、配日志、接单点登录、做权限模型，两到三周就没了。

第三，轮子重造。 表单、流程引擎、审批意见、附件上传、消息推送，这些功能我们写过的次数，两个手数不过来。

第四，联调与集成。 这部分是硬成本，但往往因为前面工期拖延而被压缩，最后变成上线后的隐患。

第五，UAT 返工。 因为业务方直到最后才看到真实系统，反馈集中在验收阶段爆发。

第六，上线后的运维与培训。 文档写不完，培训做不完，一个小改动又要走一遍完整发布流程。

这份复盘报告我发给了管理层，结论只有一句话：如果不改变交付方式，把团队人数翻倍也追不上需求增长。

三、第一次上手低代码：那个下午改变了我对”开发”的理解#

2023年7月，我开始认真看低代码平台。

说实话，一开始我是带着偏见的。我做了十几年开发，见过太多”拖拽生成系统”的工具，最后都沦为演示玩具。所以第一次试用，我特意挑了个硬骨头：就用 6 月那个供应商准入审批流，看它能不能扛住。

那天下午两点，我在会议室里拉了三个人：一名后端开发、一名前端开发，还有采购部的流程专员张工——他在我们公司干了八年采购，Excel 玩得比很多程序员都熟，但一行代码没写过。

两点半，我们在平台上建了第一张表单。字段拖拽、类型设置、必填校验、附件上传，张工自己在旁边看着，突然说：“这个字段名不对，我们内部叫’供方编码’，不是’供应商编号’。“他直接上手改了两下。

三点四十，流程节点配完。四方会签、条件分支（金额大于 50 万加签财务总监）、超时提醒，都是可视化配置。

四点半，我们卡住了。资质证书有效期需要按”发证日期 + 有效期月数”自动计算，并在到期前 60 天预警——这个逻辑平台的标准能力做不了。后端开发写了 12 行脚本挂上去，十分钟解决。

五点二十分，一个简化版的流程跑通了：提交、流转、会签、归档。张工用手机扫码填了一单，看着它走完全程，说了一句让我记到现在的话：

“原来我提需求的时候说不清楚的东西，现在可以直接画出来给你们看。”

当然，那个下午只跑通了一个原型，离生产可用还差得远：权限模型没配、ERP 主数据没对接、日志和审计没做、历史数据没迁移。而且我们都清楚，复杂的业务逻辑还是要写代码。

但有一件事被验证了：从”业务想法”到”可点击的东西”，过去要三周，现在只要三小时。

那个原型后来成了正式项目的基础。我们在它上面补了集成、测试和权限，11 个工作日上线第一版——同样的需求，此前用了 98 天。交付周期压缩了约 88%，其中真正被省掉的，是需求转译、框架搭建和通用功能编码。

四、把交付流程拆开看：低代码到底压缩了哪几个环节#

冷静下来之后，我让团队做了第二次复盘：低代码到底让哪些环节变快了，哪些环节其实一点没变？

这次我们用的是同一个供应商准入项目的实际工时记录：

这张表我反复看过很多次。它清楚地说明了两件事。

第一，低代码的压缩效果高度不均匀。 环境和通用功能编码这两块，压缩幅度超过 85%；而业务逻辑与集成只压缩了三分之一——因为这部分难度来自业务本身，不来自工具。

第二，需求澄清环节被压缩，是一个容易被忽视但影响巨大的收益。 过去业务方看的是文档，现在看的是能点的原型。文档里一句”按公司规定审批”可能要开两次会才能澄清，而在原型上点一下，业务方立刻会说”不对，这里应该先走质量部”。

我把这套流程固化成了四步：

1. 业务方描述场景（半小时，白板或会议）
2. IT 与业务方共同搭原型（1-2 天，业务方全程在场）
3. 补集成、权限与复杂逻辑（占大头，通常 1-3 周）
4. 试运行与迭代（1 周，小步发布）

第 3 步无法省略，这一点必须诚实。如果你的项目难点在算法、高并发交易、复杂数据模型，低代码帮不了你多少。 但企业内部大量存在的审批、报表、台账、协同类应用，恰好落在那 66% 里。

五、低代码开发的优势：它改变的不是编码速度，而是协作方式#

如果说第三章那个下午给我的是惊讶，那接下来半年的实践给我的，是一种认知上的修正。

我原本以为低代码的价值是”开发更快”。用了一年后我意识到，低代码开发真正的优势，是它改变了业务方和 IT 的协作方式。

过去的分工是直线型的：业务方提需求 → IT 理解 → IT 开发 → 业务方验收。信息在每一次交接中衰减。

现在的分工变成了环形的：业务方和 IT 坐在同一块屏幕前，一起把流程画出来，一起改字段名，一起争论该不该加签。

变化有多大？我拿三个指标做了对比（数据来自我们 2023 年 Q3 到 2024 年 Q2 的 30 个中型项目）：

还有一个更直观的场景。去年财务共享中心要做差旅报销的流程改造，涉及三个审批分支、七种费用类型的差异化规则。按老办法，这至少是一个三周的项目。这次我们让财务共享中心的一位主管和一位业务骨干，接受了两天平台培训后，自己把申请表单和审批分支配了出来。IT 只负责对接 ERP 凭证接口和做权限复核。

从提出到上线，9 个工作日。财务主管后来跟我说：“以前我提需求，改一个字段要等一周；现在我自己就能改，改完提交审核就行。”

这就是我说的协作方式的变化。当业务方能自己动手，IT 就从”接单方”变成了”平台建设方和守门人”。

当然，这不是没有代价的。后面第八章我会讲治理成本上升的问题，这里先按下不表。

六、三类真实场景实测：从47个积压需求到9个#

到 2024 年底，我们用低代码交付了 63 个应用。我把它们按场景分成三类，做了周期和人力对比：

第三类需要特别说明。外部协同类因为涉及外网访问、账号体系、数据安全和接口对接，压缩幅度明显小于前两类，20-35 天是比较现实的区间。我们做过一个供应商门户项目，集成和权限治理占了总工期的一半以上。

第四类必须划清界限。我们的 MES 核心排产模块、财务核算模块，至今没有用低代码重做。原因很简单：这些系统的核心价值在于算法精度、数据一致性和高并发下的稳定性，配置化带来的灵活性在这里反而是风险。

真正的成果体现在需求池上。2024 年 Q1，我们未排期的需求积压是 47 个，平均等待时间 4.2 个月。到 2024 年 Q4，这个数字降到了 9 个，平均等待时间 3 周。

团队人数没有增加。12 个人，交付了 63 个应用，外加 4 个核心系统的迭代维护。

采购部那位经理后来在年度总结会上说了一句话，我印象很深：“我现在提需求之前会先问问能不能自己配，配不了的提给 IT，一般两周内就有回音。“

七、我们踩过的五个坑：低代码选型的体验雷区#

我不想把这件事说得太顺。实际上，我们前后评估了 6 家国内外平台，踩了不少坑，也浪费过两个月。

第一个坑：只看 Demo，不看复杂场景。

几乎所有平台的演示都很流畅：拖个表单，配个流程，点一下就跑起来。但我们的真实业务里有”多级并行会签 + 动态加签 + 基于表单字段的节点跳转”，有的平台做不了，或者要用非常别扭的方式绕。建议：拿自己最复杂的那个流程去试，不要用销售给的样例。

第二个坑：忽视集成能力。

低代码平台再强，也要和企业现有的 ERP、主数据、单点登录打通。有的平台 API 能力弱，或者调用方式受限，最后集成工作反而比手写还麻烦。我们最后定下的硬性要求是：必须支持标准 REST API 调用、数据库直连（可控权限下）和消息队列接入。

第三个坑：低估权限与治理。

一开始我们只想着”让业务方自己配”，结果三个月内平台上冒出了 40 多个应用，命名混乱、权限交叉、没人知道谁在维护。后来我们不得不补上应用登记、发布审核、环境隔离三项规范，还专门设了 1 名平台管理员。

第四个坑：把低代码当万能。

我们一度想把一个包含复杂定额计算和大量历史数据比对的质量分析模块也用低代码做，结果做了三周发现性能撑不住，最后回退重写。能用配置解决的和必须用代码解决的，边界要一开始就划清楚。

第五个坑：不考虑退出成本。

应用配置能不能导出？数据能不能完整迁出？如果哪天不用这个平台，业务逻辑是不是要全部重写？这些问题在签合同前就要问清楚。我们最后把”应用与数据的完整导出能力”写进了合同条款。

这五个坑，前两个属于选型失误，后三个属于使用方式失误。工具本身没有错，错在我们一开始把它当成了万能钥匙。

八、交付周期压缩之后：团队、业务方和我自己发生了什么变化#

周期压缩到一定程度，带来的就不只是效率提升，而是组织里一些角色的重新定义。这是我在项目启动时完全没预料到的。

开发团队的变化。 我们把 3 名原本主要做表单和流程的工程师，转去做数据集成和复杂模块开发。一位女生从前端转到数据治理，用了一年时间把主数据质量提升了明显一截。团队里还多了一个新角色：平台管理员，负责规范、审核和培训。人均年交付应用数从 2.6 个提升到 9.4 个。

业务方的变化。 我们建立了”公民开发者”认证机制，培训两轮、考核一次。目前有 12 位业务同事拿到了认证，分布在采购、财务、质量、人力四个部门。他们能自己配置表单、调整流程、做简单报表，遇到集成和安全问题才找 IT。

我自己的变化。 最明显的是会议少了。以前每周 4 场排期协调会，现在 1 场就够——因为大部分需求根本不需要排期，业务方自己就消化了。我腾出来的时间，用来做数据架构规划和系统的长期演进。

有一组我们自己做的内部调研数据，我觉得比任何效率指标都更能说明问题：

但我要强调一个前提：这些变化的前提是治理没有失控。 如果我们没有及时补上应用登记、发布审核和权限复核，平台大概率会变成一个新的技术债池子。压缩交付周期省下来的时间，有一部分必须投回到治理上，这是一笔不能省的账。

九、给技术决策者的四周评估清单与打分表#

最后，我把这两年的经验压缩成一份可以立刻执行的四周清单。如果你正在做技术选型，可以直接拿去用。

第 1 周：选一个试点场景。 标准是：业务价值明确、流程清晰、风险低、不涉及核心交易数据。审批类和报表类最合适。不要一上来就挑最难的。

第 2 周：让业务方一起搭原型。 这一周的关键不是把系统做出来，而是验证协作模式。如果业务方坐在旁边毫无参与感，说明平台的可视化程度不够，或者你的引导方式有问题。

第 3 周：压测集成与权限。 把所有需要对接的系统列出来，逐一验证。同时确认权限模型能否满足你们最严格的合规要求。

第 4 周：算总账。 把平台授权费、实施成本、培训成本、后续运维成本和传统定制开发的 79 人天做对比。注意不要只算第一年。

评估维度我建议用下面这张打分表，权重是我根据自己踩坑经验定的：

我们的综合评分是 8.2/10。如果某项低于 6 分，我建议直接排除。

写到这里，我想回到开头那句话。低代码、交付周期、定制开发、优势、压缩——这五个词在两年里从概念变成了我们团队的日常。把交付周期压缩下来，省下的不只是时间，更是业务方对 IT 的信任，以及团队从重复劳动中解放出来做更有价值事情的空间。

低代码不是让程序员失业的工具，它是一道分界线：线的一边是大量重复的、可以用配置解决的问题，另一边是真正需要工程能力的复杂系统。想清楚这条线画在哪里，你就知道该不该用它，以及该怎么用它。

至于我们，现在的答案是：能用配置解决的，不再写代码；该写代码的地方，认真写。