Skip to main content

ClaudeCode 怎么让 AI 自动跑完全流程？

· 7 min read

ClaudeCode 进阶命令 6 件套,把"人在回路内"升级成"人在回路外"。

  1. 痛点：Vibe Coding 卡在"敲回车",AI 走一步你推一步
  2. 核心枢纽 /goal：把"下一步"换成"终点",AI 自判自跑
  3. /loop + /batch：派 AI 等长任务、拆 sub-agent 并行处理
  4. /simplify：commit 前的最后一道美容,改风格、不做 bug 检查
  5. /doctor + /debug：AI 给自己看病,前者查环境、后者查行为
  6. 真价值：把人类角色从操作员升级为产品经理

痛点：为什么 Vibe Coding 卡住了​

Vibe Coding 用久了,有一种疲倦感——不是 AI 不够强,是交互模式有问题。

你让 Claude 改一段代码,改完了你补一句"再精简点";它精简完,你又补一句"逻辑再通顺点"。一来一回,AI 确实在往前走,但 没有任何一步是你真正想做的事情——你全程在做的就是"按回车 + 微调方向",一个小时的产出可能还不如 10 分钟的明确指令。

问题出在哪？你把自己定位成了 操作员,而不是 产品经理。

操作员要管每一步,产品经理只管终点。AI 越强,操作员越累——你的反应速度跟不上它的迭代速度,瓶颈不在模型,在你自己。

那 6 个进阶命令 (goal/loop/batch/simplify/doctor/debug) 真正要解的就是这个问题:把"人在回路内"改成"人在回路外"。

一、/goal:核心枢纽​

/goal 是这组命令的枢纽。

它解决的核心痛点是：AI 每走一步都在等你推一下。

/goal 的思想很简单——你不再告诉 AI "下一步做什么",而是直接告诉它 终点在哪。

你给它一个明确、可验证的完成条件,Claude 不会完成一小步就停下来等你。它每轮自我迭代后自己判断目标是否达成,没达成就分析原因、继续改、继续测,直到任务完成。

怎么写一个好目标？​

目标不是描述,是 验收标准。

❌ /goal 修好那个登录页的 bug

✅ /goal 修复登录页面的功能。
   任务完成的唯一标准是:
   在终端里运行 npm run test:auth 这个测试命令。
   该命令必须成功退出,并且退出码 (exit code) 为 0。
   在整个过程中,绝对不能修改除了 src/pages/LoginPage.js 之外的任何测试文件。
   当你确认测试通过后,请在对话中明确告诉我:"目标已达成,测试全部通过。"

四个要素缺一不可:

  • 终点明确:测试命令通过
  • 验证手段清晰:检查 exit code
  • 边界清晰:能碰和不能碰的文件
  • 汇报机制:明确的完成信号

写得太模糊就像对实习生说"去,把项目搞定"——他完全不知道"搞定"是什么样,Claude 也一样。

黄金组合:/clear + /goal + Auto Mode​

很多人有个误区,以为开了 Auto Mode AI 就会自己一路干到底。其实 Auto Mode 只负责"跳过向你请求授权的那一步",它本身不会触发下一轮。

真正能让你放心走开的黄金组合是:

  1. 先用 /clear 清空上下文,让 AI 轻装上阵、不受之前对话干扰
  2. 用 /goal 把 Spec 喂给它,定义终点和验收标准
  3. 最后开 Auto Mode,减少执行过程中的打扰

三步走完,你才真正可以放心离开。

二、/loop:派 AI 去等长任务​

/loop 的本质是把"人等结果"换成"AI 等结果"。

适合的场景是:你知道状态一定会变,但需要一些时间——等部署完成、等 CI 跑完、等长任务结束。

它非常适合在当前对话里轮询"慢悠悠"的任务,但有会话和时间的边界——关闭会话即终止,不能当成 7×24 监控系统。

更多细节见 ClaudeCode /loop 命令是什么？。

三、/batch:大任务必须先拆后跑​

大任务直接丢给 AI,基本都会懵——比如框架迁移、大规模重构。

/batch 就是专门对付这种场景的:

  1. 研究与计划:深度阅读代码库,把大任务拆成一堆相对独立的子任务
  2. 分派与执行:每个子任务启动一个独立的后台子代理 (subagent),在各自的沙盒环境 (Git Worktree) 里互不干扰地工作

/batch 的强大在于并行化和规模化,但它最危险的环节也在拆分——子任务之间存在隐性依赖或边界划分不清的话,后台代理们会互相打架,最后得到一堆互相冲突、难以合并的烂摊子。

所以使用 /batch 时,仔细审查它拆分出来的计划 比让它跑更重要。这步偷懒,后面全得还。

四、/simplify:commit 前的最后一道美容​

无论谁写的代码,功能完成后总会留下一些可以优化的空间。

/simplify 就扮演了"代码清理工"的角色——它不是用来写新功能的,而是让你在提交改动之前回头审视一下代码还有没有优化空间。

跑一次 /simplify,它会检查这几件事:

  • 能否复用:有没有现成的工具函数可以调用,避免重复造轮子
  • 能否简化:有没有更简洁、更直观的写法
  • 有无效率陷阱:有没有明显的性能问题
  • 抽象是否合理:这个函数放在这里是否合适
版本变化

在新版本的 Claude Code 中,/simplify 主要负责代码风格、结构和简化,不再做正确性检查。检查 bug 应该用 /code-review 命令。

所以 /simplify 的最佳定位是 git commit 之前的最后一道代码美容工作。配合 /code-review 一起用,前者管风格,后者管正确性。

五、/doctor + /debug:AI 给自己看病​

有时候出问题的不是你的代码,而是 Claude 本身——行为怪异、干脆跑不起来。

这时候别自己去翻日志,让 Claude 自己给自己看病:

  • /doctor:当 AI 完全跑不起来时跑它。它做一次全面的环境自检,尝试自动修复
  • /debug:当 AI 能跑但行为不符合预期时跑它。它为当前会话打开详细日志,自己阅读分析

简单判断法则:

  • 跑不起来 → /doctor 查环境
  • 能跑但行为怪 → /debug 诊会话

这 6 个命令的真正价值​

回头看这 6 个命令,你会发现它们不是平行的 6 个开关,是一条完整的自动化流水线:

每一个命令解决一个具体环节:

  • /goal 解决"目标定义"
  • /loop 解决"状态等待"
  • /batch 解决"规模分解"
  • /simplify 解决"代码质量"
  • /debug /doctor 解决"异常恢复"

它们组合起来的真正价值,是 把人类角色从"操作员"升级为"产品经理"——你不再亲自指挥每一步,而是定义目标和验收标准。

Vibe Coding 卡住的根本原因不是模型不够强,而是人类还停留在"逐句确认"的旧模式里。接受这套工作流的关键,不是学会 6 个命令,是 接受"我只关心终点,过程让 AI 自己跑"的心态转变。

References​