AI 编程并行改代码会互相覆盖吗？用 Git worktree 隔离与验收
两个任务同时修改同一个工作目录，可能互相覆盖尚未提交的文件。Git worktree 让不同分支分别拥有工作目录，但隔离不等于合并正确，也不等于权限隔离。先划分任务与目录，再逐个审查、合并和测试，发现冲突就在对应步骤停止。
先看结论
未提交文件被另一个任务修改核对实际工作目录worktree 用于分离工作文件与索引
合并产生冲突停止并阅读双方改动不机械选择全部保留某一方
无文本冲突但测试失败核对组合后的接口与行为目录隔离不能代替集成测试
共享端口、凭据或服务器另设权限与资源边界worktree 不是安全沙箱
并行修改按这6步验收
核对原项目与共同基线
先查看分支、已修改文件、未跟踪文件和本地基线。存在未处理的原有工作时先保存，不把本地 main 当作必然等于远端最新版。
为任务创建不同分支和目录
从同一已核实基线建立不同 worktree，明确每个任务的绝对目录和文件范围。保留 Git 默认禁止同一分支重复 checkout 的保护。
各自检查与测试
分别查看 diff、暂存差异和新文件，运行项目已有验证。git diff --check 只是差异检查，不是功能测试通过证明。
在干净验收分支逐个合并
先审查任务提交，再使用普通合并的提交前检查点，核对未合并文件、暂存差异和组合测试后才提交。
冲突时停止
出现冲突不继续强行提交。阅读双方需求，保留分支；需要放弃本次合并时也先确认原有工作已保存，不能把 merge --abort 当作任意状态的备份。
保存产物后再清理
清理前连同忽略文件一起检查。只有不存在需要保留的修改、未跟踪和忽略文件，才正常移除 linked worktree，不用强制清理参数。
来源、日期与演示边界
这份教程与离线示例由 AIXiamo（AI夏末）维护，首次发布与核对日期为2026年10月11日。自有站保留原始发布日期；示例沿用原项目的 MIT 许可，使用合成代码而非客户项目。
Git linked worktree 共享仓库对象和部分配置，各自拥有工作目录、HEAD与索引。同一分支默认不能同时 checkout 到多个 worktree；本例不使用覆盖选项关闭保护。
目录隔离不限制进程访问其他目录、共享数据库、生产服务器或同一端口。敏感项目仍需独立约束工具权限、凭据、环境变量、服务地址与允许修改的范围。
先运行完整的离线验证
先下载并审阅脚本，需要已安装 Git 与 Python 3，没有依赖包安装步骤。每次运行创建新的临时目录，不接受现有仓库作为输入，不设置 remote，不联网、不调用模型、不推送或部署。
脚本使用独立 HOME、禁用系统与全局 Git 配置、使用空 hooks 目录和教学作者身份。47项断言检查修改隔离、提交前暂停、组合测试、冲突停止、未跟踪文件保护、分支保留与 main 未变更。成功输出应含 passed:true、checks_passed:47 和 main_unchanged:true。
报告保留在本次新建临时目录，便于核对真实命令与退出码；每次路径和提交哈希不同。失败时脚本非零退出并留下报告，不继续强制合并或清理。它的成功不证明读者真实项目的功能、权限、速度或模型质量。
python3 verify_worktree.py
# 成功输出的关键字段：
# passed: true
# checks_passed: 47
# main_unchanged: true两个任务怎样从同一基线开始
合成基线包含一个计数函数、两个单元测试和说明。任务一添加负数校验与测试，任务二只补使用说明；它们从同一个 main 提交建立，在各自目录里修改。脚本验证一个任务的未提交文件不会自动出现在其他目录。
下面是真实项目中的核对顺序，目录名与 main 只是例子，不能不经检查直接套用。已有分支或目录先核对，不覆盖、不重置；给每个任务明确实际绝对路径，避免任务打开原项目的同一份文件。
git status --short --untracked-files=all
git branch --show-current
git log -1 --oneline main
git rev-parse main
# 确认基线、分支与目录均可用后：
git worktree add -b ai/validation ../project-wt-validation main
git worktree add -b ai/docs ../project-wt-docs main
git worktree list每个任务先留下可核对的结果
在对应 worktree 审阅代码、暂存差异和新文件，运行自己的测试。示例的校验任务有三个测试，文档任务保留基线的两个测试；真实项目应使用既有工具链，不因示例用 Python 就替换自己的构建系统。
git diff --check 检查空白等差异问题，不是行为验收。只有范围正确、相关验证通过，才暂存明确文件并提交；工作目录隔离不会替你同步依赖或构建环境。
git -C ../project-wt-validation status --short --untracked-files=all
git -C ../project-wt-validation diff
git -C ../project-wt-validation diff --check
git -C ../project-wt-validation diff --cached在验收分支逐个合并，不直接改 main
示例建立第三个 worktree 承担组合验收，main 始终停在原基线。先确认验收目录干净，查看任务提交与差异，再执行 --no-ff --no-commit，使普通合并停在提交前；命令失败或出现冲突就在这里停止。
只有未合并路径为空、暂存差异通过检查、组合后的三个单元测试通过，示例才创建合并提交。第二个任务重复这个过程；真实项目还须按风险检查接口、构建、页面与数据库行为，文本合并成功不能替代这些检查。
git worktree add -b review/integration ../project-wt-review main
git -C ../project-wt-review status --short --untracked-files=all
git -C ../project-wt-review diff HEAD...ai/validation --stat
git -C ../project-wt-review diff HEAD...ai/validation
# 审阅通过且目录干净后，在提交前检查：
git -C ../project-wt-review merge --no-ff --no-commit ai/validation
git -C ../project-wt-review diff --name-only --diff-filter=U
git -C ../project-wt-review diff --cached --check
git -C ../project-wt-review diff --cached冲突停止与清理保护是另外两项验收
冲突演示让两个分支修改说明的同一行。第二次合并失败后，脚本核对 HEAD没有新增提交、README仍在未合并列表中。真实冲突需阅读两方改动，不机械选全部保留某一方。
从干净验收目录开始时，可以在确认无需额外保存合并后编辑的前提下，用 merge --abort 放弃本次合并。合并前已有未提交工作时，不保证重建所有修改，因此不能把退出合并当作通用恢复功能。
清理演示故意留一份未跟踪说明，验证普通 worktree remove 拒绝移除且文件仍在；提交合成说明后才正常移除。真实项目还要另查 .env、本地数据库和其他忽略文件，必要资料先保存。移除目录不是发布，也不删除保留的任务分支。
# 先阅读冲突和需要保存的工作；符合条件才放弃本次合并：
git -C ../project-wt-review merge --abort
# 清理门槛：连同忽略文件一起核对，输出须无待保留文件。
git -C ../project-wt-validation status --short --untracked-files=all --ignored
# 只有确认可清理后，正常移除，不加 --force：
git worktree remove ../project-wt-validation
git worktree list安全与事实检查
- 任务使用不同分支与实际工作目录，文件范围明确。
- 原项目未提交、未跟踪和必要忽略文件均已核对保存。
- 每个任务分别验证，合并后的组合行为再次测试。
- 冲突导致流程停止，没有强行提交或机械覆盖。
- 清理不使用强制参数，保留任务分支与验收证据。
- 目录隔离与工具权限、凭据和生产资源隔离分别处理。
常见问题
两个 AI 任务改不同文件，就一定没问题吗？
不一定。一个任务修改接口，另一个任务按旧接口调用，即使没有文本冲突，组合后仍可能失败。worktree 分离文件，测试和审查验证组合行为。
建了 worktree，为什么另一个任务还看见我的修改？
先核对它实际使用的绝对目录，是否仍打开原项目文件。共享提交与分支是正常的；同一未提交文件被混写则需要核对工作目录和工具权限。
能让两个任务同时使用同一个分支吗？
本例使用不同分支，并保留 Git 默认的重复 checkout 拒绝。需要共享结果时，在明确的验收环节合并，不关闭保护让多个任务同时更新同一分支。
worktree 能隔离生产权限和账号凭据吗？
不能。它不是安全沙箱；进程访问范围、环境变量、共享服务和凭据必须另外限制。
合并没有冲突，就可以直接发布吗？
不能。还须审阅暂存差异、运行组合测试，并按项目发布流程确认。本文的合成脚本不推送或部署，47项断言不是生产发布许可。
并行任务一定更快或更省会员额度吗？
本例只验证 Git 行为，没有测试模型速度与用量。任务质量、冲突成本与计划额度是不同问题，不能从目录隔离推出固定节省。
官方参考
产品功能、方案名称、用量与地区可用性以 OpenAI 当前官方页面为准。
AIXiamo 购买、交付与售后条件以对应实时商品页和原订单为准，不是上述官方文档的服务承诺。内容维护与纠错