事情要从去年Q2说起。
那天下午三点，业务方小跑着过来：“这个详情页的‘审核通过’按钮，能不能改成绿色？还有，驳回的时候能不能弹个确认框？很急，今天能上吗？”
我看了眼代码——按钮颜色在全局主题变量里，改了会影响所有页面；驳回弹框逻辑倒是简单，但那个详情页是半年前写的，当时为了赶进度，按钮的事件绑定写在了父组件的深层逻辑里，动一处可能要测三处。
“最快明天上午。”我回。
“改个按钮要一天？”业务方的眼神里写满了“你们前端是不是在摸鱼”。
我知道他没恶意，他只是不理解——为什么一个看起来“动动手指”的事情，背后要牵扯样式污染、回归测试、还有可能隐藏的副作用。
类似的场景，那个月发生了不止一次。换表格列顺序、加一个筛选条件、改表单校验规则……每一项单独拿出来都不难，但堆在一起就像温水煮青蛙，煮得整个小团队焦头烂额。
我们统计了一下：一个标准后台页面的平均交付时间是2.5人/天，其中60%的时间花在复制粘贴上一份代码、修修补补样式、调试那些本该通用的逻辑。
不是我们菜，是重复劳动真的太多了。
从“卷代码”到“卷配置”：我们走过的两条弯路和一条正路
第一次尝试很朴素：建一个内部组件库。
把表格、表单、弹窗、树形控件全部抽象成带插槽的高级组件，业务方只需要传入配置对象。效果立竿见影——相似页面的开发时间缩短了约30%。但很快就遇到了新问题：业务需求永远在组件库的边界之外。
比如“表格第三列要根据某个字段的值显示不同颜色的标签”，我们没预置，就得改组件代码、发版本、等CI。一来二去，业务方又开始催了：“改一个显示颜色也要半天？”
第二次我们想到了配置化页面。用JSON描述页面结构和逻辑，写一个渲染器去解析。这其实就是低代码的雏形。但我们低估了工作量——光是一个表单联动（A字段选“是”才显示B字段），就要在JSON里嵌套条件表达式，写起来比直接写代码还费劲。跑了一个月，大家纷纷回归“手写大法”。
真正走上正轨，是我们开始认真审视市面上已有的低代码方案。
我们研究了百度的amis（美团内部大量在用，JSON配置驱动，生态成熟）、阿里的lowcode-engine（灵活但学习曲线陡峭），也在一次技术分享会上听友商提过 JNPF快速开发平台。后者给我们的印象是：它不只是一个前端渲染器，而是把后端逻辑编排、工作流、数据源管理都打包在了一起。对我们这种缺少专门“中台支撑”的小团队来说，如果要从零复刻那一整套能力，成本远超承受范围。但当时我们的目标其实更聚焦：先解决前端的页面重复问题，后端的部分可以缓缓。
最终我们选择了基于amis做二次开发作为主路径，原因很简单：
-
amis的组件生态覆盖了后台90%的场景（表格、表单、弹窗、图表）；
-
它天然支持属性面板配置+事件动作绑定，跟我们想要的“让业务/运营也能微调页面”的思路不谋而合；
-
社区活跃，踩坑有地方问。
至于那些超过amis边界的复杂交互，我们留了“自定义组件”的扩展口——这部分代码还是要手写，但写一次就能在整个低代码体系里复用。
落地关键：三个让交付速度翻倍的设计
方案选定之后，真正的硬仗才开始。这里分享三个我们认为最有价值的设计，如果你也在考虑内部低代码，可以直接拿去用。
1. “属性钻取”式的页面拆解
我们把每个后台页面拆成三个粒度：页面级配置、区块级配置、组件级配置。
-
页面级：布局、权限、路由元信息。
-
区块级：搜索区、操作区、表格区、弹窗区——区块可以跨页面复用。
-
组件级：每个组件的props、事件绑定、数据源。
举个例子：一个“用户管理”页面，用JSON描述大概长这样：
{
"page": {
"title": "用户管理",
"permission": "user:view"
},
"blocks": [
{ "type": "SearchForm", "props": { "fields": ["username", "email"] } },
{ "type": "ActionBar", "props": { "buttons": ["create", "export"] } },
{
"type": "CrudTable",
"props": {
"api": "/api/users",
"columns": ["name", "email", "role"],
"operations": ["edit", "delete"]
},
"events": {
"onEdit": "openUserDialog",
"onDelete": "confirmAndCallAPI"
}
}
]
}
业务方如果要“在表格里加一列‘最后登录时间’”，不再需要我们改代码，直接改一下columns数组，保存即生效。原来排期半天的活，现在两分钟干完。
2. 动作系统——把“事件绑定”还给配置者
这是低代码能否真正提效的关键点。如果没有一个灵活的动作系统，配置出来的页面就跟静态模板没区别。
我们设计了一套简单的动作DSL：
{
"onClick": [
{ "action": "callAPI", "url": "/api/approve", "params": { "id": "${row.id}" } },
{ "action": "showToast", "message": "审核成功" },
{ "action": "refreshComponent", "target": "userTable" }
]
}
每个动作可以串联执行，支持变量取值（${row.id}表示从当前上下文取）。业务方不懂代码，但他们看到下拉框里列出的“调用接口”“显示提示”“刷新表格”，也能像搭积木一样配出绝大多数常见逻辑。
最难啃的骨头是复杂联动，比如“下拉框选完省份，城市下拉框自动请求接口并填充”。我们在动作系统里加了一种特殊动作"action": "dependencyFetch"，配置好源组件、依赖字段、目标API，剩下的事情由渲染器处理。
这些东西听起来复杂，但一旦封装好，前端同学只需要维护动作库，再也不需要替每个按钮写重复的请求-提示-刷新代码。
3. 自定义组件的“逃生舱”
无论如何，总有标准组件覆盖不了的场景。比如我们有一个业务模块需要手写一个甘特图，低代码组件库不可能内置。
我们的做法是：允许开发者在任何位置注入自定义Vue/React组件，并且该组件可以像原生组件一样享受属性面板、事件绑定、数据源注入。开发者只需要实现一个registerComponent接口，把组件的props定义和事件定义告诉平台，平台就能在可视化编辑器中识别它。
这块的二次开发工作量不低，但一次投入，全项目受益。后来那个甘特图组件被三个不同的业务线复用，只需要改改数据接口，UI完全不变。
效果是真的，但坑也是真的
先上数据：内部低代码平台上线三个月后，重复性后台页面的平均交付时间从2.5人/天下降到0.7人/天，缩短约72%。 而且运维期的“改一个按钮”需求，基本上由业务方自己在配置页面点一点就完成了，我们的介入率下降了80%以上。
但一路走来，坑也没少踩。
坑一：性能问题。 深度嵌套的JSON配置导致页面首次渲染慢。解决方案是做了静态分析+懒加载——先把页面骨架解析出来，表格数据等组件进入可视区再渲染。
坑二：排错困难。 业务方配错了事件动作，页面行为诡异，错误信息却不会像控制台那样直观。我们后来在低代码编辑器里做了一个“调试面板”，可以实时打印每个动作的执行日志，勉强够用。
坑三：标准化的代价。 有些特殊交互用低代码配起来反而比写代码更慢。我们定了一条规则：如果某个功能在低代码里要配超过20个动作节点，直接允许手写一个自定义组件插入。不为了“纯低代码”的虚名而牺牲效率。
如果你也想搞内部低代码，几点真心建议
-
别一上来就追求“全可视化”。 用JSON或DSL配置页面，配合一个简单的可视化编辑器，足够覆盖90%的后台场景。全拖拽式的编辑器开发成本极高。
-
从最痛的点切入。 我们是从“后台CRUD页面”开始的，因为这些页面最重复、业务变更最频繁。不要试图把整个官网首页也低代码化，那会吃力不讨好。
-
评估现有方案，不要重复造轮子。 百度的amis、阿里的lowcode-engine都是经过大规模生产验证的，在此基础上做二次开发比从零写一套渲染器靠谱得多。如果你的需求范围更广——不只是前端页面，还包括后端逻辑、工作流、权限模型的一体化配置，那么像JNPF快速开发平台这类全栈式低代码产品也值得认真评估。它们解决的不只是“前端改按钮慢”的问题，还能把审批流、数据源编排、甚至接口生成都纳入可视化管理。我们团队当时受限于预算和已有技术栈，没有全盘引入，但后来跟用过JNPF的同行交流，他们提到“从零搭一个带审批的后台只用了两周”的时候，说不羡慕是假的。
-
保留手写扩展能力。 没有哪个低代码平台能覆盖所有边界情况。一定要提供“自定义组件/自定义区块”的逃生舱，否则遇到特殊需求就会卡死。
-
先让内部开发者用起来，再考虑给业务/运营开放。 我们前两个月只让前端自己在配置页面，等稳定了才给少数核心业务方开权限。步子迈大了，容易扯着。
最后说点实在的
现在业务方再来催“改个按钮”，我会直接把他带到低代码编辑器面前，指着那个按钮的属性面板：“你要改颜色？这里选一下。要加确认框？点‘事件’，选‘onClick’，添加动作‘confirmDialog’。完事儿点保存，自己看预览。”
他看着实时刷新的页面，一脸不可思议：“这就好了？”
“好了。”
我没有告诉他，为了让这一切丝滑运转，我们花了三个月重构、填坑、优化。但我也不用告诉他——因为他看到的只有结果：一个需求从前端排期两天，变成了他自己动手两分钟。
这就是低代码对我们团队最大的价值：不是消灭前端，而是把前端从“体力活”里解放出来，去解决真正难的问题，比如性能优化、复杂动画、跨端复用，还有——维护那个该死的低代码渲染器本身。
哦对了，最后那句话是开玩笑的。维护渲染器其实挺有意思的，至少比改按钮颜色有意思多了。
