How to work with AI agent
整理与 AI 编程代理协作的实用方法，覆盖任务拆解、沟通方式、审查重点与常见误区。
本文包含如何与 AI 编程代理（如 Codex）协作的实用指南。
具体内容：
- git 仓库新建分支
- 通过 git worktree 创建工作区
- 让 Codex 在工作区里修改代码
- 提交修改并推送到远程仓库
- 用 cherry-pick 或合并文件的方式，把需要的修改拿回来
- 测试没问题后再合并到主分支
具体操作流程：
- 先查看当前仓库状态，看看当前在哪个分支，哪些文件修改了：
1
2
git status
git branch --show-current
- 先把主分支更新到最新
1
2
3
4
5
6
# 进入项目目录
cd /path/to/myproject
# 切到 main 分支。
git switch main
# 从远程仓库拉取最新的 main 分支代码，确保本地仓库是最新的。
git pull --ff-only
说明：现在很多仓库把默认主分支叫 main，但有些老仓库或者历史项目仍然叫 master。如果你的仓库默认分支不是 main，下面所有命令里的 main 都替换成你自己的主分支名即可。
- 给自己建一个分支，自己和agent都不直接在 main 上开发
1
2
3
# -c = 创建新分支
# 分支名叫 user/my-work
git switch -c user/my-work
可以这样理解：
- main：干净主线
- user/my-work：你自己的分支
- 给 ai agent 单独开一个目录和分支
1
2
3
git worktree add ../myproject-codex -b codex/task-1 main
cd ../myproject-codex
git submodule update --init --recursive
如果仓库里用了第三方子模块，创建完新的工作区之后，最好立刻执行一次 git submodule update --init --recursive，把子模块内容拉齐。否则新 worktree 里可能只有子模块目录，但没有实际文件，后续构建或运行时会报错。
具体解释：
git worktree add：添加一个新的工作区（worktree），让你可以在同一个仓库里同时有多个独立的工作目录。
../myproject-codex：新工作区的路径，这里是当前目录的上一级目录下的 myproject-codex 文件夹。
-b codex/task-1：创建并切换到一个新的分支，分支名为 codex/task-1。这个分支将基于 main 分支创建。
执行完毕后会得到：
- /path/to/myproject # 你的目录
- /path/to/myproject-codex # Codex 的目录 并且
- user/my-work 分支在 /path/to/myproject 目录
- codex/task-1 分支在 /path/to/myproject-codex 目录
这样就实现了你和 ai agent 的物理隔离，互不干扰。
- 你自己怎么工作
进入自己的工作区，正常开发：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
cd /path/to/myproject
# 看当前状态（当前在哪个分支、哪些文件修改了、哪些文件还没提交）
git status
# 看具体改了什么
git diff
# 提交修改
git add .
git commit -m "feat: add new feature"
# 可以把提交理解为“打一个存档点”
# 备份到远程仓库
git push -u origin user/my-work
# -u = --set-upstream，第一次推送时需要指定远程分支，这样以后就可以直接 git push 而不需要再指定分支了
# origin = 默认的远程仓库名字，通常指向你当前 clone 下来的那个远程仓库。可以用 git remote -v 查看实际指向。
# user/my-work = 你自己的分支
# 以后可以直接使用
git push
# 就会自动推送到 origin/user/my-work 分支
- ai agent 怎么工作
ai agent 应该只在自己的工作区里修改代码，提交修改，推送到远程仓库：
1
cd /path/to/myproject-codex
之后 ai agent 的工作和人类开发者一样，修改代码后提交：
- 查看 ai agent 的修改
直接在主目录或者 ai agent 的工作区查看修改：
1
git log --oneline codex/task-1
或者查看 ai agent 相对于 main 分支改了什么：
1
git diff main..codex/task-1
查看 ai agent 相对于你的分支改了什么：
1
git diff user/my-work..codex/task-1
具体看某个文件改了什么：
1
2
3
git diff main..codex/task-1 -- path/to/file
# 或者
git diff user/my-work..codex/task-1 -- path/to/file
备注：上述命令成立的前提是：
当前的仓库可以同时看到 user/my-work 和 codex/task-1 这两个分支的提交记录和文件修改（通过 worktree 的方式实现）。如果改成双 clone 的方式，两个仓库之间是完全隔离的，就无法直接用 git diff 来比较了。
- 把 ai agent 的修改拿回来
方式A: cherry-pick 单个提交
假设你看到 ai agent 的提交记录里有一个提交是你需要的，提交哈希是 abc123，你可以在你的工作区执行：
1
git cherry-pick abc123
它的意思是：把那个提交完整复制一份，应用到当前的分支。
方式B: 只拿某几个文件
如果你不想拿整个提交，而是只想拿某几个文件的修改，可以先切到你的分支：
1
2
git switch user/my-work
git checkout codex/task-1 -- path/to/file1 path/to/file2
意思是：从 codex/task-1 分支里把 path/to/file1 和 path/to/file2 这两个文件的修改拿过来，放到当前分支。
注意这里的 git checkout 分支 – 文件 不是切换分支，而是从指定分支取出某些文件到当前分支。git checkout 有多重含义，具体用法要看上下文，还有可能表示切换分支。
方式C: 合并分支
如果 Codex 的整个分支都很干净、就是你想要的，可以直接 merge：
1
2
git switch user/my-work
git merge codex/task-1
- 如果发生冲突怎么办
冲突的定义是：你和 ai agent 修改了同一个文件的同一行，git 就不知道应该保留哪个修改了。例如在执行 cherry-pick 或 merge 的时候，git 可能会提示：
```Auto-merging path/to/file CONFLICT (content): Merge conflict in path/to/file Automatic merge failed; fix conflicts and then commit the result.
1
2
3
4
5
这时，先看看哪个文件发生了冲突：
```bash
git status
它会提示哪些文件 both modified（双方都修改了）。打开这些文件，你会看到冲突的标记：
1
2
3
4
5
<<<<<<< HEAD
你的修改
=======
ai agent 的修改
>>>>>>> 另一侧改动来源（可能是分支名或提交 ID）
文件中的内容是git自动生成的，«««< 和 »»»> 之间的内容就是冲突的部分。你需要手动编辑这个文件，决定保留哪个修改，或者把两者的修改合并起来。
手动修改后，要手动删除这些冲突标记（«««<、=======、»»»>），确保文件内容是你想要的。修改完成后，保存文件。
修改完成后标记冲突已解决：
1
git add path/to/file
之后可以继续操作。假设之前是在执行 cherry-pick，则可以执行：
1
git cherry-pick --continue
假设之前是在执行 merge，则可以执行：
1
git commit -m "Merge codex/task-1, resolve conflicts"
如果搞不定，可以放弃这次 cherry-pick 或 merge：
1
2
3
git cherry-pick --abort
# 或者
git merge --abort
这样就能回到之前的状态，重新考虑怎么处理冲突了。
- 在解决完问题后，将自己的分支合并回 main：
1
2
3
4
git switch main
git pull --ff-only
git merge user/my-work
git push origin main
注意，上述直接 merge 到 main 的方式只适用于自己的小项目。但真实团队协作里，很多项目：
- 不允许直接推 main
- 要求 PR / MR
- 要求 main 合并前先拉最新
- 要求 fast-forward 或 squash merge
这里顺便补一下 PR（Pull Request）的原理和用法。
PR / MR 本质上不是“把代码自动合并掉”，而是“请求把一个分支的改动合并到另一个分支”。例如把 user/my-work 合并到 main。代码本身还是在 git 分支里，PR 只是托管平台（GitHub、GitLab 等）提供的一层协作界面，用来展示 diff、讨论、审查、跑 CI、最后执行 merge。
一个很常见的流程是：
1
2
3
# 先把自己的分支推上去
git switch user/my-work
git push -u origin user/my-work
然后在 GitHub 或 GitLab 上发起一个 PR / MR：
- base / target 分支选
main - compare / source 分支选
user/my-work - 填写标题和说明
- 等待代码 review 和 CI 检查
- 通过后点击 merge / squash merge / rebase merge
如果评审意见要求你继续修改，不需要新开 PR。通常直接在同一个分支继续提交，再 git push，这个 PR 就会自动更新。
如果你的团队要求“先同步主分支再合并”，可以在提交 PR 前先执行：
1
2
3
4
5
6
git switch main
git pull --ff-only
git switch user/my-work
git merge main
# 或者按团队规范使用 rebase
git push
这样 PR 里看到的就是同步过最新主线后的结果。
- 如果你需要 ai agent 接下来处理下一个任务，可以把它的分支更新到最新的 main：
1
2
3
git switch codex/task-1
git merge main
git push
或者更规范的方法。不推荐让一个 agent 分支长期反复 merge main，然后持续做很多不同任务。这样会让分支历史越来越杂。
更推荐的做法是：每个任务都新建一个分支，基于 main 创建：
1
2
3
4
5
6
7
8
9
# 删除旧的 codex/task-1 分支
git worktree remove ../myproject-codex
git branch -d codex/task-1
# 上述命令也适用于任务完成后清理旧分支
# 创建新的 codex/task-2 分支
git worktree add ../myproject-codex -b codex/task-2 main
cd ../myproject-codex
git submodule update --init --recursive
如果确实想复用现有worktree,建议：
1
2
3
4
5
cd /path/to/myproject-codex
git switch main
git pull --ff-only
git switch -c codex/task-2
# -c 表示创建新分支
“一个任务一个 agent 分支”通常比“长期维护一个 codex/task-1 分支”更干净。