22 案例：90 天路线与架构复盘
本章产出： 山城精工的 30/60/90 天实施路线、工作流、风险台账、阶段门禁和架构复盘模板。
本路线延续虚构案例，不承诺九十天完成“企业级 AI 平台”。它承诺在限定范围内做出一个可运行、可度量、可停止的闭环，并把首期能力沉淀为数据产品。时间表的意义不是把每项任务排满，而是让每三十天产生一组足以支持下一步决策的证据。
22.1 项目治理
设立一个小型跨职能核心组：
- 业务负责人：确定流程、规则、用户与价值；
- 数据产品经理：场景、PRD、数据产品、指标与路线；
- 数据架构师：目标架构、契约、ADR 与演进；
- 数据工程：采集、实体、质量和服务；
- Agent/应用工程：检索、编排、工具和体验；
- 安全与治理：权限、隐私、审计和风险门禁；
- 售后专家与试点工程师：样本、验收和反馈。
每周工作评审查看失败与阻塞，每两周产品评审看用户和价值，每三十天阶段门禁决定继续、调整或停止。项目不以研发完成率替代结果。
22.2 第 0—30 天：定义与证伪
22.2.1 业务工作
跟随不同经验水平的工程师观察真实工单，确认用户旅程、等待、风险和替代方案；选择两个设备系列、一个区域和试点人员；建立诊断时长、搜索入口、专家咨询、一次解决和重复上门的基线。
形成任务契约和不做清单。与安全、售后和管理者确认：首期只建议与草稿，不锁库存、不改合同、不直接对客、不控制设备。
22.2.2 数据工作
盘点 ERP、MES、CRM、工单、设备、文档、库存和身份，抽取真实小样本。检查设备标识覆盖、配置有效时间、手册适用元数据、工单结论、告警时钟、库存 API 和动态权限。
建立源地图、所有者和初版数据契约。关键缺口立即影响范围。例如某设备系列手册适用关系无法补齐，就不纳入首期。
22.2.3 技术工作
完成最小技术探针：设备身份查询、文档解析样本、混合检索、权威库存调用和身份传递。技术探针只验证最大未知，不建设完整界面。
确定关键 ADR：组合检索、请求时权威查询、任务级 API、建议模式。形成目标架构和粗略成本。
22.2.4 评估工作
由专家和历史工单构建首批评测集，包括常见、困难、相似型号、旧版本、无答案、越权和提示注入。定义各层指标、风险权重和上线门禁。
22.2.5 30 天门禁
继续条件：
- 任务频率和痛点有真实证据；
- 范围内关键设备与资料达到最低可用；
- 用户愿意参与试点；
- 技术探针证明可在可接受延迟取得上下文；
- 权限和建议模式能控制首期风险；
- 有可度量基线和初版评测。
若关键身份无法建立、资料不可信或价值很弱，缩小范围、改场景或停止。阶段成果是被验证的问题，不是演示视频。
22.3 第 31—60 天：最小闭环
22.3.1 数据产品
建设设备售后上下文产品 0.1：设备上下文 API、适用资料检索、确认案例检索、库存与保修查询。为关键输入建立实体映射、有效时间、来源和质量门禁。
原始证据可重放，文档块有版本和页码，索引与源对账。端口有认证、模式、错误码和基本监控。
22.3.2 Agent 与体验
助手嵌入工单入口，自动取得用户、任务和设备候选。输出结构化原因、步骤、证据、备件和限制；缺少身份或证据时澄清；所有工单只生成草稿。
先运行离线评测，再用真实请求影子运行。资深专家可以查看对照结果并标记失败，不影响正式业务。达到门槛后开放给少量试点工程师。
22.3.3 安全与运行
实施委托身份、检索前过滤、工具白名单、提示注入隔离、审计关联和敏感日志最小化。演练库存超时、文档索引陈旧、模型不可用、权限拒绝和重复草稿。
建立降级：返回原系统链接、禁止确定承诺、转专家、保留传统工单流程。没有降级就不扩大试点。
22.3.4 反馈
保存草稿与提交差异、证据采纳、转专家和结案结果。反馈有模式、权限和审核，未经确认不进入知识库。每周按数据、语义、检索、生成、工具、体验和业务分类失败。
22.3.5 60 天门禁
- 端到端评测达到首期门槛，高风险样本通过；
- 真实用户能够完成任务，且不需项目人员幕后操作；
- 身份、权限、引用、审计和人工确认有效；
- 数据与服务异常能够发现、降级和恢复；
- 用户反馈显示至少一个流程指标改善方向；
- 单次任务成本处于可接受量级。
若答案流畅但用户不采纳，优先研究证据和流程；若数据健康不足，暂停调模型，修复产品。
22.4 第 61—90 天：产品化与决策
22.4.1 稳定化
把试点中的人工步骤显式化：手册发布元数据、案例审核、实体冲突队列、质量事件、权限申请、值班和支持。补齐契约、SLO、版本、变更通知、回滚和备份。
增加黄金集和线上失败回归，实施模型、分块、索引、规则和工具变更测试。建立服务看板和风险事件响应。
22.4.2 有限扩量
在同一设备系列和区域内增加用户，不立即扩品类。通过队列比较经验、设备难度和使用方式。提供短培训，重点说明证据、限制和升级，不把助手描述为绝对正确。
业务负责人观察采用是否来自真实效率，而非行政要求。入口和重复录入问题进入产品改进。
22.4.3 价值与经济性
比较上线前后同口径的诊断时间、搜索入口、专家咨询、一次解决与重复上门；同时观察错误、越权、审批绕过和用户投诉。核算模型、检索、基础设施、API、运营与人工审核，按成功任务计算。
区分已证明与待观察：搜索时间可能九十天内明显变化，一次修复和客户影响需要更长窗口。不要为阶段汇报夸大因果。
22.4.4 90 天决策
可选结论：
- 扩展：价值、质量、采用、风险和成本均达到门槛；
- 保持：局部有价值，但继续在原范围稳定；
- 调整：场景正确但数据、体验或架构要改变；
- 停止：价值不足、成本过高或风险无法控制。
扩展也要选择一个维度：先扩设备系列、区域、用户或动作中的一个，避免同时改变导致无法归因。
22.5 工作分解
| 工作流 | 0—30 天 | 31—60 天 | 61—90 天 |
|---|---|---|---|
| 业务 | 场景、基线、范围 | 试点流程、专家兜底 | 采用、价值、扩展决定 |
| 数据产品 | 盘点、契约、MVDP | 端口、质量、反馈 | SLO、运营、生命周期 |
| 架构 | 探针、目标图、ADR | 最小链路、降级 | 稳定、复用、成本 |
| Agent | 样本、原型 | 影子、试用、草稿 | 回归、有限扩量 |
| 治理安全 | 威胁、权限设计 | 策略、审计、演练 | 事件响应、复审 |
| 组织 | 团队与门禁 | 值班和反馈节奏 | 产品所有权与组合 |
22.6 风险台账
| 风险 | 早期信号 | 所有者 | 应对 |
|---|---|---|---|
| 设备身份覆盖不足 | 澄清率高 | 售后/数据 | 收窄范围、修源流程 |
| 文档适用元数据差 | 旧版引用 | 文档所有者 | 发布门禁、人工认证 |
| 历史案例噪声 | 相似但错误 | 专家组 | 只用确认案例 |
| 用户不采用 | 调用后仍手工搜索 | 产品 | 融入工单、访谈改进 |
| 越权与泄漏 | 策略拒绝异常 | 安全 | 冻结、调查、修策略 |
| 工具重复动作 | 幂等冲突 | 服务团队 | 停写、补偿、回归 |
| 依赖不稳定 | 超时和降级增加 | 平台 | SLO、缓存、替代流程 |
| 成本失控 | 单位成本上升 | 产品/架构 | 路由、压缩、范围 |
| 专家审核瓶颈 | 候选积压 | 业务 | 风险分层、抽样 |
风险每周更新概率、影响和趋势。高风险没有所有者时不得进入下一门禁。
22.7 架构复盘框架
九十天复盘不是“完成了多少功能”，而回答：
22.7.1 目标与结果
原始问题是否存在，目标用户是否采用，哪些指标改善，护栏是否守住？报告样本、口径、时间和不确定性。
22.7.2 假设与证据
哪些假设被验证、证伪或仍未知？设备上下文是否真是瓶颈，证据引用是否建立信任，反馈是否改善案例？
22.7.3 失败与根因
按数据、语义、检索、生成、工具、体验、业务分类。重复失败背后是哪项组织责任或架构边界不清？是否存在用提示词掩盖数据问题？
22.7.4 架构质量
组件是否按责任工作，端口是否稳定，血缘能否重放，权限是否前置，降级是否有效，TCO 是否符合预期？哪些 ADR 触发复审？
22.7.5 组织与运营
所有者是否实际响应，专家审核是否可持续，数据问题是否回到源流程，业务、产品、平台和安全的节奏是否运行？
22.7.6 下一步
明确扩展、保持、调整或停止；下一阶段只选择最重要未知，写出预算、负责人、门禁与复审日期。
22.8 可能的复盘结论示例
假设九十天后，工程师使用率和证据打开率稳定，初步诊断时间下降，危险建议为零；但设备配置冲突导致澄清较多，首次修复率观察期不足，专家审核成本高。专业结论不是“项目圆满成功”，而是：
- 价值信号成立，可保持限定生产；
- 暂不扩大设备系列，优先修配置变更流程；
- 优化专家审核为高风险全审、普通案例抽样；
- 继续观察业务结果一个季度；
- 不开放库存预留；
- 第二场景只复用身份、实体、检索与评测，不复制内部索引。
这种结论保留了进展，也诚实面对证据边界。
22.9 从项目转入产品运营
九十天后若继续，临时项目组要转成明确运营模型。售后域承担设备语义、文档和案例；数据产品团队管理端口、SLO 和价值；平台提供元数据、质量、血缘、检索和工具治理；安全维护策略与事件响应。
路线图进入季度节奏：产品健康、用户与价值、风险和成本、能力复用。新需求通过场景矩阵评估，不直接塞进现有助手。未使用端口与过期数据进入退役。
22.10 本章交付物：决策型复盘
最终交付包括九十天时间线、每阶段证据与门禁、风险台账、指标对照、成本、失败分类、ADR 状态和下一步决定。所有结论链接到数据与样本，而不是只展示截图。
真正有价值的九十天，不是赶在截止日前上线一个 Agent，而是让企业第一次走通从业务问题、数据产品、架构治理到结果反馈的完整循环。即使最后选择停止，这套基线、契约、评测、数据缺口和决策方法也会留下。成熟的架构实践，正是用有限投入换取最大确定性，再决定企业下一步往哪里走。