Claude Code 的 /loop 一上线,终端党的日常画风突然就不一样了。以前我调试报错的状态,圈里叫“小龙虾”——张牙舞爪一下午,报错复制来粘贴去,最终进度还是零点几的那种挫败感。现在 /loop 把“执行命令→看回显→改代码→再跑”变成了自动闭环,你只需要定好目标、设好轮次上限,剩下的事情它会自己在终端里循环收敛。这篇文章就从终端党视角唠唠 /loop 到底是什么、怎么装怎么配,顺便把 OpenClaw、DeepSeek/Qwen/GLM、LM Studio 本地模型这些周边玩法串起来。适合被重复劳动折磨过的 CLI 用户,也适合想把 Claude Code 接进现有工具链的团队。
1. 别急着逐行敲了:/loop 到底改了什么
1.1 “小龙虾”是一个真实的终端场景,不只是网络热词
“小龙虾”这个说法在程序员圈子里流传了一阵:不是说你真的会变成虾,而是说你在终端前调试代码时,状态像极了虾在原地打转——看到一行输出,下意识复制,贴给 AI,拿到新命令,跑一下,又是下一个报错。这种“人肉循环”在过去消耗了我大量时间。举个真实例子:一个 Python 项目的测试套件挂了 12 个用例,我挨个看堆栈、改代码、重新跑,单轮循环大概 3 分钟。前 5 个用例都是同一类问题还好,到了第 6 个出现了新异常,前面改的代码反而引发了连锁失败。那天晚上我从 8 点改到 11 点,最后 git diff 一看,有效改动就两个文件。
这个环节的本质是:人承担了“循环控制器”的职责。AI 负责出主意,终端负责执行,但“观察→判断→再次触发”这个最累的部分一直由人来做。你不觉得奇怪吗?我们写程序时早就习惯用 for、while 让机器自己循环,到了用 AI 编程时反而退回成“一问一答”的人工循环。把这段逻辑交给程序自己,让它在轮次之间自动流转,这正是 /loop 想解决的事情。
1.2 /loop 不是挂机脚本,是 loop engineering 的落地
loop engineering 这两年社区提得很多,核心一句话:让智能体在“动作→观察→反思→再动作”的环路里自己转起来,直到满足退出条件。Claude Code 本来就有执行终端命令的能力,但默认情况下它更像一个随叫随到的助手:Prompt 一来一回,节奏始终由人控制。/loop 把节奏也交了出去,它不再满足于“给你一个答案”,而是“帮你把一件事做完”。
这里要分清两件事。/loop 和终端复用(tmux、screen、Windows Terminal 多标签、Tabby 分屏)不是一回事。终端复用解决的是窗口长期驻留、断线重连的问题,你可以把 Claude Code 挂在 tmux 里跑一晚上;但 tmux 本身不会帮你看报错,也不会把新输出喂回给 AI。真正干活的是 /loop 内置的循环引擎,终端复用更像是给它提供一个不会掉线的“工位”。两者互补,不是替代关系。
1.3 这篇文章适合谁
先说结论:如果你每天跟终端打交道超过两小时,并且经常处于“跑一下、看报错、再跑”的状态,/loop 值得你花一个下午认真配置。如果你在团队里负责环境搭建,也想把 Claude Code 接到 DeepSeek、Qwen、GLM 或者本地推理模型上,后面的环境章节可以直接照着抄。如果你是纯新手,第一次听说 Claude Code,也不需要慌,我会从 Node.js 安装、终端选择开始讲,你只需要跟着敲命令,不用先补一堆前置理论。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 落地准备:终端、安装与踩坑
2.1 终端选型与一张基础小抄
Windows 上我现在的日常组合是 Windows Terminal 加 Tabby。Windows Terminal 胜在启动快、和 WSL 集成好,但要说分屏、多主题、snippet 管理,Tabby 更顺手。Tabby 这类终端工具的核心价值不是“好看”,而是它能把 SSH 会话、本地 PowerShell、WSL 塞进同一个窗口,还能对每类会话保存独立的启动目录和颜色方案。实操中我主要用它同时开四个标签页:一个跑 Claude Code,一个看测试日志,一个是 git 操作台,还有一个留作临时命令。
Linux 下其实没那么多选择,系统自带的 GNOME Terminal 或者 Konsole 就够用。几个基础操作可能有人还不太熟:在 GNOME 桌面里打开终端通常是 Ctrl+Alt+T;终端里想把光标换到上一行,一般是 Ctrl+Shift+Enter 或 Alt+上箭头,不同终端略有差异;命令行里想快速回到上一条命令, Ctrl+P 比按上箭头稳定。改 IP 我习惯用 nmcli:nmcli con mod eth0 ipv4.addresses 192.168.1.10/24,改完 nmcli con up eth0 生效,比直接改 /etc/network/interfaces 少踩很多坑。
2.2 Node.js 与 Claude Code 安装
Claude Code 官方推荐通过 npm 全局安装,所以第一步是装 Node.js。Windows 和 macOS 直接去官网下载 LTS 版就行,Linux 下我更推荐用 nvm 管理版本,避免系统包管理器里的 Node 版本过老。安装完在终端里验证一下:
bash复制node -v
npm -v
然后全局安装 Claude Code:
bash复制npm install -g @anthropic-ai/claude-code
装完输入 claude 就能进入交互界面。首次启动会要求授权登录,走的是浏览器 OAuth 流程,授权完成后命令行就能正常使用了。VS Code 用户建议再装官方扩展,这样编辑器里直接开终端跑 claude,不用来回切窗口。有一点要注意:扩展终端默认继承 VS Code 的环境变量,如果你在系统终端里能用 claude、在 VS Code 里报“command not found”,大概率是 VS Code 没有继承 PATH。
2.3 终端启动报错:conpty / winpty / WSL 状态
很多人第一次跑 claude 就撞上“终端进程启动失败: 启动期间发生本机异常(无法启动 conpty)。已移除 winpty”。这个报错挺玄学,根源是 Windows 上终端后端的兼容问题。conpty 是 Windows 10 1809 以后引入的伪终端机制,VS Code 的集成终端默认依赖它。如果你的系统版本太老,或者之前装过 winpty 相关的配置残留,就会触发这个异常。
我的处理顺序是固定的:先更新 Windows Terminal 和 VS Code,然后在 VS Code 设置里搜 terminal.integrated.defaultProfile,把默认终端从 PowerShell 临时切到 cmd,跑一次 claude,如果正常再切回来。这一步能把“conpty 初始化失败”和“某个 profile 配置坏了”两种原因区分开。如果你在用 WSL,顺手在 PowerShell 里跑一下 wsl --status 和 wsl --update。很多人把这条命令打成 sl2,这就是热词里那个“sl2环境”的来由——其实想说的是 WSL2。如果状态显示默认版本是 1,执行 wsl --set-default-version 2 切到 WSL2,很多诡异的路径和权限问题会直接消失。
还有一类常见问题是 VS Code 的解释器与终端版本不一致。比如你在 VS Code 里选了 Python 3.11 的解释器,但集成终端激活的 venv 还是 3.8,导致 claude 调用命令时行为不一致。检查方法很简单:终端里输入 which python && python --version,再对比解释器列表里的路径。不一致就用 Ctrl+Shift+P 打开“Python: Select Interpreter”重新选一次,确保终端 PATH 和解释器路径指向同一个虚拟环境。
3. /loop 核心实操:多窗口、循环执行与命令直调
3.1 闭环三要素:观察、决策、执行
用恒温器来理解 /loop 是最快的:恒温器有一个目标温度(比如 26°C),它靠温度传感器“观察”当前室温,内部逻辑“决策”是开制冷还是关压缩机,然后“执行”切换到对应继电器。/loop 也一样,你给它一个目标,比如“让测试套件全绿并提交代码”,它就在自己的循环里反复做三件事:读取测试输出(观察)、判断失败原因(决策)、运行命令或修改文件(执行)。
很多人第一次用 /loop 失败,是因为没给退出条件。现实中的恒温器有明确的阈值,AI 循环没有明确结束条件就会漫无目的地乱跑,甚至越修越糟。所以在定义循环时,我会同时给出“成功条件”和“兜底条件”:成功条件是测试全绿,兜底条件是连续 5 轮没有进展就停止并输出摘要。这比单纯说“修好它”靠谱一个量级。
3.2 一个完整的 /loop 实战
我拿一个典型的 Python 项目演示具体操作。进入项目目录后启动 claude:
bash复制cd ~/work/myapp
claude
然后在交互框里输入 /loop,它会进入循环定义模式。我会这样描述目标:
code复制目标:让 pytest 测试套件全部通过。
说明:当前有 12 个失败用例。每轮开始先用 pytest -x 跑一次,统计失败数量;根
据堆栈修改 src/ 下的源码;每轮结束必须重新执行 pytest 记录结果。
退出条件:失败数降到 0,或连续 5 轮失败数未下降,或总轮次达到 20 次。
每轮结束时打印一个简短进度摘要。
提交之后,/loop 就开始自己转了。第一轮通常发生在 10 到 30 秒内,Claude 会先执行 pytest,然后阅读堆栈,修改代码,再跑下一轮。我这时候不会盯着终端看,而是切到 Tabby 的另一个标签页该干嘛干嘛。每隔一阵子回来瞄一眼 loop status,它能看到当前轮次、失败数变化、最近一次修改的文件列表。
如果我看着发现某几轮在同一个地方反复打转,就输入 loop stop 先停掉,把前面几轮的 diff 看一遍,给一条更具体的约束再让它重新跑。这个“人工打断”的时机非常重要,等它自己撞上 20 轮上限通常已经浪费了半小时。
3.3 多窗口会话:上下文隔离的正确姿势
/loop 支持多窗口,这是热词里“loop 多窗口”的来源。你可以同时启动多个独立循环,每个循环有自己独立的上下文、项目目录和任务目标。我的习惯是并行开两个窗口:一个跑测试修复,另一个做依赖升级或重构,互不干扰。命令大概是 loop new 开一个新会话,loop list 查看所有活跃循环,loop attach 接回某个会话,loop detach 暂时离开。它的上下文隔离做得比我预期好——A 窗口改了某个模块,B 窗口不会自动感知,除非你显式让它读磁盘上的最新文件。
这种隔离在一个人同时处理多条任务线时非常值钱。以前我在同一个会话里让 AI 又改代码又写文档,上下文一长,它经常把测试环境当成生产环境来回答。拆成多个 loop 窗口之后,每个窗口只负责一条逻辑线,回话质量和速度都有明显提升。
3.4 让 Claude 直接执行终端命令的姿势与边界
Claude Code 一直有执行终端命令的能力,/loop 把它变成了循环内的固定动作。你可以在 Prompt 里明确说“每轮运行以下命令并读取输出”,它就会自动执行并把结果纳入下一轮判断。“claude code 如何直接执行终端命令”这个高频问题,答案其实就是:不用特别配置,它在循环里默认就是这么干的,关键是把命令写清晰。比如让它“先 git status 再看 diff”,比笼统说“检查一下改动”准确得多。
但边界必须提前画好。我见过有人让 AI 全权处理 git 操作,结果它把本地 commit 历史搞乱了。现在我自己的规则是:只允许 /loop 在项目目录内执行命令,禁止 rm -rf、禁止推送远端、禁止修改 .git 配置。Claude Code 的命令执行通常是带确认机制的,但是循环执行中确认会打断节奏,所以我会在描述目标的时候就把禁区写明白:比如“可以使用 git add/commit,但不允许 push,不允许 force push”。
4. 换模型与本地推理:DeepSeek/Qwen/GLM/LM Studio
4.1 为什么要换模型、怎么换
Claude Code 默认走 Anthropic 官方接口,但实际使用中很多人有更具体的需求:团队要求用 DeepSeek、通义千问 Qwen 或者智谱 GLM,或者干脆想用本地模型保证代码不出内网。换模型的底层原理不复杂:Claude Code 通过环境变量或配置文件指定 API 端点、模型标识和密钥,只要你把这三个参数换成目标服务商的,它就会把请求发过去。
常见环境变量包括 ANTHROPIC_BASE_URL 指定 API 地址、ANTHROPIC_MODEL 指定模型名、ANTHROPIC_API_KEY 指定密钥。但手动改环境变量在频繁切换场景下太容易出错,所以我更推荐用配置切换工具,也就是社区常说的 cc-switch 这类方案。
4.2 cc-switch 实战
cc-switch 这类工具核心做一件事:帮你管理多套 provider 配置,一键切换。它把 Anthropic 官方、DeepSeek、Qwen、GLM、本地 LM Studio 等不同端点预先存成配置,切换时直接改写到 Claude Code 的配置文件或者当前会话环境变量。
我实际的操作流程是这样:先装好 cc-switch,然后在配置界面里添加 provider。比如 DeepSeek 的配置,端点填它的 API 地址,模型标识按服务方文档填,密钥填你自己的 key。再比如智谱 GLM,同样是端点加模型标识加密钥。保存之后,在终端里敲一条切换命令,比如 cc-switch use deepseek,再用 claude 启动,此时它实际走的已经是 DeepSeek 的接口了。
有一点必须提醒:不是所有第三方服务都原生提供 Anthropic 协议兼容,cc-switch 或者对应的网关工具是否内置格式转换,直接决定某家模型能不能用。社区里经常说“接入 DeepSeek 之后速度很快”,前提就是这家服务做了兼容层。所以看到别人的切换成功经验,第一反应应该是翻一下他用的 switch 工具版本和模型标识,而不是照抄配置。
4.3 本地模型接入:LM Studio 与 Ollama
本地模型是另一条完全不同的路。它不依赖外部 API,数据不出机器,代价是质量和速度取决于你的显卡。两个主流方案:LM Studio 和 Ollama。
LM Studio 装好后会在本机起一个 OpenAI 兼容的服务,默认地址是 http://localhost:1234/v1。你在里面下载一个合适的量化模型,启动本地服务,然后让 Claude Code 的配置指向这个地址,模型标识填你在 LM Studio 里加载的模型名,就能让 /loop 跑在本地推理上。效果上,本地模型的代码能力跟顶级云端模型还是有差距,更明显的问题是速度——一个完整的失败修复循环需要多轮推理,消费级显卡跑大模型,每轮都要等。我现在只拿本地模型处理两类任务:涉及敏感代码的分析,以及离线环境下的简单重构。
Ollama 的玩法类似,默认端点是 http://localhost:11434/v1。它胜在命令行简单、模型管理方便,ollama pull qwen2.5-coder:7b 拉下来,ollama serve 起服务,配置指过去就能用。热词里总有人问“OpenClaw 是不是只能用接入 API 的方式使用算力”,答案是否定的——OpenClaw 这类终端智能体完全可以把 Ollama 或 LM Studio 作为推理后端,用的就是你本机的 GPU 和 CPU 算力,只是很多人一开始没意识到这一点,白白买了不必要的 API 额度。
5. OpenClaw 与终端生态协作
5.1 OpenClaw 的定位:终端智能体与编排层
OpenClaw 在社区里越来越常见,它的定位可以理解成“终端侧的智能体编排框架”:把不同来源的命令工具、自定义 skill、模型后端组合起来,形成一套可复用的自动化能力。和 Claude Code 配合时,OpenClaw 通常扮演两个角色:一是任务调度器,定时或按条件触发 Claude Code 的循环任务;二是技能扩展中心,把日常要重复做的操作封装成 skill,让终端智能体按需调用。
我个人的体感是,OpenClaw 项目还在快速迭代期,功能变更频繁,不建议一开始就把复杂业务压上去。先跑通“安装→配置模型→执行一个简单 skill”的流程,等熟悉了它的配置结构再慢慢加任务。
5.2 多端部署:Windows Companion 与 Termux
OpenClaw 的部署目前最常见的是三类场景:Windows 桌面、安卓手机、Linux 容器。Windows 部署时,很多人会提到 Companion 组件,它的作用是让终端智能体能调用 Windows 本地的命令执行能力,尤其是配合 WSL 里的服务一起用。配置思路不复杂:装好依赖,配置模型后端,再启动 Companion 进程,让它和主进程建立连接。
安卓端最主流的跑法是用 Termux。Termux 本身是个运行在安卓上的 Linux 环境,先 pkg update && pkg install nodejs git 装基础依赖,拉下 OpenClaw 源码,安装依赖,然后配置模型后端。手机端算力有限,实际用途更多是“带一个随时能跑的终端助手”,而不是跑重型循环任务。如果你没有真实需求,不建议花大量时间折腾手机端——配置过程的坑比 Windows 多不少。
5.3 算力接入误区与 ROS2 场景
先澄清热词里的高频误会:OpenClaw 的算力来源不是必须走远程 API。它作为一个智能体框架,推理后端可以是任意 OpenAI 兼容端点,本地 Ollama、LM Studio 都行。决定算力消耗的核心是跑什么模型,而不是框架本身。社区里还有一种玩法是把 OpenClaw 接入 ROS2 环境,也就是热词里出现的 rosclaw——在 Gazebo 仿真或者真实机器人工作流里,让终端智能体帮忙看日志、分析传感器数据异常、辅助调试启动脚本。这个方向目前偏小众,但对机器人开发者来说,等于往终端里塞了一个能读日志、能跑命令、能帮你排查问题的助手。它的价值不在写机器人控制代码,而在于处理那些“看 log 看到眼瞎”的重复工作。
6. 高频问题排查实录
6.1 WSL 状态与“sl2”笔误
很多人把 wsl --status 记成了 sl2,在 PowerShell 里自然是一串报错。真正要确认的是默认版本是不是 WSL2,命令是:
bash复制wsl --status
wsl --list --verbose
如果显示默认版本是 1,执行 wsl --set-default-version 2。WSL2 的网络和文件系统行为更接近真实 Linux,很多在 WSL1 下出现的“终端里能跑、服务里连不上”的问题会少很多。另外,升级到 WSL2 后如果原来项目路径在 /mnt/c 下,建议迁到 WSL 自己的文件系统,比如 ~/work,否则跨文件系统 IO 会明显拖慢测试和 git 操作。
6.2 自引用循环这类“玄学”错误
“self referencing loop detected for property 'mem_memberinfo' with type 'System.Reflection...'”这类报错,和 /loop 本身无关,它来自 .NET 的序列化机制。通俗理解:你让程序把一个对象转成 JSON,但这个对象内部有个属性指回了它自己,类似两个文件夹互相包含对方的快捷方式,压缩软件一打包就发现“包含自身”,只能中断。
大多数情况下是某个管理工具或调试面板在序列化时没有配置循环引用处理。解决方向有两个:第一,如果是自己的 C# 程序,序列化时配置 ReferenceHandler.IgnoreCycles 或者 Preserve,让序列化器知道怎么处理自引用;第二,如果是第三方工具报的错,优先检查工具版本和是否开启了某个调试反序列化功能,别急着怀疑 Claude Code 或 OpenClaw。
6.3 订阅限制与企业终端合规
热词里有一条报错:“your organization has disabled claude subscription access for claude code”。如果这条来自你的企业账号,那说明组织层面已经把 Claude Code 的订阅接入关掉了。这时候你在终端里再怎么折腾配置都没有用,应该走企业内部的申请审批流程,或者在合规允许的前提下自备个人订阅账号。另外一个常被忽略的维度是终端准入和保密检查系统。在受管网络环境里,安装命令行 AI 工具会触发终端准入或保密检查策略,这类工具的安装、联网、行为审计都有明确流程。我见过不少人自己偷偷在受管终端装了 AI 工具,结果被合规扫描发现,整个团队都受影响。在受管环境里,先把工具用途报备、把涉及的数据边界讲清楚,比什么都重要。
6.4 管理终端 ACL:只允许唯一登录
顺带说一个网络管理员的场景:交换机管理终端只允许特定 IP 登录。以常见的华为交换机为例,思路是先用 ACL 定义允许的源地址,再把这个 ACL 应用到 VTY 用户界面。大致配置如下:
bash复制acl number 2000
rule 5 permit source 192.168.1.10 0
rule 10 deny
#
user-interface vty 0 4
acl 2000 inbound
authentication-mode aaa
这样只有源 IP 为 192.168.1.10 的管理员终端能建立 VTY 登录会话,其他来源全部拒绝。虽然这和 /loop 没有直接关系,但如果你在管理网络里部署 AI 终端工具,把“谁能在哪台终端上跑什么”限清楚,是企业落地 CLI 工具时绕不开的一环。
7. 写在最后:两周实战后的个人体会
/loop 用下来,我最真实的感受是:它没有让我彻底摆脱终端,但让我摆脱了“复制报错→粘贴→等答案”这个最消耗心气的循环。过去一个需要盯一下午的测试修复,现在把目标、退出条件、禁区写清楚,交给 /loop,我只要在关键时刻回来拉一下状态、看一轮 diff,就能判断是继续放养还是介入。
一个小建议:别把结束条件写成“修复所有 bug”,而要写成“能输出一份包含每轮失败数和修改文件的报告”。前者是理想,后者是可验证的产物。一旦条件不可验证,loop 就会变成一个白白烧钱的死循环。另一个经验是把 checkpoint 放在造轮子的关键节点:每跑完 5 轮,停一下看进度,再决定是放行还是收紧约束。
如果你现在正准备改造自己的终端工作流,我建议从一个小项目试起:挑一个你熟悉、测试覆盖还行的小仓库,跑一次 /loop,看它从报错到全绿的过程,也看它卡在哪类问题上。这一步做完,你对 loop engineering 的边界理解会比看十篇介绍文章都扎实。
