用 Claude Code 写代码有一个很烦的事：每一轮对话结束，它就停下来等你回复。改一个 bug 要来回五六轮，你得一直盯着终端，看它改完了没，然后敲回车让它继续。本质上你变成了一个人肉"继续"按钮。
v2.1.139 加了两个命令，直接解决了这个问题。/goal 让 Claude 自己干到满足条件为止，不用你催；claude agents 打开一个多会话管理面板，让你同时派发好几个任务，哪个卡住了一眼就能看到。这篇文章是我实际用了两天之后的完整记录。
/goal：设一个完成条件，它自己干到底
最直观的理解
以前的工作流是这样的：
bash
你：帮我把 test/auth 下的测试全部修好
Claude：改了第一个文件（停下来等你）
你：继续
Claude：改了第二个文件（又停下来）
你：继续
...重复 N 次现在用 /goal：
bash
/goal test/auth 下所有测试通过，lint 检查无报错敲完回车，Claude 开始干活。每一轮结束后，一个独立的评估模型（默认用 Haiku）会检查你设的条件是否满足。没满足就自动开下一轮，满足了就停下来通知你。你不用管，去喝杯咖啡回来看结果就行。
它和 /loop 有什么区别
这是我一开始搞混的地方。Claude Code 有三种"自动继续"的机制：
| 方式 | 下一轮触发条件 | 什么时候停 |
|---|---|---|
/goal |
上一轮结束后立刻 | 独立模型确认条件满足 |
/loop |
设定的时间间隔到了 | 你手动停止，或 Claude 判断做完了 |
| Stop hook | 上一轮结束后立刻 | 你自定义的脚本或 prompt 判断 |
简单说：/goal 是"干到条件满足"，/loop 是"每隔 N 秒干一次"，Stop hook 是"用你自己的逻辑判断要不要停"。
大多数开发场景用 /goal 最自然------你知道终点是什么（测试通过、构建成功、文件改完），让它自己跑到终点就行。
怎么写好一个 goal 条件
这里有个关键细节：评估模型只看对话记录里 Claude 产出的内容来判断条件是否满足，它不会自己去跑命令或读文件。所以条件必须写成 Claude 的输出能证明的形式。
好的条件：
bash
/goal npm test 退出码为 0，且 tsc --noEmit 无报错这能行，因为 Claude 会自己跑 npm test，测试结果会出现在对话记录里，评估模型看得到。
不太好的条件：
bash
/goal 代码质量提升这太模糊了，评估模型没法判断什么时候算"提升"了。
写条件有三个要点：
- 一个可量化的终态：测试通过、构建成功、文件数量达标、队列清空
- 明确的验证方式 ："
npm test退出码 0"比"测试通过"更精确 - 必要的约束：如果你不想让它改其他文件，写明"不修改 src/core/ 下的文件"
条件最长支持 4000 字符，足够写得很细了。
还有一个实用技巧：在条件里加转数限制。比如：
bash
/goal 所有 lint 警告清零，如果 20 轮还没搞定就停下来这样不会出现 Claude 死循环改来改去的情况。
实际用下来的几个场景
场景一：批量迁移 API 调用
我有个项目要把旧的 fetch 调用全换成封装好的 apiClient，涉及二十多个文件。以前得一个文件一个文件地让它改，现在：
scss
/goal 项目中不再有直接的 fetch() 调用（apiClient 内部除外），tsc --noEmit 通过它自己找文件、改代码、跑类型检查、发现问题再修，大概跑了十几轮，全程不需要我介入。
场景二：修复测试套件
bash
/goal pytest tests/integration/ 全部通过，不跳过任何用例Claude 跑测试、看失败原因、改代码、再跑，循环到全绿。比我手动一个个修快多了。
场景三：非交互模式
/goal 还能在命令行直接用：
bash
claude -p "/goal CHANGELOG.md 包含本周所有合并的 PR 的条目"适合放在 CI 里或者写脚本调用。
状态查看和中途退出
跑着的时候终端会显示 ◎ /goal active 和已经花了多少时间。想看详细状态：
bash
/goal不带参数直接回车，会显示当前条件、已跑轮数、token 消耗、评估模型最近一次的判断理由。
想中途停：
arduino
/goal clearstop、off、reset、cancel 这几个词也行，都是停止的意思。
Agent View：一个屏幕管所有后台任务
问题场景
/goal 解决了"一个任务自动跑到底"的问题。但做项目的时候，经常是同时有好几件事要处理：修个 bug、写个新接口、review 一个 PR、跑一组测试。以前只能开好几个终端窗口，来回切换看每个会话的进度。
Agent View 把所有会话收到一个面板里。运行 claude agents，打开一个全屏的管理界面，每个任务是一行，状态一目了然。
基本用法
bash
claude agents打开后底部有一个输入框，直接输入任务描述然后回车，就会启动一个后台会话去干这件事。比如：
bash
调查 tests/checkout.spec.ts 为什么间歇性失败回车，任务出现在列表里，状态是"Working"。再输入另一个任务：
bash
给 PR #2048 加上缺失的单元测试又一个任务出现。两个并行跑着，互不干扰。
会话状态
每一行前面有个图标，表示状态：
| 状态 | 含义 |
|---|---|
| 旋转动画 | 正在工作 |
| 黄色 | 等你回答问题或授权 |
| 灰色 | 空闲，等你下一步指令 |
| 绿色 | 任务完成 |
| 红色 | 出错了 |
列表按状态分组，需要你介入的排在最上面。不用一个个翻，哪个卡住了一眼就知道。
三个核心操作
Peek（快速查看）：选中一行按空格，弹出预览面板，显示这个会话最新的输出或者它在问什么问题。大多数时候看一眼就够了，不用进入完整会话。在预览面板里可以直接输入回复。
Attach（接管）：按回车或右箭头进入完整会话，就跟正常用 Claude Code 一样，所有命令和快捷键都能用。
Detach（放回后台）：在空 prompt 上按左箭头，会话回到后台继续跑，你回到管理面板。
这三个操作形成了一个很顺畅的循环：在面板里扫一眼所有任务状态 → 哪个需要关注就 peek 看看 → 需要深入就 attach 进去 → 处理完 detach 回来。
文件隔离机制
一个很重要的设计：每个后台会话在编辑文件之前，会自动创建一个独立的 git worktree。这意味着多个会话可以同时改同一个仓库的文件而不冲突。会话 A 在改 src/auth.ts，会话 B 也可以在改 src/auth.ts，各自在自己的 worktree 里操作，互不影响。
改完之后，merge 或者 push 对应 worktree 的改动就行。删除会话时 worktree 也会被清理，所以记得在删除之前把想保留的改动提交或推送。
从命令行管理
不想打开面板也行，直接用命令行管理：
bash
# 启动一个后台任务
claude --bg "调查 flaky 测试的根因"
# 查看某个会话的最近输出
claude logs 7c5dcf5d
# 接管某个会话
claude attach 7c5dcf5d
# 停止某个会话
claude stop 7c5dcf5d
# 重启所有停止的会话（比如电脑休眠恢复后）
claude respawn --all把现有会话送到后台
正在跑的会话也可以送到后台。在会话里输入：
bash
/bg或者带一个额外指令：
bash
/bg 跑完测试套件然后修所有失败的用例会话会转入后台继续运行，你回到管理面板。
/goal + Agent View 组合使用
这两个功能组合起来才是真正的生产力飞跃。我现在的工作流变成了这样：
- 打开
claude agents - 派发第一个任务：
修复 auth 模块的类型错误，tsc --noEmit 通过后停 - 派发第二个任务：
把 utils/format.ts 的函数全加上单元测试，覆盖率到 90% 后停 - 派发第三个任务：
review PR #315 的改动，列出所有潜在问题 - 去做别的事，偶尔切回来瞟一眼面板
每个任务各自带着 goal 条件在后台跑，完成了自动变绿。如果哪个遇到问题需要我决策，状态变黄，我 peek 看一下问题，回复一下，它继续跑。
一个上午能推进的工作量，比以前一个个盯着跑，提升非常明显。
几个注意事项
Rate limit：后台会话消耗的配额和前台一样。同时跑 10 个会话，配额消耗速度大约是 1 个的 10 倍。别贪多，根据你的 plan 限额来。
本地运行 ：后台会话跑在你本机，电脑休眠或关机会中断。恢复后用 claude respawn --all 重启。
版本要求 ：这两个功能需要 v2.1.139 或更新版本。跑 claude --version 检查一下，不够的话 claude update 更新。
Auto mode 搭配 ：/goal 管的是"什么时候停"，auto mode 管的是"每轮里的工具调用要不要你批准"。两个一起开，才是真正的全自动------不用批准工具调用，也不用手动触发下一轮。
说实话，用了这两个命令之后，以前那种一轮一轮手动推进的方式已经回不去了。AI 编码助手从"你说一句它做一步"变成了"你设个目标它自己跑完"，这才是正确的交互方式。