AI 大改代码后怎么保证可回滚？Git 纪律在 AI 时代有什么变化？
谁在问：工程向面试官二面；出过事故的团队会问得很具体
口语化问法
- AI 一口气改了几十个文件，你怎么保证能退回去？
- 你们工具里那个 checkpoint 能不能当回滚用？
- Git 那套东西在 AI 写代码之后有什么变化吗？
考察意图
三层：
- 你知不知道会话检查点和版本控制不是一回事。这是最直接的分水岭——把 checkpoint 当回滚方案的人，一定还没被它的边界坑过。
- 你有没有意识到「原则没变、参数变了」。Git 的原则（小步、可回滚、可追溯）一条没变，但每条的合理取值都变了，因为单次改动的体量和作者的性质都变了。
- 你有没有可归因意识。事故之后能不能回答「这行是谁写的、是不是 AI 写的」，2026 年已经从洁癖变成了刚需。
参考答案
60 分答案（及格线）
每次让 AI 大改之前我会先提交一次，保证有干净的基线。改完分小步提交，别一次几百行。分支保护和 CI 该有的都有，出问题就 revert 那个提交。工具自带的 checkpoint 我也用，改错了可以退回上一步。
及格。缺的是边界：checkpoint 到底能退什么、退不了什么，一句没说；而「退不了什么」正是出事的地方。
90 分答案（有生产经验的回答）
先说清两者的分工：会话检查点用来撤销「刚才那一步说错了」，git 用来撤销「这个方向整个错了」。它们不能互换，官方文档里也明写着检查点不是版本控制的替代。具体差在哪：
能力 会话检查点 git 恢复模型直接改的文件 恢复 shell 命令改的文件（ rm/mv/代码生成器）不追踪 恢复后台子 agent 的编辑 不恢复 保留期 典型上限 100 个、随会话 30 天清 永久 跨机器 / 跨人可见 最容易吃亏的是第二三行：一旦 agent 用 shell 跑了个脚本批量改文件，或者派了个后台子任务去改，检查点就退不回来了——而这两种恰恰是大改动最常用的方式。所以我的规矩很简单：异步派活之前必须先 commit 一次，这一步只花五秒，但它是唯一可靠的那道闸。
再说 Git 纪律变了什么——原则没变，参数变了：
- 提交粒度要更小。因为 AI 单次改动面更大：有统计显示 AI 辅助 PR 的 75 分位体积约 400 行，非 AI 约 157 行。一次三百行的提交，回滚时你只能全退，连带把对的部分一起退掉。判据是「一次提交对应一个可独立回滚的意图」，而不是「AI 干完这一轮」。
- 提交信息的重心从「改了什么」移到「为什么这么改」。改了什么 diff 里有；为什么只有当时的人知道——而现在这个「人」有一半是 AI，如果不写下来，三个月后没人能重建当时的判断。
- 署名 trailer 值得加，但价值不在你以为的地方。它的真实价值是事后可归因：某高校团队 2026 年扫了四万多条安全公告，确认出 74 例由 AI 生成代码引入的真实 CVE，靠的就是提交元数据里的署名。局限也在这——删掉署名就漏检，所以那个数字是系统性低估，研究者自己估计真实数是确认数的 5 到 10 倍。这也意味着：署名是团队自愿的追溯机制，不是可靠的审计手段。
- 并行开发用 worktree 隔离，但要知道代价：worktree 之间不共享提示缓存，并行省的是人的时间，花的是钱。
追问链
五层追同一条边界：checkpoint 退得回什么、退不回什么
既然有 checkpoint，为什么还要频繁 commit？
期望三个覆盖不到的场景：shell 命令改的文件（rm/mv/代码生成器）、后台子 agent 的编辑、跨会话/跨机器/跨人。再补一条：检查点是会话内线性的，同一会话干了两件不相关的事，退回去会两件一起退；git 能精确挑一个提交回滚信号具体说出「shell 改的文件不追踪」→ 真读过文档或踩过；只说「checkpoint 不太可靠」→ 听来的AI 一轮就改了三百行，你怎么切提交？
期望不按 AI 的节奏切，按意图切：改完先别提交，自己过一遍 diff，按「可独立回滚的意图」分组（重构接口 / 补幂等 / 补测试）分别 stage。切不开说明任务本身就该拆——回到规格那步拆细，而不是在提交环节硬切；超过 200 行强制拆 PR，是控评审成本最便宜的一刀信号答「AI 改完整体提一个，反正有 PR」→ 没有回滚粒度概念；说「切不开说明任务该拆」→ 把回滚问题推回了规格提交信息让 AI 写行不行？
期望能写「改了什么」，写不了「为什么」——「为什么」里含的是它不知道的东西：线上现状、历史包袱、这次为什么选 A 不选 B。做法是它起草描述、人补一句决策理由。全自动生成的读着通顺但全是 diff 的复述，提交历史一旦全是复述，代码考古就废了信号答「让它写挺好，省事」→ 团队的提交历史大概率已经没价值；能分「描述可代笔、理由不可代笔」→ 做过代码考古署名 trailer 到底有没有用？有人觉得是形式主义。
期望两面讲。有用：事后归因的唯一低成本抓手——公开研究就是靠提交元数据确认了 74 例 AI 引入的真实 CVE。不可靠：删掉署名就漏检，只能做趋势观察，不能做合规审计。组织立场也分裂：有的强制标注工具名、有的要求标注并声明作者负全责、也有基金会明确不强制信号只说「有用」或「形式主义」→ 都是单面；说出「不同组织立场分裂，取决于你在防什么」→ 高一档线上事故要回滚，改动分散在 6 个已合并且互相依赖的 PR 里，怎么退？
期望① 先止血再求净——关入口（开关降级、切流量、限流）秒级，回滚分钟级 → ② 固定一个变量一分为二：同一组输入回滚前后各跑一遍，没变就是流量/配置侧的病，回了白回 → ③ 能前滚就别回滚，判据是可不可逆：写库、发消息、扣款的 PR 不能简单 revert → ④ 真要退按依赖倒序、逐个跑判据 → ⑤ 复盘落到回滚闸：高风险配开关、不可逆操作单独成 PR信号上来就讲git revert -m→ 视角停在工具层；先说「关开关止血」→ 真值过班
前四层还在比习惯：检查点的边界、切提交的粒度、署名的两面。第 5 层才见真章 —— 考的不是 git 命令，是「先关开关止血、再判改动可不可逆」的止损顺序。
评分要点
- 说得清检查点与 git 的分工，并至少举出两条检查点覆盖不到的场景
- 有「异步派活前先 commit」这类具体、便宜、可执行的习惯
- 提交粒度以可独立回滚的意图为判据，而不是以 AI 的轮次为界
- 说得出提交信息重心的变化（从「改了什么」到「为什么」）
- 对署名 trailer 能给出双面评价（可归因 / 删掉就漏检）
- 知道 worktree 并行的代价（不共享提示缓存）
- 事故场景下先止血后回滚，并能判断改动是否可逆
- 会用「固定住一个变量把问题一分为二」确认归因，而不是直接回滚碰运气
常见错误
「有 checkpoint 就够了」没踩过 shell 改文件、后台子 agent 的坑
「AI 改完整体提一个大 commit，PR 里能看」没有回滚粒度概念，事故时只能全退
提交信息全由 AI 生成且只复述 diff提交历史失去信息量，代码考古能力归零
「署名是形式主义」或「署名能做审计」两个方向的极端，都没理解它的能力边界
事故第一反应是回滚代码缺止血意识，秒级手段没用上
六个 PR 一起 revert不区分改动是否可逆，可能造成二次事故
「回滚完再看是不是这批改动引起的」顺序反了，可能回滚了无关代码还找不到真因
「我们分支保护做得很好」——但说不出单 PR 体积限制有形式没有关键参数