首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >AI 写代码的 Git 用法,和人类完全不一样——checkpoint 策略三原则

AI 写代码的 Git 用法,和人类完全不一样——checkpoint 策略三原则

原创
作者头像
用户12475538
发布2026-05-11 13:13:55
发布2026-05-11 13:13:55
1030
举报
文章被收录于专栏:与workbuddy合作与workbuddy合作

AI 写代码的 Git 用法,和人类完全不一样——checkpoint 策略三原则

你的 Git 工作流是为自己设计的:写 30 分钟,commit 一次。AI 帮你写代码后,这个节奏全乱了——你可能需要每 3 分钟 commit 一次。


一个后悔的时刻

AI 帮我把一个模块的认证逻辑从 session 改成 JWT。它在 6 个文件里改了约 200 行。我 review 了一遍,看起来没问题。

5 分钟后我发现有个文件的改动把另一个功能的逻辑破坏了。我想回退——但我没有在"AI 动手之前"做 commit。我只有一个超大的 commit,混合了 6 个文件的改动和我在那之前的修改。

回退意味着要么丢 AI 的改动(然后手动重做),要么丢我自己的改动(然后手动重做)。 我蹲在那里骂了 10 分钟,最后手动一行行修。

从那以后,我有一个铁律:AI 每动手一次,我就在它动手前 commit 一次。


原则一:AI 动手前 = commit checkpoint

代码语言:python
复制
# ❌ 旧节奏(为自己设计的)
写代码 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 需要更细——一个"可回退单元"。

什么叫可回退单元?撤掉它,不丢你的改动,不丢上下文。


原则二:用前缀区分"你的"和"AI 的"commit

代码语言:python
复制
# 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,你想全部回退。

代码语言:bash
复制
# 有前缀区分 → 批量操作
git revert def5678 ghi9012 mno7890
# 三个命令,10 秒搞定

# 没有前缀区分 → 手动找
git log --oneline | grep -i "jwt\|认证"  # 可能漏掉
# 手动判断每个 commit 是谁写的 → 容易出错

"ai:" 前缀不只是标签——它是批量操作句柄。


原则三:AI 改动量大时,先 branch 再动手

AI 不只是改文件——它有时候会改你的项目结构、重命名整个模块、在多个文件之间移动代码。

这种级别的改动,在 master 上做是危险的。即使你有细粒度 commit,回退 10 个 commit 也让人焦虑。

代码语言:python
复制
# ✅ 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 做大胆改动时不需要那么紧张。

什么算"大改动"

代码语言:python
复制
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 命令回退干净,就开新分支。


完整工作流

把三个原则拼起来:

代码语言:python
复制
# ===========================================
# 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 里记"为什么让 AI 改"

代码语言:python
复制
# ❌ 无用的 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 改这个、改了什么范围、怎么验证的。 这三条信息,三个月后你不会记得。


Git 工具之外的收获

这套 checkpoint 策略做了一件事:把 AI 的改动从"它帮我写的"变成"一个可审计、可回退、可理解的独立单元"。

这让我从一个焦虑的 AI 监护人("它改了什么?有没有搞坏别的?")变成一个从容的代码审查者("这次的 commit 就改了 API 层,看一眼就行")。

恐惧来自不可控。checkpoint 让一切可控。


本文所有示例均已脱敏处理。你让 AI 改代码前会先 commit 吗?有没有不 commit 直接让它动手然后后悔的经历?评论区聊聊。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • AI 写代码的 Git 用法,和人类完全不一样——checkpoint 策略三原则
    • 一个后悔的时刻
    • 原则一:AI 动手前 = commit checkpoint
    • 原则二:用前缀区分"你的"和"AI 的"commit
    • 原则三:AI 改动量大时,先 branch 再动手
      • 什么算"大改动"
    • 完整工作流
    • 最容易被忽略的:commit message 里记"为什么让 AI 改"
    • Git 工具之外的收获
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档