用 AI 改老仓库：哪些先固定，哪些允许动

文章目录1. 结论先行2. 老仓库为什么更危险3. 禁止区建议写进团队约定4. 允许区相对安全5. 一次任务的最小模板5.1 工作示例限路径修 bug5.2 闸门建议固定成脚本6. 放开的节奏从小到大6.1 评审时看什么6.2 与遗留代码共存的两条纪律7. 适合与不适合8. 常见误区9. 术语速查10. 小结摘要把 AI 编程工具接进老仓库后最常见的事故不是它写不出代码而是它改到了不该动的边界密钥、鉴权、账单、迁移脚本、公共 API。本文给出一版先固定、再放开的工作区策略适合已经在用 Cursor / Copilot / Claude Code 一类工具、准备让它动真实业务仓的人。说明工具能力更新很快本文讲协作纪律不绑定某一产品的菜单路径。1. 结论先行先划禁止区再划允许区。密钥、鉴权、资金与数据迁移默认人工。测试与类型检查是闸门AI 可以改代码但不能跳过闸门。一次任务只给一个可验证目标大重构拆成可回滚的小步。AI 适合加速局部修改不适合在无约束时「顺便重构全世界」。2. 老仓库为什么更危险老仓库通常有隐含约定「这个目录动了要通知支付组」历史包袱复制粘贴出的相似模块不完整测试文档与现实不一致AI 擅长按局部上下文生成补丁不擅长自动继承你们团队没写进代码的规矩。于是它可能为了修 bug 改了公共协议字段把硬编码密钥「整理」进新文件但仍提交重命名时漏改反射/序列化入口图1. 这些不是 AI 能力问题是责任边界问题。一个真实感很强的失败路径是任务描述写「修一下订单列表空指针」模型为了「顺便统一风格」改了共享 DTO 的字段名编译在本模块通过下游三个服务在联调时才爆。人审若只扫当前文件 diff很难发现契约被顺手改了。边界不清时AI 越会「主动帮忙」风险越大。对照下同样的空指针任务若写成限路径模板模型通常只会在order_list里加空列表分支并补一条失败用例。产出变少但联调爆炸的概率也同步下降。老仓库里少改往往比多改更安全。3. 禁止区建议写进团队约定类别例子规则秘密.env、密钥、证书禁止 AI 读取与提交高风险逻辑登录、鉴权、支付、权限人工设计 人工终审数据变更迁移脚本、手动 SQL人工编写与执行对外契约公共 API、事件字段变更走评审禁止顺手改仓库层面可以用目录权限、CODEOWNERS、.cursorignore/ 等价忽略、预提交扫描密钥来落实而不是只靠提醒。落地顺序可以很短本周只写禁止区清单并合入 ignore下周给鉴权与计费目录加 CODEOWNERS再下周把密钥扫描挂进 CI。三步都做完之前不要把全仓代理模式当成默认开发方式。建议把禁止区再拆成「绝对禁止」与「必须双人审」两档避免清单过长却无人执行档位路径/主题示例执行方式绝对禁止自动改secrets/、生产.env*、证书私钥ignore pre-commit 拦截必须双人审auth/、billing/、**/migrations/**、对外 protobuf/OpenAPICODEOWNERS 禁止自合并默认可改但限路径业务特性目录、内部工具脚本任务里显式列出允许路径「禁止读取」和「禁止提交」要分开写。有的密钥文件被读进上下文后后续对话里仍可能被复述到注释或日志仅靠「不要提交」不够。4. 允许区相对安全图2. 允许区的关键是改完能快速验证。相对适合文档、注释、单测补强单模块 bug有复现步骤与失败用例新功能放在特性开关后样板代码生成后再人工收紧报错信息与日志字段整理不触及鉴权与计费语义仍建议每次给出复现步骤或验收命令允许修改的路径列表明确不要动的路径可用一张风险—适合度对照表做任务分派改动类型风险是否优先交给 AI补失败单测 / 修红测低是模块内局部 bug有复现中低是限路径跨模块重命名与协议变更高否或仅生成草案由人改鉴权/计费/迁移极高否依赖大版本升级高否拆成独立变更集5. 一次任务的最小模板可以复制给 AI或自己照着写 prompt目标修复 xxx附复现 允许修改path/a, path/b 禁止修改auth/, billing/, **/migrations/** 验收pytest -k case_xxx 或 npm test -- xxx 不要做无关重构、依赖升级、格式化全仓任务结束看三样diff 是否越界、测试是否过、有无密钥与调试残留。5.1 工作示例限路径修 bug场景后台列表页在空数据时 500。已知失败用例test_order_list_empty嫌疑在services/order_list.py。发给工具的约束可以是目标让 test_order_list_empty 通过空列表返回 200 [] 允许修改services/order_list.py, tests/test_order_list.py 禁止修改auth/, billing/, **/migrations/**, schemas/ 验收pytest -k test_order_list_empty -q 不要做改响应字段名、加新依赖、全仓 format验收清单人工 2 分钟检查项通过标准路径边界diff 仅出现允许文件行为指定测试通过相邻烟雾测试未挂残留无print调试、无临时密钥、无大段无关重构若模型提出「schemas 里字段更合理」应拒绝进本任务另开变更与评审。老仓库里「合理」往往不等于「可发布」。5.2 闸门建议固定成脚本把闸门写成一键命令比口头「记得跑测试」可靠# 示例按仓库实际替换makelintmaketypecheckpytest-krelated_case-qgitdiff--name-only# 人工核对是否越界没有测试的模块允许区应收缩为「只加测试、不改行为」或「改行为必须同时补最小用例」。否则 AI 的补丁无法被证伪。若历史包袱导致单测难写至少准备一条可手工执行的验收步骤curl、脚本、页面操作路径并要求任务结束时贴出命令与结果。没有可重复验收就不应该合并自动生成的行为变更。6. 放开的节奏从小到大固定高风险边界不是永久冻结生产力而是按成熟度逐步放开阶段条件可放开的范围L0无团队约定仅文档与注释L1有禁止区清单 密钥扫描单文件 bug 单测L2关键路径有最小测试单模块特性特性开关后L3CODEOWNERS 与 CI 闸门齐全多文件重构仍禁止鉴权/计费/迁移跳级的典型症状是第一周产出很快第二周出现契约破坏或误提交密钥。节奏应跟仓库可验证性走不跟模型版本发布节奏走。对已经上线多年的单体仓宁可在 L1 多停两周补测试也不要为了演示工具能力直接跳到 L3。工具会更新边界约定应比工具更稳定。6.1 评审时看什么人审不必逐行重写模型生成的代码但应固定看四项评审项问法边界是否出现任务未授权路径契约是否改动对外字段、错误码、事件名安全是否新增密钥读取、日志打印敏感字段可回滚能否单独还原是否与无关格式化缠在一起若四项都过、闸门全绿再讨论实现优雅与否。顺序反了容易在风格争论里漏掉越界改动。6.2 与遗留代码共存的两条纪律老仓库里常有复制粘贴出的相似模块。AI 很容易把 A 模块的修法套到 B却漏掉 B 里历史特例。两条纪律能降低扩散默认只改复现路径覆盖到的文件相似模块另开任务。行为变更必须带对比用例旧行为样本 新期望避免只靠目测 diff。对支付、鉴权类目录即使模型给出完整补丁也应由负责人重写关键分支或至少手改关键条件把责任留在人侧。7. 适合与不适合适合现在就做写出团队禁止区清单给高频模块补最小测试要求 AI 改动必须附带验收命令用 CODEOWNERS / ignore 把约定落到仓库不适合无测试、无复现就让 AI 把系统变好一次对话要求跨 20 个目录大重整用聊天记录代替 code review 结论在含生产密钥的工作树里直接开全仓代理模式8. 常见误区误区更好的做法全仓只读权限都给 AI按目录分级看生成代码很像对就合并跑验收 看 diff 边界让 AI 自己找该改哪里人先缩小范围用 AI 做安全审计替代专业审计它最多当辅助不当结论一次任务里塞重构修 bug升依赖拆成可回滚的独立提交忽略读到密钥的风险禁止区文件不进上下文用全仓自动 format 掩盖真实改动format 与行为变更分开提交9. 术语速查术语含义禁止区默认不允许自动改动的路径与主题允许区在验收命令约束下可交给 AI 加速的范围特性开关用配置控制新逻辑是否生效CODEOWNERS指定目录变更必须由谁审越界 diff修改了任务未授权的文件闸门lint / 类型检查 / 测试 / 密钥扫描等自动拦截可回滚小步单次变更可独立还原不与无关改动缠在一起双人审高风险目录变更必须第二人批准禁止自合并10. 小结AI 改老仓库的路径不在模型多聪明而在边界清不清楚。先固定高风险面再在可验证的小范围内允许它动旧项目才扛得住副驾驶式协作。工具负责提速人对契约、资金和数据变更负责。把禁止区、允许路径、验收命令写成仓库里的可执行约定比写在聊天里的提醒更耐用。