让 AI 真正进入数字产品：从“会回答”到“可交付”的产品工程

分析范围：问题不在“接不接模型”，而在“谁对结果负责”

把大模型接入网站、小程序或内部系统，通常可以很快做出一个流畅的对话演示：用户提问，模型组织语言并给出答案。但真实产品面对的是不完整输入、过期知识、越权请求、跨系统操作，以及用户把模型回复当作正式承诺的情况。

因此，本文讨论的核心问题是：AI 如何从一个生成内容的界面能力，变成可以嵌入真实业务流程、可被验证和持续运营的产品能力？

我们的工作性理解是，能上线的 AI 不是单独的聊天框，而是一个由四部分组成的交付单元：明确任务、受控上下文、有限动作、持续评估。模型负责在不确定输入中理解和生成；产品系统则负责决定它能看到什么、能做什么、何时必须停下来交给人。

先缩小任务：不要让“万能助手”直接接管业务

以客服为例，用户表面上都在“问问题”，但产品动作完全不同：查询物流可能只需检索订单状态；退款需要验证订单和资格；修改收货地址可能影响履约；涉及账户、付款争议或异常情况，则需要升级人工。若把这些任务都交给一个不带边界的对话模型，模型即使语言自然，也可能基于错误上下文给出承诺，或在不应执行时触发操作。

Klarna 的案例说明了 AI 进入业务产品时的一个可观察方向：其面向消费者的助手覆盖多语言客服、退款和退货等任务，而不仅限于商品问答；同时，Klarna 也向全球员工提供带有公司数据保护的 ChatGPT Enterprise。[3] 这里值得借鉴的不是把“聊天”替代全部服务，而是把消费者侧流程和员工侧知识工作分开设计：前者需要订单、规则和动作权限的约束，后者更适合用于检索、起草和分析。

**证据—分析—行动启示：**Klarna 所描述的退款、退货等场景已经触及具体业务流程，而非停留在开放式问答。[3] 这意味着产品团队的第一步不应是选择“最聪明”的模型，而是列出一个流程中可被明确验证的节点：例如“查询订单状态”“解释退货政策”“收集退款申请资料”。对每个节点写清输入、允许输出、所需系统数据、是否能执行动作，以及人工兜底条件。先让 AI 在低风险、高频、结果可核验的环节稳定交付，再逐步扩大范围。

可以把网站或小程序中的首期能力设计为下表，而非直接上线一个“什么都能办”的入口：

上下文不是“塞更多资料”，而是为答案和动作建立证据链

真实产品中的模型不知道企业最新规则，也不天然拥有用户订单、库存或账户权限。解决方式并不只是上传一批 PDF。更可行的结构是：用户请求先被识别为某类任务；系统按用户身份、产品版本、地区或订单号筛选可访问资料；再把少量相关内容连同当前业务状态提供给模型；如果需要执行操作，则由后端工具或 API 完成，并返回结构化结果。

这正是检索增强生成在产品决策中的意义：它不是为了让回答“看起来更有知识”，而是把回答尽量锚定在可更新、可追溯、可授权的数据上。NIST 在生成式 AI 风险管理画像中明确建议，在部署前和持续监控中审查、核验系统输出中的来源与引用；同时核验训练数据和测试评估数据的来源，并确保微调或检索增强生成所用数据有可靠依据。[1]

这里有一个常被忽略的边界：**检索能改善“依据从哪里来”，不能自动证明“结论一定正确”，更不能替代权限控制。**一份过期、冲突或权限不当的文档，依然可能被检索到；模型也可能把多段资料拼接成原文未表达的结论。对于会改变状态的操作，模型不应直接拥有“自由执行权”。应让它调用参数固定、返回结果可校验的工具，例如 get_order_status(order_id)、check_refund_eligibility(order_id)，而不是让模型自行编写数据库查询或构造任意操作。

**证据—分析—行动启示：**NIST 将来源核验、RAG 数据有据可查以及定期复查安全护栏列为生成式 AI 风险管理活动。[1] 对产品团队而言，这将“知识库”从内容运营问题变成了数据治理问题：每条可被 AI 使用的内容应有负责人、适用范围、更新时间和失效机制；每次高影响回复至少应记录检索片段版本、工具调用结果与最终答复。这样，用户投诉或业务规则变化时，团队才能定位是检索召回、规则配置、模型生成还是接口数据出了问题。

评估应模拟真实失败，而不是只挑好问题做演示

演示阶段常见的测试方式是准备十几个标准问题，观察回答是否通顺。但上线后最昂贵的问题通常不是“措辞一般”，而是少见却高代价的边界输入：用户混合多个诉求、知识库版本冲突、故意诱导系统绕过规则、接口超时后模型仍假装操作成功等。

OpenAI 对企业评估的建议提供了一个可落地的循环：先由领域专家和技术负责人共同界定目标与关键决策点，形成“黄金示例集”；再在接近真实压力与边界条件的环境中测试；最后将新错误纳入分类和下一轮改进。其建议早期审查 50 至 100 个输出，以识别系统在何时、以何种方式失败；LLM 可以辅助评分，但领域专家需要定期核验评分器，并直接审查行为日志。[6]

这套方法的关键不在于追求一个单一“准确率”。客服助手可能同时需要衡量：是否正确引用现行政策、是否成功完成分流、是否在不确定时停止回答、工具调用是否合规、人工接手时是否保留足够上下文。不同任务的失败成本不同，不能用一条总分掩盖高风险错误。

Intercom 的 Fin 是一个值得观察、但不应照搬的客服智能体案例。AIUC 在 2025 年 12 月 10 日发布的案例称，Fin 获得 AIUC-1 认证，认证通过独立对抗测试验证其对数据泄露、越狱和幻觉的技术防护；该页面还描述了每季度覆盖 1,000 多项测试的持续验证安排。[4] 这至少说明，面向企业客户的 AI 智能体，安全和可靠性可以被转化为持续测试与采购沟通材料，而不只是产品宣言。

但它不能证明所有企业都需要同等级别的外部认证，也不能证明认证本身覆盖每一个业务规则。该信息来自认证机构发布的案例，应视为一种具体实践信号，而非普遍效果结论。[4] 对多数中小团队，更可借鉴的是其方法：把提示注入、越权索取数据、无依据回答、工具失败、超出服务范围等情况做成固定回归集，并在每次改模型、改提示、改知识库、改接口后重新运行。

把“人工介入”做成产品能力，而不是故障后的补丁

人机协作不是简单地在页面底部放一个“转人工”按钮。优秀的交接需要回答三个问题：何时转、转给谁、交接什么。

Intercom 的研究描述了一种组织层面的变化：部分客服人员和管理者从处理基础咨询转向审核 Fin 的任务、改进自动化和管理 AI 表现；同时出现 AI 专员、自动化经理和 Fin 负责人等角色。[7] 这份研究反映的是受访团队的经验，不足以推导全部客服组织都会如此变化；但它提醒产品负责人，上线 AI 后仍需有人拥有错误分类、知识维护、规则审批和质量复盘的职责。

在产品层面，可以考虑设置明确的升级规则：

• 用户请求涉及退款金额、账户安全、争议或例外政策时，AI 只做信息收集和摘要；
• 检索无结果、多个来源冲突、工具返回异常时，AI 说明限制并转人工，而不是补全猜测；
• 连续追问、负面情绪或用户明确要求人工时，优先交接；
• 交接包自动包含用户原话、已验证身份状态、检索资料、工具结果与未完成事项，避免用户重复描述。

这种设计的目标不是让人工“兜住所有问题”，而是让人工集中处理模型不应独自承担的判断与例外，并将人工修正转化为后续评估样本。

一个可在 6 周内启动的实施路径

对于准备在官网、服务号、小程序或内部工作台中落地 AI 的团队，我们的建议是先做一个窄而完整的闭环，而不是并行铺开多个助手。

1. **第 1 周：选择一个任务。**选取高频、规则相对稳定、可验证且失败可控的流程。写成一句业务目标，例如“帮助已登录用户查询订单状态，并在异常时生成可供人工处理的摘要”。
2. **第 2 周：绘制边界。**列出允许的数据源、禁止回答的内容、可调用接口、必须转人工的条件。为每项工具定义输入校验、权限校验、超时和失败返回。
3. **第 3—4 周：建立黄金集。**由客服、运营、产品和研发共同收集真实脱敏样本，包含正常问题、模糊表达、恶意诱导、版本冲突和接口异常。每条样本不只写“标准答案”，还应写是否该调用工具、是否该转人工、哪些表述不可出现。
4. **第 5 周：在沙箱评估。**按同一批样本比较版本，检查来源是否可追溯、工具是否误调用、拒答和转人工是否正确；抽样由领域专家复核，而非完全依赖模型互评。[6]
5. **第 6 周：灰度上线与复盘。**先限定用户范围或时段，记录失败类型和人工改写内容。每周将新增高代价错误加入回归集；知识库或策略变更时同步触发重新评估。[1]

上线前，负责人可以用以下问题做最后检查：

• 用户能否知道 AI 的能力范围，以及何时会转人工？
• 每个关键回答能否追溯到获准使用的资料或实时接口结果？
• 模型是否被禁止自行承诺价格、退款、时效或账户状态？
• 工具调用是否经过身份、参数和权限验证，并能记录执行结果？
• 是否有一组会在每次变更后自动重跑的高风险样本？
• 谁负责审查日志、更新知识、处理反馈，并决定扩大或收缩能力边界？

结语：可交付性来自系统设计，不来自一次模型升级

模型能力提升会改变可自动化任务的范围，但不会自动解决业务目标含糊、知识过期、权限混乱和责任无人承担的问题。NIST 将可信赖性纳入 AI 产品、服务和系统的设计、开发、使用与评估过程；这也提示我们，AI 产品化不是在上线前加一道“安全检查”，而是在需求、数据、接口、评估和运营中持续做取舍。[2]

真正值得投入的，不是一个看似无所不知的演示，而是一个能在明确范围内提供依据、正确调用工具、知道何时停下，并能从真实错误中持续变好的数字产品闭环。