TL;DR：运行 Source Control → New Worktree（或 git worktree add ../experiment-X feature-X）来创建一个隔离的工作副本并切换到对应分支。让代理在 worktree 中操作；如果实验失败，直接删除该 worktree——你的主分支完全不受影响。
当你想让代理尝试一些试探性操作——重写、复杂迁移、"只是看看能不能跑通"的改动——不要让它在主分支上随意发挥。fork 一个 worktree，让它自由实验，然后只合并你想要的部分。
AI 代理最有价值的地方，在于它能替你尝试你自己不会动手写的东西——试探性重构、复杂迁移、"就看看能不能跑通"的探索。问题在于：直接在你的实时工作树上做这些操作风险很高。一旦代理跑偏，它改动的那些文件正是你准备发布的文件。构建可能崩溃，编辑器里打开的对话窗口也会对"当前哪个版本才是真实代码"感到困惑。
直觉上的答案是"用分支"——这没错，但实际上并没有真正隔离什么。在主 checkout 里切换分支，会把你未提交的改动一并带走，重置 IDE 状态，还会强迫 AI 对话进行上下文切换。分支只是一串提交的名字，不是一个独立的"地方"。你没办法同时处于两个分支。
worktree 才是 git 对"我想同时存在于两个地方"这个需求的真正答案。它是你仓库的第二个物理 checkout，指向不同的分支，但共享同一个 .git 存储。两棵树，一段历史。你可以让代理在树 B 里重写某些东西，同时你继续在树 A 里编辑——独立的窗口，独立的文件，互不干扰。本教程讲的就是：在风险足够高、值得隔离的时候如何使用这个方法，以及实验成功后如何有选择地合并回来。
在主 checkout 里切换分支，会把你正在进行的工作一并带走——未保存的文件跟着走，IDE 状态重置，AI 打开的对话标签页突然在讨论另一套代码。做个快速修复还好，但对于高风险实验来说，这种摩擦就太多了。
worktree 是你仓库的第二个物理 checkout，指向不同的分支，共享同一个 .git 存储。两棵树，一段历史。你可以让代理在树 B 里重写某些东西，同时你继续在树 A 里编辑。
在左侧边栏点击 Workspaces 标签页。你会看到当前项目及其活跃分支，顶部有一个 + New Worktree 按钮。
Workspaces 面板也是影子 worktree 的显示位置——代理在想要执行工具调用但不触碰你实际文件时，会隐式创建这些隔离树（详见下文）。
点击 + New Worktree 并选择一种模式：
本教程选择 New branch，名字可以取 try-async-await 之类的。LingCode 会在底层执行 git worktree add，并在新窗口中打开这棵新树。
在新窗口中，AI 面板操作的是 worktree 中的文件。现在可以给它那个试探性的提示了："把 NetworkManager 全部改成 async/await，不用 completion handler。"无论它改了什么，都只在这棵树里。你的主分支完全不受影响。
你也可以在这里把权限模式切换为 acceptEdits 而不用担心——当范围被限定在 worktree 内时，自动接受其实安全得多。
代理完成后，在 Workspaces 面板中打开差异视图——右键点击该 worktree，选择 Compare with main。你会看到实验改动过的每一个文件。
仔细过一遍这些差异。有些改动会很好，有些会很奇怪。这完全正常——这正是在 worktree 里先做实验的意义所在。
两种方式：
这正是 git 命令行让人头疼而 LingCode 让人一目了然的地方——你可以吸取代理的好想法，而不必继承它的烂主意。
在面板中右键点击该 worktree，选择 Remove worktree。LingCode 会执行 git worktree remove，删除工作文件，但如果你有提交过，分支仍然保留在 git 历史中。如果你也想删除分支，再选择 Delete branch。