AI 生成代码的 QA：上线前会出什么问题，以及如何排查

Lovable、Cursor、Claude Code、Replit 或其他工具生成的 AI 辅助原型可能很快做到演示，但生产就绪取决于预期用户、数据、暴露范围、架构和证据。"在我屏幕上能跑" 与 "满足明确的质量、安全和运营要求"之间的差距必须经过验证，不能从代码生成方式推断。本文介绍 AI 辅助构建上线前的风险导向 QA 流程。

这些都不是反对用 AI 来构建。我们自己也用 AI 构建。这是在说：要像测试任何即将触碰真实金钱、真实数据和真实用户的代码那样，去测试它的产出。

上线了一个 AI 原型？

预约一次生产就绪评审

AI 生成代码为什么可能在生产环境失败？

编码助手只能使用提供给它的需求和上下文。输出可能包含不安全模式、虚构依赖，或与部署系统不符的假设。人工代码也会出现同类缺陷。在架构、依赖、数据流和行为对照明确需求完成审查前，应把生成代码视为不可信。

风险取决于应用及其暴露范围。应使用威胁模型和验证标准，而不是假定 AI 生成代码必然不安全，或成功演示就能证明生产就绪。

AI 生成的代码实际会在哪里出问题？

以下是常见审查领域，并非针对所有 AI 辅助构建的实测缺陷排名。应按系统和目标风险调整范围。

认证与授权。在可信服务端代码中测试对象、功能、属性和租户边界。登录可用并不能证明用户 A 无法访问用户 B 的数据。
输入与输出处理。为每个信任边界定义类型、长度、格式、编码、允许值和拒绝行为。清洗取决于上下文，不能普遍替代校验和安全 API。
凭据与敏感配置。检查源码、历史、构建产物、日志和客户端包。撤销或轮换已暴露凭据，并将特权操作移到可信边界之后。
异常情况。测试超时、部分故障、重试、空结果、畸形响应、资源耗尽和恢复，同时避免泄露敏感细节。
性能与资源限制。对代表性数据量和并发进行性能分析。查找无界读取、重复查询、缺少限制，以及不可信输入触发的高成本工作。
并发与重放。对改变状态的操作测试重复和并行请求，并在业务规则要求时强制事务性或幂等行为。
依赖与构建完整性。盘点直接和传递组件，在可行时核验包身份与来源，并检查受支持版本、安全通告和许可义务。
状态对账。确认用户可见状态遵循权威后端状态，并能对异步或失败操作进行对账。

"生成器不是保证边界。定义目标、检查系统、复现重大问题，并保留控制有效的证据。"

AI 辅助构建的生产就绪清单

这是 Wavect 初步检查的结构，已于 2026 年 9 月 2 日复核。它不是适用于所有系统的完整测试计划。应按架构、暴露范围、威胁模型、监管和服务水平选择控制项。

授权审计。对每个受保护操作和数据路径，确认可信服务端或无服务器边界会检查行为主体及请求操作。客户端检查可以改善体验，但不是安全边界。
输入边界测试。在相关入口测试畸形、超大、恶意和意外输入，确认安全拒绝或处理。
密钥清扫。扫描仓库和客户端打包产物，找 key、token 和凭证。把泄露的全部轮换，并挪到服务端。
故障路径覆盖。模拟重大外部故障，确认已定义重试、回退、用户提示、日志和恢复行为。
负载与查询评审。对代表性工作负载和数据量做性能分析。限制读取并处理重复或意外昂贵的查询。
并发测试。对一切写入金钱或状态的地方，发起并行和重复请求。在缺失的地方补上幂等性。
依赖与许可审查。使用自动盘点和通告检查，再审查相关发现、来源、支持状态和许可义务。扫描器不能证明每项依赖都安全或兼容。
回归证据。为关键行为增加适当的自动和手动测试，使后续改动可与基线比较。测试驱动开发是组织可执行预期的一种方式。

如果你希望 AI 协助创建和维护这些回归测试，就需要一条独立的保证边界。我们的智能体测试与测试自动化试点指南说明哪些工作可以交给智能体、哪些断言必须保持确定性，以及如何衡量 30 天试点。

这是我们软件 QA 服务的核心。交付物取决于范围，可能包括问题、复现证据、修复、测试、部署控制和残余风险说明。任何审查都不能证明系统不存在缺陷。

我能不能直接让 AI 修它自己的代码？

部分可以。AI 工具能够提出测试和修复建议、搜索代码库，并根据提供的架构或问题上下文进行推理。它们也可能遗漏范围、引入回归、依赖过时的漏洞知识，或验证自己的假设。应保留独立保证边界：人对需求和风险接受负责，生成的问题与补丁需要可复现测试和审查。对于一个狭窄的发现步骤，我们的Cisco Antares 本地 CWE 漏洞定位评测解释了为什么候选文件仍必须由安全审查者确认。

让 AI 生成的代码达到生产就绪，需要多久？

不存在可辩护的通用时长。范围取决于目标架构、代码和测试质量、数据、暴露范围、集成、部署、监管、专项测试、代码库访问和整改深度。先做范围有限的审查并说明限制，再根据证据估算加固工作。

代码什么时候已经救不回来了？

当缺陷具有系统性、架构无法满足要求、依赖已停止支持或迁移风险占主导时，应比较整改与替换。重建并不会自动更便宜，它增加了功能对等、迁移、切换、重新培训和新缺陷风险。决策前应记录假设、选项、验收标准、回滚和残余风险。

最终思考

不要根据初稿由人还是模型编写来推断软件质量。定义生产目标，梳理信任边界和依赖，选择风险导向的验证，复现重大问题，并保留修复和残余风险的证据。

把这份清单作为起点，而不是认证。高影响系统可能需要更深入的架构审查、渗透测试、隐私或安全评估、行业专家和运营演练。只有当证据达到为真实系统设定的验收标准时才发布。

上线了一个 AI 原型？

预约一次生产就绪评审

验证方法的主要来源

这些来源支持风险导向的安全开发与验证，但不提供 AI 生成代码的缺陷率，也不认证某个具体应用。