"不再写提示词了"——这句话正在 AI 圈疯传。
从 Claude Code 创造者 Boris Cherny，到 OpenClaw 之父、如今在 OpenAI 做个人智能体的 Peter Steinberger，再到给这股风潮命名的谷歌工程师 Addy Osmani——这些站在最前面的人，口径出奇一致。
Cherny 说，自己现在几乎不亲手写提示词了。有一个智能体在替他给 Claude 写提示词，他只跟那个协调一切的"元 Claude"对话。他甚至撂下一句话：十年之后，循环是他最自豪的工作成果之一。
Steinberger 说得更绝：别再给编程智能体写提示词了，你该设计喂给它们提示词的循环。他当场演示了自己的方案——让 Codex 每 5 分钟醒一次，自动维护代码仓库、分派任务，部分工作全自主落地。
流行的共识是"AI 编程 = 写好提示词"。但这批人的共识是：提示词没有死，它正在从一个职业退化为一个组件。而提示词之外的那套系统——循环——才是真正拉开差距的地方。
最近，Claude Code 团队在官方博客里给这个趋势下了明确定义，一口气拆出四种循环类型，为"智能体自动干活"立了工程规矩。
一、循环的核心，不是跑，是停
在 Claude 官方定义里，循环就是"智能体重复执行工作，直到触发停止条件"。
这句话听着简单，但细想就发现——过去一年所有关于"AI 自主性"的讨论，争论的核心其实一直在这里：让 AI 跑不难，难的是怎么让它跑对方向然后停下来。
一个没有闸门的循环，会陷入两种常见陷阱。一种是烧穿 token——Steinberger 自称是"手握无限 token 的男人"，因为免费 token 是 OpenAI 员工的福利，普通人没这待遇。另一种更隐蔽：智能体"看似有进展、实则原地打转"——反复改同一个文件，却始终跑不出一个新的通过测试。它甚至信心满满地，把一个错的方案越做越"完整"。
所以工程社区对循环的共识很直接：循环很强，但没有闸门就很危险。一个设计得当的循环，必须先想好三条防线：done 条件（机器可判定，比如测试全绿）、硬上限（最大轮数和最大花费）、无进展检测（反复碰同一批文件却没有新通过测试，强制停下）。
理解了"闸门比油门重要"，Claude 官方拆出的四种循环就很好懂了——它们本质上是四种不同的"谁来踩刹车"的方案。
二、四种循环，四种停止逻辑
回合制循环：人踩刹车
最基础的一种。你写一句，AI 跑一轮，你检查完再写下一句。全程你握着方向盘。
适合零散的短任务——不进流程、不上日程。Claude Code 团队建议了一个优化方向：把你平时手动检查的步骤写进一个 SKILL.md 文件，让 AI 自己验收。检查越能量化，它越能自己判断做没做对，你要盯的地方就越少。
这其实就是"提示词增强"的终点——不是写出更长的提示词，而是把验收逻辑从人的脑子里转移到文件里。
目标循环：评估器踩刹车
先把目标写死，比如"把首页 Lighthouse 分数跑到 90 以上，试 5 次就停"。
每次 Claude 想停，一个评估器模型就对照你的标准判断——没达标就打回去接着干，直到目标达成或用光轮数。这里的精巧之处在于：评估器和执行模型是分开的。Claude 不必自己纠结"够不够好"，评估器替它判。这样既避免了过早停手的自满，也让循环有干净的收尾信号。
测试通过数、分数阈值这类可量化标准，是目标循环的最佳应用场景。
时间循环：时钟踩刹车
按时间间隔触发，像闹钟。
有些活是重复的，任务不变，只有输入在变——比如每天早上总结 Slack 消息。有些活得盯着外部系统——最简单的办法就是按时间间隔去查一眼。用 /loop 就能按间隔重跑一条提示词；想在你关机后照跑，就用 /schedule 把循环搬到云端。
这套逻辑和程序员熟悉的 cron 定时任务几乎一模一样。区别在于：传统 cron 触发的是固定脚本，时间循环触发的是 AI 工作流——它可以在每次醒来时根据外部状态动态调整自己的行为。
主动循环：事件踩刹车
事件或时间触发，全程无人值守。
配合 auto mode 和动态工作流，把长活全自动串起来：每小时扫一遍反馈频道，收到一份 bug 报告，就自动分诊、修复、回复，一条龙跑完。每个子任务达成目标就退出，整条例行任务则一直跑到你亲手关掉。
它是四种循环里自主性最高的，也最适合那些源源不断但边界清晰的活：Bug 上报、问题分类、依赖升级。
三、把循环拆成四种，真正改变了什么？
四种循环——回合制、目标、时间、主动——说穿了就是四种"什么时候该停"的答案：人来判、评估器来判、时钟来判、事件来判。
这个拆法的意义不在于"创建了新概念"。定时任务、编排、反馈循环，这些做法已经存在多年。Claude 这次做的事情更像是一次工程分类——像软件工程曾经把设计模式归类一样，把 AI 自动化的基本单元统一命名，让团队之间可以讨论"你用的是目标循环还是时间循环"，而不是各自用不同的术语描述同一件事。
而当循环成为可设计的单元，真正发生的改变是编程重心的迁移：从"内容设计"挪到了"行为系统设计"。
以前你设计的是一次指令的内容——"写一段 Python 代码，处理 CSV 文件"。现在你设计的是一整套行为系统——它怎样触发、怎样验证、怎样恢复失败、怎样停止。工程师不再只是"写代码的人"，而是"设计 AI 行为系统的人"。
这个转变，和上个时代的"单体架构→微服务"有些相似。当时开发者不再关心单台服务器的性能调优，而是关心服务编排、熔断降级、链路追踪。现在同理——AI 编程的核心能力，正在从"写更精确的提示词"，走向"设计更可靠的智能体行为循环"。
四、框架的跨场景推演
这套循环分类法的解释力，并不只在编程领域管用。
看看黄仁勋前段时间的 26 分钟访谈就清楚了。他全程没提 GPU 和算力，只谈一件事：Harness。Prompt、工具说明、记忆、上下文管理、任务拆分、重试、评测和权限控制——模型负责推理，Harness 负责把推理组织成可验收的工作。
Harness 是什么？就是把模型放进一个更大循环里的工程系统。LangChain 用 Nemotron 3 Ultra 配合 Harness 在 Deep Agents 评测上追到了 0.86（最高分 0.87），而单次成本从 43 美元压到了 4 美元。模型没换，换的是模型周围的循环系统。
再扩展开来看，"提示词→循环"的迁移，正在各个领域同步发生：
- 产品经理：从写 PRD 给研发看，到设计 AI 自动调研→生成需求→验证假设的循环
- 数据团队：从写 SQL 查数，到设计定时爬取→清洗→分析→异常告警的数据循环
- 运维团队：从配置告警规则，到设计 AI 自动诊断→定位根因→执行修复→验证恢复的修复循环
同一个框架，在不同角色手里，长成不同的形状。但本质逻辑一致：谁先把自己的工作流拆成可循环的单元，谁就先从"手动作业"进入到"系统设计"。
五、从哪开始：三问法找出你的第一个循环
Claude Code 官方给了一个极其务实的起点：先别想太复杂。去看你自己每天都在干的活，挑其中一个瓶颈环节，然后问自己三个问题。
第一问：验证——这道检查，我能不能替它写出来？
如果一项工作的验收标准是模糊的——"看起来好不好"、"用户体验如何"——那它暂时不适合做循环。但如果验收标准是可量化的——"测试全绿"、"API 响应低于 200ms"、"代码覆盖率提升 5%"——那就找到了第一个循环的候选。
第二问：目标——目标描述够不够清楚？
"优化系统性能"不够清楚。"把首页加载时间降到 2 秒以内"才清楚。模糊的目标让模型和自己都分不清什么时候该停。
第三问：节奏——活儿是不是按固定节奏出现的？
每天、每周、每小时出现的固定任务，比随机发生的任务更容易套上循环。先从有固定节奏的活开始，把经验积累起来再处理那些"不按套路出牌"的活。
只要有一个答案是肯定的，你就找到了第一个可以交出去的循环。不必一步到位上主动循环，从回合制开始——把验收步骤写进文件，让 AI 自己判断——已经是一个巨大的效率提升。
写提示词的时代不会一夜消失。但它的重心正在转移——从"谁写得更好"到"谁设计的循环更可靠"。
真正的循环设计者们，才刚刚上场。
来源：
- Claude Code Team — "Getting Started with Loops" (claude.com/blog, 2026)
- Claude Code Agent SDK Documentation — Agent Loop (code.claude.com)
- Boris Cherny / Peter Steinberger — X posts on loop engineering (2026)
- Addy Osmani — "Loop Engineering" concept (2026)
- 黄仁勋 × Harrison Chase 访谈 — "Harness" (2026)