循环工程：从提示词输入者到系统设计者的 20 步转型路径

阶段二：构建第一个循环（步骤 5 至 9）

步骤 5：在编写任何提示词前先写下完成定义

这是大多数人跳过的步骤，也是决定后续一切是否有效的步骤。在为智能体编写单条指令之前，请用平实的语言准确写出正确结果的样子。具体的、可检查的标准，而不是模糊的质量感觉。

[任务名称] 的完成定义：
- [具体可检查标准 1]
- [具体可检查标准 2]
- [具体可检查标准 3]
即使输出看起来完整或精美，如果缺少上述任何一项，则该任务未完成。

如果无法为选择的任务填写此内容，请返回步骤 4 并选择另一个任务。

步骤 6：将构建者与裁判者分离

这是任何循环中最重要的一项架构决策。产生工作的角色和检查工作的角色必须分开，因为在产生输出的同一语境中审查自身输出的模型，往往倾向于捍卫该输出，而不是对其进行真正的审查。

构建者获得创作自由并产生第一次尝试；裁判者获得构建者的输出以及步骤 5 中的完成定义，并且不需要任何说服性的辩解。 理想情况下，裁判者还可以访问构建者无法访问的内容，如测试套件、原始源文档、实时数据，因此其判定来自真实证据，而不仅仅是形成方式相同的第二个意见。

步骤 7：给裁判者提供真实凭据，而非仅仅是主观意见

仅能看到构建者输出的裁判者可以告诉你它看起来是否连贯，但无法告诉你它是否真正正确。对于编码任务，真实凭据（Ground Truth）是测试套件和实际执行输出。对于内容任务，它是原始源材料和简报并排放在一起。对于研究任务，它是应该使用的实际文档。

如果无法指定裁判者将根据其进行检查的具体真实凭据，那么无论裁判者的语言听起来多么自信，你的循环都还没有真正的校验。

步骤 8：在编写交接提示前先写下交接格式

构建者的输出和裁判者的判定都需要一个定义的结构，而不是自由流动的散文，否则下一步中的管理者就没有可靠的路由依据。

BUILDER OUTPUT: deliverable + confidence + known uncertainties
JUDGE VERDICT: PASS / FAIL / NEEDS REVISION + specific issues found + what ground truth this was checked against

步骤 9：在自动化任何事情之前，手动完整运行一次

在连接调度或自动重试之前，请亲自手动运行一次完整的 Builder-then-Judge 流程。批判性地阅读裁判者的判定。你同意吗？如果裁判者通过了你知道是错误的内容，或者未通过实际上没问题的内容，请在继续之前修补真实凭据或标准。自动化一个被破坏的校验步骤只会更快地产生破坏的结果。

步骤 5 到 9 的实操案例

为了使过去五个步骤具体化，以下是它们在真实常见的任务中的演练方式：将原始源文档转变为成品内容。

步骤 5 中的完成定义：草案中的每个事实主张都可以追溯到源文档中实际存在的内容；草案满足简报中的每项具体要求（长度、语气、所需结构）；核心论点清晰存活，未被填充物稀释。

步骤 6 中的构建者接收源材料和简报并制作草案，同时明确说明在撰写过程中不确定的内容：例如不完全确定是否在源材料中的数字、推断出的主张而非明确阐述的主张。

步骤 7 中的裁判者并排接收草案和原始源材料，绝不单独接收草案，并分别检查三个完成定义标准中的每一个，对每一个标准单独返回通过或失败，而不是一个混合的整体分数。将三个不同的检查折叠成一个单一判定会掩盖到底哪一个维度失败了，这是正常运行的循环默默停止给出有用反馈的最常见方式。

步骤 8 中的交接格式意味着裁判者的判定作为一个结构化对象到达，而不是一段防御性的散文：三个显式的通过或失败结果，任何失败都附有具体的原因。

按照步骤 9 在自动化任何内容之前手动运行一次，可以捕获裁判者过于宽容的情况（例如因为写作风格精美而通过了包含虚构统计数据的草案），或者过于严格的情况（例如因为简报中从未要求过的风格偏好而否定了草案）。这两种失败模式在第一次尝试中都很常见，而且手动捕获一次的成本远低于在循环已经无人值守运行五十次之后才发现的成本。

阶段三：添加循环缺失的组件（步骤 10 至 14）

步骤 10：构建管理者及其停止条件

管理者（Manager）读取裁判者的判定并决定接下来发生什么。这也是循环停止条件的所在地，它必须编写为硬性逻辑，而不是模型可以自行规避的软性指令。

STOP CONDITIONS:
- 最大修改次数：3次。在第 3 次失败判定时，带着完整历史记录升级交由人工处理，不要尝试第 4 次循环。
- 质量门槛：完成定义中的每个项目都必须显示 PASS。
- 预算上限：如果此任务超出 [X] 成本或 [Y] 时间，无论当前状态如何，立即停止。

没有真正停止条件的循环不是一个系统，而是一个等待任务被证明真正无法解决的那一天到来的隐患。 软性指令在这里失效的具体原因值得理解而不仅仅是接受。提示词内部的“在足够好时停止”只是一种建议，而在足够的压力下，已经失败了多次修改的模型往往会说服自己相信当前的尝试足够接近通过，恰恰是因为它渴望为任务给出一个令人满意的解决结果。由代码机械检查的硬性迭代计数器，或者管理者无法通过逻辑绕过的硬性规则，不会出现这种失效模式。

步骤 11：添加持久化，使循环在多次运行之间保持记忆

每次运行都从零开始的循环无法记住上次学到的内容。添加一个简单的持久化层，每个真正全新的教训一个文件，顶部有一行摘要，记录学到或更正的内容及其重要原因。至关重要的是，只记录其他地方尚未捕获的内容，重复的记忆是噪音而非知识。

使该步骤长期有效的纪律是写入时的克制。本能反应是记录会话中发生的所有事情，这恰恰产生了步骤 2 中警告过的过大转录问题，只是将其移到了记忆文件夹而不是提示词中。值得写下的教训是如果遗忘需要付出真实时间重新发现的内容，而不是按预期成功完成的日常工作记录。

步骤 12：按计划添加整理 Pass

单靠持久化最终会产生与过大提示词相同的问题：数十个文件，许多都在表达同一事情略有不同的版本。按照定期计划（每周一次是合理的），审查记忆文件，将重复项合并为单个更锐利的教训，并删除此后证明是错误的内容。目标是更少的文件以及每个文件更高的密度，而不是不断增加的堆积。

这个步骤是大多数人完全跳过的步骤，因为它本身不产生可见的新能力，它只是防止未来的问题。这种隐形性恰恰是为什么需要显式调度它，而不是留到有人注意到记忆文件夹变得笨重时才去做——在实践中这意味着直到循环的性能已经在同样竞争上下文窗口的相互矛盾、半相关教训的重压下开始下降之前，它永远不会发生。

步骤 13：添加检索步骤

在任何新运行开始时，让循环扫描记忆中的单行摘要，识别哪些教训实际上与当前任务相关，并且只加载这些教训。显式指示它在记忆中没有任何适用内容时声明这一点，而不是仅仅因为记忆存在就将不相关的过去教训强行套用在新情况上。

步骤 14：添加调度触发器

决定在没有你手动启动的情况下此循环何时运行。Cron 任务、文件监听器、循环日历驱动的触发器。这是将按需运行的系统转变为在你睡觉时运行的系统的步骤，它通常是这整份列表中最简单的步骤。

阶段四：扩展与加固（步骤 15 至 18）

步骤 15：在信任循环之前对其进行压力测试

在依赖此循环处理任何真实事物之前，请故意针对四种失效模式进行测试：

1. 赋予它一个真正无法解决的任务版本，并确认管理者确实停止而不是永远循环，因为仅在可以完成的任务上进行测试的循环从未证明过它知道如何优雅地失败。
2. 向裁判者提供一个你知道有微妙错误输出的内容（写得很好但包含你故意放置的具体事实或逻辑错误），并确认它确实抓住了缺陷，而不是通过听起来合理的内容。
3. 如果构建者和裁判者共享相同的底层模型，请向裁判者提供该模型特有的错误，看看它是否会让错误通过，因为共享构建者盲点的裁判者击败了步骤 6 分离的整个目的。
4. 使用最昂贵的模型调用和最长的合理输出，计算循环运行到最大修改限制的最坏情况成本，并诚实决定Real账单上的这个数字是否会让你惊慌。

在以任何重要事项信任循环之前运行这四种测试，可以捕获绝大多数失败。

步骤 16：将任务路由到最合适的模型，而非每次都使用同一个模型

一旦循环工作，请抵制在单一最喜欢的模型上运行其每个部分的习惯。构建者角色通常从能力强的模型中受益，因为它在进行实际的困难推理，这里较弱的模型会产生更差的初稿，修复它所需的修改循环成本高于第一次就生成良好的成本。

裁判者角色按照具体的书面标准进行检查，在更小、更便宜、 faster 的模型上往往表现得同样可靠。 因为它不需要发挥创造性，只需要保持一致性，并且针对极具针对性的清单进行检查的较小模型通常以成本和延迟的极小碎片匹配较大的模型。

管理者路由基于你已经写下的规则，几乎不需要最昂贵的模型，因为它的工作是执行你已经指定的逻辑，而不是开放式的推理，并且无论构建者和裁判者如何表现，它每次迭代至少运行一次，这使得其单次调用成本比其原始能力更重要。

这种分层方法——用于构建的高昂模型、用于常规检查的标准模型、用于路由的便宜模型——通常是循环中真正节省成本的地方。大多数人假设成本控制意味着更少的循环或更少的修改。它实际上来自于将模型成本与已构建循环内各个特定角色的实际难度相匹配。

步骤 17：扩展至第二个循环，而非一次构建五个

一旦第一个循环工作，诱惑是立即构建更多循环，并行解决五个不同的任务，因为架构现在在技术上支持它。抵制这种诱惑的时间要比感觉舒适的时间更长。让一个循环运行得足够可靠，以至于你已经真正停止密切检查其输出，意味着它在一段真实的时间内持续通过你自己的手动抽查，而不仅是一次大家密切关注的成功演示运行。只有这样，才开始针对不同任务启动第二个循环，理想情况下映射到与第一个完全不同的事情上，这样你就在测试底层骨架是否具有通用性，而不仅仅是进一步调整相同的任务。

步骤 18：为所有运行中的循环建立统一全局视图

一旦有多个循环在运行，请跟踪所有循环的成本和停止条件触发器的统一视图，而不是孤立地跟踪每个循环。单任务预算合理的单一循环孤立看起来完全没问题。十个各自在预算内的循环加起来仍可能达到惊人的总量，而在收到汇总账单之前没有人注意到，恰恰是因为每个单独循环的跟踪孤立看起来都没问题。

具体记录每个停止条件触发器，而不仅是成功的完成。一个不断达到修改上限的循环，而其他循环很少达到，是在告诉你它的裁判标准校准不当——要么太严格以至于无法真正通过，要么完全根据错误的真实凭据进行检查——而不是底层任务本身困难。如果你只跟踪成功并将每次升级视为孤立无小的事件，而不是关于该特定循环设计的具体数据点，那么这种模式是不可见的。

阶段五：成为系统设计者（步骤 19 和 20）

步骤 19：停止以撰写提示词的数量衡量自己

转变真正发生的明确迹象是日常关注点的变化。提示词输入者跟踪编写了多少好的提示词；系统设计者跟踪有多少循环在运行、每个循环的可靠性如何，以及不再需要监督的系统为你返还了多少你自己的时间。如果你仍然以输入的提示词数量衡量自己的生产力，那么步骤 1 的观念转变尚未完全落地，无论你在技术上构建了多少个循环。

步骤 20：向他人传授“五步动作”

最后的步骤不再关乎你自己构建的系统，而是通过向其他人解释它而无需借助行话，来确认你是否真正内化了这一转变：探索、交付、校验、持久化、调度。 如果你仅使用这五个动作和上述步骤引导另一个人构建他们自己的第一个循环，你就完成了这份路线图所描述的真正转变。你不再是循环内部输入下一条指令的人；你成了站在外面看着它运行的设计者。

跳过步骤会悄然累积的四大成本

最后有必要提出警告，因为在路线图中跳过步骤不会大声失败，而是悄无声息地失败，其方式只会在很久以后显现。

校验债务（Verification debt）会在跳过步骤 6 和 7 时累积，构建没有真正裁判者或没有真正凭据的循环。循环看起来在工作，因为输出看起来不错，直到错误在无人察觉的情况下在数十次运行中默默复合。

理解腐化（Comprehension rot）会在跳过步骤 20 时发生，运行你构建了一次但如果它们被破坏就无法再解释或调试的循环，因为你从未必须内化为什么每个部分都存在。

认知妥协（Cognitive surrender）发生在步骤 1 从未真正落地时，即在校验系统已经证明自己之后很久，你仍出于习惯继续手动双重检查每个输出，从而打败了构建系统本身的意义。

Token 爆表（Token blowout）是在跳过步骤 10 时发生的情况，运行没有真正停止条件的循环，只有在账单到达时才发现实际成本。

这些成本中的每一个都是可以避免的，并且每一个都可以通过相同的纪律来避免：按顺序构建步骤，不要跳过那些感觉不够吸引人的步骤。那些无聊的步骤——完成定义、停止条件、真实凭据——才是真正起作用的步骤。那些听起来有趣的部分——巧妙的提示词、精心制作的架构图——远不如你构建的系统是否真正知道自己何时正确、何时错误以及何时停止重要。

这就是提示词输入者和系统设计者之间的全部区别。不是聪明，而是对构建起来枯燥且容易跳过部分的纪律。