速读#
我用自定义 /goal 命令和 Claude Code 的 Stop hook，连续处理了 39 篇博客。真正省下来的不是写作本身，而是“下一篇做什么、还剩多少、什么时候允许停止”这部分调度成本。跑完后我的判断是：Loop Engineering 适合目标可枚举、步骤可重复、结果可验证的任务；如果验收标准模糊、没有预算和停滞检测，它只会更快地消耗 Token，并把错误连续复制下去。
文章数从 0/39 变成 39/39 只能证明覆盖完成，不能证明 39 篇都写得好。质量仍然需要明确的审稿规则、自动检查和人工抽样。这也是我这次最大的修正：Loop 可以负责持续推进，但不能顺便替我宣布结果可信。
我为什么拿 39 篇文章试 Loop#
2026 年 6 月，Anthropic 的 Boris Cherny 和 OpenClaw 的 Peter Steinberger 都在讨论相近的工作方式：不要再把精力全部花在逐轮 Prompt Agent 上，而要设计能够持续给 Agent 分配下一步工作的 Loop。Addy Osmani 在 Loop Engineering 中整理了这组说法，也把重点从单次提示词推进到了目标、反馈和循环控制。
我没有把它理解成 Prompt Engineering、Context Engineering 或 Harness Engineering 的替代品。一次可靠执行仍然需要清楚的指令、足够的上下文和稳定的工具环境，Loop 只是在外面增加一层控制：本轮结束后由什么判断任务是否完成，未完成时怎样生成下一步，什么时候必须停止并交还给人。它解决的是持续调度问题，不会自动修复内部指令和验证机制的缺陷。
正好我手里有一批 39 篇旧文章需要二次加工：逐篇检查结构、技术边界、重复内容和表达方式，再按统一标准修改。这个任务数量明确、步骤相似，而且每完成一篇都能留下文件和清单记录，很适合测试 Loop；它又没有生产发布、删库或外部消息等不可逆副作用，即使中途跑偏，也可以通过 Git diff 找回问题。
/goal 与 Stop hook 实际组成了什么#
我使用的 /goal 不是一句“请一直做完”的魔法提示，而是一个自定义目标入口：记录总目标、文章清单、当前状态和下一项工作。Claude Code 的 Stop hook 会在 Agent 准备结束时运行，我让它读取状态并执行控制判断。它本身就是 Loop 里的调度与停止逻辑，因此不能说这套方案“没有调度器”；更准确的说法是，我没有另外维护常驻服务或独立队列，而是把轻量调度嵌进了目标文件和 hook。
整个过程可以压缩成下面这条控制流：
/goal 写入目标、清单和状态 -> Agent 执行一轮 -> Stop hook 检查验收条件 -> 已完成：允许停止 -> 超过迭代、时间或预算，或持续无进展：停止并交还给人 -> 未完成且仍有进展：阻止停止，提交下一项任务这里至少有五个不可省略的部分：触发器决定什么时候开始；状态记录告诉下一轮已经完成什么；行动集合限定 Agent 能读写哪些文件、能运行哪些检查；验收规则判断结果是否成立；停止规则处理预算耗尽、持续停滞和高风险动作。Harness 提供单轮执行所需的工具、权限与上下文，Loop 则利用这些能力反复推进并反馈结果，两者是配合关系，不是非此即彼。
这次为什么跑得动#
39 篇改造能持续推进，首先因为任务可以枚举。每篇文章都有固定路径，清单从 0/39 递增到 39/39，因此“是否全部处理过”可以被机器检查。其次，单篇工作大致重复：读取原文、找出问题、修改、检查 front matter 和链接、更新清单。Loop 不需要每轮重新发明工作方法，只需要把同一套流程应用到下一篇。
它给我最直接的帮助，是把“接下来该处理哪篇”从脑子里搬到了状态文件。手工处理长清单时，我会不断确认剩余数量、顺序和上次停在哪里，这些动作不难，却会持续切走注意力。Loop 接管后，我更集中在技术判断上：文章里的结论有没有依据，配置能不能复现，故障原因和证据是否匹配，限制条件有没有被藏起来。工作没有消失，只是从逐轮催促转成了维护目标、规则和例外。
不过，39/39 只是覆盖率。它不能判断一篇文章是否准确，也不能证明改写后更有价值。我的审稿清单能检查“有没有说明为什么、有没有给出验证步骤、有没有讨论失败和边界”等结构要求，构建与链接检查可以验证站点是否还能正常生成；技术结论仍需要查资料、运行命令或人工复核，文风和内容取舍也需要抽样阅读。可计数目标适合作为停止条件，但不能冒充完整的质量指标。
验证不能只听 Agent 自己说完成#
最弱的验证方式，是让执行修改的 Agent 在同一上下文里回答“你是否已经完成”。它知道自己刚做了什么，也容易沿用上一轮的假设，最后把“我写过了”当成“结果正确”。把审稿任务换成另一次同模型调用会增加一次检查机会，却不天然等于独立验证：如果两次调用共享错误前提、相同资料和相似评分倾向，第二次仍可能重复第一次的结论。
更可靠的做法是把不同问题交给不同证据。文件清单和 Git diff 验证处理范围；构建、链接检查和格式校验验证机械正确性；引用原始文档、实际执行配置和故障注入验证技术结论；统一评分规则加人工抽样判断文章是否真的清楚。对于高风险任务，还应让验证读取结果而不是执行者的自述，并尽量使用独立数据、确定性测试或另一个具备反驳任务的审查上下文。
这也解释了为什么 Loop 的质量上限不只取决于模型。模型会放大它收到的反馈：反馈是测试结果，它会朝测试通过推进；反馈只是“看起来不错”，它就会围着模糊标准继续生成。与其争论一个固定比例的成败因素，不如承认终止条件、验证信号和执行能力共同决定结果，任何一项太弱都可能让循环空转或过早结束。
长循环必须先装刹车#
这次任务有 39 篇这个天然上限，文件修改也能通过 Git 回看，所以风险相对可控；如果把同一结构用于代码部署、批量删除、数据库迁移或外部通知，我不会让它裸跑。至少要在启动前规定最大迭代次数、最长运行时间和 Token 或费用预算，并记录每轮完成项、失败原因和关键输出。连续几轮没有新增完成项、重复修改同一文件或重复出现同一错误时，应当判定为停滞，而不是继续用更多轮次赌一次偶然成功。
可恢复性同样重要。每完成一组工作就保留可审查的 Git 检查点，高风险命令继续要求人工批准，Loop 不得因为目标尚未完成而绕过权限边界。遇到验收规则冲突、资料不足或需要改变任务范围时，应停止并把证据交给人，而不是自行扩张目标。自动继续是一种控制策略，不是获得无限权限的理由。
我现在会在启动前先写清楚四件事：怎样算完成，怎样证明完成，什么状态算无进展，哪些动作必须由人批准。只有第一项的 Loop 看似能跑，实际上没有质量保证和退出通道；四项都明确后，它才更接近一个可以托付重复劳动的工程流程。
跑完后的判断#
Loop Engineering 对我最有用的部分，不是一个新名词，而是一条任务选择标准：当目标可验证、过程重复、状态能持久记录时，可以把持续调度交给 Loop，把例外处理和质量判断留给人。39 篇文章改造符合这种形状，所以 /goal 加 Stop hook 的轻量实现已经够用，没有必要先搭一套常驻调度服务。
反过来，“写一个让我惊喜的功能”“把系统改得更优雅”这类目标没有稳定终点，直接套循环通常只会制造更多改动。即使任务可枚举，只要一次错误可能批量扩散，也应降低自动化范围、增加抽样频率或逐步放权。Loop 不会让工程判断消失，它只是把判断的位置提前到了目标、反馈、权限和刹车的设计上。
我最终保留下来的工作方式很简单：先把任务改写成可检查的清单，让每轮产生可以观察的增量，再用外部证据决定继续还是停止。Loop 负责不厌其烦地往前推，人负责定义什么值得推进，以及什么时候必须踩下刹车。