Claude Code 高效命令盘点：/goal 与 Agent View 实战
用Claude Code写代码时最折磨人的环节是什么？每次对话结束，终端就卡住等你敲“继续”。修复一个bug，来回五六轮是家常便饭，你得像守门员一样盯着屏幕，看他改完没，然后敲下回车。说实话，这种交互效率很低。
好在，v2.1.139版本引入的两个命令彻底打破了这种低效循环。/goal让你设定一个目标，然后放手让Claude自主执行到底；claude agents则开启一个多会话管理面板，让你像项目经理一样并行分发多个任务，哪个阻塞了，一目了然。以下是实测两天后的完整复盘。
/goal：设定完成条件，让它自主推进到底
最直观的理解
过去的工作流是这样的：
你：帮我把 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无疑最符合直觉——你知道终点是什么（测试通过、构建成功、文件改完），让它自己跑到终点就行。
如何写好一个 goal 条件
这里有个关键细节：评估模型只看对话记录里的输出内容来判断条件是否满足，它自己不会去跑命令或读文件。所以，条件必须写成Claude的输出能够证明的形式。
高效的条件：
/goal npm test 退出码为 0，且 tsc --noEmit 无报错这种写法可行，因为Claude会自己执行npm test，测试结果自然会呈现在对话记录里，评估模型能直接看到。
低效的条件：
/goal 代码质量提升这太模糊了。什么叫“提升”？评估模型无法判断。
总结一下，编写/goal条件需遵循三个要点：
- 一个可量化的终态：测试通过、构建成功、文件数量达标、队列清空等。
- 明确的验证方式：“
npm test退出码0”比“测试通过”更精确。 - 必要的约束：不想让它改动哪些文件，可以写清楚，比如“不修改src/core/下的文件”。
条件最长支持4000字符，足以让你写得足够细致。还有一个实用技巧：在条件里加个轮数限制，比如“所有lint警告清零，如果20轮还没搞定就停下来”，这样就能避免Claude陷入死循环反复修改的窘境。
实际用下来的几个场景
场景一：批量迁移API调用
我有个项目，需要把旧的fetch调用全部换成封装好的apiClient，涉及二十多个文件。以前得一个一个文件地让它改，现在只需要一个命令：
/goal 项目中不再有直接的 fetch() 调用（apiClient 内部除外），tsc --noEmit 通过它自动查找文件、修改代码、运行类型检查、发现问题再修复，大约跑了十几轮，全程无需我介入。
场景二：修复测试套件
/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、编写一个新接口、审核一个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编码助手从“你说一句，它做一步”变成了“你设个目标，它自己跑完”，这才是正确的交互方式。