织信开发日志 08自动化不是定时任务而是业务动作的编排上一篇写插件机制时我说过一个判断插件解决的是入口自动化解决的是动作如何被组织起来。所以在织信里自动化不是“定时任务”的别名。它更像一个图形化的小程序可以接收参数、设置变量、判断条件、循环处理、调用脚本、执行数据动作最后还可以返回结果。这个定位很关键。企业系统真正需要的自动化往往不是“每天几点跑一次”而是当业务事件发生后把后续动作稳定、可追踪地执行完。自动化首先是一个小程序任务列表只能描述“什么时候执行”。但业务动作通常需要上下文谁触发、传了什么参数、前一步查到了什么、后一步要写回哪里。比如客户创建后系统先判断是否重复再生成编号再分配销售再发送通知。这不是一个单点任务而是一段业务程序。把这段逻辑放到自动化画布里实施人员能看懂开发人员也能排查。它比把逻辑散落在按钮、监听器和脚本里更可维护。输入参数让自动化可以被复用自动化要被监听器、按钮、API、脚本或另一个自动化调用就必须有输入参数。参数让它从“某个页面上的动作”变成“平台里可复用的能力”。例如“生成客户编号”可以被客户创建监听器调用也可以被导入流程调用还可以被外部系统同步客户时调用。只要参数设计清楚同一段能力就不用复制三份。但参数也意味着边界。自动化不能完全假设调用方传入的一定正确必要时要做校验、规范化和失败处理。变量和流程控制决定它能走多远自动化通常不是一步完成。前一步查询到的数据后一步要用前一步计算出的结果后一步要写回接口返回的状态后一步要判断。变量就是这些步骤之间的接力棒。只有变量还不够。真实业务一定会有分支和循环客户等级不同分配规则不同合同金额不同审批路径不同导入数据时每一行都要处理。这张自动化画布里系统先查询采购订单明细再循环物料记录再根据价格条件判断是否继续执行。它已经不是“到点跑任务”而是一段被可视化表达出来的业务逻辑。步骤要覆盖真实业务动作自动化最终靠步骤完成动作。常见步骤至少要覆盖几类能力数据表读写、条件判断、列表循环、变量处理、HTTP 请求、发送通知、调用脚本、调用自动化、设置返回值、写日志。这些步骤拼在一起才能承载真实业务。比如线索进入系统后查询重复客户、创建记录、分配负责人、发送通知、调用脚本生成跟进建议最后返回处理结果。如果这些都写代码交付成本高如果都做成零散按钮又难维护。自动化的价值就是把它们组织成一条能运行、能复盘的链路。返回值让自动化变成业务函数很多自动化不是执行完就结束。API 调用它需要响应结果另一个自动化调用它需要根据结果走下一步脚本调用它也需要拿返回值。所以自动化应该像函数一样有输入也有输出。没有返回值它只能产生副作用有了返回值它才是可组合的业务能力。比如“计算报价”自动化输入客户、产品、数量和折扣内部查询规则、计算税费、判断优惠最后返回报价明细。它可以被表单按钮、API、脚本和其他自动化复用。HTTP 调用把自动化变成接口自动化开放 HTTP 调用后外部系统不必直接调用一堆底层 API而是可以调用一个明确的业务动作。比如外部 ERP 要同步客户状态不一定直接调“更新记录”接口。更好的方式是调用“同步客户状态”自动化自动化内部完成参数校验、客户查询、状态判断、记录更新和结果返回。对外暴露业务动作而不是暴露零散数据接口这是企业集成里很重要的一层抽象。限制也是设计的一部分自动化越开放越需要边界。循环写错可能变成死循环大量数据处理可能拖慢系统自动化层层调用也会让链路失控。所以运行次数限制、终止执行、错误日志、状态监控都不是附属功能而是平台治理能力。低代码平台不能只追求“能配”还要保证“配错了不会拖垮系统”。我的判断是自动化适合编排脚本适合复杂逻辑。大量计算、复杂循环、数据清洗这类事情应该交给脚本或代码片段而不是把画布堆成迷宫。表单解决数据怎么收集数据模型解决数据怎么组织流程解决状态怎么流转插件解决入口在哪里脚本解决复杂逻辑怎么承载。自动化解决的是这些能力之间业务动作怎么被组织起来。它可以被监听器触发可以被按钮触发可以被 API 调用可以调用脚本也可以返回结果。所以它不是定时任务。它是低代码平台里的业务动作编排层。