AI 驱动功能的测试策略

拆分确定性与概率性

AI 功能的大部分仍是普通软件：认证、输入校验、检索查询、速率限制、持久化与 UI 渲染。这些层应得带固定夹具的经典单元与集成测试。不要因为中间有模型就削弱它们。

生成步骤需要不同方法。对自由形式答案做精确字符串匹配会制造脆弱套件。测试模型周围的契约，并对照产品属性评估模型输出。

在持续集成中明智地打桩

每个拉取请求都调用线上模型又慢又贵且非确定性。在 PR 流水线使用录制夹具或确定性桩，并在计划任务中，或在提示、模型或检索逻辑变更时，运行更广的评估套件。

打桩时保留现实延迟与失败模式。只见完美模型响应的测试，不会保护超时处理或畸形输出路径。

• 渲染前断言输出 schema
• 对关键 grounding 答案做黄金文件
• 模拟空检索与工具失败
• 以契约测试而非模型创造力作为合并门禁

增加旅程级信心

端到端测试应验证用户能完成 AI 辅助旅程：提交请求、看到已校验响应、从拒绝中恢复，并在需要时升级。保持这些旅程少而稳定。

将自动化旅程与生产输出的定期人工抽样审阅配对。AI 的质量工程是软件纪律与产品品味的混合。

让失败可行动

失败的 AI 测试应告诉你是 schema 坏了、检索漏了、策略错误拒绝，还是评估分数下降。模糊的红色构建会训练团队忽略它们。

测试 AI 功能的目的不是假装模型是确定性的。而是把概率组件保持在仍可运维、可审阅、可安全变更的系统之内。