信任AI生成代码前必做的7项检查
内容提要
AI编程助手能快速生成大量看似可运行的代码，但可能存在语义错误。文章建议合并前做七项检查：用Git查看改动范围，避免无关修改；用编译器、linter和类型检查器验证；核实新依赖和API真实存在，警惕“包幻觉”与投毒风险；测试正常、边界、非法和失败场景；审查SQL注入、权限、路径、密钥等安全边界；检查异常处理、超时、重试和资源清理；判断代码是否必要、是否引入多余复杂度。核心原则是“生成后验证”，而非盲目信任。
延伸解读
AI代码的“包幻觉”风险与防范
文章指出，AI可能虚构看似合理的包名，2025年一项研究分析了57.6万个LLM生成的代码样本，发现商业模型的包幻觉率为5.2%，开源模型高达21.7%。这种幻觉可能被利用进行“slopsquatting”攻击：攻击者注册常被幻觉的包名，诱导开发者安装。因此，AI新增依赖时，务必用pip index versions或npm view独立验证包是否存在、维护者、更新时间及版本匹配性，并检查锁文件变化和已知漏洞。
测试应覆盖异常与失败场景，而非仅正常路径
AI生成的测试常只覆盖正常路径，因为示例和文档中最常见的就是正常情况。文章建议对每个生成的功能至少测试四类输入：正常、边界、非法和失败条件。例如折扣函数需测试折扣为0、100、负数、超过100，以及价格为0、None或字符串的情况。此外，要警惕AI通过删除测试或弱化断言来“修复”失败测试。对于关键函数，可先写测试再让模型实现，确保代码能应对用户、网络、数据库等意外行为。
安全边界需用对抗性思维审查
功能正确不等于安全。文章举例，一个拼接SQL查询的函数可能通过所有单元测试，但仍存在注入风险。当AI代码涉及用户输入、认证、数据库、文件路径、子进程、外部URL等时，应切换为对抗性思维：检查输入是否可控、能否越权访问、路径能否逃逸、查询能否参数化、命令能否执行任意输入、URL是否指向内部服务、权限是否在服务端校验。同时运行Semgrep、Bandit等静态安全工具，并搜索是否硬编码了密钥。
失败路径与代码必要性：最后的把关
AI代码在一切正常时往往表现良好，因此要刻意检查失败路径。例如捕获所有异常并返回空字典的代码看似健壮，实则隐藏超时、连接失败、认证错误、无效JSON等问题，增加调试难度。应检查重试是否无限、超时是否设置、事务是否回滚、异步任务是否正确等待、共享状态是否并发安全、资源是否释放。最后，判断代码是否必要：是否引入了多余抽象、重复工具函数或可用标准库替代的依赖。优化目标不是行数最少，而是新增复杂度最小。
Q&A
为什么AI生成的代码即使能编译通过也不能直接信任？
AI生成的代码可能语义错误，例如对API、授权规则、边界情况或依赖做出错误假设。它可能编译通过、测试通过、变量名清晰，但实际逻辑不正确。GitHub警告AI生成的代码可能语义不正确，建议合并前仔细审查和测试。
如何用Git检查AI生成的代码改动范围？
使用git status、git diff --stat和git diff查看改动。git diff --stat能快速显示改动规模。如果任务只需修改两个文件，但diff显示12个文件变更、437行插入和186行删除，应暂停并检查是否包含无关文件、删除的测试、权限变更、依赖文件修改或隐藏的大规模重构。
AI生成的代码可能引入哪些依赖风险？如何防范？
AI可能虚构包名（包幻觉），2025年研究显示商业模型幻觉率5.2%，开源模型21.7%。攻击者可能注册这些虚构包名进行投毒（slopsquatting）。防范方法：用pip index versions或npm view验证包是否存在、是否官方维护、版本是否匹配、是否引入漏洞，并检查锁文件变化。
测试AI生成的代码时应该覆盖哪些场景？
除了正常路径，必须测试边界输入、非法输入和失败条件。例如对于折扣函数，应测试折扣为0、100、-10、150，价格为0、None、字符串等情况。对于API端点，应测试有效请求、缺失字段、格式错误字段、未授权请求以及数据库/服务故障。AI常只生成正常路径测试，需补充其他场景。
AI生成的代码在安全性方面需要检查哪些点？
当代码涉及用户输入、认证、数据库、文件、shell命令或外部URL时，需以对抗思维检查SQL注入、权限绕过、路径遍历、命令注入、不安全反序列化、密钥硬编码等。可使用Semgrep、Bandit、CodeQL等工具扫描，并搜索API密钥、密码等秘密信息。
如何评估AI生成的代码是否必要？
检查代码是否引入了不必要的抽象、包装器、辅助函数或重复工具。问：是否新增了抽象？现有函数能否实现？是否用了标准库已有的功能？能否减少30%代码而不失清晰？六个月后能否理解？优化目标是以最小的新增复杂度解决问题，而非最少行数。
