我们的 loop engineering 实战：从两个 terminal 里的手工循环，变成一对开源 skill

我们开源了一对 agent skill，design-review 和 build-phases。它们成对使用，解决同一个问题：AI 做比较复杂的任务时，计划会漂。

这是 IDD 的延续。要说的问题也正是从 IDD 用出来的，所以先从那里说起。

一个从 IDD 长出来的问题

IDD 的做法是先把 intent 说清楚，再让 AI 自己规划实现。用起来确实比写 spec 舒服，但用久了会遇到一件事：AI 会不断追问细节。

Two skills, one loop: review design, then build in phases.

追问本身是好事。它问的每一个问题都合理，而且往往是我确实没想清楚的地方。所以我一个个答。

问题出在我的回答上。

我答的时候，常常会顺手带进一些不相关的东西 —— 想到哪说到哪，把背景、顾虑、还没定的想法一起说了。AI 不知道哪部分是我真正要的，它把整段都当成有效输入，于是顺着那些不相关的部分继续往下问。我又答，又带进新的枝节。

这就成了一个自己给自己加燃料的循环。噪音被当成信号，然后被展开成更多问题。

几轮之后 intent 文件就膨胀了。原本清清楚楚的三层结构变成一份很长的文档，每一条单看都对，都是我认真回答的，但合起来重点没了。那种感觉像是把一件事解释得太细，听的人反而不知道你到底要什么。

再往下就开始漂。它抓住某个细节一路展开，方向逐渐偏离，而最麻烦的是我说不清它是从哪一步开始偏的 —— 每一步都是上一步的合理延续。回头翻那份文档，我自己都很难指出问题出在哪一段。

这事有点讽刺。IDD 当初批评 SDD 的理由之一，就是 spec 会膨胀、会分散在一堆文件里。结果 IDD 自己通过一问一答，长出了同一个毛病的另一个版本。

手工阶段：两个 terminal 和 copy paste

我当时的第一反应是，得有个人来审计这份 intent 和计划，看它是不是已经乱了、有没有盲区。

但关键在于，这个审计者不能是刚才跟我一问一答的那个 agent。漂移正是那场对话造成的，它在里面待得太久，已经看不出问题了。它会觉得每一条都是自己认真想过的。

所以我开了第二个 terminal，把那份 intent 和计划整个粘过去，只给它一句话的任务：读这个，告诉我哪里乱、哪里有盲区、哪里前后不一致。不要改，只说问题。

这一步的效果在预期之内。它确实能看见第一个 agent 看不见的东西，道理也不复杂 —— 那些内容是它和我一起想出来的，它对自己参与过的部分没有距离感，每一条在它看来都是认真想过的。

真正让我意外的是另一件事。

我回头看那一路的追问，发现 AI 在问我的时候，很多时候它自己已经有想法了，而且那个想法还不错。它不是不知道该怎么办，它是在等我拍板。

更荒诞的是有几次它问的问题我一时答不上来，我是去找另一个 AI agent 帮我想答案，然后再粘回去。

那时候我才意识到，问题不在"审计"这一步，而在更前面：不该让它一直问。

追问本身在引入噪音。它问、我答、我的回答带进枝节、它顺着枝节再问 —— 而如果它本来就有不错的判断，那更合理的安排是让它自己决定、自己改，我退到只看结果。

这就是后来这两个 skill 的基本原理：让 agent 自己 review、自己 fix，人不再被卷进细节问答。

要说清楚的是，这不等于不需要人。两个 skill 都保留了明确的上报机制：design-review 遇到需要改架构方向的事会停下来交给人，它自己只修文档的一致性和测试覆盖，不动方向；build-phases 也有一组具名的硬停条件，撞上就报告、不硬扛。

所以人被移走的不是"参与"，是"参与的层级"。细节交给 agent，方向留给人。 从每天答二十个边界条件，变成偶尔拍一次板 —— 后面那种参与才是真正需要人的地方。

手工阶段一般三四轮就差不多了。第二轮问题明显变少，第三轮基本只剩措辞。到那时计划已经清楚多了，而且我能明确感觉到它站得住 —— 不是"看起来完整"，是"照这个做应该不会中途卡死"。

这个过程很笨，而且麻烦到我不会每次都做。这两点加在一起，就是该交给机器的信号。

design-review：把审计这一步自动化

design-review 做的就是上面那件事，只是不用你粘贴了。

它每一轮派一个全新的 agent 来读你的计划文档，给出问题清单和一个分数，然后按意见修改，再进下一轮。默认跑到 95 分或者最多 5 轮为止 —— 这个 5 是照手工时的经验定的，那时候三四轮基本就收敛了。

注意修改这一步也是 agent 做的，不是我。但它有一条边界：它只修文档的一致性和测试覆盖，不改架构方向。真需要动方向的时候，它会停下来交给人。

这里有个设计上的细节，我觉得是整套东西最有意思的地方：每一轮的审计者都是全新的，它看不到之前任何一轮的对话。

它只能看到磁盘上的文件。

这带来一个听起来很怪但很合理的后果：你的修改必须真的写进文件并提交，否则下一轮的审计者根本看不见。 你没法跟它解释"这个我们上一轮讨论过了"，也没法靠上下文里的铺垫让它放行。一个改动如果经不起陌生人冷读，那它就等于没改。

另外一条是审计者只能读，不能改。发现问题和修问题是两个角色。让同一个 agent 既评又改，下一轮它就是在给自己的作业打分，分数会因为"这是我写的"而上涨，而不是因为计划真的变好了。

它还会先判断你给的是什么文档（实现计划、架构设计、还是事后复盘），然后用不同的标准去看。拿实现计划的尺子去量一份复盘，只会得到一堆没意义的意见。

build-phases：计划扎实之后，执行也得盯

计划做扎实之后，新问题是执行。AI 一口气做十个阶段，中间某一步出了问题，你往往到最后才发现。

build-phases 按计划里的阶段一个一个推进。每个阶段做完要过三层验证：编译和测试跑通、功能真的跑一遍、再试着用异常输入把它弄坏。三层都过了才算这个阶段完成，然后同样派一个全新的 agent 来审一遍，通过了才进下一个阶段。

它要求每个阶段结束时系统是完整可用的，不允许出现"做了一半"的阶段。

还有一条硬规则：验证结果必须是真实的原始输出，不接受"测试通过了"这种概述。这条听起来啰嗦，但它挡掉的是最常见的一种失败 —— agent 报告说做完了，实际上什么都没做。

怎么用

它们是 agent skill，不绑定某一个具体的 agent —— Claude Code 和 Codex 都能用。

安装：

npx add-skill arcblock/agentloop

两条命令：

/agentloop:design-review    # 反复评审计划，直到它站得住
        ↓
/agentloop:build-phases     # 按计划分阶段实现，每阶段验证

build-phases 会检查计划有没有过评审，没过会让你先去跑 design-review。这个顺序是强制的，因为在一份还会漂的计划上分阶段施工，只是把问题推到后面。

两个 skill 都在 ArcBlock/agent-skills 里，design-review 和 build-phases 各自的 SKILL.md 就是完整实现，可以直接读。

什么时候不该用

小而明确的改动别用这套。修一个 bug、改一处文案、加一个字段，直接让 AI 做完跑个测试就行，启动评审加分阶段是杀鸡用牛刀，而且会让你等很久。

它适合的是那种你自己也说不太清全貌、一次做不完、中途容易跑偏的工作。判断标准很简单：如果你担心的是"这事会不会做到一半发现方向错了"，那就该用。

这就是一种 loop engineering

这套做法最近有了名字，叫 loop engineering。The Pragmatic Engineer 在 2026 年 7 月做过一篇综述 ^[1]，里面引了 Addy Osmani 的一句定义，我认为是最准的：

Loop engineering is replacing yourself as the person who prompts the agent.

把"反复推动 agent 的那个人"换成机制。

这件事的起点是个很实际的限制：上下文窗口装不下一个完整的大任务。所以与其在一个越来越长的会话里硬撑，不如把工作切成一轮一轮，每轮结束检查目标有没有达到，没达到就用干净的上下文重新开一轮，把上一轮的产出作为新的起点。这个概念最早来自 Geoffrey Huntley 的 Ralph Wiggum 技巧，后来 Matt Pocock 那篇 "Ship working code while you sleep" 让更多人知道了它。

写到这里你大概已经看出来了：「用干净的上下文重新开一轮」正是 design-review 每一轮做的事。 我们不是碰巧和这个概念沾边，我们做的就是它的一种。

而 Addy Osmani 那句话，几乎是在描述我前面讲的那个手工阶段 —— 那时候循环里"反复推动 agent 的那个人"就是我自己，我的工作内容就是切窗口和粘贴。design-review 和 build-phases 做的事，说到底是把我从这个位置上换下来。

有一点不同的是来路。我们不是先看到 loop engineering 这个框架再去找地方用它，而是从 IDD 的一个具体毛病倒推出来的 —— intent 会膨胀、计划会漂，得有个没参与过对话的角色来看。走到最后发现和别人是同一个地方。

一个概念如果从不同的起点都能被走到，通常说明它是对的。

最后

design-review 和 build-phases 加起来做的事情，说白了就是：让 AI 写的计划先被另一个没参与过的 AI 挑一遍刺，然后照着改好的计划一步步做，每一步再挑一遍。

这里面没什么高深的东西。真正起作用的还是那个笨办法 —— 换一双没被上下文污染过的眼睛。我们做的只是把这个循环里原来由我承担的部分，交给了两条命令。

IDD 当初的说法是「code review 可以交给 AI，intent review 需要人」。用了一年多之后，我觉得这句话可以往前推一步：intent 的打磨可以交给 agent，人守住的是方向和最后那次判断 —— 这东西是不是我要的。

区别在于人被问什么。以前是被问二十个细节，现在是被问一次"要不要换个方向"。

GitHub: github.com/ArcBlock/agent-skills

参考