别再手写提示词：Loop 工程14步

先看这张 14 步路线图

Loop 工程可以拆成三层：

第一层，先判断你到底需不需要 Loop。很多任务手动提示更快，硬做自动化只会多烧钱。

第二层，理解一个 Loop 的基本积木：自动化、Worktree、Skill、连接器、子 Agent。

第三层，把它做小、做稳、做安全：状态文件、最小可用 Loop、失败模式、理解债、安全边界。

这件事的核心，不是“提示词没用了”。提示词还在，只是它被放进了一个更高层的系统里。

真正的变化是：杠杆从“写提示词”上移到了“设计循环”。

第一部分：先判断你需不需要 Loop

01. Loop 工程，是把自己从“提示词工人”位置上替换掉。

过去两年，我们和代码 Agent 协作的主流程差不多是这样：写一个 prompt，给上下文，等它改代码，读 diff，再写下一个 prompt。

Agent 看起来很自动，但整个循环的发动机其实还是人。你负责判断下一步、补上下文、决定什么时候停。

Loop 工程要做的是：把这套“人推动 Agent”的流程，变成系统推动。

一个 Loop 会自己找任务、把任务交给 Agent、运行检查、记录结果，再决定继续、停止、升级给人类，或者开一个草稿 PR。你设计一次循环，后面由循环去提示 Agent。

这里可以记住一句话：你不是让 AI 替你想清楚一切，而是把你已经想清楚的流程固化下来，让它重复执行。

02. 做之前，先过 4 条硬条件。

Loop 不是万能加速器。它只有在四个条件同时满足时，才可能赚回来。

第一，任务要重复。如果一个任务只是偶尔做一次，写 Loop 的成本可能比手动提示更高。适合做 Loop 的任务，通常是每周都会出现的重复活：CI 失败分类、依赖升级、lint 修复、测试复现、issue 初稿。

第二，结果要能自动验证。Loop 必须有东西能在你不在场时拒绝坏结果。测试、类型检查、构建、lint、安全扫描都可以。没有自动门禁，你最后还是要坐回椅子上读每个 diff。

第三，预算要承受得住浪费。Loop 会重读上下文、重试方案、探索错误路径。它不只是“跑一次 prompt”，而是可能跑很多轮。一个没有预算上限的循环，实际消耗可能放大到你预期的 5-10 倍。对 token 免费或预算充足的团队，这很自然；对个人订阅用户，可能很快撞到限制。

第四，Agent 要有工程师的工具。它要能看日志、跑代码、复现问题、执行测试。没有这些工具，Loop 只是在黑箱里反复猜。

03. 谁适合做，谁应该先跳过。

真正适合 Loop 的，通常是三类人或团队。

第一类，是有大量重复、可机器检查工作的团队。比如持续测试排查、依赖更新、PR 风格修复、issue 到 PR 草稿。

第二类，是测试覆盖比较好的代码库。一个初级工程师能照着清单做，测试能拦住大部分错误，这种场景特别适合。

第三类，是已经习惯异步协作、多 Agent 工作方式的团队。Loop 在这里不是替代管理，而是把例行流程自动化。

应该跳过的也很明确：

• 个人用户在很紧的 token 预算下跑重型验证循环
• 没有自动测试、没有构建门禁的代码库
• 真正瓶颈是 review，而不是写代码速度的团队
• 一次性探索任务、架构判断、产品方向讨论

一个很现实的判断是：Loop 会产生更多代码。如果团队已经审不过来，它只会把 review 队列变长。

04. 具体任务再跑一次 30 秒检查。

4 条硬条件是战略判断，30 秒检查是战术判断。

拿到一个具体任务时，问自己 5 个问题：

1. 这件事至少每周发生一次吗？
2. 测试、类型检查、构建或 lint 能拒绝坏输出吗？
3. Agent 能运行它改的代码吗？
4. 有没有硬停止条件：轮次、时间、预算？
5. 合并、部署、依赖变化前有没有人类审核？

少一个，就先别做 Loop。

比较好的第一批 Loop：

• CI 失败分类：夜里扫失败，分出环境、偶发、真实 bug、依赖、基础设施问题
• 依赖升级 PR：每周扫更新，跑兼容测试，开草稿 PR
• lint 自动修复：PR 打开时自动修样式问题
• flaky test 复现：循环直到找到能稳定复现的理论
• 强测试代码库里的 issue-to-PR 草稿

不适合作为第一批 Loop：

• 架构重写
• 认证、支付、权限代码
• 生产部署
• 模糊产品需求
• 任何“完成”主要靠判断的任务

第二部分：Loop 的五块积木

05. 自动化，是 Loop 的心跳。

自动化决定 Loop 什么时候启动。它可以是定时任务，也可以是事件触发，还可以是“持续追目标”的循环。

放到具体工具里看：

Codex 里可以通过 Automations 配一个项目、一个 prompt、一个运行节奏，再选择本地 checkout 或后台 worktree。它发现有事就进 triage，没发现就归档。

Claude Code 里常见的是 /loop、桌面定时任务、云端 Routines，再配合 hooks 监听生命周期事件。

这里有两个概念要分开：

• /loop：按节奏重复运行，适合“每隔一段时间都检查一下”
• /goal：一直运行到你写的条件被满足，适合“测试全过再停”

真正有价值的地方，是 maker/checker 分离。写代码的 Agent 不应该也是判断完成的那一个。完成条件最好由独立检查器或客观命令验证。

06. Worktree，让并行不变成混乱。

一旦你同时跑多个 Agent，文件冲突马上出现。两个 Agent 改同一个文件，和两个工程师同时改同一段代码一样麻烦。

git worktree 的价值很简单：每个 Agent 有自己的工作目录和分支，共用同一个仓库历史，但互不踩文件。

Codex 的多线程工作方式天然适合这种隔离；Claude Code 也可以通过 worktree 或 subagent isolation 把不同助手放到不同工作区。

不过要注意：Worktree 只解决机械冲突，不解决 review 带宽。

你能并行跑 20 个 Agent，不代表你能同时看懂 20 个 PR。真正的上限，还是人类审核能力。

07. Skill，把项目知识写一次，每次运行都读。

没有 Skill 的 Loop，每一轮都在重新理解项目。它要重新猜目录结构、测试命令、代码规范、历史坑、哪些文件不能碰。

Skill 的本质，是把这些项目知识沉淀到文件里。

一个好 Skill 至少包括：

• 任务分类规则
• 常见修复路径
• 项目命令
• 绝对不能做的事
• 状态更新方式

例如做 CI triage，可以写清楚：

• env：缺 secret、环境变量错、基础设施没起来，升级给人类
• flake：重跑能过，记录并观察
• bug：和最近改动相关、可复现，允许开草稿修复
• dependency：和版本升级相关，允许开回滚或兼容 PR
• infra：超时、OOM、runner 问题，升级

还要写禁区：不要禁用失败测试，不要随便改 CI 配置，不要碰支付和权限目录。

这就是 Loop 里的“项目记忆”。Agent 会忘，Skill 不会忘。

08. 连接器，让 Loop 进入真实工作环境。

只会看本地文件的 Agent，是一个很小的 Loop。

接上连接器之后，它才能进入真实工具链：读 GitHub、开 PR、更新 Linear、查 Sentry、发 Slack、访问测试环境 API。

最快回本的连接器通常是：

• GitHub：读仓库、建分支、开 PR、评论 issue、跟踪 CI
• Linear/Jira：更新 ticket，链接 PR，关闭已验证任务
• Slack：发送 triage 结果，升级需要人类看的问题
• Sentry/错误追踪：调查高频线上错误，生成修复草稿

连接器让 Loop 不只是“告诉你该怎么做”，而是真的进入你的工作流，把动作做到下一步。

但连接器也意味着权限。权限越大，越要有审计和边界。

09. 子 Agent，让做事的人别自己批自己的卷子。

Loop 里最有用的结构之一，就是 maker 和 checker 分开。

一个 Agent 写代码，另一个 Agent 检查。更重要的是，最终还要有测试、构建、lint 这些客观门禁。

这和 Anthropic 提到的 evaluator-optimizer 模式很像：一个模型生成，另一个模型评价和反馈，然后迭代。

在 Loop 里，这个结构更重要，因为它往往发生在你不盯着屏幕的时候。

不过子 Agent 不是越多越好。每一个子 Agent 都会消耗上下文、推理和 token。把它们用在真正值得二次确认的地方：安全检查、复杂 diff review、失败原因分类，而不是每一步都开一堆助手。

第三部分：怎么把 Loop 做小、做稳

10. 状态文件，是整个 Loop 的脊梁。

这一步看起来很土，但非常关键。

Agent 默认会忘。今天学到的东西，明天不一定还在。Loop 如果没有外部状态，就会每次从零开始。

一个 STATE.md 可以记录：

• 上次运行时间
• 失败分类
• 已经开了哪些分支或 PR
• 哪些问题升级给人类
• 哪些测试通过了
• 哪些经验下次要记住

它也可以放在 Linear、GitHub Issue、数据库里。重点不是格式，而是状态要活在对话之外。

更长的 Loop，还应该配一个高层规则文件，比如 VISION.md、AGENTS.md 或项目约束文档。状态文件告诉 Agent “现在在哪”，规则文件告诉它“要往哪去”。

11. 最小可用 Loop：四件事就够了。

第一次做 Loop，不要一上来就搞多 Agent 大工程。

最小可用 Loop 只需要四件事：

第一，一个自动化触发器。比如每天早上运行一次，或者 CI 失败时运行一次。

第二，一个 Skill。把任务规则、项目上下文、禁区写进去。

第三，一个状态文件。让明天的运行接着今天的结果继续，而不是重新猜。

第四，一个门禁。测试、类型检查、构建、lint，必须至少有一个客观命令能失败它。

顺序也很重要：

先手动跑通一次。再把经验写成 Skill。然后包进 Loop。最后再排程。

别反过来。手动都跑不通，自动化只会把混乱放大。

这里还有一个好指标：cost per accepted change，每个可接受改动的成本。

不要只看花了多少 token，也不要看尝试了多少任务。真正要看的是：这些 Loop 产出的改动，有多少最后被你接受了。

如果可接受率低于一半，你可能没有省下 review 工作，只是把 review 垃圾变多了。

12. Ralph Wiggum Loop：最安静的失败。

有一种 Loop 失败方式很阴险：它不是报错，而是提前宣布完成。

一个 Agent 本来应该在真正完成时输出结束信号，但它半途就说“完成了”。Loop 收到信号就停，留下一个半成品。

这类问题通常有三个原因：

• 没有真实验证器，只是另一个 Agent 口头 review
• 完成条件太软，比如“看起来不错”
• 没有硬停止，跑到外部限制或人类发现为止

修法也很明确：用客观门禁。

测试过没过，构建成没成功，类型检查有没有错误，lint 是否为零。这些东西比“我觉得完成了”可靠得多。

另一个相关问题是目标漂移。长会话不断摘要，约束会慢慢丢失。解决办法是让 Agent 每次运行都重新读高层规则和状态文件。

第四部分：坑在哪里，怎么不失控

13. 理解债和认知投降。

Loop 越有效，越容易带来两个非技术问题。

第一个是理解债。

Loop 产出代码越快，你和仓库真实状态之间的距离就越大。短期看，你省了时间；长期看，某天你要调试一个没人真正读过的系统。

最贵的账单，不一定是 token 账单，而是“没人理解这段代码为什么存在”的账单。

第二个是认知投降。

当 Loop 一次次给出看起来合理的结果，人会越来越容易停止形成自己的判断。它说测试过了，你就信；它说可以合并，你就点。

这很危险。

缓解办法不是再加一个更聪明的 Agent，而是保留工程纪律：

• 读 diff
• 抽查门禁是否真的覆盖风险
• 禁止 Loop 做架构判断
• 重要 Loop 设计时让另一个人一起看

Loop 可以自动执行，但工程判断不能自动外包。

14. 安全税：无人值守的 Loop，也是无人值守的攻击面。

Loop 一旦无人值守运行，就成了新的攻击面。

至少要考虑四类风险：

第一，生成代码未经充分 review 就合并。如果没有 SAST、依赖审计、secret scanning 这些安全门禁，Loop 可能把不安全代码送进仓库。

第二，Skill 变成注入入口。社区 Skill、外部规则文件、自动安装的工具，都可能藏 prompt injection 或不安全脚本。一些审计样本里，确实出现过技能泄露凭据的问题。别自动安装来源不明的 Skill。

第三，日志泄密。长时间运行的 Loop 很容易把调试信息、token、环境变量、请求体写进日志。生产 Loop 要关闭过度 verbose 的日志，并清洗敏感字段。

第四，权限慢慢膨胀。一开始只是读权限，后来为了方便给了写权限，再后来能改 CI、发 PR、动依赖。每加一次权限，都要重新审计。一个实用习惯是：每 30 天复查一次 Loop 的权限。

最后，把常见钱坑合成一张清单：

• 没有跑 4 条硬条件测试
• 没有客观门禁
• 写代码和验证由同一个 Agent 完成
• 没有状态文件
• 停止条件模糊
• 没有 token 或时间上限
• 在消费级额度上跑重型循环
• 自动安装社区 Skill
• 让 Loop 做架构、支付、权限、产品判断
• 不读 diff

这些坑的共同点是：你把判断交出去了，却没有设计足够清楚的边界。

一条可以照着改的 Loop 模板

如果你想今天就开始，建议从 CI triage 或 lint 自动修复这种小任务做起。

不要让它自动合并。让它只做四件事：发现问题、尝试修复、跑检查、开草稿 PR 或写状态报告。

可以从这样的提示词开始：
每天检查 CI 失败。先读取失败日志，把问题分类为 env、flake、bug、dependency、infra。只为可复现 bug 和明确 dependency 问题创建草稿 PR。每次修改后运行测试、类型检查和 lint。禁止删除测试，禁止跳过断言，禁止修改支付、权限和部署配置。把本次检查结果、已尝试方案、升级给人类的问题写入 STATE.md。最多 3 轮，仍未通过就停止。

场景选择可以这么判断：

场景	适合程度	原因
lint 自动修复	很适合	规则清楚，门禁明确
CI 失败分类	适合	可以先分类、草稿修复、升级
依赖升级 PR	适合	测试能验证兼容性
flaky test 复现	适合	可以循环验证假设
架构重写	不适合	判断太多，完成条件太软
支付/权限代码	不适合	风险高，需要强人工审核

我自己的建议是：第一条 Loop 要无聊一点。

它越无聊，越重复，越能被机器检查，越适合作为起点。

JOTO 企业落地观察

• Loop 工程对企业智能体工程的核心启示在于：必须将‘人机协同节奏’显式建模。企业不应默认所有任务都适合闭环自动化，而应基于任务重复频率、验证确定性、工具链完备度三维度建立准入评估矩阵——这直接决定了智能体工程投入的ROI边界。
• Loop 对企业 RAG 知识工程提出新要求：Skill 文件本质是结构化项目知识库，需支持版本化、权限管控与变更审计。企业若缺乏统一的知识治理机制，Skill 将迅速退化为不可维护的‘提示词沼泽’，反而加剧知识熵增。
• Loop 的状态文件（如 STATE.md）暴露了企业 AI 安全治理的关键盲区：当前多数企业未将 AI 运行态数据纳入合规审计范围。无人值守 Loop 的日志、中间状态、决策依据必须满足 GDPR/等保三级要求，否则将成为新型数据泄露通道。
• Loop 工程对企业 FDE（驻场共创）服务模式产生结构性影响：首批 Loop 落地必然发生在 CI/CD、代码规范等‘低认知负荷、高确定性’环节，FDE 团队需前置介入客户 DevOps 流程梳理，而非仅提供模型调优——这要求驻场工程师兼具工程流程建模与 AI 系统可观测性双重能力。