一句话分辨：Prompt工程解决"怎么让AI一次做对"，Loop工程解决"怎么让AI持续做对"。它们不是进化替代关系，而是互补共存的两种哲学。

最近两个月，AI编程圈被一个词刷屏了——Loop Engineering。Boris Cherny（Claude Code创建者）说"我不再提示Claude了，我在写循环"；Peter Steinberger的推文引发800万+次浏览，核心论点是"不该给Agent写提示词了，该设计循环机制"。

于是很多人得出结论：Prompt工程过时了，Loop工程才是未来。

但我在实际项目中观察到的事实是：同一天里，我既在用Prompt工程，也在用Loop工程。 同一个需求，有时候一刀切的Prompt更高效，有时候循环迭代的Loop更靠谱。选择哪种，不是看谁更"先进"，而是看你的任务属性。

这篇文章不讲进化叙事，不讲谁替代谁。我给你一个实战决策框架——什么场景该用Prompt，什么场景该用Loop，以及两者怎么组合使用。

---

一、两种哲学的本质差异

先撕掉那些花哨的定义，回到最本质的差异：

维度	Prompt工程	Loop工程
核心问题	如何让AI一次产出正确结果	如何让AI持续迭代直到产出正确结果
人机交互模式	人→AI（单次握手）	系统→AI→系统→AI（持续对话）
设计对象	一段精心编排的提示词	一个自动运转的循环系统
对AI的要求	理解力强、输出稳定	能自主评估、能纠错、能止损
成本模型	单次高质量调用	多次迭代累计调用
失败模式	理解偏差导致一步错步步错	迭代发散导致消耗爆炸

用一个武侠比喻：Prompt工程是刀法——一招制敌，讲究精准和力量；Loop工程是阵法——围而歼之，讲究布局和节奏。

高手不会只练刀法不学阵法，也不会只用阵法放弃刀法。关键是知道什么时候该亮刀，什么时候该布阵。

---

二、实战对照：同一个需求的两种解法

我拿一个真实需求来做对照：给一个React组件库添加暗色模式支持。

方案A：Prompt工程解法

你是一个资深React开发者。请为以下组件库添加完整的暗色模式支持：

要求：
1. 使用CSS变量方案，定义 --color-primary, --color-bg, --color-text 等变量
2. 暗色模式变量值：--color-primary: #5b9bd5, --color-bg: #1a1a2e, --color-text: #e0e0e0
3. 通过 data-theme="dark" 属性切换主题
4. 所有12个组件必须适配，包括Button、Card、Modal、Table、Form等
5. 保持现有的亮色模式不变
6. 输出完整的CSS变量定义 + 每个组件的修改代码

项目文件结构：
src/components/Button.tsx
src/components/Card.tsx
...
src/styles/variables.css

请一次性输出所有修改。

结果：一次性拿到12个组件的修改代码，手动review后提交。总耗时约15分钟（5分钟写prompt + 10分钟review）。

优点：快。一次出结果，人对整个过程有完全掌控。

缺点：如果AI理解偏差（比如它用了ThemeProvider方案而不是CSS变量方案），你得重新写prompt重来。而且12个组件同时改，review压力大。

方案B：Loop工程解法

# loop_config.yaml
goal: "为React组件库添加暗色模式支持，所有测试通过"
verification:
  - cmd: "npm test"
    expect: "all tests pass"
  - cmd: "npm run build"
    expect: "no errors"
  - check: "data-theme属性在所有组件中生效"
    auto: false  # 需要人工确认
max_iterations: 8
stop_on:
  - verification_pass: true
  - consecutive_fail: 3
  - cost_limit: "$5"
context_reset: "git stash && git checkout anchor-state"  # 每轮重置到锚点

结果：Agent自动遍历组件、逐个修改、跑测试、发现失败自动回退修正。人只需要在关键节点确认（比如第一次选择技术方案时）。总耗时约2小时，但人的参与时间只有15分钟。

优点：不需要人一直盯着。Agent自己试错、自己修正，适合夜间运行。

缺点：2小时 vs 15分钟。如果你下午4点需要上线，Loop工程来不及。

---

三、决策矩阵：什么时候用哪种

这才是本文最有价值的部分。我根据半年实战经验，总结了一个四维决策框架：

3.1 时间压力维度

场景	推荐	原因
今天要上线	Prompt	单次调用，5分钟出结果
本周要交付	Prompt优先，Loop辅助	核心路径用Prompt，边缘任务用Loop
没有紧急deadline	Loop	让Agent夜间迭代，早上看结果

3.2 可验证性维度

场景	推荐	原因
有自动化测试	Loop	Agent能自己验证，闭环运转
只能人肉验证	Prompt	Loop没有评估器，等于盲转
半自动验证	组合	核心逻辑用Prompt保证，细节用Loop打磨

这是最关键的维度。 Loop工程的灵魂是"评估器"——没有评估器，Loop就是花钱烧token。如果你的任务没有可自动验证的标准（比如"用户体验要好"、"代码要优雅"），Loop工程不适合你。

3.3 任务复杂度维度

场景	推荐	原因
单文件修改	Prompt	复杂度低，一次Prompt搞定
跨10+文件重构	Loop	Agent能自动遍历，人手动改容易漏
探索性任务（写新功能）	Prompt	需要人在每一步把关方向
重复性任务（批量迁移）	Loop	规则固定，适合自动循环

3.4 成本敏感度维度

场景	推荐	原因
个人开发者/小团队	Prompt为主	Token预算有限，Loop的多次调用成本高
企业团队有预算	混合使用	核心任务Loop跑，日常任务Prompt搞定
有无限预算	Loop大胆用	Boris Cherny每晚跑数千Agent的前提是预算充足

---

四、组合使用：Prompt + Loop的最佳实践

纯用一种范式的团队，我见过的都踩了坑。真正高效的用法是组合。

4.1 "Prompt定方向，Loop跑执行"

这是我最推荐的组合模式：

1. 用Prompt工程做方案决策：花5分钟写一个高质量Prompt，让AI给出技术方案选型、架构设计、关键接口定义
2. 人review方案：确认方向正确
3. 用Loop工程做方案执行：把确认后的方案转化为Loop的goal，让Agent自动迭代实现

# 第一步：Prompt定方向
Prompt → AI输出：技术方案（CSS变量 + data-theme）
人review → 确认方案可行

# 第二步：Loop跑执行
Goal: "按已确认的CSS变量方案，为所有组件实现暗色模式"
Verification: npm test && npm run build
Max iterations: 6

这样你既不会在方向上走偏（Prompt保证了方案正确性），又不会在执行上累死（Loop自动完成重复工作）。

4.2 "Loop跑批量，Prompt做关键"

批量任务用Loop，关键节点用Prompt介入：

# Loop自动迁移100个文件
Goal: "将所有class组件迁移为function组件"
Verification: eslint + test pass

# Loop遇到无法自动决策的文件时
Trigger: "当检测到HOC模式时，暂停并请求人工介入"
→ 人工用Prompt方式处理特殊case
→ Loop继续

4.3 "夜间Loop + 白天Prompt"

Boris Cherny的做法：晚上提交数千Agent并行跑Loop，早上看结果。白天用Prompt处理需要即时响应的任务。

这个模式的前提是：你的夜间任务必须有完全自动化的验证条件。 否则早上看到的不是结果，是灾难。

---

五、三个常见误区

误区1："Loop工程替代了Prompt工程"

错。 Loop工程的前提是一个好的初始Prompt或Goal。Loop不是从零开始运转——它需要一个清晰、可验证的目标。这个目标的定义质量，直接决定了Loop的运转效率。

说"不再写Prompt了"的人，其实是在写元Prompt——不是给AI的一次性指令，而是给循环系统的运转规则。本质上还是Prompt工程，只是抽象层级更高了。

误区2："Loop工程一定比Prompt工程更高级"

错。 高级不等于适合。一个简单的CSS修改，用Prompt 30秒搞定，用Loop可能要跑3轮迭代花5分钟。选择工具要看任务属性，不是看工具的"级别"。

外科手术用手术刀，不是用激光就更好——要看切什么。

误区3："Loop工程 = 让AI自己跑不用管了"

危险。 Addy Osmani提出的两个概念值得每个团队警惕：

• 理解债（Comprehension Debt）：Agent产生大量代码，人越来越不读，团队对系统的理解逐渐下降
• 认知投降（Cognitive Surrender）：Loop越顺畅，人越容易停止思考，把决策权完全交给系统

Loop工程的真正挑战不是技术层面的——而是人如何在使用Loop的同时保持对系统的理解和控制。

---

六、给不同角色的实操建议

给个人开发者

你大概率Token预算有限，优先练Prompt工程。一个高质量的Prompt能省下10次Loop迭代的成本。什么时候用Loop？夜间跑批量任务——把白天确认好的方案写成Goal，让Agent在你睡觉时执行。

给技术Leader

你需要同时掌握两种范式，因为团队里永远有人需要快速解决小问题（Prompt），也永远有大批量任务需要自动化（Loop）。建立两条工作流：

1. 即时响应流：Prompt → review → 合入
2. 批量迭代流：Goal定义 → Loop执行 → 早上review → 合入

给产品经理

你最该关注的不是哪种范式更先进，而是验证条件是否足够自动化。Loop工程需要可自动验证的goal——如果你的验收标准是"用户体验要好"，Loop跑不起来。把验收标准从主观判断转化为可量化指标，这是你最重要的工作。

---

七、总结：不是进化，是分工

全网讨论Loop工程时，最常见的叙事是"从Prompt到Context到Harness到Loop的四层进化"。这个叙事是对的——它描述了抽象层级的递进关系。

但叙事容易误导人以为这是一条单行道：Prompt过时了，该学Loop了。

事实是：这四层是叠加包含的，不是替代的。 Loop工程包含Prompt工程——Loop的Goal定义、评估标准、停止条件，全是Prompt工程的产物。你Loop写得好不好，取决于你Prompt想得清不清。

Prompt工程是刀法，Loop工程是阵法。高手兼备，择机而用。

刀法和阵法之间，不是进化关系，是分工关系。什么时候亮刀，什么时候布阵，取决于你的任务属性、时间压力、验证能力和成本预算。

别被"Loop取代Prompt"的叙事带节奏。先搞清楚你今天要解决的问题，再选最适合的工具。

---

一句话总结：Prompt工程解决"一次做对"的问题，Loop工程解决"持续做对"的问题。它们是互补的两种哲学，不是替代的进化路线。实战中选择哪种，看四个维度——时间压力、可验证性、任务复杂度、成本敏感度。最高效的用法是组合：Prompt定方向，Loop跑执行。