a2Mia姐Claude Code 上线 /loop 的消息，这两天在终端党的小群里炸开了锅。消息出来之前，我们还在群里互相吐槽：凌晨三点还在盯着日志，一遍遍让 AI 重跑同一段任务，手指 Ctrl+C 都快按出肌肉记忆了。圈子里管这种状态叫“被小龙虾夹住了”——循环、重复、越挣扎越紧。所以当我看到 /loop 这个命令真的落地时，第一反应不是“又更新了什么玩具”，而是“终于有人把循环本身做成了命令”。
这篇文章不打算做成功能说明书，而是想从实际干活的角度聊聊：/loop 到底解决了什么痛点，怎么把它接入到日常终端工作流里，以及我在安装和使用过程中踩过哪些坑。适合正在用 Claude Code 做自动化脚本、批量重构、持续测试的人，也适合那些还在犹豫要不要从“人肉循环”切换到“命令循环”的终端用户。读完你至少能分清 /loop 和普通重复执行的区别，并且知道怎么在 VS Code、Windows 终端、WSL 这些常见环境里把它跑稳。
1. /loop 到底解决了什么问题
1.1 “小龙虾”式循环：终端党的至暗时刻
先说说“小龙虾”这个梗。群里的人把“反复让 AI 做同一件事”叫作被小龙虾夹住，原因是那种循环特别像龙虾钳子：你越急着挣脱，它夹得越紧。典型场景是这样的：你让 Claude 改一个接口，它改完第 17 个文件之后停下来，提示“请检查是否还有其他地方需要同步修改”。你检查，发现确实漏了，于是把它丢回去，说“继续”。它又补了 3 个文件，然后再次停下来说“我建议你再跑一遍测试”。你跑测试，挂了，又把报错贴回去……整个过程你可能要手动重复七八轮。
这种循环最折磨人的不是“次数多”，而是每一步都要你亲自介入。AI 每完成一小步，就停下来等你确认，然后你复制报错、粘贴回去、回车、等结果、再看日志。这个间隙里你的注意力全被切碎了，一会儿切到编辑器，一会儿切到终端，一会儿在浏览器里查文档。等到事情做完，人已经累垮了，但回头一看，真正“动脑子”的部分其实很少。
1.2 Loop Engineering：把“再跑一遍”变成一种方法论
群里讨论多了，自然有人提出“循环工程”的概念。Loop Engineering 并不是什么玄学，你可以把它理解成提示词工程的一个分支：不是让模型一次性生成完美答案，而是让它在一个可控的循环里不断评估、修正、重新执行，直到满足你定义的退出条件。
传统做法是“人肉循环”，人类负责判断结果、提取失败信息、重新发起请求。Loop Engineering 则是把“判断”和“重试”的部分也交给模型和脚本。比如你可以设定一个目标：“把这个仓库里所有的 TODO 注释替换成具体的实现说明，每完成一个文件就自动编译一次，编译失败就自行修复，直到全部通过。”如果单靠手动对话，这一串指令每一步都要你自己盯着。但如果有一个机制能让模型在这个循环里反复跑，直到所有文件通过编译，那效率就会高一个量级。
/loop 命令的出现，本质上就是把这种循环机制内置到了 Claude Code 里。你不必再自己写一堆 shell 脚本去反复调用 API，也不用靠外部工具做“循环调度”，直接在交互界面里声明一个循环任务，然后等它收敛。
1.3 /loop 命令与手动循环的本质区别
很多人的第一反应是：“我自己写个 while true; do claude ...; done 不也一样吗？”这还真不一样。手动循环只是把同一个命令反复执行，但每一次执行都是全新的上下文，AI 不会记得上一轮改了什么、为什么失败。/loop 的核心在于保留了对话上下文和中间产物，每一轮迭代都能基于上一轮的失败信息继续前进，而不是从头再来。
举个例子。假设你要处理 200 个 Markdown 文件，给每个文件补一个统一的 front matter 头。手动循环的方式是：200 次独立请求，每次都要把“规则”重复一遍，然后让 AI 读文件、改文件。/loop 的方式是：只声明一次规则，模型会在同一上下文里逐文件处理，遇到格式不对还能当场修正。省下的不只是输入量，而是大量重新理解规则的 token 和你的等待时间。
所以，/loop 本质上是把“循环”从一个“重复动作”变成了“带记忆的迭代闭环”。它更适合那些需要不断结合反馈进行调整的任务，而不是简单的批处理。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 安装与接入：把 Claude Code 跑起来
2.1 安装 Claude Code 前的环境检查
无论你是想用 /loop 还是其他命令，第一步都得先把 Claude Code 装好。官方推荐的方式是通过 Node.js 安装，所以第一件事就是确认你的机器上有 Node.js，而且版本不能太老。我在安装的时候看到很多报错，最后发现都是 Node 版本太低导致的。
建议先跑一句：
bash复制node -v
如果输出是 v18 以下，建议先去官网下载最新的 LTS 版本。装完之后顺手把 npm 也升到最新：
bash复制npm install -g npm@latest
另外，Claude Code 对操作系统的支持不太一样。macOS 和 Linux 上一般比较顺，Windows 上我强烈建议先装好 WSL2 再使用。虽然 Windows 终端理论上也能跑，但我在实战里发现，文件路径、权限、子进程信号处理这些问题在 WSL2 里要省心得多。安装 WSL 的命令很简单：
bash复制wsl --install
装完之后记得跑一下 wsl --status 确认当前状态。如果显示的是 WSL1，最好升级到 WSL2，否则一些依赖本地文件监听的场景会变得很慢。
2.2 一条命令完成安装与初始化
环境没问题之后，安装本身反而很简单。官方提供的是 npm 全局安装包：
bash复制npm install -g @anthropic-ai/claude-code
装完以后在终端里输入 claude 就能进入交互界面。第一次启动会让你确认登录方式，按提示完成授权即可。我建议第一次先进去跑一个简单任务，比如让它读一下当前目录的 README，确认整个链路是通的，再开始尝试 /loop。
如果你的机器上已经装了 VS Code，也可以直接在 VS Code 的终端里启动 claude，这样 AI 修改文件后你能立刻看到编辑器里的变化。我之前遇到过一种情况：在外部终端里让 Claude 改代码，改完后 VS Code 里一片灰，必须手动点一下刷新才知道文件变了。在 VS Code 的集成终端里启动，会少很多这种“文件没变”的错觉。
2.3 VS Code 与终端接入的两种姿势
关于 VS Code 接入，实际使用中我试过两种方式。
第一种是在 VS Code 的集成终端里直接敲 claude。这种方式最直观，AI 的操作结果会实时反映在编辑器里，你甚至不用切窗口就能看到它创建了哪些文件。缺点是你的终端会被 Claude Code 占住，如果还想同时跑其他命令，开一个多窗口是必须的。
第二种方式是使用官方提供的 VS Code 扩展，把 Claude Code 集成到侧边栏。这个方式更适合喜欢用可视化面板的人，填写需求、看日志、切换会话都比纯终端友好。不过对我这种终端原教旨主义者来说，扩展面板反而显得重。我更愿意用第一种方式，配合终端复用工具来解决“占住终端”的问题。
我个人的建议是：如果你平时已经在用终端复用（比如 tmux 或者 Tabby），那就用第一种；如果你习惯鼠标操作，就用第二种。没有绝对的好坏，关键是别让工具反过来绑架你的习惯。
2.4 没有订阅怎么办：本地模型接入思路
我知道会有人问：“我没有 Claude 订阅，能不能用 /loop？”答案是可以尝试，但你要清楚这属于社区方案，不是官方支持路径。
目前社区里比较常见的做法是让 Claude Code 的接口指向本地模型服务器，比如 LM Studio。你可以先在 LM Studio 里加载一个适合编程的模型，然后启动它的本地 API 服务，默认通常监听在 11434 端口。接下来需要把 Claude Code 的模型端点改成本地地址。具体变量名在项目文档里能找到，大致是调整 ANTHROPIC_BASE_URL 或类似的环境变量，指向 http://localhost:11434。
不过我劝你降低预期。本地模型在执行简单循环任务时还凑合，一旦任务需要长上下文和复杂的工具调用，效果会明显打折。我自己试过一个中等规模项目的重构，本地模型跑了两轮就开始前后矛盾，上下文里的关键信息被冲掉了。/loop 对模型的“长期记忆”能力要求很高，不是所有模型都能胜任。
3. /loop 实战：三个终端高频场景
3.1 场景一：批量重构代码文件
第一个适合 /loop 的场景是批量重构。比如你有一个老项目，所有的接口返回结构都是 {code, msg, data}，现在需要统一改成 {success, message, payload}。如果用编辑器全局替换，一是不安全，二是很多地方需要根据上下文做调整，比如字段名引用的地方也要跟着改。
这时候你可以进入 Claude Code，输入类似：
bash复制/loop 把 src 目录下所有接口返回结构从 {code, msg, data} 调整为 {success, message, payload}，要求同步更新所有引用字段，每改完一个模块就运行一次项目测试，失败就自查并修复，直到所有测试通过
注意，/loop 不是一个魔法咒语。你需要把“目标、约束、验证方式、终止条件”说清楚。上面这段指令里，“改完全部模块后运行测试”是验证方式，“直到所有测试通过”是终止条件。模型在循环里会反复执行“改代码 -> 跑测试 -> 看失败 -> 修代码 → 再跑测试”这个闭环。
我在实际跑这个任务时，最明显的感受是：它真的会自己“翻车”然后自己“爬起来”。有一次它连续三次改了同一个文件都没解决问题，我原以为会卡死，结果它在第四轮突然意识到前面改错位置了，自己回滚了修改，然后从另一个地方入手，最终把测试跑绿了。这种“带上下文的重试”就是 /loop 相比普通循环的价值。
3.2 场景二：让 AI 自己跑测试、修 bug、再跑测试
第二个场景是持续测试。平时我们手动调试一个功能，经常是在终端里跑测试，看到报错，复制给 AI，让它修，修完再跑。这个过程如果是十次八次，人还能忍，但一旦超过二十次，人就会变得非常烦躁，而且容易看漏报错信息。
使用 /loop 后，我把整个流程写成了类似这样的指令：
bash复制/loop 依次运行 tests 目录下的所有 pytest 用例，遇到失败就读取堆栈信息，定位到对应源码并修复，修复后重新执行失败用例，直到所有用例通过为止
这个场景里，关键是给模型充足的“自我检查”空间。你不需要告诉它具体怎么修，你只需要明确“失败的判据”和“结束的判据”。模型会自己调用终端命令去跑测试、自己解析输出、自己决定改哪个文件。
有一点要提醒：如果你的测试用例非常慢，或者有外部依赖（比如需要连数据库），那么循环时间会很长。建议先在小范围内试运行，比如只跑一个测试文件，确认模型能正确理解你的意图后再扩展到全量。不要一上来就丢一个巨大的任务，否则它可能在某个错误分支上反复横跳，浪费大量时间。
3.3 场景三：配合多窗口与终端复用，把循环挂起来
/loop 跑起来之后，最直观的问题就是：我的终端被它占住了，怎么办？我平时用的方案是终端复用工具。如果你用过 tmux，可以在一个会话里开多个窗口，一个窗口跑 /loop，另一个窗口做其他操作。这样既不会打断循环，又能随时监控进度。
如果用 Tabby 这类终端工具，多标签页是一个天然的优势。我习惯把 Tabby 分成左右两栏：左栏跑 Claude Code 的 /loop，右栏用来查看日志、跑 git 命令、或者在 WSL 里检查系统状态。这样即使循环跑很久，我也能随时看到它进行到哪一步，而不会像以前一样干瞪眼等待。
还有一个细节：在 WSL2 里跑 /loop 时，建议用 tmux 而不是直接在 WSL 窗口里跑，原因很简单——如果你的 Windows 终端不小心被关掉，tmux 会话能保留住正在运行的循环任务，重开终端后可以重新连回去。这个习惯救了我好几次，强烈建议养成。
3.4 逃生门：如何安全地中断一个失控的循环
/loop 虽然好用，但也确实见过它跑偏的时候。比如它反复修改同一个文件，越改越乱，甚至开始删掉一些不相关的内容。这时候你需要知道怎么安全地中断它。
在 Claude Code 的交互界面里，最直接的方式是按下 Esc 或 Ctrl+C，然后输入 stop 或者 q。不过要注意，/loop 在跑终端命令时，直接关掉进程可能会导致一些半成品的文件残留。我建议在执行中断操作之前，先让它“保存当前进度并停止”，也就是输入类似：
bash复制/stop 保留当前已完成的修改，停止进一步的改动，并输出一份变更摘要
这样，循环会停在当前安全边界上，而不是在一半文件改好、一半文件没改的状态下被硬生生杀掉。如果你发现循环已经开始乱改文件，最保险的做法是先用 git 把当前分支切到临时分支，或者先 stash 掉当前改动，再让 Claude Code 停止。总之，跑任何自动化循环之前，先确保工作区是干净的，并且你随时可以回滚。
4. 安装与使用中的常见问题排查
4.1 终端启动报 conpty 异常怎么办
很多 Windows 用户在启动 Claude Code 时遇到过这样一条报错：“终端进程启动失败: 启动期间发生本机异常（无法启动 conpty）。”这个问题的根源是 Windows 终端组件和 shell 之间的兼容性出了问题。
我当时的排查步骤是这样：先把 Windows 终端升级到最新版，然后确认系统语言环境没有异常，再检查 VS Code 的默认终端配置。如果还不行，可以尝试把终端启动参数里的 winpty 相关配置移除掉。部分用户环境里，Git Bash 会注入 winpty 来模拟伪终端，但这玩意儿和 conpty 冲突会导致启动失败。
我的建议是直接改用 WSL2，或者在 Windows 终端里把默认 shell 切到 PowerShell 再启动 Claude Code。实际上很多类似问题到了 WSL2 环境里会自然消失，这也是我强烈推荐 WSL2 的原因之一。
4.2 WSL 状态异常与版本不一致
另一类高频问题出现在 WSL 用户身上。有时候你安装好了 WSL，但运行 wsl --status 会提示环境有问题，或者默认状态处于“正在启动”但一直启动失败。
排查这类问题，我习惯先跑：
bash复制wsl --shutdown
然后重新打开终端，再跑：
bash复制wsl --status
如果依然异常，就要检查两个点：第一，是否同时装了两个发行版，导致默认发行版不一致；第二，磁盘剩余空间是否充足，WSL 的虚拟磁盘如果满了会有各种奇怪的报错。还有一个容易忽略的地方：如果你在 VS Code 里把终端解释器设置为 Windows 本地的 Python，但 WSL 里跑的是另一个 Python 版本，就会出现“解释器与终端版本不一致”的情况，导致 Claude Code 调用命令时拿到错误的环境。
这种版本不一致的问题，解决思路不是去硬调，而是明确你到底要在哪个环境里跑任务。如果任务依赖 Linux 工具链，就老老实实进 WSL；如果依赖 Windows 下的 GUI，就留在 PowerShell。不要混着用，否则你会被环境问题折腾到怀疑人生。
4.3 订阅/权限相关提示
有读者反馈过，启动 Claude Code 时提示“你的组织已禁用 Claude 订阅访问”。这个其实不属于技术问题，很多企业环境会通过策略禁止员工使用外部 AI 工具。你可以联系管理员确认是否放行，或者使用个人账号在个人设备上操作。
另外，如果你是用第三方 API 接入方式尝试，可能会遇到鉴权失败。我的建议是不要图方便去用来路不明的中转服务，一方面不稳定，另一方面存在数据泄露风险。无论是官方订阅还是本地模型，都要确保连接本身是可信的、可控的。
4.4 本地模型接入的常见坑
如果你尝试了把 Claude Code 接到 LM Studio 或者类似的本地模型服务，下面这几个坑大概率会遇到。
第一，端口没开对。启动 LM Studio 后一定要在“开发者”面板里明确开启本地 API 服务，不然即使环境变量指向了 11434，也会连接失败。第二，模型上下文窗口过小。/loop 这种场景特别消耗上下文，如果你的模型只支持 4K 上下文，跑不了两轮就会遗忘前面的指令。建议至少选 16K 以上的模型。第三，工具调用能力弱。有些模型能聊天，但不会主动调用终端命令，这就导致 Claude Code 明明生成了代码，却无法执行验证步骤。你需要在模型选择时关注它的“function call”能力，而不是只看编程分数。
4.5 常见问题速查表
| 现象 | 可能原因 | 处理建议 |
|---|---|---|
claude 命令找不到 |
Node.js 未安装或未加入 PATH | 重新安装 Node.js LTS，并确认 npm 全局目录在 PATH 中 |
| 启动报 conpty 异常 | Windows 终端组件冲突 | 升级 Windows 终端，移除 winpty 配置，或改用 WSL2 |
| WSL 启动失败 | 虚拟磁盘损坏或空间不足 | 执行 wsl --shutdown 后重启，检查磁盘空间 |
| VS Code 终端里 Python 版本不一致 | 解释器指向了错误环境 | 在 VS Code 中重新选择正确的解释器 |
/loop 跑一会就停 |
上下文窗口太小或指令不够清晰 | 减小任务范围，细化终止条件 |
| 本地模型接入失败 | 端口未开放或模型不支持工具调用 | 检查 LM Studio API 服务，更换具备 tool call 能力的模型 |
5. 写在最后：一些个人经验与生态联想
真正开始用 /loop 之后，我最大的变化是：不再害怕那些“需要反复试错”的任务了。以前遇到复杂的重构或者捉摸不定的 flaky test，我总会下意识地拖延，因为我知道接下来会是一长串枯燥的复制粘贴。现在我会先花几分钟把指令写清楚，然后让 Claude Code 自己跑，我只需要定时看一眼进度。它每完成一轮循环，我都能在终端里看到一个清晰的输出，那种感觉确实有点像站在旁边看一个实习生渐渐上道。
除了官方能力，最近我也注意到社区里有人在折腾 OpenClaw 这类开源项目，试图把本地模型、终端自动化、甚至硬件设备都串起来。我自己的想法是，如果能把 /loop 的思路延伸到这些开源生态里，也许以后终端就不再是一个“命令输入器”，而是一个“意图调度器”。你告诉它你要什么，它自己拆解、循环、验证，直到交付结果。这个方向很让人兴奋，但目前还处于早期，没必要盲目追捧。
最后分享一个小技巧：第一次使用 /loop 时，不要立刻投产到重要任务上，先拿一个临时目录练手。创建一个 test-project，放几个故意写错的文件，然后让 /loop 帮你修。这样你能快速摸清它的脾气，知道它什么时候会卡住、什么时候会乱改、以及你的指令应该怎么写才不容易被误解。练熟了再上真实项目，你会觉得“被小龙虾夹住”的日子真的可以结束了。