AI 产品最容易出现的误区，是把一次效果不错的模型调用当成已经完成的能力。
真正进入生产环境后，我们还要回答更多问题：答案来自哪里？什么时候会失败？失败后如何定位？同一个问题重复测试时为什么发生波动？
从可演示到可交付
一个可靠的 AI 功能至少包含四层：
- 输入边界：明确系统接收什么，以及什么情况应该拒绝。
- 证据链路：让检索结果、工具调用和最终答案之间能够被追踪。
- 质量评估：用固定案例和真实反馈判断变化究竟是提升还是回退。
- 运行诊断：出现问题时，能够快速定位发生在哪一层。
type AnswerTrace = {
query: string;
evidence: Evidence[];
decisions: Decision[];
answer: string;
};
技术选型并不是最难的部分。更重要的是建立一条团队能够理解、验证和持续改进的产品链路。
保留复杂度预算
不是每个问题都需要 Agent，也不是每次请求都应该经过多轮推理。简单请求走确定性路径，复杂请求才进入更昂贵的推理流程，通常更可靠。
好的 AI 产品不是展示模型有多聪明，而是让用户知道它什么时候值得信任。
一次回答要能解释自己的来路
上面的 AnswerTrace 是一个示意，不是说把所有原始输入和内部材料无限期存起来。实际落地时，需要根据数据敏感度决定哪些内容只保存摘要、哪些只在短期排障窗口内保留。但至少应该能回答：这次请求进入了哪条路径，使用了哪个模型和提示词版本，取到了哪些获准使用的证据，是否调用工具，以及最终为何选择回答或拒答。
如果一条问题突然答错，排查顺序不应从“再改改提示词”开始。先核对输入和上下文有没有变化，再看检索候选是否包含正确资料、工具是否返回预期结果，最后才判断生成阶段有没有忽略证据。把链路拆开，修复才能对准原因。
评估集要覆盖失败的形状
固定的演示题通常过于干净。更有价值的样本包括：资料已过期、两份文件相互矛盾、用户缺少权限、工具超时、同一个操作被重复请求，以及问题本身没有确定答案。每条样本不仅标“期望答案”，还应标期望行为：回答、补问、拒答、等待确认或转人工。
上线前比较新旧版本时，我会同时看正确率、应拒答时的克制程度、关键步骤的失败率、P95 延迟和单次成本。指标间会发生冲突：加入重排可能提高答案质量，却让响应变慢；多轮 Agent 可能解决长尾问题，却增加重复调用风险。产品决策应明确在什么场景愿意支付这些成本。
发布和回滚也是产品能力
先让少量请求进入新路径，保留老路径的回退开关，并监控失败类型而不只是总错误率。若新版本让某类高风险问题开始自信误答，即使平均分上升，也应该暂停扩大流量。一次可靠发布的成果不仅是“模型更好”，还包括团队知道变好了什么、坏了什么，出了问题能否安全退回。
这也决定了功能设计中的一个取舍：不要把所有失败都藏在“正在思考”动画后面。检索失败、工具暂不可用、缺少权限和证据不足，对用户意味着不同的下一步。把这些状态清楚表达出来，通常比再生成一段圆滑但不确定的回答更有产品价值。