大多数人用 Claude Code是「交一件、等一件」说一句等它做完看一眼再说下一句。做得挺顺但你几乎全程走不开——得守着它怕它理解偏了或者做到一半停下来等你。这篇文章想聊的是那些需要你「守着」的活其实大多可以交给它自主干——它自己判断对错、自己一步步往下做你只在开头和结尾出现。省下来的不是它的时间是你盯着它的那段时间。先说清楚一件事自主 ≠ 让它多写代码、多烧算力。用对方法总账往往更划算——省的是你来回确认、反复返工的时间算力这笔账后面会单独算给你看。下面从「为什么你总得盯着」讲起一步步到「怎么放手」。一、你为什么总得盯着它盯着本质上是因为两件事你不放心它不知道自己做得对不对。写完一段代码它说「已完成」但到底跑没跑通你不看一眼不放心。它记不住上一步。对话一长、或者换个窗口重开它就「失忆」了可能推翻之前的结论、重复劳动。想让它自己转起来就得把这两件事解决掉。方法其实特别朴素给它一个「它自己能跑的检查」。比如一条测试命令、一次编译、一段能核对源码的搜索。有了这个它做完能自己验证「对没对」而不是嘴上说「应该没问题」。这是「你得盯着的活」和「你能走开的活」之间最关键的那道分界线。让它把状态写进文件。进度、决策、待办都落到文件里而不是只存在对话里。这样哪怕换个会话重开它读一下文件就能接着干。记住一句话就够了能不能放手不取决于模型多努力取决于这件事被你设计成了什么样。在提示词里喊「请一定坚持完成、不要中途放弃」是没用的把上面两件事安排好它自然就能自己跑。另外开头说的「怕它理解偏了」也有现成解法动手前打开plan mode计划模式——它先只读代码、不改任何东西把打算怎么干写成方案给你过目你批准了它才动手。方向先对齐再谈放手。这个习惯最简单、也最该先养成后面的速查表里还会见到它。下面介绍两个最值得先掌握的能力就是照这个思路造出来的现成工具。二、第一步用/goal让它自己判断「做完没」/goal是最低成本的自主能力一句话就能上手。它是什么你给它一个「完成条件」它会一轮接一轮地干直到条件真正满足才停——中间不用你隔一会儿催一句「继续」。一个好的完成条件有三个要素① 一个能测的终态「所有测试通过」②凭什么算数「以运行测试的输出为准」③中途别碰什么「不许改其他文件」。一个实用的用法是**「一轮轮推进 划好边界」**与其让它一口气把大活全做完不如先让它把整件事拆成若干轮、写进一个 progress 文件之后每轮只给一个够得着的小目标。比如给某个项目补一整套设计文档spec可以这么交代/goal 完成 spec 初始化的第 3 轮 执行前先读 progress 文件、按里面的进度接着干做完更新 progress 边界① 只做这一轮不许提前推进后面几轮② 新文档只能写在指定目录。就这么从「第 0 轮」一路推到「第 9 轮」每轮交代完就走开。这条件里正好齐了三要素终态这一轮做完、凭什么算数以指定目录里出现本轮文档、progress 被更新为准、别碰什么锁死目录。质量收敛的活也一样比如「审一遍工程的设计文档看覆盖度和质量不断打磨到达标」。这套玩法不止对研发成立——产品同学把「文档」换成「需求里的验收点」一样能用。顺带一个容易踩的坑完成条件要「够得着」。如果把停止条件写成「全部阶段完成」这种远期目标往往第一阶段刚开头它就反复想收工、又被赶回去接着跑白白空转——因为每轮收工时都有个独立的小模型「裁判」拿这个大条件来对够不着就不放行。所以别把终点定太远拆成「一轮能达成」的小目标条件写成「这轮产出能证明的样子」它才停得下、你也才敢放手。一句实话/goal适合一个会话里就能收敛的中型任务大概两小时以内的量。任务再大、需要跨越好几个工作阶段的它就不够用了——那是下一个工具的主场。别指望它包打天下但作为「从盯着到走开」的第一步它足够好用。小提示/goal需要较新版本的 Claude Codeclaude --version看一下用之前/help确认一下可用。三、主力武器Dynamic Workflows动态工作流——让它「分兵 互相挑错」如果说/goal是让一个人把活干完那Dynamic Workflows动态工作流官方术语就是让 Claude Code自己当包工头喊一群工人分头干、还互相质检。这是从「一个人埋头干」到「一支队伍协同干」的关键一步。它解决什么问题有些活一个人的「脑容量」根本装不下——比如审计整个工程、给几十个文件逐一补测试、把一堆设计文档跟源码逐条对账。硬塞给一个会话它做到一半「脑子」就满了上下文爆掉开始丢三落四。动态工作流的做法是把大活拆成几十个小活派给几十个子 agentsubagent并行去干每个子 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比在对话里手动做同一件事要贵。所以先在小范围试跑比如先跑一个目录、别一上来就整个工程确认效果和花销都合适再放量。它省的是你的时间不是让你无脑烧算力——这个账要算清楚。顺带认识一下「子 agentsubagent」。上面反复出现的「派一个 agent 去干」那个被派出去的独立小助手就是 subagent——它有自己独立的「脑容量」干完只把结论交回主对话过程中的一大堆中间信息不会挤占你这边的上下文。动态工作流本质上就是「一次调度几十个 subagent」而单独用一个 subagent 也很常见让它去探索一片陌生代码、跑一遍评审、查一个你懒得自己翻的问题你的主对话干干净净只等答案。更省心的是这件事你常常不用开口它自己就会做。实际用下来Claude Code 会在合适的时候主动分身——比如你让它理解一个大项目它自己就派出几十次「只读探索」的 subagent 去分头翻代码而不是把整个工程一股脑塞进当前对话把自己噎住。你要做的只是知道有这么个机制看到它「分身」时不必慌——那正是它在替你省上下文。小提示动态工作流对 Claude Code 版本的要求比/goal还要新v2.1.154 及以上用之前同样先claude --version看一眼。四、再看两个真实案例不是只有事实核查能这么玩。下面两个也来自真实项目同样是「一句话交出去、它自主干完」场景怎么交代的它自己干成了什么审查整个工程有没有「过度设计」用动态工作流多个维度并行看用对抗模式互相质疑26 条发现里自己否决了 10 条站不住脚的确认的 16 条里包括一个 231 行、全工程零引用的死代码类给一个模块全面补单元测试一句「用动态工作流全面补全单测红了先别修、把问题列到文件里」一条指令产出23 个测试文件、约 250 个用例测试文件从 62 个涨到 85 个第一个案例里最值钱的是被否决的那 10 条——它没有一股脑把「疑似问题」全塞给你而是自己先筛掉了噪音比如一条「路由膨胀 40%」的判断重新读代码后发现不成立就自己撤回了。这正是自主性的意义替你把关而不是把一堆半成品甩给你。第二个案例里注意那句「红了先别修、把问题列到文件里」。这叫有边界的自主——你不是把方向盘完全撒手而是明确告诉它「哪些自己做、哪些留给我」。它照做了既没擅自乱改也没停下来反复问你。好的自主是你划好边界之后的放手不是完全不管。五、先泼盆冷水不是所有活都适合这么干上面几个案例很漂亮但别急着套到手头每一件事上。自主长任务能跑得动是有前提的——不满足这些前提硬上大概率是白烧 token。三条最要紧的前提一项目得有一套像样的「事实地基」。你注意到没有前面所有案例——事实核查、过度设计审查、补测试——脚下都踩着一套设计文档spec或清晰的代码结构。这不是巧合。让它自主跑本质是让它「拿着一份可信的参照物一轮轮比对、修正」。案例一那批文档本身不就错漏百出吗没错——那一仗的参照物是源码流水线干的正是「把这块地基修扎实」的活。参照物越完备它越能自己判断对错、自己收敛参照物是空的它就只能一路猜越跑越飘。越是复杂的项目越要先把 spec 体系搭起来长任务才有立足点。前提二vibe coding凭感觉边聊边写出来的项目先别想着上长任务。这类项目往往没沉淀下清晰的结构和文档全靠当时对话里的默契。你让它自主跑一个大目标它没有可靠的参照物只能顺着感觉往下堆很容易越跑越歪——这种情况下开长任务多半是纯粹浪费 token。正确的顺序是先花力气把结构和 spec 补扎实再谈自主。前提三任务本身得「适合」。边界清楚、有客观对错、能拆成一轮轮推进的活审计、核查、补测试、批量改造最合适反过来那种高度依赖你临场拍板、审美偏好、或者对错没有客观标准的活就别硬交给它自跑——那种活你在场反而更快。一句话收口自主能力是「放大器」不是「无中生有」的魔法。项目底子好、任务选得对它能帮你放大十倍底子虚、任务选错它只会把混乱也放大十倍账单还照收。六、能力速查先掌握三个就够Claude Code 的自主能力不止上面两个下面这张表列全方便你以后按需查。但别想着一次全用上——真正的核心就是加粗的那三个其余是进阶用到了再看。能力一句话说明什么时候用/goal给个完成条件它自己干到达成为止单会话能收敛的中型任务最低成本的自主动态工作流 Dynamic Workflows自动分兵几十个 subagent 并行 互相质检一个人装不下的大活审计、批量补测试、逐条核查plan mode计划模式先只读探索、出方案你批了再动手动手前对齐思路防止它一上来就乱改子 agentsubagent派一个独立「专家」去干某件事只回结论探索代码、评审不想污染主对话时workflow 底层就是它hooks钩子在某个动作前后自动触发脚本想强制「测试不过就不许说完成」这类硬规则无头模式 / 循环脚本在命令行里反复唤起每轮全新状态过夜级、跨多个会话的超长任务MCP 工具接入外部能力如代码知识图谱、浏览器让它查代码关系、真在浏览器里点一遍验证/loop、定时任务每隔一段时间自动重跑轮询型盯 CI、盯部署状态给刚上手的你先学会/goal和plan mode这两个最简单的再上动态工作流。这三个吃透日常八成的场景都够了。上一节说的是「大活要选对、项目要有底子」这里再补另一头琐碎小事也别硬套这一整套。改个错别字、调一行代码直接让它做就好。自主能力是为「大到你不想盯」的活准备的不是每件小事都要摆开阵仗——大活选错和小事摆阵仗都是浪费。七、循序渐进从半小时到过夜不用一步到位。按这个阶梯来每一级用顺手了、开始信任它的自查报告了再上下一级阶段怎么做大概时长1. 一句话闭环提示词里写清「做完要跑什么检查、拿证据来」10–30 分钟2. 会话内自主用/goal交代完人就走开0.5–2 小时3. 分兵作战ultracode触发动态工作流并行铺开2–4 小时4. 过夜自跑无头循环脚本配好「停止开关」跨会话接力过夜最后一条底线务必记住无论多自主不可逆的危险操作永远要你亲自确认——强制推送、删库删数据、改生产配置、对外发消息。这类动作提前圈出来绝不让它自作主张。放手是为了提效不是为了替你闯祸。写在最后回到开头那句别再一句一句地喂它、然后守着屏幕。真正的用法是——把一件事想清楚、划好边界、给它一个能自我验证的目标然后交出去。你会发现省下来的时间不是一点半点。而这才是把 AI 用成生产力的样子把重复的判断和执行还给机器把真正需要你的判断留给自己。
