不少“AI 测试平台”从用例生成页面开始：输入需求，模型输出几十条 Gherkin，再配一块看起来完整的仪表盘。演示容易，真正接入发布流程时却会遇到三个问题：结果无法复现、好坏没有统一标准、线上坏样例回不来。
如果资源有限，我更建议先做三项底座：trace 与回放、评测资产、发布门禁与反馈回流。用例生成、缺陷归因、智能编排都可以在它们之上逐步增加。
一、先把一次 AI 执行记录完整
传统接口失败通常能从请求、日志和数据库找到证据。AI 应用还需要记录：
- 应用版本、模型与参数；
- 系统提示词及模板版本；
- 用户输入和经过的预处理；
- 检索查询、召回文档 ID、分数与版本；
- 工具调用名称、参数、结果和耗时；
- 每个步骤的输出、重试和错误；
- token、成本、总延迟和最终用户反馈。
这些信息共同构成一条 trace。没有 trace，团队看到的只是一段最终文本，无法判断问题来自提示词、检索、模型还是工具。
记录不等于无条件保存
日志可能包含个人信息、业务数据和模型输入。平台必须支持：
- 字段级脱敏和采样；
- 数据保留期限；
- 访问权限与审计；
- 敏感环境关闭正文、只保留哈希或元数据；
- 从生产样例进入评测集前的人工确认。
可观测性不能以泄露数据为代价。
回放要区分“精确复现”和“重新评估”
模型服务、外部知识和工具结果都可能变化，完全复现并不总是可能。平台可以提供两种模式：
- 固定依赖回放：使用缓存的检索与工具结果，观察模型或提示词变化；
- 实时依赖重跑：重新调用当前检索和工具，验证端到端表现。
两者回答的问题不同，报告中应明确区分。
二、把评测集和 grader 当成代码资产
评测平台最小数据模型可以很简单：
EvalCase
id
input
context
expected_behavior
forbidden_behavior
tags
source
version
EvalRun
app_version
model_config
dataset_version
grader_version
per_case_results
summary评测集要能进 Git 或数据版本系统，支持 review、差异比较和回滚。模型、提示词、检索配置和 grader 也要有版本；否则分数变化时无法解释是哪一层造成的。
grader 要按确定性从高到低组合
优先级可以是：
- schema、类型、范围、必填字段等程序断言；
- exact match、集合比较、可执行结果；
- 检索召回、工具选择和参数正确率；
- 规则或统计指标；
- 经人工校准的模型裁判；
- 人工专家复核。
不是每条样例都要走最昂贵的 grader。严重越权、错误写操作、引用不存在等问题应直接失败，不应被平均语义分冲淡。
不把资产绑死在单个评测 SaaS
平台可以接入开源或厂商工具，但至少保留可导出的：
- JSONL / Parquet 样例；
- grader 配置和代码；
- 单样例明细；
- trace 关联 ID；
- 汇总计算口径。
工具会迭代甚至下线，数据和判定标准应能迁移。
三、让评测进入发布门禁，并接回生产
评测平台如果只靠人工点“运行”，很快会变成展示系统。它应当接入代码、提示词、知识库和模型配置的变更流程。
一个克制的流程是：
变更
↓
确定性测试
↓
小型关键评测集（PR 门禁）
↓
完整离线评测（合并后或定时）
↓
灰度 / 影子流量
↓
线上采样与人工复核
↓
新失败进入回归集门禁不要只看总体平均分。至少分开看：
- 关键场景是否有任何退化；
- 安全和权限样例是否全部通过；
- 与基线相比改善、持平和退化的样例分别有哪些；
- 延迟和成本是否超预算；
- 评测结果是否具有足够样本量和一致性。
对于模型裁判分数的小幅变化，不宜机械阻断发布。可以设置“硬失败 + 统计变化 + 人工 review”三层策略。
这三项底座之上再做什么
用例生成
模型先生成候选场景和理由，由人选择后进入正式用例。平台记录被接受、修改和拒绝的原因，用来改进后续生成。目标是补充思路，不是把“生成数量”当产出。
缺陷归因
把失败 trace、变更、历史缺陷和运行日志整理成证据包，让模型输出候选原因和缺失证据。最终归因仍由研发或测试确认，并把确认结果回写。
测试选择
先用覆盖率、依赖图和变更规则建立可解释基线，再评估统计模型是否确实减少执行时间且不增加漏测。夜间全量回归、抽样探索和线上监控仍是安全网。
合成数据
合成数据适合补充边界和保护隐私，但不能自动代表真实分布。关键约束应由规则保证，生成数据要做重复、泄露、分布和业务不变量检查。
一个最小可行版本
第一阶段不必做复杂平台，可以只交付：
- 一份 50—100 条、按风险分层的评测集；
- 一个命令行 runner；
- 程序断言 + 一个人工校准的模型 grader；
- 一份逐样例差异报告；
- CI 中的关键集门禁；
- 生产坏样例进入评测集的流程。
只有这条链路稳定后，再做 UI、调度集群、模型路由和多团队租户。平台抽象应来自真实接入，而不是先画出一张包罗万象的架构图。
衡量平台是否有用
建议看结果而不是调用次数：
- 关键失败在发布前被发现的比例；
- 线上坏样例进入回归集的时延；
- 评测结果与专家判断的一致性；
- 发现退化到定位责任层的时间；
- 每次评测的成本、耗时和不稳定率；
- 团队有多少变更真正经过门禁。
一套平台是否“智能”不重要。重要的是每次模型、提示词、知识和工具变化后，团队能否快速回答：哪里变好了，哪里退化了，证据是什么，能不能安全上线。