低代码能力边界与选型实践：元数据、流程引擎、性能治理

低代码这三个字这两年在我耳边响的频率已经超过“数字化转型”了。上个月跟一家准独角兽级别的低代码平台的产品和技术团队关在会议室里聊了整整一个下午从产品路线图聊到他们最头疼的客户投诉最后对方技术负责人收尾时说了一句我记到现在的话低代码不是万能的我们最怕的就是客户把我们当万能。这话我认而且我认了很多年。我自己从内部系统建设一路做过来亲手用低代码搭过巡检、工单、审批、进销存、项目台账也亲手把其中两个系统从低代码上搬下来重写。所以这篇不讲厂商宣传稿里那些“人人都是开发者”的故事就讲一件事低代码的能力边界到底划在哪儿什么活该交给它什么活交给它是自找麻烦真上手的时候哪些细节会咬人。不管你是刚被安排去选型的行政或IT还是写了十年代码、正在纠结要不要接这个平台的老兵下面这些内容应该都能直接用上。1. 先把“低代码”这个词拆开看1.1 它本质上是一台“元数据解释器”很多人对低代码的误解是从把它当成“简化版IDE”开始的。其实它的内核跟IDE关系不大。你拖一个表单控件上去平台存下来的不是一段HTML而是一条元数据记录字段ID、类型、校验规则、可见性、默认值。你在流程设计器里连一条线存下来的是节点ID、跳转条件、审批人来源。运行时引擎读这些元数据动态渲染页面、动态驱动流程。所以低代码平台真正的产品是那套元数据模型 解释引擎界面只是它的外在表现。理解这一点很多现象就顺了。为什么低代码改字段特别快因为改的是元数据不用改代码、不用重新编译、不用发版。为什么低代码做复杂交互特别别扭因为解释引擎能覆盖的交互模式是有限的你想搞一个画布上拖拽排布的东西元数据描述不出来。为什么平台升级有可能影响你的应用因为你的应用是“跑在别人引擎上的配置”引擎变了配置的解释方式可能跟着变。这个底层认知决定了后面所有的取舍。打个比方低代码像一套高度标准化的预制板房体系。盖个三层办公楼一周就能封顶水电管线全预留好了你只需要决定几个房间、几个门。但你要盖一个带穹顶的剧院这套体系就开始跟你较劲了——不是盖不出来是每一处都得定制定制成本很快超过现浇。1.2 演示环境和生产环境之间隔着一条河我见过太多选型翻车的案例根源都是拿演示当结论。厂商 demo 里那个“三天上线一套审批系统”条件是这样的数据量三位数单人操作字段二十个以内没有历史数据迁移没有外部系统对接没有权限分层没有并发。而真实场景里同样是“一套审批系统”可能面对的是五万条存量数据要导入、三个部门三套权限逻辑、要走财务系统的科目校验、月底集中提交时有几十个人同时点。我在一次选型里做过一个很简单的对照实验让对方在演示环境里把一张列表的数据量灌到八万行然后做三件事——按三个字段组合筛选、导出全量、打开一条关联了子表的记录。结果筛选转圈超过十秒导出直接超时关联记录打开要等两秒多。这三件事在演示时是零延迟的。这不是说这家平台不行而是任何平台在低数据量下都是流畅的性能差异只在大数据量下才暴露。所以我在选型阶段一定会逼着厂商做这个实验对方支支吾吾基本就能判断了。注意演示阶段一定要自己上手点不要让销售替你点。你点出来的每一个卡顿都是未来用户投诉的原型。1.3 一张我自己在用的能力边界清单聊完之后我把这些年踩过的坑整理成了一张清单左边是低代码明显占优的活右边是它明显吃力的活。这张表我现在每次评估需求都拿出来对一遍能省掉很多争论。场景特征低代码合适度判断依据表单填报 审批流转极高元数据天然适配改动成本几乎为零台账、档案类管理高结构稳定、以查为主、写少读多周期性任务派发与跟踪高定时任务 状态机配置即可部门级数据汇总与看板中高聚合量不大时够用超过百万行要谨慎跨系统数据搬运与通知中取决于平台开放API的深度和限流策略强事务库存扣减、账务记账低缺事务保证和行锁容易超卖、对不平高并发写入秒级百笔以上低引擎层解释开销摆在那儿复杂前端交互画布、拖拽编辑极低元数据描述不了自由布局重计算跑批、复杂算法低公式和脚本能力有天花板且难调试这张表看着简单但它解决的其实是组织里最常见的争论业务方说“这个用低代码很快”IT说“这个低代码做不了”双方都对只是没说清楚在说什么。把需求往表里一放讨论立刻具体。2. 选型别只看拖拉拽我用来初筛的六项硬指标2.1 数据模型决定天花板功能列表能吹数据模型吹不了。我评估一个低代码平台第一件事是打开它的数据模型设计器看四样东西字段类型够不够细、关联关系怎么表达、唯一约束能不能设、索引能不能加。字段类型里最容易被忽略的是数值和日期。有些平台的数值字段只有一个“数字”没有精度控制你存金额存成 12.3000000001对账的时候能疯。日期字段要区分“日期”和“日期时间”还要看时区怎么处理。关联关系上能表达一对一、一对多不算本事关键是多对多怎么处理——是用中间表还是允许在字段里塞一个ID列表。后者在演示时特别爽实际用起来是灾难你没法对列表里的ID做关联查询没法保证引用完整性删除一条主数据后关联字段里留下一个指向空气的ID。唯一约束和多字段联合唯一是业务系统的基本需求比如“同一设备同一天只能有一条日检记录”。这个能力缺失你就只能在流程里加判断去堵堵得住但性能差、还容易漏。索引能力更直接它决定你的列表在十万行之后还能不能筛。有些平台默认给主键和创建人建索引其余字段全靠全表扫那你把最常用的筛选字段告诉厂商也加不上索引就只能靠归档硬扛。2.2 流程引擎的深浅看这四个动作流程引擎是低代码的招牌也是最容易注水的地方。判断深浅不用看它支持多少种节点就问四个动作会签、加签、驳回、撤回。会签要看的是“部分人同意后怎么走”——是全部同意才过还是按比例还是按权重能不能设置“一票否决”。加签要看加签后原审批人还需不需要再审加签是加在前还是加在后。驳回是最见功力的驳回是回到上一个节点还是回到发起人还是允许驳回到任意已走过的节点驳回后修改数据重新提交时是走完整流程还是从驳回点继续撤回则是发起人自己收回要看收回的边界在哪——别人已经审过还能不能撤。这四个动作里任意一个有硬伤落到实际业务上就是无穷无尽的线下沟通。我见过一个平台驳回只能回发起人于是“财务驳回到部门经理改一个数字”这种日常操作变成了发起人收到通知找部门经理部门经理告诉发起人改成什么发起人改完重新提交部门经理再审一遍。一个五秒钟的事变成了半天。还有个细节值得单独看流程中的数据快照。审批过程中表单数据被改了审批人看到的是提交时的版本还是当前版本有没有修改留痕这在有审计要求的场景里是硬指标。2.3 权限模型字段级和行级是分水岭权限这块我把它分三层看功能权限能不能进这个应用、能不能点这个按钮、字段权限这条记录的某个字段能不能看、能不能改、数据权限能看哪些行。功能权限几乎所有平台都有。字段权限有一半平台做得马马虎虎。数据权限是真正的分水岭。数据权限的常见实现有三种按人本人创建、按组织本部门、本部门及下级、按自定义规则比如“我负责的客户”。第三种的表达能力直接决定你能不能用它做真实业务。举个例子“销售只能看自己跟进的客户但客户移交后原销售保留30天查看权”——这种规则要么平台支持公式化的数据权限条件要么你就得靠额外的中间表去模拟模拟出来的东西维护成本高得离谱。提示评估数据权限时直接问厂商“能不能用表单里的某个字段值作为数据过滤条件”。能说明底层是把权限当查询条件拼进去的不能说明它只是几个固定维度的开关。这两者的能力差距是数量级的。2.4 集成能力与数据归属集成能力我只关心三件事API开放度、鉴权方式、限流策略。开放度看能不能对表单记录做增删改查、能不能触发流程、能不能订阅事件webhook。鉴权看是长期token还是需要换取临时凭证有没有IP白名单。限流最容易被忽略但它决定你的集成方案能不能成立——如果平台限制每分钟60次调用你要同步一万条数据就得将近三小时那这个同步方案在设计上就不成立。数据归属是选型里最该较真、却最常被跳过的一项。数据存在哪、能不能全量导出、导出格式是不是可读的CSV/JSON 还是加密包、导出是否包含附件、平台停止服务后数据怎么办。我一般会要求对方现场演示一次全量导出然后自己打开看一眼字段名是不是原始的、关联关系是不是保留了ID。有些平台导出的关联字段直接是显示名等于把你的关系结构拍平了迁出去还得重新对一遍。3. 实操拆解从零搭一套设备巡检与工单系统3.1 需求拆解与表结构设计拿一个我做过三遍的虚构项目举例某制造类企业的设备巡检与异常工单系统。需求听着简单——设备台账、按周期巡检、发现异常开工单、跟踪闭环、出统计——但拆起来有讲究。我第一步不是打开平台是在纸上画实体关系。最终落成六张表设备表设备编号唯一、名称、位置、类型、责任人、状态、启用日期巡检点表点位编号、所属设备、检查项描述、标准值范围、排序号巡检任务表任务编号、计划日期、执行人、状态、关联设备巡检记录表关联任务、关联点位、实测值、是否异常、照片、备注工单表工单号、来源记录、异常描述、优先级、处理人、处理过程、关闭时间人员表工号、姓名、部门、角色、上级这里面有几个设计决策值得说。巡检记录为什么单独一张表而不是塞进任务表的子表单因为记录要参与统计——“本月某类点位的异常率”这种查询如果记录藏在子表单里很多平台的聚合能力就抓瞎了。独立成表虽然多了一次关联但后面所有报表都好做。巡检点和设备为什么分开一台设备可能有八个检查点检查项还会随设备型号变化。如果合在设备表里用文本描述你就永远统计不出“哪个检查项最常出问题”。为什么不用文本存枚举状态、类型、优先级这类字段一律用下拉选择或关联到字典表绝不用自由文本。我见过一个系统用文本存“设备状态”结果库里出现了“正常”“正 常”“正常使用”“OK”四种写法做统计时得写四个条件。3.2 表单与字段的几个“反直觉”细节表结构定完配表单。这块有几个我踩过坑的地方。公式字段和脚本字段的取舍。简单计算求和、日期差、字符串拼接用平台自带的公式性能好、可视化、业务方能自己改。涉及条件判断、跨表查询、正则处理的用脚本字段。但脚本字段有个坑它通常在读取时计算列表页一屏50行就是50次脚本执行量大了会明显拖慢。所以我的原则是——列表页只放公式字段脚本字段只在详情页用。举个例子判断巡检是否超时// 详情页脚本字段超时判定 const plan record.getValue(计划完成时间); const actual record.getValue(实际完成时间); if (!plan) return 未计划; if (!actual) { return new Date() new Date(plan) ? 已超时 : 进行中; } const diffH (new Date(actual) - new Date(plan)) / 3600000; return diffH 0 ? 超时${diffH.toFixed(1)}小时 : 按时;这段逻辑放列表页就完了五十行乘以每次读时间列表直接卡成幻灯片。改成在任务表上冗余一个“是否超时”的布尔字段由定时任务每天凌晨刷一遍列表页直接筛这个字段体验天差地别。照片和附件的存储。巡检拍照是刚需但附件是最吃存储和带宽的东西。要注意两点一是平台对单条记录附件数量有没有上限二是附件是否计入套餐容量。我做过一个项目一年下来照片占了总存储的八成续费的时候才发现套餐是按总存储算的。后来改成移动端拍照先压缩到长边1280、质量70%体积降了七成清晰度对巡检场景完全够用。手机号的校验和脱敏。这个细节小但很典型。校验用正则脱敏要在展示层做而不是在存储层做——存原文列表页用视图或公式字段显示138****8888。存脱敏后的值你后面想做短信通知就抓瞎了。3.3 流程配置分支、会签与超时工单流程我配了五个节点提交 → 班组长确认 → 维修处理 → 验收 → 关闭。看着线性实际暗藏三个分支。按优先级分流。优先级为“紧急”时跳过班组长确认直接派给维修组并在群里发通知普通优先级走完整流程。这个用条件分支实现条件写成优先级 紧急。有个细节条件分支的判断依据是提交时的快照还是当前值如果流程走到一半有人把优先级从紧急改成普通流程会不会跳这个行为各平台不一样必须实测然后在文档里写死“流程中禁止修改优先级”或者用字段权限锁住。维修处理节点的会签。涉及两个专业机械、电气时需要两个组都出人。这里用会签规则设成“至少一人同意即通过”并允许加签。为什么不设“全部同意”因为实际运行中总有一个组的人在休假全部同意意味着流程会卡死在那儿。这类规则的选择本质是对组织真实运转方式的判断不是技术问题。超时提醒。每个节点设48小时超时超时后自动提醒处理人及其上级。这里要注意提醒是重复提醒还是一次性重复提醒的频率是多少我一般设成“超时后每天早九点提醒一次连续三天”超过三天升级到部门负责人。这个配置在平台里通常是定时任务 条件查询不是流程引擎自带的能力得单独配。3.4 自动化与外部系统对接系统跑起来之后有三条自动化规则是必须的。第一条每天凌晨生成当日巡检任务。定时任务在工作日早六点执行查设备表里状态为“在用”且到了巡检周期的设备按巡检点表展开生成任务记录指派给责任人。这里有个幂等性的问题——如果任务生成失败重跑了一次会不会生成两份解决办法是生成前先按“设备计划日期”查一遍是否已存在存在就跳过。这个判断在配置里就是加一个查询条件但很多人会忘。第二条巡检异常自动开工单。巡检记录保存时如果“是否异常”为真触发自动化创建工单把异常描述、照片、设备信息带过去。用平台的“记录创建触发”还是“按钮触发”我选前者因为人在现场容易忘记点按钮。代价是要防止重复触发同样用唯一性判断兜住。第三条对外推送。工单关闭后通过 webhook 推给企业的办公IM群同时把关键字段写入另一个业务系统的接口。推送代码大概长这样import requests, json, time def push_ticket(ticket): url https://api.example.com/open/v1/records headers { Content-Type: application/json, Authorization: Bearer get_token() } payload { form_id: TICKET, data: { ticket_no: ticket[工单号], equipment: ticket[设备编号], level: ticket[优先级], closed_at: ticket[关闭时间] } } for i in range(3): # 重试三次指数退避 try: r requests.post(url, headersheaders, datajson.dumps(payload), timeout10) if r.status_code 200: return True if r.status_code 429: # 被限流等一会儿再来 time.sleep(2 ** i * 2) continue except requests.Timeout: time.sleep(2 ** i) return False这段里有两个东西是必须的重试 指数退避以及幂等键。平台侧的接口如果不支持幂等键那就在自己这边加一张推送日志表成功过的不再推。我见过最惨的情况是接口超时了但其实写成功了重试又写了一遍工单在两边各存在一份对账对了半个月。3.5 数据量涨上来之后这套系统上线时是四百多台设备、日均一百多条巡检记录一年下来巡检记录表大概四万行用起来毫无压力。第二年设备翻倍、巡检频次加密记录表到了二十万行问题开始出现列表页打开要三秒按点位筛选要八秒月度统计报表直接超时。处理办法按性价比排序我一共做了四步。第一步给最常用的三个筛选字段加索引——这一步在支持的平台上就是勾一下效果立竿见影八秒降到一秒多。第二步把列表页默认时间范围从“全部”改成“近30天”用户要看历史自己去改筛选条件这一步降的是心理落差而不是真性能。第三步把月度统计从实时聚合改成定时预聚合每天凌晨算好存到一张统计表里前端只读结果。第四步加归档策略超过十八个月的巡检记录移到归档表主表只留近一年半。四步做完二十万行下的体验和四万行差不多。这个过程我想说的重点是低代码的性能问题大多数不是平台不行而是用法不对。索引、默认筛选、预聚合、归档这四招在任何平台上都适用而且都不需要写代码。4. 低代码做不好的四类活以及替代方案4.1 强事务与高并发写入这是低代码最硬的天花板。库存扣减、账务记账、排队叫号、秒杀报名这类场景的共同特征是需要事务保证和并发控制。低代码平台的操作单元通常是“一条记录的增删改”多条记录之间的原子性很多平台只能靠“先写主表再写子表失败后补偿”来模拟。模拟在低并发下看不出问题一旦两三个人同时操作就会出现经典的数据不一致。我亲身经历的一次用低代码做了一个物料领用系统库存字段用“当前值减申请量”的方式更新。两个人同时领都读到库存10各减3理论剩4实际剩7。这不是平台的bug是读-改-写这个模式在无锁环境下必然的结果。平台如果提供原子更新操作比如直接下发“库存 库存 - 3”的指令而不是先读后写能缓解但跨多表的原子性依然没有。这类需求我的处理方式是把核心事务交给专业系统数据库直连的应用、或者带事务能力的后端服务低代码只做前端表单和流程编排。用户还是在低代码界面上填单子、走审批审批通过后调用后端接口执行真正的扣减。低代码在这里的角色是“交互层”不是“账本”。这个分工既不浪费低代码的交付速度也不让它承担它承担不了的责任。4.2 重交互与复杂前端只要需求里出现“拖拽”“画布”“实时协同”“自定义排版”“手势操作”这几个词我就基本不考虑低代码了。原因回到第一节这些交互的本质是自由布局和实时状态同步元数据模型描述不了。举个具体的做过一个“车间平面图点选设备”的需求——一张车间平面图上面按实际坐标标注设备位置点设备弹出详情。在低代码里你最多能用图片控件 一堆绝对定位的按钮勉强模拟但设备位置一改就得重新拖一遍按钮三十台设备还能忍三百台就是灾难。换成一段前端代码用 SVG 或者 Canvas 渲染位置数据从接口读改坐标只改数据。同样的需求低代码三天出个能看的代码方案五天出个能用的但后续维护成本差十倍。我的判断标准是交互模式在平台的标准组件库里能找到对应物就用低代码需要自己发明交互模式的就写代码。中间地带——比如需要一个平台没有的图表类型——优先找平台的插件市场或者自定义组件机制能不跳出盒子就不跳。4.3 重计算与大数据量报表报表这块要分两层看。展示层低代码做得很好各种图表、透视表、看板拖拖就行。计算层是短板。平台提供的聚合能力通常是“对某个字段求和/计数/平均按某几个维度分组”这覆盖了八成需求。剩下两成——同比环比、移动平均、分组内排名、漏斗转化、同期对比——就得靠脚本而脚本在大数据量下的执行效率跟专业的数据仓库不在一个量级。我一般的做法是分层低代码只负责展示计算全部下推到数据库或者数据仓库里做算完的结果写成一张宽表低代码读这张表。这样低代码侧的查询永远是简单的“按条件取行”性能可控。代价是链路变长了从“配一个图表”变成“建一张表 写一个定时任务 配一个图表”但换来的是数据量涨十倍也不慌。有一种情况我建议直接用电子表格工具而不是低代码一次性的、探索性的分析。比如老板突然要看“近三年各产品线毛利率的季度变化”这种需求做完就没人看了用低代码搭一套报表要半天用表格工具拉一下透视表十分钟。工具选型的第一个问题永远是“这个东西要用多久”。4.4 需要长期演进的深定制系统最后这类最容易被低估系统本身不复杂但要长期演进而且演进方向不可预测。典型特征是需求方自己都说不清三年后要什么只知道“肯定会一直加功能”。低代码在这种场景下的问题不在当下在未来。你的应用是几千条元数据配置没有版本管理的概念或者有但diff起来像看天书没有单元测试没有CI/CD没有代码审查。改错了一个公式可能要等用户报错才发现。团队里如果只有一个人懂这套配置他一走就是黑盒。我给的建议是核心业务系统、生命周期超过三年、涉及多人协作维护的优先考虑代码方案低代码用来做周边的辅助应用。反过来部门级的、生命周期两三年内的、需求相对稳定的、维护人就是业务方自己的低代码是压倒性的优解。这个判断跟技术能力无关跟系统在组织里的位置有关。5. 成本这笔账很多人算错了5.1 三年TCO的拆法低代码的成本讨论经常停留在“人均每年多少钱”这个层面太浅。我算 TCO 一般拆成五块成本项说明常见误判平台订阅费按人数/按应用/按调用量看清计价单位只算首年忽略阶梯涨价实施与搭建内部人力工时或外部实施方费用按“配置不用开发”估成零学习与培训业务方上手、管理员进阶、开发人员的脚本能力只算一次培训集成与运维接口开发、监控、故障处理、版本升级回归几乎全被忽略迁出成本数据导出、结构重建、并行期双跑默认“不会迁出”第三、四、五项是最容易漏的。尤其是迁出成本很多团队潜意识里认为上了就不会下但实际上组织调整、业务剥离、平台涨价、技术栈统一都可能触发迁移。迁移的成本跟数据模型的复杂度成正比——一张纯表单的表迁起来很轻松二十张互相关联、还有几十条自动化的应用迁一次等于重做一遍。5.2 一个算例拿一个五十人规模、三个部门使用的场景粗算三年账。平台订阅按人均每年 800 元算五十人三年是 12 万。搭建阶段内部投入一个半人三个月按人力成本折算约 9 万。培训和上手损耗算 2 万。集成两个外部接口加日常运维三年算 8 万。合计 31 万。同样三个应用用代码做粗估一个后端加一个前端两个人四个月人力成本约 30 万服务器和运维三年约 6 万合计 36 万。看起来低代码省了 5 万但这是静态对比——没算需求变更。如果三年内有 100 次中小改动代码方案每次平均 1 人天低代码方案每次平均 0.3 人天差出来 70 人天按日成本折算又是十几万。这时候差距才拉开。反过来如果三年只有 20 次改动或者需求里有一条“必须支持私有化部署且数据不出内网”这种硬约束导致平台方案受限结论可能完全翻转。所以我从来不给人一句“低代码更省钱”或者“代码更划算”的结论我只给这个算法让需求方自己代入数字。提示算 TCO 时把“业务方自助修改”的收益单独折出来。很多低代码项目的真实价值不在省了开发人力而在于业务方不用排队等IT一个字段的改动从两周变成两小时。这个收益很难量化但它在决策里的权重往往比省下的钱更高。6. 常见问题排查实录6.1 问题速查表这几年被问得最多的问题我整理成了一张表按现象查原因基本能覆盖八成日常故障。现象大概率原因排查动作流程卡在某节点不动审批人来源解析为空离职、调岗、组织未同步查该节点审批人配置看解析结果是否为空设兜底审批人公式字段值不对引用了空值或类型隐式转换拆成多步中间字段逐段验证空值用 IFNULL 兜住该看到的数据看不到数据权限条件与组织架构不匹配用该用户身份登录复现查组织架构同步时间列表越用越慢缺索引、默认查全量、脚本字段上了列表加索引、改默认时间范围、把脚本字段挪到详情页接口调用超时被限流、单次数据量过大、对方响应慢加日志记录状态码分批提交加退避重试批量导入失败必填校验、唯一约束冲突、日期格式先导100行试看错误报告定位行号格式统一为ISO两人同时编辑丢数据无并发控制开启编辑锁或乐观锁关键字段用原子更新移动端页面错位固定宽度布局、附件控件过大改用响应式布局列表页减少字段展示举一个具体的排查过程。有次用户报“昨天的巡检任务没生成”我先看定时任务的执行日志显示成功耗时 1.2 秒。那就不是任务本身的问题。再看任务生成的查询条件设备状态 在用 AND 下次巡检日期 今天。查了一下问题出在“下次巡检日期”这个字段是手工维护的有一批设备维护人休假前没更新日期停在半年前理论上应该早就生成了——但没有。继续查发现这批设备的“责任人”字段为空生成任务时因为执行人为空被跳过而跳过是静默的日志里看不出来。解决办法有三层一是给责任人字段设成必填二是在生成任务时对“执行人为空”的情况打一条警告日志并汇总推送管理员三是加一个兜底规则执行人为空时派给设备所属部门负责人。这个案例的教训是——自动化流程的静默失败最危险一定要让失败可见。6.2 上线之后更重要的治理动作系统上线只是开始真正决定它能不能活下去的是治理。我在每个项目上线时都会定几条规矩写进文档贴在应用首页。命名规范先定死。表名、字段名、流程名、自动化规则名统一前缀加语义。比如巡检相关的全部insp_开头。不定规范的后果是半年后出现“表1”“新建表单(2)”“流程副本”谁也不敢删。环境隔离。测试应用和生产应用分开改配置先在测试环境验证。很多平台支持应用复制用这个做发布。跳过这一步等于在生产上直接改数据库。元数据备份。平台一般有应用导出功能每周导一次存到自己的存储里。这个动作看着多余直到某次误删了一个字段导致关联的三十条公式全部失效你才会感谢自己。账号与权限回收。离职、调岗的人员权限必须跟着组织架构同步别手工维护。有条件的话接组织架构同步没条件就固定每月初核对一次名单。使用度回访。每季度拉一次数据哪些应用三个月没人打开哪些表单提交量骤降。没人用的应用就是负债该下线就下线。我见过一个企业低代码平台上挂着两百多个应用真正在用的不到三十个剩下的全是历史遗留维护成本全压在管理员一个人身上。公民开发的边界。让业务方自己搭应用是低代码最大的价值但必须有边界涉及钱、涉及对外、涉及个人信息的应用必须走IT审核其余的应用业务方自治但要用统一的命名空间和统一的组织架构。这条边界划不清半年后就是一个巨大的影子IT沼泽。聊到最后那位技术负责人问我一个问题你觉得我们该往哪个方向做深我说了句可能不太中听的——别急着加功能先把大数据量下的性能和失败可见性做扎实。低代码这个赛道功能列表早就卷到看不出差异了真正分流客户的是“用了两年之后还稳不稳”。这话对平台成立对我们这些用平台的人也成立。选型的时候多花两天做压测和边界验证比看一百页功能清单有用得多。