20  案例：数据产品 PRD

本章产出： “设备售后上下文产品”首期 PRD，覆盖用户、任务、数据、端口、SLO、权限、评估、风险与验收。

本 PRD 延续虚构案例“山城精工”，所有范围和数字均为教学设定。它不是一个聊天页面的功能清单，而是业务产品、Agent 能力和数据平台之间的共同契约。功能说明用户看到什么，Agent 需求说明完成任务要具备什么能力，数据产品说明企业长期向这些能力提供什么上下文。

20.1 一、产品概述

产品名称： 设备售后上下文产品。
首个消费者： 售后诊断与备件协同助手。
目标用户： 指定区域的一线售后工程师、售后专家和区域主管。
核心任务： 在目标设备故障处理中，聚合设备配置、适用资料、确认案例、保修规则与备件状态，支持带证据的诊断和工单草稿。
产品所有者： 售后业务负责人与数据产品经理共同负责价值和语义，数据工程与平台负责服务，安全负责最低控制。

价值主张不是“提供统一数据接口”，而是减少跨系统搜索、缩短形成初步诊断的时间，并在不增加高风险错误的前提下提高经验复用。

20.2 二、目标与非目标

首期目标：

  1. 范围内设备能通过工单或序列号识别，并返回配置与质量状态；
  2. 能找到对当前型号、版本和时间有效的正式资料；
  3. 能召回有确认结果的相似故障案例；
  4. 保修与库存通过权威服务查询，不由模型猜测；
  5. 每个关键建议带来源、限制和更新时间；
  6. 工程师修改和最终结案能够进入反馈；
  7. 系统在证据不足、数据陈旧或越权时安全降级。

非目标包括全品类知识库、自动维修、自动对客承诺、库存锁定、设备远程控制、用用户反馈自动训练。非目标在路线图评审后才能改变。

20.3 三、用户故事

一线工程师： 当我打开工单时，希望助手自动识别设备并展示当前可确认配置，使我不用在多个系统中重复输入；当我描述故障时，希望看到适用手册、案例和步骤，并能打开原始证据；当资料不足时，希望系统明确告诉我缺什么。

售后专家： 当助手无法判断或工程师提出修订时，希望收到结构化上下文和证据，而不是重新询问全部背景；我确认的结论可成为候选案例，但发布前仍能审核。

区域主管： 希望看到采用、诊断时间、一次解决、风险和成本，不以对话量作为成功；出现高风险错误时，可以冻结相应工具或范围。

数据运营： 希望质量事件能定位源、影响产品与负责人；修复后可重放并验证，不手工修改多个索引。

20.4 四、任务流程

  1. 用户从工单进入，系统取得任务、身份和设备候选；
  2. get_asset_context 返回设备配置、有效时间、来源和缺口；
  3. 用户输入症状或故障码；
  4. search_service_evidence 按设备与权限召回正式资料和确认案例；
  5. check_warranty 与 query_part_availability 查询确定事实；
  6. Agent 生成结构化诊断：原因、置信、步骤、引用、备件、限制；
  7. 证据不足时澄清或转专家；
  8. 用户采纳或修改，生成工单草稿；
  9. 用户确认提交；
  10. 结案时回填真实原因、步骤和实际备件，进入审核反馈。

任何步骤的失败都要有明确状态，不以一段模糊文本掩盖。

20.5 五、数据输入

数据对象 权威来源 关键语义 首期时效
设备与客户 ERP/CRM 唯一标识、安装关系 小时级
出厂与变更配置 MES/工单 有效时间、确认状态 十分钟至小时
正式手册与公告 文档库 版本、适用型号、生效 发布后十分钟
历史工单 工单系统 原因、处置、结果、审核 日级
告警 设备平台 事件时间、错误码 分钟级
保修 规则服务 条件、版本、结论 请求时
备件状态 库存服务 可查询量、仓库、时间 请求时
用户权限 身份与工单 角色、区域、客户关系 请求时

每项输入保留所有者、模式版本、质量与血缘。无法判断的配置冲突返回“待核实”，不静默合并。

20.6 六、产品输出

产品发布五个端口：

  1. 设备上下文 API：结构化设备、配置、客户关系与质量；
  2. 适用资料检索：正式文档块、版本、页码和适用原因；
  3. 确认案例检索：脱敏案例、相似因素、最终结果和审核；
  4. 规则与状态工具：保修、库存、权限等权威结论；
  5. 反馈事件：采纳、修订、升级、实际结果和审核状态。

内部表、原始向量和凭据不对 Agent 暴露。端口有版本、认证、限流、错误码和示例。

20.7 七、输出契约

诊断结果采用结构化模式：

task_id: 任务标识
asset:
  id: 设备标识
  context_status: confirmed | incomplete | conflict
possible_causes:
  - label: 原因
    confidence: 0-1
    evidence_ids: [证据]
recommended_steps:
  - sequence: 顺序
    action: 操作
    safety_level: normal | warning | stop
parts:
  - part_id: 零件
    status_time: 查询时间
    commitment: recommendation_only
limitations: [信息缺口]
decision: answer | clarify | abstain | escalate

关键事实只能来自工具结果，建议必须连接证据。自由语言回答由该结构生成，方便用户阅读；结构本身保存用于评估和审计。

20.8 八、服务等级

案例首期 SLO 由真实基线校准，这里给出设计方向：

  • 设备识别对范围内样本达到约定覆盖，冲突不计为成功；
  • 正式资料结果全部可追到有效文档位置；
  • 设备上下文与检索端口在交互允许时间内返回；
  • 配置、文档、告警和库存分别满足各自数据年龄；
  • 服务不可用时展示状态并提供原系统入口；
  • 高风险建议、越权和未经确认动作不得发生。

质量达标率按任务切片观察，不以简单平均隐藏特定设备系列问题。SLO 超标触发警告或阻断门禁。

20.9 九、权限与隐私

Agent 使用用户委托身份。工程师只查看所负责工单和客户范围；历史案例去除姓名、电话和地址；合同仅返回与保修相关的结论和依据，不返回完整价格附件；库存只查询，不预留。

检索前过滤文档和案例，引用访问执行同一策略。模型不可接触凭据，提示与日志最小化。外部文档视为不可信内容，不能改变工具白名单。工单草稿必须由用户预览确认。

20.10 十、质量与数据契约

关键门禁包括：

  • 设备标识、型号和配置关系；
  • 手册适用型号、版本与有效日期；
  • 结案案例有确认原因和实际处置；
  • 文档块保留标题、页码、源版本与权限；
  • 库存、保修和权限工具返回时间和规则版本；
  • 源变更、删除和撤回传播到索引；
  • 反馈发布前经过领域审核。

契约变更通过兼容检查和血缘通知。破坏性变化提供并行版本与迁移窗口。

20.11 十一、评估

离线集合包括常见故障、复杂组合、相似型号、旧手册、配置缺失、库存超时、权限越界、提示注入和无答案问题。分别评估数据、召回、引用、生成、工具和任务。

上线采用影子—专家试用—有限工程师的顺序。线上记录证据采纳、人工修改、转专家、草稿提交和最终结果。高风险错误单独统计，任何严重越权或危险操作触发冻结。

主业务指标为形成初步诊断的时间和有效诊断任务；结果指标观察一次修复和重复上门；护栏包括严重错误、越权、审批绕过和单位成功任务成本。

20.12 十二、人工兜底

以下情况必须澄清或升级：

  • 无法唯一识别设备；
  • 当前配置缺失或冲突；
  • 没有适用的正式资料；
  • 证据相互冲突；
  • 数据超过任务允许年龄；
  • 用户无权访问必要上下文；
  • 涉及安全控制、合同承诺或不可逆动作；
  • 工具返回不确定执行状态。

升级包包含任务、已知事实、证据、缺口和尝试，不让专家从头收集。专家结论进入候选反馈，经审核后发布。

20.13 十三、依赖与风险

依赖包括源系统只读接口、统一身份、文档发布规范、工单反馈字段、模型和检索基础设施。主要风险及缓解：

风险 缓解
设备映射不足 缩小范围、人工核实、源流程修正
手册版本错误 适用元数据、认证、有效期过滤
工单噪声 只用已确认案例、专家审核
模型过度回答 结构输出、证据校验、拒答
权限泄漏 前置过滤、委托身份、审计
用户不采用 嵌入工单、减少重复录入、共创
成本增长 分层模型、缓存、按成功任务核算

20.14 十四、验收标准

首期进入生产必须满足：

  • 规定范围和用户真实可用；
  • 关键输入有负责人、契约和自动质量监测；
  • 端口有认证、版本、SLO、错误和降级；
  • 评测通过普通、边界、无答案和安全门禁；
  • 每个关键结论有证据或明确拒答；
  • 工单草稿需要确认，未开放动作无法调用；
  • 反馈与最终结果可关联，发布有审核；
  • 基线、价值、风险和成本看板可运行；
  • 值班、故障、回滚和专家接管完成演练。

20.15 十五、发布与迭代

0.1 版本验证设备识别与资料检索；0.2 增加权威规则和工单草稿；1.0 达到产品化门禁后面向限定生产用户。新增设备系列必须单独验证标识、手册、案例和权限，不能因为代码相同自动纳入。

产品待办按失败和业务价值排序：先修会导致错误任务的上下文，再优化召回与体验，最后增加范围和动作。每次路线图评审都可决定扩展、保持或停止。

20.16 本章交付物：一份共同承诺

这份 PRD 的价值不在页数，而在它让不同团队说同一种可验收语言。业务知道助手改变哪段流程，用户知道什么时候应信任或升级，数据团队知道要交付哪些实体与 SLO，架构团队知道端口与依赖，安全团队知道权限和动作边界，管理层知道用什么指标判断投资。

当 PRD 能把用户任务、Agent 能力和数据产品责任连接起来，AI 项目才不再由界面演示推动，而由真实闭环推动。

PRD 不是签字后冻结的需求。试点中发现设备识别比预想更差，产品应缩小范围或增加核实；若用户几乎不使用某项检索，团队应检查流程而非继续扩建。每次调整都保留假设、证据和版本，避免需求随意见漂移。

产品经理在这一过程中承担翻译与取舍：把业务焦虑变成任务，把任务变成数据承诺，把风险变成产品行为，把架构限制变成用户可理解的降级。正是这种端到端责任，而不是列举功能，使 AI 数据产品岗位区别于一般需求管理。

它也让每一次取舍都有依据。