---
title: 当AI圈开始聊Loop:提示词工程已死,但杀死它的不是新技术
source_url: https://mp.weixin.qq.com/s/WTdrjZtEFagM58vryDqvIA
author: TechFarrari (公众号)
publisher: TechFarrari
publish_time: 2026-06-15 10:30
related_first_source: loop-engineering-addy-osmani-challengehub (2026-06-10)
ingested: 2026-06-15
type: raw
sources: [entities/loop-engineering-addy-osmani-challengehub]
review_value: 7
review_confidence: 7
review_recommendation: worth-reading
review_stars: 3
char_count: 4683
sha256: d69c774ddf61755143747a5b1c1ab64c15270f08c7a15c0d2213fd36dd84ba0f
notes: |
  TechFarrari 公众号 2026-06-15 解读 Boris Cherny 访谈 + Addy Osmani《Loop Engineering》,
  创新: 范式迁移叙事 (prompt→context→harness→loop) + 6 问工程化翻译 + 责任批判视角 + 跨域应用(内容选题 loop) + 生命周期短预言。
  与现有 4 来源(Addy/InfoQ/微信公众号教科书/若飞)同主题 5th source commentary。
---

# 当 AI 圈开始聊 Loop：提示词工程已死，但杀死它的不是新技术

**公众号**: TechFarrari | **发布时间**: 2026-06-15 10:30

---

一个多月前,Claude Code 负责人 Boris Cherny 在接受采访时随口说了一句话,当时没多少人注意。

> **"我现在基本不直接给 Claude 下指令了。我有一堆循环在跑,它们负责给 Claude 发任务、决定下一步做什么。我的工作变成写循环了。"**

一个直接决定千万开发者怎么用 AI 编程的人,说自己每天都在写循环。

说真的,我第一次听到这句话,第一反应不是"好厉害",而是"这日子还能这么过?"

上周 Google Cloud AI 总监 Addy Osmani 正式把这个概念讲透了——他写了篇长文叫《Loop Engineering》,给它拆成六个零件,加一个记忆机制。他的判断更直接:想把这东西真用明白,比过去写提示词还难。

两件事加在一起,够有意思的了。

## 一、从"写好一句话"到"设计一个系统"

过去两年 AI 圈的名词变迁史,本身就是一部"人的位置怎么被一步步往后推"的历史。

- **2023** 年刚有 ChatGPT 的时候,大家最在意的是 prompt 怎么写。"prompt engineer" 甚至短暂地成了一个正经岗位,年薪开到几十万。
- **2024** 年,模型变聪明了——重心从 prompt 转向了 **context**——怎么喂更多更好的信息给模型,怎么管理 token 预算。有人管这叫 "Context Engineering"。
- **2026** 年初, OpenClaw 和 Claude Code 把 Agent 能力做实了,于是有了 **"Harness Engineering"**——给 Agent 搭个运行环境,让它不那么容易翻车。
- **June 2026**。Boris Cherny 说的那句话之所以重要,是因为——一个亲自在做这个产品的人,向大家坦白了一种新的做事方式。

> **你不需要再一轮一轮地指挥 Agent 了。你设计一个系统,让系统去替你做这件事。**

听起来很美是不是?我也觉得。但后面还有半句没说完的话:

> **你从"写 prompt 的人"变成了"设计系统的人",听起来是升职了,实际上是你活变多了,责任变大了,但没人给你加工资。**

Prompts 变成了这个系统里的一个零件。真正决定结果的,变成了那个 loop。

## 二、一个 Loop 到底装了什么

Addy 的原文把它拆成"五个积木加一个记忆"。我把它翻译成更直白的问题——一共六个。

### 2.1 第一个问题:谁来把它叫醒?

不会自己启动的,不叫 loop,顶多算你"设定时的定时任务"。

所以第一层是**调度**。定时、按事件触发、或者跑到条件满足才停。这一层区分的是:你在用工具,还是在运行一个系统。

> **大部分人的 loop 之所以失败了也没人知道,就是因为只布置了任务,没布置起床闹钟。**

Claude Code 的 `/loop` 和 `/goal`、Codex 的 Automations 标签页,本质上都在解决同一个问题。

### 2.2 第二个问题:多个 Agent 一起来,怎么不打架?

只要有并行——哪怕只是先后启动但任务重叠——就躲不开一个问题:两个 Agent 改了同一个文件,互相覆盖。

**解决方案粗暴但有效:隔离。一人一个工作空间。**

但说实话,这个问题到现在也没被真正解决。worktree 只能隔离文件,**隔离不了语义冲突**——两个 Agent 对同一个函数做不冲突但逻辑矛盾的重构,worktree 管不了。

> **没有隔离的并行不是提效,是批量造冲突。**

### 2.3 第三个问题:AI 怎么知道你们平时怎么干活?

模型每次开工,都像一个刚入职的新同事——有技能,但不懂你们项目的臭规矩。

**解决方案是一个"外部脑子"**——WeWrite 管它叫 SKILL.md,Codex 管它叫 `.codex/agents/` 里的 TOML 配置。

> **Prompts 是当场的临时指令,Skills 是长期的固定规则。** 没有这层规则,loop 每转一圈都要重新认识你一遍。

### 2.4 第四个问题:它能碰到本地之外的东西吗?

只能看本地文件的 Agent,还是半封闭的。loop 往往要接出去:issue 系统、数据库、CI、PR 工具。

> **这一步决定了 AI 是说还是做**——是告诉你"这个变量命名不太规范,建议改成 xxx",还是直接开分支、跑 lint、开 PR、把结果丢进你的待审列表。两边差了大概……一个量级。

### 2.5 第五个问题:谁来看它做得好不好?

写代码的 Agent 天然高估自己的答案。你让它写完再自评"行吗",答案大概率是"行"。

> **所以越来越多的 loop 把执行和验证拆开了。一个负责做,一个专门挑。道理跟团队里那条老规矩一样——写代码的人,不应该给自己做 code review。**

### 2.6 第六个问题:它怎么记住昨天做到哪了?

这是个最不起眼的组件——但几乎所有长期跑的 loop 都离不开它。

**而且说实话,现实中没有几个人真的做到了**。大家都在嘴上说"要有记忆机制",但真去写那个 markdown 文件的人,不到 10%。

> **Agent 最大的麻烦之一,是每次启动都太像重新来过。昨天验证过的结论今天再查一遍,上周否掉的方案这周又端上来。** 所以得有个对话之外的载体,记下做过什么、失败过什么、哪些已经确认。

模型会忘,但仓库不会。

## 三、难的不是技术,是责任没跟着走

Addy 那篇文章里有一层意思,我越读越觉得不是随口写的——他一直在强调成本和边界。

### 3.1 成本

Loop 一旦跑起来,就**不是问一次答一次的计费方式了**。它会反复试错、反复验证,有时候还要拉三四个 Agent 一起干。token 消耗可以非常、非常大。

> **原来你是一块钱干一件事。现在你是一块钱建个机器,机器干十件事——但机器可能干着干着就干了些你没让它干的事。然后你还得为这些事买单。**

Peter Steinberger (Lobster 创始人)对此的回应很直接:但你的时间就不值钱吗?话是这么说,但这个账得自己算清楚。

### 3.2 隐蔽的代价(最危险的部分)

Loop 替你做了越来越多的事,人会很自然地不再去看过程。AI 说"完成了",未必真没问题——框架写对了但业务逻辑没覆盖、测试通过了但测的条件不对、PR 合并了但没有人在 review 时认真看。

> **你每让出一个环节的理解权,就多了一个"以后才发现"的风险。而 AI 跑的次数越多,代码堆得越厚,你的理解缺口就越大。**

比写提示词难的地方就在这里。**提示词写坏了最多下一次重来。但一个跑了 47 轮的 loop 出了事,你得回溯的状态空间——我不敢想有多崩溃。**

### 3.3 商业动机

> **AI 圈现在这批造词的人,同时也是卖工具的人。** 他们告诉你用 loop 就能省时间、解放生产力。但仔细想想,每次循环多跑一圈,就意味着多花一份 token 钱。

你省下来的时间,本质上是**用更多 compute 换的**。这个账,他们算过,但不会主动告诉你。

## 四、代码是起点,不是终点

说句实话,Loop Engineering 这个概念的爆发,**是因为代码是最完美的落点**——它有天然反馈回路:测试过没过、程序跑不跑、日志报不报错,结果可以直接验证。

但把这个思路抽象出来,它适合的地方远不止写代码。

非代码领域跑 loop 有个挺现实的问题:怎么定义"做完了"?代码有测试用例兜底,内容选题谁来判断好不好?运营 loop 怎么知道这条触达策略是对是错?**很多场景的反馈信号,比代码模糊太多了。**

### 跨域应用案例:内容选题 loop

> 上个月跟一个做内容的朋友聊天,他说他们团队已经在跑了——**每天凌晨 4 点,Bot 开始抓取前一天的行业新闻,跑一遍摘要,对比 3 家竞品的动态,早上 8 点前出选题会 agenda。** 他说这叫"数字主编",我说这叫 loop。

一个内容选题 loop:

- **清晨定时**去扫新闻源、X、博客和论文站
- 挑出值得看的
- 补上来源
- 摘出核心观点
- 标出争议点
- 资料不够的地方标红
- 串成一份**选题清单交给编辑**

**一个编辑不再花 60% 的时间在"找",而是用那 60% 的时间在"判断"。**

### 跨域通用条件

- 任务会重复
- 流程相对稳定
- 结果有一部分能自动检查

满足这几点,loop 就有落地空间。**前提是——你愿意花时间先把 loop 设计好。**

## 写在最后

每次 AI 圈出新概念,我第一反应都是:**来,先等等,看它半年后还在不在。**

不是我不信任技术的迭代速度。是我太信任人类的造词速度了。

> **Loop Engineering 这个词大概率撑不过年底的。** 就像 Prompt Engineering、Context Engineering、Harness Engineering 一样——每过几个月就有个新词,每个新词都宣称自己要杀死上一个。

但 Boris Cherny 和 Addy Osmani 各自用不同的方式在说同一件事,这件事不会因为"Loop"这个标签过时而消失。

> **当 AI 能处理越来越长的链路时,人和它的协作方式,必须从一轮一轮的对话,升级成一个能自己运转的闭环。**

过去大家比的是谁的提示词写得好。**接下来比的可能是谁的 loop 设计得好:怎么调度、怎么验证、怎么记录、什么时候该停。**

> 回到最开头 Addy 那句话。这件事不会让你的工作变简单——**它只是把发力点挪了个位置。**

**你可以做那个始终在场、理解每一行代码在发生什么的工程师。也可以做那个只负责按开始键、然后看着代码越堆越多的人。**

**选哪个,没有标准答案。但得知道自己选的是哪个。**