本文为「AI 辅助编程实战指南」第5篇，完整系列持续更新中。

前言

AI 编程工具越强大，越需要给它”立规矩”。本篇系统讲解如何通过保护机制、安全规则清单和开发 SOP，让 AI 在可控范围内高效工作，而不是擅自修改核心代码或引入安全漏洞。

你有没有遇到过这种情况：让 AI “帮我优化一下数据库查询”，结果它顺手把你的认证中间件也改了？或者让它写个新接口，结果生成的代码里密码用明文存储？

这不是 AI 的”恶意”，而是它没有边界感。AI 编程工具的底层逻辑是”尽可能满足你的请求”，但”满足请求”和”安全地满足请求”之间，隔着一条你必须在部署工具之前就划好的红线。

本篇学完你将掌握：

  • AI 编程场景下的 5 类典型安全风险
  • 各主流工具的代码保护机制配置方法（Cursor / Claude Code / Qoder / Copilot）
  • 一份可直接复用的 AI 代码安全审查清单
  • 一套将安全规则固化为开发 SOP 的完整流程
  • 规则文件从编写到落地的全链路实战

一、AI 编程的 5 类典型安全风险

在讲防护之前，先搞清楚风险在哪。AI 辅助编程的安全隐患不是”AI 会写错代码”这么简单，而是系统性的、可预测的 5 类问题。

1.1 风险全景图

风险类型 典型表现 危害等级 触发场景
越权修改 AI 擅自修改认证、鉴权、加密等核心模块 极高 大范围重构、Agent 模式
安全漏洞引入 生成 SQL 注入、XSS、硬编码密钥等不安全代码 高 新功能开发
依赖投毒 推荐未经验证的第三方库，可能包含恶意代码 高 AI 自由推荐依赖
敏感信息泄露 代码中嵌入 API Key、数据库密码、内部地址 高 生成配置文件、示例代码
逻辑一致性破坏 修改 A 模块时破坏与 B 模块的调用契约 中 多文件编辑、大范围重构

💡 提示：越权修改和依赖投毒是最容易被忽视的两类风险。很多开发者只关注”AI 写的代码有没有 Bug”，却忽略了”AI 有没有动不该动的代码”和”AI 推荐的库是否可信”。

1.2 一个真实的”翻车”场景

假设你对 AI 说：”帮我把这个项目的数据库从 MySQL 迁移到 PostgreSQL。”

AI 可能会做的事：

  1. 修改数据库连接配置——这是你期望的
  2. 修改 ORM 查询语句以适配 PostgreSQL——这也是你期望的
  3. 顺手把 .env 文件里的数据库密码改成了 postgres123——你没让它干这个
  4. 在 requirements.txt 里加了一个你没听说过的 PostgreSQL 驱动——可能包含恶意代码
  5. 把 auth 模块里的某个字段类型也改了，因为”看起来也需要适配”——认证逻辑被破坏

这 5 个动作里，有 3 个是你不想要甚至危险的。而解决这个问题的方法，不是”更仔细地审查 AI 的输出”（人总会漏看），而是提前用规则文件告诉 AI：哪些事你能做，哪些事你不能做。

二、保护机制：给 AI 划”不可触碰”的红线

保护机制的核心思路是：与其信任 AI 的判断力，不如用规则文件限制它的行动边界。 各主流 AI 编程工具都支持通过配置文件实现这一目标。

2.1 文件级保护：标记”只读”文件

最简单的保护方式是告诉 AI “这些文件你不能动”。

Cursor：在 .cursorrules 中配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# 项目保护规则

## 不可修改的文件（AI 禁止编辑）
以下文件/目录为只读，任何情况下不得修改：
- `.env`、`.env.*`：环境变量和密钥文件
- `config/security.*`：安全配置
- `src/auth/**`：认证和授权模块
- `src/middleware/auth.*`：鉴权中间件
- `docker-compose.prod.yml`：生产环境编排文件
- `nginx/conf.d/`：Nginx 生产配置

## 修改前必须确认的文件
以下文件修改前必须向用户明确说明修改原因：
- `src/database/migrations/`：数据库迁移文件
- `src/api/`：公共 API 接口定义
- `package.json`、`requirements.txt`：依赖清单

Claude Code：在 CLAUDE.md 中配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 文件保护规则

## 只读保护
以下路径的文件禁止修改，只能读取和引用：
- .env 及所有 .env.* 变体
- config/security/**
- src/auth/**
- src/middleware/auth.*
- docker-compose.prod.yml
- nginx/conf.d/**

## 依赖安装限制
- 禁止安装 package.json 中不存在的依赖
- 如需新增依赖，必须先列出依赖名称、用途和安全评估

Qoder：在 AGENTS.md 中配置

1
2
3
4
5
6
7
8
9
10
11
12
13
# 安全规则

## 文件保护
以下目录和文件受保护，AI 不得修改：
- .env*：所有环境变量文件
- config/security*：安全配置
- src/auth/：认证模块（完整目录）
- src/middleware/auth*：鉴权中间件
- docker-compose.prod*：生产环境配置

## 依赖管理
- 新增依赖需说明用途和安全评估
- 禁止安装 star 数 < 1000 的未经验证依赖

💡 建议：保护规则的粒度越细越好。不要只写”不要修改核心代码”，而是明确列出每个受保护的文件和目录路径。AI 不会理解”核心代码”这个抽象概念，但它能精确匹配文件路径。

2.2 操作级保护：限制 AI 的执行权限

除了文件级保护，还可以限制 AI 能执行哪些操作。

操作权限分级：

权限级别 说明 典型场景
只读 AI 只能读取和引用代码，不能修改任何文件 代码分析、架构理解
受限编辑 AI 可以编辑代码，但不能执行终端命令 日常编码辅助
完全自主 AI 可以编辑文件 + 执行命令 + 安装依赖 Agent 模式、全流程开发

各工具的权限控制方式：

工具 权限控制方式
Cursor Composer 模式下选择 “Normal”（受限）或 “Agent”（完全自主）
Claude Code 在 CLAUDE.md 中声明 禁止执行终端命令 或 禁止安装依赖
Qoder Agent 模式下可在设置中限制文件写入范围
Copilot Agent 模式下通过 .github/copilot-instructions.md 限制操作范围
OpenAI Codex 三种模式：建议模式（人工确认）、自动编辑、完全自主

⚠️ 注意：在高权限模式下（Agent / 完全自主），务必配合文件级保护使用。权限越大，风险越高——保护规则就是你的最后一道防线。

2.3 代码块级保护：标记”不可修改”的代码段

有些情况下，整个文件不需要保护，但文件中的某些关键代码段不能动。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# === PROTECTED: 以下认证逻辑不可修改 ===
# 这段代码经过安全团队审计，任何修改都可能导致认证绕过
def verify_jwt_token(token: str) -> dict:
    """验证 JWT Token 并返回用户信息"""
    try:
        payload = jwt.decode(
            token,
            settings.JWT_SECRET_KEY,  # 密钥从环境变量读取
            algorithms=["HS256"]
        )
        return payload
    except jwt.ExpiredSignatureError:
        raise HTTPException(status_code=401, detail="Token 已过期")
    except jwt.InvalidTokenError:
        raise HTTPException(status_code=401, detail="Token 无效")
# === END PROTECTED ===

在规则文件中配合声明：

1
2
3
## 代码块保护
- 凡是被 `PROTECTED` / `END PROTECTED` 注释包裹的代码段，禁止修改
- 如需修改受保护代码，必须明确说明修改原因并获得用户确认

三、安全规则清单：AI 生成代码的必检项

保护机制解决了”AI 不能动什么”的问题，安全规则清单解决的是”AI 生成的代码必须满足什么安全标准”。

3.1 通用安全规则（适用于所有项目）

以下规则建议写入项目的规则文件，作为 AI 生成代码的强制约束：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
## 安全规则（所有生成代码必须遵守）

### 认证与授权
- 密码必须使用 bcrypt/argon2 哈希，禁止 MD5/SHA1
- JWT Token 过期时间不超过 2 小时，Refresh Token 不超过 7 天
- 所有 API 接口必须经过认证中间件，除非明确标记为公开接口
- 权限校验在服务端完成，禁止仅依赖前端鉴权

### 数据保护
- 敏感数据（密码、密钥、身份证号）禁止明文存储
- 日志中禁止输出密码、Token、身份证号等敏感字段
- 数据库连接字符串禁止硬编码，必须从环境变量读取
- 文件上传必须验证类型和大小，限制为白名单格式

### API 安全
- 所有输入必须校验和清洗（使用 Pydantic / Joi / Zod 等）
- 接口必须有速率限制（rate limiting）
- SQL 查询必须使用参数化查询，禁止字符串拼接
- 错误响应禁止暴露堆栈信息和内部系统路径

### 依赖安全
- 禁止引入 star 数 < 1000 或最后更新超过 2 年的第三方依赖
- 新增依赖必须说明用途和安全评估
- 禁止安装与已有依赖功能重叠的库

3.2 分场景安全规则

不同项目类型的安全重点不同，下面是按场景细分的补充规则：

Web 后端项目

1
2
3
4
5
### Web 后端补充规则
- 所有写操作（POST/PUT/DELETE）必须有 CSRF 保护
- 文件上传路径禁止直接拼接用户输入
- 分页查询必须有最大条数限制（防止全表扫描）
- 跨域请求必须配置白名单，禁止 `Access-Control-Allow-Origin: *`

数据处理项目

1
2
3
4
5
### 数据处理补充规则
- 批量数据操作必须有事务保护和回滚机制
- 大批量查询（> 10000 条）必须分页或流式处理
- 数据导出必须脱敏处理（手机号、邮箱、身份证号）
- 临时数据文件使用后必须清理，禁止残留在磁盘上

云原生项目

1
2
3
4
5
### 云原生补充规则
- 容器镜像禁止使用 `latest` 标签，必须指定版本
- Kubernetes Secret 必须加密存储，禁止明文写在 ConfigMap 中
- 服务间通信必须使用 mTLS 或 API Gateway 鉴权
- 禁止在容器内以 root 用户运行应用

3.3 安全规则的落地方式

安全规则写在规则文件里只是第一步，关键是让它在开发流程中真正生效：

落地方式 说明 效果
规则文件声明 写入 .cursorrules / CLAUDE.md / AGENTS.md AI 生成代码时自动遵守
Git Hook 检查 用 pre-commit hook 检查敏感信息和禁止修改的文件 提交前自动拦截
CI/CD 扫描 用 Semgrep / Bandit / ESLint Security 扫描 AI 生成的代码 合并前自动检测
代码审查 Skill 安装 code-reviewer Skill 专门做安全审查 AI 自动审查安全问题

💡 建议：推荐的安全防线组合是：规则文件（第一道）+ Git Hook（第二道）+ CI/CD 扫描（第三道）。三道防线缺一不可——规则文件防止 AI 生成不安全代码，Git Hook 防止开发者不小心提交敏感信息，CI/CD 扫描作为最后兜底。

四、开发 SOP：将安全规则嵌入开发全流程

规则文件和安全清单解决了”约束什么”的问题，开发 SOP 解决的是”什么时候检查”的问题。将安全规则固化为标准操作流程，让每次 AI 辅助开发都遵循同一个安全标准。

4.1 AI 辅助开发的标准 SOP

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
┌─────────────┐
│ 1. 需求确认  │ ← 明确任务边界，避免 AI 自由发挥
└──────┬──────┘
       ↓
┌─────────────┐
│ 2. 方案设计  │ ← AI 先输出方案，人工审核后再编码
└──────┬──────┘
       ↓
┌─────────────┐
│ 3. 受控编码  │ ← AI 在规则约束下生成代码
└──────┬──────┘
       ↓
┌─────────────┐
│ 4. 安全审查  │ ← 检查清单逐项核对
└──────┬──────┘
       ↓
┌─────────────┐
│ 5. 测试验证  │ ← 单元测试 + 安全测试
└──────┬──────┘
       ↓
┌─────────────┐
│ 6. 提交合并  │ ← Git Hook + CI/CD 扫描
└─────────────┘

4.2 每个环节的安全检查点

环节 1：需求确认

1
2
3
4
5
## 需求确认检查清单
- [ ] 明确本次任务涉及哪些文件和模块
- [ ] 明确哪些文件不在本次修改范围内
- [ ] 如果涉及安全相关模块，是否需要人工介入
- [ ] AI 是否有权限安装新依赖

环节 2：方案设计

1
2
3
4
5
## 方案设计检查清单
- [ ] AI 输出的方案是否涉及新增依赖？如有，是否经过安全评估？
- [ ] 方案是否影响现有的认证/授权逻辑？
- [ ] 方案是否涉及敏感数据的存储或传输？
- [ ] 方案的数据库变更是否需要新的迁移脚本？

环节 3：受控编码

编码阶段是安全规则文件发挥作用的主要环节。确保规则文件已正确配置：

1
2
3
4
5
## 编码阶段检查清单
- [ ] 规则文件已配置并生效（.cursorrules / CLAUDE.md / AGENTS.md）
- [ ] 受保护的文件未被修改
- [ ] AI 没有引入规则之外的新依赖
- [ ] 生成的代码不包含硬编码的密钥或密码

环节 4：安全审查

这是最关键的环节。使用下面的一站式安全审查 Prompt，让 AI 对自己生成的代码做安全检查：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
【角色设定】请扮演拥有 10 年经验的安全审计专家，熟悉 OWASP Top 10。

【审查任务】
请审查以下代码变更，按以下步骤逐项检查：
1. 认证与授权：JWT/Session 配置是否安全，权限校验是否完整
2. 数据保护：敏感数据是否加密存储，日志是否泄露敏感信息
3. 输入校验：所有用户输入是否经过验证和清洗
4. SQL 安全：是否使用参数化查询，是否存在拼接风险
5. 依赖安全：新增依赖是否经过评估
6. 错误处理：异常响应是否暴露内部信息

【输出格式】
对每个检查项，输出以下格式：
- 检查项名称
- 状态：通过 / 存在问题
- 问题描述（如有）
- 修复建议（如有）
- 严重程度：高 / 中 / 低

【约束】
- 不要修改业务逻辑，只审查安全问题
- 每个问题标注对应的代码行号

环节 5：测试验证

1
2
3
4
5
## 测试阶段检查清单
- [ ] 单元测试覆盖了核心逻辑的正常路径和异常路径
- [ ] 安全相关的接口有对应的鉴权测试
- [ ] 输入校验有对应的边界值测试
- [ ] 没有测试用例直接硬编码真实密钥或密码

4.3 SOP 固化模板

将以上所有检查清单整合为一个团队可复用的 SOP 文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
# AI 辅助开发安全 SOP

## 一、适用范围
本 SOP 适用于所有使用 AI 编程工具（Cursor / Claude Code / Qoder / Copilot 等）
进行开发的任务。

## 二、前置条件
- [ ] 项目规则文件已配置（.cursorrules / CLAUDE.md / AGENTS.md）
- [ ] 保护机制已启用（文件保护 + 操作权限）
- [ ] Git pre-commit hook 已安装

## 三、开发流程

### 3.1 需求确认
- 明确任务涉及的文件和模块
- 标记不在修改范围内的受保护文件
- 评估是否需要人工介入安全模块

### 3.2 方案设计
- AI 输出设计方案，人工审核
- 检查新增依赖的安全性
- 确认方案不影响认证/授权逻辑

### 3.3 受控编码
- AI 在规则约束下生成代码
- 实时监控受保护文件未被修改
- 不引入规则之外的新依赖

### 3.4 安全审查
- 使用安全审查 Prompt 逐项检查
- 重点检查：认证授权、数据保护、输入校验、SQL 安全
- 所有"高"严重程度问题必须修复后才能进入下一步

### 3.5 测试验证
- 运行单元测试，确保覆盖率 > 80%
- 安全接口有对应的鉴权测试
- 无硬编码密钥或密码

### 3.6 提交合并
- Git pre-commit hook 自动检查敏感信息
- CI/CD 管道运行安全扫描（Semgrep / Bandit）
- Code Review 确认无遗漏

## 四、异常处理
- 如果 AI 修改了受保护的文件 → 立即回退该文件的变更
- 如果 AI 引入了未经验证的依赖 → 移除依赖，人工评估后重新添加
- 如果安全审查发现"高"级别问题 → 修复后重新走安全审查流程

💡 建议：把这个 SOP 文件放在项目根目录的 AI_DEVELOPMENT_SOP.md 中，并在规则文件中引用它。这样 AI 在每次执行任务时都会自动加载这个 SOP 作为约束。

五、踩坑记录：AI 偷偷改了认证中间件，测试全绿却没发现

现象：
使用 AI 的 Agent 模式重构用户管理模块。任务完成后所有单元测试通过，CI 流水线也显示绿色。但上线后发现部分用户无法登录——排查后发现 AI 在重构过程中修改了 auth/middleware.py 中的一个条件判断，导致特定角色的用户被绕过认证。

原因：
Agent 模式拥有完全自主权，AI 在重构用户管理模块时”顺便”优化了认证中间件里一个它认为”冗余”的条件判断。虽然单元测试覆盖了用户管理的核心逻辑，但没有针对认证中间件的完整测试。受保护文件清单也没有覆盖 auth/middleware.py。

解决方案：

  1. 立即将 auth/ 整个目录加入文件保护清单
  2. 为认证中间件补充完整的集成测试，覆盖所有角色的认证流程
  3. 在 CI 中增加 auth/ 目录变更的强制 Code Review 规则
  4. 将 Agent 模式降为受限编辑模式，日常开发不再使用完全自主权限

避坑建议：

  • 安全相关的目录（auth/、security/、middleware/）必须整个目录加入保护，而不是只保护单个文件
  • Agent 模式虽然高效，但在涉及安全模块时，宁可降权使用受限编辑模式
  • 测试不能只看”通过率”，还要看”覆盖率”——认证模块的测试覆盖率必须达到 100%

总结与回顾

核心要点 关键结论
5 类安全风险 越权修改、安全漏洞引入、依赖投毒、敏感信息泄露、逻辑一致性破坏
文件级保护 用规则文件明确标记只读路径，粒度越细越好
操作级保护 按场景选择权限级别，高权限必须配合保护规则
安全规则清单 认证授权、数据保护、API 安全、依赖安全四大维度
开发 SOP 需求确认 → 方案设计 → 受控编码 → 安全审查 → 测试验证 → 提交合并
三道防线 规则文件（预防）+ Git Hook（拦截）+ CI/CD 扫描（兜底）

延伸阅读

本文为「AI 辅助编程实战指南」第5篇，完整系列持续更新中。