Vibe Coding 安全清单：给用 AI 写代码的团队十条纪律 · 行业洞察

效率提上来了，纪律还没跟上

Vibe Coding——用自然语言描述意图、让 AI 生成实现——已经不是极客的玩具。在不少团队里，它承担了从脚手架搭建到业务逻辑实现的大部分工作量。

问题在于，安全流程的设计前提还是“代码由人写”：人会记得自己引了哪个库，会对陌生依赖产生警觉，会在复制 Stack Overflow 代码时犹豫一下。AI 不会。它以极高的置信度输出看起来完全合理的代码，包括并不存在的包名、带着原始许可证的开源片段，以及在训练数据里学到的过时写法。

这不是反对用 AI 写代码。恰恰相反：正因为它会长期存在且比重还会上升，配套纪律必须补齐。下面十条按开发流程的五个环节组织，每条都可以直接写进团队规范。

纪律 1 · 在提示词里写明约束，而不是事后修补。

同样是“写一个文件上传接口”，加上“使用项目已有的 validation 工具，不引入新依赖，路径处理需防目录穿越”，得到的代码质量差异是数量级的。把团队的技术栈约束、安全要求、依赖策略沉淀成提示词模板，比在代码审查时逐个纠正高效得多。

纪律 2 · 敏感上下文不进公共模型。

生产环境配置、真实密钥、客户数据、未公开的业务逻辑——这些内容贴进公共聊天机器人的那一刻，就已经离开了你的可控范围。团队需要明确的数据分级：哪些代码域可以用公共 AI 工具，哪些必须用企业内部部署的模型。这条纪律的执行难点不在技术，在于提供足够好用的合规替代品，否则开发者一定会绕过。

纪律 3 · 把 AI 当作高产的初级工程师，而不是资深专家。

初级工程师的代码要过 review，AI 生成的代码同样要过。区别在于 AI 的产出速度快得多，所以审查机制必须自动化——靠人力逐行读完 AI 生成的代码，团队会先被拖垮。

纪律 4 · 生成即扫描，不要等到提交。

风险发现得越晚，修复成本越高。理想的形态是 IDE 内实时检测：AI 写下一段代码的同时，安全引擎就完成了污点分析、依赖检查和许可证比对。这也是“安全左移”在 AI 时代的必然延伸——左移到代码生成的那一刻。

纪律 5 · 建立依赖白名单，AI 只能在白名单内选择。

AI 引入依赖的判断依据是训练数据里的流行度，不是你们团队的技术栈规划、许可证策略或安全基线。让 AI 在受控的依赖集合内工作，比事后逐个审查它引入的库现实得多。

纪律 6 · 对幻觉包做主动防御。

AI 会以完全自信的语气引用并不存在的包名。攻击者已经在系统性地注册这些高频出现的幻觉名称——这就是 slopsquatting。防御有三层：安装前校验包是否真实存在且有合理的发布历史；使用内部制品仓库镜像并配置内部优先解析；对新引入依赖的首次安装做人工确认。

纪律 7 · 传递依赖也要看。

AI 引入的一个包，可能带进来几十个传递依赖。它们同样会成为你的攻击面和许可证义务来源，却不会出现在任何人的注意力里。完整的依赖树解析和持续的漏洞比对，是 AI 时代依赖管理的基本盘。

纪律 8 · 用片段级检测捕捉开源代码复现。

AI 可能逐字复现训练数据中的开源代码。这些片段不出现在任何依赖清单里，只读 manifest 的工具完全看不到——但它们携带的许可证义务是真实的。片段级指纹比对是目前唯一能发现这类风险的手段，而在 AI 生成代码占比越来越高的今天，这项能力从“锦上添花”变成了必需品。

纪律 9 · 审查重点放在业务逻辑，而非语法。

AI 生成的代码通常语法正确、风格统一，甚至比人写的更规范。它容易出错的地方在于：对业务规则的理解偏差、边界条件处理不全、权限判断的位置错误、错误处理过于宽松。人类审查者的注意力应该集中在这些机器不擅长的判断上，语法和风格交给工具。

纪律 10 · 留下代码归属的痕迹。

哪些代码由 AI 生成、用的哪个模型、什么时候、基于什么提示词——这些信息在三种场景下会突然变得关键：出现安全事件时的溯源、许可证纠纷时的举证、以及未来可能出现的合规审计要求。成本是提交时多加一个标记，收益是在需要时你有据可查。

十条纪律如果只是文档，落地率不会高。真正有效的方式是把它们编码进流程：提示词模板进 IDE 插件，依赖白名单进制品仓库配置，扫描进 IDE 与 CI，归属标记进提交模板，最后由 CI 门禁做统一的准入判断——不合格的代码进不了主干。

AI 让代码的生产速度提升了一个数量级，安全能力必须以同样的速度跟上。这不是给开发者加负担，而是让他们能放心地用好这个工具。

---