为什么你的 Claude Code 例行任务报告成功，却什么都没做

HN Code LLM Research 2026-10-06T07:25:43.876466

作者

发布于

Anthropic 的 routines（例行任务）文档里有一句话，比整页其他内容加在一起制造的困惑都多：运行列表里的绿色状态，只代表会话成功启动、并且没有因为基础设施错误而退出——它并不代表你提示词里的任务真的完成了。

一句话就把无人值守自动化的全部问题说透了。例行任务运行时没人在旁边盯着，而运行列表是大多数人唯一会看的东西。问题是，这个列表汇报的东西根本不对：它告诉你机器跑起来了，而不是活儿干完了。

下面讲讲例行任务在报告成功的同时实际失败的三种方式，以及一套八步检查法——在你排定任何任务之前，它能把这三种坑全堵上。

三种看起来和成功一模一样的失败

1. 数据源根本没读到

你的邮件连接器超时了，例行任务于是写下「没有紧急消息」。你喝咖啡时看到这句，当成好消息。

这可不是好消息。这是没有消息——而在输出结果里，这两者根本分不出来。这是无人值守场景里代价最高的一种失败，因为它看上去一点问题都没有。日历连接器挂了，渲染出一张空白日程表，而空白日程表读起来就像是「今天空闲」。等到周四你才发现不对劲——周二那场你压根没去的会议。

2. 检查根本没执行

一个健康检查例行任务连不上你的服务端点，却对此只字不提，读起来就和系统一切正常毫无区别。沉默本身是有歧义的，而在读者脑子里，有歧义永远默认解读为「没事」。

这里有个具体的报错特征值得了解一下：在默认的云端环境里，网络访问权限是 Trusted，只允许访问 Anthropic 的默认白名单。请求白名单之外的域名会失败，返回 403，并带有响应头 x-deny-reason: host_not_allowed。这是一个真实的、有明确名称、可以捕获的错误——但前提是你的提示词写了去捕获它，而不是假装无事发生继续往下走。

3. 触发时机不对的运行

如果你把例程刚好安排在每个整点，它可能晚几分钟才启动。Anthropic 自己的建议是选 9:07 而不是 9:00。本地桌面任务更糟。早上 7 点的简报因为笔记本关机而没跑成，等机器晚上 11 点唤醒时会被当作「补跑」执行——而且它仍然用现在时写「今天」，可这一天都快过完了。

这三种情况都不会报错。三种都是绿灯。

八项检查

任何例程提示词——不管是模板里现成的，还是你自己写的——在安排调度之前，都先过一遍这八项检查。每一项都堵住一个具体的漏洞。

检查 1——自包含

例程会话不记得你们之前的对话，也没法追问。任何提示词里默认「你（指人）会补上」的信息，实际上都是缺失的。把它当成写给一个从没见过你的、能力不错的陌生人的说明书来写：指名道姓说清文件、时间窗口和阈值。

检查 2——写明来源

输出里的每一个数字，都应该能追溯到例程在这次运行中真正读到的东西。这项检查防的是一种很隐蔽的失败：一个看起来合理、却不知道从哪冒出来的数字。要求提示词列出它的来源和计数，编造出来的数字就无处藏身。

检查 3——自我核对

加一步，让例程重新打开自己的输出，跟它读到的东西对一遍。计数要跟列出的条目对得上。时间要按实际读到的写，不能四舍五入。结论要能追溯到证据。这一步得有能力让整个运行失败——一个永远都会通过的核对环节，只是摆设。

检查 4——可重复执行

例程会被触发不止一次。GitHub 触发器在有人往一个打开的 pull request 里推送时就会触发，而 Claude Code 不会在不同事件间复用会话——推五次就是五次独立的运行。所以要把状态绑定在稳定的东西上（比如最新的 head commit SHA，而不是 PR 编号），这样重复运行时就什么都不写，而不是写出重复内容。

检查 5——读不到就如实说

这一条几乎所有提示词都过不了，也是代价最大的一个。规则很短：

读不到的来源，绝不能渲染成一个空着没内容的来源。

修改只需几行，却是你能对例行任务提示词做出的价值最高的一处改动：

For each source, record exactly one of two outcomes:
  read: <count> items for <explicit window>
  unavailable: <the exact error or refusal text>

Never infer absence from a failure. If a source is unavailable, the
section it feeds says "unavailable: <reason>". An empty section and
an unreadable section must never look the same.

两种结果，缺一不可。窍门就这一点，它能把无人值守自动化里最危险的故障，变成一眼就能看出的故障。

检查 6 — 最小权限

在权限这件事上，平台的默认设置对你不利，这点必须说直白些。创建例行任务时，你账号下当前挂着的所有连接器（connector）都会默认加进来。运行时，Claude 可以使用这些连接器中的每一个工具——包括写入——而且不会停下来征求许可。

也就是说，你直接接受、不做修改的模板，一上来就握着你全部连接器清单，写入权限一应俱全；只要任务看起来需要，它就会不打招呼地用上其中任何一个。第一次运行之前就把这份清单削减到例行任务真正需要的范围，别等出了第一次事故再动手。

检查 7 — 失败要出声

既然绿色的成功提示什么都说明不了，例行任务就得自己开口。给每次运行一个明确状态——OK 或 PARTIAL——只要某个来源不可用，或某项校验失败，结果就标成 PARTIAL。每次运行往日志文件里追加一行。这样，一个悄悄失败了两周的例行任务，你能直接看到，而不用自己去察觉那片沉默。

检查 8 — 感知时间

让提示词先读时钟，和它本该运行的时间段作对比。如果已经晚了几个小时，就在输出的第一行说明，并且汇报原本那个时间段覆盖的范围——而不是从现在往前推 24 小时。晚上 11 点生成的简报，根本不该出现「今日重点」这样的清单。

全部落地后是什么样子

这八项合在一起，就把一个只描述任务的提示词，变成既描述任务、也描述任务失败后该怎么办的提示词——一旦无人盯着，这才是唯一要紧的区别。

本文的配套文章用一个真实模板从头到尾走完整条流程，并附上可直接粘贴的加固版提示词：如何加固每日简报（Briefing）例程模板。

另外几篇也值得一读：

Routines Runbook收录了 32 个从一开始就按这套方法搭建的现成例程，还包含 Anthropic 官方八个免费模板的加固替代版，以及背后支撑它们的十四种护栏模式。看看里面有什么，或者领取免费的 5 个例程入门包。

本文描述的平台行为，已在 2026 年 10 月 5 日对照 Anthropic 的例程和桌面端定时任务文档核实过。例程目前属于研究预览版，细节随时会变；本页标注了核实日期，方便你判断内容有多陈旧。与 Anthropic 无隶属关系。

更多文章

查看原文