AI 生成的代码怎么把关？有哪些风险？

2026年阅读约 9 分钟面试指南 · AI面试

AI 面试 AI编程

AI编程面试题：AI生成代码的风险与把关，幻觉API与slopsquatting供应链攻击、安全漏洞、许可证污染、技能退化、review清单与团队防线，分三层讲解。

一句话总结

AI 代码的四大风险：幻觉 API/依赖包（调用不存在的函数、编造包名——衍生出 slopsquatting 供应链攻击）、安全漏洞（SQL 注入、硬编码密钥、缺失校验——训练数据里就有这些旧代码）、许可证污染（逐字复述带 GPL 的代码）、能跑但错（逻辑对需求的理解偏差，测试没覆盖就发现不了）。把关原则一句话：AI 产出走与人工代码完全相同的门禁，一步都不省。

初级理解

为什么不能直接信任：语言模型的目标是"生成统计上像正确代码的代码"，不是"正确的代码"。它没有真实执行过你给的场景——"看起来对"和"是对的"之间的差距，就是 review 要补的部分。

个人 review 清单（五项保底）：

1. 依赖真实性：import 的包/函数真的存在吗？在官方文档查过吗？ 2. 安全红线：SQL 拼接？密钥硬编码？用户输入未校验？日志打印敏感数据？ 3. 边界与异常：空值/超长/并发/失败路径处理了吗？ 4. 行为一致性：改动的公共方法，所有调用方都兼容吗？ 5. 测试真实有效：断言的是业务结果，还是"形式断言"？

反面案例记住一个：AI 生成的数据库工具函数用了字符串拼接 SQL，测试全绿（测试自己也没传恶意参数），上线后被扫描器抓出注入——"测试通过"不等于"安全"。

中级深入

幻觉 API 与幻觉包（slopsquatting，2025 年后必考）：AI 会自信地编造不存在的库函数，更危险的是编造不存在的包名——攻击者监控 AI 常编造的包名并提前抢注到 PyPI/npm（称为 slopsquatting），开发者照着 AI 建议安装就中招。防御：

新依赖引入必须走人工确认（官方仓库是否存在、维护活跃度、下载量）
锁文件（lockfile）+ 私有源白名单，CI 禁止运行时动态拉包
幻觉函数在编译/解释期就会暴露——所以"每小步都跑构建"是天然的幻觉探测器

安全风险的成因与对策：训练语料包含大量历史不安全代码（老教程、Stack Overflow 答案），AI 会"复刻"这些模式。对策：SAST 静态扫描（SonarQube/Semgrep）+ 密钥扫描（gitleaks）进 CI；鉴权/加密/支付类代码禁止 AI 直接生成后直接用，必须人写或逐行审。

许可证风险：模型可能逐字复述训练数据中的 GPL/AGPL 代码片段。企业对策：代码溯源扫描（如 fossa/scancode）抽样审计；内部规范要求 AI 辅助代码同样声明来源审查。

高级拓展

团队防线设计（资深岗答题框架）：

第一道（生成时）：规则文件约束（指定经过审计的库与写法）；私有化/企业版模型防止代码外泄
第二道（提交时）：PR 模板加"AI 产出"勾选项（促使 reviewer 提高警觉）；AI code review 作为第一轮筛子，人审聚焦设计与安全
第三道（CI）：测试覆盖率阈值、SAST、依赖与密钥扫描——所有代码同一标准，AI 产出没有豁免通道
第四道（运行时）：灰度发布 + 监控告警，兜住漏网之鱼

技能退化的管理视角：团队风险不是"个人不会写代码"，而是组织排查能力空洞化——当线上故障没人能脱离 AI 排查时就是危机。可操作做法：核心模块的"无 AI 演练"（定期让成员手写关键修复）、code review 时要求说明"为什么这样写"（检验理解而非接受）、新人前三个月限制 Agent 模式（先建立基础心智模型）。

注意：把 AI 代码标注出来不是歧视它，而是让 reviewer 分配注意力——就像区分"新人的 PR"和"资深同事的 PR"一样自然。

实战场景

场景一：review 一个 AI 生成的 PR（面试实操题）

检查顺序（15 分钟版）： 1. diff 范围 vs 任务描述——有没有"顺手改"的无关文件 2. 依赖变更——新包是否存在/必要/许可证干净 3. 安全敏感点——注入/密钥/权限校验 4. 异常与边界——错误处理是吞掉还是传播 5. 测试——是真断言还是形式断言，失败路径覆盖了吗 6. 最后跑 CI 全量，不接受"AI 说测试过了"

场景二：一次幻觉 API 事故复盘（讲故事模板）

// 现象：AI 生成的工具类调用了 commons-lang3 不存在的方法，编译失败 // 若是脚本语言（不编译）则上线才炸——更危险 // 复盘结论： // 1. 每次生成后立即构建（幻觉探测器前置） // 2. 团队规范写入规则文件：只用项目内已出现的库 // 3. CI 加 unused/unresolved 检查

场景三：给团队定 AI 使用规范（管理题）

# 一页纸规范（示例骨架） - 允许：样板代码、单测、重构建议、文档生成、日志分析 - 人工主导：鉴权/支付/加密/资损路径、架构决策 - 强制：同一 review 门禁、CI 全绿、新依赖人工确认 - 禁止：敏感数据贴给外部工具、AI 产出免审合入 - 度量：周期时间/返工率，季度复盘规范本身

面试模拟

Q：AI 生成的代码和资深工程师写的，review 时有什么不同？

A：关注点分布不同。资深的 PR 重点看设计取舍；AI 的 PR 重点看三处：① 幻觉（API/依赖/配置项是否真实存在）；② "聪明但错"的隐藏逻辑（AI 喜欢写出能跑但曲解需求的实现）；③ 范围外改动（Agent 常顺手重构）。相同点：安全、边界、测试有效性的标准完全一致。一句话总结——对 AI 代码，我的默认假设是"有错待证"，对人反而先信任。

Q：什么是 slopsquatting？怎么防？

A：AI 幻觉出的不存在的包名被攻击者抢注发布恶意版本，开发者按 AI 建议安装即中招——是 AI 时代特有的供应链攻击面。防御：新依赖人工核实（官方源存在性、维护者、下载量）、锁文件 + 私有源白名单、CI 禁止动态解析依赖、对 AI 建议的新包保持"默认不装"的姿态。组织级可以维护内部经过审计的依赖目录。

Q：长期用 AI，工程师基本功退化怎么办？

A：先承认风险真实存在（调试能力、系统直觉靠练习不靠阅读）。个人层面：核心技能刻意保留"裸写"练习、review AI 代码时弄懂每一行而不是只看结果、定期做无 AI 排障演练。团队层面：新人成长期限制 Agent 自主模式（先手写建立心智模型）、把"能脱离 AI 讲清系统"作为晋升答辩的一部分。结论：把 AI 当杠杆而不是拐杖——杠杆放大能力，拐杖替代能力。