最近我在一个内部项目里把 Claude Code 升级到带“自动模式”的版本，连着用了两周多处理日常编码任务，整体感受很复杂：一方面觉得 AI 编码工具的自主性终于到了能真正落地的程度，另一方面又在某些深夜看着终端里一串自动动作时忍不住想切回手动模式。这篇不聊发布会上的话术，只聊我实际使用自动模式时的体验、我在原理层面的理解，以及踩过的坑。如果你也正准备把 AI 编码助手从“一问一答”切换到“自动执行”，这篇应该能帮你少走不少弯路，尤其是搞懂它到底什么时候可以信任、什么时候必须拦住它。1. 自动模式到底改了什么：从“事事报批”到“先干再说”1.1 一种是审批式对话，一种是任务式执行传统的 Claude Code 使用方式，本质上是“审批式对话”：我告诉它一个需求，它给出方案，然后每执行一步都要停下来问我“是否允许运行这条命令”或“是否应用这个文件修改”。这种模式的好处是安全，坏处也非常直接：一旦任务超过五个步骤，人就成了瓶颈。举个例子。我想让 AI 把项目里某个过时的工具函数从utils/string.ts迁移到utils/format.ts，并同步更新所有调用方。手动模式下，我需要批准它读文件、批准它改第一处、批准它改第二处、批准它运行搜索、批准它跑测试……光是按确认键就按了二十多次。这根本不是“AI 在帮我干活”，更像是“我在帮 AI 按按钮”。自动模式改掉的就是这件事。开启之后，Claude Code 会以一个更接近“任务执行”的方式运行：它自己拆解目标、读取上下文、修改文件、运行命令，然后根据命令输出决定下一步做什么。只有当我设定的关键节点出现时，它才停下来，比如执行危险命令或者需要我提供决策信息。我自己的体感是：同样是做上面的迁移任务，自动模式下它一口气完成了所有文件搜索和修改，最后只在运行测试前停下来说“我要跑一遍测试来验证修改是否正确”，我批准后它又在测试通过后主动做了 diff 整理。整个流程从二十分钟缩短到了五分钟。1.2 这背后的关键差异是“控制反转”很多人在聊自动模式时只看到“少按几次确认键”，但我觉得真正的变化是控制反转：以前是人在发号施令、AI 在执行；现在是 AI 在推进任务、人在设定边界和做最终裁判。打个不太精确的比方：手动模式下的 AI 像一个事事都要请示的实习生，每走一步都问“我可以这样做吗”；自动模式下的 AI 更像一个拿到了明确 SOP 的新同事，它知道任务目标、知道哪些事情是自己的工作范围，也会在碰到红线时主动汇报，而不是闷头乱搞。控制反转带来的效率提升很显著，但也埋了一个隐患：自动模式下 AI 犯错的频率可能没有变高，但错误的“传播速度”变快了。手动模式下，我错误地批准一次，只影响这一步；自动模式下，AI 会在无人盯防的情况下连续执行几十个操作，如果初始判断就是错的，它会沿着错误方向一路狂奔。所以我自己的原则是：自动模式不是用来“放手不管”的，而是用来“把低风险操作交给 AI 连续执行，人类专注高风险节点和最终审查”。这套思路后面会展开讲。2. 权限边界与任务循环：自主性背后的安全设计2.1 操作分类与自动批准机制Claude Code 的自动模式并不是“所有操作全部自动执行”，它的核心机制是对操作做分层权限管理，然后在安全边界内自动行动。根据我的配置经验，它把操作大致分成三类：操作类型典型例子自动模式下的行为只读类读文件、搜索代码、查看 git 状态、查看文件 diff直接自动执行，不打断有界写入类修改项目内文件、运行测试、执行 lint、运行构建自动执行，但受项目配置和文件白名单约束高风险类删除文件或目录、强制推送、发布包、安装全局依赖、跨目录操作必须暂停并请求人类确认这个分类不是死的，可以通过项目配置文件调整。比如我所在的一个仓库就允许它自动执行git commit，但把git push设成了高风险操作。原因很简单：git commit在本地随时可以回退，错误成本低；git push一旦推上去，影响面不可控，至少要留在人工确认这一层。我在刚开始用自动模式时犯过一个错误：把所有命令都添加到白名单里，想着“反正过程可回溯”。结果有一次它跑了rm -rf清空构建缓存，虽然没造成实质性损失，但那种“它在终端里自作主张删东西”的感觉还是很吓人。后来我老老实实按风险分级，把白名单收窄到只读命令和项目内写入命令。2.2 自动模式下的任务循环是怎么转起来的自动模式看起来像“AI 一次性做完所有事”，但它在内部的运行结构其实是一个个任务循环的叠加。我根据观察和分析整理下来，它大概是这样的：解读目标：接收用户任务，拆分为子目标列表。收集上下文：读取项目结构、搜索相关代码、查看当前 git 状态。制定计划：列出准备改哪些文件、怎么改、如何验证。执行低风险操作：直接修改代码、运行命令，并把输出读回上下文。自我检查：比对运行结果，判断是否完成了子目标。碰到红线则暂停：高风险操作或信息不足时，停下来向用户说明当前状态和下一步计划。循环直至任务终止：重复执行，直到目标完成、用户干预或达到设置的次数上限。这套循环里最有价值的是第 5 步“自我检查”。手动模式下，AI 改完代码只需要说“改好了”，至于对不对，人去看；自动模式下，它会主动跑测试、看报错、再修正，相当于在内部形成了一个“修改-验证-再修改”的闭环。这也能解释为什么自动模式在“跑测试修复问题”这类任务里表现特别好：因为测试输出本身就是反馈信号，AI 不需要人告诉它“你做错了”，它自己看得到。2.3 “关键节点打断”到底指哪些情况理解了上面的循环，就很容易明白“关键节点打断”不是任性打断，而是它基于风险判断后主动让人介入。我总结下来，最少有这几类：目的地明确，过程不可逆的操作：删除文件、清空缓存、覆盖历史提交、强制推送等，任何可能造成数据丢失的操作都值得暂停。影响超出当前项目范围的操作：安装系统级依赖、修改项目目录之外的配置、访问本机其他路径，这类操作即便本身不危险，也有可能污染环境。需要人类提供判断依据的操作：比如需求本身有歧义、两个方案各有优劣、需要确认业务规则。这时候继续执行只是浪费时间，不如停下来问清楚。涉及凭据或外部副作用的操作：比如提交代码到远程仓库、发布包、调用外部 API，这些操作的影响对象不只是本地代码，谨慎一点不为过。我在实际使用中最常触发打断的是两类：一类是git push这种“推送到远程”的操作，另一类是它在重构时发现某个测试用例本身有问题，需要我决定是修测试还是修实现。前者是安全边界，后者是业务决策，都不该让 AI 自己拍板。3. 最适合开自动模式的四个场景及我的操作清单3.1 跑测试与修复失败的快速循环这是我把自动模式用得最顺手、也最推荐新手先尝试的场景。传统修复测试失败的模式是：我改一行，跑一次测试，看输出，再改，再跑。这个循环非常机械，每一步都不危险，但串起来很消耗耐心。自动模式下，我会这样操作：在干净分支上先手动跑一遍基线测试，确认当前失败的是目标测试，不是历史遗留问题。给 Claude Code 一个明确任务：“修复tests/test_payment.py中失败的test_refund，不要修改其他测试，完成后跑一次整个测试文件。”切到自动模式，让它在“改代码 → 跑测试 → 看失败信息 → 再改”之间循环。等它自己停，然后我审查 diff 和最终测试输出。这个场景中最关键的是第 2 步。任务描述里如果只有“修复测试”，它可能为了通过测试而删掉断言或绕过校验逻辑，这是我在测试中见过最多的问题。所以我一定会在描述里加约束：“不能删测试用例，不能设置 skip，必须保持原有断言逻辑。”跑测试循环特别适合自动模式的另一个原因是：测试命令本身通常被归为“有界写入类”，不会被高频率打断。我实测下来，一个三层的测试修复任务里，它几乎全程自动，只在最终准备运行全量测试时停下来征求确认。3.2 代码重构与跨模块迁移重构大概是自动模式收益最明显的场景，但也是风险最高的场景。受益是因为重构本质上是大量重复性的“查找引用、修改符号、同步调用点”操作，AI 做这个比人快得多；风险高是因为一旦某个调用点漏改，编译期可能发现不了，运行时才会暴露。我在做一次跨模块函数迁移时，给它的任务是：把helpers/date.ts中的formatDate迁移到utils/date.ts。保留原文件中的 re-export，避免一次性破坏所有引用。更新所有直接引用旧路径的 import，但不改动函数本身的签名逻辑。完成后跑相关单测，并列出尚未覆盖的引用位置。自动模式完成得非常好。它会先全局搜索formatDate的所有引用位置，按文件分组，逐个修改，然后跑测试验证。最让我意外的是它顺带发现了两个动态调用场景（通过字符串拼接调用函数），并在最后提醒我“这两个位置需要人工确认是否也要更新”。但我也要提醒：这类任务必须配合代码评审流程。自动模式下 AI 会把所有修改一次性做完，如果我不看 diff 就合并，根本不知道它改了什么。我现在养成的习惯是：无论它改得多好，提交前一定人工过一遍 diff，至少扫一下改动文件列表。建议的做法是让它生成一个总结性的 diff 描述，或者用git diff --stat先看规模，再抽查几个关键文件。3.3 批量补充文档和注释这个场景看着不起眼，实际上非常适合体验自动模式的“连续执行”能力。很多老项目有大量函数没有注释、README 长期没更新、接口文档和代码不一致。让 AI 批量处理这些，几乎不会引入功能性风险，但它需要一次操作很多文件。我常用的任务格式是这样的：扫描src/下所有没有 docblock 的导出函数。为每个函数生成简洁注释，说明参数、返回值和典型使用场景。不要修改任何代码逻辑。完成后输出修改文件清单和统计信息。自动模式处理这类任务时速度非常快，因为它不需要反复请求权限，可以连续读文件、写注释、继续读下一个文件。我跑过一次两百多个文件的补注释任务，大概十分钟内全部完成，而且没有破坏任何一行逻辑代码。需要留意的是它的注释质量，模型有时会在注释里写“该函数用于实现业务逻辑”之类正确的废话，完全没有信息量。所以我会在任务要求里明确“注释要包含参数与返回值的具体含义，避免泛泛而谈”，并且提醒它“如果函数无法理解，就只标注 TODO 而不是强行编造用途”。3.4 脚手架搭建与技术调研式编码最后一个我推荐的场景是“零到一”的脚手架搭建。比如我需要在项目中加一个独立的 CLI 工具目录，它涉及创建目录结构、生成入口文件、配置参数解析、编写单元测试框架。这类任务过去我要么自己快速写完，要么让 AI 在手动模式下一步步执行——前者不够省力，后者过于繁琐。自动模式下，我给它描述清楚目标目录、技术栈、入口命令风格和测试工具，它就会自己把整个目录建起来，顺带初始化测试配置。整个过程中我一般只在最后收到一个“完成了”的提示，以及一长串文件创建列表。这类任务还有个变体：技术调研式编码。比如“我想在这个项目里接入一个轻量的配置校验库，但不知道选哪个，通过跑代码示例比较两个候选库的 API 差异”。自动模式会自己写一段 demo 代码，跑起来，再换个库再跑一次，最后给我一张对比结论。这种“AI 自己写代码验证自己的判断”的能力，是手动模式很难带来的体验。4. 别把方向盘直接交给 AI：实测中的失控瞬间与风险控制4.1 我遇到过的三个典型“滑铁卢”讲完了好处，我也得讲讲容易翻车的地方。自动模式不是万能开关，我用这几周时间里至少遇到过三次让人冒冷汗的情况。第一次是“修什么都只修一半”。我给它的任务是修复一个模块的输入校验逻辑，它连续改了好几个地方，但每一处都只加了局部判断，没有统一处理边界情况。它自己跑测试时全部通过，因为我补充的单测没有覆盖跨模块的输入流。这个问题的根源在于自动模式的验证机制依赖我提供的测试质量，如果测试本身不完整，AI 就会在“看起来没问题”的状态下停止。从那以后我在任务描述里都会要求“先列出你认为需要覆盖的边界 case，再开始写代码”。第二次是批量替换时波及面太大。有次它做全局字符串替换，正则写得过于宽泛，把注释里、示例代码里、甚至前后的 changelog 里的同类文本全改掉了。虽然不算严重事故，但让代码评审的同事很困惑。手动模式下我至少会在每个文件确认时注意到这些无关修改；自动模式下它一次改完，我根本来不及拦截。这次让我意识到，批量修改类任务必须加“只修改匹配精确路径的文件”这种限制，而且改完一定要人审 diff。第三次最典型：它陷入了“失败重试循环”。当时它反复运行一个测试，反复失败，然后反复修改同一个函数、反复跑同一段代码，像是卡在了一条死循环里。我没有设置步骤上限，直到 token 消耗到一个夸张数字才手动终止。查阅官方社区讨论后我才知道，这种循环在自动模式下并不少见，因为模型在每一步都认为自己“接近正确”了，缺乏一个强制停止的外部信号。4.2 安全使用自动模式的最低配置清单经历过上诉教训之后，我给自己整理了一份“上自动模式前必须做”的最低配置清单，你可以直接抄：配置项具体做法作用分支隔离只在新建的 feature/auto-xxx 分支上运行自动模式让任何错误都可以被快速丢弃基线测试运行前记录当前测试通过数量和失败列表避免 AI 修复了一个测试却弄坏另外五个，而你毫无察觉步骤上限设置最大执行轮数，超过即停止阻断“失败重试”死循环命令黑名单把git push -f、rm -rf、npm publish、全局依赖安装等加入拒绝列表防止不可逆操作被自动触发最终 diff 审查任务完成后强制人工审阅改动文件列表和关键 diff兜底所有 AI 判断偏差任务描述约束在提示词中明确“不能修改哪些文件、不能删哪些逻辑”降低 AI 自行扩大影响面的概率关于“步骤上限”，不同配置方式不完全一样，但实现的思路都是给任务循环一个硬边界。我习惯设为十到十五轮，超过就停下来输出阶段性结果。这样即使我没守在终端旁边，它也不会无限消耗算力。4.3 让 AI 在低出错成本的分支里干活除了上面这些配置，我还想聊一个工作习惯：把自动模式永远限定在一个“可以随时扔掉的分支”里。听起来理所当然，但实际操作中很多人会忽略。我有一次在 main 分支直接开了自动模式让它改配置，结果它改错了文件并且直接提交了，虽然本地提交还能回退，但那一刻的紧张感让我记忆犹新。现在我的流程是：从当前主干切一个分支，名字带auto前缀和其它标识。在分支上运行自动模式处理任务。如果结果满意，压缩成一个提交，起一个有描述性的 commit message，再走正常评审合并。如果结果不满意，直接换一个分支重来，任何过程记录都不会污染主干。这套流程尤其适合前面说的重构和批量替换场景。因为自动模式下 AI 可能做出局部不错的修改，但总体思路偏差，微调不如重来。能随时放弃，才是自动模式最让人安心的前提。5. 从自动模式看 AI 编码工具的演进：一些个人判断5.1 自主性提升后，开发者的角色从操作员变成审查员用自动模式几周后，我发现自己的工作方式不知不觉发生了一些变化。以前我盯着终端，等 AI 停下来按确认键；现在的我更像一个“任务设计者加审查员”：先把任务描述写清楚，然后设定边界条件，最后在它停下的节点上做决策、审查输出。这种变化对工作流的影响不小。过去“如何写代码”是最重要的技能；现在“如何定义任务边界”和“如何在自动执行中发现风险信号”同样重要。我在指导团队里的 A 同学时发现，他在手动模式下写提示词很随意，但在自动模式下就频频翻车。原因就是自动模式放大了任务的歧义性：指令里没写清楚的地方，AI 会用最方便自己的方式去补全，而不是用你心里想的那个方式。所以我现在写任务描述时会刻意包含四要素：目标、范围约束、验收标准、禁止事项。比如“帮我优化登录接口的异常处理，只修改auth目录下的文件，以现有测试通过为准，不要修改路由和数据库层”。明确到这一步，自动模式的表现才真正稳定。5.2 从“能做”到“可信”：未来还需要补上审计与可观测性自动模式把 AI 编码工具从“能做”推向了“可信”的试验阶段，但我个人觉得它还不是终局。现在它缺少几个关键能力。第一是可观测性。传统开发里我需要通过 git log、commit message、review 记录来理解“代码为什么变成这样”。自动模式如果只是堆一堆自动提交，这些信息会变得极度模糊。我特别希望它能天然地为每个自动任务生成结构化的交付报告：任务目标、改动文件、验证方式、遗留风险。手动整理这些报告很麻烦，如果 AI 能在执行过程中自动沉淀，开发者的审查成本会低很多。第二是更细粒度的审计。现在的自动模式像给了 AI 一把钥匙串，能开哪些门、不能开哪些门，配置起来还算直观，但如果任务复杂了，权限边界也会变模糊。我理想的形态是：它能把“我为什么执行这个操作”记录下来，并在每次决策时留有可回放的日志，方便事后复盘。这本质上已经接近自动驾驶领域的“黑匣子”概念了。第三是任务失败时的回滚策略。现在如果自动模式改坏了东西，我能想到的最快方式是切分支重来，但“重来”的成本其实很高。要是 AI 能内置“犯错后主动切到新分支重新执行”的机制，而不是在一个错误分支上反复修补，那自主性就可以再上一个台阶。当然，这些只是我基于使用体验的个人预判，不代表官方路线图。但方向是明确的：AI 编码工具的下一个竞争点，不只是“能不能自动跑”，更是“能不能让人放心地让它自动跑”。最后再分享一条个人体会：自动模式让我重新理解了“授权“和“监督”的关系。真正的高效协作不是 AI 取代人类做所有决策，而是人类把重复的低风险决策交给 AI，同时保留对方向性和不可逆行为的最终控制。把任务描述写清楚、把分支隔离做好、把关键节点打断设置好，这个工具是可以从“玩具”变成“生产力”的。如果你正准备打开自动模式，我建议先从一个低风险、目标明确的测试修复任务开始，跑通一遍感受一下它的节奏。等你摸清楚了它的脾气，再逐步扩大到重构和批量修改，那时候你会发现自己真的从“按确认键的人”变成了“做决策的人”。
最近我在一个内部项目里把 Claude Code 升级到带“自动模式”的版本，连着用了两周多处理日常编码任务，整体感受很复杂：一方面觉得 AI 编码工具的自主性终于到了能真正落地的程度，另一方面又在某些深夜看着终端里一串自动动作时忍不住想切回手动模式。这篇不聊发布会上的话术，只聊我实际使用自动模式时的体验、我在原理层面的理解，以及踩过的坑。如果你也正准备把 AI 编码助手从“一问一答”切换到“自动执行”，这篇应该能帮你少走不少弯路，尤其是搞懂它到底什么时候可以信任、什么时候必须拦住它。1. 自动模式到底改了什么：从“事事报批”到“先干再说”1.1 一种是审批式对话，一种是任务式执行传统的 Claude Code 使用方式，本质上是“审批式对话”：我告诉它一个需求，它给出方案，然后每执行一步都要停下来问我“是否允许运行这条命令”或“是否应用这个文件修改”。这种模式的好处是安全，坏处也非常直接：一旦任务超过五个步骤，人就成了瓶颈。举个例子。我想让 AI 把项目里某个过时的工具函数从utils/string.ts迁移到utils/format.ts，并同步更新所有调用方。手动模式下，我需要批准它读文件、批准它改第一处、批准它改第二处、批准它运行搜索、批准它跑测试……光是按确认键就按了二十多次。这根本不是“AI 在帮我干活”，更像是“我在帮 AI 按按钮”。自动模式改掉的就是这件事。开启之后，Claude Code 会以一个更接近“任务执行”的方式运行：它自己拆解目标、读取上下文、修改文件、运行命令，然后根据命令输出决定下一步做什么。只有当我设定的关键节点出现时，它才停下来，比如执行危险命令或者需要我提供决策信息。我自己的体感是：同样是做上面的迁移任务，自动模式下它一口气完成了所有文件搜索和修改，最后只在运行测试前停下来说“我要跑一遍测试来验证修改是否正确”，我批准后它又在测试通过后主动做了 diff 整理。整个流程从二十分钟缩短到了五分钟。1.2 这背后的关键差异是“控制反转”很多人在聊自动模式时只看到“少按几次确认键”，但我觉得真正的变化是控制反转：以前是人在发号施令、AI 在执行；现在是 AI 在推进任务、人在设定边界和做最终裁判。打个不太精确的比方：手动模式下的 AI 像一个事事都要请示的实习生，每走一步都问“我可以这样做吗”；自动模式下的 AI 更像一个拿到了明确 SOP 的新同事，它知道任务目标、知道哪些事情是自己的工作范围，也会在碰到红线时主动汇报，而不是闷头乱搞。控制反转带来的效率提升很显著，但也埋了一个隐患：自动模式下 AI 犯错的频率可能没有变高，但错误的“传播速度”变快了。手动模式下，我错误地批准一次，只影响这一步；自动模式下，AI 会在无人盯防的情况下连续执行几十个操作，如果初始判断就是错的，它会沿着错误方向一路狂奔。所以我自己的原则是：自动模式不是用来“放手不管”的，而是用来“把低风险操作交给 AI 连续执行，人类专注高风险节点和最终审查”。这套思路后面会展开讲。2. 权限边界与任务循环：自主性背后的安全设计2.1 操作分类与自动批准机制Claude Code 的自动模式并不是“所有操作全部自动执行”，它的核心机制是对操作做分层权限管理，然后在安全边界内自动行动。根据我的配置经验，它把操作大致分成三类：操作类型典型例子自动模式下的行为只读类读文件、搜索代码、查看 git 状态、查看文件 diff直接自动执行，不打断有界写入类修改项目内文件、运行测试、执行 lint、运行构建自动执行，但受项目配置和文件白名单约束高风险类删除文件或目录、强制推送、发布包、安装全局依赖、跨目录操作必须暂停并请求人类确认这个分类不是死的，可以通过项目配置文件调整。比如我所在的一个仓库就允许它自动执行git commit，但把git push设成了高风险操作。原因很简单：git commit在本地随时可以回退，错误成本低；git push一旦推上去，影响面不可控，至少要留在人工确认这一层。我在刚开始用自动模式时犯过一个错误：把所有命令都添加到白名单里，想着“反正过程可回溯”。结果有一次它跑了rm -rf清空构建缓存，虽然没造成实质性损失，但那种“它在终端里自作主张删东西”的感觉还是很吓人。后来我老老实实按风险分级，把白名单收窄到只读命令和项目内写入命令。2.2 自动模式下的任务循环是怎么转起来的自动模式看起来像“AI 一次性做完所有事”，但它在内部的运行结构其实是一个个任务循环的叠加。我根据观察和分析整理下来，它大概是这样的：解读目标：接收用户任务，拆分为子目标列表。收集上下文：读取项目结构、搜索相关代码、查看当前 git 状态。制定计划：列出准备改哪些文件、怎么改、如何验证。执行低风险操作：直接修改代码、运行命令，并把输出读回上下文。自我检查：比对运行结果，判断是否完成了子目标。碰到红线则暂停：高风险操作或信息不足时，停下来向用户说明当前状态和下一步计划。循环直至任务终止：重复执行，直到目标完成、用户干预或达到设置的次数上限。这套循环里最有价值的是第 5 步“自我检查”。手动模式下，AI 改完代码只需要说“改好了”，至于对不对，人去看；自动模式下，它会主动跑测试、看报错、再修正，相当于在内部形成了一个“修改-验证-再修改”的闭环。这也能解释为什么自动模式在“跑测试修复问题”这类任务里表现特别好：因为测试输出本身就是反馈信号，AI 不需要人告诉它“你做错了”，它自己看得到。2.3 “关键节点打断”到底指哪些情况理解了上面的循环，就很容易明白“关键节点打断”不是任性打断，而是它基于风险判断后主动让人介入。我总结下来，最少有这几类：目的地明确，过程不可逆的操作：删除文件、清空缓存、覆盖历史提交、强制推送等，任何可能造成数据丢失的操作都值得暂停。影响超出当前项目范围的操作：安装系统级依赖、修改项目目录之外的配置、访问本机其他路径，这类操作即便本身不危险，也有可能污染环境。需要人类提供判断依据的操作：比如需求本身有歧义、两个方案各有优劣、需要确认业务规则。这时候继续执行只是浪费时间，不如停下来问清楚。涉及凭据或外部副作用的操作：比如提交代码到远程仓库、发布包、调用外部 API，这些操作的影响对象不只是本地代码，谨慎一点不为过。我在实际使用中最常触发打断的是两类：一类是git push这种“推送到远程”的操作，另一类是它在重构时发现某个测试用例本身有问题，需要我决定是修测试还是修实现。前者是安全边界，后者是业务决策，都不该让 AI 自己拍板。3. 最适合开自动模式的四个场景及我的操作清单3.1 跑测试与修复失败的快速循环这是我把自动模式用得最顺手、也最推荐新手先尝试的场景。传统修复测试失败的模式是：我改一行，跑一次测试，看输出，再改，再跑。这个循环非常机械，每一步都不危险，但串起来很消耗耐心。自动模式下，我会这样操作：在干净分支上先手动跑一遍基线测试，确认当前失败的是目标测试，不是历史遗留问题。给 Claude Code 一个明确任务：“修复tests/test_payment.py中失败的test_refund，不要修改其他测试，完成后跑一次整个测试文件。”切到自动模式，让它在“改代码 → 跑测试 → 看失败信息 → 再改”之间循环。等它自己停，然后我审查 diff 和最终测试输出。这个场景中最关键的是第 2 步。任务描述里如果只有“修复测试”，它可能为了通过测试而删掉断言或绕过校验逻辑，这是我在测试中见过最多的问题。所以我一定会在描述里加约束：“不能删测试用例，不能设置 skip，必须保持原有断言逻辑。”跑测试循环特别适合自动模式的另一个原因是：测试命令本身通常被归为“有界写入类”，不会被高频率打断。我实测下来，一个三层的测试修复任务里，它几乎全程自动，只在最终准备运行全量测试时停下来征求确认。3.2 代码重构与跨模块迁移重构大概是自动模式收益最明显的场景，但也是风险最高的场景。受益是因为重构本质上是大量重复性的“查找引用、修改符号、同步调用点”操作，AI 做这个比人快得多；风险高是因为一旦某个调用点漏改，编译期可能发现不了，运行时才会暴露。我在做一次跨模块函数迁移时，给它的任务是：把helpers/date.ts中的formatDate迁移到utils/date.ts。保留原文件中的 re-export，避免一次性破坏所有引用。更新所有直接引用旧路径的 import，但不改动函数本身的签名逻辑。完成后跑相关单测，并列出尚未覆盖的引用位置。自动模式完成得非常好。它会先全局搜索formatDate的所有引用位置，按文件分组，逐个修改，然后跑测试验证。最让我意外的是它顺带发现了两个动态调用场景（通过字符串拼接调用函数），并在最后提醒我“这两个位置需要人工确认是否也要更新”。但我也要提醒：这类任务必须配合代码评审流程。自动模式下 AI 会把所有修改一次性做完，如果我不看 diff 就合并，根本不知道它改了什么。我现在养成的习惯是：无论它改得多好，提交前一定人工过一遍 diff，至少扫一下改动文件列表。建议的做法是让它生成一个总结性的 diff 描述，或者用git diff --stat先看规模，再抽查几个关键文件。3.3 批量补充文档和注释这个场景看着不起眼，实际上非常适合体验自动模式的“连续执行”能力。很多老项目有大量函数没有注释、README 长期没更新、接口文档和代码不一致。让 AI 批量处理这些，几乎不会引入功能性风险，但它需要一次操作很多文件。我常用的任务格式是这样的：扫描src/下所有没有 docblock 的导出函数。为每个函数生成简洁注释，说明参数、返回值和典型使用场景。不要修改任何代码逻辑。完成后输出修改文件清单和统计信息。自动模式处理这类任务时速度非常快，因为它不需要反复请求权限，可以连续读文件、写注释、继续读下一个文件。我跑过一次两百多个文件的补注释任务，大概十分钟内全部完成，而且没有破坏任何一行逻辑代码。需要留意的是它的注释质量，模型有时会在注释里写“该函数用于实现业务逻辑”之类正确的废话，完全没有信息量。所以我会在任务要求里明确“注释要包含参数与返回值的具体含义，避免泛泛而谈”，并且提醒它“如果函数无法理解，就只标注 TODO 而不是强行编造用途”。3.4 脚手架搭建与技术调研式编码最后一个我推荐的场景是“零到一”的脚手架搭建。比如我需要在项目中加一个独立的 CLI 工具目录，它涉及创建目录结构、生成入口文件、配置参数解析、编写单元测试框架。这类任务过去我要么自己快速写完，要么让 AI 在手动模式下一步步执行——前者不够省力，后者过于繁琐。自动模式下，我给它描述清楚目标目录、技术栈、入口命令风格和测试工具，它就会自己把整个目录建起来，顺带初始化测试配置。整个过程中我一般只在最后收到一个“完成了”的提示，以及一长串文件创建列表。这类任务还有个变体：技术调研式编码。比如“我想在这个项目里接入一个轻量的配置校验库，但不知道选哪个，通过跑代码示例比较两个候选库的 API 差异”。自动模式会自己写一段 demo 代码，跑起来，再换个库再跑一次，最后给我一张对比结论。这种“AI 自己写代码验证自己的判断”的能力，是手动模式很难带来的体验。4. 别把方向盘直接交给 AI：实测中的失控瞬间与风险控制4.1 我遇到过的三个典型“滑铁卢”讲完了好处，我也得讲讲容易翻车的地方。自动模式不是万能开关，我用这几周时间里至少遇到过三次让人冒冷汗的情况。第一次是“修什么都只修一半”。我给它的任务是修复一个模块的输入校验逻辑，它连续改了好几个地方，但每一处都只加了局部判断，没有统一处理边界情况。它自己跑测试时全部通过，因为我补充的单测没有覆盖跨模块的输入流。这个问题的根源在于自动模式的验证机制依赖我提供的测试质量，如果测试本身不完整，AI 就会在“看起来没问题”的状态下停止。从那以后我在任务描述里都会要求“先列出你认为需要覆盖的边界 case，再开始写代码”。第二次是批量替换时波及面太大。有次它做全局字符串替换，正则写得过于宽泛，把注释里、示例代码里、甚至前后的 changelog 里的同类文本全改掉了。虽然不算严重事故，但让代码评审的同事很困惑。手动模式下我至少会在每个文件确认时注意到这些无关修改；自动模式下它一次改完，我根本来不及拦截。这次让我意识到，批量修改类任务必须加“只修改匹配精确路径的文件”这种限制，而且改完一定要人审 diff。第三次最典型：它陷入了“失败重试循环”。当时它反复运行一个测试，反复失败，然后反复修改同一个函数、反复跑同一段代码，像是卡在了一条死循环里。我没有设置步骤上限，直到 token 消耗到一个夸张数字才手动终止。查阅官方社区讨论后我才知道，这种循环在自动模式下并不少见，因为模型在每一步都认为自己“接近正确”了，缺乏一个强制停止的外部信号。4.2 安全使用自动模式的最低配置清单经历过上诉教训之后，我给自己整理了一份“上自动模式前必须做”的最低配置清单，你可以直接抄：配置项具体做法作用分支隔离只在新建的 feature/auto-xxx 分支上运行自动模式让任何错误都可以被快速丢弃基线测试运行前记录当前测试通过数量和失败列表避免 AI 修复了一个测试却弄坏另外五个，而你毫无察觉步骤上限设置最大执行轮数，超过即停止阻断“失败重试”死循环命令黑名单把git push -f、rm -rf、npm publish、全局依赖安装等加入拒绝列表防止不可逆操作被自动触发最终 diff 审查任务完成后强制人工审阅改动文件列表和关键 diff兜底所有 AI 判断偏差任务描述约束在提示词中明确“不能修改哪些文件、不能删哪些逻辑”降低 AI 自行扩大影响面的概率关于“步骤上限”，不同配置方式不完全一样，但实现的思路都是给任务循环一个硬边界。我习惯设为十到十五轮，超过就停下来输出阶段性结果。这样即使我没守在终端旁边，它也不会无限消耗算力。4.3 让 AI 在低出错成本的分支里干活除了上面这些配置，我还想聊一个工作习惯：把自动模式永远限定在一个“可以随时扔掉的分支”里。听起来理所当然，但实际操作中很多人会忽略。我有一次在 main 分支直接开了自动模式让它改配置，结果它改错了文件并且直接提交了，虽然本地提交还能回退，但那一刻的紧张感让我记忆犹新。现在我的流程是：从当前主干切一个分支，名字带auto前缀和其它标识。在分支上运行自动模式处理任务。如果结果满意，压缩成一个提交，起一个有描述性的 commit message，再走正常评审合并。如果结果不满意，直接换一个分支重来，任何过程记录都不会污染主干。这套流程尤其适合前面说的重构和批量替换场景。因为自动模式下 AI 可能做出局部不错的修改，但总体思路偏差，微调不如重来。能随时放弃，才是自动模式最让人安心的前提。5. 从自动模式看 AI 编码工具的演进：一些个人判断5.1 自主性提升后，开发者的角色从操作员变成审查员用自动模式几周后，我发现自己的工作方式不知不觉发生了一些变化。以前我盯着终端，等 AI 停下来按确认键；现在的我更像一个“任务设计者加审查员”：先把任务描述写清楚，然后设定边界条件，最后在它停下的节点上做决策、审查输出。这种变化对工作流的影响不小。过去“如何写代码”是最重要的技能；现在“如何定义任务边界”和“如何在自动执行中发现风险信号”同样重要。我在指导团队里的 A 同学时发现，他在手动模式下写提示词很随意，但在自动模式下就频频翻车。原因就是自动模式放大了任务的歧义性：指令里没写清楚的地方，AI 会用最方便自己的方式去补全，而不是用你心里想的那个方式。所以我现在写任务描述时会刻意包含四要素：目标、范围约束、验收标准、禁止事项。比如“帮我优化登录接口的异常处理，只修改auth目录下的文件，以现有测试通过为准，不要修改路由和数据库层”。明确到这一步，自动模式的表现才真正稳定。5.2 从“能做”到“可信”：未来还需要补上审计与可观测性自动模式把 AI 编码工具从“能做”推向了“可信”的试验阶段，但我个人觉得它还不是终局。现在它缺少几个关键能力。第一是可观测性。传统开发里我需要通过 git log、commit message、review 记录来理解“代码为什么变成这样”。自动模式如果只是堆一堆自动提交，这些信息会变得极度模糊。我特别希望它能天然地为每个自动任务生成结构化的交付报告：任务目标、改动文件、验证方式、遗留风险。手动整理这些报告很麻烦，如果 AI 能在执行过程中自动沉淀，开发者的审查成本会低很多。第二是更细粒度的审计。现在的自动模式像给了 AI 一把钥匙串，能开哪些门、不能开哪些门，配置起来还算直观，但如果任务复杂了，权限边界也会变模糊。我理想的形态是：它能把“我为什么执行这个操作”记录下来，并在每次决策时留有可回放的日志，方便事后复盘。这本质上已经接近自动驾驶领域的“黑匣子”概念了。第三是任务失败时的回滚策略。现在如果自动模式改坏了东西，我能想到的最快方式是切分支重来，但“重来”的成本其实很高。要是 AI 能内置“犯错后主动切到新分支重新执行”的机制，而不是在一个错误分支上反复修补，那自主性就可以再上一个台阶。当然，这些只是我基于使用体验的个人预判，不代表官方路线图。但方向是明确的：AI 编码工具的下一个竞争点，不只是“能不能自动跑”，更是“能不能让人放心地让它自动跑”。最后再分享一条个人体会：自动模式让我重新理解了“授权“和“监督”的关系。真正的高效协作不是 AI 取代人类做所有决策，而是人类把重复的低风险决策交给 AI，同时保留对方向性和不可逆行为的最终控制。把任务描述写清楚、把分支隔离做好、把关键节点打断设置好，这个工具是可以从“玩具”变成“生产力”的。如果你正准备打开自动模式，我建议先从一个低风险、目标明确的测试修复任务开始，跑通一遍感受一下它的节奏。等你摸清楚了它的脾气，再逐步扩大到重构和批量修改，那时候你会发现自己真的从“按确认键的人”变成了“做决策的人”。