AI 写代码不放心给技术博客准备一份代码审校清单面向“AI 爪客”CSDN 技术博客的深度技术博文草稿。本文适合写给正在使用 AI 辅助编码、代码生成、单元测试生成、自动重构的开发者与技术负责人。摘要AI 编程助手已经能快速生成业务代码、脚本、测试用例和文档但“能跑”不等于“可靠”“看起来对”也不等于“可上线”。很多团队在引入 AI 写代码后会遇到类似问题代码风格不统一、边界条件遗漏、安全风险被忽略、依赖版本不匹配、生成的测试只覆盖了理想路径甚至把伪造 API、过期语法和隐性性能问题一起带进仓库。本文提供一份可直接复用的AI 代码审校清单帮助开发者从需求一致性、正确性、安全性、可维护性、性能、测试、工程化、合规边界等角度系统审查 AI 生成代码。你可以把它用于技术博客示例、团队 Code Review 模板、AI Agent 工作流也可以直接复制文末“资产复制区”中的提示词与 Checklist。一、问题背景1. AI 写代码的典型幻觉AI 生成代码常见问题并不只是“语法错”。更棘手的是以下几类需求理解偏差用户要求“支持分页查询”AI 可能只实现limit没有处理offset、默认页码、最大页大小和非法参数。伪造依赖或 APIAI 可能编造一个看似合理但实际不存在的方法例如client.fetchAllUsersWithCache()。边界条件遗漏只处理正常输入不处理空列表、空字符串、超大文件、并发请求、网络超时、时区差异等。安全风险隐藏在“便捷实现”里例如直接拼接 SQL、把密钥写进代码、关闭 TLS 校验、对用户输入不做转义、日志打印敏感信息。测试样例过于乐观AI 生成的测试经常只覆盖 happy path断言也可能过弱甚至测试逻辑和业务代码存在同源错误。工程集成不完整单文件能跑但放进真实项目后与 lint、类型检查、CI、配置加载、权限模型、日志规范不兼容。2. 为什么技术博客需要“审校清单”技术博客中的代码具有传播性。读者可能会直接复制示例到项目中因此博客作者不仅要展示“如何实现”还要说明“如何判断实现是否可靠”。一份好的 AI 代码审校清单可以帮助博客内容从“炫技演示”升级为“工程实践”让示例代码更可信帮助读者形成审查习惯降低错误代码被复制传播的风险体现作者对安全、质量和工程边界的责任感。二、最终效果预览读完本文后你将得到三类可复用资产一套 AI 生成代码审校流程先对齐需求再检查正确性再验证安全、性能、可维护性最后补齐测试与工程化集成。一份 Markdown 版代码审校 Checklist可直接粘贴到 CSDN、GitHub PR 模板、语雀/飞书文档适合人工 Code Review也适合喂给 AI 做二次审查。一组提示词模板用于让 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 生成代码的 diffIDE推荐开启类型检查、Lint 和安全提示单元测试框架如 JUnit、pytest、Jest、Go test代码扫描工具如 ESLint、Pylint、Bandit、Semgrep、SonarQube依赖漏洞扫描如 npm audit、pip-audit、OWASP Dependency-Check、SnykCI/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){constkeywordreq.query.keyword||;constpagereq.query.page||1;constpageSizereq.query.pageSize||20;constsqlSELECT * FROM users WHERE name LIKE %${keyword}% LIMIT${pageSize}OFFSET${(page-1)*pageSize};constusersawaitdb.query(sql);res.json({users});});这段代码看起来简洁但问题很多keyword直接拼接进 SQL存在 SQL 注入风险page、pageSize未转换为数字可能导致类型问题未限制pageSize最大值可能造成性能风险未处理负数、零、超大页码未返回总数未处理数据库异常SELECT *可能返回敏感字段没有测试。审校后的改进示例app.get(/users/search,async(req,res,next){try{constkeywordString(req.query.keyword||).trim();constpageMath.max(Number.parseInt(String(req.query.page||1),10),1);constrawPageSizeNumber.parseInt(String(req.query.pageSize||20),10);constpageSizeMath.min(Math.max(rawPageSize||20,1),100);constoffset(page-1)*pageSize;constlikeKeyword%${keyword}%;constcountResultawaitdb.query(SELECT COUNT(*)::int AS total FROM users WHERE name ILIKE $1,[likeKeyword]);constuserResultawaitdb.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);}});这个版本做了几件关键改进使用参数化查询降低注入风险对分页参数做了数字转换和范围限制避免SELECT *只返回必要字段补充总数查询使用统一异常处理保留进一步测试和索引优化空间。审校时可以追问 AI 的问题你可以要求 AI 对代码逐项回答请基于以下需求和代码进行审校 1. 代码是否完全满足需求如果不满足请列出缺口。 2. 是否存在安全风险请按高/中/低分级。 3. 是否存在边界条件遗漏 4. 是否存在性能瓶颈 5. 是否需要补充测试请给出测试用例列表。 6. 是否建议合并请给出明确结论。六、提示词模板下面给出几组可以直接复用的 Prompt。模板 1AI 生成代码自查你是资深软件工程师。请对下面这段 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 无法判断“代码是否实现了该实现的东西”。 **排查方式**审校时同时提供需求、接口约定、数据结构、错误码规范、权限要求。 ### 错误 2AI 生成的测试没有真实断言 **现象**测试只检查“不报错”没有验证业务结果。 **示例** 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 审校不能只停留在文本层面。更可靠的做法是# 示例不同项目命令不同请按实际情况调整npmrun lintnpmrun typechecknpmtestnpmaudit对于 Python 项目可以类似执行ruff check.pytest pip-audit九、资产复制区本节内容可以直接复制到博客、团队文档或 PR 模板中。资产 1AI 代码审校 Checklist# AI 代码审校 Checklist ## 1. 需求一致性 - [ ] 代码是否完整实现需求 - [ ] 是否存在擅自扩展、遗漏或误解需求 - [ ] 输入、输出、错误码、状态码是否符合约定 - [ ] 是否考虑权限、角色、租户、数据范围等业务规则 ## 2. 正确性与边界条件 - [ ] 正常路径是否正确 - [ ] 空值、空数组、空字符串是否处理 - [ ] 非法输入是否校验 - [ ] 极大值、极小值、分页边界是否处理 - [ ] 时间、时区、金额、精度是否处理正确 - [ ] 并发、重复提交、幂等性是否考虑 ## 3. 安全性 - [ ] 是否存在 SQL/NoSQL/命令注入风险 - [ ] 是否存在 XSS、SSRF、路径穿越、反序列化风险 - [ ] 是否正确做了认证和授权 - [ ] 是否可能发生越权访问 - [ ] 是否泄露密码、Token、密钥、手机号、身份证号等敏感信息 - [ ] 日志、错误信息是否脱敏 - [ ] 文件上传、下载、解析是否有限制 - [ ] 加密、签名、随机数是否使用安全方案 ## 4. 性能与资源 - [ ] 是否存在 N1 查询 - [ ] 是否有不必要的全表扫描或 SELECT * - [ ] 是否限制分页大小和上传文件大小 - [ ] 是否存在内存一次性加载大文件的问题 - [ ] 外部 API 调用是否设置超时、重试和熔断 - [ ] 是否需要索引、缓存或异步处理 ## 5. 可维护性 - [ ] 命名是否清晰 - [ ] 函数是否过长或职责过多 - [ ] 是否存在重复代码 - [ ] 配置是否硬编码 - [ ] 是否符合项目目录结构和编码规范 - [ ] 注释是否解释了必要的业务原因而不是重复代码 ## 6. 测试质量 - [ ] 是否有单元测试 - [ ] 是否有集成测试或接口测试 - [ ] 是否覆盖异常路径和边界值 - [ ] 断言是否足够具体 - [ ] Mock 是否合理是否掩盖真实问题 - [ ] 测试是否能在 CI 中稳定运行 ## 7. 工程化与发布 - [ ] 是否通过 Lint、格式化、类型检查 - [ ] 是否通过构建和测试 - [ ] 是否兼容当前依赖版本 - [ ] 是否补充配置、迁移脚本、文档 - [ ] 是否具备日志、监控、告警和回滚方案 - [ ] 是否确认未提交密钥、隐私数据或内部敏感信息 ## 8. 合并结论 - [ ] 可以直接合并 - [ ] 修改后合并 - [ ] 不建议合并 结论说明 【填写风险、原因和修复建议】资产 2AI Reviewer 输出模板# AI Reviewer 审校报告 ## 总体结论 - 风险等级高 / 中 / 低 - 是否阻塞合并是 / 否 - 主要原因 ## 问题清单 | 编号 | 等级 | 文件/位置 | 问题描述 | 影响 | 修复建议 | |---|---|---|---|---|---| | 1 | 高 | | | | | ## 测试建议 - [ ] 正常路径 - [ ] 异常路径 - [ ] 边界输入 - [ ] 安全场景 - [ ] 性能场景 ## 验收标准 - [ ] 所有阻塞问题已修复 - [ ] 单元测试和集成测试通过 - [ ] Lint、类型检查、构建通过 - [ ] 安全风险已确认或修复 - [ ] Reviewer 人工复核通过。资产 3博客写作时的代码审校声明 本文示例代码用于讲解技术思路已尽量补充安全与边界说明。实际生产环境中请结合你的业务权限模型、数据安全要求、依赖版本、基础设施和团队规范进行二次审查。涉及认证、支付、隐私数据、生产密钥等高风险场景时不建议直接复制示例代码上线。十、结尾互动AI 写代码正在从“新鲜玩具”变成“日常生产力工具”。但越是高效越需要一套稳定的质量控制机制。真正靠谱的 AI 编程流程不是让 AI 一次性生成完美代码而是让 AI 参与“生成—审校—测试—修复—再验证”的闭环。如果你正在团队里推广 AI 编程可以先从本文这份 Checklist 开始把它放进 PR 模板把提示词固化到 AI Agent把安全红线写进团队规范。这样AI 不是替代 Reviewer而是帮 Reviewer 更快发现问题。欢迎在评论区聊聊你遇到过最离谱的 AI 代码幻觉是什么你们团队是否允许 AI 生成生产代码如果要加一条“必查项”你会加什么如果大家感兴趣下一篇可以继续拆解如何把 AI 代码审校 Checklist 做成自动化 PR Bot。
AI 写代码不放心？给技术博客准备一份代码审校清单
发布时间：2026/5/28 14:36:20
AI 写代码不放心给技术博客准备一份代码审校清单面向“AI 爪客”CSDN 技术博客的深度技术博文草稿。本文适合写给正在使用 AI 辅助编码、代码生成、单元测试生成、自动重构的开发者与技术负责人。摘要AI 编程助手已经能快速生成业务代码、脚本、测试用例和文档但“能跑”不等于“可靠”“看起来对”也不等于“可上线”。很多团队在引入 AI 写代码后会遇到类似问题代码风格不统一、边界条件遗漏、安全风险被忽略、依赖版本不匹配、生成的测试只覆盖了理想路径甚至把伪造 API、过期语法和隐性性能问题一起带进仓库。本文提供一份可直接复用的AI 代码审校清单帮助开发者从需求一致性、正确性、安全性、可维护性、性能、测试、工程化、合规边界等角度系统审查 AI 生成代码。你可以把它用于技术博客示例、团队 Code Review 模板、AI Agent 工作流也可以直接复制文末“资产复制区”中的提示词与 Checklist。一、问题背景1. AI 写代码的典型幻觉AI 生成代码常见问题并不只是“语法错”。更棘手的是以下几类需求理解偏差用户要求“支持分页查询”AI 可能只实现limit没有处理offset、默认页码、最大页大小和非法参数。伪造依赖或 APIAI 可能编造一个看似合理但实际不存在的方法例如client.fetchAllUsersWithCache()。边界条件遗漏只处理正常输入不处理空列表、空字符串、超大文件、并发请求、网络超时、时区差异等。安全风险隐藏在“便捷实现”里例如直接拼接 SQL、把密钥写进代码、关闭 TLS 校验、对用户输入不做转义、日志打印敏感信息。测试样例过于乐观AI 生成的测试经常只覆盖 happy path断言也可能过弱甚至测试逻辑和业务代码存在同源错误。工程集成不完整单文件能跑但放进真实项目后与 lint、类型检查、CI、配置加载、权限模型、日志规范不兼容。2. 为什么技术博客需要“审校清单”技术博客中的代码具有传播性。读者可能会直接复制示例到项目中因此博客作者不仅要展示“如何实现”还要说明“如何判断实现是否可靠”。一份好的 AI 代码审校清单可以帮助博客内容从“炫技演示”升级为“工程实践”让示例代码更可信帮助读者形成审查习惯降低错误代码被复制传播的风险体现作者对安全、质量和工程边界的责任感。二、最终效果预览读完本文后你将得到三类可复用资产一套 AI 生成代码审校流程先对齐需求再检查正确性再验证安全、性能、可维护性最后补齐测试与工程化集成。一份 Markdown 版代码审校 Checklist可直接粘贴到 CSDN、GitHub PR 模板、语雀/飞书文档适合人工 Code Review也适合喂给 AI 做二次审查。一组提示词模板用于让 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 生成代码的 diffIDE推荐开启类型检查、Lint 和安全提示单元测试框架如 JUnit、pytest、Jest、Go test代码扫描工具如 ESLint、Pylint、Bandit、Semgrep、SonarQube依赖漏洞扫描如 npm audit、pip-audit、OWASP Dependency-Check、SnykCI/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){constkeywordreq.query.keyword||;constpagereq.query.page||1;constpageSizereq.query.pageSize||20;constsqlSELECT * FROM users WHERE name LIKE %${keyword}% LIMIT${pageSize}OFFSET${(page-1)*pageSize};constusersawaitdb.query(sql);res.json({users});});这段代码看起来简洁但问题很多keyword直接拼接进 SQL存在 SQL 注入风险page、pageSize未转换为数字可能导致类型问题未限制pageSize最大值可能造成性能风险未处理负数、零、超大页码未返回总数未处理数据库异常SELECT *可能返回敏感字段没有测试。审校后的改进示例app.get(/users/search,async(req,res,next){try{constkeywordString(req.query.keyword||).trim();constpageMath.max(Number.parseInt(String(req.query.page||1),10),1);constrawPageSizeNumber.parseInt(String(req.query.pageSize||20),10);constpageSizeMath.min(Math.max(rawPageSize||20,1),100);constoffset(page-1)*pageSize;constlikeKeyword%${keyword}%;constcountResultawaitdb.query(SELECT COUNT(*)::int AS total FROM users WHERE name ILIKE $1,[likeKeyword]);constuserResultawaitdb.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);}});这个版本做了几件关键改进使用参数化查询降低注入风险对分页参数做了数字转换和范围限制避免SELECT *只返回必要字段补充总数查询使用统一异常处理保留进一步测试和索引优化空间。审校时可以追问 AI 的问题你可以要求 AI 对代码逐项回答请基于以下需求和代码进行审校 1. 代码是否完全满足需求如果不满足请列出缺口。 2. 是否存在安全风险请按高/中/低分级。 3. 是否存在边界条件遗漏 4. 是否存在性能瓶颈 5. 是否需要补充测试请给出测试用例列表。 6. 是否建议合并请给出明确结论。六、提示词模板下面给出几组可以直接复用的 Prompt。模板 1AI 生成代码自查你是资深软件工程师。请对下面这段 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 无法判断“代码是否实现了该实现的东西”。 **排查方式**审校时同时提供需求、接口约定、数据结构、错误码规范、权限要求。 ### 错误 2AI 生成的测试没有真实断言 **现象**测试只检查“不报错”没有验证业务结果。 **示例** 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 审校不能只停留在文本层面。更可靠的做法是# 示例不同项目命令不同请按实际情况调整npmrun lintnpmrun typechecknpmtestnpmaudit对于 Python 项目可以类似执行ruff check.pytest pip-audit九、资产复制区本节内容可以直接复制到博客、团队文档或 PR 模板中。资产 1AI 代码审校 Checklist# AI 代码审校 Checklist ## 1. 需求一致性 - [ ] 代码是否完整实现需求 - [ ] 是否存在擅自扩展、遗漏或误解需求 - [ ] 输入、输出、错误码、状态码是否符合约定 - [ ] 是否考虑权限、角色、租户、数据范围等业务规则 ## 2. 正确性与边界条件 - [ ] 正常路径是否正确 - [ ] 空值、空数组、空字符串是否处理 - [ ] 非法输入是否校验 - [ ] 极大值、极小值、分页边界是否处理 - [ ] 时间、时区、金额、精度是否处理正确 - [ ] 并发、重复提交、幂等性是否考虑 ## 3. 安全性 - [ ] 是否存在 SQL/NoSQL/命令注入风险 - [ ] 是否存在 XSS、SSRF、路径穿越、反序列化风险 - [ ] 是否正确做了认证和授权 - [ ] 是否可能发生越权访问 - [ ] 是否泄露密码、Token、密钥、手机号、身份证号等敏感信息 - [ ] 日志、错误信息是否脱敏 - [ ] 文件上传、下载、解析是否有限制 - [ ] 加密、签名、随机数是否使用安全方案 ## 4. 性能与资源 - [ ] 是否存在 N1 查询 - [ ] 是否有不必要的全表扫描或 SELECT * - [ ] 是否限制分页大小和上传文件大小 - [ ] 是否存在内存一次性加载大文件的问题 - [ ] 外部 API 调用是否设置超时、重试和熔断 - [ ] 是否需要索引、缓存或异步处理 ## 5. 可维护性 - [ ] 命名是否清晰 - [ ] 函数是否过长或职责过多 - [ ] 是否存在重复代码 - [ ] 配置是否硬编码 - [ ] 是否符合项目目录结构和编码规范 - [ ] 注释是否解释了必要的业务原因而不是重复代码 ## 6. 测试质量 - [ ] 是否有单元测试 - [ ] 是否有集成测试或接口测试 - [ ] 是否覆盖异常路径和边界值 - [ ] 断言是否足够具体 - [ ] Mock 是否合理是否掩盖真实问题 - [ ] 测试是否能在 CI 中稳定运行 ## 7. 工程化与发布 - [ ] 是否通过 Lint、格式化、类型检查 - [ ] 是否通过构建和测试 - [ ] 是否兼容当前依赖版本 - [ ] 是否补充配置、迁移脚本、文档 - [ ] 是否具备日志、监控、告警和回滚方案 - [ ] 是否确认未提交密钥、隐私数据或内部敏感信息 ## 8. 合并结论 - [ ] 可以直接合并 - [ ] 修改后合并 - [ ] 不建议合并 结论说明 【填写风险、原因和修复建议】资产 2AI Reviewer 输出模板# AI Reviewer 审校报告 ## 总体结论 - 风险等级高 / 中 / 低 - 是否阻塞合并是 / 否 - 主要原因 ## 问题清单 | 编号 | 等级 | 文件/位置 | 问题描述 | 影响 | 修复建议 | |---|---|---|---|---|---| | 1 | 高 | | | | | ## 测试建议 - [ ] 正常路径 - [ ] 异常路径 - [ ] 边界输入 - [ ] 安全场景 - [ ] 性能场景 ## 验收标准 - [ ] 所有阻塞问题已修复 - [ ] 单元测试和集成测试通过 - [ ] Lint、类型检查、构建通过 - [ ] 安全风险已确认或修复 - [ ] Reviewer 人工复核通过。资产 3博客写作时的代码审校声明 本文示例代码用于讲解技术思路已尽量补充安全与边界说明。实际生产环境中请结合你的业务权限模型、数据安全要求、依赖版本、基础设施和团队规范进行二次审查。涉及认证、支付、隐私数据、生产密钥等高风险场景时不建议直接复制示例代码上线。十、结尾互动AI 写代码正在从“新鲜玩具”变成“日常生产力工具”。但越是高效越需要一套稳定的质量控制机制。真正靠谱的 AI 编程流程不是让 AI 一次性生成完美代码而是让 AI 参与“生成—审校—测试—修复—再验证”的闭环。如果你正在团队里推广 AI 编程可以先从本文这份 Checklist 开始把它放进 PR 模板把提示词固化到 AI Agent把安全红线写进团队规范。这样AI 不是替代 Reviewer而是帮 Reviewer 更快发现问题。欢迎在评论区聊聊你遇到过最离谱的 AI 代码幻觉是什么你们团队是否允许 AI 生成生产代码如果要加一条“必查项”你会加什么如果大家感兴趣下一篇可以继续拆解如何把 AI 代码审校 Checklist 做成自动化 PR Bot。
