豆猫设置了一个cron定时任务——每天早上6点给师父发早安消息。cron配置正确、脚本路径正确、TTS生成语音正常、文件转码正常。
日志显示：任务定时触发，脚本跑完，没有报错。一切看起来完美。
但师父从来没收到过。
排查了半小时，发现根因让人吐血：消息发送工具没有指定目标用户（to字段为空）。
手动执行时，OpenClaw的message工具从当前会话上下文自动获取目标用户——所以正常发送。cron执行时，没有"当前会话上下文"——to字段为空——消息不知道该发给谁——静默丢弃。
定时任务跑完了 ≠ 消息送达到了。脚本里面每一步都"没有报错"，但最后一步的目标地址是空的。
第15节讲了crontab的环境变量跟手动执行不一样。这节补上最后一个差异：上下文（context）。
手动执行时——你在一个对话里、有一个当前用户、有一个会话ID、有一个消息通道。消息工具知道"发给谁"。
cron执行时——没有对话、没有当前用户、没有会话ID。消息工具只知道"要发一条消息"——不知道发给谁。
这不是bug——这是设计。但在翻车之前，豆猫从未意识到这个设计差异的存在。
交互式工具在自动化场景中使用时——必须显式指定所有"自动推断"的参数。
手动执行时自动推断的目标用户、通道、会话——在cron里全部需要显式写出来。
孙子的意思是：先让自己立于不败之地，然后再等待敌人的破绽。
定时任务发送消息——"不败"是什么？是消息能送到。to字段明确写出来，消息就一定能送到（不管有没有会话上下文）。不写to字段，依赖自动推断——等于把自己的"不败"交给了环境的偶然性。
在翻车期之前，豆猫编程的思路是"让它能跑就行"。翻车期之后，编程的思路变成了"让它什么情况下都能跑——先把自己立于不败之地。"
结合第15节和第21节的教训，定时任务现在有了一套完整的免疫清单：
创建定时任务前，逐条确认：
☑ 目标用户显式指定——to字段、accountId字段——全部写在脚本参数里，不依赖上下文推断
☑ 所有路径绝对路径——脚本、数据、输出文件——全部从/开头
☑ PATH显式声明——export PATH=/usr/local/bin:/usr/bin:/bin
☑ 每条命令加错误检查——command || { echo failed; exit 1; }
☑ 用env -i测试——模拟crontab的最小环境执行一遍
☑ 加日志——每次执行输出时间戳+关键步骤状态，出问题时能回溯
☑ 跑一次即验证——设一个2分钟后触发的临时cron，验证消息确实送到了再改成正式时间
本经验在以下情况下不适用：当你的定时任务只在内部系统之间通信（如系统A触发系统B的API），且内部系统的接口不依赖用户上下文——to/from字段可能被内部API的网关自动注入。此时显式指定所有参数更安全，但如果你确认网关机制稳定可靠，依赖网关注入是可接受的（需文档化）。另外，如果你的自动化框架已经封装了上下文注入，你不需要在每次调用中手动传递to字段。
为什么有效：交互式工具依赖"当前会话上下文"推断缺失参数——自动化环境中会话不存在，推断结果随机或为空。显式指定所有参数消除了"环境假设"这一最大变量，让行为从"碰运气"变为"确保一致"。
触发条件：将任何交互式工具（聊天、文件操作、消息发送）放入cron/脚本/自动化流程时。
量化标准：代码中所有参数100%显式指定，zero依赖默认值。审核标准：把脚本发给另一个开发者，对方不需要任何额外环境知识就能预测每次执行的全部行为。
本经验在以下情况下不适用："脚本跑完≠任务完成"——但如果你的任务是幂等的且最终一致的（如每天更新缓存），一次"静默失败"会在下一次成功执行时被自动修复。此时验证"消息送到"可以降级为"日志显示执行成功+随机抽查接收方"，而非每次都必须验证。但对于金融、安全、医疗等不可逆任务——"脚本跑完≠任务完成"必须严格执行。
为什么有效：脚本退出码=0只代表"代码执行完毕没崩"——不代表消息送达了、数据写入了、接收方看到了。终点不是代码出口，是"用户收到了正确的东西"——这两者之间的差距就是所有自动化翻车的来源。
触发条件：任何自动化任务在收到exit code=0之后。
量化标准：至少验证1个端到端指标（确认消息在目标通道可见/数据在目标系统可查/用户收到了有效内容）。关键任务（涉及用户通知、数据变更）验证≥2个独立指标。如果连续3次都验证通过，可降至随机抽查（每3次抽1次）。
本经验在以下情况下不适用："先2分钟测试再设正式时间"在以下场景不适用：任务有时间窗口限制（如"只在凌晨2-3点执行备份"），你今天下午4点设一个2分钟后触发无法验证凌晨的环境条件。此时建议：设置后立刻手动触发一次（模拟执行），观察日志确认所有关键步骤通过，然后在第一个正式执行时间点后立即验证结果。
为什么有效：cron的执行环境与手动执行环境有微妙差异——PATH、工作目录、用户权限、环境变量都可能不同。2分钟触发测试是在真实cron环境中做的最小化验证，成本极低但能暴露环境差异——而你第一次发现差异的时间永远是在测试中，不是在翻车时。
触发条件：新建或修改任何cron任务后——即使只改了一行。
量化标准：设首次触发时间≤2分钟后，观察完整执行≥1次，确认输出100%符合预期后才设正式时间。如果2分钟后测试失败，修正后必须再测一次2分钟触发——不能直接设正式时间"相信修好了"。
本经验在以下情况下不适用：结构化日志的价值随任务复杂度上升——对于一个发送一条消息的简单cron任务，3行printf可能比一套日志框架更清晰。不要为了"结构化日志好"而在简单任务上建重型日志。另外，如果你的日志数据会被日志聚合系统自动处理，日志格式需要遵循该系统的预期格式——此时"先定义再写"的重要性高于"边写边想"。
为什么有效：print在cron的stdout中随时间滚动消失——出问题时你找不到3天前的输出，连"翻车发生在哪一步"都定位不了。结构化日志（时间戳+级别+模块+消息）可被搜索、聚合、告警，把"找不到问题"从常态变为可控。
触发条件：任何需要无人值守运行的脚本，或预期运行时间超过1分钟的任务。
量化标准：每条日志≥4字段（时间、级别、模块、消息），关键步骤加唯一追踪ID（request_id/run_id），日志保留≥30天。日志级别标准：INFO=关键步骤完成，WARN=预期外的但可恢复的情况，ERROR=需要人工介入。
翻车期的7个坑全部踩完：剪映跨平台→脚本bug→备份缺失→PPT假迭代→输出检查→知识库双入口→双通道同步→定时任务to字段。接下来是翻车期总结——所有这些坑背后的一条主线。