别只学 Prompt 了，下一步是设计 Loop

告别单纯学习 Prompt，下一步的关键在于构建 Loop 工作流

最近读到 Addy Osmani 的一篇文章，标题是《Loop Engineering》。他的判断非常直接：AI 编程的下一个阶段，不是继续优化 prompt，而是设计能够持续驱动 agent 运转的循环系统（loop）。

先给出结论：这一方向值得深入关注，但千万不要误以为“人类终于可以退出开发流程了”。

恰恰相反。Loop Engineering 不是要淘汰工程师，而是将工程师的职责从逐轮手动操作，升级为系统架构设计、边界定义、验证与复核。

1. Addy 这篇文章的核心内容

以往使用 coding agent 时，多数场景仍是聊天式交互。

给 agent 一个 prompt，它返回一版结果。你查看后补充上下文，再让它修改。整个过程是一轮一轮的手动衔接，人始终掌控着方向盘。

Addy 提出的 loop 是另一种架构：设计一个小型系统，让它自主发现任务、分配任务、检查结果、记录状态，并决定下一步行动。

这并非单次 agent 运行，而是一个持续循环。

例如：每天早上自动扫描昨日的 CI 失败记录、issue 列表以及最近的 commit，将值得处理的事项整理成 Markdown 或 Linear 中的文档；针对某个问题创建独立 worktree，让一个 agent 草拟修复方案，另一个 agent 按照测试规范和项目规则进行检查；最后将结果、失败原因以及下一步计划写回状态文件。

关键不在于“agent 完成了一次任务”。

重点在于：这套流程明天还能自动继续执行。

2. Loop 与 Prompt 的本质差异

Prompt engineering 解决的是单次交互的质量问题。

你需要清晰描述目标、补充充足上下文、明确约束条件。它很重要，也不会消失。

但 Loop Engineering 解决的是另一个问题：重复性任务如何稳定、可靠地自动发生。

它关心的不仅是“这次如何让 agent 做得更好”，而是：

因此，loop 比 prompt 更像一个工程化系统。

它不是一段冗长的提示词，而是一套具备输入、输出、边界、状态和验收标准的工作流。

3. 一个可用 loop 的六个核心组件

构建一个可运行的 loop 需要六大关键要素

Addy 将 loop 拆解为若干部件，可归纳为六个核心维度。

第一，心跳机制（Heartbeat）。

即自动化触发条件。可以是每天定时运行、CI 失败时触发、或某个 issue 进入特定状态时激活。没有心跳，就只是手动执行的一次 agent 调用。

第二，隔离环境（Isolation）。

也就是 worktree 或隔离目录。当多个 agent 并行工作时，文件冲突不可避免。worktree 解决了物理碰撞问题，让每个 agent 在自己的分支和目录中独立操作。

第三，项目知识（Project Knowledge）。

即技能规则（skill）。不要每次都重新解释项目如何构建、测试如何运行、哪些模式被禁用。将这些写入 SKILL.md 文件中，让 agent 每次从固定规则出发。

第四，连接器（Connectors）。

loop 不能只盯着文件系统。它需要能够读取 issue、CI、PR、文档、监控和通知工具。否则它只能告诉你“我该怎么做”，而无法融入真实工作流。

第五，检查器（Checker）。

也就是子 agent 或独立验证器。负责编写代码的是“制造者”（maker），检查代码的是“验证者”（checker）。不要让同一个模型生成代码后又自我评估“我觉得完成了”。这种做法风险极高。

第六，记忆系统（Memory）。

即状态文件。可以是 Markdown、Linear 或数据库。关键是要让状态持久化，超越单次对话，记录已完成、失败原因以及下次从哪里继续。

这六项整合起来，才构成一个真正有效的 loop。

4. 为什么工程师的角色反而更重要

很多人听到 loop 后会本能地认为：那以后是不是可以完全放手了？

这是最危险的误解。

loop 会放大能力，同样也会放大错误。一个糟糕的 prompt 只错一次，而一个糟糕的 loop 会按节奏反复出错。一个缺乏验证的 agent 偶尔乱改，而一个没有验证的 loop 会持续将错误推向更远的地方。

Addy 在文章后面提到的几个风险，值得我们重点关注。

第一，验证依然是你的责任。

loop 输出“完成”字样，只是一个系统状态，并不等于质量事实。测试是否通过、边界是否覆盖、代码是否真正符合业务目标，这些都不能因为 agent 说完成了就算完成。

第二，理解债会不断累积。

agent 写代码越快，你越不去阅读代码，你对系统的理解差距就会越大。短期看似省事，长期则会让你退化为只会按按钮的操作员。

第三，认知投降会变得更加隐蔽。

在单次 prompt 场景中，你还能明显感知到自己在做判断；而当 loop 运行顺畅后，你很容易默认接受它的输出。表面上效率提升了，实际上工程判断力在下降。

所以 Loop Engineering 的核心，不是把工程师移除，而是将工程师的判断力写入系统之中。

你需要定义触发条件、上下文来源、执行边界、验证规则、状态记录以及人工复核节点。

这比写 prompt 难度更高。

5. 普通开发者如何开始实践

不要从全自动修复 bug 起步，先搭建一个小型闭环

如果你想现在尝试 loop，建议不要直接挑战“全自动修复 bug”这种高难度任务。

从一个很小的 loop 开始。

例如：每天早上自动扫描昨天失败的测试和新提交的 bug issue，整理成一份 triage.md 文档。这个 loop 不直接修改代码，只负责发现问题和分级。

跑顺之后，再增加第二步：

从 triage.md 中挑选一个任务，让 agent 在独立 worktree 中尝试修复。

然后添加第三步：

由另一个 agent 或脚本运行测试、检查 diff、按照项目 skill 规则进行代码 review。

最后增加第四步：

将结果写回 triage.md：已尝试、通过状态、失败原因、下一步建议。

这个 loop 非常朴素，但已经包含了关键结构：

完成这个闭环后，再考虑更复杂的自动化方案。

6. 推荐哪些人现在开始实践

Loop 既能放大能力，也能放大风险

需要谨慎给出建议。

第一类，是已经稳定使用 Codex、Claude Code、Cursor 等工具的开发者。你已经了解 agent 能做什么，也清楚它容易在哪些地方犯错。

第二类，是拥有完善测试和 CI 流程的团队。没有基本的验证体系，不要急于搭建无人值守的 loop。

第三类，是已经沉淀了 issue、PR、文档和项目规范的小团队。loop 依赖外部状态和项目知识，空白项目很难跑出稳定收益。

不推荐给两类人。

第一类，是还没有养成阅读代码习惯的人。loop 会加速你对系统理解的丧失。

第二类，是缺少质量门禁的团队。没有代码 review、没有回滚机制，loop 只会让风险更快扩散。

7. 总结

Prompt engineering 尚未终结，但它已经不再是全部。

下一阶段的 AI 编程能力，将越来越像系统设计能力：你是否能把触发、上下文、工具、隔离、验证、状态以及人的判断，组合成一个可以重复运行的 loop。

需要特别强调：loop 不是逃避理解的工具。

同一个 loop，在懂系统的人手中是杠杆；在不想理解系统的人手中，则是风险。

所以，你可以开始设计 loop。

但要像一个仍然打算继续做工程师的人那样设计它。

不是按下按钮就离开，而是把你的工程判断力写进循环之中。