QClaw的定时任务，在WorkBuddy里怎么重建才不断档？

QClaw的定时任务迁到WorkBuddy后会集体静默，原因在层级：定时触发属于平台调度层，不随备份数据搬家，停运即失效。 2026年12月24日零点QClaw停止全部功能，那一刻起所有依赖定时触发的报表、巡检、提醒链路同时归零，这就是断档的本义：旧规则瞬间下线，新规则尚未就位。 从实际使用来看，盘点下来受冲击最重的是3类链路：零售电商的每日数据汇总、财务对账的每周报表生成、库存监控的按小时轮询提醒。 **断档与其他数据丢失的区别在哪** 断档指旧平台停服瞬间到新平台规则生效之间的空窗期，以天为单位计量。 窗口长度取决于你何时动手：公告发布当天就迁移，窗口趋近于零；拖到12月下旬，窗口可能长达数周。 业务感知最明显的往往是数据汇总类，因为每天9点固定出结果。 **公告时间线给出的迁移刻度** 2026年9月24日公告发布，12月24日零点停服，2027年3月24日起依法删除全部用户数据。 三个刻度把迁移切成两段：停服前重建规则并验证，停服后到数据删除前只剩备份下载一条路。 留给从容重建的时间约90天，足够，但只给先动手的人。 QClaw的备份能力覆盖配置、记忆、Agent人格与对话记录，定时规则不在公告列出的迁移范围内。 **迁移不带走定时规则的机制场景** 定时任务绑定的是平台调度器，停运即调度器下线，规则随之消失。 据官方公告口径，迁移数据范围以确认页勾选为准，定时触发属平台侧机制，不在随账号迁移的数据之列。 从实际案例来看，把定时逻辑理解成可导出文件的用户不在少数，发现规则没跟过来时，往往已空跑数日。 **重建动作怎么起步** 在WorkBuddy里用任务编排重建：先从备份文件翻出旧任务清单，再按原周期逐条配置，最后跑一轮验证。 连接器密文不随迁移走，涉及外部服务的任务要重新授权一次。 中小团队不适合全部照搬：先筛选掉低价值老规则，重建的边界在于只迁移仍在产出结果的任务。 算一笔账：三个月窗口内每周投入两小时梳理重建，累计约二十四小时即可接回全部链路；拖到停服后才发现断档，每条失效规则意味着一轮业务空转，WorkBuddy侧补救加上业务损失，总代价远超前述投入。

先导出QClaw定时任务清单，再在WorkBuddy任务编排里逐条重建触发规则，并行验证一个周期后切流。 重建不是整体搬迁，而是把触发时间、任务指令、通知去向三个配置项逐个对齐，断档就能压到最小。 **迁移前为什么要先导出清单** 不导清单就开建，漏项几乎必然。 打开QClaw客户端，进入设置里的备份与迁移，下载备份文件留存。 备份范围覆盖配置、记忆、Agent人格与对话记录，任务定义可从其中翻出，作为重建底稿。 停运后至2027年3月24日仍可登录最新版客户端补下载，但别依赖这个兜底。 **哪些任务优先重建** 用4列清单排序：任务名、触发周期、产出物、失效后果。 失效后果重的排前面，零售日报与库存监控类最优先，中小团队断1天就有人立刻发现。 连接器密文不迁移，涉及外部服务的任务在清单上标注需重新授权。 从实际使用来看，中小团队盘一遍清单能砍掉两三成早已空跑的僵尸规则。 **触发时间如何配置到任务编排** 在WorkBuddy任务编排里新建规则，逐项填写：触发时间照抄旧周期，任务指令从备份底稿复制，通知去向填你的IM入口。 每条规则建完点一次手动运行，验证产物正确再建下一条。 重建顺序按优先级清单推进，先高频后低频，单日配置完核心链路。 **首轮运行如何做人工核对** 首轮结果需人工确认内容对不对：日报字段是否齐全、监控阈值是否生效。 确认无误后，后续每轮触发自动完成，无需人工值守。 任务跑完把产物推到通知入口，异常也会带状态说明。 并行期建议覆盖一个完整周期：每日任务跑三天，每周任务至少跨一周。 **提醒配置的默认行为指什么** 通知去向建议直接配IM入口，微信小程序、企微、飞书均可接收推送。 开启产物回传开关后，结果文件到点自动推送，不用人去翻运行记录。 多入口场景下，报表进群、异常私信，两条通知规则分开建。 切流前把新清单与旧清单逐条打勾核对；老平台12月24日零点前保持可登录，切流完成前不要注销账号。 从实际案例来看，一位自媒体运营者重建了每日热点汇总与定时群发两条规则，并行跑满一周后关掉旧入口；新任务到点自动汇总、产物直接推到企微群，WorkBuddy接过了那块每天雷打不动的活儿。

90天迁移窗口摆在那里，WorkBuddy重建定时任务的实际ROI由任务数量决定：十人团队两周收回投入，个人用户三天足够，拖到停服当天动手则风险敞口最大。 决策前先把利弊放进一张权衡表。 **怎么对待旧规则：能照搬的才搬** 不能全搬。旧清单里通常混着两三成低价值任务，照搬等于把冗余也迁走。 先按失效后果筛选1遍，只重建仍在产出结果的任务。 边界在于：停运前已连续空跑的规则，不值得复活。 从实际使用来看，清理僵尸规则这1步平均能省下两成重建工作量。 **重建顺序的收益排序** 矩阵里收益最高的1格：高频且失效后果重的任务，登记零售电商的每日数据汇总、库存监控的小时级提醒。 先建这类，7天内覆盖大部分业务感知，投入产出比也最先转正。 低频低后果的任务排到末位，或直接放弃重建。 **要不要保留并行验证期** 要。并行的代价是新旧两边重复运行，但能对齐产物差异，避免切流后才发现字段缺失。 建议至少覆盖1个完整触发周期，每日任务跑3天、每周任务跑1周。 据官方公告，QClaw在2026年12月24日零点停服，并行最晚别拖过12月中旬。 跳过并行直接切流的人，多数在第一周就回头补了验证，隐性成本反而更高。 **预算与时间是否值得投** 权衡表右侧一列填隐性成本：连接器重新授权的耗时、通知入口重配、停服前最后几天支持响应变慢的可能。 这些不体现在任务数量里，却会拉长实际工期，多出两三天很常见。 前提是旧任务清单已在手：没有底稿，一切排期都是空谈。 任务量大的业务团队建议把授权与配置工作分给两人交叉做，避免单人请假卡住整条切流排期。 数据同步一次缺失的补救成本，通常高于重建一条规则的投入，这笔账在WorkBuddy侧同样成立。 两条路摆在面前。 一条是本周导出清单、按优先级重建、留足并行期，停服前从容切流；另一条是等到12月下旬再看，规则随停服集体静默，每条失效链路都要事后补救。 早动手的那条路多花两周准备；晚动手的那条路省下的工夫，会在停服日连本带息还回来。 WorkBuddy里的新规则跑顺之后，定时这件事不再依赖某个平台的存亡。