你的 Git 工作流是为自己设计的:写 30 分钟,commit 一次。AI 帮你写代码后,这个节奏全乱了——你可能需要每 3 分钟 commit 一次。
AI 帮我把一个模块的认证逻辑从 session 改成 JWT。它在 6 个文件里改了约 200 行。我 review 了一遍,看起来没问题。
5 分钟后我发现有个文件的改动把另一个功能的逻辑破坏了。我想回退——但我没有在"AI 动手之前"做 commit。我只有一个超大的 commit,混合了 6 个文件的改动和我在那之前的修改。
回退意味着要么丢 AI 的改动(然后手动重做),要么丢我自己的改动(然后手动重做)。 我蹲在那里骂了 10 分钟,最后手动一行行修。
从那以后,我有一个铁律:AI 每动手一次,我就在它动手前 commit 一次。
# ❌ 旧节奏(为自己设计的)
写代码 30 分钟 → commit "WIP: 用户模块重构"
写代码 30 分钟 → commit "WIP: 继续重构"
让 AI 改 6 个文件 → ...没有 commit,因为"一会儿还要继续"
# 出问题 → 无法回退
# ✅ 新节奏(为 AI 协作设计的)
写代码 30 分钟 → commit "feat: 用户模块基础结构" # 你自己的 checkpoint
让 AI 改 API 层 → commit "ai: JWT 认证 - API 层" # AI 的 checkpoint
让 AI 改服务层 → commit "ai: JWT 认证 - 服务层" # AI 的 checkpoint
让 AI 改测试 → commit "ai: JWT 认证 - 测试更新" # AI 的 checkpoint
# 任何时候发现 AI 的改动有问题 → git revert <ai-commit>核心区别:commit 的粒度变了。 人类写的 commit 通常是一个"逻辑单元"(一个功能、一个修复)。AI 协作的 commit 需要更细——一个"可回退单元"。
什么叫可回退单元?撤掉它,不丢你的改动,不丢上下文。
# commit 命名约定
你自己写的: "feat: xxx" / "fix: xxx" / "refactor: xxx"
AI 帮你写的: "ai: xxx" (统一前缀)
# 为什么需要区分?
git log --oneline
abc1234 fix: 修复登录页面样式
def5678 ai: JWT 认证 - 中间件更新
ghi9012 ai: JWT 认证 - 错误处理
jkl3456 feat: 添加用户搜索功能
mno7890 ai: JWT 认证 - 测试修复
pqr1234 refactor: 重构数据库连接池
# 一眼看出:3 个 commit 是 AI 的(可以集体 revert)
# 3 个是你自己的场景:AI 在"JWT 认证"三个 commit 里引入了 bug,你想全部回退。
# 有前缀区分 → 批量操作
git revert def5678 ghi9012 mno7890
# 三个命令,10 秒搞定
# 没有前缀区分 → 手动找
git log --oneline | grep -i "jwt\|认证" # 可能漏掉
# 手动判断每个 commit 是谁写的 → 容易出错"ai:" 前缀不只是标签——它是批量操作句柄。
AI 不只是改文件——它有时候会改你的项目结构、重命名整个模块、在多个文件之间移动代码。
这种级别的改动,在 master 上做是危险的。即使你有细粒度 commit,回退 10 个 commit 也让人焦虑。
# ✅ AI 做大改动前的标准流程
git checkout -b ai/refactor-user-module # 1. 开新分支
# 让 AI 在这个分支上随便改
git checkout master # 2. 随时可以切回主分支
# review AI 的改动
git diff master...ai/refactor-user-module # 3. 看所有改动
# 确认没问题
git checkout master
git merge ai/refactor-user-module # 4. 合并
git branch -d ai/refactor-user-module # 5. 删除分支分支给了你一个"随时可以扔掉整个 AI 改动"的安全网。 这让你在让 AI 做大胆改动时不需要那么紧张。
def needs_branch(task):
if task.files_to_modify > 5:
return True
if task.lines_to_change > 300:
return True
if task.renames_modules:
return True
if task.moves_code_between_files:
return True
if "重构" in task.description or "refactor" in task.description:
return True
return False一句话:如果不能 2 个 revert 命令回退干净,就开新分支。
把三个原则拼起来:
# ===========================================
# AI 协作的 Git 工作流
# ===========================================
# 1. AI 动手前 → commit 你的当前状态
git add -A
git commit -m "checkpoint: AI 修改前的状态"
# 2. 判断改动规模
if task_to_give_to_ai.is_large():
git checkout -b "ai/$task_name"
# 3. 每次 AI 完成一个独立改动 → commit
# (不是等 AI 做完所有事再 commit)
# AI 改完了 API 层
git add src/api/
git commit -m "ai: $task_name - API 层"
# AI 改完了服务层
git add src/services/
git commit -m "ai: $task_name - 服务层"
# AI 改完了测试
git add tests/
git commit -m "ai: $task_name - 测试更新"
# 4. 验证 → 合并或回退
if ai_changes_are_good():
git checkout master
git merge "ai/$task_name"
else:
# 回退某个具体 AI commit
git revert <bad-ai-commit>
# 或者扔掉整个分支
git checkout master
git branch -D "ai/$task_name"# ❌ 无用的 commit message
git commit -m "ai: 更新"
# ✅ 有用的 commit message
git commit -m "ai: JWT 认证重构 - 替换所有 session 逻辑
原因:session 在负载均衡下不稳定
AI 改了什么:src/auth/middleware.py, src/auth/tokens.py
AI 没改什么:数据库 schema、前端 cookie 逻辑
验证方式:跑 test_auth.py 全部通过"三个月后你回看这个 commit,能知道:为什么当时要让 AI 改这个、改了什么范围、怎么验证的。 这三条信息,三个月后你不会记得。
这套 checkpoint 策略做了一件事:把 AI 的改动从"它帮我写的"变成"一个可审计、可回退、可理解的独立单元"。
这让我从一个焦虑的 AI 监护人("它改了什么?有没有搞坏别的?")变成一个从容的代码审查者("这次的 commit 就改了 API 层,看一眼就行")。
恐惧来自不可控。checkpoint 让一切可控。
本文所有示例均已脱敏处理。你让 AI 改代码前会先 commit 吗?有没有不 commit 直接让它动手然后后悔的经历?评论区聊聊。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。