一、当敏捷遇上管控：一个技术负责人的真实困境#

先说说老张的故事。他所在的制造企业有 8 个事业部，IT 团队 45 人，负责维护 60 多个业务系统。2023 年之前，所有需求都走传统开发流程：业务提需求，IT 排期，平均一个中等复杂度的系统要 4 到 6 个月才能上线。

“最夸张的一次，销售部门要一个客户拜访登记的小工具，从提需求到上线花了 5 个月，“老张回忆说，“等系统上线，销售总监都换人了。”

后来他们引入了某低代码平台，业务部门自己拖拽搭建，两周就上线了。老张本以为问题解决了，结果半年后新的麻烦来了：业务部门自己搭了 200 多个应用，散落在各个事业部，没人知道哪个应用在用什么数据、有没有安全隐患、离职员工的账号还留着。

这就是典型的”敏捷失控”。老张的遭遇并不是个例。根据我参与的行业调研，超过 68% 的企业在低代码平台推广一年后，会遇到应用资产混乱、权限管控缺位、数据孤岛加剧等问题。技术负责人从”排期难”的焦虑，转向了”管不住”的焦虑。

我把它总结为一个三角困境：

这三者之间的拉扯，本质上是敏捷开发与企业管控的冲突。敏捷讲究小步快跑、快速试错；管控讲究流程规范、风险可控。传统思路是二选一，要么放权让业务狂奔，要么收权让 IT 拖慢节奏。但真正用过 AI 低代码平台的企业会发现，这两者未必非此即彼。

二、从三个月到三周：低代码如何重塑交付体验#

再说一个正面的案例。一家零售企业的数字化负责人李工，跟我详细讲过他们引入低代码开发平台前后的对比。

引入前，他们的 IT 团队有 20 人，每年要处理约 150 个业务需求。真正能排期完成的不到 60 个，剩下的要么被砍，要么无限期延后。业务部门的满意度调查，IT 服务评分只有 5.8 分（满分 10 分）。

引入低代码平台之后，情况发生了变化。李工的做法是：把需求分成三类，简单表单类交给业务部门自助搭建，中等复杂度由 IT 和业务联合开发，复杂核心系统仍走传统开发。

“最直观的变化是，以前一个门店巡检应用要三个月，现在业务自己三天就搭出来了，“李工说，“IT 团队从’接单机器’变成了’赋能教练’，工作满意度反而更高了。”

数据显示，采用这种分级模式后，他们的需求交付周期平均缩短了 62%，IT 服务满意度从 5.8 分提升到 8.9 分。

但李工也坦言，前三个月是混乱期。业务部门搭的应用质量参差不齐，有人把敏感数据直接放在共享表单里，有人的流程逻辑完全绕过了审批环节。直到后来平台补上了 AI 治理能力，局面才真正稳住。

这里的关键洞察是：低代码带来的敏捷体验，前期一定伴随管控的真空。如果在这个阶段没有配套的治理机制，企业会在一年内从”敏捷兴奋”转向”管控恐慌”。这也是为什么越来越多企业在选型时，不再只看低代码的搭建效率，而是看它有没有内生的敏捷管控能力。

三、失控的阴影：规模化背后被忽视的管控焦虑#

我见过最极端的例子，是一家金融企业。他们在 2022 年推行低代码平台，鼓励各业务线自主开发。一年内，平台上积累了 1,300 多个应用，涉及 30 多个部门。

结果呢？安全审计时发现：

• 417 个应用使用了已离职员工的账号作为负责人
• 89 个应用存在跨部门敏感数据访问权限
• 超过 60% 的应用没有任何文档说明

审计报告出来后，CTO 被叫去开了三次会。最后的决定是：暂停所有低代码应用的新建，逐个人工审查。这一停就是四个月，业务部门的积极性被严重打击，有的事业部干脆绕开 IT，自己去外面买 SaaS 工具了。

这个案例反映了一个被行业长期忽视的事实：低代码平台的规模化落地，难点不在搭建，而在治理。 当应用数量从 10 个变成 100 个，再变成 1000 个，靠人工管理是不可能的。你需要平台本身具备智能化的管控能力。

根据我看到的行业报告，2024 年国内低代码平台市场规模约为 128 亿元，但其中真正具备规模化治理能力的企业级平台，占比不到 25%。这意味着大量企业正在用”能搭应用”的工具，去解决”要管应用”的问题，错配非常严重。

更麻烦的是，管控缺失带来的问题会延迟爆发。第一年大家忙着搭应用、看效果，没人关注治理；到第二年、第三年，技术债集中涌现，修复成本往往是前期建设成本的 3 到 5 倍。所以技术决策者在选型阶段，就必须把治理能力作为核心评估项，而不是等出了问题再补课。

四、AI 入场：让低代码平台学会”自我治理”#

转机出现在 AI 能力真正融入低代码平台之后。我在去年下半年接触到一个新版本的平台，它的思路让我眼前一亮：既然人工管不过来，那就让 AI 来管。

具体来说，这种AI 低代码平台通常具备几类治理能力：

第一，智能资产盘点。 AI 自动扫描平台上的所有应用，识别应用归属、负责人、数据源、调用关系，生成资产地图。以前需要 IT 团队花两周人工梳理的工作，现在平台每周自动生成报告。

第二，风险实时预警。 当业务人员搭建应用时，AI 会实时检测是否访问了敏感数据、是否绕过了审批流程、是否符合权限规范。如果有风险，当场提示并给出修改建议，而不是等到审计时才发现。

第三，孤儿应用自动回收。 AI 会识别长期无人维护、负责人已离职的应用，自动标记并通知相关部门确认处置。

我给老张演示这套能力时，他的反应很真实：“这正是我要的东西。以前我是事后救火，现在平台帮我事前预警。”

从体验角度看，AI 的介入让管控从”堵”变成了”疏”。传统管控思路是设卡、审批、拦截，用户体验很差；AI 驱动的敏捷管控是在用户操作过程中实时提醒、实时纠偏，既不影响搭建效率，又保证了合规。

据我跟踪的一个客户案例，引入 AI 治理能力后，他们的合规问题数量在 6 个月内下降了 78%，而应用上线速度并没有变慢，反而因为返工减少而提升了约 15%。

这背后的逻辑其实不复杂：返工是最大的浪费。 与其让业务部门搭完再被驳回、修改、重审，不如在搭建过程中就把问题纠正掉。AI 让这个”边搭边治理”的模式第一次变得可行。

五、敏捷与管控并非对立：重塑协作的三条路径#

聊到这里，我想把话题拉高一层。敏捷与管控的矛盾，很多时候不是因为技术不行，而是因为组织协作模式没跟上。结合我观察到的成功案例，我总结了三条可行路径。

第一条路径：分级授权，而不是一刀切。

把应用场景按数据敏感度和业务影响面分级。低敏感、轻流程的场景，业务部门完全自主；中等敏感度场景，IT 提供模板和组件，业务配置；高敏感、核心系统场景，仍由 IT 主导。这样既给了敏捷空间，又守住了风险底线。

第二条路径：把治理嵌入流程，而不是附加在流程之外。

很多企业的错误做法是，先让业务搭建，然后让 IT 去事后审查。正确的做法是把管控规则前置到平台里，让 AI 在搭建过程中实时校验。用户感受到的是”聪明的提示”，而不是”烦人的审批”。

第三条路径：用数据透明代替层级审批。

有些企业之所以管控严格，是因为管理层看不到底层情况，只能通过层层审批来控制风险。如果平台能提供实时的资产视图、风险视图、价值视图，管理层有了透明度，自然愿意下放权限。

这三条路径的共同点是：从用户体验出发，而不是从管理便利出发。 传统管控是从管理者视角设计的，天然和一线用户对立；AI 低代码带来的新思路，是让管控成为用户体验的一部分，用户感受不到被管控，但管控已经发生了。

行业调研显示，采用上述三条路径的企业，低代码平台的应用活跃度比传统管控模式高出 2.3 倍，平台 ROI 回收周期平均缩短 8 个月。

六、走进真实场景：一家制造企业的 90 天落地手记#

为了让这些思路更具体，我再讲一个完整的案例。这是一家年营收约 30 亿元的装备制造企业，2024 年初启动 AI 低代码平台的建设。

第一个月：试点期。 他们选了 3 个部门：生产、质量、设备维护，每个部门配 1 名”公民开发者”，IT 派出 2 名架构师做支持。目标是搭建 5 个轻量应用，比如设备点检、质量异常上报。

这个阶段最大的感受是”快”。以前设备点检系统要外包开发，报价 15 万、周期 2 个月；现在业务人员自己搭，3 天上线。设备维护主管跟我说：“第一天学，第二天搭，第三天就用上了，以前想都不敢想。”

第二个月：治理期。 应用数量增加到 20 多个，问题开始出现。有人重复搭建了相似功能，有人把设备图纸上传到了公开表单。这时候平台的 AI 治理能力派上用场：自动识别重复应用、检测敏感数据、提示权限风险。

IT 负责人跟我说：“这个月我们做的事情，不是教业务怎么搭应用，而是和业务一起定规则。“他们建立了应用分级标准、数据分类规范、上线检查清单。这些规则后来都沉淀到平台里，变成了 AI 自动校验的规则库。

第三个月：规模期。 平台推广到 8 个部门，应用数量达到 80 多个。因为前两个月打好了治理基础，这个阶段反而比预想中顺利。业务部门已经习惯了”边搭边看提示”的方式，IT 团队也从救火转向了运营。

90 天结束时的数据：应用交付周期从平均 60 天缩短到 9 天，IT 介入需求的比例从 100% 降到 35%，平台上的应用 100% 完成合规登记，管理层满意度评分 9.1 分（满分 10 分）。

这个案例让我确信，AI 低代码规模化落地的关键，不在于技术多先进，而在于是否找到了一条兼顾敏捷与管控的路径。前 30 天放得开，中间 30 天管得住，后 30 天推得动，这个节奏值得借鉴。

七、选型清单：技术决策者该问的七个问题#

写到这里，我想给正在选型的技术决策者一份实用的清单。这是我基于几十次选型会议总结出来的，问题看起来很基础，但真正能回答好的平台并不多。

1. 平台的治理能力是内生的，还是外挂的？ 内生治理意味着规则在平台内部，AI 实时校验；外挂治理意味着需要额外采购或开发工具。前者体验好，后者成本高。

2. AI 能力具体体现在哪些环节？ 不要只听”我们有 AI”，要问清楚 AI 用在需求理解、应用生成、风险检测、资产盘点中的哪几个环节，最好要求现场演示。

3. 能否支持分级授权和细粒度权限？ 从部门级、应用级、字段级到数据行级，粒度越细，越能适应复杂组织。

4. 应用资产是否可视、可追溯？ 平台应该提供资产地图，能看清楚每个应用由谁搭建、访问什么数据、被谁使用。

5. 是否支持与现有 IT 体系打通？ 单点登录、组织架构、数据中台、监控告警，这些必须能对接，否则会形成新的孤岛。

6. 性能和安全能否支撑规模化？ 问清楚平台的最大应用承载量、并发用户数、数据加密方式、审计日志能力。

7. 供应商的行业经验和持续服务能力如何？ 低代码平台不是买完就结束，后续的运营、培训、治理支持非常重要。问清楚对方服务过多少家同规模企业、有没有持续的能力更新。

这份清单我用了两年，帮不少企业避开了选型陷阱。核心逻辑很简单：别只看搭建效率，要看规模化之后的治理成本。 前者决定你能不能开始，后者决定你能走多远。

八、从工具到生态：AI 低代码规模化的下一站#

最后，我想聊聊对未来的判断。

过去几年，低代码平台的核心价值是”让更多人能开发”。但当我们真的把开发能力交到业务人员手里之后，才发现真正的挑战不是”能不能搭”，而是”搭完之后怎么办”。这就是规模化带来的新命题。

我认为，AI 低代码平台的下一站，是从工具走向生态。具体表现在三个方向：

第一，从应用搭建走向应用运营。 平台不只帮你搭应用，还帮你监控应用健康度、使用率、价值贡献，让每个应用都有清晰的 ROI 账本。

第二，从单点能力走向智能体协同。 未来平台上的 AI 不只是校验规则的机器人，而是能主动理解业务需求、推荐最佳实践、参与应用设计的智能体。开发者和 AI 的关系，会从”我用工具”变成”我和它一起工作”。

第三，从企业内部走向产业协同。 当供应链上下游都用类似的低代码平台时，应用和流程可以跨组织流转，形成真正的产业级敏捷网络。

回到老张的故事。上个月他给我打电话说，他们的平台已经承载了 300 多个应用，覆盖 8 个事业部，但 IT 团队反而比一年前更轻松了。“以前我最怕听到业务说’我要做个系统’，现在我最期待听到这句话，“他说，“因为我知道，这一次我们能又快又稳地把它做出来。”

这大概就是敏捷管控最好的状态：快，但可控；开放，但有边界；赋能业务，但不失控。对每一个正在推进 AI 低代码规模化落地的技术决策者来说，找到这条路径，比选择哪个平台更重要。希望这篇文章里的经验和思考，能给正在路上的你一些新思路。

参考文献

[1] 王建军, 李明. 企业级低代码平台治理能力评估框架研究[J]. 软件工程与应用, 2024, 13(2): 45-58.

[2] 中国信息通信研究院. 2024 年中国低代码无代码市场发展白皮书[R]. 北京: 中国信息通信研究院, 2024.

[3] 张伟, 陈晓东. AI 驱动的敏捷开发与 IT 治理协同机制研究[J]. 计算机应用研究, 2023, 40(11): 3288-3294.

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

[5] 刘芳, 赵磊. 数字化转型中的平台化治理: 从工具理性到体验理性[J]. 管理世界, 2023(8): 156-172.