Loop Engineering 不是你想的那回事
𝗿𝗮𝗺𝗮𝗸𝗿𝘂𝘀𝗵𝗻𝗮— 𝗲/𝗮𝗰𝗰 (@techwith_ram)
2026-06-11
R
原文
---
title: "Loop Engineering 不是你想的那回事"
author: "𝗿𝗮𝗺𝗮𝗸𝗿𝘂𝘀𝗵𝗻𝗮— 𝗲/𝗮𝗰𝗰 (@techwith_ram)"
source_url: "https://x.com/techwith_ram/status/2064925285003542820"
published_at: "2026-06-11T04:18:46.000Z"
fetched_at: "2026-06-12T04:30:01Z"
updated_at: "2026-06-12T05:07:17Z"
language: "zh"
review_status: reviewed
---
# Loop Engineering 不是你想的那回事
那些在做最先进 coding agent 的人说，他们现在几乎不怎么亲自写 prompt 了。取而代之的是，他们在构建能生成、审查并改进自身工作的系统。这个愿景很诱人：少一点盯着，多一点自动化。
但这里有个问题。
大多数关于 loop（循环）的讨论，都在讲它们能做什么，而不是它们要付出什么代价。每多转一轮，就会多烧 token、多做假设，也会离你的直接控制更远一点。
### 如果你想学习 AI agent，可以看看这个 GitHub repo：
### https://github.com/Ramakm/ai-agents.git
Claude Code 背后的工程师 Boris Cherny 有一句话，让很多开发者停下来想了想。
别人问他现在怎么工作时，他说自己已经很少直接给模型写 prompt 了。相反，他有一套 loop 替他去 prompt 模型。他的工作，是构建这些 loop。
这是个细微但重要的转变。
他的重点不再是和 AI 对话，而是构建一个会和 AI 对话的系统。OpenClaw 的创建者 Peter Steinberger 也表达过类似观点：别再给 coding agent 写 prompt 了，开始设计会替你 prompt 它们的 loop。
果不其然，AI 圈马上跟了上去。Agentic loop 成了最新热词。
但和往常一样，现实比标题复杂得多。很多谈论 loop 的人，其实说不清它到底是什么、什么时候真的有用，以及为了换来自动化，你到底放弃了什么。
这篇文章我就把这件事讲清楚！！
## **首先，**什么是「loop」？
其实你一直都在跑一个 loop。只是这个 loop 里有人：你自己。
你打开 Cursor、Claude Code 或 Codex，输入：「帮我做一个落地页。」你看它返回的结果。Hero 区看起来不太对，于是你要求修改。它生成另一个版本。你审查它、调整方向，然后重复这个过程。
**生成。审查。调整方向。重复。**
这个循环有个名字：human-in-the-loop。
agent 负责构建，但指挥、判断、掌舵的人仍然是你。
这种方式让人安心，因为你能很早发现偏离。落地页看起来不对？你会在它开始写任何一行 auth 代码之前指出来。你同时扮演质量关、品味判断和路线修正的角色——只是这个人类又慢又细心。
## **新的**想法：把人拿出去
现在大家兴奋的趋势，是把这张图反过来。以前每一轮都由你来闭环；现在你只闭环一次。你交给 agent 一份 spec，也就是一个描述要构建什么的 **spec.md** 或 **PRD.md** 文件，然后退到一边。
**看看这个 repo：** https://github.com/snarktank/ai-dev-tasks/blob/main/create-prd.md
agent 生成内容，读取自己的输出，判断还剩什么要做，然后再次 prompt 自己。如此反复，靠它自己一路跑下去，直到它认为任务完成。
这并不是什么小众想法。开源开发者 Geoffrey Huntley 把它最简单的版本包装成了 **「Ralph Wiggum」loop。**它的核心，就是用一个 Bash loop 反复让 agent 在同一个任务上重跑，直到满足明确的完成条件。
Cursor 的 **/goal**，以及到处流传的各种 **/loop** 和 **/sloop** 命令，本质上都是同一类动作的不同版本：「目标给你；没做完别停。」在 Anthropic，这种工作方式也是 Claude 现在能写出绝大多数已合并生产代码的原因之一。
这确实让人瞥见了未来会往哪里走。但幻灯片到这里结束，现实从这里开始。
## **为什么**它看起来像魔法，但通常并不是
想象一下，你雇了一个很厉害的开发者，交给他一份 spec，然后整整两周没有任何消息。
两周后，他带着一个完成品回来。有些决定非常到位，有些则完全不是你原本想要的。
不是因为他能力差，而是因为没有任何 spec 能捕捉一切。
这就是自主 loop 的问题。
一旦 agent 开始替你做成百上千个决定，它就不得不填补那些空白。而空白永远存在。
最后交回来的东西可能像老虎机。拉下拉杆，等着，然后希望输出正好符合你的想法。有时会。很多时候不会。
最难受的是，你没法在过程中一路掌舵。一旦你输入 /goal，火车就已经开出站了。
## **没人**放进幻灯片里的部分：账单
这里有个不太舒服的现实：**loop 不是免费的。**
一次请求就是一轮 token。一个 loop 可能跑十轮、二十轮，甚至五十轮，每一步都带着 context、输出和历史往前走。成本会很快滚起来。
这就是整个 agentic loop 运动背后那个没人明说的星号。
很多主张全自主工作流的人，预算大到 token 成本几乎无关紧要。大多数开发者没有这种奢侈条件。
如果你用的是**每月 20 美元、100 美元，甚至 200 美元**的套餐，一个开放式 loop 可能会以出乎意料的速度烧光你的预算。
这就是为什么公司已经开始限制 agent 使用量。技术很强，但经济账也很重要。
这并不是说 loop 是坏主意。它只是说明，loop 不是魔法。它是一种工具，和任何强大的工具一样，在让它一直跑下去之前，你需要先理解它的成本。
## **那么，**loop 到底什么时候真的有效？
有个简单规则：成功标准越客观，loop 越好用。
测试通过了吗？分数超过阈值了吗？输出符合模板了吗？
当答案是明确的是或否时，loop 就有了具体的优化目标。麻烦出现在成功变成主观判断的时候。
「这感觉对吗？」「这是我想象中的产品吗？」「客户会喜欢它吗？」
这些问题不是 agent 能可靠衡量的。到了这个点，loop 就是在猜。这也是为什么 loop 特别擅长这类事情：按固定格式生成几百个 SEO 页面、跑 eval，或者处理大规模代码迁移。目标清楚，反馈也一致。
但「帮我做一个能赚钱的创业公司」是完全不同的问题。产品市场契合没有测试套件，品味没有 benchmark，愿景也没有客观分数。
目标越主观，人类判断就越有价值。
## 一个今天就能跑起来的 loop
如果只能向几乎所有开发者推荐一个 loop，我会推荐自动化代码审查 loop。
为什么？因为它拥有大多数 agent 工作流没有的东西：一个清晰、客观的信号。
你把代码 push 到 GitHub。Greptile、CodeRabbit 或 Macroscope 这样的审查 agent 会检查这些改动，并返回一个五分制评分。
然后你设一个简单规则：低于 4/5 的东西不能发版。
如果分数回来是 2/5 或 3/5，你不需要手动跳进去。你触发一个小工作流，让它读取审查意见、应用建议修复、push 改动，然后等待下一轮审查。
这个过程会重复，直到分数超过 4/5，或者 loop 达到最大尝试次数。一个好的 loop 就该长这样：一个闭合系统，有可衡量的目标，也有明确的退出条件。
秘密不在 loop 本身，而在于有一个 loop 可以可靠追逐的分数。如果你想看它最朴素的形态，Ralph 风格的 loop 其实就是围着你的 agent 写几行代码：
```python
# the whole idea, minus the ceremony
for i in $(seq 1 5); do
agent run "read the latest review, apply fixes, push"
score=$(get_review_score) # the fixed, objective signal
if [ "$score" -ge 4 ]; then
echo "passed at $score/5 — shipping"; break
fi
done
```
先提醒一句：即使是这么干净的 loop，一到边界情况也会开始出问题。如果一次性 push 超过约 1,000 行，审查 agent 就很难把所有东西都放进 context 里；你也很少能拿到 5/5。修法还是优秀工程师本来就在用的纪律：保持改动小，把大工作拆成多个 PR。即使在一个整洁、定义良好的 loop 里，scope 仍然是最容易把它弄坏的东西。
## 我的真实看法
以上这些，并不是在否定推动自主 loop 的人。他们很可能只是太早了，而不是错了。自愈 agent、自动 bug 修复、能看见并测试自己工作的系统，正在以超过多数人预期的速度到来。
但「正在到来」和「已经适合一切」是两回事。
现实是，大多数优秀产品并不只靠逻辑构建。它们需要品味、判断，以及一大堆任何 spec 都无法完全捕捉的小决定。
这也是为什么我喜欢这句话：AI 可以复制 sauce，但它不能创造 sauce。
目标清楚时，loop 非常强。审查、测试、lint、迁移、基于模板的生成。给它们一个可衡量的目标，它们可以干上一整天。
但当问题变成「这感觉对吗？」或者「人们真的会想要这个吗？」时，你仍然需要一个人在 loop 里。
所以，不要构建一个巨大的 loop，然后让它替你创造创业公司。围绕工作里那些枯燥、二元判断的部分构建小 loop；而凡是需要品味和愿景的地方，方向盘还是要握在自己手里。
这不是在对抗趋势，而是在理解趋势。
关注 @techwith_ram，获取更多类似内容