大多数人用 Claude Code，是「交一件、等一件」：说一句，等它做完，看一眼，再说下一句。做得挺顺，但你几乎全程走不开——得守着它，怕它理解偏了，或者做到一半停下来等你。

这篇文章想聊的是：那些需要你「守着」的活，其实大多可以交给它自主干——它自己判断对错、自己一步步往下做，你只在开头和结尾出现。省下来的不是它的时间，是你盯着它的那段时间。

先说清楚一件事：自主 ≠ 让它多写代码、多烧算力。 用对方法，总账往往更划算——省的是你来回确认、反复返工的时间；算力这笔账，后面会单独算给你看。下面从「为什么你总得盯着」讲起，一步步到「怎么放手」。

一、你为什么总得盯着它？

盯着，本质上是因为两件事你不放心：

1. 它不知道自己做得对不对。 写完一段代码，它说「已完成」，但到底跑没跑通？你不看一眼不放心。
2. 它记不住上一步。 对话一长、或者换个窗口重开，它就「失忆」了，可能推翻之前的结论、重复劳动。

想让它自己转起来，就得把这两件事解决掉。方法其实特别朴素：

• 给它一个「它自己能跑的检查」。 比如一条测试命令、一次编译、一段能核对源码的搜索。有了这个，它做完能自己验证「对没对」，而不是嘴上说「应该没问题」。这是「你得盯着的活」和「你能走开的活」之间最关键的那道分界线。
• 让它把状态写进文件。 进度、决策、待办，都落到文件里而不是只存在对话里。这样哪怕换个会话重开，它读一下文件就能接着干。

记住一句话就够了：能不能放手，不取决于模型多努力，取决于这件事被你设计成了什么样。 在提示词里喊「请一定坚持完成、不要中途放弃」是没用的；把上面两件事安排好，它自然就能自己跑。

另外，开头说的「怕它理解偏了」也有现成解法：动手前打开 plan mode（计划模式）——它先只读代码、不改任何东西，把打算怎么干写成方案给你过目，你批准了它才动手。方向先对齐，再谈放手。这个习惯最简单、也最该先养成，后面的速查表里还会见到它。

下面介绍两个最值得先掌握的能力，就是照这个思路造出来的现成工具。

二、第一步：用 /goal 让它自己判断「做完没」

/goal 是最低成本的自主能力，一句话就能上手。

它是什么？ 你给它一个「完成条件」，它会一轮接一轮地干，直到条件真正满足才停——中间不用你隔一会儿催一句「继续」。

一个好的完成条件有三个要素：① 一个能测的终态（「所有测试通过」）；② 凭什么算数（「以运行测试的输出为准」）；③ 中途别碰什么（「不许改其他文件」）。

一个实用的用法是**「一轮轮推进 + 划好边界」**：与其让它一口气把大活全做完，不如先让它把整件事拆成若干轮、写进一个 progress 文件，之后每轮只给一个够得着的小目标。比如给某个项目补一整套设计文档（spec），可以这么交代：

/goal 完成 spec 初始化的第 3 轮
执行前先读 progress 文件、按里面的进度接着干，做完更新 progress；
边界：① 只做这一轮，不许提前推进后面几轮；② 新文档只能写在指定目录。

就这么从「第 0 轮」一路推到「第 9 轮」，每轮交代完就走开。这条件里正好齐了三要素：终态（这一轮做完）、凭什么算数（以指定目录里出现本轮文档、progress 被更新为准）、别碰什么（锁死目录）。质量收敛的活也一样，比如「审一遍工程的设计文档，看覆盖度和质量，不断打磨到达标」。这套玩法不止对研发成立——产品同学把「文档」换成「需求里的验收点」，一样能用。

顺带一个容易踩的坑：完成条件要「够得着」。 如果把停止条件写成「全部阶段完成」这种远期目标，往往第一阶段刚开头它就反复想收工、又被赶回去接着跑，白白空转——因为每轮收工时，都有个独立的小模型「裁判」拿这个大条件来对，够不着就不放行。所以别把终点定太远，拆成「一轮能达成」的小目标，条件写成「这轮产出能证明的样子」，它才停得下、你也才敢放手。

一句实话：/goal 适合一个会话里就能收敛的中型任务（大概两小时以内的量）。任务再大、需要跨越好几个工作阶段的，它就不够用了——那是下一个工具的主场。别指望它包打天下，但作为「从盯着到走开」的第一步，它足够好用。

小提示：/goal 需要较新版本的 Claude Code（claude --version 看一下），用之前 /help 确认一下可用。

三、主力武器：Dynamic Workflows（动态工作流）——让它「分兵 + 互相挑错」

如果说 /goal 是让一个人把活干完，那 Dynamic Workflows（动态工作流，官方术语） 就是让 Claude Code 自己当包工头，喊一群工人分头干、还互相质检。这是从「一个人埋头干」到「一支队伍协同干」的关键一步。

它解决什么问题？ 有些活，一个人的「脑容量」根本装不下——比如审计整个工程、给几十个文件逐一补测试、把一堆设计文档跟源码逐条对账。硬塞给一个会话，它做到一半「脑子」就满了（上下文爆掉），开始丢三落四。

动态工作流的做法是：把大活拆成几十个小活，派给几十个子 agent（subagent）并行去干，每个子 agent 有自己独立的「脑容量」，主对话只收最终结论。 于是上下文不会爆，几十件事同时推进，而你——什么都不用盯。

怎么用？ 你不用自己写脚本。只要在需求前面加一句 ultracode，或者直接说「用 workflow 跑」，Claude Code 就会自己把编排逻辑写成一段程序、在后台跑起来，同时你的窗口还能继续对话。跑的过程用 /workflows 能随时看。

真正的杀手锏，是它能自己质检自己。

这才是「自主」最值钱的地方。举一个真实案例：

案例一：给一批设计文档做「事实核查」
某项目有十几份设计文档是早期用 AI 生成的，没人逐条核对过，积累了不少「看起来合理但其实不对」的错误——编造的方法名、写反的枚举值、不存在的接口路径。人工逐条核太慢，于是把它整成一条六道工序的流水线，一句话交给动态工作流跑：
1.三路并行初查：三个子 agent 同时上——一路拿文档去比源码，一路反过来查源码里有没有文档漏记的，一路专找文档之间自相矛盾的地方。三个视角互不打架，尽量把疑点捞全。
2.对抗复核（关键工序）：对初查捞出的每一条疑点，再派一个独立的「怀疑者」agent。它不信上一步给的证据，自己重新钻进源码查一遍，只留下真站得住的。这一轮并行派出了 28 个怀疑者，结果 27 条确认属实、1 条被推翻（上一步的误报，误报率 3.6%）。
3.汇总去重：把确认的 27 条合并成一份干净清单，每条标好「哪个文件第几行、错在哪、正确的是什么、证据在哪」。
4.修复计划 + 双签：一个 agent 出修复方案，另一个独立 agent 逐条审——这条改动有没有证据撑腰、会不会改出新错、会不会又把删掉的细节塞回来。两签都过才准动手。
5.分文件执行 + 自检：每份文档派一个 agent 去改，改完自己检查（格式没坏、改动精确没误伤、新写的断言能被 grep 验证）。
6.交叉回归验证：最要命的一道——A 改过的文件交给 B 复验，而且 B 不知道修复计划长什么样，纯拿源码重新核一遍。就是这一步，揪出某份文档还有 2 处问题——一处漏改、一处是修复环节自己改错的，回头补上。

请注意第 6 步：它自己发现了自己的疏漏，并且改掉了。 整条流水线从头到尾没让人插手，最后交回来的是一份「已经被另一拨 agent 挑过刺」的结果。这就是为什么「对抗验证」值得你记住——让「找茬的」和「拍板的」是不同的 agent，谁也别信谁，结论才靠得住。一个人既当运动员又当裁判，往往会「发现问题、然后说服自己这问题不大」，就放过去了；两拨人互相较劲，才不会自欺。

一句成本上的实话：动态工作流一次开几十个 agent，比在对话里手动做同一件事要贵。所以先在小范围试跑（比如先跑一个目录、别一上来就整个工程），确认效果和花销都合适，再放量。它省的是你的时间，不是让你无脑烧算力——这个账要算清楚。

顺带认识一下「子 agent（subagent）」。 上面反复出现的「派一个 agent 去干」，那个被派出去的独立小助手就是 subagent——它有自己独立的「脑容量」，干完只把结论交回主对话，过程中的一大堆中间信息不会挤占你这边的上下文。动态工作流本质上就是「一次调度几十个 subagent」，而单独用一个 subagent 也很常见：让它去探索一片陌生代码、跑一遍评审、查一个你懒得自己翻的问题，你的主对话干干净净只等答案。

更省心的是，这件事你常常不用开口，它自己就会做。实际用下来，Claude Code 会在合适的时候主动分身——比如你让它理解一个大项目，它自己就派出几十次「只读探索」的 subagent 去分头翻代码，而不是把整个工程一股脑塞进当前对话把自己噎住。你要做的，只是知道有这么个机制，看到它「分身」时不必慌——那正是它在替你省上下文。

小提示：动态工作流对 Claude Code 版本的要求比 /goal 还要新（v2.1.154 及以上），用之前同样先 claude --version 看一眼。

四、再看两个真实案例

不是只有事实核查能这么玩。下面两个也来自真实项目，同样是「一句话交出去、它自主干完」：

第一个案例里最值钱的，是被否决的那 10 条——它没有一股脑把「疑似问题」全塞给你，而是自己先筛掉了噪音（比如一条「路由膨胀 40%」的判断，重新读代码后发现不成立，就自己撤回了）。这正是自主性的意义：替你把关，而不是把一堆半成品甩给你。

第二个案例里注意那句「红了先别修、把问题列到文件里」。这叫有边界的自主——你不是把方向盘完全撒手，而是明确告诉它「哪些自己做、哪些留给我」。它照做了，既没擅自乱改，也没停下来反复问你。好的自主，是你划好边界之后的放手，不是完全不管。

五、先泼盆冷水：不是所有活都适合这么干

上面几个案例很漂亮，但别急着套到手头每一件事上。自主长任务能跑得动，是有前提的——不满足这些前提硬上，大概率是白烧 token。三条最要紧的：

前提一：项目得有一套像样的「事实地基」。 你注意到没有，前面所有案例——事实核查、过度设计审查、补测试——脚下都踩着一套设计文档（spec）或清晰的代码结构。这不是巧合。让它自主跑，本质是让它「拿着一份可信的参照物，一轮轮比对、修正」。（案例一那批文档本身不就错漏百出吗？没错——那一仗的参照物是源码，流水线干的正是「把这块地基修扎实」的活。）参照物越完备，它越能自己判断对错、自己收敛；参照物是空的，它就只能一路猜，越跑越飘。越是复杂的项目，越要先把 spec 体系搭起来，长任务才有立足点。

前提二：vibe coding（凭感觉边聊边写）出来的项目，先别想着上长任务。 这类项目往往没沉淀下清晰的结构和文档，全靠当时对话里的默契。你让它自主跑一个大目标，它没有可靠的参照物，只能顺着感觉往下堆，很容易越跑越歪——这种情况下开长任务，多半是纯粹浪费 token。正确的顺序是：先花力气把结构和 spec 补扎实，再谈自主。

前提三：任务本身得「适合」。 边界清楚、有客观对错、能拆成一轮轮推进的活（审计、核查、补测试、批量改造）最合适；反过来，那种高度依赖你临场拍板、审美偏好、或者对错没有客观标准的活，就别硬交给它自跑——那种活，你在场反而更快。

一句话收口：自主能力是「放大器」，不是「无中生有」的魔法。 项目底子好、任务选得对，它能帮你放大十倍；底子虚、任务选错，它只会把混乱也放大十倍，账单还照收。

六、能力速查：先掌握三个就够

Claude Code 的自主能力不止上面两个，下面这张表列全，方便你以后按需查。但别想着一次全用上——真正的核心就是加粗的那三个，其余是进阶，用到了再看。

给刚上手的你：先学会 /goal 和 plan mode 这两个最简单的，再上动态工作流。这三个吃透，日常八成的场景都够了。

上一节说的是「大活要选对、项目要有底子」；这里再补另一头：琐碎小事也别硬套这一整套。 改个错别字、调一行代码，直接让它做就好。自主能力是为「大到你不想盯」的活准备的，不是每件小事都要摆开阵仗——大活选错和小事摆阵仗，都是浪费。

七、循序渐进：从半小时到过夜

不用一步到位。按这个阶梯来，每一级用顺手了、开始信任它的自查报告了，再上下一级：

最后一条底线，务必记住：无论多自主，不可逆的危险操作永远要你亲自确认——强制推送、删库删数据、改生产配置、对外发消息。这类动作提前圈出来，绝不让它自作主张。放手是为了提效，不是为了替你闯祸。

写在最后

回到开头那句：别再一句一句地喂它、然后守着屏幕。真正的用法是——把一件事想清楚、划好边界、给它一个能自我验证的目标，然后交出去。

你会发现，省下来的时间不是一点半点。而这，才是把 AI 用成生产力的样子：把重复的判断和执行还给机器，把真正需要你的判断留给自己。