7 数据产品路线图与生命周期

本章产出： 一张从验证、产品化、复用到规模化的路线图，以及与之配套的数据产品生命周期和阶段门禁。

AI 项目最容易获得掌声的时刻，往往是第一次演示：用户说出一个问题，屏幕很快返回一段流畅回答。最容易失去方向的时刻，则是演示之后。业务提出增加更多文档，管理者希望立即推广全公司，技术团队忙着扩容和更换模型，安全团队在上线前才第一次看见方案。所有人都在前进，却没有共同的路线图来回答：眼下究竟要验证什么，什么时候可以扩大范围，哪些基础能力应该复用，什么时候应当停止。

数据产品路线图不是功能排期表。它应同时表达业务假设、用户范围、数据边界、架构能力、治理控制、运营责任和价值证据。每一个阶段都要用上一阶段产生的证据换取下一阶段的投入，而不是用领导期待或技术热度代替证据。

7.1 路线图从不确定性开始

传统系统常在需求相对明确后进行建设，而 Agent 场景包含多层不确定性：用户是否愿意改变工作方式，企业数据能否支持任务，模型能否在边界内稳定工作，风险控制是否可接受，单位成本能否规模化。路线图首先要排列这些不确定性，而不是排列功能数量。

可以把不确定性分为五类：

价值不确定性：问题是否足够重要，改善后是否值得持续投资；
使用不确定性：目标用户是否会在真实流程中采用，而非只在培训时体验；
数据不确定性：关键上下文是否存在、可连接、可授权并保持新鲜；
技术不确定性：检索、推理和工具调用是否能满足任务与时延要求；
风险不确定性：错误、越权、隐私泄露和动作失控能否被约束。

早期路线图要优先验证最可能让项目失败的假设。例如山城精工如果大量设备缺少可关联的序列号，那么再优化语言模型也无法给出适用手册；如果工程师不愿在现场多打开一个应用，再高的离线准确率也不会产生价值。先找到“最大未知”，团队才知道下一笔投入用于补数据、改流程还是调技术。

7.2 四个阶段，而不是一次大上线

7.2.1 阶段一：验证期

验证期的目标是证明一个受控场景中存在可重复的价值信号。范围应主动收窄：一个核心用户群、一段明确流程、少量高价值数据源、有限设备或客户范围，并保留人工兜底。系统可以有部分手工处理，但关键过程必须可观察，不能用幕后人工伪装自动能力。

这一阶段要建立最小评测集和上线前基线。山城精工可选择一个服务区域、两个主力设备系列和十余名经验层次不同的工程师。助手运行在影子或建议模式，只展示诊断依据、排查步骤和备件建议；所有外部承诺与系统写操作都由人确认。团队记录当前跨系统搜索时间、平均诊断时长、首次解决率和典型失败样本。

验证期不是追求完整平台。可以接受部分文档人工校验、部分数据每日同步、少量规则显式配置，但不能妥协的底线包括身份认证、敏感信息控制、来源引用、拒答能力和关键操作审计。阶段结束的证据应是：在目标样本上任务质量达到最低门槛，真实用户愿意持续使用，且至少一个流程指标显示改善方向，没有触发不可接受的安全风险。

7.2.2 阶段二：产品化期

验证价值之后，目标从“能运行”变为“可依赖”。此前隐藏的手工步骤需要被识别：谁在更新文档，谁处理实体匹配失败，谁判断规则冲突，服务中断时谁响应。产品化不是简单扩用户，而是为已有承诺补齐契约、监控、权限、版本和运营。

这一阶段要把 MVDP 固化为正式数据产品：输入有权威来源与责任人，转换过程可追踪，输出接口有版本，关键质量能够自动检测，服务等级能够被观察，变更会通知消费者，反馈可以进入待办。Agent 侧要形成离线评测、影子测试、小流量发布和回滚机制；工具调用要具备幂等、超时、审批和失败补偿。

对山城精工而言，产品化期可将设备上下文 API、证据检索服务和备件查询工具作为正式输出端口；将手册适用范围、保修规则有效期和设备配置完整率设为质量门禁；建立售后业务、数据产品、平台、安全共同参与的每周运营评审。阶段结束不以“功能全部开发”为准，而以目标用户能够在生产环境稳定依赖、异常有负责人接住为准。

7.2.3 阶段三：复用期

当第一个场景成功后，组织通常会提出更多助手。此时最危险的做法是复制整个项目：每个团队重新抽取客户、设备和组织数据，重新解析文档，重新做权限，重新建设自己的向量库。短期看速度快，长期会形成语义冲突、成本重复和安全盲区。

复用期的目标是识别哪些能力属于某一场景，哪些可以成为共享产品或平台能力。设备标识解析、客户权限、企业术语、文档版本、通用检索、身份传递、审计、反馈采集和评测框架通常具有复用价值；而具体故障判断规则、售后工作流和备件推荐策略仍应由领域负责。

复用不是建设一个包揽所有需求的“大一统平台”。共享能力要有清晰消费者、接口和服务承诺，同样按产品运营。新场景应通过标准端口组合上下文，而不是直接读取第一个场景的内部表。阶段成功的标志包括：第二个、第三个场景的交付周期明显缩短，共享组件的消费增长而不降低可靠性，领域差异能够通过契约扩展而非复制代码解决。

7.2.4 阶段四：规模化期

规模化不是简单增加用户数，而是让多个领域能够在共同规则下自治。中心团队不可能审批每个字段，也不应替各业务域解释语义。企业需要建立联邦式运营：领域团队对数据产品的含义、质量和价值负责，平台团队提供发现、契约、血缘、权限、可观测、评测与交付能力，治理和安全团队定义最低控制与风险分级。

此时路线图的单位也会变化：从单个功能和项目，转向数据产品组合、共享能力和组织机制。管理层要看到哪些产品支撑了多个 Agent，哪些产品成本高但无人使用，哪些领域成为瓶颈，哪些高风险动作需要集中控制。规模化成功不是“全公司都有聊天机器人”，而是新场景能以较低边际成本获得可信上下文，并在统一护栏内快速试验。

7.3 用阶段门禁控制扩张

每一阶段都应设置进入与退出门禁。门禁不是为了增加审批，而是防止在证据不足时放大风险。

阶段	核心问题	典型退出证据
验证	值得做、能做、有人用吗	基线、任务评测、真实采用、风险初判
产品化	能稳定依赖吗	契约、SLO、监控、权限、运营与回滚
复用	能以产品方式支持更多场景吗	标准端口、复用消费者、交付周期改善
规模化	能在自治与统一控制间平衡吗	组合治理、域责任、单位成本与风险态势

门禁指标必须包含主指标和护栏。即使平均诊断时长下降，只要出现严重安全建议或越权访问，就不能扩大自动化范围；即使离线准确率很高，如果真实采用率低，也不应立即推广到更多区域。门禁还应明确由谁签署：业务负责人确认价值和流程，数据产品负责人确认契约与运营，架构负责人确认可演进性，安全和治理负责人确认风险控制。

7.4 一份可执行的九十天路线图

路线图应根据企业现实调整，下面的九十天安排不是固定模板，而是一种把证据逐步做实的节奏。

7.4.1 第 0—30 天：确定问题并建立基线

团队跟随用户观察真实工作，确认任务、风险和不做范围；完成数据盘点、实体与语义冲突调查；抽取第一批黄金样本与边界样本；记录流程基线；形成 Agent 数据需求卡、MVDP 画布和初版架构决策。这个阶段最重要的成果不是代码，而是团队对问题和验收口径形成同一理解。

山城精工在此期间应核对设备序列号覆盖、手册版本与型号的对应关系、历史工单结论质量、库存状态口径以及用户权限来源。若发现关键数据缺口，立即降低首期范围或增加人工确认，而不是把问题留给模型猜测。

7.4.2 第 31—60 天：构建闭环并受控试用

建立最小数据管道和上下文服务，完成检索与工具接口，设置身份、证据和审计；运行离线评测和影子测试；让小范围用户在建议模式下试用；记录人工修订、最终动作与失败分类。每周审查错误样本，判断问题属于数据、规则、检索、模型、界面还是流程。

此时不要用频繁更换模型掩盖数据问题。若证据本身过期，模型再强也无法给出当前答案；若输出没有进入工单流程，用户仍需重复录入，采用率自然受限。产品经理应保持问题归因的完整性。

7.4.3 第 61—90 天：产品化并决定下一步

将验证中有效的手工过程转为可运营能力，补齐数据契约、质量门禁、监控告警、权限申请、版本变更、回滚和支持机制；扩大到有限生产人群，按基线衡量流程与业务结果；核算单次成功任务成本和人工审核成本。最后举行阶段评审，决定扩范围、继续优化、保持现状或停止项目。

停止也是合格的路线图结果。如果问题价值不足、数据成本长期高于收益、风险无法合理控制，及时结束比继续堆功能更专业。被证伪的假设、积累的评测集和治理缺口仍可成为组织资产。

7.5 把业务、产品、架构和治理放在同一张图上

许多路线图只有功能泳道：问答、搜索、推荐、自动执行。更完整的路线图至少包含五条同步演进的泳道：

业务与用户：范围、流程变化、培训、采用和价值；
数据产品：输入、语义、端口、契约、反馈和生命周期；
Agent 能力：检索、推理、工具、记忆、拒答和评测；
平台与架构：采集、处理、上下文、服务、监控与成本；
治理与组织：所有权、权限、风险分级、审计和运营节奏。

五条泳道必须在关键里程碑汇合。例如开放工单写入之前，Agent 工具能力准备好并不够，业务要定义哪些字段可自动生成，数据产品要承诺实体和状态质量，平台要支持幂等与回滚，安全要确认身份与审批，运营要能追踪结果。路线图由此成为跨团队的承诺图，而非某个研发小组的待办清单。

7.6 数据产品也需要出生、成长与退役

数据产品上线并不是生命周期的终点。完整生命周期包括发现、设计、构建、发布、运营、演进和退役。

在发现阶段确认消费者与价值；设计阶段定义边界、契约和责任；构建阶段实现并验证；发布阶段完成目录登记、文档、权限和支持；运营阶段持续观察 SLO、使用、价值和成本；演进阶段处理新消费者与破坏性变更；退役阶段通知依赖方、迁移消费、保留必要审计并安全删除数据。

每个产品应有生命周期状态，避免“看起来可用、实际无人维护”的僵尸资产。若一个端口连续多个周期无人消费，应确认是否降级或退役；若源系统即将替换，应提前发布兼容版本；若规则变化导致输出含义改变，应使用版本和生效日期，而不是悄悄覆盖。Agent 对上下文高度敏感，静默变更可能在界面无异常的情况下改变决策结果。

7.7 用架构决策记录保存“为什么”

路线图中的重大选择应形成架构决策记录：为什么首期只做建议模式，为什么库存采用查询而非事件推送，为什么先用检索增强而不建设完整知识图谱，为什么某类数据必须驻留在指定环境。记录应包含背景、选项、决定、后果、复审条件和负责人。

这类记录不是为了增加文档，而是保护组织记忆。三个月后团队看到一个范围限制时，能够知道它是临时验证假设还是长期合规要求；当数据规模、成本或模型能力变化时，也知道何时重新评估。路线图因此不是一次性预测，而是由一系列可复审决策构成的演进机制。

7.8 本章交付物：双层路线图

建议最终提交两层路线图。第一层面向管理与业务，用阶段、价值假设、用户范围、投资和门禁表达；第二层面向交付团队，用五条泳道列出数据产品、Agent、架构、治理和组织责任。每个里程碑都应标注证据、决策人和失败后的处理方式。

山城精工的首个九十天计划不应承诺“建成企业级智能平台”，而应承诺更具体的结果：在限定设备与区域内，让售后工程师获得带证据的诊断和备件建议；证明它能安全地缩短搜索与诊断时间；把设备上下文建设为可运营的数据产品；根据真实结果决定是否增加设备系列、区域或动作权限。

路线图的成熟，不体现在它画得多远，而在于最近一步足够清晰、下一步需要什么证据足够明确、错误扩张能够被及时阻止。数据产品正是在这样的节奏中从一次性项目成长为企业能力：先形成一个闭环，再让闭环稳定；先证明一项复用，再谈平台化；先让责任跟上智能，才让智能进入更大的组织范围。