AI 写代码不放心？给技术博客准备一份代码审校清单

面向“AI 爪客”CSDN 技术博客的深度技术博文草稿。本文适合写给正在使用 AI 辅助编码、代码生成、单元测试生成、自动重构的开发者与技术负责人。

---

摘要

AI 编程助手已经能快速生成业务代码、脚本、测试用例和文档，但“能跑”不等于“可靠”，“看起来对”也不等于“可上线”。很多团队在引入 AI 写代码后，会遇到类似问题：代码风格不统一、边界条件遗漏、安全风险被忽略、依赖版本不匹配、生成的测试只覆盖了理想路径，甚至把伪造 API、过期语法和隐性性能问题一起带进仓库。

本文提供一份可直接复用的 AI 代码审校清单，帮助开发者从需求一致性、正确性、安全性、可维护性、性能、测试、工程化、合规边界等角度系统审查 AI 生成代码。你可以把它用于技术博客示例、团队 Code Review 模板、AI Agent 工作流，也可以直接复制文末“资产复制区”中的提示词与 Checklist。

---

一、问题背景

1. AI 写代码的典型幻觉

AI 生成代码常见问题并不只是“语法错”。更棘手的是以下几类：

1. 需求理解偏差
   用户要求“支持分页查询”，AI 可能只实现 limit，没有处理 offset、默认页码、最大页大小和非法参数。

2. 伪造依赖或 API
   AI 可能编造一个看似合理但实际不存在的方法，例如 client.fetchAllUsersWithCache()。

3. 边界条件遗漏
   只处理正常输入，不处理空列表、空字符串、超大文件、并发请求、网络超时、时区差异等。

4. 安全风险隐藏在“便捷实现”里
   例如直接拼接 SQL、把密钥写进代码、关闭 TLS 校验、对用户输入不做转义、日志打印敏感信息。

5. 测试样例过于乐观
   AI 生成的测试经常只覆盖 happy path，断言也可能过弱，甚至测试逻辑和业务代码存在同源错误。

6. 工程集成不完整
   单文件能跑，但放进真实项目后与 lint、类型检查、CI、配置加载、权限模型、日志规范不兼容。

2. 为什么技术博客需要“审校清单”

技术博客中的代码具有传播性。读者可能会直接复制示例到项目中，因此博客作者不仅要展示“如何实现”，还要说明“如何判断实现是否可靠”。

一份好的 AI 代码审校清单，可以帮助博客内容从“炫技演示”升级为“工程实践”：

• 让示例代码更可信；
• 帮助读者形成审查习惯；
• 降低错误代码被复制传播的风险；
• 体现作者对安全、质量和工程边界的责任感。

---

二、最终效果预览

读完本文后，你将得到三类可复用资产：

1. 一套 AI 生成代码审校流程

   • 先对齐需求；
   • 再检查正确性；
   • 再验证安全、性能、可维护性；
   • 最后补齐测试与工程化集成。

2. 一份 Markdown 版代码审校 Checklist

   • 可直接粘贴到 CSDN、GitHub PR 模板、语雀/飞书文档；
   • 适合人工 Code Review，也适合喂给 AI 做二次审查。

3. 一组提示词模板

   • 用于让 AI 自查；
   • 用于让 AI 扮演 Reviewer；
   • 用于让 AI 生成测试用例；
   • 用于让 AI 输出风险分级报告。

示例审校输出大致如下：

## AI 代码审校结论

- 总体风险：中
- 是否建议直接合并：否
- 阻塞问题：2 个
- 建议优化：5 个

### 阻塞问题
1. SQL 查询存在拼接风险，需改为参数化查询。
2. 文件上传接口缺少大小限制和类型校验。

### 建议优化
1. 为异常路径补充单元测试。
2. 对外部 API 调用增加超时和重试策略。
3. 将魔法数字提取为配置项。

---

三、技术方案总览

AI 代码审校不应该只问一句“这段代码有没有问题？”。更稳妥的方案是拆成多轮、多维度检查。

推荐流程如下：

需求对齐
  ↓
代码可运行性检查
  ↓
正确性与边界条件审查
  ↓
安全风险审查
  ↓
性能与资源使用审查
  ↓
可维护性与可读性审查
  ↓
测试覆盖与测试质量审查
  ↓
工程集成与发布风险审查
  ↓
形成风险分级报告

可以把它理解为“AI 代码质量网关”：

审校维度	关注点	常用验证方式
需求一致性	是否实现真实需求，是否擅自扩展或遗漏功能	对照需求逐项核验
正确性	逻辑是否正确，边界条件是否完整	人工阅读、单测、属性测试
安全性	注入、越权、敏感信息、依赖风险	安全 Checklist、SAST、依赖扫描
性能	时间复杂度、内存占用、IO、并发	压测、基准测试、复杂度分析
可维护性	命名、结构、耦合、重复代码	Lint、架构 Review
测试质量	覆盖率、断言强度、异常路径	Coverage、Mutation Testing
工程化	配置、日志、监控、CI/CD、回滚	集成测试、发布检查

---

四、环境准备

本文不绑定具体语言或框架，但建议准备以下基础环境，方便把 Checklist 落到真实项目中。

1. 基础工具

• Git：用于查看 AI 生成代码的 diff；
• IDE：推荐开启类型检查、Lint 和安全提示；
• 单元测试框架：如 JUnit、pytest、Jest、Go test；
• 代码扫描工具：如 ESLint、Pylint、Bandit、Semgrep、SonarQube；
• 依赖漏洞扫描：如 npm audit、pip-audit、OWASP Dependency-Check、Snyk；
• CI/CD：将审校动作固化到流水线。

2. 建议的项目约束

在让 AI 写代码前，最好先提供项目约束，而不是只给一句自然语言需求：

请遵守以下约束：

1. 技术栈：Node.js 20 + TypeScript + Express。
2. 数据库：PostgreSQL，所有 SQL 必须使用参数化查询。
3. 错误处理：统一返回 `{ code, message, requestId }`。
4. 日志：禁止打印 token、password、手机号、身份证号等敏感信息。
5. 测试：至少包含正常路径、异常路径、边界输入。
6. 风格：遵循项目现有 ESLint 和 Prettier 规则。

3. 安全边界提醒

重要提醒：AI 代码审校不能替代正式安全审计、法务审查和生产发布评审。涉及支付、身份认证、权限控制、隐私数据、医疗金融、工业控制等高风险场景时，必须由具备资质的人员进行人工复核，并结合专业安全测试工具验证。

同时，不建议把以下内容直接粘贴给外部 AI 服务：

• 生产环境密钥、Token、证书；
• 用户隐私数据、交易数据、医疗数据；
• 未脱敏的日志和数据库导出；
• 公司内部私有协议、未公开算法、商业机密；
• 尚未披露的安全漏洞细节。

---

五、核心实现思路或示例

下面通过一个简化示例说明：为什么 AI 生成代码需要审校。

示例需求

实现一个用户搜索接口：

• 支持按关键字搜索用户名；
• 支持分页；
• 返回用户列表和总数；
• 禁止 SQL 注入；
• 默认每页 20 条，最大每页 100 条。

AI 可能生成的风险代码

app.get('/users/search', async (req, res) => {
  const keyword = req.query.keyword || '';
  const page = req.query.page || 1;
  const pageSize = req.query.pageSize || 20;

  const sql = `
    SELECT * FROM users
    WHERE name LIKE '%${keyword}%'
    LIMIT ${pageSize}
    OFFSET ${(page - 1) * pageSize}
  `;

  const users = await db.query(sql);
  res.json({ users });
});

这段代码看起来简洁，但问题很多：

• keyword 直接拼接进 SQL，存在 SQL 注入风险；
• page、pageSize 未转换为数字，可能导致类型问题；
• 未限制 pageSize 最大值，可能造成性能风险；
• 未处理负数、零、超大页码；
• 未返回总数；
• 未处理数据库异常；
• SELECT * 可能返回敏感字段；
• 没有测试。

审校后的改进示例

app.get('/users/search', async (req, res, next) => {
  try {
    const keyword = String(req.query.keyword || '').trim();
    const page = Math.max(Number.parseInt(String(req.query.page || '1'), 10), 1);
    const rawPageSize = Number.parseInt(String(req.query.pageSize || '20'), 10);
    const pageSize = Math.min(Math.max(rawPageSize || 20, 1), 100);
    const offset = (page - 1) * pageSize;

    const likeKeyword = `%${keyword}%`;

    const countResult = await db.query(
      'SELECT COUNT(*)::int AS total FROM users WHERE name ILIKE $1',
      [likeKeyword]
    );

    const userResult = await db.query(
      `
        SELECT id, name, avatar_url, created_at
        FROM users
        WHERE name ILIKE $1
        ORDER BY created_at DESC
        LIMIT $2 OFFSET $3
      `,
      [likeKeyword, pageSize, offset]
    );

    res.json({
      users: userResult.rows,
      total: countResult.rows[0].total,
      page,
      pageSize,
    });
  } catch (error) {
    next(error);
  }
});

这个版本做了几件关键改进：

1. 使用参数化查询，降低注入风险；
2. 对分页参数做了数字转换和范围限制；
3. 避免 SELECT *，只返回必要字段；
4. 补充总数查询；
5. 使用统一异常处理；
6. 保留进一步测试和索引优化空间。

审校时可以追问 AI 的问题

你可以要求 AI 对代码逐项回答：

请基于以下需求和代码进行审校：

1. 代码是否完全满足需求？如果不满足，请列出缺口。
2. 是否存在安全风险？请按高/中/低分级。
3. 是否存在边界条件遗漏？
4. 是否存在性能瓶颈？
5. 是否需要补充测试？请给出测试用例列表。
6. 是否建议合并？请给出明确结论。

---

六、提示词模板

下面给出几组可以直接复用的 Prompt。

模板 1：AI 生成代码自查

你是资深软件工程师。请对下面这段 AI 生成代码进行自查。

请按以下维度输出：

1. 需求符合度：是否完整实现需求。
2. 正确性：是否存在逻辑错误或边界条件遗漏。
3. 安全性：是否存在注入、越权、敏感信息泄露、依赖风险等问题。
4. 性能：是否存在明显性能瓶颈或资源浪费。
5. 可维护性：命名、结构、重复代码、可读性是否合理。
6. 测试建议：至少给出正常路径、异常路径、边界路径测试用例。
7. 合并建议：可以合并 / 修改后合并 / 不建议合并。

背景需求：
【粘贴需求】

项目约束：
【粘贴技术栈、规范、安全要求】

代码：
```语言
【粘贴代码】

请用表格输出问题清单，并给出修复建议。

### 模板 2：让 AI 扮演严格 Code Reviewer

```markdown
请扮演一名非常严格的 Code Reviewer，重点找问题，不要只说优点。

审查目标：
- 找出可能导致线上故障的问题；
- 找出可能导致安全风险的问题；
- 找出测试覆盖不足的问题；
- 找出不符合工程规范的问题。

输出格式：

## 总体结论
- 风险等级：高 / 中 / 低
- 是否阻塞合并：是 / 否

## 问题列表
| 编号 | 等级 | 位置 | 问题 | 影响 | 修复建议 |
|---|---|---|---|---|---|

## 必须补充的测试
- [ ] 测试项 1
- [ ] 测试项 2

## 修复后的验收标准
- 标准 1
- 标准 2

待审查代码：
```语言
【粘贴代码】

### 模板 3：生成测试用例

```markdown
请基于以下函数/接口生成测试用例，不要只覆盖正常路径。

要求：
1. 覆盖正常输入、空输入、非法输入、边界值、异常依赖、并发或重复请求场景。
2. 每个测试用例包含：用例名称、输入、预期输出、断言重点。
3. 如果代码存在不可测试点，请指出并建议如何重构。

需求：
【粘贴需求】

代码：
```语言
【粘贴代码】

### 模板 4：安全专项审查

```markdown
请只从安全角度审查以下代码。

重点检查：
- SQL/NoSQL/命令注入；
- XSS、SSRF、路径穿越、反序列化；
- 鉴权和越权；
- 敏感信息泄露；
- 日志脱敏；
- 加密算法和随机数使用；
- 依赖漏洞和过期 API；
- 默认配置是否不安全。

请按高危、中危、低危分类输出，并给出可执行的修复建议。

代码：
```语言
【粘贴代码】

---

## 七、常见错误与排查

### 错误 1：只让 AI 看代码，不给需求

**现象**：AI 审校结果泛泛而谈，只指出命名、注释、格式问题。  
**原因**：没有需求上下文，AI 无法判断“代码是否实现了该实现的东西”。  
**排查方式**：审校时同时提供需求、接口约定、数据结构、错误码规范、权限要求。

### 错误 2：AI 生成的测试没有真实断言

**现象**：测试只检查“不报错”，没有验证业务结果。  
**示例**：

```ts
expect(result).toBeDefined();

这种断言太弱。更好的断言应该验证具体字段、数量、状态变化和异常信息。

错误 3：忽略依赖版本

现象：AI 使用了项目中不存在的库，或使用了旧版本 API。
排查方式：

• 检查 package.json、requirements.txt、pom.xml、go.mod；
• 让 AI 基于当前依赖版本重新生成；
• 在 CI 中运行安装、构建和测试。

错误 4：安全审查只看“有没有 SQL 注入”

安全问题远不止 SQL 注入。还要关注：

• 文件上传是否限制大小、类型和路径；
• 用户是否能访问别人的数据；
• 外部 URL 请求是否可能 SSRF；
• 日志是否记录敏感信息；
• 错误信息是否暴露内部路径、SQL、堆栈；
• 是否使用弱加密算法或固定随机种子。

错误 5：没有把审校结果变成工程门禁

如果审校只停留在口头 Review，很容易在赶进度时被跳过。建议把关键检查固化为：

• Pull Request 模板；
• CI 必跑任务；
• Lint 和类型检查；
• 单元测试覆盖率阈值；
• 安全扫描；
• 发布前 Checklist。

---

八、优化方向

1. 建立团队级 AI 代码审校规范

团队可以沉淀一份统一模板，包含：

• 允许 AI 生成的代码类型；
• 禁止 AI 处理的数据范围；
• 生成代码必须通过的检查项；
• 哪些改动必须人工复核；
• 高风险模块的审批流程。

2. 将 Checklist 嵌入 PR 模板

例如：

## AI 参与说明

- [ ] 本 PR 是否使用 AI 生成或修改代码？
- [ ] 已人工确认代码符合需求。
- [ ] 已检查安全风险。
- [ ] 已补充必要测试。
- [ ] 未提交密钥、Token、隐私数据或公司机密。

3. 让 AI 做“二次审查”，但不让它做最终拍板

AI 很适合做初筛：发现明显问题、补充测试思路、解释风险。但最终是否合并，仍应由开发者、Reviewer 或负责人决定。

建议分工：

角色	适合做什么	不适合做什么
AI	初步审查、生成测试、解释风险、列清单	替代最终审批、处理敏感数据
开发者	修复问题、补测试、验证运行结果	盲信 AI 结论
Reviewer	判断设计合理性、安全边界、上线风险	只看 AI 总结不看代码
CI 工具	自动化格式、测试、扫描	理解复杂业务意图

4. 建立风险分级标准

建议把问题分成三档：

• 高危：可能导致数据泄露、越权、资金损失、服务不可用，必须阻塞合并；
• 中危：可能导致部分功能异常、性能下降、维护成本显著增加，建议修复后合并；
• 低危：命名、注释、局部可读性问题，可以视情况优化。

5. 加入真实运行验证

AI 审校不能只停留在文本层面。更可靠的做法是：

# 示例：不同项目命令不同，请按实际情况调整
npm run lint
npm run typecheck
npm test
npm audit

对于 Python 项目，可以类似执行：

ruff check .
pytest
pip-audit

---

九、资产复制区

本节内容可以直接复制到博客、团队文档或 PR 模板中。

资产 1：AI 代码审校 Checklist

# AI 代码审校 Checklist

## 1. 需求一致性
- [ ] 代码是否完整实现需求？
- [ ] 是否存在擅自扩展、遗漏或误解需求？
- [ ] 输入、输出、错误码、状态码是否符合约定？
- [ ] 是否考虑权限、角色、租户、数据范围等业务规则？

## 2. 正确性与边界条件
- [ ] 正常路径是否正确？
- [ ] 空值、空数组、空字符串是否处理？
- [ ] 非法输入是否校验？
- [ ] 极大值、极小值、分页边界是否处理？
- [ ] 时间、时区、金额、精度是否处理正确？
- [ ] 并发、重复提交、幂等性是否考虑？

## 3. 安全性
- [ ] 是否存在 SQL/NoSQL/命令注入风险？
- [ ] 是否存在 XSS、SSRF、路径穿越、反序列化风险？
- [ ] 是否正确做了认证和授权？
- [ ] 是否可能发生越权访问？
- [ ] 是否泄露密码、Token、密钥、手机号、身份证号等敏感信息？
- [ ] 日志、错误信息是否脱敏？
- [ ] 文件上传、下载、解析是否有限制？
- [ ] 加密、签名、随机数是否使用安全方案？

## 4. 性能与资源
- [ ] 是否存在 N+1 查询？
- [ ] 是否有不必要的全表扫描或 SELECT *？
- [ ] 是否限制分页大小和上传文件大小？
- [ ] 是否存在内存一次性加载大文件的问题？
- [ ] 外部 API 调用是否设置超时、重试和熔断？
- [ ] 是否需要索引、缓存或异步处理？

## 5. 可维护性
- [ ] 命名是否清晰？
- [ ] 函数是否过长或职责过多？
- [ ] 是否存在重复代码？
- [ ] 配置是否硬编码？
- [ ] 是否符合项目目录结构和编码规范？
- [ ] 注释是否解释了必要的业务原因，而不是重复代码？

## 6. 测试质量
- [ ] 是否有单元测试？
- [ ] 是否有集成测试或接口测试？
- [ ] 是否覆盖异常路径和边界值？
- [ ] 断言是否足够具体？
- [ ] Mock 是否合理，是否掩盖真实问题？
- [ ] 测试是否能在 CI 中稳定运行？

## 7. 工程化与发布
- [ ] 是否通过 Lint、格式化、类型检查？
- [ ] 是否通过构建和测试？
- [ ] 是否兼容当前依赖版本？
- [ ] 是否补充配置、迁移脚本、文档？
- [ ] 是否具备日志、监控、告警和回滚方案？
- [ ] 是否确认未提交密钥、隐私数据或内部敏感信息？

## 8. 合并结论
- [ ] 可以直接合并
- [ ] 修改后合并
- [ ] 不建议合并

结论说明：
【填写风险、原因和修复建议】

资产 2：AI Reviewer 输出模板

# AI Reviewer 审校报告

## 总体结论

- 风险等级：高 / 中 / 低
- 是否阻塞合并：是 / 否
- 主要原因：

## 问题清单

| 编号 | 等级 | 文件/位置 | 问题描述 | 影响 | 修复建议 |
|---|---|---|---|---|---|
| 1 | 高 |  |  |  |  |

## 测试建议

- [ ] 正常路径：
- [ ] 异常路径：
- [ ] 边界输入：
- [ ] 安全场景：
- [ ] 性能场景：

## 验收标准

- [ ] 所有阻塞问题已修复；
- [ ] 单元测试和集成测试通过；
- [ ] Lint、类型检查、构建通过；
- [ ] 安全风险已确认或修复；
- [ ] Reviewer 人工复核通过。

资产 3：博客写作时的代码审校声明

> 本文示例代码用于讲解技术思路，已尽量补充安全与边界说明。实际生产环境中，请结合你的业务权限模型、数据安全要求、依赖版本、基础设施和团队规范进行二次审查。涉及认证、支付、隐私数据、生产密钥等高风险场景时，不建议直接复制示例代码上线。

---

十、结尾互动

AI 写代码正在从“新鲜玩具”变成“日常生产力工具”。但越是高效，越需要一套稳定的质量控制机制。真正靠谱的 AI 编程流程，不是让 AI 一次性生成完美代码，而是让 AI 参与“生成—审校—测试—修复—再验证”的闭环。

如果你正在团队里推广 AI 编程，可以先从本文这份 Checklist 开始：把它放进 PR 模板，把提示词固化到 AI Agent，把安全红线写进团队规范。这样，AI 不是替代 Reviewer，而是帮 Reviewer 更快发现问题。

欢迎在评论区聊聊：

1. 你遇到过最离谱的 AI 代码幻觉是什么？
2. 你们团队是否允许 AI 生成生产代码？
3. 如果要加一条“必查项”，你会加什么？

如果大家感兴趣，下一篇可以继续拆解：如何把 AI 代码审校 Checklist 做成自动化 PR Bot。