AI 功能不是在演示中跑通就算完成。
这就是陷阱所在。你问了三个友好问题，它答对了两个半，每个人都看到了未来的雏形，然后产品路线图上突然多了一个叫"AI 助手"的功能，而本该有的技术规格却不见踪影。
我不信任那种流程。我信任更慢的那个：明确承诺，编写失败案例，测试非理想路径，并在系统证明自己可靠之前始终保留人工介入。
功能不是一次性评估完成的。它在一个循环中流转：定义承诺，构建失败集，评审实际输出，然后才决定哪些可以发布。
从承诺开始
第一个问题不是"我们应该用哪个模型？"
第一个问题是：用户在与这个功能交互后，可以相信什么？
这句话很关键。如果功能是总结文档，用户相信总结是忠实的。如果功能是起草客服回复，用户相信它不会凭空编造退款政策。如果功能是解释交易信号，用户相信它并非披着友好外衣的金融建议。
用一句话写下承诺：
- "此功能对请求进行分类，并将其路由到正确的工作流程。"
- "此功能草拟回复，由人工批准后发送。"
- "此功能搜索内部文档，并引用所使用的来源。"
如果承诺需要写一段话，说明功能范围尚未界定清楚。
在理想路径之前构建失败集
大多数 AI 演示都是无意中为了通过演示而训练的。
真正的评估集应该包含那些让产品感到棘手的输入：
- 模糊的请求
- 矛盾的指令
- 缺少上下文
- 恶意的提示注入
- 过时的政策文档
- 重复的记录
- 带有愤怒情绪的客户消息
- 处理不当会带来经济损失的边缘情况
对于面向客户的 AI 工作流程，在信任系统形态之前，我至少需要 25 个示例。不是 25 个完美的基准测试行。而是 25 个代表实际工作的、不那么完美的示例。
评估集不是文书工作。它是产品的边界。
区分模型质量与产品质量
模型可能很好，但产品仍然可能很差。
模型可能给出正确答案但没有引用来源。工作流程可能引用了正确的文档却埋没了重要警告。UI 可能让答案看起来是最终版，而实际上只是草稿。
我分层评估 AI 功能：
- 它是否理解了任务？
- 它是否使用了正确的来源或工具？
- 它是否避免了在来源之外做出断言？
- 它是否以用户可操作的形式返回了结果？
- UI 是否清晰展示了系统的置信度和局限性？
只有前两个主要与模型相关。其余的都是产品问题。
让人工介入的时间比感觉方便的更久一些
AI 工作流程的第一个生产版本通常应该是"先草稿，后发送"，而不是"直接发送"。
这听起来没那么神奇。很好。
先草稿后发送能给你评审数据。它显示用户在哪里编辑输出，在哪里拒绝输出，他们纠正了哪些字段，以及哪些任务从一开始就不应该被自动化。
人工评审步骤不是永久的拐杖。它是仪表化手段。
当编辑变得可预测时，就将编辑自动化。当拒绝集中在某一种输入类型时，就修改路由。当评审员反复手动检查同一个来源时，就添加检索和引用。
你不会因为演示跑通了就移除人工。你会在评审日志表明系统已经赢得信任时才移除人工。
发布检查清单
在发布 AI 功能之前，我需要确保以下事项到位：
- 一句承诺
- 包含丑陋示例的评估集
- 每个示例的通过/失败标准
- 对提示、工具调用、来源和结果的日志记录
- 高风险输出的人工评审路径
- 模型不可用时的回退方案
- 从 UI 报告不良输出的方式
这些都不会让功能变得不那么令人印象深刻。
它让功能变得真实。
相关系统：构建前的 AI 实施审计 将同样的思路拆解为构建前的审计路径，供决定先自动化什么的团队使用。
