摘要：把 AI 编程工具接进老仓库后，最常见的事故不是它写不出代码，而是它改到了不该动的边界：密钥、鉴权、账单、迁移脚本、公共 API。本文给出一版先固定、再放开的工作区策略，适合已经在用 Cursor / Copilot / Claude Code 一类工具、准备让它动真实业务仓的人。

说明：工具能力更新很快，本文讲协作纪律，不绑定某一产品的菜单路径。

---

1. 结论先行

1. 先划禁止区，再划允许区。
2. 密钥、鉴权、资金与数据迁移，默认人工。
3. 测试与类型检查是闸门；AI 可以改代码，但不能跳过闸门。
4. 一次任务只给一个可验证目标；大重构拆成可回滚的小步。
5. 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/OpenAPI	CODEOWNERS + 禁止自合并
默认可改但限路径	业务特性目录、内部工具脚本	任务里显式列出允许路径

「禁止读取」和「禁止提交」要分开写。有的密钥文件被读进上下文后，后续对话里仍可能被复述到注释或日志；仅靠「不要提交」不够。

---

4. 允许区（相对安全）

图2. 允许区的关键是：改完能快速验证。

相对适合：

• 文档、注释、单测补强
• 单模块 bug（有复现步骤与失败用例）
• 新功能放在特性开关后
• 样板代码生成后再人工收紧
• 报错信息与日志字段整理（不触及鉴权与计费语义）

仍建议每次给出：

1. 复现步骤或验收命令
2. 允许修改的路径列表
3. 明确不要动的路径

可用一张风险—适合度对照表做任务分派：

改动类型	风险	是否优先交给 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 闸门建议固定成脚本

把闸门写成一键命令，比口头「记得跑测试」可靠：

# 示例：按仓库实际替换
make lint && make typecheck && pytest -k related_case -q
git diff --name-only   # 人工核对是否越界

没有测试的模块，允许区应收缩为「只加测试、不改行为」或「改行为必须同时补最小用例」。否则 AI 的补丁无法被证伪。

若历史包袱导致单测难写，至少准备一条可手工执行的验收步骤（curl、脚本、页面操作路径），并要求任务结束时贴出命令与结果。没有可重复验收，就不应该合并自动生成的行为变更。

---

6. 放开的节奏：从小到大

固定高风险边界，不是永久冻结生产力，而是按成熟度逐步放开：

阶段	条件	可放开的范围
L0	无团队约定	仅文档与注释
L1	有禁止区清单 + 密钥扫描	单文件 bug + 单测
L2	关键路径有最小测试	单模块特性（特性开关后）
L3	CODEOWNERS 与 CI 闸门齐全	多文件重构（仍禁止鉴权/计费/迁移）

跳级的典型症状是：第一周产出很快，第二周出现契约破坏或误提交密钥。节奏应跟仓库可验证性走，不跟模型版本发布节奏走。对已经上线多年的单体仓，宁可在 L1 多停两周补测试，也不要为了演示工具能力直接跳到 L3。工具会更新，边界约定应比工具更稳定。

6.1 评审时看什么

人审不必逐行重写模型生成的代码，但应固定看四项：

评审项	问法
边界	是否出现任务未授权路径？
契约	是否改动对外字段、错误码、事件名？
安全	是否新增密钥读取、日志打印敏感字段？
可回滚	能否单独还原，是否与无关格式化缠在一起？

若四项都过、闸门全绿，再讨论实现优雅与否。顺序反了，容易在风格争论里漏掉越界改动。

6.2 与遗留代码共存的两条纪律

老仓库里常有复制粘贴出的相似模块。AI 很容易把 A 模块的修法套到 B，却漏掉 B 里历史特例。两条纪律能降低扩散：

1. 默认只改复现路径覆盖到的文件；相似模块另开任务。
2. 行为变更必须带对比用例：旧行为样本 + 新期望，避免只靠目测 diff。

对支付、鉴权类目录，即使模型给出完整补丁，也应由负责人重写关键分支或至少手改关键条件，把责任留在人侧。

---

7. 适合与不适合

适合现在就做：

• 写出团队禁止区清单
• 给高频模块补最小测试
• 要求 AI 改动必须附带验收命令
• 用 CODEOWNERS / ignore 把约定落到仓库

不适合：

• 无测试、无复现，就让 AI 把系统变好
• 一次对话要求跨 20 个目录大重整
• 用聊天记录代替 code review 结论
• 在含生产密钥的工作树里直接开全仓代理模式

---

8. 常见误区

误区	更好的做法
全仓只读权限都给 AI	按目录分级
看生成代码很像对就合并	跑验收 + 看 diff 边界
让 AI 自己找该改哪里	人先缩小范围
用 AI 做安全审计替代专业审计	它最多当辅助，不当结论
一次任务里塞重构+修 bug+升依赖	拆成可回滚的独立提交
忽略读到密钥的风险	禁止区文件不进上下文
用全仓自动 format 掩盖真实改动	format 与行为变更分开提交

---

9. 术语速查

术语	含义
禁止区	默认不允许自动改动的路径与主题
允许区	在验收命令约束下可交给 AI 加速的范围
特性开关	用配置控制新逻辑是否生效
CODEOWNERS	指定目录变更必须由谁审
越界 diff	修改了任务未授权的文件
闸门	lint / 类型检查 / 测试 / 密钥扫描等自动拦截
可回滚小步	单次变更可独立还原，不与无关改动缠在一起
双人审	高风险目录变更必须第二人批准，禁止自合并

---

10. 小结

AI 改老仓库的路径，不在模型多聪明，而在边界清不清楚。先固定高风险面，再在可验证的小范围内允许它动，旧项目才扛得住副驾驶式协作。工具负责提速，人对契约、资金和数据变更负责。把禁止区、允许路径、验收命令写成仓库里的可执行约定，比写在聊天里的提醒更耐用。