AI编程新范式：Claude Code之父联手龙虾创始人，终结提示词工程？

先给出几个关键观察。

一位工程师曾描述自己的进化路径：一年前写代码，还得老老实实打开IDE。去年11月，他索性卸载了IDE——因为同一时间可能并行运行5到10个Claude实例，所谓的“写代码”，其实只是对着Claude下达指令。而到了现在，连提示词都很少亲自写了，取而代之的是一堆自动循环在后台运转，循环本身负责提示Claude、判断下一步该做什么。他本人的工作，变成了编写这些循环。

说这话的人是Anthropic工程师、Claude Code的创建者Boris Cherny。在他看来，这正是未来几个月乃至今年剩余时间里，我们将目睹的又一次范式转移。

几乎同一时期，现任OpenAI的“龙虾之父”Peter Steinberger也在X上表态：“你不该再给编程Agent写提示词了。你应该设计一套循环机制，让这些循环去提示你的Agent。”这条帖子很快获得150万浏览量，评论区里开发者们争论不休。

两位关键人物的公开表态，将一个新概念推到了台前：Loop Engineering。简而言之，开发者不再手动向编程Agent输入提示词，而是构建一套能够持续提示、调度和约束Agent的循环系统。

已有网友调侃称，LinkedIn上很快会掀起一波“Loop Engineering”的新潮流。Peter回应道，别急，大概还得三个月，之后人们就该讨论“设计你的循环舰队”了。

这股讨论热度的背后，是社区已经开始将“写Loop”视为继“写Prompt”之后的下一层抽象。有人把这个变化概括为“从prompt engineer到meta-prompt engineer”。

也有先行者表示，这条路确实可行。“我就在搭建循环流程，配置终于调顺了，但字符膨胀的问题开始冒头，额度烧得飞快。烦人的是，它明明能跑通，可只要搞清楚哪里出了问题，就能用两倍速度、更低成本完成同样的事。”

Loop不是机械重复

面对这个新概念，不少开发者第一反应是：这不就是个cron job吗？反复告诉模型“把这个应用做得更好”而已？

但真正让Loop发挥价值的，是反馈循环。

想想一个开发团队日常需要什么：要知道新功能是否按预期工作、哪里能改进、用户还有哪些问题、哪些工作流可以优化、优化能带来什么价值。有些信息LLM可以直接访问数据获得，有些需要你自己生成——比如用户访谈、创建任务，或者干脆让模型自己跑A/B测试、增加监控。

和开发团队一样，你需要明确的OKR或目标。给内部员工开发应用，目标可以是提升性能、降低错误率、自动化工作流；如果是电商，目标就是优化从转化漏斗到成交的流程、提高收入。甚至可以像Dependabot那样用来升级库、修复安全漏洞、管理技术债、做QA。关键在于，必须有一个清晰的目标，以及一个能验证输出结果的反馈闭环。

YC CEO Garry Tan在转发相关讨论时也提醒，不要把Agent变成“富士康工厂”式的重复劳动机器。Agent通常是智能且有思考能力的，开发者应该让它们承担更多工作，而不是重复执行同一个动作。

有开发者补充，可以让Agent做更多事，但边界必须明确。目标不应该是每一步都盯着它们看，而是提供清晰的上下文、可信的工具、可审计的操作记录和安全的停止条件。这样Agent才能自主运行，而不至于演变成一套失控的“影子自动化”。

一名开发者在Peter的帖子下指出，设计Loop只完成了一半，另一半是在Loop里放入能够说“不”的机制——比如测试、类型检查或真实错误。没有反馈机制的Loop，只会让Agent不断重复并自我确认。Peter回应说，自己的项目中使用VISION.md文件来应对这个问题。

这些讨论说明，真正有效的Loop Engineering不是简单的自动化脚本，而是一套带有反馈闭环的工程系统。需要明确什么情况下继续、什么情况下停止、什么情况下回滚、什么情况下交给人类。否则，Agent的错误可能在循环中被不断放大。

也有开发者指出，这高度依赖具体场景。如果用Loop构建Web应用，可能导致系统膨胀，之后又得用另一个Loop去削减复杂度。必须建立严格的治理栈和清晰规范。

还有人追问一个更实际的问题：所谓Loop，到底是在CLI里循环、在shell脚本里循环，还是直接让Claude自己循环？

事实上，Claude Code早就发布了Loop功能。开发者可以在CLI中设置周期性提示词，让Claude Code按固定间隔反复执行任务。

Boris Cherny近期还介绍过自己现在的工作流：让大量AI Agent长时间并行工作，夜间通常运行“几千个”AI Agent，持续执行更深层次的开发任务，通过Claude App管理。这套工作流的关键，在于Claude Code中两个面向持续自动化的功能：/loops 和 Routines。

具体来说，用户可以通过cron在本地定时运行/loops，让Agent按计划循环执行任务；而Routines则运行在服务器端，可以执行周期性任务。即使工程师合上笔记本电脑，相关Agent仍然可以继续工作。

Loops有一个关键变化：不再依赖外部cron或shell loop。过去用脚本包裹claude -p时，每次调用都是一次“冷启动”，缺少上一轮上下文；而Loops会在持续存在的Claude Code会话中运行，保留上下文窗口、工具权限和MCP连接。Agent能记住上一轮操作，并在下一轮继续推进。

开发者可以用自然语言创建任务，比如：“每5分钟检查一次PR构建是否通过。如果失败，就读取错误日志，修复问题，并推送一个新commit。”也可以通过命令创建：

/loop "Summarize any new posts tagged #announcements in the team Slack channel" --interval 30m --expires 8h

当网友问Peter具体怎么做时，他只表示在用claw监视其Codex，没有过多解释。

目前，Codex虽然有自动化和定时能力，但在CLI里并没有像Claude Code那样设立明确的原生循环命令，比如创建新计划循环的cron create、查看活跃Loop的cron list，以及终止指定Loop的cron delete。

有意思的是，有用户问Peter如何在VS Code中实现这一点，Peter反问：“现在还有谁用VS Code？”

正如一位网友所说：“我们已经从‘学会写代码’，走到了‘学会编写那个会写代码的东西’。不知为什么，这听起来既像进步，又像一场金字塔骗局。”

开发者：你们有无限token供应，我没有啊

设想很美好，但现实是，这种循环工程的token消耗量一点不低。无论是Boris Cherny还是Peter Steinberger，其背后的公司都提供了近乎无限的token支持，但对社区中的大多数人来说，自己的token预算可没那么高。

此前，Developers Digest发文提醒，每一次Loop迭代都是一次完整提示词执行。如果设置1分钟执行一次、连续运行8小时，就会产生480次API调用。团队需要提前规划使用成本。

对于token消耗问题，实际上连Peter也无解。有人指出“20美元的套餐根本不可能”，他只能回答：“没错。可难道你的时间真不值钱吗？”

还有开发者打了个比方：Loop可以是for循环，也可以是while循环。Token充裕的公司可以随意使用while循环；Token紧张的初创公司也能用for循环实现同样目标，只是花的时间更长。

为此，有网友半开玩笑地对Peter说：“多么虚伪啊，你在对那么有无限token的人说这些吗？为什么把这事儿说得好像是技术问题，而不是资金问题？”Peter的回答也挺“正确废话”的：能卖出去的好创意，依然需要人类的巧思。

具体落地中，当前Claude Code对token消耗问题的做法基本是做各种限制：Loops支持最小1分钟间隔，最长运行3天，到期自动停止，以避免无人管理的后台进程和失控API账单；Loops不是持久化后台任务系统，它绑定当前Claude Code会话，关闭终端或结束会话后，Loop就会停止。这一设计是为了安全和可预测性，避免任务在用户遗忘后继续消耗API额度。此外，Claude Code也提供禁用Loop的开关，如果担心自动化任务失控、API成本跑飞，或者不希望团队成员使用循环式Agent工作流，可以关闭这个功能。

除成本外，Loop的实现可能比想象中麻烦得多。

“所有人都在冲向loops，但调试一个已经跑了47轮的状态机，比修好一个prompt难10倍。”有网友指出，“Loops的方向是对的，但我们跳过了一个关键阶段：大多数人现在连一个可靠的一次性prompt都还写不好。”

一些已经开始使用Loop的开发者表示，“一开始什么都很容易设置，但之后你才会意识到，里面有一堆痛点，修起来又太费劲。”

“现在想想，我都有点对不起同事，因为是我把Loop引进并推广到我们组织里的。现在如果迁移到另一个方案，会耗费大量时间和资源，所以我们只能再撑一阵子，直到它变得实在太痛苦为止。”有开发者跟帖道。

“我们也干过这事，把它集成进来，想在一个项目里试用Loop。结果现在光是把那个项目的数据导出来，再迁到我们现在用的工具里，就已经要花很多时间和精力，没人想干。我的建议是：能多早迁就多早迁。时间拖得越久，情况只会变得越糟。”有开发者回复称。

Claude Code如何一年内从20分钟跑到“数天”

Loop工程的重点在于“让Agent在长时间运行中持续不跑偏，并能可靠判断自己有没有做对”。这方面，Claude Code自己就是典型代表。

Anthropic应用AI团队的工程师Ash近日表示，公司当前探索方向更偏“尽量完全自主”，目标是把人类判断写入Harness，而不是在不稳定环节插入人工兜底。团队会同时运行多个生成结果、阅读失败案例、调整提示词，反复迭代，直到可以较放心地让Agent自主运行。

过去一年，Claude Code已从“只能连续运行约20分钟、连Bash命令和字符串转义都容易出错”，进化到“几乎由Claude Code自己编写，并可连续运行数天”的阶段。

Anthropic工程师Andrew指出，让Agent连续运行数小时甚至数天，核心难点主要有三类：上下文、规划和自我判断。

首先，上下文窗口有限，新会话会让Agent像“失忆”一样从头开始；长会话中还会出现上下文腐烂（context rot），模型越接近上下文窗口末尾，越容易出现“上下文焦虑”，匆忙结束任务。其次，模型默认并不擅长长期规划，可能一次性试图完成所有任务，也可能只做完一半功能就停止。更关键的是，模型很难准确判断自己的输出，经常会把半成品误认为完成——前端按钮已经出现，但后端逻辑并不存在。

为解决这些问题，Anthropic采用了两条路径：一是继续提升模型本身，把更多长时任务能力写入模型权重；二是改造模型外部的Harness，也就是围绕模型的智能体脚手架。

在具体机制上，Anthropic早期长时运行Agent会先由初始化Agent将模糊需求拆解成一组持久化文件，例如feature_list.json、progress文件、Git仓库和初始化脚本。随后，Agent在新鲜上下文窗口中反复执行：读取当前进度、启动项目、选择一个未完成功能、实现、测试、提交代码，并继续下一轮。这种模式通过“新上下文窗口 + 持久化工件 + 验证循环”来缓解长任务中的上下文丢失和任务漂移。

但随着Opus 4.6等新模型能力增强，Anthropic已开始简化这类Harness。Opus 4.6更擅长规划和工具选择，Sonnet 4.6则以更低成本提供接近Opus的执行能力，因此常见组合是用Opus做规划、用Sonnet执行代码。同时，服务器端压缩和百万级上下文窗口使模型可以在单一长会话中保持更久连贯性，不再总是依赖频繁开启新会话。

当前，Anthropic正在内部实验的前沿Harness模式是：生成器—评估器—规划器结构。这个设计借鉴了生成对抗网络（GAN）的思想：生成器负责构建应用、评估器负责批判和打分，两者通过对抗压力不断提升结果质量。

与让一个Claude Code会话自查不同，Anthropic会让评估器拥有独立上下文窗口和系统提示词，并真正使用Playwright打开网页、点击、截图和测试应用，而不只是阅读代码diff。

不过，Ash指出，自我评估是一个陷阱。模型很容易对自己的作品过于宽容，但如果把“构建者”和“批评者”拆开，单独训练一个更严苛的评估器会更可控。他用人类类比称，一个人评价一幅画或一道菜很容易，但亲自画出来或做出来要难得多。大语言模型同样如此：它作为批评者和作为生成者之间存在能力差距，而Harness可以利用这种差距。

在评估主观质量方面，Anthropic还尝试将“品味”写成可评分的量规。Ash表示，很多人认为设计审美无法评估，但只要有足够明确的观点并写下来就可以评分。比如，Anthropic将前端应用质量拆成设计、原创性、工艺和功能性四类标准，并根据模型能力调整权重。由于Opus 4.6在功能性上已经较强，当前评估更侧重设计和原创性，目的是避免常见的“紫色渐变”“AI味审美”等问题。

为了从页面生成走向完整应用，Anthropic又引入了规划器角色。规划器只负责把一句话需求拆成高层规格和冲刺阶段，而不是提前规定所有技术细节。真正开始写代码前，生成器和评估器还会先协商“什么叫完成”：生成器提出要实现的功能和测试方式，评估器则反驳范围是否过大、测试是否太弱、是否漏掉边界情况。双方通过磁盘文件来回沟通，直到形成一份契约，之后评估器按照这份契约验收，而不是按照最初模糊需求验收。

至于“Ralph Loop”（让AI在同一个任务上持续工作，直到真正完成所有目标）是否仍有价值，Andrew表示，在百万级上下文窗口和Opus 4.6的连续会话能力下，Anthropic已经在部分场景从新会话切换到单一长会话加压缩，但具体选择仍取决于用例和评测。Ash则认为，上下文腐烂是当前模型的临时性缺陷，某些支架组件未来可能会随着模型进步被移除。

来源：互联网