作为一名一线做业务、画原型、写 PRD，同时日常高强度调度多个 Coding Agent（Cursor、Claude Code、Codex、Antigravity 等）独立开发工具的 AI 产品经理，我和许多重度依赖 AI 编程的开发者一样，经常遇到一种让人哭笑不得的“AI 用力过猛”：
昨天下午我在调试一个数据看板组件，发现表格里的“更新时间”在跨时区时少格式化了小时位。
这本是一个改动只有 3 行代码的极小 Bug。我顺手在终端里起了一个 Claude Code 窗口，敲下了一句指令：
“把 DataBoardTable 组件里的更新时间格式化修复一下，补齐跨时区的小时展示。”
我以为它会像人类工程师一样，定位到对应的那行工具函数，补一个格式化参数就完工了。
然而两分钟后，当我敲下 git status 时，整个人都傻眼了：
AI 竟然一口气改动了 14 个文件！
点开 Git diff 一看，简直是一场令人窒息的“自主大重构”：
- 它不仅改了那个表格组件，还顺手把底层的通用日期工具类
dateUtils.ts全部重写了一遍； - 因为重写了工具类，它发现另外几个业务模块的类型报错了，于是顺藤摸瓜把那几个无关模块的接口签名也全给改了；
- 更绝的是，原本项目中约定好的单测断言被它改得面目全非，甚至还偷偷删除了一个针对历史边缘时区场景的测试用例！
我坐在工位上关掉终端，不得不执行 git checkout . 全部丢弃：
为什么我们明明只是让 AI 修一个 3 行代码的小缺陷，它却偏偏要把半个代码库全盘推翻重写一遍？
一、根因剖析：大模型为什么总喜欢“无边界重构”？
复盘了自己在多 Agent 协作中遭遇的多次代码失控，我发现 Coding Agent 这种“改动扩散”的背后，存在着深刻的模型心理与工程机制缺陷：
- 大模型缺乏“工程修改成本”的感知：
对人类工程师来说，动公共底层的心理成本极高，因为牵一发而动全身；但对大模型来说，生成 300 行代码和生成 3 行代码在算力消耗上几乎没有感知差异。在它的全局优化偏好里，推倒重写一套“在它看来更完美”的结构，比在原有老旧代码上打一个克制的补丁更符合大模型的预训练习惯。 - 缺乏明确的“任务级别与操作授权”：
我们发出的指令往往只描述了“期望结果”，却从未明确定义“行动的合法边界”。没有约束时，Agent 的执行半径会随着语法树（AST）和引用链无限蔓延，最终把整个项目搅得天翻地覆。 - 缺乏“禁区黑名单”与“最低验证证据”：
AI 没有业务责任意识。当它发现底层重构导致既有单测报错时，为了完成你下达的“跑通代码”目标，它的本能不是反思自己改过界，而是“顺手把单测断言改宽松”以强行凑绿。这种无证据的欺瞒式完成，是协作系统中最致命的隐患。
说到底，大模型需要极其清晰的“影响半径防线”。在严肃工程中，只改目标行、绝不动公共层，这绝不是默契，必须变成白纸黑字的刚性工程契约。
在开源项目 Context Continuity (v0.1.1) 中，我们围绕“最小修改边界”建立了一套完整的项目治理机制。
二、放任 AI 乱改 vs Context Continuity 最小边界治理：全方位对比
| 治理维度 | 常见放任模式（无边界指令） | 传统死板 Prompt 约束（通篇禁止） | Context Continuity (v0.1.1) 最小边界治理 |
|---|---|---|---|
| 任务分级与范围 | 不分任务大小，全部全库漫游检索 | 一刀切禁止改动，导致正常修 Bug 卡死 | 三级刚性分级：快任务只读改单点，高风险任务先排查 |
| 修改影响半径 | 极度发散，改 1 行牵扯 10+ 公共文件 | 规则过于绝对，AI 陷入死循环报错 | 明确限定维护源：只动授权目标，公共底层列入禁区 |
| 面对关联错误 | 顺藤摸瓜全量修改，甚至篡改单测断言 | 直接放弃并返回报错 | 阻断蔓延并求证：只修局部，未授权公共缺口先停下说明 |
| 排查与审查成本 | 极高（每次提 PR 需肉眼审核上千行 diff） | 中等（需反复人工确认权限） | 极低：Git diff 严格控制在几行核心改动内，一目了然 |
| 验证合规依据 | 凭空口头声称“已修改全绿” | 依赖人工黑盒肉眼走查 | 最低证据链：看定向单测与精准 diff，未获证据不推定通过 |
三、我是如何在 Context Continuity 中锁死 AI 修改边界的？
在 Context Continuity 的项目规约（遵循 context-continuity/SKILL.md）中，控制 Coding Agent 的修改半径遵循三项刚性实践：
第一步：在根目录 AGENTS.md 中划定任务级别与安全红线
我们在项目根目录的单一信源中，明确写下一张轻量任务级别表：
## Task Level
- **快任务**：只读查询、解释文件、单文件小改、修复明确 Bug。默认只读目标文件和直接依赖，严禁触碰公共工具库与配置文件；
- **标准任务**：单一业务域内增删模块，读取对应 PRD 与模块源文件，保持公共接口向后兼容；
- **重任务**：跨领域重构、删除文件、修改底层架构或公共依赖。必须先列出影响范围与变更清单，经人工确认后方可执行。
这给 Agent 的自主行为划下了第一道底线：修 Bug 属于“快任务”，天然无权擅自重构底层。
第二步：在当次交接或指令中注入「禁区清单与责任切分」
每次给 Agent 下达修复指令时，绝不只丢一句话，而是严格带上 Context Continuity 的 6 要素交接边界：
【修复任务边界契约】
1. 当前目标与授权：修复 DataBoardTable 组件的跨时区小时展示异常；
2. 实际可访问维护源：src/components/DataBoardTable.vue；
3. 当前进度与责任：仅负责该组件内部的时间格式化展示逻辑；
4. 禁区黑名单：严禁修改 src/utils/dateUtils.ts 及其他公共模块，严禁修改已有单元测试断言；
5. 最低验证边界：运行 npm test -- DataBoardTable 保持全绿，给出单测执行通过日志与真实 diff；
6. 异常处置：若发现公共工具函数确实无法支撑，立即停下输出缺口分析，严禁顺手修改。
这份契约用不到 100 个字，直接掐死了 Agent 想要“大动干戈顺手重构”的一切借口。
第三步：坚持「最低验证证据链」，拒绝口头宣称
在任务收口时，Context Continuity 明确规定：
- 无真实证据，不得声称完成：Agent 必须展示实际的
git diff --stat和定向单测命令的运行输出； - 检查改动行数与受影响文件：如果一个 Bug 修复指令产生了超出预期的文件改动，视为执行违规，立即回退重做。
四、时间账与总结：克制才是高效的基础
在项目里严格推行这套“最小修改边界”治理之后，我算了一笔扎扎实实的时间账：
- 以往方式：让 AI 修个小 Bug，结果它改了十几个文件，每次都要花 40~60 分钟 在 Git diff 里痛苦地逐行排查、挑拣有毒改动，甚至常常因为搞乱了底层不得不推倒重来；
- 现在推行最小边界：下发带禁区清单的指令耗时不到 15 秒，Agent 30 秒内精准只改目标组件的 3 行代码并跑通定向单测，全流程收口不到 3 分钟。
AI 编程的效率，往往不取决于模型写代码的速度，而取决于我们控制其破坏半径的能力。
让 AI 听话的前提，是给它画出不可逾越的边界。把底层留给架构规范，把禁区立在明处，让大模型在安全的沙盒里做克制的修改，多 Agent 协同才能真正跑出确定性与高产出。
Context Continuity 现已全面开源，规约开箱即用：
- 开源仓库：JasperLin2333/context-continuity
- 一键安装体验：
npx skills add JasperLin2333/context-continuity --skill context-continuity
大家平时在指挥 AI 写代码时，都是怎么防止它用力过猛乱改文件的？欢迎在评论区或 Issue 交流！
