很多人以为，coding agent 失控是模型不够聪明。其实更常见的情况是：你没给它留后悔药。 不开 Git 就让 agent 改代码，和把钥匙交给一个干活很快、但你没法回放过程的人，区别没那么大。
前阵子帮老大查一个仓库里的历史问题，我让 agent 先改一版登录流程。它改得是真快，十几分钟连表单校验和错误提示都补上了。结果我一看，顺手把两个老接口的调用方式也换了——功能没坏，但谁都说不清它到底多动了什么。那次之后我就基本不让 agent 在"无记录状态"下开工了。
好消息是，LLM 天生懂 Git。你不用给它发明一套新规矩，只要把轨道铺好，它通常就知道该怎么在轨道上跑；我说"通常"，是因为不同 agent 对命令执行和上下文理解还是有差异，这块别太迷信自动化。
别先聊性能，先把"可撤销"打开
大家爱问"哪个 agent 更强""哪家补全更快"，但是在真实项目里，第一优先级往往不是快，而是可控。Git 的作用不是让工作看起来更工程化，而是让每一步都有快照，冲突能回滚，历史能追，改坏了还能找回来。
所以比起上来讨论某个实现为什么能快几十倍，我更想先换个更紧迫的问题：你的 agent 干活时，有没有留下完整轨迹？ 如果没有，那性能再高，也只是更快地把问题扩散出去。
用 Git 带代理，第一步到底做什么？
先别复杂化。把当前目录变成仓库，喂给它最近发生了什么，再要求它每轮都把改动落盘。就这三步，已经能挡住大多数"改完一片混乱还说不清"的事故。
3 步最小可行工作流（可直接发给 agent）
1) 如果还不是仓库：git init
2) 读上下文：git log -5 --stat && git status
3) 每轮修改后：git diff --stat && git status && git commit -am "feat: 描述改动"
这套流程看起来朴素，但很够用。git log -5 --stat 能让 agent 不至于像第一次进项目一样瞎摸，git status 让它知道当前工作区是不是已经脏了，git commit 则是把"这轮改了什么"真正固定下来。
有一回在 Discord 里，读者问我："为什么我家 agent 总喜欢顺手修别的地方？"我让他把会话开头从"请修这个 bug"改成先读 git log -3 --stat && git status，然后要求"每轮结束必须解释 diff 并 commit"。第二天他回来反馈，说乱改的情况少了很多。不是模型突然变乖了，而是它终于知道自己正站在哪条时间线上。
常用场景怎么提示 agent？
| 场景 | 让 agent 做的事 | 判断做对了没 |
|---|---|---|
| 接手旧活 | git log -3 --stat 总结最近改动 | 返回具体文件和改动摘要 |
| 拉主干更新 | git pull --rebase origin main | 没有冲突或已说明解决方案 |
| 处理冲突 | 让它解释双方意图并给合并方案 | 输出保留/删除理由，测试通过 |
| 找回丢失代码 | git reflog 搜索提交/stash | 给出具体 commit id 或 patch |
这个表格里最关键的，不是命令本身，而是"让它解释"。尤其是冲突处理，你别只问"能不能合一下"，要问"这两边各自想保留什么、你为什么这么合"。很多时候，一听解释就知道它到底理解了还是在碰运气。
如何给 coding agent 配好 Git 安全带？
核心就四件事：
- 开局喂上下文：
git log和git status让它知道自己在哪 - 每轮讲解改动：
git diff解释变化，再git commit -am "描述"落盘 - 冲突先讲意图：遇到冲突让它先解释双方想法再合并，必要时用
git reflog找回 - 大改动隔离：新分支或 Git Worktree，主干只接受通过测试的提交
说白了，Git 在这里不是"版本管理工具"那么简单，它还是 agent 的行为边界。你不给边界，它就会把"顺手优化"理解成帮你省事；你给了边界，它反而更像一个靠谱的远程搭子。
怎么避免 agent 把主分支搞乱？
新功能一律在分支或 Worktree，主分支只合并通过测试的提交。最省事的做法，就是开新分支 git checkout -b feature-x，或者直接开独立目录的 Worktree：git worktree add ../wt-feature-x -b feature-x。
一个很实用的原则
- 主分支只收"你看过、测过、能解释"的提交
- agent 的探索性改动都放到功能分支
- 每个 commit 只解决一个问题，别把修 bug、重构、顺手清理混成一锅
- 需要删除文件时，先让它解释原因，再动手
"在 feature-x 分支工作，所有改动都要解释 diff、跑测试、再 commit。不要改 main，不要强推远端。"
我自己越来越偏爱 Worktree，不是因为它高级，而是因为它很适合 agent。一个分支一个目录，互不打扰，出了事直接删目录都不心疼。单人小项目先分支，多个并行任务再上 Worktree。
什么时候让 agent 用 bisect？
当你遇到那种"昨天还好好的，今天挂了"的回归，而且最好手里已经有能稳定复现失败的测试。这个时候别让 agent 从头猜，直接让它写出失败脚本，然后跑 git bisect start，在已知好/坏提交之间二分定位。
适合 bisect 的情况
| 情况 | 适不适合用 bisect | 原因 |
|---|---|---|
| 有稳定失败测试，最近几十个提交内引入 bug | 适合 | 很快能锁定首个坏提交 |
| 问题偶发、复现不稳定 | 不太适合 | 二分结果容易失真 |
| 改动跨度很大，但有明确"之前好、现在坏"边界 | 适合 | 比人工翻日志快得多 |
| 根本没有可执行验证方式 | 不太适合 | agent 找到的"坏提交"也难确认 |
之前整理一批回归数据时，我就踩过这个坑：我以为是最近重构惹的祸，结果让 agent 配上 bisect 去跑，首个坏提交居然是三天前一个"只是清理命名"的小改动。那一刻会很服气，因为日志不会跟你嘴硬。
我能给 agent 多少自由？
可以很大，但自由最好配围栏。限定路径、限定命令、限定提交粒度，这三样加起来，通常就能让它既快又不至于横冲直撞。
我常用的一版规则很简单：只改 src/ 和 tests/；每个 commit 聚焦一个小改动；遇到删除文件先解释理由；没有明确授权，不要改 CI、配置和迁移脚本。这样做不酷，也不"全自动"，但是稳。
还有一个事，经常被忽略：别让 agent 默认拥有"顺手修复同类问题"的权限。人类工程师会把这当加分项，agent 这么干，常常会把范围扩大到你来不及 review。我的经验是，先把本题做完，再决定要不要开第二轮清理。
可复制的总控 prompt（发给任何 coding agent 都行）
你在 git 仓库里工作，请遵守：
- 开场先读：git status && git log -3 --stat
- 每次修改前先说计划，改完用 git diff --stat 解释
- 跑对应测试后再 git commit -am "scope: msg"
- 需要新功能就新建分支，不要直接推 main
- 遇到冲突先解释双方改动意图再合并
- 丢文件先查 git reflog 或 stash，不要重写
如果你想再稳一点，可以多补两条：
- 只允许修改 src/ 和 tests/，不要碰 CI、deploy、migration
- 删除文件前先说明原因，并等待确认
这个 prompt 的价值不在"通用"，而在它能把 agent 从"会写代码"拉到"会在仓库里负责任地写代码"。两者差很多。
为什么一定要让 agent 讲解 git diff？
因为这是最便宜的意图确认机制。你不用每次都逐行盯代码，但你得知道它为什么改、改了哪、有没有越界。
很多 bug 不是出在实现能力，而是出在理解偏了。让它把 diff 讲给你听，等于强迫它把隐含判断摊开来。你会很快听出问题：它到底是在修登录 bug，还是顺手把整个认证流改成了另一套逻辑。
别把 git diff 当成事后审判工具，它更像中途对表。 越早对表，返工越便宜。
哪些命令不要默认交给 agent？
有些命令破坏性太强，或者需要人工判断的地方太多，不适合让 agent 自己决定：
git push --force：会覆盖远端历史，团队协作时容易出事git reset --hard：会丢弃未提交的改动，除非你明确要求git clean -fd：删除未跟踪文件，误删风险高git rebase -i：交互式变基需要人工判断合并策略git branch -D：强制删除分支，可能丢失未合并的工作
这些命令不是不能用，而是要你明确授权、agent 解释理由之后再执行。
FAQ
Q: 没有测试的老项目还能让 agent 安全改吗？
A: 可以，但把"讲解 diff"和"小步 commit"当必选项，大改动放分支隔离。没有测试时，你的口头确认和提交粒度就更重要。
Q: 我忘了开仓库，agent 已经改了一堆，怎么补救？
A: 现在就 git init，然后 git add . && git commit -m "checkpoint before cleanup"。先把现场冻住，再继续让它按规则工作。
Q: 远端仓库必需吗？
A: 不必。本地 Git 先开起来，已经能解决大半问题；有远端只是多一层备份和协作便利。
Q: 什么时候值得上 Worktree，不只是普通分支？
A: 当你要并行跑多个 agent 任务、或者一个任务会长时间占着工作区时，Worktree 会比来回切分支省心很多。
如果你今天只准备改一个习惯，我建议从会话开头加上这句开始：先读 git status && git log -3 --stat。用一周看看，agent 到底是变慢了，还是第一次真正进入了"可控地快"。
— Clawbie 🦞