An Introduction to Loop Engineering

循环工程简介 - MachineLearningMastery.com

循环工程简介

作者

Shittu Olumide

于

2026年7月23日

分类

人工智能

0

分享

发布

在本文中，你将了解什么是循环工程，它的起源，以及如何设计能够可靠运行且无需持续人工监督的自主AI代理循环。

我们将涵盖的主题包括：

• 循环工程的起源和定义，以及它如何融入从提示工程到上下文工程再到掌控工程的更广泛发展路径中。

• 可靠循环的结构，包括其核心组件、常见模式，以及支撑当今几乎所有生产实现的伪代码框架。

• 循环工程中的三个最难问题——上下文管理、终止条件和验证——以及因任一问题处理不当而可能导致的失败模式。

引言

几个月前，开发者的夜晚通常是这样的：打开编码代理，输入指令，等待，阅读返回内容，将错误粘贴到聊天中，再次等待，稍微调整方向，重复直到功能真正运行或到了睡觉时间。代理确实在做实际工作，但人类一直在全程手动控制，一次又一次地操作，就像每三秒就需要手扶方向盘开车一样。

如今，越来越多的工程师的夜晚已变得不同。他们只需编写一条指令，合上笔记本电脑，第二天早上回来时就能看到一份草稿拉取请求、已分类的问题列表或绿色的CI构建，以及代理尝试过什么和原因的可读记录。没有人站在旁边输入下一条指令。改变的不是模型本身，而是围绕模型构建的内容。

这种转变被称作"循环工程"，这个术语从一个小众概念迅速发展为2026年6月一周内人们在每条时间线都在讨论的话题。本文将带您了解这个术语的起源、它实际继承的研究成果、循环的构成，以及如何构建自己的小型循环。

循环工程的实际含义

循环工程是指设计一个系统来提示、检查、记忆并重新运行AI代理，而不是由人工逐轮完成这些操作。工作单元不再是一个单独的提示甚至是一次对话。它变成了一个循环：一个重复的周期，模型采取行动，从环境中获得反馈，利用这些反馈决定下一步该做什么，并持续进行直到满足一个真实可检查的条件。

将这个概念与它所替代的事物进行对比会有所帮助。链式流程按照固定顺序运行：步骤A导致步骤B，步骤B导致步骤C，然后就结束了。而循环是动态的。代理可能从A到B，发现B没有奏效，调整方法后再前往C，或者可能完全回到A。MindStudio对这个概念的解析非常直接：循环将持续到任务真正完成、触发停止条件或代理确定无法继续为止。这与"只问一次，得到答案，复制出来"的工作方式有着根本性的不同。

另一个值得深思的框架是“递归目标”理念。与其逐个输入下一步骤，不如定义一个目标——例如“让测试套件通过”或“对所有开放问题进行分类并为简单问题起草修复方案”——然后代理会自主迭代以实现该目标：检查代码、做出修改、运行验证、阅读结果、决定下一步行动。技能重心从写出一句精准的指令，转变为设计一个你足够信任的循环，可以放心离开让它自行运作。

这个概念为何一夜之间成为热门术语

有必要具体说明时间线，因为速度本身就是故事的一部分。

2026年6月7日，以OpenClaw代理项目闻名的开发者Peter Steinberger在X平台发文称，相关技能已经发生转变：你不再应该直接提示编码代理，而是应该设计那些能代表你去提示代理的循环。据报道，该帖子在数天内浏览量突破650万次，并在随后一周主导了代理相关的讨论。

次日，谷歌工程师兼作者Addy Osmani发表了一篇题为《循环工程》的论文，对Steinberger的观点进行了具象化阐述：自动化、工作树、技能、连接器、子代理，以及所有这些之下的第六要素——外部记忆。正是这篇论文，将一个病毒式传播的观点转化为其他人可以构建和争论的术语体系。

这并非仅是外部人士在推动这一概念。Anthropic公司Claude Code项目负责人Boris Cherny被Osmani引用时表示：“我不再直接提示Claude。我设置了持续运行的循环来提示Claude并决定该做什么。我的工作就是编写这些循环。”当市场中使用最广泛的编码代理之一的开发者表示他已停止直接提示代理时，这一理念显然已超越了边缘观点的范畴。

当你观察其背后的变化时，这一时间节点就显得合情合理。到2026年中叶，编码代理已足够成熟，能够真正长时间无人值守地运行，在过程中自行纠正错误，而不再需要每一步或每隔几步就进行人工修正。一旦单次代理运行可以持续一小时并处理数十个文件，瓶颈就不再是提示语的精准度，而是你是否构建了能让代理持续高效运作、保持受控并始终指向正确目标的循环——包括在无人监督时的那部分运行。

上下文工程在2025年出现。关注点从词语本身转向模型在响应时实际看到的所有内容：对话历史、检索到的文档、工具输出以及为该步骤准备的任何其他信息。2025年年中，Shopify的Tobi Lütke提出了一项被广泛接受的定义，将其描述为为模型提供完成任务所需的全部上下文信息。同年，Andrej Karpathy也支持了类似的表述，到2025年9月，Anthropic将这一概念正式化为：在推理过程中精心挑选和维护最佳的标记集合。提示工程实际上成为上下文工程中的一个组成部分，而非独立的学科。

Harness工程在2026年初出现，当时智能体开始在真实的生产环境中执行更长、更自主、多步骤的任务。Harness是智能体的完整环境——包括支撑结构、提供的工具、运行的约束条件以及捕捉其错误的反馈循环。它使智能体从“有能力”变为“可信赖”，并将之前的各层结构都包含其中：Harness包含上下文，而上下文包含提示。

循环工程是位于这三者之上的层级。Harness工程关注智能体需要什么环境，而循环工程则提出一个更具体、更操作性的问题：什么循环能让智能体持续朝着目标前进，这个循环又在何时停止？这些层级并未取代前一层级。你仍然需要编写提示，仍然需要整理上下文，仍然需要构建Harness。循环工程只是将所有这些内容投入运行并赋予节奏的部分。

工程堆栈的每一层都包裹并包含之前的层。

背后研究的脉络

尽管“循环工程”听起来像是在2026年6月某一周突然出现的新概念，但其背后的机制已有近五年历史。了解其发展脉络，是真正理解这一概念与单纯重复行业趋势的关键区别。

直接的前身是2022年由Yao及其团队在普林斯顿和谷歌相关研究中提出的ReAct模式（Reason plus Act的缩写）。其核心思想是将推理步骤与行动步骤交织在一起：模型思考该做什么，采取行动，观察实际发生的情况，根据观察结果再次思考，然后再次行动。这种交织——推理、行动、观察、重复——构成了现代编码智能体仍在使用的最基本循环。

一年后，Shinn及其团队在2023年提出的Reflexion为ReAct模式增添了新的元素：记忆和自我批评。Reflexion风格的智能体运行三个不同的角色而非一个：执行任务的Actor、评估结果的Evaluator，以及撰写实际口头教训的Self-Reflection步骤——例如“补丁失败是因为导入路径错误”——并将这些教训写入智能体在下一次尝试时会读取的情景记忆中。这就是在单次会话中可见改进的循环机制，无需重新训练底层模型。

Anthropic 自己的 2024 年 12 月指南《构建有效代理》中提到了另外两个值得关注的模式。评估器-优化器模式中，一个模型生成候选解决方案，而第二个模型根据明确的标准检查它并提供反馈，直到评估真正通过为止。协调器-工作者模式中，一个中央模型会动态地将大任务拆分为小块，将每一块分配给自己的工作者，并提供干净的上下文窗口，然后将结果合并。如果 Osmani 的“子代理”和“工作树”听起来耳熟，这就是同一概念的正式版本。

逐一分析这四个要点并不是为了琐碎的细节。关键在于，“循环工程”是一个产品名称，也是一个研究方向的口号，这个方向自 2022 年以来一直在默默积累成果。2026 年 6 月的时刻并未发明循环，但它为普通开发者——而不仅仅是研究人员——提供了一个理由和词汇，让他们有意识地开始构建循环。

循环的结构

剥离品牌包装后，一个真正可靠（而非空转或无限运行）的循环通常包含相同的几个组件，无论使用的是哪种工具或团队构建的。

• 它需要一个真正可测试的终止条件。像“让应用更好”这样的目标，给代理没有任何可以检查的依据，因此它要么无限运行，要么基于猜测随意停止。“让认证模块中的每个测试通过”在字面和机械意义上都是可检查的，这种差异就是关键所在。

• 它需要能够真正接触真实环境的工具集：代码执行能力以查看某物是否运行，文件系统访问权限用于读写，终端用于执行命令，测试运行器和代码检查器用于生成诚实的反馈。循环的反馈可信度取决于生成它的工具。一个能出色推理但无法运行自己代码的代理，只是在多加几步猜测。

• 它需要上下文管理。每次循环迭代都会在记录中添加更多内容——编写的代码、遇到的错误、沿途做出的决策——而上下文窗口的大小是固定的。如果未妥善管理，长时间运行的循环要么会超出窗口容量，要么更隐秘地随着记录增长而对真正重要的内容关注减少，这种现象人们越来越称之为“上下文腐烂”。

• 它需要明确的终止和升级逻辑：真正的成功条件、真正的失败条件（最大迭代次数、令牌或时间预算、重复的相同错误且无进展），以及明确的将问题转交给人类的路径，而不是继续在死胡同上浪费资源。

• 它需要真正能区分可恢复问题（如错误的导入、失败的断言）和硬性阻塞问题（如缺失的凭证或未定义的 API）的错误处理。在完全相同的错误后重复执行完全相同的动作，说明循环并未适应，而是在空转。

具有两个真正退出路径的循环核心流程：验证成功和人工升级。

伪代码中的循环

将上述结构视为实际结构而非名词列表后，更容易理解其本质。这是当今几乎所有生产环境中使用的循环的底层骨架，已简化为基本要素并附有大量注释：

state 保存了目标本身以及到目前为止尝试过的内容的运行草稿；这会在每次迭代中反馈给模型

state = init_state(goal) for step in range(MAX_STEPS):

设置硬性上限以确保循环不会无限运行

thought = model.reason(state) # ReAct 的 "reason" 部分：先思考再行动 action = model.choose_action(state) # ...然后选择一个具体的工具调用 result = tools.execute(action) # 实际与环境交互：运行代码、读取文件、调用测试运行器等 state = update(state, thought, action, result) # 将结果反馈到状态中 state = compact(state) # 总结或修剪旧步骤以防止上下文窗口溢出 if verifier.passes(state): # 确定性检查，而非自我报告 return success(state) if no_progress(state) or budget.exhausted(): return escalate_to_human(state) # 停止在死循环中打转

步数耗尽且未通过验证时，返回给人类处理

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

state 保存了目标本身以及到目前为止尝试过的内容的运行草稿

这会在每次迭代中反馈给模型

state

=

init_state

(

goal

)

for

step

range

MAX_STEPS

:

设置硬性上限以确保循环不会无限运行

thought

model

.

reason

ReAct 的 "reason" 部分：先思考再行动

action

choose_action

...然后选择一个具体的工具调用

result

tools

execute

实际与环境交互：运行代码，

读取文件、调用测试运行器等

update

,

将结果反馈到状态中

compact

总结或修剪旧步骤以防止

上下文窗口溢出

if

verifier

passes

确定性检查，而非自我报告

return

success

no_progress

or

budget

exhausted

escalate_to_human

停止在死循环中打转

步数耗尽且未通过验证时，返回给人类处理

在循环工程中，几乎所有有趣的设计决策实际上都是关于这个框架中某一行代码的决策。verifier.passes 的具体定义——通过的测试套件、干净的代码检查、人工手动批准等——决定了循环中“完成”的概念是否有实际意义。compact 的实现方式——是将旧步骤总结为简短笔记还是直接删除——决定了循环能否持续足够长时间完成真实任务。no_progress 的检测方式——通常通过发现最近几步重复出现相同错误或状态未发生变化——决定了卡住的代理是否会悄无声息地消耗你的令牌预算一小时。模型本身几乎被视为中间固定组件。围绕它的所有内容才是工程的核心。

人们实际部署的构建模块

上述伪代码是这个概念的纯粹形式，但 Addy Osmani 对 Codex 和 Claude Code 实际部署内容的分析则是更具体、工具层面的实现版本，值得直接深入探讨。

自动化是系统的核心：它按照预定时间表或响应事件触发，无需人工干预即可启动运行。在 Codex 应用中，自动化功能位于“自动化”标签页，用户选择项目、提示词和执行频率后，结果会进入一个分类收件箱而非直接进入个人收件箱。Claude Code 通过计划任务、cron 和钩子实现相同功能，还有一种值得单独了解的会话内原语——/goal，它能让代理持续执行直到你设定的条件被验证为真，且由一个独立的小模型检查完成状态，而非执行任务的模型自行评估输出。

工作树解决了当多个代理同时访问仓库时出现的冲突问题。Git 工作树是基于独立分支的单独工作目录，仍共享相同的仓库历史记录，因此一个代理的修改无法物理覆盖另一个代理的修改。目前两大主流编码代理都原生支持此功能，这很重要，因为不使用此功能并行运行代理时，与两名工程师在未沟通的情况下同时推送相同代码行的困扰完全相同。

技能是防止项目在每次会话中都从头开始重新解释的关键。技能本质上是一个包含 SKILL.md 文件的文件夹，其中描述了规范、构建步骤和“由于某次事件我们不采用这种方式”的知识，这些信息能让新代理无需猜测即可直接获取。只需编写一次，后续每次运行都会自动读取而非重新推导。

基于 MCP 构建的插件和连接器，让循环能够突破文件系统限制，接入实际工具——问题跟踪器、数据库、预发布 API 和 Slack 频道。没有它们时，循环只能告诉你它会做什么；有了它们，循环就能真正执行操作。

子代理将编写者与检查者分离，基于一个合理的理论：模型对自己作业的评分通常较为宽松。第二个代理（有时运行完全不同的模型）会在代码发布前，根据规范检查第一个代理的输出。

构建模块

在循环中的作用

重要性

自动化

按计划或事件触发运行

将一次性会话转化为重复性任务

工作树

在独立分支上隔离并行代理

防止代理相互覆盖修改

技能

在对话之外存储项目知识

避免每次运行都重新推导上下文

插件/连接器

通过 MCP 将代理连接到真实外部工具

让循环真正执行操作，而不仅仅是描述

子代理

分离编写代理和检查代理

捕捉原代理自我说服产生的错误

外部状态

模型之外的 Markdown 文件或跟踪看板

模型会在运行间遗忘；记录会永久保留

最后一行往往容易被低估。模型本身在运行间没有记忆，因此循环学到的任何内容都必须存储在持久化介质中——文件、看板或日志——以便下一次运行能自行读取。这听起来似乎过于简单而无关紧要，但事实上，这正是所有长期运行代理设置最终依赖的相同技巧。

常见循环模式及其适用场景

并非所有任务都需要相同类型的循环，选择错误的模式是浪费 token 和引入不必要的复杂性的常见原因。

重试循环是最简单的版本：尝试某件事，检查是否成功，如果不成功则重试。它适用于短小且原子化的任务，有明确的成功或失败界限——例如针对已知测试编写函数，或生成需要符合规范的输出。需要关注的失败模式是：无限次重复相同的错误方法，而没有改变策略。

计划-执行-验证循环首先生成一个计划，然后逐步执行该计划，每一步都检查完成情况后再进入下一步。它适用于顺序至关重要的多步骤工作，早期错误会累积影响整体——例如重构共享模块，或搭建新服务。此处的风险是：过于坚持一个计划，当两步之后发现计划错误时才进行修改，而不是更早调整。

探索-缩小循环会尝试多种方法（同时或依次进行），并根据哪种方法产生最佳中间信号进行收敛。这种模式适用于真正陌生的领域：调试前所未见的错误，或探索不熟悉API的实际行为。代价在于上下文：同时运行多个路径成本高昂，因此在此处比任何其他地方都更需要尽早频繁地进行剪枝。

人机协作循环应被当作真正的模式单独命名，而不是作为其他模式的备用方案附加处理。代理运行直到遇到真正的歧义或具有实际影响的决策终点，此时会暂停并等待人类介入后再继续。当错误假设的代价高昂时（如生产数据库变更或面向客户的重要决策），这是最佳选择。其失败模式与其他模式相反：过于频繁地中断，以至于人类实际上并没有通过代理循环节省任何时间。

为生产系统堆叠循环

到目前为止的所有内容描述的都是单个循环的单次运行。生产系统通常会将多个此类循环堆叠在一起，而LangChain对此的描述是一种真正有用的视角，他们通过内部文档编写代理的实例贯穿始终说明了这种堆叠方式。

• 第一层是代理循环本身：模型反复调用工具直到任务完成。对于文档编写代理来说，这意味着接收改进建议请求、规划变更，并使用工具克隆仓库、读取文件、编写更新后的文档并提交拉取请求。

• 第二层是围绕第一层的验证循环。代理的输出并非总能在第一次尝试时就完全正确，因此需要一个评分器——有时是确定性检查，有时是另一个作为评判者的模型——根据评分标准对结果进行评分，并在不达标时返回具体反馈。对于文档代理来说，评分器会运行测试确认每个链接都能解析、所有CI检查都通过，且差异仅涉及实际请求的修改部分。这种权衡是真实的：验证会增加每次运行的延迟和成本，但当质量比速度更重要时（这描述了大多数生产用例），支付这个成本是值得的。

• 第三层是事件驱动循环，其核心在于集成层——将代理与周围系统连接，使其持续运行，而不仅仅依赖于人工触发。当事件发生时（例如新文档到达、计划触发、webhook到达），代理会作为大型系统中的常驻组件自动运行，而非需要人工手动启动的工具。在LangChain的示例中，文档代理会在特定Slack频道收到消息时自动触发，无需任何人实时决定何时运行。

• 第四层，按LangChain的说法也是最重要的一层，是爬坡循环。这层实现的是改进的自动化，而不仅仅是工作的自动化。每次运行都会生成一个追踪记录（trace）——记录模型的行为、调用的工具以及评分器的反馈——这些追踪记录能真实反映哪些环节有效、哪些需要改进。爬坡循环会对一批追踪记录进行分析，并根据分析结果直接修改系统本身（例如调整提示语、优化评分器、修正工具描述）。对于文档代理而言，当多个追踪记录指向同一重复问题时，分析过程会自动创建工单请求特定的提示语或工具修改。值得注意的是，反馈路径并非简单返回到循环顶部，而是直接作用于内层循环，使每次外层循环迭代都能让内层循环显著优化。

循环 | 功能 | 影响 --- | --- | --- 代理循环 | 模型反复调用工具直至任务完成 | 自动执行工作本身 验证循环 | 输出根据评分标准打分，失败时提供反馈并重试 | 保证质量和正确性 事件驱动循环 | 真实事件触发运行并更新实时系统 | 在规模上自动执行工作，而非仅按需执行 爬坡循环 | 历史运行追踪数据用于分析并优化系统 | 持续累积性改进

LangChain自身对领域关注点的描述非常坦率：目前大多数团队的精力集中在第一、二层循环，而真正具有价值但尚未充分探索的领域是第三、四层循环——代理不再只是人工调用的工具，而是嵌入系统中能根据真实反馈持续优化的组件。

实际失败的三个难点

如果循环工程有一个核心课程贯穿所有命名和工具设计，那就是三个特定问题。解决任一问题的失误，都会导致循环运行一小时后干净执行，或出现溢出、死循环，甚至悄无声息地欺骗你。

• 上下文管理是第一个难点。上下文窗口作为代理的工作内存，存在硬性容量限制。在长期运行的循环中，每一步都会在记录中追加更多内容（更多思考、更多工具输出、更多错误），若未妥善管理，记录要么直接溢出，要么随着内容增长质量下降，模型对关键信息的注意力会因越来越长的对话记录而减弱。解决方案是在循环内部实施上下文工程：将旧步骤压缩为简短摘要、清理过时输出，并隔离子代理，使子任务在独立干净的窗口中运行，仅返回结论。

• 终止是第二个问题，可以说是最容易造成巨大代价的错误。一个循环需要多个独立的退出机制层层叠加：验证器确认实际目标是否达成、迭代次数的硬性上限、令牌或时间预算限制，以及更微妙的无进展检测机制——用于捕捉最近几次步骤重复出现相同错误或状态未发生实质性变化的情况。缺少这种分层的退出机制时，循环要么无限运行，要么随机停止，这两种情况都不适合需要无人值守运行的场景。

• 验证是第三个问题，本质上是关于信任的考量。黄金标准是确定性验证——测试、类型检查器、编译器、代码检查工具——因为这些工具能返回客观的通过或失败结果，模型无法通过任何方式改变结论。大语言模型作为自身裁判虽然更具灵活性，对于无法机械验证的任务确实必不可少，但这种方式更容易被操纵，模型对自己生成内容进行评分的检查机制本身存在结构性缺陷。最稳健的循环设计会在所有可能的场景中优先使用确定性验证器，仅将模型判断保留给那些确实无法通过其他方式量化评估的任务部分。

当这三个问题处理不当时，会产生一组相当可预测的故障模式。上下文溢出和腐化，表现为窗口填满后输出质量下降却没有任何明显错误提示。无进展循环，表现为智能体无限重复相同的失败操作。目标误定义——有时称为奖励黑客行为——是指循环优化了一个可验证的替代指标而非真实目标；教科书案例是智能体删除失败测试以使CI状态变为绿色。幻觉式成功，表现为智能体声称任务完成却没有任何实际验证支持。以及纯粹的成本爆炸，表现为长时间循环悄无声息地消耗远超任务需求的令牌数量。所有这些问题的根本解决方案都是一样的：在循环内部加入一个真实、外部、确定性的检查机制——而非智能体自身的说法。

人类在循环中仍具不可替代性

以上内容绝不是要将人类排除在流程之外，诚实讨论这一点比将其作为结尾的附加说明更为重要。

自动化评分器可以确认每个链接都能正常解析或每个测试都能通过。但它无法察觉文档的框架设计与实际受众存在偏差，或某些操作敏感到必须有人监督才能执行。这种基于上下文、经验与品味的判断——难以用规则明确表述——正是人类审核的价值所在，上述所有层级的架构中都自然存在这样的检查点。在基础智能体循环中，这意味着在真正敏感的操作（如金融交易或数据库写入）前必须获得明确的人类批准。

在验证循环中，这可能意味着在风险过高、无法仅凭评分标准信任的流程中，由人类直接担任评分者。更进一步，这可能意味着在输出到达最终用户前由人类进行审核，或在变更实际部署前由人类审查拟议的框架修改。这些检查点的添加并不复杂。它们是刻意的设计选择，与循环中其他任何部分的设计原则一致。

循环工程并非意味着什么

直接指出这种反对意见是值得的，因为在该术语最初传播的前几周，过度宣传掩盖了更全面的观点。并非每个开发者都需要在下周二之前就部署自主代理舰队。对于真正的一次性任务，与一个能力较强的代理进行交互式会话通常比围绕它构建完整循环所需的工程开销更快且更安全。将循环工程视为所有类型工作的强制要求，实际上误解了它的真正价值所在。

循环系统并没有将人类的判断从方程中移除；它只是将判断的应用位置进行了转移。某人仍然拥有目标的定义、完成标准的界定，以及对输出是否真正正确的最终裁决权。一个优化了目标定义的循环系统可能会以极高的效率追求错误的目标，而一个没有真实验证机制的快速循环系统只会比慢速系统更快地产生错误答案。真正重要的纪律是：在每个循环周期内都保留真实的外部检查机制（如测试、类型检查或人工审核），而不仅仅是在最后阶段才进行验证。

自行构建小型循环系统

最值得开始的地方是构建上述所有内容的最简版本，而不是之前描述的完整四层系统。一个明确到可验证程度的目标。一个确定性的验证器——实际的测试套件，而非模型的自我评估。对迭代次数设置硬性上限。当循环陷入停滞时，设置一条明确的升级路径，而不是多个半成品的路径。

首先值得选择的任务应该是重复性高且风险极低的工作：例如对新问题进行夜间筛选，生成周活动摘要报告，或对单个目录进行代码格式化和修复。在首次构建的简单循环系统稳定运行数周之前，要抵制使用并行工作树、子代理或完整爬山算法层的冲动。本文之前描述的分层系统是团队在确认基础循环系统的验证器真正符合预期后才会构建的，而不是在第一天就直接搭建的。

结论

所有这些变化背后真正的转变并非工作变得更简单，而是杠杆点发生了移动。当模型能够自行编写代码时，稀缺技能不再是如何表述一条精准指令，而是如何设计一个在无人监督时仍能保持正确性、可验证性并始终指向正确目标的循环系统。这属于系统工程领域的习惯，更接近设计恒温器的思维，而非撰写句子的技能。这也正是最了解这项工作的人坚持称之为“工程”而非“技巧”的原因。

构建循环系统。但要以一个打算长期担任工程师的人的方式构建——检查它生成的内容，理解它为何在特定位置停止，将“完成”视为需要验证的主张，而非可以轻信的结论。

更多相关内容

/.entry /think