聊聊 loop engineering，以及 xxx engineering 为什么出现
这两天刷到一堆讲 loop engineering 的文章，但无非就是推特上的文章翻译翻译，讲讲概念，讲讲技术细节。
看着既让人觉得是在炒概念，也根本看不进去。所以我想从这篇开始，结合自己工作中实际做的事情，尽可能用简单、直白地聊一聊行业中不断出现的这些新概念。
大概在 loop engineering 这个概念被正式提出的前一个月，我便开始了类似的工作。在看到 loop engineering 这个词后，反而还莫名觉得挺贴切，正在做的事情也算有了个正式的概念来概括。
01 loop engineering 是什么
这个概念由 loop 和 engineering 两个词组成，先谈谈什么是 loop。
所谓 loop，说白了就是：把工作中会不断重复的事情，交给 AI 来自动化处理。在我开始构建 loop 前，起初也只抱了一个想法：希望工作中这些重复的工作都可以交给 AI 来解决。
而 engineering，就是确保 AI 在每一次循环中，即使存在大量的变化和此前没见过的问题，也能尽可能贴近“我亲自上手”的质量和标准。
是的，即使是使用当前最强的模型，如果完全任由它自行发挥，一开始大概率也只能得到一个漂移严重、可能只有 20-30 分水准的结果。但在经过 engineering 后，可以达到 80-90 分，并且持续稳定在这一水平，彻底将人从重复工作中解放出来。
02 我搭的两个 loop
在这一个月里，我主要搭了这样两个 loop：
第一个，自动化数据分析 loop，分成每日 / 每周 / 每月三个时间来触发：
- 每天自动化生成：产品核心指标，新订阅 user cases 及分析，退订用户 cases 及分析等等
- 每周自动化生成：周报（产品的数据概览、用户结构、分层下钻、产品改动对数据的影响及归因等等）、token 成本分析等等
- 每月自动化生成：月报，月维度的成本分析等等
第二个，Agent 自迭代 loop，从最初搭建的一套 benchmark 跑测系统，逐渐延伸为：
“benchmark 跑测 → AI 分析 bad cases / 低分 test cases 的服务器日志自动找 bug → 基于 bug 的影响范围和严重程度 define task 和优先级 → 每个 task 产出优化方案和 spec 文档 → human 确认 bug 和优化方案 → AI develop → 新一轮的跑测验证”
这样一整套系统。
实际的搭建过程并不轻松，完全符合了 loop engineering 中 engineering 一词的概念。搭好一个高质量的 loop，这确实是一个工程问题。
03 怎么搭好一个 loop
具体我是怎么做的？下面是我基于这两个 loop 的搭建过程，总结出的一套实践流程。
第一步，把每个环节拆解为最小可执行单元。
每项工作都由一个个环节组成。拿一个简单的数据分析任务举例，比如分析上周的产品改动对核心指标的影响，产出这份报告至少需要知道三件事：
- 上周的产品改动有哪些
- 产品核心指标是什么
- 结合产品改动和数据，写出一份高质量的分析报告
以上三个环节就属于这项任务中的最小可执行单元。
第二步，手把手教给 AI，并把每个最小单元反复迭代到满意。
对人来说，越是简单、越是熟悉的环节（比如获取某个口径的数据），交给 AI 执行时越容易忽略其中的细节，导致 AI 难以产出满意的结果。用上面的三个环节来举例：
- 上周的产品改动有哪些。 想完全自动化，可以读取代码库 PR 的 changelog 来生成产品改动文档。但直接让 AI 生成，就会发现它很容易迷失在代码的细节里，难以从产品视角归纳出功能改动。这时需要产品经理不断和 AI 对齐，把这份产品功能 log 打磨到贴合自己的认知，比如代码和产品功能的关系，不同功能在产品里起什么作用、又会明显影响哪些核心数据和指标。换句话说，必须尽可能跟 AI 讲清楚“代码 - 产品功能 - 核心指标”的关系，并把这些认知以文件知识库的形式存在项目里，持续更新。
- 产品核心指标是什么。 要让 AI 知道核心指标是什么、对产品有哪些意义；每个指标的口径是什么、怎么算、从哪个表的哪个字段取数。因为取数很多时候已经交给 AI 了，对数据准确性的校验就格外重要，必须让它每次都能得到和你此前自己计算 / 看数时一模一样的数字。关于如何通过 AI 来完成数据分析，Anthropic 专门有一篇文章《How Anthropic enables self-service data analytics with Claude》，感兴趣可以去读读。
- 产出高质量的分析报告。 这看起来是结合前两步的上下文，AI 就能生成一个不错的分析报告，但拿到手有时候常常还是差口气。在数据分析上，仍然要告诉 AI 各个指标有哪些下钻维度、怎么分层分类、过程数据怎么获取；在写作上也要立规矩，如结论先行、章节怎么分、大小标题怎么用、每个结论需要哪些点来支撑。
可以说，把每一个单一任务都打磨到接近人的水平，几乎相当于把自己工作中那些有意无意的技巧都倾囊相授。
第三步，将所有环节串起来，在 AI 达不到要求、或需要人较强主观偏好的环节 keep human in the loop。
数据分析的 loop 还好，跑通之后我基本很少再被 involve。但在 Agent 自迭代的 loop，或者说类似的产品自迭代 loop 中，基本每一轮都还需要人工介入。
有标准答案的，放手交给 AI。 数据分析的 loop 就是这类，取数、算指标、按口径出报告，产出可以通过客观数字来验证。所以它跑通之后，我基本很少再被 involve。
没有标准答案/复杂度较高的，keep human in the loop。 Agent 自迭代的 loop，或者说类似的产品自迭代 loop，基本在根据问题产出 Agent 优化方案的环节后，都会进行人工 review 并做出最终决策。一方面是 AI 给出的优化方案很多时候还是只盯着“解决问题本身”。另一方面，agent 的设计其实往往不只是工程 / 算法问题，也是产品问题，甚至商业化问题。很多时候需要在 agent 泛化性、产品效果、token 成本三者之间，找一个最适合产品当下阶段的解。这个解更多时候不是一种标准答案，而是一种平衡和取舍。如何决策也取决于个人对 agent、对产品的 taste。
虽然很多人会期待随着模型能力的提升，每一个环节都可以由 AI 完成，但在那些需要权衡取舍、本就没有标准答案的任务里，人并不会，也不该从这套自我进化的 loop 中缺席。
最后，真正开始动手搭建 loop，以及搭建中要注意什么。
在动手把重复工作搭成 loop 前，建议先把那些你认为需要先学会才能开始的概念忘掉，比如什么 subagent、worktree、hook 等等，这些东西的应用交给 AI 自己调用就行。
把需求和 AI 说清楚，剩下的只要再注意三点：
- 都存成文件。 搭 loop 时用到的一切，都让 AI 存成项目里的文件——这其实就是一套可迭代的知识体系。
- 先跑通，再做 skill。 等 loop 跑通之后再去构建 skill，别一上来就建。
- 持续迭代。 随着新功能上线，对 loop 不断打磨。
至于定不定时、何时触发，完全看个人需求：有固定时间的就定时，没有的就在需要时手动触发。因为 loop 里每个任务都被拆成了最小可执行单元，任何一个也都能在需要时单独触发。
04 为什么每隔一阵就冒一个 xxx engineering
除了这些搭 loop 的实践经验，我想借着 loop engineering 这个概念的出现，聊一聊为什么从去年开始，每过一段时间就会出现一个新的 xxx engineering。
如果按模型发布的时间来看，每一次新的 xxx engineering 的出现，都是在新模型发布、模型能力又上了一个台阶之后。
个人认为 xxx engineering 其实并不是炒新概念，而是随着每一次模型能力的提升，新模型被应用到新的任务场景下，并在过程中逐渐探索到可模型的能力边界。而为了让模型在这些新场景下更稳定可靠地发挥，带来效率与生产力进一步的提升，则需要人花费大量精力来“engineering”，通过工程手段，把 AI 从 20 分提升到 80、90 分，来保障模型能符合预期地完成任务。
最终，这些“脚手架”会被内化进模型中，使模型在这些场景下也可以越来越得心应手。
所以很多人常拿“只要现在不学，过一段就不用学了”开玩笑，但事实在某种程度上真是如此。但这并不是说 prompt、context、harness 不重要了，恰恰相反。即使今天，system prompt 在任何一个 agent 中仍然是最重要的组成部分之一，只不过 prompt 不需要、也不应该是由人一个字一个字的手敲出来的了，AI 已经比人更知晓如何写好 system prompt。
至于那些在某个新概念出来后，就喊“xxx 已死”“xxx 又活了”的自媒体，只能说建议取关就完事儿了。
05 写在最后
loop engineering 的出现，是模型在 long horizon（长程任务）能力发展上的必要条件。我们也朝“AI 能更主动、更高质量地端到端完成某个职能”又近了一步。
随着未来模型能力的提升，也仍然会有新的 xxx engineering 的概念被提出。距离“AGI”，或许就差一、两个 xxx engineering 了。