15 个正在被实用的 AI 循环命令
AI 编程里的 loop、goal、schedule 很容易混用。这里整理 15 个可直接改造的循环命令，保留关键代码，并去掉人物和第一人称叙述。
AI 编程工具里，最近被反复讨论的是 loop：让智能体持续执行、检查、修正，直到达到某个条件。
这类玩法容易被说得很玄，其实可以拆成三种命令：/goal、/loop、/schedule。区别搞清楚，后面的 15 个模板就好理解了。
先分清三个命令
/goal <condition> 适合“做到某个可验证结果为止”。它会持续工作，直到条件成立，然后停止。典型场景是：修到测试通过、修到检查器不再报错、修到验收条件全部满足。
/loop <interval> <prompt> 适合“人在场时，按固定间隔重复一件事”。例如每 5 分钟检查部署状态、每 10 分钟清一个小任务。 Claude Code 有这个命令；Codex 当前更接近的做法，是用 codex exec 包一层 shell 循环，或者在 Codex App 里用 Thread Automation 。
/schedule <description> 适合“人不在场时也要跑”。它更像云端 routine，比如每天早上 9 点检查 PR 、每天晚上扫一遍错误日志。 Claude Code 里是 /schedule，Codex 里对应 App 里的 Automations 。
容易踩的坑是把它们混成一个东西。没有通用的 /routine 命令。要做短时重复，用 /loop；要做有终点的任务，用 /goal；要做定时后台任务，用 /schedule。
1. 构建-测试-修复循环
这是最常见的代码循环：一个智能体写代码，另一个检查测试、类型和 lint 。每轮失败结果都会反馈回去，直到构建变绿。
/loop build the next item on the plan, then run tests, typecheck, and
lint. Feed every failure back as the next instruction and fix it. Stop
when the build is green and the checker has nothing left to report.
适合场景：小功能、重构、补测试、修 lint 。关键在于给代码生成配一个明确的检查器。
2. 独立验证器循环
很多循环会失败，是因为写完后自己给自己打分。更稳的做法是把执行者和验证者拆开：一个模型干活，另一个模型按规格和测试验收。
/loop work the task list. After each task, have a separate verifier model
check the result against the spec and the tests. Only move on when it
passes. Surface anything the verifier rejects twice.
如果验证器连续两次拒绝同一个结果，就不要继续硬跑，应该把问题暴露出来，让人处理规格、测试或实现方向。
3. loop-engineer 启动模板
有些团队不想从零搭循环框架，可以直接克隆现成模板。它把代码库 harness 、知识模板、构建、观察、验证和停止条件放在一起，适合先跑通一个最小版本。
git clone https://github.com/JayZeeDesign/loop-engineer-template
这类模板的价值在于少搭脚手架。真正上线前，仍然要改成适合本仓库的测试、日志、预算和停止条件。
4. 五分钟仓库维护循环
这个循环适合工作时挂在旁边：每五分钟做一个小的、可验证的仓库维护任务。比如修一个 flaky test 、补一个类型、清一段过期注释。
/loop 5m make one small verified repository improvement: a flaky test, a
stale comment, a missing type. One change, one commit, tests green. Never
touch anything risky.
注意这里限制得很窄：一个小改动、一个提交、测试通过、不碰高风险代码。范围越小，循环越不容易失控。
5. 计划-生成-验证-修复循环
这是 /goal 更适合的用法：先计划，再实现，再验证，再修复。为了避免无限循环，要把迭代次数写死。
/goal plan the task, implement it, verify against the tests, and fix what
failed. Save state to files each pass. Max 5 iterations. Stop at the first
clean pass or when the cap is hit, and report which condition stopped the run.
“最多 5 轮”很重要。没有上限的循环，最后常常修不好问题，只会把 token 烧完。
6. 提交后代码审查循环
roborev 是一个开源代码审查工具，可以把审查放进 git hook 。每次提交后自动触发后台 review，再把发现的问题交给修复循环。
roborev init # adds a post-commit hook: every commit triggers a review
roborev fix # the agentic loop that fixes the surfaced findings
这种模式适合保持上下文热度。代码刚改完，错误、意图和相关文件还很近，修复循环更容易命中问题。
7. 目标澄清循环
很多失败来自目标太模糊。这个模板先把请求改写成严格目标：结果是什么、如何验证、不能碰哪里、何时停止。
/goal before doing anything, rewrite the request into a precise goal: the
exact end state, how it will be verified, what must not be touched, and the
stop condition. Confirm that goal, then execute against it.
适合交给智能体之前先跑一遍，尤其是需求含糊、范围可能变大的任务。
8. 邮件处理 routine
这是生产型 routine 的典型形态：定时拉取邮件，分类、起草回复，只把敏感事项升级给人工。
/schedule every 15 minutes, pull new guest emails, classify each, and
draft a reply for the routine ones. Queue anything sensitive for operator review and
log every decision. Never auto-send a refund or a booking change.
关键边界是“不自动发送退款或改订单”。后台任务最怕越权，敏感动作必须排队等人工确认。
9. 防空转循环
循环最常见的失败，是卡在同一个坏方案里反复试。防空转循环会检查几个停止条件：没有进展、重复路径、来回摇摆、超预算。
/loop build toward the goal, then audit and verify against a
machine-checkable contract. Stop if there is no progress, an approach repeats,
approaches flip-flop, or the budget is hit. Finish only when the contract passes.
这类循环适合复杂任务。只写“继续修直到好”为时过早，必须先定义机器可检查的 contract 。
10. 夜间 PR routine
这是 /schedule 的典型用法：晚上自动看开放 PR，修能自动修的构建失败，回复明确的 review comment，重放过期分支。
/schedule every night, watch open PRs. Auto-fix build failures, answer
review comments in a fresh worktree, and rebase what is stale. Leave
anything ambiguous for operator review. Persist state in git so a crash loses nothing.
适合成熟仓库。必须配套独立 worktree 、状态持久化和模糊事项升级，否则很容易把分支历史弄乱。
11. 人工审批队列循环
有些流程不能全自动，但可以半自动：任务跑完后暂停，通过 Telegram 或其他渠道发来 approve / revise / skip，让人工决定下一步。
/loop run the task, then pause and send approve / revise / skip on
Telegram before anything ships. On approve, continue. On revise, take the
review note and redo. On skip, move to the next item.
这类循环适合发布、运营、客服、内容审核。人工审核在这里是循环里的一个明确节点，不再只是事后救火。
12. 生产错误清扫 goal
这个模板适合每天或每晚扫生产错误。它要先区分真实可复现问题和噪音，再给可行动问题写修复和回归测试。
/goal review the last 24h of production errors. For each one that is
actionable and reproducible, write a fix with a regression test and open
a PR. Ignore transient and third-party noise. Done when the actionable
list is clear.
重点是定义 actionable 。没有这个词的边界，智能体会追着第三方服务抖动、偶发网络错误和无意义日志跑。
13. 连续通过质量循环
很多“测试通过”只代表一次运气。质量循环不在第一次绿灯时停止，而是要求连续多轮通过。
/goal run the full product test suite against realistic scenarios. Fix
whatever fails, then run again. A new failure resets the count. Done only
after 10 consecutive clean passes.
适合端到端测试、关键链路、复杂重构。一次 green 可以骗人，连续 streak 更接近可靠性。
14. 对抗式审查命令
这个命令的思路是让不同模型互相审查。一个模型写 PR，另一个模型在合并前审查，最多来回迭代 5 次，并设置通过阈值。
/clodex [task] think hard --max-iter 5 --threshold medium
--max-iter 5 和 --threshold medium 是核心。没有迭代上限和阈值，这类对抗式流程很容易变成无休止辩论。
15. 完成条件契约命令
很多智能体会在没完成时说 done 。这个工具先写一份“什么才算完成”的契约，列出每个需求需要什么证据，再按证据验收。
$goal-planner-codex [task]
这类命令特别适合需求拆解、产品改动和多文件重构。完成条件越清楚，循环越不容易误判完成。
被忽略的成本和验证
循环最容易被讲成“让一千个智能体通宵工作”。生产环境里，首先看到的通常是账单。每个 goal 都应该有预算，每个 loop 都应该有轮数或时间上限，每个 routine 都应该有日预算。
可以把预算直接写进条件里：
Stop after 8 turns, 30 minutes, or when estimated spend reaches the configured budget.
Report unfinished work instead of continuing silently.
第二个问题是验证。不会判断好坏的循环，只是在更快地产出错误。最强的循环都有第二套眼睛：测试、类型检查、独立模型、人工审批、生产日志，至少要有一种。
一个能落地的循环栈可以这样开始：白天跑构建-测试-修复 /loop，工作时跑五分钟仓库维护 /loop，晚上跑 PR routine /schedule。每个循环都带预算、验证器和停止条件。先小范围跑通，再扩大权限。
这波变化的核心并不复杂：不要只写一次性提示词，要写能重复执行、能检查结果、能知道何时停止的工作循环。循环本身不神奇，真正有价值的是验证器和边界。没有这两件事，自动化只会把错误放大。