AI Reference Implementation：模式库与复用保证架构
AI reference implementation 不是示例代码，也不是组件目录。它是一个经过治理、可运行、带证据的可复用模式实现：团队复用的不只是 prompt、RAG、tool gateway 或 UI skeleton，还要复用质量门禁、安全控制、eval baseline、observability、证据包、偏差处理、版本生命周期和适用边界。
AI Reference Implementation / Pattern Library / Reuse Assurance Architecture 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_REFERENCE_IMPLEMENTATION_PATTERN_LIBRARY_REUSE_ASSURANCE_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
重要说明: 本文是学习和架构训练材料, 不构成法律意见、监管解释、审计结论、信息安全认证、模型验证结论或生产上线批准。金融零售正式项目必须由授权的业务、风险、合规、隐私、安全、模型风险、技术和审计角色确认。访问日期按 2026-06-30 记录。
Source Anchors
这些来源用于校准 AI 风险管理、AI 管理体系、架构描述、平台工程、工程绩效和可观测性语言。本文关注 reference implementation、pattern assurance 和 reusable evidence, 不把它扩展成完整 AI platform service catalog、golden path 目录或 product line engineering 方法。
| Source | Official link | 本文采用的思想 |
|---|---|---|
| NIST AI Risk Management Framework | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 组织 AI 模式的风险分类、控制证据、监测和持续改进 |
| ISO/IEC 42001 AI management system | https://www.iso.org/standard/81230.html | 用 AI management system 的 policy、objective、operation、performance evaluation、management review 和 improvement 管理可复用模式 |
| ISO/IEC/IEEE 42010 Architecture Description | https://www.iso.org/standard/74393.html | 用 stakeholder concerns、viewpoints、architecture rationale 和 architecture description 组织 pattern 的多视图描述 |
| CNCF Platforms White Paper | https://tag-app-delivery.cncf.io/whitepapers/platforms/ | 用 platform as product、self-service 和 paved-path 思想定义平台团队与产品团队的接口, 但不把本文变成 service catalog |
| DORA | https://dora.dev/ | 用 deployment frequency、lead time、change fail rate、time to restore 的思想衡量 reference implementation 对交付流和恢复能力的影响 |
| OpenTelemetry Documentation | https://opentelemetry.io/docs/ | 用 traces、metrics、logs 和 semantic conventions 的思想设计 AI pattern 的 observability skeleton 和 evidence trace |
核心导读
AI reference implementation 不是示例代码，也不是组件目录。它是一个经过治理、可运行、带证据的可复用模式实现：团队复用的不只是 prompt、RAG、tool gateway 或 UI skeleton，还要复用质量门禁、安全控制、eval baseline、observability、证据包、偏差处理、版本生命周期和适用边界。
模式库的最大风险是把成功经验复制成不可见风险。成熟的 reuse architecture 必须回答：这个模式适用于哪些场景、依赖哪些假设、继承哪些控制、需要哪些本地化、如何证明复用后仍然安全可靠、何时必须偏离或废弃。
问题定义
企业 AI 规模化后会反复出现相同模式：
policy RAG
customer service copilot
case evidence extraction
tool-calling workflow
human review queue
AI eval harness
prompt and retrieval observability
audit evidence package
如果每个团队都从零实现，结果通常是交付慢、质量不稳定、控制证据重复、平台接口混乱、风险口径不一致。如果简单复制代码，又会把原场景的假设、权限、数据边界、eval 数据和合规约束误带到新场景。
因此问题不是“如何建立一个模板库”，而是“如何让可复用资产携带可复用 assurance，同时让本地场景的差异被显式评估”。
核心原理/方法
几个概念必须分开：
| 概念 | 定义 | 主要风险 |
|---|---|---|
| Pattern | 对一类问题的抽象解决结构 | 太抽象，无法直接落地 |
| Template | 起步文件或配置骨架 | 容易复制代码但不复制控制 |
| Golden path | 推荐交付路径和平台能力组合 | 可能变成强制流程，压制合理差异 |
| Reference implementation | 可运行、可验证、带证据的模式实例 | 若边界不清，会被误用到不适用场景 |
| Pattern library | 管理模式、适用性、版本、证据、偏差和采用度的体系 | 可能沦为静态文档目录 |
Reference implementation 应包含四类资产：
| 资产 | 内容 |
|---|---|
| Runnable skeleton | 最小可运行实现、接口契约、配置、部署路径、测试 |
| Assurance skeleton | eval baseline、安全控制、权限、数据分类、风险边界 |
| Observability skeleton | traces、metrics、logs、cost、latency、groundedness、tool events |
| Evidence skeleton | 架构决策、控制映射、测试报告、risk acceptance、deviation records |
模式成熟度可以分层：
| 等级 | 特征 |
|---|---|
| L0 ad hoc | 只有某项目代码或文档片段 |
| L1 repeatable | 有基本模板和说明，但证据弱 |
| L2 governed | 有适用边界、owner、版本、eval 和安全控制 |
| L3 assured | 有可继承证据包、偏差流程、监控和定期复核 |
| L4 productized | 有自服务接入、telemetry、支持模型和持续改进机制 |
系统/架构模型
参考架构：
pattern intake and classification
-> reference implementation repository
-> control and evidence pack registry
-> eval and observability baseline
-> reuse qualification workflow
-> local adaptation and deviation record
-> deployment and monitoring integration
-> lifecycle review, deprecation and reuse ROI tracking
关键组件：
| 组件 | 架构职责 |
|---|---|
| Pattern registry | 管理 pattern family、适用场景、owner、版本、成熟度、依赖和状态 |
| Reference repository | 存放 runnable skeleton、IaC、接口、测试、示例数据和文档 |
| Control mapping | 把模式映射到 AI risk、安全、隐私、记录、模型风险和运营控制 |
| Eval baseline registry | 保存评测数据、指标、阈值、失败样本、红队用例和本地化要求 |
| Observability contract | 定义必须采集的 trace、metric、log、事件和证据关联字段 |
| Reuse qualification workflow | 判断新用例是否可直接复用、需本地化、需偏差审批或禁止复用 |
| Deviation process | 记录偏离原因、风险补偿、批准、有效期和复核条件 |
| Adoption telemetry | 追踪采用、交付周期、缺陷、incident、control reuse 和维护成本 |
模式卡片不应只是描述。它应包含：
pattern_id:
version:
problem_class:
allowed_use_cases:
excluded_use_cases:
data_classes:
required_controls:
eval_baseline:
observability_contract:
security_assumptions:
human_review_boundary:
known_failure_modes:
reuse_qualification_questions:
deviation_approval_required_when:
lifecycle_state:
evidence_pack_link:
关键机制与取舍
标准化与本地适配是核心张力。强标准化能降低重复建设和治理成本，但金融零售场景中的数据分类、客户影响、监管边界、操作流程和模型风险等级差异很大。模式库必须允许受控偏差，而不是把所有场景压成同一实现。
控制继承必须有证据边界。某个 RAG pattern 已经通过安全审查，不代表新用例也自动通过。可继承的是通用控制，如日志结构、检索引用、权限过滤、prompt injection 防护、eval harness；不可继承的是具体数据授权、业务规则、客户影响评估和上线批准。
Eval baseline 要分成 reusable 与 local 两层。Reusable baseline 覆盖通用能力：groundedness、citation completeness、refusal、PII leakage、prompt injection、tool misuse、latency、cost。Local eval 覆盖具体业务规则、政策口径、产品术语、客户沟通边界和失败后果。
Reference implementation 要避免两种极端：只给代码会复制风险；只给治理清单会降低采用。最有效的形态是可运行 skeleton + 自动化检查 + 最小证据包 + 清晰偏差流程，让团队在默认路径上更快，同时在偏离时必须说清楚原因。
模式生命周期要有废弃机制。模型供应商变化、法规变化、安全漏洞、eval 失败、incident、数据接口变更、组织控制要求变化，都可能让一个模式从 approved 降级为 restricted 或 deprecated。
证据与控制
Reusable evidence pack 应包括：
| 证据 | 用途 |
|---|---|
| Architecture decision record | 说明模式选择、替代方案、约束和责任边界 |
| Threat and misuse analysis | 覆盖 prompt injection、data leakage、tool misuse、overreliance |
| Control mapping | 映射到 AI risk、安全、隐私、记录、运营和审计控制 |
| Eval report | baseline 数据、指标、阈值、失败样本和复测计划 |
| Observability contract | trace/span/event/metric/log 字段和 evidence linkage |
| Access and data classification | 支持的数据类别、禁止数据、权限模型和脱敏要求 |
| Human review boundary | 哪些动作可自动化，哪些必须人工确认 |
| Version and dependency record | 模型、库、prompt、embedding、retriever、tool gateway、policy 版本 |
| Deviation records | 本地化差异、补偿控制、批准人、到期复核 |
复用审批不应只问“能不能复用代码”，而应问：
use case 是否属于 pattern 的 allowed_use_cases
数据类别是否在 approved boundary 内
客户/资金/合规影响是否改变风险等级
local eval 是否覆盖业务规则和失败模式
observability 是否接入统一证据链
human review boundary 是否保持一致
偏差是否记录、批准并设置复核期
金融零售/AI产品场景
客户政策 RAG 可以复用 retrieval、citation、permission filtering、groundedness eval、refusal guardrail 和 observability skeleton。但每个产品线必须本地化政策语料、术语、客户沟通边界和升级路径。
内部操作 copilot 可以复用 tool gateway、step-by-step evidence logging、human confirmation 和 action preview。不同业务域要单独定义可调用工具、审批门槛、写操作限制和回滚路径。
AML investigation workbench 可以复用 evidence card、case summarization、gap detection、graph context display 和 audit event model。不能复用的是 SAR 判断、具体 red flag 权重、机构阈值和法律口径。
KYC evidence extraction 可以复用 OCR/LLM extraction schema、confidence scoring、human review queue 和 record linkage。不同市场的证件类型、语言、隐私要求和拒绝理由必须本地化。
Payment exception assistant 可以复用 event graph、exception taxonomy、repair draft 和 maker-checker evidence model。Rail rules、cut-off calendar、ledger posting authority 和 treasury handoff 不能被模板硬编码。
反模式
| 反模式 | 风险 |
|---|---|
| 模式库只是 wiki 页面 | 没有 runnable skeleton、eval、控制和证据，难以真正复用 |
| 复制代码不复制假设 | 原场景的数据、权限、风险和流程边界被隐形继承 |
| 把 golden path 当强制架构 | 合理场景差异被压制，团队绕开平台 |
| 没有偏差流程 | 变更藏在代码和配置里，审计与复盘无法解释 |
| 控制证据无限继承 | 新用例风险等级变化却没有重新评估 |
| 不监控采用质量 | 只知道被用了多少次，不知道是否降低缺陷或提升控制 |
| 没有废弃机制 | 旧模式在模型、规则或安全边界变化后继续传播 |
最终心智模型
AI reference implementation 的目标不是让团队少写几行代码，而是让组织复用经过验证的系统形态和控制证据，同时把本地差异显式化：
reusable pattern
+ runnable implementation
+ eval baseline
+ observability contract
+ security and governance controls
+ evidence pack
+ qualification workflow
+ deviation and lifecycle management
+ adoption and value telemetry
当一个模式只能被复制，不能被验证、监控、偏离、废弃和审计，它还不是 reference implementation。真正可复用的是 assurance architecture，而不只是实现片段。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。