AI 生成代码进入工程仓库前，如何用沙箱分支、最小改动范围、测试和 review 防止污染主分支？｜网易后端开发面经解析

60 秒回答模板

我会把主分支看成团队共享的可信集成物，AI 生成代码不能直接写入主分支或长期开发分支。完整流程是：第一，所有 AI 修改都在临时 worktree、沙箱分支或 fork 中进行，分支命名和提交信息标注 AI 辅助来源，避免和人工开发混在一起。第二，任务进入前要定义允许修改范围、不可改目录、diff 行数上限、预期测试和验收标准；模型先给计划，工程师确认后再生成 patch。第三，提交前自动做格式化、编译、单元测试、集成测试、静态扫描、secret scan、依赖许可检查和危险文件检查，尤其拦截配置、迁移、权限、发布脚本等敏感变更。第四，PR review 不能只看结果，要看模型是否改了无关文件、是否改变公共契约、是否删除边界处理、是否让测试适配错误实现。第五，合入采用 squash 或小 commit，要求 CI 绿、owner 通过、可回滚；上线后监控相关指标。这样即使 AI 生成了错误代码，也只会停在沙箱和 PR 阶段，不会污染主分支。

考点 沙箱隔离

难度 真实面经题

回答目标 让候选人能给出一条可执行的 AI 代码入库治理链路：隔离生成、约束范围、自动验证、人工审查、可追溯合入和可回滚。

深入解析

主分支必须保持可信

主分支承载的是可构建、可测试、可发布的团队共识。AI 生成代码的风险在于改动快、范围可能扩散、理由可能看似合理但隐藏错误，所以不能让工具直接 push 到主分支。第一道原则是所有 AI 输出先进入隔离空间，主分支只接受通过验证和 review 的改动。

沙箱分支隔离改动半径

可以使用临时分支、独立 worktree、fork 仓库或容器化开发环境承接 AI 修改。沙箱里允许模型读代码、生成 patch、跑测试，但不允许直接改远端主干。沙箱生命周期要短，任务完成后通过 PR 流转；失败的实验分支可以直接丢弃，避免残留半成品。

进入生成前先定义 diff 契约

任务开始前要写清楚目标、允许文件、禁止文件、预期行为、测试列表和验收标准。可以限制单次 diff 行数、文件数和模块范围，要求模型先输出修改计划。这样 review 时能判断生成结果是否越界，而不是等到一大坨 diff 出现后再人工猜意图。

自动化门禁覆盖质量和安全

AI 代码进入 PR 前应经过格式化、lint、类型检查、编译、单元测试、集成测试、契约测试、静态扫描、secret scan、依赖许可证和危险命令检查。对数据库迁移、配置、权限和发布脚本等敏感文件，要额外要求人工确认或禁止自动生成。

Review 重点看无关改动和契约破坏

AI 生成代码常见问题不是语法错误，而是顺手重构、删除兼容逻辑、改变错误语义、吞异常、扩大权限、修改测试适配错误实现。review 要对照任务契约逐项检查：是否只改必要文件，是否保留 API 兼容，是否新增足够测试，是否有可解释的设计取舍。

合入后还要可追溯可回滚

通过 review 后，合入策略应保持小而清晰，例如 squash 成一个可回滚提交，或按行为拆小 commit。提交信息、PR 描述和审计记录应说明 AI 辅助范围、主要风险和验证结果。上线后观察相关告警和业务指标，一旦回归可快速定位到该 PR 并回滚。

易错点

允许 AI 工具直接 push 主分支或自动合并，只在事后发现问题。
没有在生成前定义允许修改范围，导致模型顺手改配置、迁移、公共库或测试。
把 CI 绿当成唯一标准，忽略 API 契约、兼容性、权限语义和异常处理。
review 只看最终效果，不看无关 diff、测试是否被改坏、公共行为是否变化。
AI 实验分支长期保留并反复合并，造成半成品代码和人工改动混在一起。
声称某公司有特定主干保护平台或内部策略，来源只支持通用工程治理问题。

面试官追问

为什么 AI 生成代码不能直接提交主分支？

因为模型可能生成看似合理但破坏隐含契约的代码，主分支一旦被污染会影响团队构建、发布和后续开发。隔离分支能把风险限制在 review 前。

沙箱分支和普通 feature 分支有什么区别？

沙箱分支更强调短生命周期、权限受限、可丢弃和可审计。它可以承接 AI 的多次尝试，但只有经过人工整理、测试和 review 的最小 diff 才进入正式 PR。

AI 改动的 PR 描述应该包含什么？

应包含任务目标、AI 辅助范围、主要文件、风险点、测试结果、未覆盖项和回滚方式。这样 reviewer 不需要重新猜模型为什么这么改。

模型生成测试是不是就足够了？

不够。模型生成测试可以作为候选，但要防止它把测试写成迎合错误实现。关键路径要有独立的回归用例、边界用例和人工确认的验收标准。

如何处理 AI 生成的一大段无关重构？

不要直接 review 大 diff。应要求拆分或重做：只保留与任务目标直接相关的最小改动，无关格式化、重命名和重构单独提交，必要时直接丢弃沙箱分支。