收益：
- 能够在三层验证人工智能输出：准确性、安全性和来源/许可
- 能够利用安全的模具和工具来规避注射、幻包和埋藏秘密等风险
- 能够将安全关键代码提交给有能力的工程师批准并了解责任的不可转移性
生成 AI 代码很容易；信任他是昂贵的。本单元的唯一目的是将我们在之前所有单元中重复的“验证”原则转变为系统的工程学科。因为人工智能生成的代码，即使乍一看似乎是正确的，也会带来三种不同的危险：无法工作/不正确（幻觉）、不安全（漏洞）以及携带法律/许可风险。了解这三者并为他们每个人建立一扇门将使您成为一名专业人士。
在这里，我们从三个层面考虑“验证”：正确性（代码是否真正完成工作？）、安全性（是否能够承受恶意输入？）以及出处/许可（我是否有权使用该代码？）。每一层都有自己的控制手段，任何一个都不能用“AI就是这么说的”来绕过。
三层风险
1. 准确性风险（幻觉）。该模型可能会调用不存在的函数、滥用 API、默默地绕过边缘情况。该代码看起来“合理”，但实际上是错误的。解决方法：编译、测试、静态分析和目视检查。
2、安全风险。 AI 可以在训练数据中重复不安全的模式：容易受到 SQL 注入的查询、未经身份验证的用户输入、弱加密、不安全的反序列化、开放重定向。该代码可以工作，但容易受到攻击。解毒剂：以安全为中心的审查、自动扫描仪 (SAST) 以及实施已知的安全模式。
3. 来源/许可风险。人工智能可能会产生与受版权保护或限制性许可代码非常相似的输出，或者可能会暗示不适当的许可依赖性。解决方法：依赖性和许可证检查、原创性检查、公司政策。
注意：这三个风险中最隐蔽的是安全风险；因为代码可以通过测试，在生产中顺利运行，并且只有当攻击者发现该漏洞时，该漏洞才会被暴露。 “工作”与“安全”不同。
一步一步：分层身份验证门
- 带着理解去阅读。在接受之前真正理解代码；不要合并你不理解的代码。如果您无法解释“为什么它有效”，则它尚未得到验证。
- 验证它是否存在。确认使用的每个函数、API 和包确实存在并且正确使用（幻觉门）。
- 运行自动化工具。编译器、linter（样式/错误扫描器）、类型检查器、单元测试，如果可能的话还包括 SAST（静态应用程序安全测试 - 扫描源代码中是否存在漏洞的工具）。
- 从安全角度来看。输入是否经过验证？查询是否参数化？秘密被埋没了吗？有权限控制吗？
- 检查来源和许可证。新的依赖项是否已获得许可？输出看起来与已知的代码库过于相似吗？
- 如果它对安全至关重要，请请求专家批准。必须由精通身份验证、支付、加密、访问控制等领域的工程师进行独立审查。
三个迷你箱
案例 1 — 在检查口发现 SQL 注入。 AI 生成的代码将用户输入直接连接到搜索端点的 SQL 查询中（“... WHERE name = '” + q + “'”）。该代码正在运行并通过了测试。以安全为重点的检查和 SAST 扫描发现了这一点；它被转换为参数化查询（准备好的语句）。如果没有被发现，这将是一个典型的数据泄露漏洞。
案例 2 — 幻觉包。 AI 为任务建议了一个不存在的 npm 包（fast-safe-parse）。当开发人员尝试安装它时，找不到该包。更糟糕的是：在某些情况下，攻击者可以用真实的恶意包填充此类“幽灵”包名称（依赖关系混淆）。教训：根据官方注册表和下载/维护历史记录验证每个推荐的软件包。
情况 3 — 许可证不兼容。 AI 建议的一个漂亮的配套库具有强大的 Copyleft 许可证，但与该机构的产品许可证不兼容。依赖许可证扫描报告了这一点；该团队用合适的替代方案替换了许可证。如果没有验证，产品分销就会产生法律负担。
四个可复制模板
入园前自检：
在接受以下 AI 生成的代码之前，请检查：1）它使用的每个函数/API/包是否确实存在？标记嫌疑人。2) 是否存在任何未经验证的输入、SQL/命令串联、隐藏的秘密、弱加密？3) 有哪些未解决的错误/边缘情况？将每个发现标记为“确定/可能”并建议修复。{{code}}
以安全为重点的审查：
从安全角度检查此代码。查找常见的 OWASP 风格漏洞：注入、身份验证/授权损坏、敏感数据泄露、不安全的反序列化、未经身份验证的重定向。对于每个发现：风险、利用场景、补救措施。这是初步筛选；将关键发现提交给人类安全审查。{{code}}
依赖性和许可证检查：
列出此代码添加/建议的依赖项。对于每个：该包是否确实存在，是否得到维护，其典型许可证是什么（必须验证），以及该项目是否确实需要它，或者可以使用现有工具来完成吗？{{代码或依赖项列表}}
安全模板拼装（生产中）：
为{{task}}编写代码。强制性安全规则：- 验证/清理所有外部输入。- 仅在数据库访问中使用参数化查询。- 不要在代码中嵌入秘密；假设环境变量/秘密管理器 - 不要吞下错误；有意义地考虑一下。在 3 项中解释代码如何符合这些规则。
弱提示/强提示
弱：“编写一个按用户名搜索的查询。” （可能会出现容易被注入的代码。）
强：“编写一个按用户名搜索的函数。永远不要将用户输入作为字符串连接到查询中；使用参数化查询（准备好的语句）。验证输入的长度和字符。用两句话解释为什么代码禁止注入。”
强版本从一开始就强制采用安全模式；因此，它可以确保漏洞根本不会发生，而不是稍后才发现。但是，必须让生成的代码通过验证门。
认证层
工具/方法
“AI说”就够了吗？
准确度
编译、测试、目视检查
不
API/封装现实
官方文件/记录控制
不
安全性
SAST、安全审查
不
许可/来源
依赖性和许可证检查
不
安全关键逻辑
专家工程师认可
绝对不是
责任不可转移
由人工智能工具生成的代码引起的错误、漏洞或违规行为的责任属于组装和分发该代码的团队，而不是工具提供商。这是一个专业事实，也是一个法律事实：你签字。因此，“人工智能创造了它”不是借口，而是格外谨慎的理由。特别是在安全关键系统中，人工智能输出在任何情况下都不能替代合格工程师的审查和批准；人工智能最多提供了一个可以加快工程师速度的蓝图。
提示：在您的团队中创建一个简短的清单，您将其称为“AI 生成代码的验证门”（构建 + 测试 + 安全扫描 + 目视检查）。一旦这个门成为一种习惯，速度的损失就最小，风险的降低也最大。
常见错误
- 将“有效”与“安全”混淆。通过测试的代码可能容易受到攻击。
- 使用包/API 而不验证它。幻觉数据包不仅会损坏，还会带来安全风险。
- 绕过自动化工具。 Linter、类型检查器和 SAST 可以廉价地捕获人类遗漏的内容。
- 忽略许可证。不当的许可依赖性会给分发带来法律负担。
- 把责任推到车辆身上。团队负责生产中的代码； “人工智能做到了”并不是借口。
综上所述
接受人工智能输出需要三层验证：正确性（编译、测试、目视检查）、安全性（SAST 和以安全为重点的审查）和来源/许可证（依赖性检查）。确认使用的每个包和 API 确实存在，从一开始就强制实施安全模式，并提交安全关键代码以供合格工程师批准。 “有效”并不意味着安全，“人工智能产生”并不免除责任。验证门的代价是专业，而不是速度。
应用任务
故意给人工智能一个安全敏感的任务（例如“通过用户输入搜索数据库的功能”），这次不强加安全模式。通过“预准入自我审核”和“安全重点审查”模板传递传入代码：是否存在任何注入、隐藏秘密、幻觉数据包或未经身份验证的输入？然后使用“安全模式强加”模板再次询问相同的任务并比较两个输出。如果可能，运行 linter/SAST 工具并将结果与 AI 的自我调节进行比较。
清单
- [ ] 我在三层验证人工智能输出：准确性、安全性和许可。
- [ ] 我确认所使用的每个函数、API 和包均确实存在。
- [ ] 我运行编译、测试、linter，如果可能的话，还运行 SAST 工具。
- [ ] 我从一开始就施加安全模式（参数化查询、输入验证、秘密管理）。
- [ ] 我检查新依赖项的许可和要求。
- [ ] 我正在提交安全关键代码以供主管工程师批准，并且我了解我对此负责。