Prompt工程是刀法，Loop工程是阵法——AI Coding两种哲学的实战选择指南

一句话分辨：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工程是阵法——围而歼之，讲究布局和节奏。

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

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

我拿一个真实需求来做对照：给一个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 时间压力维度

3.2 可验证性维度

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

3.3 任务复杂度维度

3.4 成本敏感度维度

四、组合使用：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跑执行。