织信开发日志 09低代码平台里的脚本应该怎么设计上一篇写自动化核心是把业务动作编排起来。但自动化继续往前走很快会碰到一个问题有些逻辑不是“配置几个条件”就能表达清楚。比如复杂报价、外部接口签名、多表数据清洗、历史规则生成编号、采购明细价格校验、客户负责人分配。这些逻辑如果硬做成配置最后会变成一套比代码还难懂的配置系统。脚本不是低代码的反面。脚本是低代码面对复杂业务时必须保留的安全出口。脚本解决什么问题配置表达起来别扭但业务又必须执行的逻辑交给脚本。它不应该替代表单、流程、权限、自动化也不应该把整条业务链路吞进去。更好的方式是自动化负责“先做什么、后做什么”脚本负责“这一段到底怎么算”平台负责权限、日志、超时、版本和运行边界。比如客户创建后需要查重、计算线索评分、判断是否进入重点客户池。自动化负责串联动作复杂计算放到脚本函数里。脚本不能变成黑盒脚本最容易出问题的地方是短期太快。一个开发者把查询、判断、更新、通知、接口调用全写进一个脚本今天确实能跑。但几个月后业务人员看不到链路实施人员不好排查权限边界也容易被绕开。所以脚本在低代码平台里不能是“随便写一段代码”。它必须是一个被平台托管的运行单元。平台能力要通过对象暴露脚本不能只是裸 JavaScript。真正有价值的是脚本可以通过平台对象访问应用、流程、组织、数据源、HTTP、JDBC、文件、Excel、PDF、邮件和 AI 能力。这类对象的价值是把平台能力变成脚本可以调用的函数。但能力越多边界越重要。脚本能读哪些表、能写哪些数据、能调哪些外部接口、能不能使用系统身份都不能只靠脚本作者自觉。自动化里调用脚本函数我更喜欢把脚本函数当成自动化里的一个“计算节点”。自动化负责整体编排脚本函数负责局部复杂逻辑。举个例子采购订单提交后要校验明细价格。如果只是字段比较用条件分支就够了。但如果不同供应商、物料类别、采购类型、历史报价都参与计算继续堆配置就很难维护。这时可以让脚本函数返回结构化结果是否通过、失败原因、命中的规则、需要进入哪一级审批。自动化再根据返回值决定后续动作。脚本管理不是做一个编辑器语法高亮、运行按钮、保存按钮当然需要但这只是表面。真正难的是脚本生命周期。脚本多起来以后必须回答这些问题谁改了脚本、什么时候生效、哪些自动化正在调用它、失败时能不能回滚、能不能和 Git 仓库同步。如果这些问题没有答案脚本越强平台越难维护。没有脚本平台会僵硬。脚本失控平台会退回定制开发。好的脚本设计应该让复杂逻辑有地方表达同时不破坏平台原本的可视化、权限和可追踪能力。