说“检验器是瓶颈”，只说对了一半
名字只是给问题贴标签。造检验器这件事，仍然是你的功课
开篇
几年前，这项工作还只有一个名字：提示工程（Prompt Engineering）。就是不断修改一句话，直到模型按你想要的方式动起来。去年，同样的工作被冠上了新名字：上下文工程（Context Engineering）；今年在各个讨论串里，它又被叫作循环工程（Loop Engineering）。每次换名字，后面都跟着同一句话：“现在的瓶颈不是模型，而是检验器。”
每次改名，开发者的反应都一样：“这是真的变了，还是只是为了卖一门课程而重新刷了层漆？”这种怀疑大体上是对的。AI工具的术语更替速度，远远快于它所指向的问题本身。
所以我打算一层层拆开来看。先说结论：**每次改名，“你在工程化的单位”确实变了。变的不是漆，而是工作对象本身。**只不过，最新这个名字所指向的问题是真实的，而名字本身只是给这个问题贴了标签，并没有把它解开。
单位曾经是“提示”
先把2022年到2024年划为一段。那时工作的单位是单条提示。也就是打磨一句请求文本。放入少样本1示例，赋予角色，加上“请逐步思考”，调整先问什么后问什么的顺序。你所能掌控的整个表面，就是那一条消息里的文本，把它写好，就是这门技艺的全部。
回头看，那个年代的经验几乎都可以归结为“一句话该怎么写”。放几个示例、按什么顺序发问、如何赋予角色。这种直觉到今天依然有效——好的提示仍然是好结果的起点。变化在于，它不再是“全部”了。因为工作本身已经装不进一条消息里了。
🧩 单位变成了“表面”
2025年年中，Andrej Karpathy给人们已经在做的事情起了个名字：上下文工程。单位从一条消息扩展到了窗口（window）里的一切：系统提示、检索拉取来的文档、工具定义，还有每一轮都要一起装载的CLAUDE.md或AGENTS.md2之类的指令文件。现在不再是打磨一句话，而是要策展一整个表面。
这个表面有一个开发者们付出昂贵代价才明白的特性：放在表面上的东西，大多数并不真正连接到实际行为上。《The State of AI Instruction Quality》用确定性分析器扫描了28,721个代码仓库，**发现指令文件的中位数含有50个内容条目，其中真正的指令只有12条。**其余的都是标题、背景说明，以及模型完全可以无视的结构。
更尖锐的失败方式则单独成文了。《Do NOT Think of a Pink Elephant》指出，以否定形式写的约束（比如“不要写模拟实现（mockup）”）反而可能提高恰恰被禁止的那种行为发生的概率——原因和你现在读到这个标题时脑中浮现出一头粉色大象是一样的。
这两点都是上下文工程的问题，都被测量过，也都被公开发表过。
🔁 单位现在是“循环”
2026年6月，术语变成了循环工程。Addy Osmani把Boris Cherny和Peter Steinberger的讨论整理并传播出去，几周之内就传遍了整个时间线。**现在的单位是一个不断转动的循环：生成、检查、纠正方向、重试、停止。**提示成了循环里的一个节点，上下文表面则成了循环在每次迭代之间搬运的状态（state）。
（配图：提示 → 模型生成 → 检验器（这样够了吗？）→ 停止。检验器有一条回到“纠正方向并重试”的环路，上下文表面与模型生成一起被纳入其中。）
所有解说文章反复强调的说法是这样的：现在划定边界的不再是模型，而是决定“这样就够了，停”的检查环节。让我们大方地接受这个名字。前两个名字含糊带过的东西，这个名字正面指了出来：判定某一次迭代是否合格、要不要再跑一轮的那个装置。这个装置一直都在——任何会重试的智能体都有它。循环工程真正添加的，是把这个装置从一个被动继承的默认设定，提升为你需要亲自设计的对象。
🔑 那么检验器到底在检查什么？
“检验器是瓶颈”是句好口号，也是半句话。它指出了瓶颈在哪，却没说这个检验器到底该检查什么。那个空白，正是这句口号所跳过的工程问题。
检查分为两种，彼此不能互换。确定性检查3会执行代码、确认退出状态、扫描是否存在被禁止的导入项，同一输入永远给出同一判定，中间不掺入任何判断。基于模型的检查4则是去问另一个模型：“这样行吗？”它能触及第一种方式无法表达的标准——比如“这段说明是否清楚”、“这句话读起来是否显得无礼”。但代价是，它会原样继承循环本来想要圈住的那种不稳定性。换句话说，把一个概率性生成的结果何时算完成，交给了一个同样是概率性判断的裁判。
来看实际循环中两者分道扬镳的那一点。假设你让智能体重构一个模块，做完就停。确定性检验器可以证明测试是否依然通过、是否偷偷混入了被禁止的导入项——这是每次迭代都可核实的事实，没有争议的余地。但它无法判断这次重构本身是否值得做。于是为了回答这个问题，你又加上一个基于模型的检查，这时停止条件就变成了建立在“一个模型给另一个模型的品味打分”之上。循环在裁判满意时结束，而这个裁判本身，恰恰属于循环原本要监督的那一类部件。
两者都没有错，它们回答的是不同的问题。一旦你搞混了自己此刻问的到底是哪个问题，循环就会在错误的那一次迭代上，充满自信地停下来。
实务中拿不准时，我会这样划分：“这个标准能不能不问别的模型，而是靠执行或扫描直接得出真假？”如果能，几乎总应该用确定性检查——成本低、不会摇摆、失败时还留有日志说明原因。反过来，如果这个标准只存在于人的脑子里（比如“这段文案是否符合品牌调性”），那就避不开模型判定。这种时候，至少可以把判定标准拆成更细的颗粒，让模型按清单逐项作答，而不是自由给出总体评价——这能收窄它摇摆的空间。不是彻底取消判断，而是压缩判断能摇摆的余地。
这个权衡——也就是“检查究竟检查了什么”——并不是新问题。《Green Tests Don’t Mean Better Software》给出了它在CI（持续集成）语境下的版本。**通过的测试只能证明代码符合规格，却对这次改动是否真的让系统变得更好，什么都没说。**检查回答了一个你根本没有提出的问题。把同样的区分从测试套件转到智能体循环上，循环工程的问题，正好可以借每个开发者早已信任的这个例子来阐述。
Oswarld视角
老实说，这个名字让我既高兴又谨慎。
长期做GTM策略，我见过太多次这种模式：“技术会改变一切”这种预言大体是对的，只是时机和路径几乎全错。每次冒出新术语，我都会先怀疑一遍这个模式。**但这一次的三度改名有点不一样。每次改名，真正动了的不是营销话术，而是工作对象本身。**从一句话到一个表面，再从表面到一个循环。所以我把这几次改名归到诚实的那一边。
不过这里有个需要冷静看待的地方。名字给你的是一个“对象”。**造检验器的活儿，仍然是你自己的功课，而且这占了整个工作的大部分。**你得为某项任务定义什么叫“对”，再把它变成一个可以运行的检查。
这项工作的一半，就是选对检查的种类。用处理数据的老习惯来看，这其实是个测量设计问题。“这段说明是否清楚”，需要模型来判断；“没有被禁止的导入项”，用确定性扫描就够了。选错了，两边都要付出代价：本该用确定性检查的地方交给模型裁判，等于白白买了一份不稳定性；而在需要判断的地方硬塞确定性检查，得到的绿灯看起来漂亮，实际意义却很浅。名字只是让这个选择变得可见，并不会替你做出选择。
结语
总结一下。**第一，名字从提示到上下文、再到循环的变化，不是刷漆，而是被工程化的单位确实在变大。**第二，“检验器是瓶颈”是对的，但只对了一半，另一半是这个检验器到底检查什么、用什么方式检查。第三，名字只会给问题贴上标签，造检验器这件事，仍然原样留在你的功课清单上。
这个循环由多个部件组成。接下来几期，我打算把这个循环一块一块拆开，在每一块下面各自铺上一套测量方式：怎样区分“在错误的地方响起的检查”和“根本不存在的信号”，纠正方向的规则和拒绝的规则有什么不同，上下文表面上的一条指令每一轮到底要花掉多少成本。今天这篇文章提出的问题，就是后续几期的出发点。
如果你亲自跑过智能体循环，你的停止条件用的是确定性检查，还是交给了模型裁判？在哪里栽的跟头最大，欢迎在评论里告诉我，我会把它写进下一期的素材里。
💬 欢迎在评论里聊聊你是如何设计停止条件的 · 📨 如果身边有在做智能体的同事，请把这篇文章转发给他们
参考资料与延伸阅读
核心来源
- reporails，《The State of AI Instruction Quality》。：指令文件中位数含50个内容条目、实际指令只有12条这一数据的出处。
- cleverhoods，《Do NOT Think of a Pink Elephant》。：否定形式约束反而提高被禁止行为概率这一论点的出处。
- reporails，《Green Tests Don’t Mean Better Software》。：检查回答了一个未被提出的问题这一论点的出处。
- cleverhoods，《Prompt Engineering, Context Engineering, Loop Engineering: What Actually Changed》。：今天这期通讯所依据的原始骨架来源。
背景知识
- Andrej Karpathy，“上下文工程”命名（2025年年中）。：这个术语出处的起点。
- Addy Osmani，“循环工程”整理（2026年6月，综合Boris Cherny与Peter Steinberger的讨论）。：今天这篇文章中第三个名字传播开来的路径。
值得一起阅读的往期
- （如果有主题上真正相关的往期，请在此处放置链接。例如：如果有一期讨论过上下文窗口、指令文件，可以在此关联。）
📝 术语说明
作者安光涉是世宗大学经营学教授，也是 OBF（Oswarld Boutique Consulting Firm）首席顾问。他在大学教授经营数据管理、商业分析等统计与数据分析课程，同时在产业现场负责 GTM 与人工智能战略咨询，设计技术与商业的连接方式。他曾发表关于 AI 对话系统记忆架构（HEMA）的学术论文，并运营每日策展全球 AI 论文的 Daily Arxiv 项目。他毕业于高丽大学技术经营专业研究生院与 KMBA，著有《把思考交出去的人：Homo Brainless》。