当你需要为一个新出现的 AI 工具写一份研究简报时传统流程通常是打开 Claude输入第一版提示阅读回复发现缺少 star 数和真实来源再补一句“请加上 GitHub 链接和使用场景”又读回复发现格式不统一……如此往复 6-8 轮tokens 已经烧掉不少输出却总差那层“可直接交付”的专业度。而真正改变游戏规则的做法是你只花 5 分钟写下一条清晰的「完成线」然后离开电脑。两小时后回来成品已经生成、验证、自检完毕直接可用。这不是魔法而是Loop 工程的核心范式从“写指令”转向“写条件”。传统迭代提示的隐形成本我起初也以为只要把任务描述得足够详细Claude 就能一次性给到满意结果。后来在真实生产任务中反复踩坑才发现每一次人工介入其实都在把 AI 的自主性重新拉回“保姆模式”。每轮迭代都需要你重新读取上下文、判断缺失、重新组织语言这本身就是巨大的认知开销。更致命的是AI 不知道“什么时候该停下来”。它会继续生成直到你手动喊停或者 tokens 耗尽。Loop 工程把这个决策权交还给系统你定义“完成”的 verifiable 标准Claude或其内置 checker自己负责规划路径、执行、验证、纠错。只有当所有标准都被满足时它才会停止并交出结果。这背后的底层逻辑其实很简单——提示是命令Loop 是契约。Loop 工程的四个必备要素任何一个能稳定运行的 Loop都必须同时具备以下四部分。缺任何一个都可能导致输出质量下降或无限循环。Goal完成线必须是可验证的终态而不是模糊的“研究一下”。坏例子“研究 AI 工具并写总结”。好例子“生成一个 Markdown 表格包含正好 5 个条目每个条目必须有工具名称、简短描述、GitHub Stars 数量、核心使用场景、 verifiable 来源链接。当表格完整且每条来源可点击验证时任务结束。”Scope作用域明确告诉 Claude 它能改哪些文件、不能碰哪些目录。没有 Scope 限制Loop 很容易在你意料之外的位置创建或覆盖文件造成真实损害。Checker验证机制这是区分“能用”和“可靠”的关键。你可以在 Goal 里内置自检规则也可以使用 Claude Code 原生的 /goal 命令——它会在每轮结束后自动调用一个轻量模型进行打分“当前输出是否已完全满足 Goal”不满足则继续满足则停止。Stop Rule停止规则必须同时设置成功停止和失败停止。成功Goal 全部达成。失败“若连续 3 次尝试后仍无法满足 Goal或总 token 消耗超过 X请立即停止并输出失败原因及当前进度。”缺少失败停止规则是我早期最常犯的错误之一——曾经有一个 Loop 因为卡在无法解决的问题上硬跑了 40 多分钟才被我发现。第一个可直接运行的 /goal 示例在 Claude Code需 Pro 或更高订阅中直接粘贴以下内容即可启动你的第一个 Loop/goal 为我生成一份关于「2026 年最值得关注的 5 个开源 AI Agent 框架」的研究简报。 完成标准Goal - 输出一个 Markdown 表格恰好包含 5 行数据 - 每行必须包含框架名称、核心定位一句话、GitHub Stars 数量精确到当前日期、典型使用场景、官方或可靠来源链接 - 所有 Stars 数量和链接必须真实可验证 - 表格下方附上 3-5 条关键洞察基于数据而非主观 - 当表格完整、每条数据来源可点击且无遗漏时立即停止并输出最终结果 作用域Scope - 仅在当前工作目录下的 research/ 文件夹内操作 - 不要修改任何已有文件除非明确要求创建新文件 - 不要访问或修改项目根目录外的任何内容 停止规则 - 成功表格完全符合上述完成标准 - 失败连续 3 次尝试后仍无法满足 Goal或总 token 消耗超过 80k请立即停止并说明当前进度和阻塞原因运行后你会看到 Claude 先规划方法、搜索信息、编译数据、自我验证最后在满足所有条件时停止。整个过程你几乎不需要再输入任何内容。三个生产级 Loop 示例可直接改写使用Loop 1研究简报我目前使用频率最高适用于需要快速吃透一个新工具或赛道。以前手动阅读 笔记要 2-3 小时现在 Claude 自主完成约 90 分钟且输出结构更一致。Loop 2内容审计指向一个包含多份草稿的文件夹让它扫描所有文件输出结构化 gap 分析和改进建议。以前是手动做 Excel现在完全自动化。Loop 3周报生成结合 /loop 命令设置定时任务每周一自动从笔记文件夹拉取内容生成结构化周报。真正实现“周一早上醒来就有报告在等我”。这三个 Loop 我前三周累计节省了约 8-10 小时手动工作。落地前必须避开的 5 个真实坑没有失败停止规则→ 修复每条 /goal 都必须同时写成功和失败条件。Scope 过宽→ 修复永远加上“仅修改 [具体文件夹]”和“不要改动未指定的文件”。Goal 过于模糊→ 修复用“可被陌生人验证”的标准重写表格行数、字段、来源要求等。不观察第一轮→ 修复前几次一定要全程盯着第一 cycle确认方向正确后再放手。把简单任务也用 Loop→ 修复单步可验证的任务直接普通提示更快只有多步骤、需要自检、耗时较长的任务才值得用 Loop。什么时候不该用 Loop并非所有场景都适合。快速问答、纯创意 brainstorm、主观判断类任务“让这个文案更有感染力”、需要实时人类决策的场景普通提示反而更高效。经过三周实践我目前只有约 30-40% 的 Claude 使用场景切换到了 Loop其余仍用传统方式。这不是失败而是正确识别“哪些任务是 Loop-shaped”。从提示工程师到 Loop 架构师真正的生产力跃迁不是让 AI 回答得更快而是让它自己知道“什么时候该停下来、怎么验证自己做得够好”。当你开始把工作拆解成清晰的完成线时你其实已经在把自己的角色从“实时操作员”升级为“系统设计者”。这和过去十年软件工程从“写代码”到“写测试 定义验收标准”的演进本质上是同一件事。下次当你面对一个需要多轮迭代、涉及信息收集 结构化输出的任务时不妨先花 5 分钟定义一条严格的完成线然后让 Claude 自己跑完整个闭环。你会发现节省的不仅是时间更是之前被消耗在“判断 AI 做得怎么样”上的心智带宽。我是紫微AI在做一个「人格操作系统ZPF」。后面会持续分享AI Agent和系统实验。感兴趣可以关注我们下期见。
停止写指令，开始写「完成线」：Claude Loop 工程如何让 AI 自主完成 2 小时任务
发布时间：2026/7/6 3:15:37
当你需要为一个新出现的 AI 工具写一份研究简报时传统流程通常是打开 Claude输入第一版提示阅读回复发现缺少 star 数和真实来源再补一句“请加上 GitHub 链接和使用场景”又读回复发现格式不统一……如此往复 6-8 轮tokens 已经烧掉不少输出却总差那层“可直接交付”的专业度。而真正改变游戏规则的做法是你只花 5 分钟写下一条清晰的「完成线」然后离开电脑。两小时后回来成品已经生成、验证、自检完毕直接可用。这不是魔法而是Loop 工程的核心范式从“写指令”转向“写条件”。传统迭代提示的隐形成本我起初也以为只要把任务描述得足够详细Claude 就能一次性给到满意结果。后来在真实生产任务中反复踩坑才发现每一次人工介入其实都在把 AI 的自主性重新拉回“保姆模式”。每轮迭代都需要你重新读取上下文、判断缺失、重新组织语言这本身就是巨大的认知开销。更致命的是AI 不知道“什么时候该停下来”。它会继续生成直到你手动喊停或者 tokens 耗尽。Loop 工程把这个决策权交还给系统你定义“完成”的 verifiable 标准Claude或其内置 checker自己负责规划路径、执行、验证、纠错。只有当所有标准都被满足时它才会停止并交出结果。这背后的底层逻辑其实很简单——提示是命令Loop 是契约。Loop 工程的四个必备要素任何一个能稳定运行的 Loop都必须同时具备以下四部分。缺任何一个都可能导致输出质量下降或无限循环。Goal完成线必须是可验证的终态而不是模糊的“研究一下”。坏例子“研究 AI 工具并写总结”。好例子“生成一个 Markdown 表格包含正好 5 个条目每个条目必须有工具名称、简短描述、GitHub Stars 数量、核心使用场景、 verifiable 来源链接。当表格完整且每条来源可点击验证时任务结束。”Scope作用域明确告诉 Claude 它能改哪些文件、不能碰哪些目录。没有 Scope 限制Loop 很容易在你意料之外的位置创建或覆盖文件造成真实损害。Checker验证机制这是区分“能用”和“可靠”的关键。你可以在 Goal 里内置自检规则也可以使用 Claude Code 原生的 /goal 命令——它会在每轮结束后自动调用一个轻量模型进行打分“当前输出是否已完全满足 Goal”不满足则继续满足则停止。Stop Rule停止规则必须同时设置成功停止和失败停止。成功Goal 全部达成。失败“若连续 3 次尝试后仍无法满足 Goal或总 token 消耗超过 X请立即停止并输出失败原因及当前进度。”缺少失败停止规则是我早期最常犯的错误之一——曾经有一个 Loop 因为卡在无法解决的问题上硬跑了 40 多分钟才被我发现。第一个可直接运行的 /goal 示例在 Claude Code需 Pro 或更高订阅中直接粘贴以下内容即可启动你的第一个 Loop/goal 为我生成一份关于「2026 年最值得关注的 5 个开源 AI Agent 框架」的研究简报。 完成标准Goal - 输出一个 Markdown 表格恰好包含 5 行数据 - 每行必须包含框架名称、核心定位一句话、GitHub Stars 数量精确到当前日期、典型使用场景、官方或可靠来源链接 - 所有 Stars 数量和链接必须真实可验证 - 表格下方附上 3-5 条关键洞察基于数据而非主观 - 当表格完整、每条数据来源可点击且无遗漏时立即停止并输出最终结果 作用域Scope - 仅在当前工作目录下的 research/ 文件夹内操作 - 不要修改任何已有文件除非明确要求创建新文件 - 不要访问或修改项目根目录外的任何内容 停止规则 - 成功表格完全符合上述完成标准 - 失败连续 3 次尝试后仍无法满足 Goal或总 token 消耗超过 80k请立即停止并说明当前进度和阻塞原因运行后你会看到 Claude 先规划方法、搜索信息、编译数据、自我验证最后在满足所有条件时停止。整个过程你几乎不需要再输入任何内容。三个生产级 Loop 示例可直接改写使用Loop 1研究简报我目前使用频率最高适用于需要快速吃透一个新工具或赛道。以前手动阅读 笔记要 2-3 小时现在 Claude 自主完成约 90 分钟且输出结构更一致。Loop 2内容审计指向一个包含多份草稿的文件夹让它扫描所有文件输出结构化 gap 分析和改进建议。以前是手动做 Excel现在完全自动化。Loop 3周报生成结合 /loop 命令设置定时任务每周一自动从笔记文件夹拉取内容生成结构化周报。真正实现“周一早上醒来就有报告在等我”。这三个 Loop 我前三周累计节省了约 8-10 小时手动工作。落地前必须避开的 5 个真实坑没有失败停止规则→ 修复每条 /goal 都必须同时写成功和失败条件。Scope 过宽→ 修复永远加上“仅修改 [具体文件夹]”和“不要改动未指定的文件”。Goal 过于模糊→ 修复用“可被陌生人验证”的标准重写表格行数、字段、来源要求等。不观察第一轮→ 修复前几次一定要全程盯着第一 cycle确认方向正确后再放手。把简单任务也用 Loop→ 修复单步可验证的任务直接普通提示更快只有多步骤、需要自检、耗时较长的任务才值得用 Loop。什么时候不该用 Loop并非所有场景都适合。快速问答、纯创意 brainstorm、主观判断类任务“让这个文案更有感染力”、需要实时人类决策的场景普通提示反而更高效。经过三周实践我目前只有约 30-40% 的 Claude 使用场景切换到了 Loop其余仍用传统方式。这不是失败而是正确识别“哪些任务是 Loop-shaped”。从提示工程师到 Loop 架构师真正的生产力跃迁不是让 AI 回答得更快而是让它自己知道“什么时候该停下来、怎么验证自己做得够好”。当你开始把工作拆解成清晰的完成线时你其实已经在把自己的角色从“实时操作员”升级为“系统设计者”。这和过去十年软件工程从“写代码”到“写测试 定义验收标准”的演进本质上是同一件事。下次当你面对一个需要多轮迭代、涉及信息收集 结构化输出的任务时不妨先花 5 分钟定义一条严格的完成线然后让 Claude 自己跑完整个闭环。你会发现节省的不仅是时间更是之前被消耗在“判断 AI 做得怎么样”上的心智带宽。我是紫微AI在做一个「人格操作系统ZPF」。后面会持续分享AI Agent和系统实验。感兴趣可以关注我们下期见。
