AI 生成代码时代的版本管理：回滚、评审与提交策略

变化的本质：代码产出的「规模与速度」冲击了 git 的默认假设

git 的工作流默认假设是「人类以人类的速度产出人类规模的改动」——AI 编程打破了这个假设：一次 Agent 会话改 20 个文件、一天产出过去一周的 diff、以及「生成的代码连作者都未必逐行看过」。三个被冲击的环节。提交粒度：AI 的改动是「任务级」的（一个任务跨多文件多类型），git 的原子提交假设（一次提交一件事）在「AI 一次干了一摊」面前失效。评审带宽：diff 的增长速度超过人的阅读速度（逐行评审 AI 的千行 diff 在物理上不可持续）。回滚需求：AI 犯错的模式是「大而快的错」（一大批改动方向错了）——粗粒度的快速回滚能力从「偶尔需要」变成「日常必需」。版本管理需要一套针对性的改造。

提交策略：任务级提交、AI 分支与信息规范

提交策略的三条改造。改造一：任务级的提交粒度。AI 完成一个任务 = 一个提交（或一个 PR）——以「任务的验收」为提交的原子单位（而非「文件的改动」）；提交前的人工动作：跑测试 + 快速扫 diff（重点看「AI 改了它不该碰的地方吗」——本库 AI 代码评审篇的审查清单）。改造二：AI 改动的隔离分支。AI 的工作放在独立分支（或独立 worktree——本库 worktree 篇），主干只接收「经人评审的合并」——「AI 直接推主干」是团队规范的崩塌点，隔离分支让主干永远是人类把关后的状态。改造三：提交信息的 AI 署名与规范。提交信息标注 AI 参与（工具、模型、任务上下文——本库开源治理篇的 AI 贡献署名议题在团队实践层的落法）、以及提交信息里写「验收方式」（这个改动是怎么被验证的——跑过什么测试、人工查了什么——为未来的审计留痕）。git 的"作者"字段与工具治理：AI 生成的提交用 co-author 标注或专门的署名规范——团队需要对「AI 改动占比」有可查询的账（哪些代码是 AI 写的、谁验收的——出问题时的责任链与改进依据）。

评审策略：分流、聚焦与「不可逐行」的现实

评审策略要接受「不可逐行」的现实，转向分流与聚焦。分流的第一原则：按风险分层。高风险代码（安全边界、资金逻辑、数据删除、并发）——逐行人工评审，不接受 AI-only；中风险（业务逻辑的功能代码）——AI 辅助评审 + 人类重点抽查（逻辑正确性、边界条件）；低风险（样式、文档、测试的机械补充、样板代码）——快速扫描或信任 CI（测试覆盖下的低风险改动让机器守门）。聚焦的评审技巧：评审「意图与实现的偏差」而非「每行代码」（AI 的代码语法层面几乎总是对的，风险在「它理解的需求」与「真实需求」的偏差——先看任务规格再看 diff，找「方向性错误」）；评审「AI 的越界」（改了任务外的文件、引入了计划外的依赖、动了配置——越界是 AI 改动的头号风险模式）；用工具放大评审（AI 辅助评审工具处理初筛——本库 AI 代码评审篇，人做终审）。评审的效率真相：AI 时代的评审重心从「逐行正确性」转向「系统级正确性」——测试的完备性、架构的合理性、安全边界——这些恰恰是人类的判断力不可替代的部分。

回滚设计：AI 时代的护栏工程

回滚是 AI 时代的核心护栏，设计要前置。护栏一：改动前的快照习惯。让 AI 动手前确保工作区干净（全部提交或 stash）——「AI 动手前的干净基线」是回滚的锚点（Cursor/Cline 的检查点机制是产品化实现，git 是通用底座）。护栏二：小步提交 + 分支隔离。AI 的长任务拆成多个里程碑提交（每完成一个可验证的步骤就提交）——回滚的粒度由提交粒度决定（一次性的大提交让回滚变成「全有或全无」）；AI 工作在隔离分支（本库 worktree 篇），主干永远有「已知良好」的回退点。护栏三：生产级的回滚预案。AI 生成的代码上线后发现问题——部署层的回滚（上一版本的镜像/发布）要比代码层回滚更快（生产的止损先于代码的修复）、以及数据层的警惕（AI 写的迁移脚本跑坏了数据——代码可以回滚，数据回滚贵十倍——迁移脚本的人工评审与备份前置是不可妥协项）。护栏四：可观测的异常检测。AI 代码上线后的监控密度要高于人工代码（错误率、性能指标的告警阈值更紧——AI 的错误模式与人类不同，监控的敏感度要按「新代码占比」调节）。回滚设计的哲学：回滚不是失败，是 AI 时代的日常操作——把「快速安全地撤销」设计成一等公民，才能放心地享受 AI 的产出速度。

AI 代码的评审实战：一套可操作的检查清单

AI 代码评审（正文策略）的实战：一套可操作的检查清单，评审 AI 生成代码时的逐项对照。第一组：越界检查（AI 改动的头号风险）。改了任务外的文件吗（diff 的文件清单 vs 任务范围）、引入了计划外依赖吗（package.json 的变化——依赖变更必须单独确认）、动了配置与基础设施吗（.env、部署配置、权限文件）。第二组：逻辑与需求偏差。实现与需求的一致性（先读任务规格再看 diff——本库正文的意图偏差原则）、边界条件（空输入、极端值、并发）、错误处理的覆盖（AI 常写「happy path 完整、异常路径草率」——异常与失败分支重点看）。第三组：安全红线（本库安全篇）。输入校验、认证授权、硬编码的密钥与敏感信息（AI 偶尔会把示例密钥留在代码里）、SQL 注入与 XSS 的老三样。第四组：工程质量。与现有代码的风格一致性（本库 Rules 工程的产出）、测试的覆盖（AI 写了实现但测试够吗）、以及「过时的引用」（AI 引用了废弃的 API 或过时的库版本——知识截止的痕迹）。清单的使用方式：按风险分流（本库正文的高中低风险分层）选用子集——高风险全查、低风险抽查——清单的电子化进 PR 模板（AI PR 的评审 checklist 自动附上），让清单成为流程而非记忆。

AI 代码的度量：团队的「AI 占比」与质量仪表盘

AI 代码（正文署名议题）的度量：团队的「AI 占比」与质量仪表盘。度量的维度。产出占比：AI 生成的代码行数/提交数占比（co-author 标注与工具日志的统计——本库署名规范的数据来源）、验收效率：AI PR 的评审时长与一次通过率（与人类 PR 对比——评审负担的真实数据）、质量指标：AI 代码的缺陷密度、回滚率（与人类代码对比——「AI 代码更差吗」用数据回答而非印象）。仪表盘的价值场景。策略的校准（AI 用在哪些任务类的「一次通过率」高——按任务类型优化 AI 的使用分配）、风险的监控（某类 AI 改动的回滚率异常——定位到具体的提示词或任务模式）、以及向管理层的汇报（AI 的真实产出与质量——用数据管理期望，避免「AI 万能」或「AI 不行」的两个极端叙事）。度量的注意事项：行数不是价值（AI 的代码行密度与人类不同——按「任务完成数」度量比按行数诚实）、以及度量的目的校准（度量是为了优化协作，不是为了考核淘汰——把 AI 占比当 KPI 考核，会催生虚假标注——度量伦理的提醒）。这一节的收束：AI 代码的度量，是团队从「感觉 AI 变强了」到「知道 AI 在哪些任务上能托付」的认知基建——仪表盘不是给老板看的，是给团队自己校准协作策略的。

AI 代码的长期影响：代码库的「AI 债务」管理

AI 代码（正文工程）的长期影响：代码库的「AI 债务」管理——AI 大量产出之后，代码库的长期健康需要新的债务观。AI 债务的形态。无主代码（没人真正理解「为什么这么写」的代码——AI 写的、验收人扫过的——理解债：接手者与三个月后的你自己都要重新逆向）；模式漂移（AI 的不同会话用不同模式写同类功能——一致性债：代码库的风格分裂）；依赖的膨胀（AI 顺手引的库——依赖债：supply chain 的面扩大）；以及测试的「生成化」（AI 生成的测试通过率高但覆盖浅——测试债：绿灯的假安全感）。债务的管理机制。AI 代码的标记与追踪（本库署名篇的度量——AI 债务的「账本」）、定期的「AI 代码重构波」（对 AI 高密度区域的专项重构——像还债一样周期性处理）、关键路径的「人类重写权」（核心逻辑由人类重写或深度评审——关键路径不欠 AI 债的纪律）。以及一个正面的视角：AI 债务的管理，也可能让代码库整体更健康——AI 重构的技术债清理、测试的批量补齐、文档的批量生成——AI 既是债务的制造者，也是史上最强的还债工具；用哪个面，取决于团队的纪律。

AI 代码的评审工具链：辅助评审的自动化

AI 代码评审（正文分流）的工具链：辅助评审的自动化——评审的带宽靠工具放大。工具的分层。层一：静态分析的自动化（lint、类型检查、SAST 安全扫描——机器能查的不用人查：AI 代码先过全部自动化门禁再到人）。层二：AI 辅助评审（AI 审 AI——用另一个 AI 做初筛：「这个 diff 有什么问题」的自动化评论——本库 AI 代码评审篇的流程，AI 的初筛标注让人的聚焦更准）。层三：人的终审（聚焦意图偏差与系统级判断——本库正文的不可逐行原则）。评审工具的选择。CodeRabbit 类的 AI 评审工具（PR 的自动评论——初筛的自动化）、传统的评审增强（danger.js 的规则化检查、CODEOWNERS 的自动指派——AI 改动的自动指派给对应 owner）。工具链的整合模式：AI 生成 PR → 自动化门禁（lint/SAST/测试）→ AI 初筛评论 → 人类终审（聚焦清单）→ 合并——每一环都减少人的无效注意力消耗，人的精力留给只有人能做的判断。工具链的收束：AI 代码的评审困境（diff 太多看不过来）的解，是「用 AI 评审 AI」——人从「逐行检查员」升级为「终审法官」；评审的自动化不是去掉人，是把人的判断力用在刀刃上。

小结

AI 生成代码冲击 git 的三个假设（提交粒度、评审带宽、回滚需求），对应的改造：提交策略（任务级提交、AI 隔离分支、署名与验收留痕）、评审策略（按风险分流的分层评审——聚焦意图偏差与越界，接受不可逐行的现实）、回滚设计（干净基线、小步提交、生产回滚预案、数据迁移的人工闸门）。AI 时代的版本管理哲学一句话：产出交给 AI，把关交给人类，撤销的能力永远握在自己手里——git 的每个环节都值得为这个三角重新校准。