Vibe Coding 脏工作树安全改码：先保护已有修改，再约束 AI 补丁

脏工作树不是必须先解决的异常，它可能是用户正在进行的另一项工作、已暂存但尚未提交的修复、工具生成的本地文件，或多个任务共享现场。真正危险的是 AI 把“保持仓库整洁”理解成可以 reset、restore、stash、clean 或全仓格式化。那些命令可能让当前任务更容易，却改变了它没有所有权的内容。

安全原则是把任务补丁叠加到现有现场，并能证明哪些变化原本就存在、哪些由本任务新增。它不同于并行编程 Agent 的 Worktree 所有权围栏：后者解决多个独立 worktree 的并发 claim；本文处理一个共享工作目录中已经存在的修改。

先读懂三层状态

Git 工作现场至少有 HEAD、index 和 working tree 三层。git status --short 给出概览，git diff 展示工作树相对 index 的未暂存变化，git diff --cached 展示 index 相对 HEAD 的已暂存变化。还要单独列出未跟踪文件；它们没有基线 diff，却可能是用户刚创建的完整工作。

不要只看文件名。一个文件可能同时包含已暂存和未暂存 hunk，rename 也可能在另一层有后续编辑。二进制文件、submodule、文件模式和符号链接需要保留其类型信息。ignored 文件默认不进入任务范围；若验证会改缓存或生成物，先确认它们确实可丢弃。

M  src/auth.ts       staged: pre-existing fix
 M src/router.ts     unstaged: ownership unknown
?? tests/return.ts   untracked: user draft

这份清单只描述状态，不自动推断所有者。用户明确说“这些都是我正在改的”时才标为保护；由当前任务刚生成的文件可标为 owned。无法区分的内容按保护处理。

建立路径和 hunk 级归属

允许范围不能只写“可以改 src/”。把文件分为 owned、shared、protected、unknown。owned 文件可按任务修改；protected 和 unknown 只读；shared 文件允许增加与任务有关的 hunk，但不得重写现有 hunk。若目标修复恰好需要同一行，先停止并展示冲突，让用户决定合并语义。

记录开始时的状态与 diff 摘要，可保存到任务外的受控证据目录，避免证据本身污染仓库。对未跟踪文件记录路径和内容摘要，但不要把秘密文件内容送入模型。快照用于对比，不是替代版本控制，也不赋予 AI 回滚权。

大型 Monorepo 的索引新鲜度说明索引需叠加脏工作树；AI 读取代码也必须以当前工作树为准。只从 HEAD 读取会漏掉用户新接口，随后生成一个错误的“兼容修复”。

禁止用清理命令解决不确定性

git restore 官方文档明确说明它会恢复工作树或 index 内容；reset、checkout --、clean 同样可能破坏现场。除非用户明确授权具体路径和目标状态，否则 Agent 不应执行。stash 也不是无害暂停键：它改变工作树、可能漏掉未跟踪内容，并在恢复时制造冲突。

提交也不是默认保护手段。AI 不应把用户的半成品和本任务混成一个 commit，更不应为获得干净基线擅自提交。需要隔离时，可以建议新 worktree 或补丁移交，但创建、移动和删除工作树仍需遵循仓库政策与用户授权。Git 高级工作流提供这些 Git 工具的背景，关键是不要把“工具可用”误认为“当前任务获准使用”。

编辑时控制补丁形状

优先做局部、可审阅的编辑。避免对 shared 文件运行会重排全文件的 formatter、代码生成器或 import sorter；如果项目门禁必须运行，先确认输出范围并获得同意。批量替换先只统计命中，检查是否包含 protected 路径，再应用到批准集合。

每次编辑后立即看目标文件 diff，确认没有吞掉已有 hunk。AI 若发现磁盘内容和刚读取的版本不同，应视为并发变化，停止写入并重新盘点，而不是用手头旧内容覆盖。对于生成文件，找到源和生成命令；不能因为产物里有错误就直接重写整份文件。

验证结果也要区分归因

脏基线可能已有 lint 或测试失败。修改前尽可能运行针对性基线，记录已知失败；修改后比较新增、修复和未变化失败。不能把本任务没有造成的红灯声称为已解决，也不能因为基线本来红就忽略新的失败。

编程 Agent 的改动验证门要求测试证据绑定具体 diff。在脏树中，这个绑定应包括 HEAD、初始 diff 摘要和本任务增量。否则一次绿色测试无法说明它覆盖了哪组混合修改。

用前后收据证明没有越界

完成时重新采集 status、staged diff、unstaged diff 和未跟踪列表，生成三类结果：原有且未改变、本任务新增、意外变化。逐个核对 protected 文件内容摘要、shared 文件旧 hunk、文件删除与重命名。任何无法解释的变化都阻止交付，先回到用户确认；不要自行“修正”未知变化。

最终报告应明确列出本任务文件、保留的已有文件、运行的命令、基线失败和剩余风险。安全完成不要求工作树变干净，而要求已有工作完整、任务增量可识别、验证覆盖清楚。Vibe Coding 可以在复杂现场中继续推进，但前提是 AI 把所有权当成硬边界，而不是把清理现场当作默认步骤。

延伸阅读

• 并行编程 Agent 的 Worktree 所有权围栏
• 大型 Monorepo 的索引新鲜度
• Git 高级工作流
• 编程 Agent 的改动验证门