把”无人值守”做成可交付的工程能力，是 Claude Code 自动化例程（routines）的核心目标。要让云端会话在没有人在场的情况下稳定产出，官方在文档里把”prompt 必须自包含且明确说明要做什么以及成功标准”列为头号硬性要求。这一规定不是行文偏好，而是与 Plan 模式的设计哲学、可审计交付物的契约习惯直接挂钩。
一、为什么无人值守场景下 prompt 必须自包含
自动化例程运行在 Anthropic 托管的云基础设施上，触发方式有三种：定时（每小时/每晚/每周一次）、API（外部系统发起 HTTP POST）、GitHub 事件（PR/issue 触发）。无论哪种触发，会话启动时现场都无人：
- 会话没有澄清机会：用户不在场，模型得不到”刚才那条是什么意思”的追问；含糊指令直接变成含糊产物；
- 上下文不携带历史：每次运行是干净的云端会话，前一次的对话、临时笔记、用户偏好都进不来；
- 执行路径不可中断：没有中途审批，没有”等用户确认再继续”，错误只能靠 prompt 自身的回退逻辑兜底。
| 触发方式 | 是否有人值班 | Prompt 缺信息的后果 |
|---|---|---|
| 定时 | 否 | 模型乱猜，产出一堆误标 |
| API | 否 | 调用方拿不到想要的字段 |
| GitHub | 否 | 误改仓库、误开 PR |
把”自包含且明确成功标准”作为硬性要求，本质是把”人在场才能完成的判断”提前写进 prompt。这与 Plan 模式里”先把意图拆清楚再执行”是同一套思路，只是执行者从模型变成了”没人”。
二、Plan 模式与自动化例程的同构关系
Plan 模式强调三件事：目标（outcome）、验收标准（acceptance criteria）、边界（boundaries）。自动化例程的 prompt 恰好也是这三件事：
| Plan 模式三件套 | 自动化例程的对应 |
|---|---|
| 目标（要做什么） | prompt 中的目标陈述 |
| 验收标准（怎么算成功） | prompt 中的 success criteria |
| 边界（不做什么） | prompt 中的 scope exclusions |
Plan 模式是”人在场时的即时对齐”，自动化例程是”把对齐结果固化成文档”。两者本质都是把”做事前的共识”显式化、文本化，让模型后续按图索骥。正因为这种同构，官方在两份文档里用几乎一致的措辞要求”outcome / acceptance criteria / out of scope”三件齐全。
在工程实践里，一个有效做法是：先用 Plan 模式在 IDE 中打磨出一份计划，把这份计划直接搬到例程的 prompt 字段。这样既复用了一线工程师的判断，又避免了”为云端另写一版”的双轨维护。
三、为什么”成功标准”必须显式给出
成功标准是 prompt 里最容易被略掉的部分，但它对工程交付有决定性影响。
举一个反例与正例对比：
- 反例：每晚扫描 PR，给出评审意见。
- 正例：每晚扫描当天新开 PR，给每条 PR 输出三条以内的评审意见，意见必须包含”文件:行号 + 问题类型 + 建议改法”；产出物为 PR 评论；若 PR 已被标记为 draft 则跳过。
| 维度 | 反例 prompt | 正例 prompt |
|---|---|---|
| 触发条件 | 模糊 | 明确”当天新开”且”非 draft” |
| 产出形态 | 未定义 | 限定”三条以内”+”PR 评论” |
| 内容结构 | 未约束 | 强制”文件:行号 + 问题类型 + 建议” |
| 边界条件 | 未提 | 显式跳过 draft |
反例 prompt 跑一个月，产出会漂移到完全不可用的程度；正例 prompt 跑半年，产出仍能稳定可消费。这就是”显式成功标准”在工程交付里换来的复利。
四、自动化例程的工程交付契约
把视角拉到团队层面，自动化例程是一种”无人值守的工程交付物”，它跟 CI 流水线、夜间批处理任务属于同一类资产。这类资产有一个共同特点：交付时必须附一份”运行手册”，否则接手的人无从判断它是否在按预期工作。
一份合格的例程 prompt 至少覆盖四块：
- 目标陈述：用一句话说清”这次例程要被自动完成的事是什么”；
- 输入清单：列出例程依赖的连接器、环境变量、仓库分支、外部 API；
- 操作步骤：用有序列表写出”读 → 判 → 改 → 写”的具体动作，每步动词开头；
- 成功标准：用可观测信号（PR 评论数、Slack 消息、日志字段）说明”成功长什么样”。
下面是一段骨架示例，可按团队场景填充：
目标：每周一上午 9:00 扫描过去 7 天合并到 main 的 PR，
找出与"订单退款流程"相关的代码变更。
输入：
- GitHub 连接器：访问仓库 billing-svc；
- 关键字集合：refund, chargeback, reversal。
操作步骤：
1. 用 GitHub 连接器列出过去 7 天合并到 main 的 PR；
2. 过滤标题或 diff 中包含任一关键字的 PR；
3. 为每条命中的 PR 打开 issue，标题格式 "[退款巡检] <原 PR 标题>"；
4. 在 issue 正文里附上原 PR 链接与命中的关键字。
成功标准：
- 当周无关键字命中时，发一条 Slack 消息到 #billing-ops，写明"无退款相关变更"；
- 命中的 PR 必须全部产生对应 issue，issue 数量等于命中数量；
- 任何步骤失败时，把异常堆栈写入 #billing-ops 同一频道，不静默吞错。这份 prompt 跑起来，每次运行结果都可被另一名工程师仅凭”读 prompt”验证是否符合预期。这正是工程交付里”可被独立审计”的要求。
五、把自包含要求落到团队流程
把”自包含”从个人习惯升级为团队纪律，三条建议足够：
- prompt 入库即评审：所有要上线的例程 prompt 必须走一次 code review，评审人对照”目标/输入/步骤/成功标准”四块逐项打钩；
- 失败样例倒推修订：每次例程出现误判或漏判，都把”当时 prompt 与失败 case”一并归档，作为下一轮修订的依据；
- 与 Plan 模式共用模板：把 Plan 模式打磨出来的计划文件直接复用为例程 prompt，团队只维护一份”标准 prompt 模板”。
把这套流程跑顺之后，自动化例程就从”黑盒定时任务”升级为”团队可维护的工程资产”，与 CI、Airflow、cron job 等传统自动化站在同一条可治理的线上。
常见问题（FAQ）
Q1：prompt 写得很短，能跑就行吧？
短可以，但目标、输入、步骤、成功标准四块缺一不可，否则无人值守时必然漂移。
Q2：能不能在 prompt 里写”参考 GitHub issue 模板”？
可以，但 GitHub issue 模板本身也要在 prompt 里复述关键约束，不能假设模型跨会话记得。
Q3：Plan 模式和例程 prompt 是什么关系？
Plan 模式是把意图对齐在交互中完成；例程 prompt 是把对齐结果固化为无人值守的可执行文本。
