"能跑"不等于"能上线"
AI 生成的代码有一个特点：它几乎总是能跑起来。这恰恰是问题所在——能跑掩盖了一切，你没有任何反馈信号提示你去看第二眼。
Veracode 2025 年的一份分析指出，AI 生成的代码携带的安全缺陷密度约为等量人写代码的 2.74 倍。这个倍数不算离谱，但考虑到 AI 生成的代码量正在爆炸式增长，绝对数量很可观。
你不需要成为安全专家。下面这几项，非专业人士花二十分钟也能查完，能挡掉大部分事故。
一、密钥有没有写死在前端
最高频、后果最直接的一类。
// 这行如果出现在浏览器能加载到的文件里，密钥就已经泄露了
const client = new SomeAPI({ apiKey: "sk-live-xxxxxxxx" });
怎么查：在项目里全局搜 sk-、api_key、secret、password、token，逐个确认它出现在服务端文件里，而不是客户端组件里。
Next.js 项目要特别注意：任何以 NEXT_PUBLIC_ 开头的环境变量都会被打进前端产物，不管你多想让它保密。
二、有没有真正的后端
AI 建站工具大多产出的是"前端外壳"：表单看起来能提交，实际上没有任何持久化。
怎么查：提交一次表单，然后去数据库或收件箱里确认数据真的到了。别相信界面上的"提交成功"提示——那个提示很可能是硬编码的。
三、权限校验在哪一侧
这一条最容易被忽略，因为它在界面上完全看不出来。
// 前端隐藏了删除按钮 —— 这不是权限控制
{user.isAdmin && <DeleteButton />}
按钮藏起来了，但接口还在。任何人直接调用那个接口都能删数据。
怎么查：任何"只有管理员能做"的操作，去看对应的服务端接口，确认那里也做了身份和权限判断。前端隐藏 UI 不是权限控制，是视觉建议。
四、用户输入怎么处理
- 输入有没有在服务端校验（前端校验只是体验，不是安全）
- 用户提交的内容渲染回页面时，有没有被当作 HTML 执行
- 数据库查询有没有用参数化写法，而不是字符串拼接
五、依赖是不是真实存在
AI 会引用不存在的包名。更糟的是有人专门注册这些"幻觉包名"投毒。
怎么查：安装依赖时留意有没有报错；对陌生的包，去 npm 上看一眼周下载量和最后更新时间。下载量极低又刚发布的包要格外警惕。
六、性能上的低垂果实
AI 生成的代码通常偏重。不用做深度优化，先看三件事：
- 图片 —— 有没有把 4MB 的原图直接放上首页
- 依赖体积 —— 为了一个日期格式化引了整个 moment.js？
- 首屏请求数 —— 打开开发者工具 Network 面板，看首屏发了几十个还是几百个请求
跑一次 Lighthouse，它会直接告诉你最大的那块在哪。
七、错误处理
AI 喜欢写"快乐路径"：一切顺利时的代码。
- 网络请求失败时，用户看到的是什么？
- 数据为空时，页面是空白还是有提示？
- 后端返回错误时，错误信息会不会把内部细节暴露给用户？
怎么查：断网，然后把你的站点走一遍。
二十分钟版清单
[ ] 全局搜索密钥，确认没有出现在客户端代码里
[ ] 提交一次表单，确认数据真的落库/到邮箱
[ ] 管理员操作的服务端接口有权限校验
[ ] 用户输入在服务端也做了校验
[ ] 依赖包在 npm 上真实存在且有正常下载量
[ ] 跑一次 Lighthouse，看性能与无障碍分项
[ ] 断网走一遍，确认错误态有合理提示
一句话
你发布它，你就对它负责。 "这是 AI 写的"在任何场合都不是免责事由——无论是对用户、对客户，还是对监管。
MotionSites 上的提示词会显式约束技术栈和依赖，减少幻觉包和密钥外泄的概率。