测试不是上线前的一次检查

很多项目把测试放在开发的最后：功能做完了，找几个人试一试，没有明显问题就上线。这套逻辑能检查“能不能用”，却很难回答“是不是值得做”。

对 AI 产品来说，这个差别更关键。模型输出会受场景、上下文、用户表达和系统策略共同影响，一次通过不代表稳定可用。因此，我更愿意把测试理解为一条连续的产品决策链。

先测的不是功能，而是产品假设#

测试的起点不应该是“这个按钮能否点击”，而是更早的三个问题：

1. 谁遇到了什么麻烦？ 把目标用户、任务和使用时刻说清楚。
2. AI 为什么值得介入？ 如果规则、搜索或人工流程更稳定，就不应该为了 AI 而 AI。
3. 什么证据会证明我们判断错了？ 在开发前写下反证条件，可以减少上线后为结果找理由。

这三个问题构成了后续评测的坐标系。如果问题定义不清，再精细的指标也只是精确地衡量了错误的方向。

评分标准要对应用户任务#

一个总分很方便，却容易遮住关键差异。我会把评分拆成几个可诊断的维度：

• 任务完成度：结果是否真的帮用户推进了任务。
• 事实与证据：关键结论是否有来源，能否被复核。
• 风险与边界：不确定时是否能拒答、降级或转人工。
• 交互成本：用户为了得到结果，需要补充多少信息、重试多少次。

分维度的价值不是让报表更复杂，而是让团队看到问题究竟发生在模型、数据、工具调用，还是产品流程。

离线评测和真人测试各自回答什么#

离线评测适合做稳定、可重复的版本对比；专家复核适合判断高风险样本；任务可用性测试则能暴露用户是否理解输入方式、是否信任输出。三者不是替代关系，而是在回答不同的产品问题。

验收标准不只要写“多好才能上线”，也要写“多差必须停下”。

上线是换了一种测试方式#

上线前的样本永远有限。真实使用中会出现未预期的表达、边界场景和错误组合，所以埋点不应只记录 PV 和点击量，而要围绕用户任务设计事件：

观测问题	可用信号	帮助做的判断
用户是否得到结果	任务完成、复制、导出	产品是否创造了可用价值
用户是否需要反复修正	重试、重写、人工接管	问题更可能出在输出质量还是交互引导
什么情况下信任中断	放弃位置、证据展开、负向反馈	应优先改模型、证据表达还是风险提示

埋点只能告诉我们“发生了什么”。要理解“为什么”，还需要结合会话抽样、用户访谈和任务回放。

让失败样本变成下一轮的资产#

数据飞轮不是“数据越多，产品自然越好”。它需要一条可管理的回流链路：

1. 将线上异常聚类，区分是偶发噪声还是稳定失败模式。
2. 经过脱敏、边界标注和人工复核后，把典型失败样本加入回归集。
3. 每次改动都重跑核心集和风险集，既看新问题是否修复，也防止旧能力退化。
4. 记录这次判断、改动和结果，形成可追溯的决策台账。

真正产生复利的不是某一次调参，而是问题定义、评测集、埋点事件、失败分类和决策记录逐渐变成团队的共同资产。

最后的判断#

测试不是为了证明产品做对了，而是用尽可能低的成本，更早地发现我们在哪里判断错了。

当产品定义、评分标准、验收门槛、线上观测和样本回流连在一起，测试就不再是一个阶段，而会成为产品持续学习的方式。