让 Claude Code 写篇普通文档,它却按写代码的方式开工了

前几晚，我让 Claude Code 处理一个很普通的文档任务。不是开发功能，不是改代码，也不是修 bug，只是基于已有材料产出一份 Markdown 文档，顺手做一下检查，最后把文件交付出来。

这类事我平时经常交给 AI 做：读一点上下文，整理结构，生成文件，确认结果。按我的理解，这就是一次“非代码文件交付”。

但那次不太一样。文档还没交付出来，屏幕上先出现了几个明显属于软件工程世界的词：worktree、隔离目录、分支、子任务。它不像是在处理文档，倒像一个程序员接到需求之后，先拉了一条分支，把任务搬进一间独立办公室，再关上门开始干活。

我当时第一反应是：等等，我不是让你写代码，你为什么先给自己开了个工位？

后来我顺着本地痕迹查了一圈，发现这不是界面上随便闪过的一段说明。它真的创建了一个隔离工作区。本地留下了独立目录、Git 分支、reflog 记录，还有一次真实提交。也就是说，这不是“看起来像触发了机制”，而是机制确实跑起来了。

这件事真正有意思的地方，不是“AI 又出异常现象了”。更准确地说，它可能是 Claude Code 把一次普通文档任务识别成了“会改动项目文件的多步骤交付”，于是调用了原本用于软件开发的隔离流程。换句话说，我看到的不是一个孤立异常，而是 Agent 工具后台的一次任务路由。

现场留下了什么

我后来能确认的证据链是这样的：2026 年 7 月 15 日晚上 22:09 左右，本地 Git 记录里出现了一个新分支：worktree-ai-context-handoff-article。同时，机器上多了一个隔离目录：.claude/worktrees/ai-context-handoff-article/。

大约 40 分钟后，这个隔离分支产生了一次提交：content: draft AI context handoff article。这次提交新增了两份文件，共 473 行：一份交付文档，以及一份 review.md 检查记录。

这里有两个细节值得注意。第一，它不是只在界面上展示了一段 worktree 说明，而是在文件系统和 Git 历史里留下了可追踪痕迹。第二，故事的起点不是我偶然发现陌生文件夹，而是我在当时看它运行时，先觉得过程不对劲；后面交付结果也有点偏，于是才回头查本地痕迹，最后把 worktree、分支、提交和检查记录串了起来。

所以，这不是一个“我发现奇怪文件夹”的故事，而是一次“我看见执行过程异常，然后反向追踪机制”的小调查。

worktree 不是神秘功能，它是隔离工位

如果你不是程序员，可以把 worktree 理解成一个“隔离工位”。一个项目目录就像你的主桌面，里面有原始文件、素材、草稿、配置和各种工作痕迹。如果 AI 要在这个目录里改东西，直接动主桌面当然最快，但风险也最大。

风险在哪里？它可能覆盖原文件，生成一堆中间文件，改到一半方向不对，或者任务结束后你分不清哪些改动是刚才产生的。对代码项目来说，这类风险非常常见，所以软件工程里有一套成熟做法：不要直接在主线上乱改，先开分支，隔离执行，验证没问题，再决定要不要合并回来。

这对代码开发来说很正常。问题在于，我那次交代的是非代码文档任务。它为什么会走到这一步？答案不在 worktree 本身，而在 Claude Code 对任务性质的判断。

真正值得拆的是“它怎么判断要不要隔离”

表面看，这是“文档任务触发了 worktree”。往下一层看，它其实涉及一套任务路由：Claude Code 不是只理解你说了什么，还要判断这件事该用什么方式执行。

我把这个过程拆成五层。

第一层是用户意图识别。用户眼里的任务是“帮我产出一个文档”，但 Claude Code 眼里的任务可能不是“回复一段文字”，而是“在当前项目中读取材料、生成文件、写入目录、进行检查、形成交付”。一旦任务从“回答”变成“改动文件系统”，它就进入了更接近工程执行的范畴。

第二层是任务复杂度判断。简单问答不需要隔离，直接回复就行；简单文件修改也未必需要隔离。但如果任务包含多个步骤，比如读取上下文、组织结构、生成新文件、检查结果、记录结论，它就可能被判定为多步骤交付。多步骤交付的风险不只在内容对不对，还在过程会不会污染工作区。

第三层是项目环境读取。Claude Code 不是悬浮在空气里工作的，它在一个真实目录中运行。这个目录可能有 Git 历史、已有文件、项目规则、未提交改动、.claude 配置、Skill 或全局指令。它接到任务后，可能会把“当前目录是一个可版本管理的工作区”也纳入判断。对一个编程助手来说，只要任务要落盘，当前目录状态就不是背景信息，而是执行约束。

第四层是规则或 Skill 触发。Claude Code 的行为不只来自模型本身，还会受到系统规则、用户规则、项目指令和 Skill 工作流影响。这些规则可能写着：复杂任务要先隔离，涉及多文件改动要开独立工作区，交付前要检查，不能污染当前目录。我们现在缺少那次会话里调用 EnterWorktree 的完整原始参数，所以不能百分之百断言是哪一条规则触发；但从痕迹看，“复杂任务 + 文件交付 + 工程化保护流程”这条链是说得通的。

第五层是执行环境选择。当前面几层判断叠加到一起，系统就可能选择一种更稳妥的执行环境：不要在主工作区直接做，开一个 worktree。于是你看到的就不是普通文档生成，而是分支、隔离目录、提交、检查记录这一整套工程流程。

这也是我觉得这件事有价值的地方。它不是在证明 Claude Code 有多神秘，而是在提醒我们：Agent 工具的执行逻辑不是一个黑箱按钮，而是一套连续判断。它可能会先判断你要什么，再判断这是不是交付、会不会动文件，并结合当前项目约束，选择普通执行还是隔离执行。

为什么这次判断显得“过度认真”

如果这是一段代码改造任务，我不会惊讶。开 worktree、拉分支、做检查、留提交，这些都合理。但这次只是非代码文档任务，所以反差感很强。

这里的关键不是 Claude Code 失控，而是它的任务分类边界变宽了。对用户来说，“文档”天然不像代码；对 Claude Code 来说，只要它要读文件、写文件、生成交付物、做检查，它就已经具备很多代码任务的结构特征。

换句话说，它可能不是按“内容类型”分类，而是按“执行形态”分类。你觉得这是文档，它看到的是文件系统变更；你觉得这是整理，它看到的是多步骤交付；你觉得只是让它产出结果，它看到的是一个需要保护主工作区的任务。

这个差异很重要。我们平时会把任务分成“写代码、写文档、整理资料、做表格”。但 Agent 工具可能会换一种分法：要不要读本地文件？要不要改文件？要不要跨多个步骤？要不要验证？要不要保留回滚空间？要不要避免污染主目录？

一旦它按后一种方式分类，就会出现这种看起来很奇怪、但内部逻辑并不离谱的行为：普通文档任务，被路由到了工程化执行流程里。

这不是失控，而是工作流溢出

很多类似事件很容易被写成“AI 失控了”“后台黑箱被看见了”。但从证据看，它没有越权，没有乱删文件，也没有做不可逆操作。它只是调用了一套本来用于软件开发的安全机制。

问题在于，这套机制被用在了一次非代码文档任务上。我更愿意把它叫作：工作流溢出。一个工具原本为 A 场景设计的流程，在遇到边界模糊的 B 场景时，也被触发了。

Claude Code 的核心身份是编程助手。它习惯处理代码项目、文件修改、分支、测试、验证和提交。但我们现在越来越常拿它做非代码任务：整理知识库、生成文档、归档项目资料、维护个人资料库、把零散素材变成可交付文件。

这些任务虽然不是代码开发，但它们和代码开发共享一组底层动作：读文件、写文件、改目录、产生版本、检查结果、避免破坏原始材料。所以从 Agent 的视角看，这不是聊天，而是一次交付。既然是交付，就可能需要隔离、执行、检查、留下记录。

这也是为什么我不想把它写成猎奇事故。它更像是一次边界测试：当一个工具拥有工程化工作流之后，这套工作流会不会溢出到非代码任务里？答案是，会，而且已经发生了。

对普通用户真正有用的结论

这件事不是让大家去学 Git，也不是让每个人都去研究 worktree。真正有用的结论是：当你使用 Claude Code 这类 Agent 工具时，你面对的已经不只是一个会说话的模型，而是一个带执行环境、工具权限、项目规则和工作流判断的系统。

普通聊天模型的重点是“怎么回答”。Agent 工具的重点变成了“怎么干活”。它不只生成文字，还会选择工具、读写文件、判断风险、决定是否隔离、检查交付物。这时，用户真正要学的不是更多提示词模板，而是更清楚地定义任务边界。

比如你可以明确说：这是一个轻量文档任务，直接在当前目录生成文件，不需要开隔离工作区。或者反过来说：这是重要资料，先在隔离目录处理，确认后再合并回来。再比如你可以要求：只生成草稿，不做发布检查；或者必须检查链接、图片和文件路径后再交付。

我之前写过一篇文章，讲的是怎么让 AI 在信息充分时少问废话、直接交付。这次其实是同一个问题的另一面：不是只告诉 AI “什么时候可以直接做”，还要告诉它“什么时候应该轻量做，什么时候必须隔离做，什么样才算做完”。

最后

那天之后，我对 Claude Code 的理解变了一点。以前我更多把它当成一个“能改文件的 AI”。现在我会把它看成一个“带工程习惯的 AI 员工”。

这个员工有时候很认真。认真到你只是给它一个普通文档任务，它也可能先判断任务性质、读取项目环境、套用规则、选择执行工位，然后再开始干活。

那一次，Claude Code 没有失控。它只是把一套适合改代码的安全流程，过度认真地套在了非代码文档任务上。

但正是这个“过度认真”，把 Agent 后台那套任务路由推到了台前：模型不只是理解一句话，还可能会根据任务形态，把它归到问答、文件修改、复杂交付，或需要隔离的工程任务里。我们最终看到的一行回复，可能只是结果；真正的 AI 工作现场，早就在后台开工了。