每天自动生成待办：定时任务如何工作

每天自动生成待办定时任务如何工作上一篇我们用“库存不足自动通知”讲了自动化当数据发生变化时系统可以自动做下一步动作。但企业里还有另一类很常见的自动化它不是由某条数据变化触发而是由时间触发。比如销售团队每天早上 9 点都会问同一个问题今天该跟进哪些客户如果没有系统这件事通常靠人自己翻 Excel、查聊天记录、看昨天的备忘录。问题不在于“找不到”而在于每天都要重复找而且很容易漏掉。这一篇我们就用一个小案例看看在织信这样的 AI 低代码系统里如何用定时任务每天自动生成客户跟进待办。先说一个关键点在织信里定时任务本身更像“时间触发器”。它负责在指定时间、指定周期把任务启动起来真正的业务逻辑通常交给自动化或脚本完成。也就是说定时任务不是把所有业务规则都写在自己身上而是负责回答“什么时候执行、在哪些服务节点执行、失败后怎么处理、调用哪段业务逻辑”。场景每天早上自动生成销售待办假设我们已经有一个客户管理应用里面至少有三类数据客户表记录客户名称、负责人、当前阶段、下次跟进时间。跟进记录表记录每次沟通内容、沟通方式、跟进人和下一步计划。待办表记录销售今天应该处理的事项、负责人、截止时间和完成状态。业务规则很简单每天早上 9 点系统自动扫描所有“下次跟进时间等于今天并且还未完成跟进”的客户为对应负责人生成一条待办。看起来只是“每天跑一次”但真正落到系统里至少要回答五个问题什么时间触发查哪些数据满足什么条件才生成待办如何避免重复生成执行成功或失败如何追踪这五个问题就是理解定时任务的入口。定时任务不是闹钟而是时间触发入口很多人第一次理解定时任务时会把它想成“系统里设置一个闹钟”。这个理解没错但不够完整。在织信里更准确的理解是定时任务负责在特定时间点启动一段业务逻辑而这段业务逻辑可以是自动化也可以是脚本。从配置界面可以看到定时任务会关注几类核心信息类型可以使用默认周期配置也可以使用 cron 表达式。运行服务节点指定任务在哪些 Biz 节点上运行。失火策略当任务错过执行时间或异常触发时系统应该如何处理。失败阈值时间秒数用于判断任务触发是否超出可接受时间窗口。周期和时间例如每天、每周、每月或者间隔特定时间。执行失败后重试次数决定失败后是否自动重试。调用类型调用自动化或者调用脚本。这最后一项非常关键。定时任务并不直接等同于“查询客户、生成待办、发送通知”的全部逻辑。它更像一个时间入口到了时间后去调用已经配置好的自动化或脚本。所以在企业系统里一条完整的定时任务链路通常是这样的它不是简单提醒一下人而是可以连续完成多步动作到点触发每天 9 点启动一次。调用自动化或脚本把真正的业务逻辑交给下游执行。查询数据由自动化或脚本找到今天需要跟进的客户。条件过滤排除已经完成、已关闭、无负责人或不需要跟进的记录。去重判断检查今天是否已经为这个客户生成过待办。生成待办为客户负责人创建任务。记录结果定时任务本身有运行日志业务逻辑也可以额外写入业务日志或异常明细。这样做的好处是业务不再依赖某个人“记得去看”。系统会在固定时间主动把该做的事情推到人面前。先把数据关系想清楚做定时任务之前不要急着配置触发器。更重要的是先把数据关系想清楚。在这个客户跟进场景里数据可以拆成这样客户表是业务对象待办表是任务承载执行日志是系统追踪。一个比较实用的字段设计可以是表关键字段作用客户表客户名称、负责人、客户阶段、下次跟进时间、跟进状态判断哪些客户今天需要处理待办表待办标题、关联客户、负责人、截止时间、状态、来源类型、来源任务日期承接销售当天要做的动作定时任务运行日志名称、执行状态、执行周期、Cron、服务节点、最后执行时间、下次执行时间追踪定时任务是否按计划触发业务执行日志任务名称、执行时间、扫描数量、生成数量、失败数量、执行结果、错误信息追踪自动化或脚本执行后的业务结果这里最容易被忽略的是“来源类型”和“来源任务日期”。如果待办只是写一句“跟进某客户”后面很难判断这条待办到底是人工创建的还是系统自动生成的。加上来源字段后系统就能识别这条待办来自“每日客户跟进定时任务”。这条待办是为哪一天生成的。同一天同一个客户是否已经生成过。这就是后面做去重和追踪的基础。第一步定义触发时间和调用类型定时任务的第一步是定义运行周期同时选择调用类型。在这个案例里我们可以配置为触发周期每天。触发时间09:00。时区按企业实际使用时区。调用类型调用自动化或调用脚本。启用状态启用。如果是跨地区团队还要额外考虑一个问题是按照公司总部时间统一运行还是按照销售负责人所在地区分别运行。第一版通常建议简单一点先按公司统一时间每天运行一次。等业务量变大再考虑不同区域的任务分组。这里可以有两种实现选择如果规则比较标准比如“查询满足条件的数据然后新增待办、发送通知”优先用自动化。如果规则比较复杂比如要跨表聚合、做特殊去重、调用外部接口、生成复杂摘要可以用脚本。这也是织信定时任务设计里很重要的一点时间调度和业务逻辑是解耦的。时间调度负责稳定触发自动化或脚本负责具体执行。第二步用自动化或脚本查询今天需要跟进的客户定时任务触发之后会调用对应的自动化或脚本。接下来才是具体业务逻辑查询客户表。查询条件可以设计成下次跟进时间等于今天。跟进状态不是“已完成”。客户阶段不是“已关闭”或“已流失”。负责人不为空。这里有个很重要的细节字段值越规范自动化越可靠。如果“客户阶段”里有人填“已关闭”有人填“关闭”有人填“Closed”定时任务就很难稳定判断。所以在数据表设计阶段阶段、状态、负责人这类字段尽量用单选、成员、日期等结构化字段不要都用普通文本。低代码系统真正省时间的地方不是少写几行代码而是让业务数据从一开始就有结构。第三步生成待办前必须去重定时任务有一个常见坑重复执行。比如系统 9 点执行了一次因为网络波动没有拿到最终结果管理员又手动补跑一次。如果没有去重就可能给同一个销售生成两条一样的待办。所以生成待办之前最好先判断是否已经存在一条“来源类型 每日客户跟进定时任务来源任务日期 今天关联客户 当前客户”的待办如果已经存在就跳过。如果不存在再创建。这条规则看起来很小但它决定了系统是否能经得住真实业务里的重试、补跑和异常恢复。第四步在应用监控里查看定时任务运行日志很多团队做自动化时只关心动作有没有发生却没有记录动作是怎么发生的。这会带来一个麻烦当业务同事说“今天怎么没有生成待办”时技术人员只能去翻后台日志甚至不知道任务到底有没有运行。织信提供了应用监控能力可以在应用监控里查看每个定时任务的运行情况。在应用监控的定时任务页面可以看到每个任务的关键状态名称例如 license 到期前提醒、交付延期任务提醒、售前售后延期任务提醒。执行状态任务当前是待执行、运行中、成功还是异常。执行周期每天、每周、间隔特定时间等。Cron系统实际使用的定时表达式。执行服务节点例如 informat-biz3-prd。最后执行时间最近一次任务实际触发的时间。下次执行时间下一次计划触发时间。启停状态可以启用或停用定时任务。这类日志解决的是“定时任务有没有按计划触发”的问题。同时对于“触发之后到底处理了多少业务数据”我仍然建议在自动化或脚本里额外记录一份业务执行结果。比如每次任务运行后写入一条业务日志本次执行时间。扫描客户数量。命中客户数量。新增待办数量。跳过去重数量。失败数量。执行状态。错误信息。这样销售主管或系统管理员不用找开发也能自己判断任务今天有没有跑。跑了多久。生成了多少条待办。哪些客户因为数据问题没有生成。应用监控里的运行日志加上业务侧的执行结果记录才是完整的“可追踪”。第五步失败后要能补偿而不是只能祈祷真实系统一定会遇到失败。可能是某条客户记录缺少负责人可能是待办表字段校验不通过也可能是外部通知服务临时异常。所以定时任务不要只设计“成功路径”还要设计失败后的补偿方式。比较稳妥的做法是单条失败不影响整体任务继续执行。失败记录写入执行日志或异常明细。管理员可以根据日志修正数据。修正后允许手动补跑当天任务。补跑时仍然走去重规则避免重复生成。这样系统就不是“跑成功就好跑失败就完”而是有一个可恢复的闭环。织信里如何理解这个能力从产品能力上看定时任务通常会和数据表、自动化、工作流、脚本一起使用。在织信里你可以把它理解为数据表负责承载客户、待办、日志这些业务对象。定时任务负责把“时间”作为触发条件并按周期调用业务逻辑。自动化负责承接相对标准的业务动作例如查询数据、新增待办、发送通知。脚本负责承接更复杂的业务逻辑例如批量计算、复杂去重、跨系统调用。工作流负责处理需要人工审批或多人流转的场景。应用监控负责查看定时任务运行日志判断任务是否按计划执行。也就是说定时任务不是一个孤立功能。它的价值在于把原来靠人记、靠人查、靠人提醒的动作变成系统在固定时间自动执行并且留下过程记录。如果接入 AI会发生什么变化这一篇先讲低代码里的定时任务但它也很适合和 AI 能力衔接。比如每天生成待办后AI 可以进一步做几件事根据最近几次跟进记录生成今日沟通建议。判断客户当前风险等级提醒销售优先处理。根据知识库里的销售话术生成不同阶段的跟进模板。对昨天未完成待办进行汇总给主管一份异常清单。不过要注意AI 不应该绕过业务系统直接“自由发挥”。更合理的方式是AI 在权限范围内读取客户、跟进和待办数据再把建议写回系统形成可查看、可修改、可追踪的结果。这也是 AI 低代码的核心方向低代码搭好业务骨架AI 参与判断和生成但每一步仍然留在系统链路里。小结定时任务解决的不是“提醒一下”这么简单的问题。它解决的是企业里大量周期性、重复性、容易遗漏的业务动作每天生成客户跟进待办。每周汇总销售数据。每月检查合同到期。每小时同步外部系统状态。每天推送异常库存或逾期任务。做好定时任务关键不是把时间设置上去而是把四件事设计清楚什么时候触发每天、每周、每月还是 cron 表达式。触发后调用什么自动化还是脚本。业务逻辑怎么保证稳定条件过滤、去重、失败重试和补偿。运行结果怎么看应用监控看定时任务运行日志业务日志看具体处理结果。当这些能力组合起来系统就会从“保存数据的地方”变成“主动推动业务运行的地方”。