我在一家制造企业做IT负责人，手下管着ERP、MES、CRM七八套系统。
去年开始，业务部门提需求的速度明显加快了。销售部要一个客户跟进台账，生产部要一个设备点检记录，质量部要一个异常品追踪表。都不是什么复杂需求，但每一个都要走"提需求→排期→开发→测试→上线"这套流程，一个表单页面排期两周起步。
业务等不了。他们等不了就自己想办法——用Excel共享、用微信群接龙、用问卷星收集数据。结果呢？数据散在各处，格式不统一，月底汇总的时候对不上，又回来找IT救火。
这就是我最纠结的地方：不管吧，业务自己搞出来的东西后患无穷；管吧，IT人手根本不够。
第一次接触低代码，我是拒绝的
说实话，最开始有人推荐低代码平台的时候，我的第一反应是"不靠谱"。
不是因为技术不行，是因为我见过太多"看起来很美"的东西。
前几年有个部门自己买了一套表单工具，拖拽式搭页面，确实快。但用了半年之后问题来了：数据存在别人的云上，我们想导出来对接到ERP，发现接口要额外收费；想改一个字段的校验规则，发现平台不支持，只能绕过；最要命的是，有一次平台升级，之前搭的几个表单样式全乱了，业务跑来找我们修，我们连后台都进不去。
从那以后我就定了一条规矩：任何业务系统，IT必须能拿到源代码、能部署在自己的服务器上、能审计每一次数据变更。 不满足这三条的，一概不批。
所以当有人跟我说"试试低代码"的时候，我的态度很明确——除非你能让我看到代码，否则免谈。
后来为什么改主意了
改变我的想法的是一个做技术选型的朋友。他跟我说了一句话："你把低代码想成Excel的升级版，当然觉得不靠谱。但如果一个平台既能给你源代码，又能让业务自己调配置，你为什么不用？"
我带着怀疑去看了几家。大多数确实不行——要么只给SaaS不给源码，要么源码是加密过的没法审计，要么所谓的"可视化配置"功能太弱，稍微复杂一点的逻辑就配不出来。
但有一种模式让我觉得有点意思：同一个平台，IT和业务用两种不同的方式操作。
IT这边拿到的是标准的Java代码，Spring Cloud架构，注释写得清清楚楚，可以直接进我们自己的Git仓库，走我们自己的CI/CD流程。数据库表结构、API接口文档、权限配置清单，全部可以导出审查。
业务那边用的是可视化配置界面。加一个字段、改一个审批节点、调整一个校验规则，不用写代码，拖拽点选就能完成。改完马上生效，不用等发版。
关键是这两套操作是同一份数据。 业务在界面上加了一个"设备停机原因"字段，IT这边能看到数据库自动建了对应的列，表单上自动生成了录入框，流程引擎里也自动识别了这个字段可以作为审批条件。
真正让我放心的，是一个小细节
有一次业务部门自己改了一个字段的类型——从文本改成了下拉选择。改完之后系统自动弹了一个提示： "该字段被3个表单、2条审批流程引用，变更类型可能导致已有数据不匹配，是否确认？"
然后列出来具体是哪3个表单、哪2条流程，让业务确认影响范围之后再提交。
这个细节让我意识到，这个平台的设计者是真的理解IT的痛点——不是怕业务改东西，是怕业务改了不知道会影响什么。 如果每次变更都能自动识别影响范围、留痕可追溯，那业务自己操作的风险就大幅降低了。
另外，每一次配置变更都会存一个版本快照，可以一键对比差异、回滚到任意历史状态。这对我来说很重要——出了问题我能查，能回退，不会失控。
半年用下来，我的真实感受
我们现在用这种方式跑了半年，大概建了二十多个业务应用，大部分是部门级的台账、审批、数据收集类的需求。
IT的工作量确实降了。 以前一个部门级应用从需求到上线要两周，现在业务自己配置一两天就能跑起来。IT只需要在上线前做一次安全检查和数据备份策略确认。
业务的满意度提升了。 以前提需求要等排期，现在自己就能搭，遇到问题再找IT帮忙调。从"等IT做"变成了"IT和业务一起做"。
但我也有不满意的地方。
第一，复杂业务逻辑还是配不出来。比如涉及多表关联计算、条件分支嵌套的场景，可视化配置就力不从心了，还是得写代码。所以我的策略是：80%的简单需求用配置解决，20%的复杂需求走开发。
第二，业务人员的配置能力参差不齐。有的人很快就能上手，有的人教了好几次还是搞不定。后来我们专门做了两次内部培训，把常见的配置操作录了视频教程，情况才好一些。
第三，平台本身的学习成本不低。虽然宣传说"零门槛"，但要真正用好，还是得理解一些基本概念——数据模型、流程节点、权限角色这些。不是完全的小白友好。
给其他IT负责人的建议
如果你也在纠结要不要用低代码，我的建议是：
先定好底线，再去找工具。
我的底线是三条：源代码可审计、私有化部署、变更可追溯。不满足这三条的，功能再强也不考虑。满足这三条的，再去看它的配置能力、模板丰富度、学习成本。
不要指望低代码解决所有问题。 它适合的是"高频、细碎、常变"的部门级需求，不适合核心交易系统。把低代码定位成"IT的补充"而不是"IT的替代"，心态就对了。
一定要做内部培训。 不要指望业务人员自己摸索就能用好。花两天时间做培训，把常见操作录成视频，后续能省很多沟通成本。
做IT这么多年，我越来越觉得，好的工具不是让人变得更懒，而是让人把精力花在更值得的地方。
以前IT团队80%的时间在写表单、调接口、改字段，这些工作技术含金量不高但特别耗时间。现在这些重复劳动交给配置引擎，开发团队可以集中精力做核心系统架构、性能优化、安全加固这些真正有价值的事。
业务那边也是。以前他们的需求被压在IT的排期表里，等得着急上火。现在自己动手就能解决大部分问题，跟IT的关系也从"催单和拖延"变成了"协作和分工"。
可控和敏捷，原来不一定是对立的。 关键是找到一个两者都能接受的平衡点。
