AI 可以很快生成页面、表单和接口，但“页面能打开、按钮能点击”只说明一部分功能可用，并不能证明代码没有暴露密钥、越权读取数据或错误处理漏洞。准备把 AI 生成的网站交给客户使用前，建议先把它当作一份需要审查和测试的代码变更，逐项验收。
先按网站功能划分风险
纯展示型页面主要检查外部脚本、表单提交、后台账号和部署配置；如果网站包含登录、会员资料、订单、文件上传或管理后台，就要进一步确认用户身份、数据权限和操作记录。涉及支付、敏感个人信息或关键业务时，应增加有经验的开发或安全人员复核，不能只依赖 AI 的“检查通过”结论。
先列出实际存在的功能和数据，再决定检查范围。不要因为项目看起来小，就跳过登录接口、管理入口、文件目录和第三方服务配置。
上线前逐项核对七个方面
- 密钥是否暴露。检查代码仓库、前端打包文件和浏览器网络请求，确认数据库密码、私钥、短信或支付密钥没有写进前端代码，也没有提交到公开仓库。前端需要调用的服务应经过服务端代理或使用权限受限的公开凭据。发现密钥曾经暴露时，应先撤销并轮换，单纯删除代码不足以消除风险。真实密钥、客户数据和生产日志不要直接交给未获准使用的 AI 服务处理。
- 每个数据操作是否校验权限。登录只回答“你是谁”，授权还要回答“你能看什么、能改什么”。建立“角色 × 操作 × 数据范围”表，分别测试普通用户、管理员和未登录用户。除了页面按钮，还要直接访问接口和修改记录编号，确认后端会拒绝不属于当前用户的数据请求；仅仅把按钮隐藏起来不算权限控制。
- 输入和输出是否按场景处理。对表单字段设置服务端校验和合理长度范围；涉及数据库时使用参数化查询；展示用户输入时按输出环境进行转义。对搜索词、备注、富文本和 URL 参数分别设计异常输入测试，不能因为前端做了校验就省略服务端验证。
- 文件上传是否受限制。如有上传功能，确认服务端检查文件类型和大小，避免只依赖文件名后缀；为文件重新命名并控制存储位置，禁止用户上传的内容被当作可执行脚本运行。还要验证超大文件、伪造类型、空文件和重复提交时系统如何反馈。
- 依赖和构建来源是否清楚。查看项目使用了哪些第三方库、版本是否锁定、是否存在已知风险提示。运行项目所用生态的依赖检查工具，在测试分支逐项评估升级影响；不要为了消除告警而一次性盲目升级所有依赖。生产构建应来自可追溯的代码版本，避免把临时调试代码一起带上。
- 错误和日志是否泄露信息。让普通用户看到可理解的错误说明，不把堆栈、数据库地址、令牌、密码或完整个人资料返回给浏览器。日志保留排查所需的时间、请求标识和错误类型即可，避免记录密码、验证码、访问令牌等内容。开发和测试环境尽量使用虚构或脱敏数据。
- 备份是否能够恢复。确认上线前已有可用备份，并在非生产环境实际演练恢复。只看到“备份成功”提示不代表数据库和上传文件可以一起恢复；还要确认恢复后页面、账号和关键记录能正常使用。
给 AI 做只读审查时，怎样提问更有效
不要只问“这段代码安全吗？”这样的问题范围太宽，模型容易给出笼统结论。先去掉真实凭据和客户数据，再说明项目用途、用户角色、关键数据和允许的审查范围，要求 AI 引用具体文件或代码位置，并把事实、推测和未知项分开。可以使用下面的提示词：
请对以下代码做只读安全审查，不要修改文件、执行命令或访问外部系统。项目用途：……；用户角色：……；敏感数据：……；功能入口：……。请重点检查密钥暴露、服务端权限校验、输入处理、文件上传、错误信息和依赖风险。每条发现都要给出代码位置、成立条件、可能影响、建议修复方向和一个回归测试用例；如果证据不足，请标为“待人工确认”，不要声称项目绝对安全。以下代码已移除真实密钥和客户数据：……
AI 输出的风险清单应当回到代码和测试环境逐条核实。要求它提供定位和复现条件，比接受“没有发现问题”更有价值；对高风险项，仍应由开发人员审查实现和修复结果。
用一组可重复的测试完成验收
至少准备正常流程、无权限访问、边界输入、重复提交、服务异常和备份恢复这几类测试。每条记录写清楚测试账号、操作步骤、预期结果、实际结果和修复版本。先在测试环境完成，修复后重新运行原用例，再检查是否影响相邻功能；确认部署包来自已审核版本后再发布。
OWASP 的 Web 应用安全风险清单可用于建立风险意识，安全代码审查指南、密钥管理指南和授权检查指南可以帮助补充检查项。这些资料是检查参考，不是自动认证；具体结论仍取决于网站的功能、数据和部署环境。
实用判断：如果网站只展示内容，先检查表单和后台入口；如果涉及账号、订单、客户资料或文件，必须把后端权限和数据处理纳入验收。让 AI 帮你找线索、整理测试用例，再由人复核证据和修复结果，才能把“能运行”推进到“可交付”。
