上周末我在终端里跟一个测试报错死磕了一下午直到 Claude Code 的新命令 /loop 上线后我才反应过来那种报错—复制—问AI—粘贴—再跑的手动循环本来就不该由人来干。终端圈管这种状态叫小龙虾——谐音是瞎循环又小又碎弯弯绕绕人也确实像只虾一样弓在屏幕前。Claude Code 是 Anthropic 家的终端 AI 编程工具你在命令行敲一个claude就能让它读项目、改代码、跑命令。而新上线的 /loop 把循环从人的重复劳动变成了 AI 的自主流程给定一个目标它自己规划、动手、看反馈、再动手直到目标完成或达到你设定的上限。这篇文章聊聊 /loop 是什么、怎么用、哪些任务适合它以及我在真实项目里踩过的几个坑。不管你是刚装好 Claude Code 的新手还是已经在终端里跑了几个月的老人应该都能从中拿走点东西。1. 先弄明白小龙虾是什么终端里最磨人的手动循环1.1 一次典型到不能再典型的调试下午我上一份工作里维护过一个有点年头的 Node 服务那天下午新需求上线后测试挂了报错指向src/processor.js里一个边界条件没处理。正常流程是什么先跑一遍单测确认失败范围把红色报错塞进对话框问 AI 这个问题怎么改拿到建议后切回编辑器改代码再跑一遍。跑完发现原来的错没了但旁边一个模块跟着红了——因为它引用了没改好的函数。于是再来一轮复制新报错问 AI改代码跑测试。那个下午我就这样在终端、编辑器和聊天框之间来回弹了六个小时最后改好了人也快瞎了。这个场景你说多高级吗一点都不高级。但它在 AI 编程工作流里极其普遍。很多人以为自己用了 AI 辅助编程就多高效实际上大部分人做的只是把手动写代码换成了手动搬运问题描述。真正消耗精力的从来不是写那两行代码而是每一次搬运之间的上下文重建这个报错是哪个文件导致的我之前是怎么改的AI 这次给的建议跟上一轮矛盾了怎么办这些判断每一轮都要重新来一遍。1.2 这套虾式循环为什么让人头疼仔细复盘一下这套手动循环有四个特别讨厌的特征。第一是动作重复。复制、粘贴、切窗口、跑命令这些动作本身不带任何创造性但它们占掉了大半时间。尤其是上下文稍长一点的项目报错信息动辄几十行每次复制还要手动挑重点。第二是判断滞后。错误信息本来是要给机器看的但中间必须经过人大脑转译才能变成给 AI 的有效指令这中间的信息损耗非常严重。报错经常被贴得残缺不全AI 只能靠猜猜错了再来一轮。第三是上下文断裂。错在终端改在编辑器思考在 AI 对话框三个地方不共享上下文每次切窗口都要重建一轮记忆。你一边看着终端输出一边回忆上一轮改了什么还要在对话里补上一句这是我刚才改的那部分帮我看看是不是这里的问题——这种话本身就是效率损失。第四是精力耗散。等 AI 回复的几十秒里你以为能歇实际上脑子里还在想下一步怎么描述问题。这种持续紧绷的空转比连续写两小时代码还累。等你终于把问题修好会有一种被掏空的感觉不是因为工作量大而是因为同一个问题在你脑子里被反复过载了太多遍。顺便说一句小龙虾这个叫法我是服气的。虾跟瞎谐音这种循环干多了确实容易瞎忙活另一方面人弓在屏幕前面来回弹的样子也确实像只虾。它不是某款工具的名字而是状态的代称——一个应该被工具消灭的状态。那问题来了这种循环能自动化吗能。但它缺的不是更好的复制粘贴而是一个会自己看结果、自己决定下一步动作的主体。这就是 Claude Code /loop 上线的意义。2. /loop 的本质它把看结果、想下一步这件小事收了2.1 /loop 在终端里到底干了什么先说清一个概念/loop 不是一个聊天指令也不是一个宏它是一套完整的行动—观察—调整循环流程。你在 Claude Code 里输入loop 让项目里所有测试通过实际命令是/loop在斜杠后跟你的目标描述接下来发生的事情大概是Claude 先扫描项目搞清楚测试怎么跑、失败集中在哪些文件。它按顺序处理第一批失败读代码、定位原因、修改文件。改完立刻重新跑测试拿到最新失败结果。如果新报错是它自己改出来的它会注意到这个错是我刚才引入的然后回头修正。迭代到没有失败为止或者达到你设置的最大轮数。这个过程有个学名叫 agentic loop中文社区现在管它叫循环工程也就是 loop engineering。以前这套闭环是每个开发者手动完成的现在 /loop 把整套闭环内置成了命令。换句话说循环从人的工作方法变成了工具的能力。我第一回跑通的时候还挺震撼的。不是说它多聪明而是它终于把AI 改完代码自动跑一遍测试再把结果拿给自己看这个动作补全了。以前用 AI 写代码AI 是盲写的——它看不到自己改完之后的运行效果只能靠你反馈。而 /loop 模式里AI 能看到自己的行为结果能自我修正。这两者之间的差距本质上就是单次问答和闭环执行的差距。2.2 和普通对话式编程的关键区别我做个表格方便你对照理解维度普通对话式编程/loop 循环模式用户指令描述当前这一步描述最终目标流程控制每一步都要用户确认AI 根据反馈自己调整错误处理报错后用户再次提问AI 自己看报错并自我修正适合场景探索性、需要决策的任务目标明确、可自动验证的任务用户精力全程盯流程设好边界后只看结果这个区别我打过一个比方普通对话是你坐在副驾驶每个路口都要你指挥左转右转/loop 是你只报目的地堵车了它自己换路线开错了它自己掉头。当然前提是你得告诉它目的地到底长什么样——这也是后面要说的任务描述技巧。2.3 为什么说这是终端党的解药终端党的工作习惯跟图形界面用户不太一样核心诉求是手不离键盘、眼不离终端。以前的问题恰恰在于AI 对话往往要开浏览器、开桌面应用或者至少切一个窗口。而 Claude Code 本身就是终端里的工具/loop 把看结果—做判断—下命令全部收敛到了同一个终端会话里。你在终端里要做的从搬砖工变成了包工头定目标、设边界、看验收中间的过程交给循环去磨。对习惯命令行的人来说这种掌控感是很舒服的——你不会再因为切来切去而心烦也不会因为几个工具之间上下文对不上而白费力气。3. 上手 /loop环境检查、第一条循环命令、循环控制3.1 先确认你的 Claude Code 能跑 /loop/loop 是相对较新的能力如果你的 Claude Code 是旧版本先升级。命令很简单# 全局安装 npm install -g anthropic-ai/claude-code # 查看当前版本 claude --version # 在线升级到最新 claude updateNode 版本建议 18 以上太老的版本在 npm 安装时容易触发各种兼容问题。升级之后在项目目录里运行claude进入交互终端输入/help确认命令列表里有 loop。不同版本的参数写法可能略有差异以你自己终端里显示的为准。第一次登录需要你的 Anthropic 账号或 API Key。如果之前已经用 Claude Code 写过代码升级完直接就能用不需要重新登录。这里多说一句如果你在公司内网或者有严格的网络策略登录和升级可能比个人环境多一层麻烦具体以官方文档为准别在配置环节卡太久。3.2 写第一条 /loop让 AI 自己把 ESLint 跑干净我建议第一条别整复杂的从一个结果可验证的小任务开始。比如项目里 ESLint 报了一堆错/loop 修复 src/utils.js 里所有 ESLint 报错你回车之后Claude 大概会这样执行先看 ESLint 配置运行npx eslint src/utils.js拿到完整错误列表按文件逐个修改每改几个文件就再跑一次 lint 确认直到输出干净。整个过程你可以盯着终端输出一点一点变正常。如果它改到一半发现自己改错了你能看到它自我纠正的过程——原来的错没了它自己引入的新错它也自己处理掉。这里有个很重要的体验变化以前报错之后把输出粘给 AI这个动作现在不需要了。报错直接产生在同一个终端里AI 直接就能读到上下文不再断裂。3.3 循环控制轮数、暂停、中断、权限/loop 好用但也不能撒手不管。几个关键控制点最大轮数我习惯在任务描述后带上迭代上限比如loop 修复所有测试失败 10防止它无限跑下去。虽然具体写法在不同版本里略有出入但带一个数字或--max-iterations这类参数是通用思路拿不准就输/loop --help。中断任何时候按 ESC循环立即停下停在当前状态方便你检查它改到哪了。这一步很重要别等它跑完才发现方向早偏了。每轮暂停确认如果你希望每轮结束时都人工看一眼再放行可以在任务里加一句每轮结束后等确认的要求或者在工具的交互选项里开启确认模式。权限边界Claude Code 本身就支持限制它能执行的命令和能改的目录。跑 /loop 前把权限收窄到跟任务相关的范围能避免它顺手改了不该碰的文件。提示第一次试 /loop 的朋友我强烈建议你开一个测试分支或者找一个不影响主干的小模块先跑。等摸清楚它的脾气再放到正式项目里也不迟。4. /loop 的实战定位这些活交得放心这些活别碰4.1 三类最适合交给循环的任务一类是批量修复类。比如把所有测试失败修掉把所有 lint 错误清干净把所有 TODO 按注释要求补齐。这类任务的最大特点是结果可以自动验证失败信息就是反馈信号天然适合循环。你不需要告诉它每一步怎么改只需要告诉它验收标准是什么。二类是反复重构类。重构最怕的不是改代码而是改完不知道有没有破坏其他东西。你给 /loop 一句重构某个函数保证所有测试仍然通过它每改一轮就跑一遍测试。实测下来这类任务完成度很高因为反馈信号非常清晰测试通过就是通过不通过就是不通过没有模糊地带。三类是多文件拼装类。写一个新功能时光靠一轮对话往往做到一半就断了要么是文件太多要么是对项目结构不熟。让 /loop 做的话它会先把相关文件都打开摸清依赖关系再按骨架—实现—测试—联调的顺序自己滚。最后你只需要审查它交付的结果。4.2 不太适合的任务我建议别硬上第一需要主观判断的任务。比如 UI 视觉调整、文案语气调整。这类结果没有客观标准循环很容易来回横跳——改了又改怎么说都不对。你问它这个配色行不行它永远觉得行你说再亮一点它改了你又觉得太亮了。这种无休止的拉锯效率反而不如自己手动调。第二强审计流程的步骤。如果每一步都必须有明确的人工确认记录那你还是一步一停别让 AI 一口气跑完。审计要求的项目里有个人的确认痕迹是刚需AI 连续自动修改很难满足这一点。第三环境依赖很重的任务。比如任务需要反复连接外部服务、要真实用户数据才能验证一旦外部环境变化循环很容易陷入无意义的重试。我在老项目上就吃过这个亏后面细说。所以把任务交给 /loop 之前先问自己一句这个任务的结果是否不需人工判断就能验收能就交不能就分步跑。4.3 和 MCP、子代理配合的进阶玩法/loop 不是孤立的。Claude Code 支持 MCPModel Context Protocol你可以给 Claude 挂数据库、浏览器、文件系统、API 客户端这些外部工具。挂上之后循环里就可以做查数据—改代码—调接口—验证结果这种跨系统闭环。再进一步循环里还能派子代理去干专门的事。比如主循环负责改代码子代理负责翻文档、跑性能测试结果汇总回来。这个玩法很像真实项目里主程带着实习生改代码、测试组统一验收的结构只不过现在指挥的人是你。这套能力的上限取决于你定义任务和边界的能力。先从小任务开始练慢慢你会找到手感什么样的任务描述能跑得顺什么样的边界条件能让它不跑偏。5. 实测中的坑空转、连锁改坏、token 燃烧5.1 循环空转最折磨人的一种失败我在一个老项目上跑 /loop任务很简单修复 api/v1 模块下所有单测失败。结果它跑了五轮每一轮都在改同一个文件而且每次都是同一个报错。为什么因为那个测试依赖一个外部服务本地根本起不来。Claude 每次都试图改代码绕过但绕不过去——它卡在了一个我不可能从这个报错里自己学到更多的死结。怎么识别空转看终端输出连续几轮动作一样、结果一样没有新的信息进来那就是空转了。对策有三第一启动前把外部依赖准备好能 mock 就 mock减少环境不确定性第二设定最大轮数空转超过额定时直接退出人工接管第三任务描述里写清楚如果连续两轮没有进展停下来解释原因这种指令对模型很有效它会主动停下来等你而不是傻乎乎地一遍遍重试。5.2 改一处坏一处给循环加守门规则/loop 跑多文件任务时最容易出的问题为了修一个函数它按自己的理解改了另一个文件的引用结果把一处原本好好的功能弄挂了。表现是轮次越往后测试红色反而越多。我现在的做法是任务描述里明确写每轮修改后跑一遍完整测试如果增加了新的失败先撤销本轮的无效修改再继续。这句话看起来简单但能让 Claude 自己约束自己效果立竿见影。还可以配合目录权限只允许它动 src 下的文件不让它碰配置文件、部署脚本这些改错代价高的地方。权限这东西宁可先收紧再放宽别一上来就给满。5.3 token 消耗与费用控制别让循环烧起来循环比对话贵这是物理事实——每多跑一轮就是多几次模型调用。粗算一笔账一次 10 轮的 /loop假设每轮读改写涉及上下文十几万 token哪怕输出只有几千 token累计输入就是百万 token 级别。按当前主流 API 价格这大概是 1 到 3 美元的量级。如果任务复杂、每轮读的文件多这个数字还可能翻倍。跑大循环前先看一眼 API 账单别等月底才发现超了。我的经验是首次试跑务必设置最大轮数3 到 5 轮足够判断一个任务值不值得继续跑大项目先小范围试比如先让 /loop 处理某个子目录确认思路对了再放开全仓上下文太长时主动执行/compact压缩对话历史能显著减少后续轮次的 token。如果觉得官方 API 价格肉疼社区里有 cc switch 这类工具可以把 Claude Code 的请求转到 DeepSeek、Qwen、GLM 这些模型上/loop 命令照用成本能降一截。官方接口跟第三方网关的稳定性各有取舍我是主用官方、备一个网关兜底量大的脏活累活走网关精雕细琢的活儿留在官方。5.4 长时间运行和断连终端会话怎么保活/loop 跑大任务可能持续很久笔记本电脑合盖、SSH 断线、网络闪断都会把会话杀掉。我的习惯是任务交给 tmux 这类终端复用工具托管在 tmux 的 session 里启动 claude然后挂后台。就算笔记本合盖回到电脑前会话还在。跑的时候开一个分屏实时盯日志或者用watch定时刷新测试结果不用一直盯着屏幕。Tabby 这类终端工具也支持会话管理换机器了还能接着看体验也不错。总之跑 /loop 前先把会话保活安排好不然跑到一半断了前面的 token 就白烧了。6. 跟小龙虾说再见之后我的终端工作流变成了什么样6.1 终端里的新日常现在的日常大概是这样的拿到一个明确的修复需求先自己在终端里跑一遍确认问题范围然后写一条 /loop 命令把目标、验收标准和边界条件都塞进去。跑起来之后我去干别的事或者开一个 tmux 分屏看它输出。它跑完会给我一版结果我 review 一遍有不对的地方直接补一条指令让它重跑。这套流程里手动复制粘贴基本绝迹了。偶尔又要从某个地方拷贝报错出去我会下意识想这活儿其实应该包进 /loop 里。6.2 loop engineering成为终端党的新基本功现在圈子里聊 loop engineering 的人越来越多。我的理解是它讲究的不是 AI 怎么循环而是人怎么把任务定义成一个AI 能自己闭环的形态。关键就三件事目标要可验证别写优化一下性能要写让接口 p95 延迟低于 200ms边界要清晰说清楚哪些文件能改、哪些文件别碰反馈要通顺让 AI 有办法自己检查自己不管是跑测试还是跑 lint。这三件事做好不管 Claude Code 还是别的 Agent 工具跑起来的靠谱程度都会上一个台阶。6.3 最后分享一句实在话/loop 不是万能药。我见过最失败的用法是把一个需求描述得含糊其辞就丢给循环然后抱怨 AI 越改越乱。工具再强也只是把会不会做事的决定权交还给了你的任务定义能力。但话说回来能用一条命令把一下午的小龙虾式调试压缩成几分钟的自主循环这个变化确实值得每个终端党上手试试。至少对我来说那个弓着腰在终端和对话框之间反复弹来弹去的下午已经很久没出现过了。