给 Claude Code 加停止规则，减少无效重试

Claude Code 放着自己跑，可能连续五次重试同一条失败命令，也可能反复检查一个没有变化的文件。作者给出的办法很小：把任务说明和停止条件写进一个 skill，让 agent 在继续消耗额度之前，先判断是否还在推进。

这套规则来自他们团队在一个项目中每天运行多个 Claude Code 会话的经验，没有跨项目的节省数据。值得借鉴的是它把「什么时候该停」写成了具体条件，适合拿来检查自己的长任务指令。

开工前，先把任务边界交代完整

作者建议，在启动子 agent 或重复任务前，先写清目标、目的、允许修改的范围，以及预算。

目标回答「交付什么」，目的回答「为什么做」。例如，检查失败究竟需要修复代码，还是只需要定位原因，两者允许采取的行动可能不同。文件或目录范围则限定 agent 可以动哪里，避免一个局部任务扩展成无休止的整理。

预算可以按轮次、token 或分钟设定。原文没有推荐具体额度，也没有说明这些预算是否由工具自动执行。

预算要在任务启动前确定，超出后先重新判断。

原文说要写清「四件事」，实际列成了三项，其中「目标和原因」合在一起。落地时把它们拆成四个字段即可，不必纠结格式。

停止条件，要能判断有没有进展

作者的规则不是遇到失败就放弃，而是阻止同一种尝试无限重复：

• 连续两次检查没有可衡量的进展，例如状态、文件或数值都没变化，就停下来重新思考。
• 同一个错误出现两次，先改变导致错误的条件，再重试。原文举了循环中的工具和 API 限制作为排查方向。
• 超出任务说明中的预算，就停止继续消耗。
• 遇到 git 冲突或文件锁阻塞，不要强行推进。

这里最有用的是区分「执行过动作」和「取得了进展」。又调用了一次工具，只能证明 agent 还在运行；它不能证明离目标更近。

结果返回后也有边界：最多三轮跟进，每轮都要有理由。到了第三轮，就明确采用或舍弃，不能一直挂着等待下一次修改。这个限制约束的是结果跟进，不应直接理解成所有命令最多只能执行三次。

SKILL.md 承载的是约定，执行机制没有交代

原文展示的代码是 skill 的元数据，用来说明它的名称和适用场景：

---
name: loop-stop
description: "Brief a long-running agent or loop properly and know when to stop it. Use when launching or watching a subagent, a sweep or any repeating task."
---

要看的是 description 那一行：它把使用时机限定在启动或观察子 agent、扫描任务及其他重复任务时。真正的停止规则并没有出现在这段代码里，而是在原文正文和另行提供的完整文件中。

标题称它是一个「15 行 skill」，正文称三十秒就能读完，但输入没有展示完整文件，无法核对总行数。文章也没有解释，agent 是否一定会加载并遵守它，或超预算时有没有外部机制中断执行。

作者另外提到一个包含七个 skills 的付费包，涉及换一种路径核验「完成」、长任务前设置额度预算、每日交接报告，以及跨会话的文件记忆。这些属于配套介绍，不能当成免费规则已经验证有效的证据。

我的判断

这套方法说得对的地方，是把停止条件放到了执行之前。失败发生后再决定要不要提高额度，很容易因为「已经花了这么多」而继续投入。

但它仍是单项目经验。作者明确表示，没有测量其他项目上的节省效果，也不承诺结果。文章没有提供采用前后的 token、耗时或成功率对照，因此不能据此判断能省多少。

「两次没进展就停」也需要任务语境。等待异步构建或外部任务时，两次状态相同未必异常；原文没有给出检查间隔和进展指标。使用前要补上这两个定义，否则规则可能过早终止正常工作。

与命令超时、最大重试次数相比，文字规则能表达更复杂的判断；外部限制则能更确定地中断执行。我的取舍是把 skill 用作行为约定，同时为无人值守任务保留可执行的预算和超时限制。

能拿来做什么

• 启动前端或 Node 长任务前，写下目标、原因、可修改目录和预算，并明确什么结果算完成。
• 让 agent 修复构建失败时，要求第二次出现同一错误后先解释原因及下一步变化，再决定是否重试。
• 对重复扫描任务约定进展指标和检查间隔，避免把「又检查了一遍」当成有效产出。
• 在结果跟进中记录每轮修改理由，最多三轮，并在第三轮明确采用或舍弃；遇到 git 冲突或文件锁则先处理阻塞。