使用Claude Code编写代码时，最常见的困扰是什么？往往是每次对话结束后，它都会暂停等待你手动点击“继续”。修复一个bug往往需要反复五六轮，你不得不像一台人肉“继续”按钮一样始终盯着终端，确认它修改完成后才能按下回车。坦白说，这种体验非常低效。
幸运的是，v2.1.139版本引入了两个全新命令，彻底终结了这种低效循环。/goal允许你设定一个目标后放手让Claude自主执行到底；而claude agents则开启一个多会话管理面板，让你像项目经理一样同时分配多个任务，任何卡顿都能一眼识别。以下是我经过两天实际使用后的完整体验记录。
/goal：设定完成条件，让Claude自动执行到底
最直观的理解
过去的工作流是这样的：
你：帮我把 test/auth 下的测试全部修好
Claude：改了第一个文件（停下来等你）
你：继续
Claude：改了第二个文件（又停下来）
你：继续
...重复 N 次现在用/goal，你只需要敲一行命令：
/goal test/auth 下所有测试通过，lint 检查无报错回车后，Claude就开始工作了。每一轮结束后，一个独立的评估模型（默认用Haiku）会检查你设定的条件是否达成。未完成则自动启动下一轮，完成便停下来通知你。你完全无需干预，去冲杯咖啡，回来看结果即可。
它和 /loop 有什么区别
很多人会混淆，其实Claude Code有三种“自动继续”的机制，做个对比就清楚了：
| 方式 | 下一轮触发条件 | 什么时候停 |
|---|---|---|
/goal | 上一轮结束后立即触发 | 独立模型确认条件满足 |
/loop | 设定的时间间隔到达 | 你手动停止，或Claude判断完成 |
| Stop hook | 上一轮结束后立即触发 | 你自定义的脚本或prompt判断 |
简单说，/goal是“持续工作直到条件满足”，/loop是“每隔N秒尝试一次”，而Stop hook则是“用你自己的逻辑判断何时停止”。对于大多数开发场景，/goal无疑最自然——你知道终点（测试通过、构建成功、文件改完），让Claude自己跑到终点即可。
如何写好一个 goal 条件
这里有一个关键细节：评估模型仅根据对话记录中的输出内容来判断条件是否满足，它不会自行运行命令或读取文件。因此，条件必须写成Claude的输出能够证明的形式。
好的条件：
/goal npm test 退出码为 0，且 tsc --noEmit 无报错这种写法可行，因为Claude会自主运行npm test，测试结果自然出现在对话记录中，评估模型能够读取到。
不太好的条件：
/goal 代码质量提升这就太模糊了。什么叫“提升”？评估模型无法判断。
总结一下，撰写/goal条件需注意三个要点：
- 一个可量化的终态：测试通过、构建成功、文件数量达标、队列清空等。
- 明确的验证方式：“
npm test退出码0”比“测试通过”更精确。 - 必要的约束：不想让Claude改动的文件，可以写明，比如“不修改src/core/下的文件”。
条件最长支持4000字符，足够你写得详尽。还有一个实用技巧：在条件里加个轮数限制，例如“所有lint警告清零，如果20轮还没搞定就停下来”，这样能避免Claude陷入死循环反复修改的窘境。
实际用下来的几个场景
场景一：批量迁移API调用
我有个项目，需要把旧的fetch调用全部换成封装好的apiClient，涉及二十多个文件。以前需要逐个文件让Claude修改，现在只需一条命令：
/goal 项目中不再有直接的 fetch() 调用（apiClient 内部除外），tsc --noEmit 通过Claude会自动查找文件、修改代码、运行类型检查、发现问题再修复，大约跑了十几轮，全程无需我介入。
场景二：修复测试套件
/goal pytest tests/integration/ 全部通过，不跳过任何用例Claude运行测试、分析失败原因、修改代码、再次运行，循环直到全部变绿。这比我手动一个个修复快太多了。
场景三：非交互模式
/goal还能直接在命令行使用，非常适合放入CI或编写脚本调用：
claude -p "/goal CHANGELOG.md 包含本周所有合并的 PR 的条目"状态查看与中途退出
任务运行时，终端会显示◎ /goal active和已用时间。想查看详细状态，直接输入/goal（不带参数）回车，就会显示当前条件、已运行轮数、token消耗以及评估模型最近的判断理由。想中途停止，输入/goal clear或者stop、off、reset、cancel等命令即可。
Agent View：一个屏幕管理所有后台任务
问题场景
/goal解决了“一个任务自动跑到底”的问题，然而做项目时，常常需要同时处理好几件事：修个bug、写个新接口、review一个PR、跑一组测试。以前只能开多个终端窗口，来回切换，观察每个会话的进度。
Agent View正是为此设计。运行claude agents，就打开了一个全屏管理界面，每个任务一行，状态一目了然。
基本用法
claude agents打开后，底部有一个输入框，直接输入任务描述，然后回车，就会启动一个后台会话去执行。例如：
调查 tests/checkout.spec.ts 为什么间歇性失败回车，任务出现在列表里，状态为“Working”。你可以再输入另一个任务：
给 PR #2048 加上缺失的单元测试又一个任务出现，两者并行运行，互不干扰。
会话状态
每一行前面都有一个图标，表示当前状态：
| 状态 | 含义 |
|---|---|
| 旋转动画 | 正在工作 |
| 黄色 | 等待你回答问题或授权 |
| 灰色 | 空闲，等待下一步指令 |
| 绿色 | 任务完成 |
| 红色 | 出错了 |
列表按状态分组，需要你介入的会排在最上面。哪个卡住了，一眼就能看到，不用逐个翻找。
三个核心操作
Peek（快速查看）：选中一行按空格，会弹出一个预览面板，显示该会话的最新输出或它正在问的问题。大多数情况下，看一眼就够了，无需进入完整会话。在预览面板中可以直接输入回复。
Attach（接管）：按回车或右箭头键，进入完整会话，所有命令和快捷键都能正常使用。
Detach（放回后台）：在空prompt上按左箭头，会话回到后台继续运行，你返回管理面板。
这三个操作形成了一个非常顺畅的循环：在面板中扫一眼所有任务状态 → 哪个需要关注就Peek查看 → 需要深入就Attach进入 → 处理完就Detach返回。
文件隔离机制
一个很重要的设计：每个后台会话在编辑文件之前，会自动创建一个独立的git worktree。这意味着多个会话可以同时修改同一个仓库的不同文件而不产生冲突。会话A在改src/auth.ts，会话B也可以在改src/auth.ts，各自在自己的worktree里操作，互不影响。
改完之后，merge或push对应worktree的改动即可。删除会话时，worktree也会被清理，所以记得在删除之前，把想保留的改动提交或推送。
从命令行管理
不想打开面板的话，也可以直接用命令行管理：
# 启动一个后台任务
claude --bg "调查 flaky 测试的根因"
# 查看某个会话的最近输出
claude logs 7c5dcf5d
# 接管某个会话
claude attach 7c5dcf5d
# 停止某个会话
claude stop 7c5dcf5d
# 重启所有停止的会话（比如电脑休眠恢复后）
claude respawn --all把现有会话送到后台
正在运行的会话也可以随时送到后台。在会话里输入/bg即可。也可以附带一个额外指令：
/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编码助手从“你说一句，它做一步”变成了“你设个目标，它自己跑完”，这才是正确的交互方式。
