★ FEATURED ARTICLE 如果你还在用Superpowers那我不要和你说话——这句话最近在我们几个技术群里几乎成了暗号。说这话的人不少是当年把Superpowers吹上天的第一批用户被这句话点名的是那些还在靠Superpowers搭内部系统的老同事。Superpowers这个名字听起来很“超能力”它也确实是一款火过两三年的一体化快速开发平台我也曾是它的重度用户从项目立项到第一个内部系统上线全靠它。今天不打算单方面吐槽而是想把自己从“全平台”到“全代码”的完整经历记录下来尤其是给那些正在用、想换又不敢换的团队一点参考。如果你刚接触这个名字不要紧。Superpowers本质上是一个开源的低代码快速开发平台自带了模型设计、列表页/表单页自动生成、权限管理和简单的审批流核心思路是“用配置代替编码”。在你只需要做一堆CRUD管理界面的时候它确实快得离谱。我和团队在早期靠它把运营后台、工单系统、客户管理都搭了起来一度觉得这是团队提效的终极答案。可后来业务越拧越复杂平台的能力边界越来越近团队内部开始出现“这是不是该重写”的争论。这篇文章会把我们看到的真相、踩过的坑和最终迁移的方案都摊开讲希望能让正在纠结的人少走一些弯路。1. 一句话把技术选型问题掀开了1.1 Superpowers到底是一款什么样的工具如果只看官网演示Superpowers的卖点非常直接你画一个数据表结构填好字段名、字段类型、是否必填它就能自动生成一套可用的前后端页面包括列表、搜索、新增、编辑、删除。再往上一层它提供一个可视化的“页面编排器”你可以拖拽字段位置设置按钮权限甚至配置简单的状态流转。我当时被它吸引原因很现实团队前端力量薄弱而后台管理类的需求占了七成以上。登录、权限、菜单这些事用传统方式做一遍少说要一两周但Superpowers几乎开箱即用。它把数据模型、服务端API、前端页面三者绑定在了一起你在界面上创建一个“客户管理”模型系统就会自动出现一套对应接口和页面。早期体验确实接近“超能力”。这个模式在当时完全不丢人。一个几十人的团队业务变化比发版还快需求方经常今天说列表要加一列明天说状态要多一个。如果每次都改前后端代码哪怕只是改字段也得走完开发、联调、测试整个链路。而Superpowers只用管理员在后台改配置保存后立即可见效率差距是数量级的。这也是后来很多人对它又爱又恨的根源它把“快”建立在了“黑盒”之上而黑盒在早期需求简单时几乎没有代价。1.2 被吐槽的不是名字是被它“惯坏”的开发方式“还在用Superpowers”这句话表面上是技术鄙视链本质上说的是开发方式出了问题。Superpowers这类运行引擎型低代码工具最大的问题不是不够好用而是把应用的核心逻辑放进了平台引擎里开发者只能提交配置却无法评审、无法追踪、无法做自动化测试。打个比方你请人帮你把房子装修好直接拎包入住。住进去前三个月很舒服可等到你要在墙上加一排插座、改卫生间下水管时才发现你手里连图纸都没有所有管线都被封在墙里了。Superpowers就是这么一套精装修的房子。配置在数据库里运行逻辑在引擎内部团队里最懂业务的人每天面对的是表单和格子而不是代码仓库里的diff记录。等到系统开始承载关键业务需求复杂度上来你会发现自己根本不知道某个页面为什么慢、某个权限为什么漏、某个字段为什么被篡改。说白了一个道理工具让你走得快不代表不会让你摔跤。尤其当这个工具停止迭代之后你从选择它那天起积累的隐性技术债会一下子暴露出来。2. 从“真香”到“鸡肋”别等到黑盒吞掉一切2.1 配置越来越多行为越来越难解释我们团队真正意识到问题是从一个数据模型从几十个字段膨胀到上百个字段开始的。最早用Superpowers搭客户管理系统时只有客户名称、联系人、电话、状态、备注几个字段一切都很清爽。后来业务加上了来源渠道、归属部门、跟进状态、合同编号、下单时间、最后回访时间、专属销售、数据权限范围、审批意见……这些字段在界面上一字排开一个列表页超过四十列一个表单页分了好几个Tabs。配置本身开始不可维护了。字段之间的联动、显隐规则、校验规则、按钮可用状态全部堆在平台的可视化配置里。每次改动一个字段我都得像考古一样把相关配置翻一遍害怕影响到其他模块。Superpowers允许你在模型里写一些脚本片段用来处理自定义逻辑但这些脚本分散在各个实体模型里没有统一的函数库也没有调试工具。出了问题只能一遍遍在界面上复现效率比直接写代码低得多。2.2 平台能力见顶每次定制都要绕过引擎Superpowers比较适合标准的单表CRUD。一旦业务开始出现复杂关联、批量操作、多表事务、异步任务它就有点吃力了。我们最早做的客户管理里有一个需求销售关闭一张订单时要同时把客户状态更新为“已成交”还要给财务系统发一条通知。这在传统后端里就是一次事务内完成的事但Superpowers的标准CRUD不支持跨实体联动的原子操作。平台倒是留了一个“自定义API”的口子可以让我们用服务端脚本实现。但这个口子很窄脚本里能拿到的上下文有限调试靠打日志日志还经常不完整。实践中我们被迫在业务侧做了一些补偿操作比如前端先调A接口、再调B接口然后失败时靠人工补数据。这个体验很糟糕也是压垮我们信心的第一根稻草。2.3 没有版本、没有评审、没有安全感对开发团队来说Superpowers还有一个致命伤配置存在平台自己的数据库里不是代码文件。你没有办法对一个配置变更做Code Review也没有办法在测试环境完整验证后再上生产。平台本身的“导出/导入”功能看似能搬运配置但经常出现导出包在两套环境之间行为不一致的情况。我记得有一次测试环境已经完全验证通过的客户列表页同步到生产环境后导出的查询条件少了一个筛选组结果把“全部客户”暴露给了普通销售。排查到最后发现是两套环境里某个枚举值的数据字典不一致而配置导出根本没带上这些字典数据。那次事件之后团队在很长一段时间里对“平台配置变更”都心有余悸。没有版本控制意味着没有可追溯性没有评审意味着风险敞口始终存在。对于一个要长期维护的业务系统这不是效率问题而是生存问题。3. 替代方案怎么选把“低代码”的提效留给生成器3.1 先别急着骂花一周摸清真实依赖决定放弃Superpowers之后我们并没有立刻开始写代码而是先做了一次全面的资产盘点。把Superpowers里所有模型、页面、权限、脚本、流程全部导出来整理成一份功能清单再对着这份清单逐个模块评估业务价值和使用频率。关键是要分清楚哪些功能是Superpowers真正帮到我们的哪些功能是我们为了弥补Superpowers的限制而强行做出来的。比如很多“自定义脚本”本质上只是给列表页补了几个计算字段这种在新系统里一条SQL就能解决而有些权限规则确实复杂涉及部门和职级的数据范围过滤还原时要格外小心。这一周不做别的就是盘点依赖目的是搞清楚“换掉Superpowers”不等于“把这些业务逻辑也一起扔掉”而是找到更透明的方式重新实现它们。3.2 新架构的核心代码生成 通用组件我们最终选定的方案并不复杂后端使用一种主流的全栈框架比如Spring Boot或NestJS前端使用Vue或React的管理后台模板然后自建一套轻量级代码生成器。这里的核心思路是把Superpowers里“配置后运行时解析”的体验换成“配置后编译生成真实代码”的体验。代码生成器做的事情很简单连接数据库读取表结构自动生成对应的CRUD接口、参数校验、前端列表页和表单页的初始代码。生成出来的代码是实实在在的文件可以提交到Git仓库可以Code Review可以按团队自己的规范继续修改。前端部分则沉淀出一套标准页面模板包含查询栏、数据表格、分页器、操作列、弹窗表单这些通用能力。后端的生成器主要负责Entity、DTO、Controller、Service的骨架。这样既保留了Superpowers时代“快速搭建标准模块”的优势又把黑盒的隐患全部消解掉了。生成完后开发人员想改哪就改哪不用再绕过某个引擎生成的代码本身也遵循了自己的规范后续接手的人不会对着一个诡异的平台界面发愣。低代码的价值被压缩到了“生成”这一步而真正的业务逻辑回到代码层由团队自己掌控。3.3 代价与收益算一笔团队能接受的账很多团队不敢迁移是怕成本太高。我们也算过账当时系统里一共有二十多个业务模块页面超过一百个。如果用传统方式全部重写在人员不增加的情况下按每个模块平均两到三周算至少一年。但如果把标准模块交给生成器把复杂业务按优先级逐块替换实际迁移周期压缩到了四个多月。收益更明显新系统上线后一次接口查询的平均响应时间从原来的八百多毫秒降到了两百毫秒以内页面流转不再依赖平台运行时出问题时可以直接在日志里看到完整调用链更关键的是团队终于可以做自动化测试了。以前Superpowers的页面很难做端到端测试现在代码化之后接口层的单元测试和集成测试可以随每次提交自动跑起来。这部分隐性收益长期来看比迁移本身大得多。我用记忆里最深刻的一个数字来说明差距Superpowers时代改一个列表页的分页逻辑要先在平台界面里找半天配置再在前端脚本里改一段别人看不懂的代码新系统里直接定位到对应页面组件改动十行代码提一个MR测试通过发布。两种体验有本质上的不同。4. 迁移实操从Superpowers到代码化系统4.1 资产盘点与业务复原迁移第一步是把Superpowers的配置导出转换为可阅读的文档。平台导出的数据模型会有字段名、类型、关联、注释这些信息很宝贵。我们另建了一个数据字典文档把每一个字段对应到真实业务含义标注枚举值取值并补上很多之前配置里无法表达的说明。业务复原阶段更花时间。很多业务规则虽然靠着Superpowers的脚本片段硬运行着但这些脚本没有任何测试去保护。我们把每个脚本都翻译成新系统的代码翻译过程中会先写单元测试把原平台的预期行为固定下来再去验证新代码是否一致。也就是说迁移不是“凭感觉重写”而是“用测试锁定旧行为再逐步调节到新期望”。这个阶段很容易焦躁因为你会看到大量重复的逻辑。比如每个列表页都有一个“导出Excel”的按钮对应一套导出实现Superpowers把它藏在了公共库里迁移时只需要统一提取成一个公共导出服务就行不用逐个模块复制。建议做一次全局逻辑归类能节省很多工作量。4.2 数据模型与权限模型重建新数据库不能再是平台那种大而全的模型结构要把每个业务对象的关系理清楚。原来的Superpowers模型里外键关系很多是靠字符串关联的比如owner_id指向用户表但数据库并没有真正建立外键约束。新系统必须把外键补上数据类型也尽量规范主键统一使用自增长整型。权限模型是迁移中最敏感的部分。旧平台里有“角色-菜单-按钮-数据范围”四个维度角色控制菜单和按钮组织架构控制数据范围。新系统里我们实现了类似的能力但特意把“数据范围”从角色权限里拆了出来单独做成一个数据权限策略。原因是旧系统的权限经常会同时出现在多个配置块里导致判断混乱新系统用明确的注解和策略类来统一处理。-- 旧平台导出的客户表简化 CREATE TABLE sp_customer ( id varchar(32) PRIMARY KEY, name varchar(255), owner_id varchar(32), status varchar(20), payload jsonb ); -- 新系统重建的客户表简化 CREATE TABLE customer ( id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY, name varchar(255) NOT NULL, owner_id bigint REFERENCES sys_user(id), status smallint NOT NULL DEFAULT 0, created_by bigint, updated_at timestamptz DEFAULT now() );权限重建时有个容易漏掉的点旧系统里“仅查看本部门数据”的规则通常是在列表页查询时即时过滤。新系统如果只是在接口层做过滤容易漏掉导出、批量操作、详情查看等入口。我们最后统一抽象了一个DataScopeHandler在核心服务层强制检查数据权限而不是依赖每个接口自己写条件。4.3 模块迁移顺序与双跑策略我们定的迁移顺序是“先工具、后业务”先把数据字典、用户管理、角色管理、消息通知这些基础模块换到新系统再迁移客户管理、订单管理这类核心业务模块。基础模块被所有业务依赖先把地基打稳后面换业务模块才有底气。每个模块切到新系统后会保留旧平台数据入口同时把新系统设为唯一可写入口跑两到三周的“双跑期”。这期间业务人员照常使用前台页面但后台审计团队会定期抽查新老两套系统的数据一致性。双跑不是简单对比数量而是要对比状态流转后的结果、审批意见、操作日志和最终导出的Excel。一旦发现差异马上定位是迁移逻辑问题还是旧数据问题。为什么强调“双跑”因为低代码平台很多逻辑是隐性的比如在保存客户时平台会在后台自动给updated_at写入当前时间、给updated_by写入当前登录人。这些隐性行为你根本注意不到只有让新旧系统同跑同一份输入才能发现这样的差异。我们团队在实际双跑中就发现旧平台会把“删除客户”变成逻辑删除而新系统一开始做成了物理删除差点丢数据。4.4 数据迁移的几个坑数据迁移不是简单地把旧表INSERT到新表还要处理字段映射、类型转换、值域匹配和脏数据清理。第一个坑是枚举值不一致。旧平台用字符串存状态比如status active, 新系统为了效率和约束改用smallint就需要一份映射关系。更麻烦的是旧数据里存在平台没约束住的“非法值”例如客户状态被手动改成了一串乱码迁移脚本遇到这种数据会直接报错。处理方式是把非法值收集起来由业务负责人确认归档不能擅自映射。第二个坑是时间时区。旧平台存的是带时区的时间戳但很多数据是通过前端脚本写入的用的是服务器默认时区新系统统一使用UTC存储、展示时再转本地时区。如果没有迁移时做一次时区归一化用户看到的新系统和旧系统时间可能差出八小时对账对不上。第三个坑是文件路径。旧平台的附件上传存在服务器本地磁盘数据库里只存了一个相对路径。新系统如果迁移了附件存储策略需要先扫描全部附件并复制到新的对象存储再把数据库路径批量更新成新的URL。这种看似不起眼的环节往往才是迁移后期最耗时间的部分。5. 常见问题与避坑记录5.1 权限模型对不齐怎么办旧平台里Superpowers的权限模型一般有“角色”和“数据范围”两个概念但两者是耦合在一起的。比如一个角色可以分配“仅查看本部门数据”的数据范围同时又拥有“导出数据”的按钮权限。迁移时如果简单地把角色和菜单搬过去很容易出现“用户有导出按钮但导出数据时没有走数据范围过滤”的越权情况。我们的做法是从两个维度重新建模功能权限只控制用户能不能看到/操作某个按钮数据权限单独用一个策略类控制在Service层统一校验。写新的权限判断时不要相信前端传来的组织信息必须重新解析当前登录用户的身份然后再拼装查询条件。整个权限模块用了一周时间专门做测试用例覆盖跨部门查看、上级查看下级、仅本人数据、超级管理员忽略范围四种典型情况。5.2 流程引擎怎么办旧平台的审批流是很轻量的状态机只有“提交、审批、驳回、通过”几步而且没有流程版本概念。新系统引入一套重型流程引擎前我们仔细评估过必要性最后决定暂不引入而是用业务代码里的状态模式先实现。原因很简单审批流一旦复杂现有流程需求没有完全稳定直接上引擎容易反被引擎限制。如果非要保留一套可视化流程配置能力可以先把“流程定义”写成代码块而不是数据库里动态执行。比如用一组状态节点和迁移条件定义在枚举类里后续需要增加流程版本时再把流程元数据抽到表里。这样做的好处是流程变更能够走代码评审坏处是配置效率没有平台高但从可维护性角度看完全划算。一个实操建议迁移时不要照着旧流程一比一复刻那些看起来奇怪的跳转。旧流程可能因为平台限制才那么设计新系统里可以实现得更合理。我们就在迁移过程中和业务方重新梳理了一遍审批路径砍掉了两个其实没人在意的人工节点流程审批效率提升了不少。5.3 自定义校验脚本怎么处理旧系统的自定义脚本是排查重点。先把所有脚本找出来按功能分成几类字段级校验类比如手机号格式校验、金额必须大于零。这类直接转成后端的Validation注解或自定义校验器。跨字段联动类比如选择了某个选项后另一个字段自动赋值。这类要在前端表单里处理同时也要在后端做一次兜底。业务数据计算类比如根据订单金额计算佣金。这类要单独写成服务方法并加单元测试。和外部系统交互类比如调用内部接口同步数据。这类最危险迁移时要重点验证接口的参数和返回格式是否有变化因为旧脚本本身没有超时重试机制经常悄悄失败。我特别提醒一点不要因为脚本写得难看就在迁移时直接删掉。先跑一遍确认它承担的隐性功能否则上线后才发现某个字段不再自动更新那才是麻烦事。我见过一个线上丢数据的案例就是因为迁移时觉得某段脚本是历史遗留代码结果那是旧平台唯一在维护自定义字段快照的地方。6. 如果团队还在犹豫我的建议是6.1 新项目先上车不要等到把老系统全部想明白再行动。最稳妥的方式是所有新项目从一开始就直接用新代码体系旧系统维持现状但不再新增功能。这样做有三个好处新项目能让团队尽快熟悉新技术栈也不会受旧平台的历史包袱影响新项目跑起来之后可以反哺出一套更成熟的模板和公共组件为后期迁移老系统提供经验团队士气也会因为“终于不用再看那个平台”而明显改善。老系统里如果只有一两个模块还有业务增量那就先把这些模块的增量需求放到新体系里做通过接口和旧系统单向对接。哪怕一开始有点别扭也比在老平台上再叠两三层配置要安心。6.2 别以迁移为目的要以提效为目的如果团队把这次工作定义为“将Superpowers项目迁移到XX框架”很容易变成机械搬代码最后只是换了个壳子原有的配置化设计思维还在。我们更倾向于把它定义成“重新梳理业务并建立新的生产工具链”。在这条路上代码生成器、组件库、数据字典、CI/CD、自动化测试才是真正的产出。真正麻烦的不是那几个CRUD页面而是团队能不能从“被平台牵着走”的状态里走出来。新系统搭建期间我们不仅实现了旧功能还把代码生成器改造成了内部工具以后新模块从建表到页面全部自动生成。这个过程看起来比预期多花了一点时间但团队整体交付效率在后面半年提升了一倍多。6.3 长期主义工具会退代码不会从一个更长的时间维度看Superpowers曾经带给我们的是效率后来限制我们的是不透明。任何一个工具都有它的生命周期尤其当你发现维护工具的人已经不更新了社区里无人应答文档里的例子开始和实际版本对不上这就不是“再用一阵子”的问题而是止损问题。技术选型时很多人都会问“这个方案现在能不能用”却很少问“这个方案出问题后我们自己能不能修”。Superpowers在早期完全够用但等到团队规模大了它就成了一个挡在开发人员和业务之间的黑盒。代码化之后我们的安全感完全不同所有人都能看懂代码所有变更都有迹可循所有线上问题都可以通过日志去还原。这些能力不是一个可视化配置平台能给到你的。如果你现在还在用Superpowers听到那句“不要和你说话”时不用急着反驳也别急着焦虑。真正应该做的是花一周时间做一次依赖盘点推演一下继续用一年、两年团队会不会变得更被动。迁移确实要花时间但继续背着黑盒这一年的成本往往比你先预想的高得多。我在整个过程中最深的体会是工具好不好不由社区评价决定而由你能否随时扔掉它决定。能随时扔掉还不伤筋动骨的工具才是真正安全的选择。Superpowers教会了我们快速构建也教会了我们什么是技术债。今天我们把债还掉了剩下的反而是对业务逻辑更完整的理解这套理解比任何工具都值钱。
阅读完成 · 觉得有帮助？
