怎么让 AI Agent 不把仓库改坏
AI agent 最大的价值，是它能进入真实仓库完成工作。它会读文件、改文件、跑命令、根据失败继续修。它最大的风险，也正是它能进入真实仓库完成工作。
如果没有边界，agent 可能把无关文件一起改了，可能回退别人的未提交改动，可能执行一个看似清理环境但实际删除数据的命令，也可能在主分支上留下一个难以解释的混合 diff。
让 AI 不把仓库改坏，不是靠提醒它“仔细一点”。要靠流程和权限。
先看工作区，不要一上来就改
每次让 agent 动手前，都应该先看工作区状态：
git status
git diff --stat
这一步不是形式。它能回答几个很重要的问题：
- 当前是不是在正确分支。
- 有没有未提交文件。
- 这些改动是不是本次任务相关。
- 有没有生成文件、配置文件、锁文件已经变化。
- 有没有其他人或其他 agent 正在同一个目录工作。
如果工作区已经脏了，不要让 AI 直接“清理一下”。清理可能意味着删除你还没保存的东西。更稳的做法是确认哪些改动属于谁，当前任务是否应该换到新分支或新 worktree 里做。
分支解决版本边界，worktree 解决目录边界
分支是最低要求。真实项目里，agent 不应该直接在 main 或长期开发分支上自由修改。
但在多人、多 agent、多个任务并行时，单纯分支还不够。因为同一个工作目录里仍然可能有未提交文件、构建产物、本地配置和其他任务的临时改动。
这时 git worktree 很有用。它可以从同一个仓库创建一个新的工作目录，让 agent 在隔离目录里做任务：
git worktree add ../repo-task-fix origin/main -b fix/user-export-permission
这样可以把风险隔离在目录层面：
- 当前任务有自己的文件系统视图。
- 不会覆盖原目录里的未提交改动。
- diff 更容易审查。
- 做错了可以删除整个 worktree，而不是清理一个混乱工作区。
不是每个小任务都必须开 worktree。改一篇文章、修一个局部测试，在干净分支上也可以。但只要仓库脏、任务风险高、多人并行，worktree 就比“相信 agent 不会碰错”可靠。
不要让 agent 自动回退未知改动
最危险的命令不一定看起来危险。
例如：
git checkout -- .
git restore .
git reset --hard
这些命令常被用来“恢复干净”。但如果工作区里有你、同事或其他 agent 的未提交改动，它们就会直接把这些改动丢掉。
所以规则应该很明确：agent 不能回退它没有创建、也没有被明确授权回退的文件。
如果它发现无关改动，正确行为是报告：
工作区里有这些与任务无关的修改：
- ...
我会忽略它们，只改本次任务文件。
这条规则看起来保守，但在真实仓库里非常重要。很多事故不是 AI 写错逻辑，而是它为了“整理环境”把别人的工作清掉了。
权限审批要按破坏性分级
不是所有命令都应该同等对待。
通常可以允许 agent 自己运行的命令包括：
rg、ls、sed这类读取命令。git status、git diff这类状态命令。- 项目约定的测试、构建、lint 命令。
需要确认的命令包括：
- 删除文件或目录。
- 重写 Git 历史。
- 强推远程分支。
- 删除 Docker volume、数据库、缓存数据。
- 安装未知脚本或全局工具。
- 修改生产环境配置。
- 上传日志、数据库 dump 或包含密钥的文件。
判断标准很直接：如果命令执行错了，会不会丢数据、丢提交、影响别人、影响生产环境？如果会，就必须停下来确认。
这不是不信任 AI，而是把操作风险和读写风险分开。读代码和删数据不应该共用同一套默认权限。
测试要匹配风险，不要只跑最快的
agent 很容易倾向于跑最快、最容易成功的检查。比如只跑格式化，或者只跑一个类型检查，然后说“验证通过”。
真实项目里，验证强度要和风险匹配：
- 文档和文章：构建或 MDX 编译通常就够。
- UI 展示：组件测试、页面构建、必要时打开页面看。
- 业务逻辑：相关单元测试和集成测试。
- 权限和认证：至少覆盖允许、拒绝、缺失绑定、越权访问。
- 缓存和刷新：验证 mutation 后读路径是否拿到新数据。
- 数据迁移：本地迁移、回滚路径、幂等性检查。
如果测试跑不了，也要让 agent 明确说明原因。不能把“没有运行”包装成“应该没问题”。
用 diff 管住任务范围
最后一定要看 diff。
重点不是每一行都要吹毛求疵，而是先判断范围有没有失控：
- 是否只改了允许修改的文件。
- 是否新增了没必要的依赖。
- 是否混入格式化大改。
- 是否改了锁文件、配置文件、生成文件。
- 是否把本地路径、密钥、调试日志写进去了。
- 是否删掉了测试或弱化了校验。
如果 diff 大到看不完，不要硬合并。让 agent 拆任务，或者先把不相关改动剥离出去。
关于合并前具体看什么，可以继续读：AI 代码 review 在合并前该看什么。
一套实际规则
我更推荐把规则写成短清单，而不是每次临时提醒：
- 开始前必须报告
git status。 - 默认不在主分支改代码。
- 脏工作区或并行任务使用新 worktree。
- 只修改任务范围内文件。
- 不回退未知改动。
- 破坏性命令必须确认。
- 验证命令要和风险匹配。
- 交付时列出改动文件、验证结果和未覆盖风险。
这套规则不会让 AI 变慢太多，但会大幅降低不可逆错误。
如果任务本身还没说清楚，先看：真实项目里的 AI 上下文工程。上下文不清楚时，仓库安全规则只能减少损失，不能保证方向正确。
结论
AI agent 不会因为能力强就自动安全。它越能执行真实命令，越需要真实的工程护栏。
分支和 worktree 隔离工作，权限审批控制危险操作，测试验证行为，diff 暴露事实，脏工作区规则保护别人的改动。
做到这些，agent 才适合进入真实仓库。否则，它只是一个修改速度很快、但边界不清楚的自动化入口。