企业官网建设流程全解析

织信开发日志 09：低代码平台里的脚本应该怎么设计

上一篇写自动化，核心是把业务动作编排起来。

但自动化继续往前走，很快会碰到一个问题：有些逻辑不是“配置几个条件”就能表达清楚。

比如复杂报价、外部接口签名、多表数据清洗、历史规则生成编号、采购明细价格校验、客户负责人分配。

这些逻辑如果硬做成配置，最后会变成一套比代码还难懂的配置系统。

脚本不是低代码的反面。脚本是低代码面对复杂业务时必须保留的安全出口。

脚本解决什么问题

配置表达起来别扭，但业务又必须执行的逻辑，交给脚本。

它不应该替代表单、流程、权限、自动化，也不应该把整条业务链路吞进去。

更好的方式是：

• 自动化负责“先做什么、后做什么”；
• 脚本负责“这一段到底怎么算”；
• 平台负责权限、日志、超时、版本和运行边界。

比如客户创建后，需要查重、计算线索评分、判断是否进入重点客户池。自动化负责串联动作，复杂计算放到脚本函数里。

脚本不能变成黑盒

脚本最容易出问题的地方，是短期太快。

一个开发者把查询、判断、更新、通知、接口调用全写进一个脚本，今天确实能跑。

但几个月后，业务人员看不到链路，实施人员不好排查，权限边界也容易被绕开。

所以脚本在低代码平台里不能是“随便写一段代码”。它必须是一个被平台托管的运行单元。

平台能力要通过对象暴露

脚本不能只是裸 JavaScript。真正有价值的是：脚本可以通过平台对象访问应用、流程、组织、数据源、HTTP、JDBC、文件、Excel、PDF、邮件和 AI 能力。

这类对象的价值，是把平台能力变成脚本可以调用的函数。

但能力越多，边界越重要。脚本能读哪些表、能写哪些数据、能调哪些外部接口、能不能使用系统身份，都不能只靠脚本作者自觉。

自动化里调用脚本函数

我更喜欢把脚本函数当成自动化里的一个“计算节点”。

自动化负责整体编排，脚本函数负责局部复杂逻辑。

举个例子，采购订单提交后要校验明细价格。

如果只是字段比较，用条件分支就够了。但如果不同供应商、物料类别、采购类型、历史报价都参与计算，继续堆配置就很难维护。

这时可以让脚本函数返回结构化结果：是否通过、失败原因、命中的规则、需要进入哪一级审批。自动化再根据返回值决定后续动作。

脚本管理不是做一个编辑器

语法高亮、运行按钮、保存按钮当然需要，但这只是表面。

真正难的是脚本生命周期。

脚本多起来以后，必须回答这些问题：谁改了脚本、什么时候生效、哪些自动化正在调用它、失败时能不能回滚、能不能和 Git 仓库同步。

如果这些问题没有答案，脚本越强，平台越难维护。

没有脚本，平台会僵硬。

脚本失控，平台会退回定制开发。

好的脚本设计，应该让复杂逻辑有地方表达，同时不破坏平台原本的可视化、权限和可追踪能力。