从 Prompt 到 Loop Engineering：AI 编程正在进入“反馈系统”时代

前言

AI 编程的重点，正在从"如何写好一句 Prompt"，转向"如何设计一个能持续反馈、验证和迭代的系统"。

过去我们使用 AI 编程工具，大多是这样的流程：

我描述需求；
AI 生成代码；
我运行、报错、复制错误信息；
AI 再修；
我继续验证。

这其实还是一种"人肉循环"。AI 负责执行，人负责不断推动下一步。

而 Loop Engineering 想解决的问题是：能不能把这个循环也工程化？

也就是说，不只是让 AI 写代码，而是让 AI 在一个可控系统里自动完成：发现问题、制定计划、执行修改、验证结果、记录状态，并根据反馈继续迭代，直到满足明确的停止条件。

这就是我理解的 Loop Engineering：它不是一个新 Prompt 技巧，而是一种新的 AI 编程系统设计方法。

一、什么是 Loop Engineering？

Addy Osmani 对 Loop Engineering 的定义非常直接：

Loop Engineering 是用一个你设计的系统，替代你本人去提示 Agent。

换句话说，过去是"人提示 Agent"，现在变成"系统提示 Agent"。

这背后的变化非常关键：

阶段	关注点	典型问题
Prompt Engineering	怎么问 AI	提示词怎么写更清楚？
Context Engineering	让 AI 看什么	应该给 AI 哪些代码、文档和背景？
Harness Engineering	AI 在什么环境里工作	工具、权限、沙箱、规则如何设计？
Loop Engineering	AI 做完一步后怎么办	如何验证、修正、继续或停止？

Prompt Engineering、Harness Engineering 和 Loop Engineering 的区别

如果只看名字，这几个概念很容易混在一起。但从工程视角看，它们解决的是不同层级的问题。

对比维度	Prompt Engineering	Harness Engineering	Loop Engineering
核心问题	如何让 AI 更好地理解一次请求	如何让 AI 在受控环境中安全地执行任务	如何让 AI 在反馈中持续推进任务
主要对象	提示词、角色、格式、示例	工具、沙箱、权限、文件系统、命令执行环境	自动化流程、状态、验证、停止条件、多 Agent 协作
工作方式	人给 AI 一条高质量指令	人给 AI 配一个可操作的工程环境	人设计一个能反复发现、执行、验证和迭代的系统
典型产物	Prompt 模板、提示词规范、Few-shot 示例	Agent 工具链、权限策略、执行沙箱、项目规则	CI 修复 Loop、Issue 分流 Loop、自动 Review Loop、任务状态机
优势	上手快，能明显提升单次回答质量	让 AI 能真正操作项目，而不只是聊天	能减少人工调度，让 AI 持续处理工程任务
局限	依赖单次上下文，容易停留在"问答"层面	能执行，但不一定知道下一步该做什么	设计复杂，若缺少验证和边界，容易放大错误
适合场景	生成代码、解释代码、写文档、总结问题	让 Agent 读写文件、运行测试、调用工具、遵循权限	自动修复 CI、周期性巡检、批量处理 Issue、长期任务推进

我自己的理解是：

Prompt Engineering 像是在写一份清楚的任务说明书：告诉 AI 要做什么、按什么格式输出、注意哪些约束；
Harness Engineering 像是在搭一个工作台：给 AI 文件、终端、测试命令、工具权限和安全边界；
Loop Engineering 像是在设计一条自动化流水线：让 AI 不只做一步，而是能根据结果继续判断下一步。

举个例子，假设我们希望 AI 修复一个测试失败：

Prompt Engineering 关注的是：如何描述失败现象，如何要求 AI 分析原因并给出修复；
Harness Engineering 关注的是：AI 是否能读取代码、运行测试、修改文件，以及哪些命令允许执行；
Loop Engineering 关注的是：测试失败后是否自动重试，修复后是否再次验证，超过次数是否停止，成功后是否创建 PR 并记录状态。

所以，三者不是互相替代，而是逐层叠加：

复制代码

Prompt Engineering 解决"怎么说清楚"
Harness Engineering 解决"怎么安全地做事"
Loop Engineering 解决"怎么持续把事做完"

这也是为什么 Loop Engineering 更像一种系统工程能力。它并不是不要 Prompt，而是把 Prompt 放进一个更大的执行、反馈和验证闭环里。

所以，Loop Engineering 并不是替代 Prompt，也不是替代 Harness，而是站在 Prompt、Context 和 Harness 之上的更高一层抽象。

它真正关心的不是"AI 单次回答好不好"，而是"整个系统能不能持续可靠地推进任务"。

二、从"对话式 AI"到"系统式 AI"

很多人第一次使用 AI 编程工具时，会觉得最重要的是提示词。比如：

"请你扮演一个资深前端工程师"；
"请一步一步思考"；
"请输出完整代码"；
"请遵循某某规范"。

这些技巧当然有用，但它们解决的是单轮交互的问题。

真正的软件开发并不是单轮交互。一个稍微复杂的任务，往往包含：

需求拆解；
代码阅读；
方案设计；
多文件修改；
测试验证；
错误修复；
代码审查；
文档更新；
合并发布。

如果每一步都靠人手动告诉 AI 下一步做什么，那么人仍然是整个流程的调度器。AI 只是一个更快的执行工具。

Loop Engineering 的目标，是把"调度器"也系统化。

例如，一个 CI 自动修复 Loop 可以这样运行：

定时检查 CI 是否失败；
读取失败日志；
判断失败类型；
创建隔离分支或工作区；
派发 Agent 修改代码；
运行测试验证；
如果失败，继续迭代；
如果成功，生成 PR；
记录本轮状态；
等待人工 Review。

这个过程里，人不再逐条输入指令，而是提前设计好目标、约束、状态和验证机制。

这就是从"与 AI 对话"，走向"编程式 AI"。

三、Loop Engineering 的核心循环

我把 Loop Engineering 的基本流程概括为五个阶段：

1. Discover：发现问题

Loop 首先要知道自己该处理什么。

信息来源可以是：

CI 失败记录；
GitHub Issues；
用户反馈；
错误日志；
监控告警；
最近提交；
代码扫描结果。

这一步的关键是：不要让 AI 凭空想任务，而是从真实系统中发现任务。

2. Plan：制定计划

发现问题后，AI 不能立刻乱改代码，而应该先制定计划。

一个可靠的计划至少应该回答：

问题是什么？
影响范围在哪里？
需要修改哪些模块？
风险点是什么？
如何验证结果？
什么条件下可以停止？

这一步决定了 Loop 是工程化流程，还是"自动乱试"。

3. Execute：执行修改

执行阶段才是大家最熟悉的 AI Coding：读代码、改代码、写测试、补文档。

但在 Loop Engineering 中，执行最好是受约束的：

限定修改范围；
限定工具权限；
使用独立分支或 worktree；
禁止直接部署生产环境；
对高风险操作要求人工确认。

AI 的能力越强，边界就越重要。

4. Verify：验证结果

这是 Loop Engineering 最核心的一环。

因为 AI 说"完成了"，并不代表真的完成了。完成只是一个声明，不是证明。

验证应该尽量客观，例如：

单元测试通过；
集成测试通过；
lint 通过；
typecheck 通过；
CI 绿色；
性能指标未退化；
安全扫描无高危问题。

没有验证的自动化，只是更快地产生不确定性。

5. Iterate：根据反馈继续迭代

如果验证失败，Loop 应该根据错误信息继续修正；如果验证成功，则进入交付或等待人工审查。

这里一定要有停止条件，比如：

最多迭代 3 次；
指定测试全部通过；
修改文件不超过某个范围；
超过成本阈值则停止；
遇到权限、安全或架构问题转人工处理。

没有停止条件的 Loop，很容易变成"无限消耗 token 的自动化"。

四、构建 Loop 的六个关键组件

综合两篇文章的观点，一个比较完整的 Loop Engineering 系统通常包含六类组件。

1. Automations：循环的心跳

Automations 决定 Loop 什么时候运行。

常见触发方式包括：

每天早上定时运行；
每次 push 后运行；
CI 失败后运行；
Issue 新建后运行；
手动触发；
达到某个目标前持续运行。

如果没有 Automation，Loop 就仍然依赖人工启动。

2. Worktrees：并行开发的隔离层

当多个 Agent 同时修改同一个仓库时，很容易互相覆盖代码。

Git worktree 的价值在于：

每个 Agent 有独立目录；
每个任务有独立分支；
不同任务互不干扰；
方便回滚、对比和合并。

不过，worktree 只能解决机械冲突，不能解决人工 Review 带宽问题。你可以让十个 Agent 并行写代码，但不一定有能力同时审查十个 PR。

3. Skills：把项目经验写下来

AI Agent 最大的问题之一是"每次启动都像第一次见到项目"。

Skills 的作用，就是把项目经验沉淀成可复用的知识包，例如：

项目目录结构；
构建和测试命令；
编码规范；
API 设计约定；
常见坑；
历史技术债；
特定任务处理流程。

这能减少 AI 的猜测，让每次循环都站在已有经验之上。

4. Connectors：连接真实工具链

一个只能读写本地文件的 Loop，能力是有限的。

真正有价值的 Loop，往往需要连接外部系统：

GitHub / GitLab；
Jira / Linear；
Slack / 飞书 / 企业微信；
CI/CD 平台；
数据库；
日志系统；
监控平台。

Connector 的意义是让 AI 不只是"建议你怎么做"，而是能在权限边界内进入真实工程流程。

5. Sub-agents：让实现和验证分离

一个非常重要的原则是：不要让写代码的 Agent 自己给自己打分。

更可靠的设计是多 Agent 分工：

Explorer：负责阅读和定位问题；
Implementer：负责实现修改；
Reviewer：负责代码审查；
Verifier：负责运行测试和判断是否满足目标；
Security Agent：负责安全检查。

这就像真实团队里不会让开发者完全跳过 Code Review 一样。

6. State：外部持久状态

Loop 必须有记忆，但不能只依赖模型上下文。

因为上下文会丢失、压缩、漂移，而且一次会话结束后很多信息就不存在了。

更可靠的做法是把状态写入外部系统，例如：

STATE.md；
PROGRESS.md；
GitHub Issue；
Linear Ticket；
数据库；
任务队列。

状态应该记录：

当前任务是什么；
已经尝试了什么；
哪些失败了；
哪些验证通过了；
下一步该做什么；
是否需要人工介入。

一句话：模型会忘，仓库和状态文件不会。

五、实践建议

如果要在真实项目里尝试 Loop Engineering，我会从以下几点开始。

1. 从低风险任务开始

不要一开始就让 AI 自动改核心业务逻辑。

可以先选择：

文档检查；
lint 修复；
测试补全；
依赖更新说明；
changelog 生成；
CI 失败摘要。

这些任务风险低、收益明确，适合作为第一批 Loop。

2. 每个 Loop 都必须有停止条件

比如：

最多运行 3 轮；
只允许修改测试文件；
测试通过即停止；
失败则输出原因并转人工；
成本超过阈值立即停止。

不要设计没有边界的循环。

3. 把项目知识写成 Skill

不要每次都在 Prompt 里重复解释项目。

应该把稳定信息写下来：

怎么启动项目；
怎么运行测试；
哪些目录不能动；
代码风格是什么；
常见错误怎么处理。

这类知识越清晰，Loop 越不容易跑偏。

4. 实现和验证必须分离

至少要有两个角色：

一个负责改；
一个负责查。

哪怕暂时没有多 Agent 系统，也可以在流程上要求 AI 先输出计划、再修改、再用独立检查步骤审查。

5. 人工 Review 不能省

Loop Engineering 的目的不是取消工程师，而是减少重复劳动。

尤其是涉及架构、安全、数据、权限、性能的修改，必须保留人工审查。

AI 可以说"我完成了"，但工程师要确认"它真的完成了"。

六、总结

Loop Engineering 代表了 AI 编程的一个重要方向：从单次提示词优化，走向持续反馈系统设计。

它的核心不是让 AI 一次性变得完美，而是让 AI 在一个工程化闭环中不断发现、计划、执行、验证和迭代。

一个成熟的 Loop，通常需要：

Automation 提供触发；
Worktree 提供隔离；
Skill 提供项目知识；
Connector 接入真实工具；
Sub-agent 分离实现和验证；
State 保存长期记忆。

但越是自动化，越需要工程判断。

如果没有边界、验证、状态和人工 Review，Loop 只会更快地放大错误；如果设计得当，它则能把开发者从大量重复调度工作中解放出来，把注意力放回架构判断、质量把关和系统设计。

所以，我对 Loop Engineering 的理解可以用一句话概括：

不要只是让 AI 写代码，而要设计一个能让 AI 可靠工作的反馈系统；但最终，仍然要由工程师为结果负责。

参考阅读

Addy Osmani：《Loop Engineering》：AddyOsmani.com - Loop Engineering
徐小夕：《Loop Engineering 深度解析与实战指南（全网最全）》：Loop Engineering 深度解析与实战指南（全网最全）