从 Prompt 到 Loop：软件工程的下一个十年

从 Prompt 到 Loop：软件工程的下一个十年

——一条演化路线的终点，与另一条路线的起点

写在前面：  软件工程正在发生什么？十年后工程师的工作会是什么样的？Loop 是终点，还是另一次演化的起点？这篇文章没有代码，只有思考。思考比代码更难写，也更难被 Loop 替代。

零、一句话引发的风暴

2026 年 6 月 7 日，Boris Cherny（Anthropic Claude Code 负责人）在一场演讲里说了一句话：

"我不再 prompt Claude 了。我有循环在运行，它们负责 prompt Claude 并决定下一步做什么。我的工作就是写循环。"

这句话在 Twitter/X 上引发了数千条回复，在 Hacker News 首页待了两天，被翻译成十几种语言，触发了"prompt engineering 已死"的新一轮论战。

但大多数讨论错过了这句话最重要的部分——不是"我有循环"，而是"我的工作就是写循环"。

这六个字是一个巨大的认知跳跃。它不是在说 AI 更强了。它是在说工程师的工作内容发生了结构性的改变——从"告诉 AI 做什么"变成了"设计让 AI 决定做什么的系统"。

这个跳跃，是本系列所有内容的根基。

一、演化路线图：软件工程的五个时代

要理解 Loop Engineering 的位置，需要先看清楚它从哪里来。

1.1 第一时代：工具时代（1950s-1990s）

工程师写代码，代码在机器上运行。工具（编译器、调试器、IDE）的作用是让写代码这件事更容易。但写代码本身是完全属于人类的工作。

工程师的核心技能：数学逻辑、系统思维、算法设计。

1.2 第二时代：模式时代（1990s-2010s）

设计模式、框架、开源库的大爆发。工程师不再从零写每一行代码，而是组合已有的模式和组件。抽象层次提升，同样的人力产出了更复杂的系统。

工程师的核心技能：架构设计、框架理解、代码组合能力。

1.3 第三时代：云与平台时代（2010s-2022）

基础设施被抽象成服务。AWS、K8s、SaaS 工具让工程师可以把更多精力放在业务逻辑上，而不是基础设施。"全栈"工程师成为可能。

工程师的核心技能：云原生思维、系统集成、API 设计。

1.4 第四时代：AI 辅助时代（2022-2025）

GitHub Copilot 的出现标志着这个时代的开始。AI 成为工程师的"配对程序员"——建议代码、解释错误、生成样板代码。但人类仍然是主导者，AI 是助手。

工程师的核心技能：AI 提示能力（Prompt Engineering）、判断 AI 输出的能力。

工具的进化代表了抽象层次的提升：从汇编到高级语言，从高级语言到框架，从框架到平台，现在从平台到 AI 原生开发。

1.5 第五时代：Loop 时代（2025-？）

这是我们现在正在进入的时代。核心转变是：AI 不再只是助手，而是自主执行者。人类不再"让 AI 做"，而是"设计让 AI 自主决定做什么的系统"。

工程师的核心技能：系统设计（Loop 设计）、验证器设计、元判断能力（判断 Loop 是否在正确方向上）。

用一张演化图来看：

text

软件工程的抽象层次演化：
时代          工程师直接操作的对象       被抽象掉的东西
─────────────────────────────────────────────────────────
工具时代      机器指令 / 汇编              硬件细节
模式时代      算法 / 设计模式              机器指令
云与平台时代  业务逻辑 / API               基础设施
AI 辅助时代   意图表达（Prompt）           代码生成
Loop 时代     目标定义 + 系统设计          迭代过程本身
─────────────────────────────────────────────────────────
规律：
每一次演化，工程师操作的抽象层次提升一级，
被"抽象掉"的东西变得更多、更复杂。
但有一件事从未被抽象掉：
判断"这个系统在正确方向上运行"的能力。

这个规律很重要。每一次抽象提升，都是一次双向运动：

• 工程师从"更低层的细节"中解放出来
• 工程师被要求在"更高层的设计"上承担更多责任

Loop 时代也不例外。

二、被改变的事与未被改变的事

在 Loop 时代，有些事情发生了根本性的改变，但有些事情顽固地保持不变。这是本文最核心的二分法。

2.1 改变了的事

改变一：工程师的时间分配结构

在传统开发中，工程师的时间大致这样分配：

• 40%：写代码
• 30%：调试和修复
• 20%：code review 和沟通
• 10%：架构设计和规划

在 Loop 驱动的工作方式中，理想状态的分配变成：

• 5%：写代码（只写 Loop 处理不了的核心部分）
• 15%：审查 Loop 产出的代码
• 20%：设计和配置 Loop（SKILL.md、验证器、停止条件）
• 25%：判断 Loop 的输出质量、处理 Loop 失败的情况
• 35%：更高层次的工程活动（架构、技术方向、跨团队协作）

这不是"工作量减少了"，而是"工作内容的质地变了"。从执行型工作为主，变成判断型工作为主。

改变二：技能的重要性排序

传统时代最重要的技能：

1. 算法和数据结构（直接影响代码质量）
2. 特定语言的熟练度（写代码的速度）
3. 框架和工具的使用经验

Loop 时代最重要的技能：

1. 系统设计思维（设计 Loop 架构）
2. 批判性判断力（评估 AI 输出，识别反模式）
3. 验证标准的定义能力（把"好"写成可验证的条件）
4. 元认知能力（知道什么时候用 Loop，什么时候不用）

算法和语言熟练度仍然重要，但它们从"核心竞争力"退变成了"基础门槛"。

改变三：错误的类型和发现时机

传统工程中，错误主要来源于人类：逻辑错误、类型错误、边界条件遗漏。

Loop 时代引入了新的错误类型：

• Loop 设计错误（成功条件定义错误 → AP-01、AP-02）
• 验证器偏差（Judge 被"训练"成放松标准 → AP-05、AP-06）
• 上下文中毒（长时间运行的 Loop 遗忘原始目标 → AP-11）
• 理解债务（代码在增长，但没有人理解它 → AP-15）

这些错误的危险性在于：它们不会立刻崩溃，而是慢慢积累，直到突然爆发。

改变四：成本结构的变量化

传统工程的成本是相对固定的：人力 + 服务器，可以预测。

Loop 时代的成本是动态的：token 消耗随着 Loop 使用模式变化，且变化幅度可以是数量级的（AP-08、AP-09）。这要求工程师和管理者建立全新的成本意识和控制机制。

2.2 顽固未变的事

这部分比"改变了什么"更重要，因为它决定了工程师这个职业的根基是否还在。

未变一：目标的定义是人类的工作

无论 Loop 有多强大，它只能朝着被定义的目标前进。定义目标是什么——这件事永远属于人类。

Loop 可以写代码，但不能决定写什么代码。Loop 可以修复 bug，但不能决定什么样的系统值得维护。Loop 可以优化性能，但不能判断这个系统对用户的价值是否足以支撑优化的代价。

这不是因为 AI 不够聪明——在某些局部任务上 AI 已经超越了人类。这是因为目标定义是一个价值判断，而价值判断需要扎根于人类的具体生活和需求，而不是数据分布。

未变二：质量的最终判断是人类的工作

验证器可以告诉你"测试通过了"，但它不能告诉你"这个测试是否测了真正重要的事情"。

Judge 可以评估"文章的逻辑是否连贯"，但它不能评估"这篇文章是否说了值得说的话"。

在每一个 Loop 的终点，都有一个人类需要做的判断：这个结果是否真的好？

好的验证器减少了"明显不好"的通过，但无法识别"正确但无意义"或"合规但错误方向"的输出。那个最终判断，是人类不可推卸的责任。

未变三：理解是责任的前提

第八篇提到的理解债务（AP-15），背后是一个哲学命题：你只有理解了，才能为它负责。

如果你批准了一个 PR 但没有理解它，你在形式上承担了责任，但实质上放弃了判断。这是一种责任转移的幻觉——你把"点了批准按钮"误认为"承担了工程责任"。

Loop 时代，理解的重要性不是降低了，而是提高了——因为需要理解的东西更多（Loop 产出的代码），而理解的机会更少（没有"写代码"这个自然的理解过程）。

理解需要主动努力。在 Loop 时代，主动理解 AI 产出的代码，是工程职业素养的核心标志之一。

未变四：复杂系统的涌现属性需要人类感知

一个软件系统的行为，不等于它的每个组件的行为之和。

复杂系统有涌现属性（Emergent Properties）——在组件层面看起来正确的东西，在系统层面可能产生意想不到的行为。

Loop 在组件层面工作：修这个 bug，改那个函数，优化这个模块。但系统层面的涌现行为——性能瓶颈如何传播、一个模块的改动如何影响整体架构、技术债务如何积累成系统性风险——这些需要人类持续地感知和干预。

没有任何 Loop 能替代一个有经验的工程师站在代码库前，感受系统的"健康状态"，并决定什么时候需要架构性的干预而不是局部修复。

三、「元杠杆」的涌现

本系列讨论了很多具体的技术杠杆：Prompt Caching 降低 70% 成本，混合路由节省 7 倍支出，验证器设计决定修复成功率。

但这些都是"一阶杠杆"——直接作用于单个 Loop 的工具。

Loop Engineering 的真正深层价值，在于它创造了一种"二阶杠杆"，或者说元杠杆：

text

元杠杆的含义：
一阶杠杆（直接）：
  我用 Loop 修复了一个 bug → 节省了 30 分钟
二阶杠杆（间接）：
  我设计了一个 Loop 框架，让团队的任何工程师都能
  用 Loop 修复同类 bug → 每周节省 5 × 30 分钟 = 150 分钟
三阶杠杆（元）：
  我设计了一个让团队持续改进 Loop 框架本身的机制
  → Loop 的效率每月提升 10%
  → 6个月后，同样的 Loop 比初始版本高效 77%

这个元杠杆逻辑，解释了为什么"Loop 工程师"的价值远大于"会用 Loop 的工程师"：

• 会用 Loop：自己的效率提升，个人贡献增加
• 会设计 Loop 框架：团队效率提升，组织贡献增加
• 会设计让 Loop 持续演化的机制：组织能力提升，竞争优势增加

这三层能力之间，不是量的差异，而是质的差异。

四、一个没有在教程里出现的风险

整个 Loop Engineering 社区，包括本系列文章，大量讨论了技术风险（翻车、成本、验证器偏差）和组织风险（理解债务、橡皮图章化）。

但有一个风险被几乎所有人忽略了：判断力的退化。

这个风险是这样发生的：

当工程师把越来越多的判断委托给 Loop（"让它试试，看看结果"），工程师自己做独立技术判断的频率就降低了。人类的判断力，和任何技能一样，是"用进废退"的。

一个每天做 50 个技术判断的工程师，和一个每天做 10 个技术判断（另外 40 个交给 Loop）的工程师，两年后在判断力上会出现差距——不是因为后者变笨了，而是因为他练习得更少。

更微妙的是：这个退化是隐性的。你不会感觉到自己的判断力在下降。你会感觉效率在提升，因为更多的事情"自动完成了"。但在某个关键时刻——Loop 覆盖不到的、需要深度判断的时刻——你会发现自己的肌肉萎缩了。

这不是反 AI 的观点，而是一个简单的神经科学事实：任何技能，如果长期不练习，都会退化。

如何防止判断力退化：

text

判断力保护机制（个人层面）：
① 主动保留"纯人工"的任务
  每周选 1-2 个完全不用 Loop 的任务来做
  不是因为 Loop 做不好，而是为了维持手感
② 在 Loop 成功后进行"反向工程"
  当 Loop 修复了一个 bug，读懂修复方案后，
  自问："如果是我，我会怎么想到这个方案？"
  把 Loop 的过程转化成自己的学习
③ 定期做"盲评"练习
  不看 Loop 的输出，先自己判断"这个问题应该怎么解决"
  然后和 Loop 的方案对比
  差异是最好的学习材料
④ 保持对底层的感知
  定期阅读代码库中最核心的模块（不用 Loop 帮助）
  理解系统的整体健康状态
  这是不能委托给 Loop 的感知能力

五、Loop Engineering 的精神内核

读完这 10 篇文章，可能有一个印象：Loop Engineering 是一套复杂的技术体系——验证器、停止条件、成本控制、组织治理……

但如果剥去所有技术外壳，Loop Engineering 的精神内核只有一句话：

把你的判断标准外化为系统，然后监督这个系统。

这句话的每个词都有分量：

• 把：这是一个主动的行为，需要你先弄清楚自己的标准是什么
• 你的：不是别人的标准，是你对"好工作"的理解
• 判断标准：什么叫做好的代码、好的内容、好的调研结果
• 外化为系统：把它写成 SKILL.md、验证器、成功条件、停止规则
• 然后：外化之后，工作还没完
• 监督这个系统：确保系统在按照你设计的方向运行，而不是走偏了

这个精神内核，让 Loop Engineering 和"自动化"有了本质的区别：

传统自动化的心智模型：机器做事，人类设定规则，然后走开。

Loop Engineering 的心智模型：系统做事，人类持续监督和调整，永远在场。

这种"在场"不是物理的在场（你不需要盯着 Loop 跑），而是认知和判断的在场——你知道系统在做什么、为什么这么做、什么时候应该干预。

六、给不同阶段的人的不同建议

6.1 给刚接触 Loop Engineering 的人

最重要的第一步，不是学工具，而是定义"好"。

在你打开任何 Loop 工具之前，先回答这三个问题：

1. 我想用 Loop 完成什么任务？
2. 这个任务完成得"好"是什么样子？（写出具体标准，不是感觉）
3. 如果 Loop 产出了"不好"的结果，我能识别出来吗？

如果你对第3个问题没有把握，那就先不要用 Loop——先让自己练习手工完成这个任务，直到你对"好不好"有清晰的判断能力，再引入 Loop。

这个顺序是反直觉的（大多数人想着"用工具效率更高"），但它是正确的顺序。Loop 放大你的判断能力，而不是替代它。

推荐的第一周实践：

text

第1天：选择一个你现在花大量时间手工做的重复任务
第2天：把你对"好的结果"的标准写成5个具体可验证的条件
第3天：尝试用 Claude 或其他工具生成一个结果，按你的5个标准评判
第4天：把你的评判标准转化成一个验证器（可以是另一个 prompt，也可以是代码）
第5天：把执行器+验证器连接成最简单的 Loop（哪怕只有 while 循环 + 两次 API 调用）
第6天：运行 Loop，记录它在哪里通过、哪里失败
第7天：基于失败，改进你的标准定义，而不是改进 Loop 的执行器

6.2 给已经在用 Loop 但感觉"用得不好"的人

"用得不好"通常有三种表现：

• Loop 总在错误的方向上迭代（目标定义问题 → 重读第一、五篇）
• Loop 成本比预期高很多（架构问题 → 重读第二、三篇）
• Loop 产出的质量不稳定（验证器问题 → 重读第四篇）

但在重读这些文章之前，先做一个诊断：

text

Loop 问题诊断三问：
问题1：你的成功条件是否可以用终端命令验证？
  YES → 基本结构正确，问题在执行层
  NO  → 从这里开始修复（改写成功条件）
问题2：你的验证器是否和执行器使用不同模型家族？
  YES → 验证器设计基本正确
  NO  → 立刻修复（同族裁判问题，AP-04）
问题3：你的 Loop 每次失败后，你知道具体原因吗？
  YES → 你在监督系统，继续优化
  NO  → 加入结构化的失败记录（外置记忆，AP-12）

6.3 给想在团队中推广 Loop Engineering 的人

不要从技术开始，从一个具体的痛点开始。

找到团队里所有人都认可的一个痛点——比如"每天 CI 失败太多、手动修复太耗时"——然后用 Loop 解决这一个具体问题。

做出结果之后，用数据说话：

• 修了多少个 CI 失败
• 节省了多少工程师时间
• 花了多少 AI 成本
• ROI 是多少

有了第一个成功案例和真实数据，推广就有了基础。

不要做的事：

• 不要从"理论上 Loop 很好"开始
• 不要一次推广太多场景
• 不要在没有建立基础护栏（成本控制、质量验证）之前大规模铺开
• 不要忽视团队里对 AI 工具有顾虑的成员（他们的顾虑往往有道理）

6.4 给 CTO 和工程 VP 的一句话

Loop Engineering 是一个杠杆，但只有当你理解它在撬什么的时候才是杠杆。

最危险的使用方式是：部署它，然后走开，用上升的速度指标作为成功的证明。

速度指标容易骗人。真正需要追踪的是：

• 团队对代码库的理解度（是否在下降？）
• 生产事故率（是否在上升？）
• 工程师的技术判断力（是否在演练，还是在萎缩？）

这三个指标，任何一个出现问题，都比速度指标下降更危险。

七、Loop Engineering 的边界：它不是什么

这一节专门澄清误解。每一个新的技术范式都容易被过度解读，Loop Engineering 也不例外。

误解一：Loop Engineering 意味着工程师会减少

这个论断太粗暴了。更准确的理解是：Loop Engineering 会改变工程师的工作内容，但"需要多少工程师"取决于企业想构建多大规模的系统。

历史规律是：每一次效率工具的出现，最终都导致了更多而不是更少的软件工程师——因为可以构建的系统变得更多、更复杂。计算器的出现没有减少数学家，电子表格的出现没有减少会计师，CAD 的出现没有减少工程师。

但工程师的工作内容会发生深刻变化，能力要求会提升，适应不了这种变化的人会面临挑战。这是真实的。

误解二：Loop Engineering 适用于所有任务

不是的。本系列反复强调：Loop 适合"需要推理判断的任务"，不适合"需要确定性执行的任务"。

有些任务永远不应该交给 Loop：

• 涉及真实人类情感和关系的决策
• 法律和合规的最终判断
• 安全关键系统的架构决策
• 创造性工作中最核心的创意判断

把这些任务强行放进 Loop，不是在使用工具，而是在逃避判断责任。

误解三：Loop Engineering 等于更聪明的自动化

Loop 和自动化的核心区别在第九篇里讨论了：Loop 是目标驱动的，自动化是规则驱动的。

更重要的区别是：自动化的目标是减少人类干预；Loop Engineering 的目标是让人类干预集中在最有价值的地方。

好的 Loop 设计不是"人类干预越少越好"，而是"人类在正确的时机、以正确的深度介入"。

误解四：Loop Engineering 是大公司的玩具

Uber 的案例经常被引用（烧掉全年预算），让人觉得 Loop Engineering 是需要大规模资源才能玩的游戏。

实际上，本系列的实验数据显示：单个工程师每天在 $5-15 的预算内，可以运行非常有价值的 Loop。Qwen 3.6 Plus 每个 bug 修复成本 $0.08，一个月修复 100 个 bug 总成本 $8——这是任何规模的团队都负担得起的。

大公司的风险不是 Loop Engineering 本身，而是在没有建立治理机制的情况下大规模部署。

八、软件工程的下一个十年：三个可能的方向

2026 年，Loop Engineering 刚刚从技术概念变成实践标准。但它会向哪里演化？有三个可能的方向，每一个都代表一种不同的未来。

方向一：Loop 成为软件开发的新基础设施

就像今天的 CI/CD 流水线一样——它存在，每个团队都在用，但没有人把它当作"新技术"，它已经是标准的工程基础设施。

在这个方向上，Loop Engineering 会被彻底工具化：有标准的 Loop 编排平台（类似 GitHub Actions 之于 CI/CD）、有标准的验证器市场（开箱即用的 rubric 模板）、有内置的成本控制和审计日志。

工程师不需要学 Loop Engineering，就像今天的工程师不需要"学 CI/CD 理论"——他们只需要知道怎么用，以及何时用。

如果这个方向实现： Loop Engineering 的技术内容会被大量抽象，工程师的差异化能力转向更高层次的设计和判断。

方向二：Loop 演化为 Multi-Agent 网络

单个 Loop（一个执行器 + 一个验证器）的能力有限。下一步自然是：多个 Loop 并行运行，互相提供验证和反馈，形成一个 Agent 网络。

在这个方向上，"设计 Loop"本身变成了"设计 Agent 网络的拓扑"——哪些 Agent 负责执行、哪些负责验证、哪些负责协调、信息如何在 Agent 之间流动、整个网络的目标如何被定义。

这个演化已经在发生：Arbor、SWE-agent 团队等都在探索多 Agent 协作的架构。研究者报告称，多 Agent 系统在复杂任务上的表现远超单 Agent。

如果这个方向实现： Loop Engineering 的技能演化为"Agent 网络架构师"——更接近系统设计，更远离代码编写。

方向三：Loop 遭遇可靠性上限，回归人类中心

这是一个更悲观但同样可能的方向：Loop 的能力在某个层次触顶。对于足够复杂、足够模糊、足够需要创造力的任务，Loop 始终无法达到令人满意的质量。

在这个方向上，Loop 成为了一个专业工具——特定类型任务的加速器——而不是通用的工程方式。大多数"真正重要"的工程工作仍然是人类主导的。

这个方向并不意味着 Loop Engineering 是失败的——菜刀是专业工具，不能替代所有烹饪方式，但依然是厨房里不可或缺的东西。

如果这个方向实现： Loop Engineering 的价值被重新定标为"特定场景的最优工具"，而不是"软件工程的范式转变"。

我的判断： 三个方向很可能同时发生，只是在不同领域的体现不同。重复性、结构化的工程任务走向方向一（基础设施化）；复杂的系统级问题走向方向二（Multi-Agent 网络）；创造性、判断密集型的任务走向方向三（人类中心）。

九、一个被问了很多次的问题

在这个系列的写作过程中，被问到最多的一个问题是：

"十年后，初级工程师还有没有位置？"

这是一个真实的焦虑，值得认真回答。

简短的答案是：有位置，但不是相同的位置。

历史上每一次工程效率工具的出现，都有相同的担忧。1970 年代结构化编程让"打孔卡片操作员"消失了，但工程师数量增加了。1990 年代面向对象的框架让很多"样板代码"工作自动化了，但工程师数量增加了。2010 年代云计算让"服务器管理员"这个角色大量减少，但整体技术就业仍然增长。

规律是：技术工具让特定类型的"执行工作"自动化，但同时创造了新的"设计和判断工作"的需求，而且通常创造的需求比消灭的多。

但这里有一个重要的区别：转型速度。

过去每一次技术转型的窗口期是 10-20 年，给了人们足够的时间适应。Loop Engineering 的转型速度可能更快——从"概念"到"行业标准"的时间可能只有 3-5 年。

这意味着工程师需要比历史上任何时候都更主动地适应这种转变，而不是等待行业慢慢重塑自己。

对初级工程师最实用的建议：

不要把 Loop Engineering 看作竞争对手，把它看作加速你成长的工具。

初级工程师的成长路径历来是：通过大量做具体的事，积累判断力，然后升级到更复杂的工作。

Loop Engineering 可以让你：

• 通过审查 Loop 产出的代码，接触到比手写更多的代码模式
• 通过设计验证器，被迫把隐式的质量判断变成显式的标准
• 通过分析 Loop 的失败，理解代码问题的类型和根因

关键是：把 Loop 当成学习加速器，而不是工作替代者。

阅读 Loop 产出的每一行代码，理解它为什么这么写，比让 Loop 生成而不去阅读学到的东西多十倍。

十、结语：Loop 的本质是一种认识论

写完这个系列的九篇技术文章，再来写这最后一篇的时候，我发现 Loop Engineering 的深层含义远超技术层面。

它实际上是一种认识论的实践——关于"如何知道一件事是对的"的哲学。

传统工程的认识论是：我写了这段代码，我相信它是对的，因为我在脑子里运行过它。

Loop Engineering 的认识论是：我定义了"对的"的标准，我设计了一个系统来检验这个标准，我监督这个系统是否真的在检验正确的东西。

这个认识论有一个核心的谦逊之处：它承认个人的直觉是不够可靠的，需要被外化和验证。

但它同时也有一个核心的责任担当：谁来定义标准、谁来监督系统——这永远是人类的工作。

在 Loop Engineering 的框架里，AI 做的是"在给定标准下的最优执行"。人类做的是"设定标准、判断标准是否正确、在系统偏离时纠正方向"。

这个分工，是我认为最值得保留的东西——无论技术如何演化。

十一、系列的终点，与一个邀请

《从 Prompt 到 Loop》这个系列，从第一篇的翻车纪录，经过成本、弱模型、验证器、停止条件、非代码场景、反模式、组织视角、CI/CD 集成，到这最后一篇的思想总结。

十篇，约 20 万字，近 300 个代码块，数十组实验数据。

但这不是一个封闭的知识体系，而是一个开放的邀请。

邀请你去实践：每一篇文章都有可以在下周运行的具体代码。最好的学习是动手——让 Loop 翻车，从翻车里学习，然后修好它。

邀请你去质疑：这个系列的每一个观点都来自于特定的实验和视角。你的实验可能得出不同的结论，你的视角可能发现我没有看到的盲点。

邀请你去分享：如果你发现了更好的 Loop 设计模式、更有效的验证器策略、更聪明的停止条件——分享出来。这个领域太新，所有人都是在探索中学习。

最后，我想用一句话来结束这个系列。它来自第一篇引用的 Boris Cherny 的那句话的另一半：

"构建 Loop。但要像一个打算继续当工程师的人那样构建它，而不只是那个按下开始键的人。"

这句话里，"打算继续当工程师"是关键。

工程师这个词的含义，从来不是"写代码的人"，而是"用系统性思维解决问题的人"。

无论技术如何演化，这个定义的核心保持不变。

Loop Engineering 改变的是工具和方法。系统性思维，是你永远需要带到工作中的东西——无论你在设计一个编译器，还是在设计一个让 AI 自主修复 CI 的循环。

这，是软件工程下一个十年的赌注。

《从 Prompt 到 Loop》系列完整索引

篇次	标题	核心问题
第1篇	从 0 到翻车到修好	Loop 是什么？为什么会翻车？
第2篇	Loop 成本实验室	不同配置的真实 ROI 是多少？
第3篇	弱模型也能跑 Loop	国产模型如何替代 Claude？
第4篇	验证器设计模式	谁来判断 Loop 的输出好不好？
第5篇	停止条件的艺术	什么时候让 Loop 停下来？
第6篇	超越编程：非代码场景	Loop 如何应用到非技术领域？
第7篇	反模式清单	哪 15 种设计会让 Loop 翻车？
第8篇	组织架构的影响	Loop 改变了什么？谁来负责？
第9篇	Loop vs 传统 CI/CD	两者如何分工与互补？
第10篇	从 Prompt 到 Loop	这一切意味着什么？

下一步：如果你从第一篇读到这里——恭喜。现在去跑你的第一个 Loop 吧。