AI Product Line Engineering / Reusable Platform Assets 解读

配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是 docs/AI_PRODUCT_LINE_ENGINEERING_REUSABLE_PLATFORM_ASSETS_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。

---

Source Anchors

核心导读

AI Product Line Engineering 的目标是把企业 AI 从“一堆一次性 use case”升级为“核心平台资产 + 明确可变点 + 业务线配置”的产品族。AI POC 难规模化, 往往不是模型不够强, 而是 prompt、RAG、eval、connector、policy、workflow、UX pattern 和证据格式都没有被系统复用。

这篇的核心判断是: 复用不是复制代码, 而是把可复用资产做成带 owner、版本、SLO、eval、风险边界、adoption telemetry 和 deprecation plan 的平台产品。

问题定义

典型 AI POC 路径:

业务提出 AI 助手
  -> 团队快速做 demo
  -> prompt 写在应用里
  -> 知识库临时上传
  -> eval 只靠人工试用
  -> 工具连接硬编码
  -> 上线前补权限和审计

第一个 POC 看起来快, 第十个 POC 会变慢:

• prompt 不可版本化。
• eval set 不可复用。
• RAG pipeline 无统一 metadata、permission 和 citation。
• 业务系统 connector 重复开发。
• policy guardrails 分散。
• human review workflow 每次重做。
• 审计证据格式不一致。
• 成本和质量无法横向比较。

Product line thinking 的核心问题是:

哪些能力应该作为 core asset 被平台产品化?
哪些差异必须作为 variation point 由业务线配置?

核心原理/方法

AI core asset taxonomy:

Variation points 必须显式管理:

系统/架构模型

AI product line 需要分离 domain engineering 与 application engineering:

Domain engineering
  -> define capability model
  -> build core assets
  -> manage reference architecture
  -> provide configuration and extension mechanisms
  -> operate eval, risk, security and observability guardrails

Application engineering
  -> select reusable assets
  -> configure business knowledge, workflow, thresholds and language
  -> add domain-specific eval cases
  -> design adoption and training
  -> own business outcome and operational performance

架构形态:

AI product family
  -> core platform assets
    -> model gateway
    -> RAG pipeline
    -> tool connectors
    -> EvalOps
    -> HITL workflow
    -> policy controls
    -> observability
  -> variation profiles
    -> domain
    -> risk tier
    -> jurisdiction
    -> channel
    -> workflow
    -> language
  -> application products
    -> AML case assist
    -> credit operations assist
    -> customer complaint assist
    -> KYC onboarding assist

平台不是“帮业务线做项目”, 而是提供可配置、可观测、可治理的核心资产。

关键机制与取舍

Product line architecture 的难点是避免两个极端:

• 平台过度统一: 业务线无法满足监管、流程和客户差异。
• 业务线过度自由: 复用失败, 风险、成本和证据失控。

复用 ROI 不能只看代码复用率:

Reuse ROI =
  reduced delivery time
  + reduced risk review effort
  + consistent evidence
  + lower unit cost
  + faster onboarding
  + better cross-domain learning
  - platform overhead

证据与控制

每个 core asset 都应有资产记录:

复用决策应记录:

AI产品/金融零售场景

Case assist product line

产品族:

• AML case assist。
• Credit operations case assist。
• Customer complaint case assist。
• KYC onboarding case assist。

共享核心资产:

可变点:

• 风险等级。
• 监管话术。
• 业务政策。
• 数据权限。
• SLA。
• 人工审批角色。

推进顺序:

1. 先做 case summary、citation 和 trace 这类低风险高复用资产。
2. 再做 policy RAG、eval harness 和 HITL queue。
3. 最后按业务线风险成熟度开放 tool/action capability。

AI platform assets

平台资产应按产品线管理: 例如 model gateway 不只是路由服务, 还包括 allowlist、cost policy、trace、vendor fallback 和 deprecation; EvalOps 不只是测试工具, 还包括 dataset registry、judge calibration、risk-tier threshold 和 release evidence。

反模式

最终心智模型

AI Product Line Engineering 的最终心智模型是:

把重复能力产品化;
把业务差异参数化;
把风险控制平台化;
把评估和证据标准化;
把新项目中的通用能力反哺为核心资产。

企业 AI 规模化不靠不断启动新项目, 而靠形成可复用、可配置、可治理的产品族。复用的目标不是减少所有差异, 而是让差异发生在明确、可审查、可运营的 variation points 上。

---

SOTA 状态标注 (2026-07-01)

本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。