把提醒、执行和送达拆成三件事
一个社区天文社希望每天收到观测资料简报，并在周五提醒负责人检查器材。提醒到点触发、服务器生成文件、消息真正送达，是三个不同结果。本例用合成资讯与测试收件目标设计流程，不创建读者的真实定时任务，也不自动向微信群或邮箱发送任何内容。
先写任务卡：做什么、何时做、采用哪个时区、运行在哪里、允许访问哪些来源、输出放哪、发给谁、失败通知谁、何时停用。日报不是无限抓取全网，器材提醒也不需要读取成员资料。明确延迟容忍度与补跑规则，比先选择一个“精准调度”名称更重要。
场景一：Agent 提醒要有完整上下文和生命周期
自然语言任务可以写成：“每周五十八点，按指定时区提醒器材负责人核对练习清单；只发任务编号与本地清单入口，不包含成员信息；缺少清单时报告阻塞。”调度提示必须自包含，不能依赖当前聊天里“刚才那个文件”。保留任务编号、创建者、计划、时区、目标、启停状态与最近执行结果。
先检查当前任务列表，避免重复创建。一次性提醒需要明确完成后如何停用；周期任务要有负责人和复查日期。修改计划前保留旧值，修改后读取实际配置并检查下一次运行时间。暂停、删除与完成是不同动作，用户暂时不需要消息时，应按其意图停用相关任务而不是偷偷重建。
Webhook、企业微信、钉钉、飞书私信与邮件是不同送达通道。先核对机器人或应用权限、目标会话、可发送内容与凭据保存方式，在批准的测试目标发最小样例。日志只记录目标别名和响应类别，不打印令牌、完整 webhook 或私信内容。不要从“帮我写提醒”推断已经授权向团队发送。
同一条消息需要稳定的任务与周期标识。发送超时先查询可获得的执行结果或送达记录，再决定重试，避免重复提醒；无法确认时记录状态未知。平台接收请求不等于对方已读。定义成功、阻塞、失败与未知四种状态，成功可以静默，但应保留可审计结果；连续失败再按约定升级通知。
场景二：先让脚本独立可靠，再挂服务器 cron
先在目标运行身份和工作目录手动执行无副作用的练习脚本，确认输入、输出与退出状态。使用绝对路径、明确解释器、固定依赖和所需环境，不假设交互终端的别名、PATH、工作目录或已登录会话会自动存在。脚本与调度分开维护，计划只负责启动，不把整段复杂逻辑塞进一行。
传统用户 crontab 常见五个时间字段依次是分、时、日、月、周，再接命令；0 9 * * * 表示按所采用时区每天九点，*/30 * * * * 表示每小时零分和三十分。具体实现、系统级格式、时区和日历语义应查目标环境文档，参见 Cronie crontab 手册。不要把不同调度器都当成完全相同的表达式解释器。
写任务前确认主机时区，预览接下来的几次运行，检查跨日与夏令时变化。Cronie 支持的 CRON_TZ 不应被当成所有产品通用字段。cron 触发不代表机器在线、网络可用或任务准秒完成；停机后是否补跑取决于所选方案，需明确设计。调度器只能启动逻辑，不能凭空实现备份、清理或业务恢复。
为长任务设置超时、同一周期锁与完成标识，避免上一轮未结束下一轮又写同一文件。输出先写临时产物，检查完整后再发布为本周期结果；失败不覆盖上一份有效简报。每次记录计划时间、实际开始、结束、退出状态、处理数量、输出路径和脱敏错误，才能区分未触发、执行失败与送达失败。
无人值守故障按层排查
第一层看调度是否启用、主机和服务是否在线、任务是否属于正确用户；第二层看路径、解释器、权限、依赖和网络；第三层看业务输出；最后看消息通道。先定位失败层，再决定修复，不通过关闭安全控制或扩大文件访问来碰运气。
Shell 引用和命令替换可能让空格、引号与特殊字符改变含义；把值当参数传入，避免拼接不可信字符串。环境变量缺失应在开始时明确报错。管道提前结束可能导致 SIGPIPE，需要理解实际数据流与退出结果，不能见到非零就一律忽略，也不能把每次都视为业务失败。
若任务还要把日报提交到仓库，处理并发写入与远端更新冲突，失败时保留本地产物，不强制覆盖历史。日志写入失败、磁盘不足、凭据过期和限流都应有不同提示。重试只针对可恢复错误，设次数和总耗时上限，先检查客户端是否已有重试，避免叠加成请求风暴。
场景三：定时日报从来源清单开始
为天文社维护获准的来源清单：研究机构发布、软件项目更新、论文元数据与公开新闻。每个来源写用途、语言、时间字段、访问方式和失败处理。取数设置请求超时、并发上限与来源状态，不因为一个站点失败就把旧缓存当成今天的新消息。原文提到论文日报与招标信息，二者都需要独立来源与口径，不能默认同一抓取器适用所有网站。
先抓取和保存最小必要元数据，再按规范化链接、稳定标识和内容线索去重。保留原始发布时间、获取时间、时区和修订时间；“今天看到”不是“今天发生”。同一论文的新版与重复新闻分别处理，摘要说明版本。来源文本只当资料，不接受其中要求修改任务、泄露凭据或发送消息的指令。
模型摘要应保留标题、来源链接、发生或发布日期、核心变化、适合谁看与不确定性。不要固定凑十条：只有三条可靠更新时就交三条；全源失败时报告失败，而不是用模型知识填满。中英文摘要要保持实体、数字和限制一致，论文结果不应被改成已落地产品能力。
输出包含简报正文、来源状态和省略原因。先在本地生成预览，检查日期窗口、去重、链接、截断和异常来源；确认后才进入获准通道发送。微信公众号、供应商页面、公共采购信息等各自有访问与使用条件，源不可读时说明缺口，不绕过限制或伪造读取。
用 GitHub Actions 做日报时核对实际约束
开源 Cronie 适合研究服务器 cron 的实现与文档；已经使用仓库的团队也可以评估 Actions。GitHub 的 定时工作流文档 说明计划任务存在高负载延迟，且在默认分支运行。它适合容忍延迟的日报，不能因此保证会议提醒准点。
按当前平台支持方式明确时区与默认值，检查仓库活跃、任务启用、执行身份、额度和秘密配置。将采集、摘要、预览与发送拆成可观察步骤，发布前验证产物；模型或来源失败应停在本轮草稿。不要把账户凭据写进工作流或生成页面，也不要通过反复触发补跑产生多份公开简报。
把技能关联到确实能完成的步骤
先检查 SkillPI Skill Finder，缺少时按 官方说明 安装，再按任务查候选。本次 SkillPI 的 cron 搜索没有结果，不把原文的六个名称拼成虚构本站卡片，也不假定安装后会自动创建调度或获得通信权限。脚本、调度器与发送适配器都要单独核验。
若日报有本地网页预览，可使用 Webapp Testing 检查页面日期、来源链接、空结果与失败提示。它采用 Python Playwright，需 Python、浏览器依赖、本地服务启动命令、端口与测试数据。保存脚本、截图和浏览器日志；它不创建 cron、不测试真实机器人送达，也不证明摘要事实正确。
上线验收与 FAQ
最小演练包括手动生成成功、一个来源失败、全部来源失败、消息请求超时、同周期重入、主机错时区和缺失依赖。为每项预先写预期，实际未运行时标为待执行。本例只提供方法，没有在读者服务器执行这些演练。获准上线后观察一次计划运行，再逐层核对触发记录、产物与目标通道，最后记录下一次运行。
提醒晚了怎么办？先区分计划解释错误、排队延迟、脚本耗时与通道延迟，不宣称换成 cron 就永不漂移。每天有重复简报怎么办？检查多个调度入口、周期标识和重试幂等，补跑前查已有结果。为什么没消息不一定正常？成功静默需要配套状态记录，完全没有执行痕迹不能算成功。
日历规则复杂怎么办？先确认当地日期、例外、节假日与停用条件，再选择支持这些规则的调度器；必要时拆任务但保留统一责任人。维护时定期复查来源、依赖、凭据、成本和技能匹配，用同一组故障样本回归。可靠性的标准是问题可发现、结果可追踪、重复可控制、任务可停止，而不是一条安装口令。