拒绝 AI 代码“暗度陈仓”：工程级 AI 编码边界与防护规则设计

一、引言：AI Coding 的"范围蠕变（Scope Creep）"危机

当研发团队全面拥抱 Cursor Composer、Claude Code 或 Windsurf 等新一代具备自主执行能力的 Coding Agent 时，代码库的隐性熵增达到了前所未有的速度。

在 Code Review 中，我们经常抓到类似提交：

暗改依赖图谱： Agent 仅仅为了使用一个工具函数（如 uuid），就在 package.json 中擅自引入了体积巨大的第三方包；
语义腐化： Agent 认为一段带有历史 Workaround 的防御性代码"过于冗余"，在未经回归测试的情况下将其"优化"掉；
跨域越权（Cross-domain Mutation）： 需求本身只局限于 UI 视图层，Agent 却顺手修改了底层通用状态管理逻辑。

这种现象在软件工程中被称为 Agent 范围蠕变（Agent Scope Creep）。如果缺乏系统性的护栏（Guardrails），AI 提效省下来的时间，最终会被漫长痛苦的 Debug 和线上故障连本带利收回。

二、防御架构：三层 AI 边界防护体系

依赖人类在 Code Review 时肉眼比对几百行 git diff 是不可靠的。我们必须建立纵深防御架构（Defense in Depth）：

text 复制代码

┌──────────────────────────────────────────────────────────────┐
│  L1. 认知层约束 (Cognitive Prompting)                         │
│  - 在 AGENTS.md / CLAUDE.md 中声明硬性边界清单与负向提示词        │
├──────────────────────────────────────────────────────────────┤
│  L2. 工具级沙箱 (Tool-Level Sandboxing)                      │
│  - 利用 Cursor MDC 等协议，针对关键目录声明 Read-Only 规则     │
├──────────────────────────────────────────────────────────────┤
│  L3. 确定性物理门禁 (Deterministic Git / CI Gateways)          │
│  - pre-commit hook 阻断对受保护资产的未授权暂存                 │
│  - CI 流水线拦截核心元数据被静默修改                            │
└──────────────────────────────────────────────────────────────┘

三、工程落地实战

1. 契约层：边界协议声明（`boundaries.md`）

在项目根目录沉淀明确的架构资产分级，明确标注"不可变核心（Immutable Core）"：

markdown 复制代码

# Architectural Boundaries & Protection Matrix

| 资产类型 | 保护范围 | AI 操作权限 |
| :--- | :--- | :--- |
| **基础设施** | `package.json`, `pom.xml`, `.env*` | **DENY ALL** (只读，禁止修改) |
| **核心领域层**| `src/domain/core/*`, `src/utils/crypto.*` | **READ ONLY** (只读，修改需确认) |
| **历史兼容区**| 带有 `// SACRED:` 注释的代码块 | **IMMUTABLE** (不可变) |
| **常规业务层**| `src/features/*`, `src/views/*` | **READ & WRITE** (允许写入) |

2. 工具层：Cursor 元数据锁定

利用 Cursor 的规则拦截机制，在 .cursor/rules/immutable-core.mdc 中建立强制约束：

markdown 复制代码

---
description: Enforce architectural boundaries and protect critical files
globs: *
alwaysApply: true
---
## Architectural Boundary Constraints
1. NEVER modify files matching: `src/core/auth/**`, `**/migrations/**`.
2. Any edit that introduces new external dependencies to `package.json` must be REJECTED.
3. If a task cannot be completed without modifying protected files, STOP and ask the user.

3. 门禁层：确定性拦截（Pre-commit Guard）

不要盲目相信大模型的遵守率（Instruction-Following Rate），必须引入确定性代码检查。

在 .husky/pre-commit 中集成防护脚本：

bash 复制代码

#!/usr/bin/env bash
# 调用防护核心脚本
./scripts/pre-commit-ai-check.sh

脚本通过提取暂存区索引：

bash 复制代码

git diff --cached --name-only

与 boundaries.md 中的保护清单做正则比对。只要发现被修改的清单中包含核心资产，直接以 Exit Code 1 阻断提交流程，强迫开发者介入核查。

四、防删注释实践：定义"神圣注释（Sacred Comments）"

为了防止 AI 乱删核心注释，我们团队制定了代码注释的 RFC 规范，约定在极其重要的逻辑前添加特定前缀：

typescript 复制代码

// SACRED(Safari-14-Bug): 严禁删除此处的 microtask 调度，用于绕过旧版渲染引擎时序 Bug
queueMicrotask(() => {
  renderCanvas();
});

在系统级提示词中注入一条极短的规则：

"NEVER remove or alter any comments starting with // SACRED:. They represent production survival patches."

实测该策略能将 Agent 误删关键避坑逻辑的概率从 37% 压降至 0.5% 以下。

五、总结

AI 编程正在经历从"野蛮生长"向"规范治理"的演进。优秀的工程团队不是不用 AI，而是先给系统装上刹车与护栏，再一脚油门到底。

本文提到的所有防乱改配置、Git 拦截脚本及边界声明规范已汇总至开源资源包：AI-Guardrails-Pack/。包含 Shell 与 PowerShell 双版本，开箱即用，欢迎集成到你的主力工程中！