Papers & Methodology

(TradFi × DeFi Bridge Architecture White Paper)

第1章 项目概览

本文记录了 Finance Research AI Agent v1 的完整设计与实现。该系统是一个面向 buyside 研究员、独立投资人与小型 FOF 的多 Agent 金融研究工具，能跨越 TradFi 与 Crypto 两个数据域，主动调用财报、链上数据、新闻和合规数据库完成深度研究任务。

本图是「学习内容 → 作品产出 → 能力证据」三层的索引，不是计划复述。三个状态标记贯穿全文：

2025 下半年开始，"会写 evals"从一个隐性的工程加分项，变成了 AI 产品岗位的显式职责。OpenAI 的 CPO 在一次公开访谈里直接说，"PM 最重要的技能是写 evals"（2025-08）；Hamel Husain 与 Shreya Shankar 的《AI Evals For Engineers & PMs》在 Maven 上累计训练了 2000+ 工程师与 PM，他们把这套方

2025 年是「会接 MCP」的红利年，2026 年是「会守 MCP」的稀缺年。当几乎所有 AI 产品都长出了工具调用能力之后，差异化不再来自「能不能调用一个外部工具」，而来自「当这个工具是恶意的、或被中途调包的时候，你的 agent 会不会被牵着走」。这正是 AI Solutions Architect（AISA）岗位在 2026 年被反复问到的那一类问题——它不是模型能力题，而是系统安全题。

日期：2026-08-15

日期：2026-09-12

日期：2026-09-19

日期：2026-10-04

日期：2026-10-07

企业架构（EA）这门学科有一个尴尬的现状：它最权威的方法论 TOGAF，至今没有为 agentic AI（自主代理型 AI）给出官方治理标准。

2025–2026 是稳定币从"DeFi 抵押物 / 投机筹码"正式变成"全球支付基础设施"的转折点：

不是"三巨头"了,2026 已是 Top-5 格局(早期叙事说 BUIDL/Ondo/Franklin 三巨头,现 Circle USYC、WisdomTree 已挤入):

以太坊一直有两类账户:

传统 swap:用户构造并签一笔确定路径的交易(走哪个池、什么滑点),自己承担 MEV、自己付 gas、跨链还得自己过桥。

1. 查询改写 / 分解(query rewriting/decomposition):检索前先改写——把 2-hop 问题拆成 2 个子查询、扩展实体、用领域词汇重述。

面向银行 AML 调查员的 AI Copilot：把「告警 → 证据汇集 → 洗钱类型学比对 → SAR 草稿」从每案 4-8 小时人工压缩到分钟级，全程 HITL 复核 + 审计轨迹，eval 体系先于 LLM 落地。

生产级 AI 工程不是“把模型接到产品里”，而是建立一套可以稳定交付、评估、监控、回滚和持续治理的工程系统。大模型应用改变了传统软件的若干基本假设：同样输入可能产生不同输出；自然语言结果难以用单个断言判断；成本和延迟随上下文、输出长度、路由策略大幅波动；知识、模型、prompt、工具和用户行为都会漂移。因此，AI 工程的中心从单点功能实现转向 eval-first、trace-first、gate

[前言：为谁而写](#前言为谁而写)

完成两件事：

完成两件事：

填写人/团队：

Blast：Phase 2 为期 12 个月至 2025 年 6 月；Points 约 0.065/Block/ETH（块约 2 秒），Gold 每月首周向 Dapp 发放。

主看板 / 对外分享：优先 Dune（案例多、易复现）

先读 ../AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md。本目录是论文和架构深度笔记库，不是要求从 1 到 174 平均用力读完的每日课程。

Transformer 的关键贡献不是“发明注意力”，而是把序列中任意位置的信息交互从递归状态和局部卷积里释放出来，用 self-attention 作为主干来实现全局、动态、可并行的上下文混合。它把 token 表示、位置信息、Q/K/V 匹配、multi-head 分解、feed-forward 加工、残差连接、归一化和 masking 组合成可以稳定堆叠的计算单元。

RAG 的关键不是给语言模型加一个搜索框，而是把模型参数中的隐式知识和外部可检索知识组合成一个可更新、可引用、可审计的生成系统。原论文把文档视为 latent variable：retriever 先给出候选 passages，generator 再在问题和证据条件下生成答案，并对多个候选文档路径进行概率整合。

ReAct 和 Toolformer 共同回答了语言模型从“生成文本”走向“执行任务”时的两个底层问题：运行时如何在推理、行动和观察之间形成闭环，训练时如何让模型学会何时调用外部工具。ReAct 把 reasoning、acting、observation 交错成可推进任务的轨迹；Toolformer 则展示模型可以用少量 API 示例和自监督筛选学习工具调用模式。

InstructGPT / RLHF 的关键不是让模型“更会聊天”，而是把基础语言模型的训练目标从续写高概率文本，推进到更稳定地遵循人类意图、格式约束、拒答边界和偏好排序。它用示范数据、候选回答排序、reward model 和 PPO 优化构成后训练流程，说明模型规模、语言能力和可用助手行为不是同一件事。

Chain-of-Thought 的原理是把多步问题拆成中间 token，让模型在生成过程中拥有可见的临时推理上下文。Self-Consistency 则不相信单条推理路径，而是采样多条候选路径，再对最终答案或结构化结论做聚合。二者共同说明：推理质量不只由模型参数决定，也受 test-time compute、解题程序、采样策略和验证方式影响。

LoRA 的原理不是“便宜微调”这么简单，而是把完整权重更新拆成冻结基座模型加少量低秩增量。模型主体保持不变，adapter 学习某个任务或领域所需的行为偏移；QLoRA 又通过量化冻结权重进一步降低训练门槛。PEFT 的核心思想，是只改动足够表达下游差异的那一小部分参数。

推理优化研究的是同一个模型在推理阶段如何更快、更便宜、更稳定地服务真实负载。KV cache 复用历史 token 的 Key / Value，减少自回归解码的重复计算；FlashAttention 通过 IO-aware exact attention 降低 attention 的高成本内存读写；speculative decoding 用小模型草稿和大模型验证缓解逐 token 串行瓶颈。

LLM-as-Judge 的原理是用强语言模型按照明确 rubric、输入证据和结构化返回格式，对开放式回答做 pointwise scoring、pairwise comparison 或维度化判断。G-Eval 说明评估可以由 criteria 和 evaluation steps 驱动，MT-Bench / Chatbot Arena 则展示了强模型 judge 在部分偏好评估中的可扩展性。

MoE 的原理是用 router 为每个 token 选择少数 expert 子网络，让模型拥有很大的总参数容量，但每次推理只激活一部分参数。这是一种 sparse scaling：总模型很大，active computation 相对受控。Switch Transformer 等工作进一步用 top-1 routing 简化了条件计算和分布式服务复杂度。

Scaling laws 研究的是参数量、训练数据量、计算预算和语言建模 loss 之间的经验规律。它解释为什么 foundation model 能随规模扩大获得更强迁移能力，也提醒团队不要把“更大”误读成唯一答案：Chinchilla 等工作说明，在固定算力下，模型大小和训练 token 的配比同样决定能力边界。

Preference optimization 解决的不是“模型是否知道事实”，而是“在多个可能回答中，模型默认更倾向哪一种行为”。SFT 用示范建立基本任务格式，RLHF 用偏好训练 reward model 再优化策略，DPO 直接提高 chosen answer 相对 rejected answer 的概率，Constitutional AI 则把原则、批评和修订引入反馈生成。

ReAct 和 Toolformer 代表的是同一个转变：LLM 不再只是生成文本，而是可以读取外部上下文、选择工具、观察结果并继续行动。Prompt injection 的原理也因此更清楚：当系统指令、用户请求、检索文档、网页、邮件、PDF 和工具返回都被拼进同一上下文时，不可信文本可能试图劫持模型的指令解释和工具选择。

RAG 的原理是把模型的参数记忆与外部检索记忆结合：先检索相关资料，再让生成模型基于上下文回答。RAGAS 的启发，是把这个过程拆成可评估对象：context 是否相关、是否覆盖答案所需信息，answer 是否回应问题，关键断言是否忠实于提供的 context。

GraphRAG 的原理是把文本切片、实体、关系、claim 和 community summary 组织成图谱，再把图谱检索与文本检索结合。普通 RAG 主要依赖相似片段，GraphRAG 则让系统可以沿实体邻居、关系路径和社区结构构造上下文，回答多跳关系和全局模式问题。

Generative Agents 的原理是把长期行为拆成 memory stream、retrieval、reflection 和 planning。Agent 持续记录观察和交互，按相关性、时间性和重要性召回记忆，再把零散事件反思成高层抽象，最后把抽象转成未来计划。它研究的是 AI 如何在一段时间内保持行为连续性，而不是一次性回答是否聪明。

AutoGen 的原理是把单个 agent 的观察、推理、工具调用循环扩展成多个 agent 之间的可编排对话。不同 agent 可以拥有不同角色、提示、工具、终止条件和人类参与方式；复杂任务由消息传递、共享状态和中间产物逐步推进，而不是由一个模型一次性完成。

HELM 的原理是把模型评估组织成 scenario、metric、model 和 run configuration 的矩阵。它不只问模型在某个 benchmark 上分数多高，还要求说明评估场景是什么、指标覆盖哪些质量和风险维度、prompt 和解码参数如何配置、结果在哪些边界内成立。

Model Cards 和 Datasheets 的原理，是把模型和数据从黑箱资产变成有上下文的治理对象。Model Card 说明模型用途、限制、评估和风险边界；Datasheet 说明数据集的动机、组成、收集、标注、预处理、授权、维护和禁用范围。二者共同回答：这个 AI 资产是在什么条件下构造和验证的。

Tree of Thoughts 的重点不是让模型输出更长的思考过程，而是把复杂任务拆成可生成、可评估、可回退、可停止的搜索问题。它把推理从单路径生成改造成受控搜索：系统先产生多个中间状态，再用评分器、搜索策略和停止条件决定哪些路径继续扩展。

Self-RAG 和 CRAG 的共同价值，是把 RAG 从“检索 top-k 文档再生成答案”的固定流水线，升级为会判断检索需求、检索质量、证据支持、纠错路径、拒答和升级条件的受控系统。它们把幻觉治理前移到证据选择和证据评价环节，而不是只在最终回答后做补救。

AgentBench 和 τ-bench 的价值不在于给 agent 排名，而在于重新定义评测对象：agent 不是单轮回答器，而是由模型、工具、状态、用户交互、业务规则、异常恢复和审计证据组成的运行系统。评测必须覆盖 action-observation loop，而不是只看最终文本。

Mechanistic interpretability 试图从模型内部找到可理解的特征、回路和计算机制。它关注的是模型如何在 residual stream、attention head、MLP feature 和稀疏特征之间组织计算，而不是只从输入输出行为归纳规律。

长上下文模型的关键不是“最多能放多少 token”，而是在给定成本、延迟、权限、噪音和版本冲突下，模型能否稳定找到、组合、引用并正确使用关键事实。Lost in the Middle 揭示模型对上下文位置敏感，中间信息更容易被忽略；RULER 和 LongBench 进一步说明标称 context length 不等于真实可用上下文长度。

DSPy、OPRO 和 APE 的共同价值，是把 prompt 从个人经验写作推进为可声明、可评测、可优化、可版本化的系统配置。它们不只是让模型自动生成“更好的提示词”，而是让任务定义、输入输出契约、评价指标、候选搜索和发布门禁形成工程闭环。

Reflexion 和 Self-Refine 的重点不是“模型会自我反思所以更聪明”，而是把失败、反馈、修订、重试和记忆组织成受控的推理时改进机制。它们说明 agent 可以在不更新模型权重的情况下，通过 verbal feedback、critic、memory 和 refinement policy 改善下一次尝试。

Process supervision 的核心不是把模型的思考过程展示给用户，而是把复杂任务拆成可验证步骤，并判断每一步是否使用了正确证据、遵守了业务规则、触发了合适边界。Let's Verify Step by Step 说明，复杂推理只看最终答案会掩盖错误路径；过程监督可以提供更密集的训练和评估信号。

结构化输出的核心不是“让模型尽量返回 JSON”，而是把模型输出变成下游系统可消费、可验证、可审计的契约。Constrained decoding、LMQL、Guidance、Outlines、Jsonformer 等方法说明，格式、字段、枚举和部分控制流可以由 schema、grammar 和程序化解码约束，而不是完全依赖提示词。

FrugalGPT、RouteLLM 和 semantic cache 的共同价值不是“用便宜模型省钱”，而是把每一次 AI 请求变成可治理的路由决策：这个请求在当前风险等级、质量要求、延迟预算、成本上限和数据边界下，应该走小模型、大模型、专用模型、RAG、缓存、级联、人审还是拒绝。

SWE-bench、WebArena、OSWorld 和 GAIA 的共同价值不是给 agent 排名，而是把模型放进真实或近真实环境：它必须理解目标、读取状态、调用工具、修改环境、处理反馈、恢复错误并交付可验证结果。它们把“能聊天”与“能完成工作”分开评测。

Mamba 的重要性不在于宣称“替代 Transformer”，而在于重新打开了一条序列建模路线：把历史信息压缩进可递推状态，并通过 selective mechanism 让模型按输入内容决定保留、遗忘和传播什么。它把长序列问题从全量 token-token attention 的计算形态，改写为状态更新、选择性写入和硬件友好扫描的组合。

Embedding 的核心价值是把文本、图片、用户、商品、交易、案件等对象映射到可比较的向量空间；ANN 的核心价值是用可控近似误差换取大规模检索速度。相似度提供的是候选生成信号，不是事实证明、权限判断或业务决策。

CLIP 的关键贡献不是又训练了一个图片分类器，而是用大规模图文对比学习把图片和文本放进同一个语义空间，使“用文本找图片、用图片找文本、用自然语言定义临时类别”成为可规模化能力。它把视觉识别从固定标签分类扩展为跨模态相似度匹配。

Diffusion 的核心价值不是“模型会画图”，而是把视觉生成拆成可控制、可采样、可评测的逐步去噪过程。Latent Diffusion 进一步把昂贵的像素空间生成搬到压缩 latent space，使高分辨率生成进入可产品化成本区间。

GNN 的核心价值不是把普通表格模型换成更复杂的神经网络，而是让系统直接学习“关系如何影响风险”。欺诈、AML、账户滥用、商户风险、退货异常和推荐滥用往往不是单个客户或单笔交易的属性问题，而是客户、账户、设备、地址、商户、交易、受益人和公司之间的网络模式问题。

推荐系统不是“猜你喜欢”的展示模块，而是企业 AI decisioning layer 的一种形态。它把用户、上下文、候选库存、目标函数、策略约束和反馈闭环组合在一起，决定下一步应该展示、建议、触达、升级或拦截什么。

Learning to Rank 训练的不是“某个 item 是否相关”，而是在给定 query、用户、任务和候选集合下，哪些候选应该排在前面。它处理的是注意力、操作顺序和稀缺人工容量的分配问题。

Feature Store 的本质不是“给模型读取特征的缓存”，而是把模型需要的业务事实做成可定义、可版本化、可回放、可服务、可监控、可审计的数据产品。

AI runtime 的权限边界不能由 prompt 承担。Prompt 可以引导模型行为，但不能作为安全边界、审计证据或访问控制机制。

Federated Learning 解决的是“数据不能或不应集中，但多个数据持有方仍需要协作建模”的问题。FedAvg 的核心是把模型发送到本地训练，再聚合本地更新，而不是把原始数据搬到同一个训练环境。

Differential Privacy 不是匿名化、脱敏或 hash ID。它提供的是可量化保证: 限制单个个体是否出现在数据集中对发布结果或模型参数的影响。

小模型策略不是“降级版 AI”，而是把任务复杂度、风险等级、延迟、成本、隐私边界和运行环境映射到合适模型的系统能力。最大模型适合复杂、低频、高价值和不确定任务，但不应默认承担所有生产流量。

企业 Agent 不是一次模型调用，而是带状态、工具、副作用、人工审批、失败恢复和审计证据的长运行工作流。只要 Agent 会跨系统行动，就必须把“模型建议”放进 durable workflow 和显式状态机中治理。

Digital Twin for AI Decisioning 是把真实业务系统中的实体、事件、状态、资源、策略和反馈机制抽象成一个可校准、可回放、可压力测试的决策实验环境。它不等同于 3D 可视化，也不等同于预测模型；它关注的是“如果策略、模型或流程发生变化，系统会如何连锁反应”。

AI Release Science 是把模型、prompt、RAG、agent、tool policy 和推荐排序等变更，从“感觉更好”推进到“在真实流量中有统计证据，并且没有越过风险护栏”。它不是增长实验的同义词，而是生产变更治理系统。

AI 数据平台的核心不是“把数据集中到湖仓”，而是证明每个模型、eval、RAG 答案、特征和业务决策使用的数据是什么、从哪里来、谁负责、质量如何、何时变更、被允许用于什么目的。

AI SecOps 是把 AI 系统中的 prompt、retrieval、tool call、model call、policy decision、data access、output 和 human override 变成可监控、可检测、可响应的安全运营面。它补足传统 SOC 对 AI 行为链路的盲区。

Forecasting 是把历史事件、未来已知因素、业务假设和不确定性转成决策输入。高阶能力不在笼统宣称“预测得准”，而在能说明预测在什么 horizon、什么粒度、什么分位数、什么数据可用性边界下可信，并如何驱动库存、排班、资金、额度和风险运营。

Anomaly detection 的产品价值不在模型打分，而在把异常信号变成 risk monitoring system: 明确实体、窗口、异常类型、阈值、运营容量、分流策略、反馈标签和 incident 升级路径。

Causal AI 的价值不是让模型“更智能”，而是把产品、运营和风险决策从相关性 dashboard 升级到可审查的 intervention evidence。它要求显式定义 treatment、outcome、population、horizon、DAG、识别假设、估计方法和敏感性检查。

Optimization 是 AI 决策系统从“预测和建议”走向“可执行运营方案”的关键层。预测告诉系统可能发生什么，优化回答在资源、规则、成本、风险和服务承诺约束下应该怎么做。

Contextual bandit 是“带上下文的自适应决策实验”: 系统根据用户、场景和业务状态选择动作，只观察被选择动作的反馈，并在探索新动作与利用当前最佳动作之间持续权衡。

强化学习不是“让模型自己试错”的产品话术，而是一套描述连续决策的系统语言：在某个业务状态下，系统可以采取哪些动作，动作带来什么即时反馈，又如何改变未来状态、成本、风险和客户关系。金融零售和企业 AI 的关键难点通常不在算法名，而在历史轨迹是否完整、奖励是否代表真实目标、离线策略能否被可靠评估、线上探索是否会伤害客户，以及高风险动作是否被合规、风控和人工门禁约束。

Bayesian Optimization 处理的是昂贵实验下的序贯决策：用已有 trial 建立 surrogate model，估计候选配置的期望表现和不确定性，再用 acquisition function 选择下一次最有信息价值或业务价值的实验点。它不是 grid search 的加速版本，而是把“试哪个配置”建模为探索、利用和约束之间的动态权衡。

不确定性治理的核心不是给界面加一个“信心分”，而是把模型分数、置信度、预测集合、覆盖率和分布外信号转化为可执行的系统动作。校准回答“模型给出 80% 时，长期正确率是否接近 80%”；conformal prediction 回答“在合理假设下，预测集合或区间能否达到目标覆盖率”。

Data-Centric AI 关注的不是单纯增加标注量，而是把标签定义、专家规则、弱监督信号、冲突处理、数据版本、质量指标和治理证据做成可迭代的系统能力。Snorkel / programmatic labeling 的关键机制，是把专家知识、业务规则、字典、远程监督、模型信号和 LLM 辅助判断写成可版本化的 labeling functions，再通过 label model 处理覆盖、冲突

Active Learning 的核心不是“让人帮模型补标签”，而是用明确的采样策略，把有限专家时间投向最能降低模型风险、暴露盲区、提升覆盖和修正标签口径的样本。模型不确定、模型之间分歧、样本具有代表性、业务风险高、关键 segment 覆盖不足，都可以成为请求人工标签的理由。

Dataset shift monitoring 的价值不是画几张输入分布图，而是持续验证“生产现实是否仍然匹配模型上线时的假设”。模型上线后，客户结构、渠道、攻击模式、政策、人工口径、数据管道、知识库和系统负载都会变化；离线 AUC 再高，也不能保证未来仍可靠。

AI Management System 的核心不是多建一个审批委员会，而是把 AI 从零散试点变成可持续运行的组织能力。ISO/IEC 42001 提供管理体系语言：范围、政策、目标、角色、风险、控制、运行、绩效评价和持续改进；NIST AI RMF 提供风险活动语言：Govern、Map、Measure、Manage。

AI 技术债的危险不在于模型代码有多乱，而在于模型、数据、特征、配置、标签、业务流程、用户行为、下游消费者和治理证据被悄悄缠在一起。Sculley 等人的经典论文提醒我们，ML 系统中最贵的部分往往不是模型，而是模型周围的系统复杂性。

CD4ML 的核心不是把模型训练自动化，而是让 AI 系统在 code、data、model、prompt、knowledge、policy、threshold 和 evaluator 都会变化的情况下，仍然可复现、可验证、可审计、可回滚地发布。AI 发布的难点在于多 artifact 共同决定系统行为。

Human-AI Interaction 的核心不是让界面看起来更像人，而是让人能够正确理解、校准信任、控制、纠错、拒绝、升级和追责。Amershi 等人的 HAI Guidelines 和 Google PAIR 的设计方法共同说明：AI 失败常常不是模型完全无能，而是系统没有说明它能做什么、证据在哪里、什么时候不确定、错误如何恢复、人工何时接管。

AI ADR 的核心不是多写一份架构文档，而是把关键 AI 决策的背景、取舍、证据、风险、后果和反转条件保存为组织记忆。AI 系统中很多选择会长期影响成本、风险、客户体验和可演进性：RAG 还是 fine-tune，是否保存 memory，Agent 能否执行动作，LLM judge 能否作为门禁，vendor model 如何退出，哪些数据能进入 prompt。

AI 需求工程的难点不是把用户故事写得更细，而是把模糊业务愿望转成可验证的 AI 行为、风险边界和上线证据。GQM 的价值在于把 Goal 拆成必须回答的 Question，再把 Question 绑定到可收集的 Metric；用于 AI 时，这条链还必须延伸到 eval dataset、acceptance threshold、release gate、monitoring signal、own

AI 架构评审不能停在“RAG 还是 fine-tune”“用哪个模型”“要不要 agent”。这些都是方案层问题。真正决定系统能否上线和长期运营的, 是质量属性在具体业务场景中的可接受边界: 准确性、groundedness、延迟、成本、隐私、安全、审计、可变更性、韧性和人工控制如何同时成立, 又在哪些地方必须取舍。

STPA 用于 AI 安全时, 关注点不是“模型是否足够准”, 而是整个业务控制结构是否会在目标、权限、反馈、时序和人机分工失配时产生不可接受损失。对 agentic AI 来说, 真正危险的不是一次回答错误, 而是错误回答被放进工作流后触发工具调用、客户状态变更、人工误信、审计缺口和事故延迟发现。

Sociotechnical AI 把 AI 看成一个由人、模型、数据、流程、工具、政策、组织责任和反馈循环共同构成的工作系统。模型能力只是其中一个部件。AI 上线后, 工作会被重新分配, 信任会被重新校准, 例外会被放大或隐藏, 责任边界会被重新解释。真正的产品失败经常不是模型不会生成, 而是系统没有理解 work-as-done。

AI Capability-Based Planning 的核心, 是把 AI 投资从“用例清单”提升为“企业能力组合”。客服助手、知识库问答、代码助手、风控模型、销售助手这些名称都只是项目形态。更重要的问题是: 哪些能力是企业长期竞争力, 哪些能力应该平台化, 哪些只是局部自动化, 哪些必须先补数据、流程、风险和组织能力。

Wardley Mapping 用在企业 AI 中, 不是为了画一张战略海报, 而是为了让“自研、采购、平台化、合作、退出”这些决策有地形依据。AI 价值链中的组件成熟度差异极大: 基础模型 API 可能已经接近 utility, 但领域知识、eval set、人工复核流程、风险证据和客户信任机制仍高度定制。

Conway's Law 在企业 AI 中不是一句组织学警句, 而是架构诊断工具。AI 系统的接口、反馈、责任和控制路径会反映团队沟通结构: 如果数据、平台、业务、风险、安全和运营按职能墙协作, 最终 AI 系统也会形成脆弱的跨职能拼接。

AI-assisted SDLC 的生产力不能用代码行数、提交数或 agent 使用次数衡量。AI 会同时放大有效交付和无效产出: 它能缩短实现时间, 也能更快制造低质量测试、安全缺陷、架构漂移和评审负载。

AI Continuous Discovery 的重点不是收集“谁想要一个助手”, 而是持续发现哪个业务结果值得改善、哪个工作机会真实存在、哪个 AI 自动化边界可接受、哪些假设风险最高、用什么证据决定继续、调整、停止或规模化。

JTBD/ODI 用于 AI use case 选择, 不是为了把用户故事写得更漂亮, 而是为了避免“有 AI 能力, 所以找个地方塞进去”。AI 是否值得介入, 要看用户要完成的 job、当前 outcome 是否 underserved、AI 是否能改善该 outcome, 以及自动化边界是否在风险可承受范围内。

AI 产品价值不能用调用量、聊天次数、生成字数、采纳率或主观节省工时来证明。AI North Star 必须表达风险可接受、可归因、可扩展的客户和业务价值, 并与输入指标、质量评测、风险护栏、运营负载、成本和因果证据连接。

AI Product Operating Model 的核心不是建立更多流程, 而是让团队对业务结果负责, 同时在明确的风险、数据、模型、平台和运行边界内自主决策。AI 产品不能按传统需求工厂运行, 因为它的能力边界、质量、风险、知识源和用户行为都会持续变化。

AI Portfolio Management 的核心不是给 use case 排优先级, 而是把 AI 机会管理成有资金纪律、风险边界、平台复用和收益兑现机制的投资组合。AI 的不确定性高、证据周期短但扩展风险大, 因此不能按传统年度项目预算一次性承诺全部资金。

AI Service Blueprint 把 AI 体验从“一个对话框”扩展成完整服务系统: 客户动作、前台 AI、前台人工、后台流程、数据/知识/模型、控制证据和运行指标共同决定信任。金融零售场景中, 客户是否信任 AI, 取决于系统是否能在正确时刻解释能力边界、展示依据、承认不确定、交接人工、纠正错误并留下证据。

AI BPR 不是在旧流程上加一个 copilot, 而是重新设计价值流、流程、决策、判断边界、控制点和证据链。BPMN 表达工作如何流动, DMN 表达决策如何形成, AI eval/control 表达不确定性如何被验证和治理。

AI risk appetite 如果停留在董事会或政策文件里, 产品团队仍然不知道哪些能力能做、做到什么程度、需要什么证据才能上线。成熟做法是把风险偏好产品化: 转成 risk tier、product guardrails、runtime controls、breach thresholds、exception process 和 stop rules。

Enterprise AI Reference Architecture 是企业 AI 系统的 shared mental model。它把体验、编排、模型、数据/知识、工具、策略控制、评估、可观测性和治理证据拆成可复用、可控制、可演进的架构平面。

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

AI 成熟度不是“上线了多少模型”或“有多少个实验项目”，而是组织能否稳定地把 AI 假设转化为可控业务结果。成熟度模型的价值在于把能力、证据、风险、投资节奏和组织行为放进同一个评估系统：哪些能力已经可复用，哪些能力仍依赖个人英雄主义，哪些能力一旦扩大规模就会引入不可接受的合规、运营或声誉风险。

AI Control Library 是把风险要求翻译成稳定、可复用、可测试的控制语言；Assurance Evidence Graph 是把这些控制和具体产品、数据、模型、流程、测试、日志、例外和审批连接起来。前者解决“应该控制什么”，后者解决“如何证明控制真实运行”。

AI Domain-Driven Design 的核心不是把 DDD 名词套到 AI 项目上，而是用 bounded context、ubiquitous language、domain event 和 context map 约束 AI 的理解、检索、推理和行动边界。大模型最容易制造的系统性风险之一，就是把相似词当作同义词，把局部上下文当作全局规则，把建议型任务误解成决策型任务。

AI EventStorming 是用业务事件链发现 AI 应该介入哪里、承担什么任务、调用什么工具、何时交给人、失败后如何补偿。它的价值不是把流程画得更漂亮，而是把 agent 工作流中的状态变化、决策点、外部系统、副作用、异常和证据显性化。

AI Knowledge Work Redesign 不是给每个员工发一个 copilot，而是重新设计任务、责任、决策权、证据流和绩效系统。Role-Task Architecture 的核心问题是：哪些任务应被自动化，哪些应被增强，哪些必须保留人工判断，哪些应该被拆分、合并或消除。

AI Platform Service Catalog 是把模型访问、RAG、工具调用、评测、观测、控制、证据和成本能力产品化；Golden Paths 是把这些能力组合成可复用的交付路径，让业务团队在不绕过治理的情况下更快上线。

AI Architecture Views 的重点不是“多画几张图”, 而是建立一个架构表达系统: 每张 view 都服务一个明确 concern, 每个 concern 都能连接到业务价值、架构决策、运行机制、风险控制和证据来源。

AI Architecture Fitness Function 是一条可执行的架构约束: 它把“系统应该持续满足的质量、风险、成本或治理要求”转成测试、门禁、监控、阈值、证据查询和复核节奏。

Contract-first AI integration 的核心是: 先定义 tool/API/event 的结构、权限、副作用、错误、版本和证据要求, 再让模型或 agent 在这些受控契约内行动。

AI Traceability Graph 是把“为什么做、要满足什么、如何评测、如何控制、如何实现、线上发生了什么、证据在哪里”连接成一张可查询的关系图。

AI Enterprise Architecture 的任务是把 AI 从点状 use case 拉回企业能力、价值流、信息资产、平台服务、控制体系和迁移路线图中管理。TOGAF ADM 提供架构开发和治理节奏，ArchiMate 提供跨业务、应用、技术和动机层的建模语言，AI 风险框架和管理体系则让架构决策具备可审计的风险依据。

银行 AI 不能只学习某个系统的表结构和文档片段，它需要对齐行业级业务能力、金融概念和消息语义。BIAN 帮助定义银行能力和服务边界，FIBO 帮助统一金融概念，ISO 20022 帮助约束支付和金融消息含义。三者结合，可以让 AI 的知识边界、工具契约、语义层和审计证据更稳定。

Semantic interoperability 是让 AI 在跨文档、跨数据、跨系统、跨团队时仍能保持概念一致。RDF 适合表达事实和关系，OWL 适合表达本体和可推理语义，SHACL 适合验证图数据是否符合约束，JSON Schema 适合约束 API payload 和模型结构化输出。它们的价值不是“更学术”，而是把自然语言的不稳定性转成可验证的语义契约。

AI Value Stream Management 管理的是 AI 从机会发现、假设验证、数据准备、评测、发布、采用到业务结果的端到端流动。它不把模型调用量、功能上线数或 demo 数当作成功，而是追踪价值、风险、质量、成本和组织学习如何在系统中流动。

AI Regulatory Architecture 是把法规义务、风险框架和管理体系翻译成 inventory、risk tier、controls、release gates、runtime monitoring 和 evidence graph。EU AI Act、NIST AI RMF 和 ISO/IEC 42001 的共同价值，不是让企业多写合规文档，而是让 AI 产品从设计开始就具备分

AI validation 是对模型、数据、上下文、工具、流程、控制和业务结果的独立挑战，不是只看 benchmark 分数。传统模型风险管理强调 conceptual soundness、process verification 和 outcome analysis；生成式 AI 和 agent 系统要求把这些验证扩展到 prompt、RAG、工具调用、人机协作、供应商和运行漂移。

AI vendor architecture 是用合同、接口、控制、遥测、证据和退出方案管理供应商能力，而不是把模型或 SaaS 当成黑盒。供应商风险不是采购后才出现，它会进入数据治理、模型行为、服务连续性、成本、监管证据、客户体验和企业架构可替换性。

AI data lifecycle governance 是知道每个 AI 数据对象从哪里来、为什么用、被谁处理、进入了哪个 prompt 或工具、产生了什么输出、保留多久、何时删除、如何证明。AI 数据不只是训练数据，还包括知识库、检索片段、prompt、用户输入、工具结果、模型输出、反馈、日志、eval dataset 和治理证据。

Agent autonomy 不是模型智能程度的刻度，而是组织把行动权委派给 AI 系统的方式。真正需要设计的不是“让 Agent 更自动”，而是回答：什么任务可以被委派、谁授权、能访问哪些数据、能调用哪些工具、能写入哪些状态、什么时候必须升级给人、如何撤销、如何证明它按边界行动。

Agent 不能靠共享 admin key 在企业系统里行动。生产级 Agent 必须有自己的身份、任务级授权、可撤销 session、purpose-bound scope，以及能贯穿下游系统的 actor chain evidence。

AI observability 不等于把聊天记录和错误日志存起来。生产级 AI 需要 runtime evidence architecture：既要看见一次 AI run 的技术执行链，也要证明它使用了哪些来源、遵循了哪些策略、谁批准了哪些动作、输出是否被采纳、是否产生后续风险信号。

单个 AI use case 的风险可接受，不代表整个 AI portfolio 的风险可接受。当多个产品共用同一个模型、供应商、RAG 知识源、embedding、工具网关、身份服务、human review queue 或 evidence stack 时，原本独立的失败会变成相关失败。

AI customer harm 不是“模型答错”这一件事，而是 AI 失败、客户影响、发现能力和恢复路径共同形成的产品与治理问题。金融零售 AI 一旦进入支付争议、信贷解释、费用说明、欺诈冻结、催收、投诉分流或客服 RAG，就会影响客户权益、时间成本、资金可得性、申诉机会和监管投诉概率。

AI fairness 不是一个上线前指标，也不是把 protected class 从特征表里删掉就完成。金融服务里的 fairness 是产品边界、数据来源、代理变量、模型行为、人工复核、解释、客户救济、监控和证据共同构成的控制系统。

Explainability 不是把模型内部推理展示给客户，也不是给每个 AI 输出附上一段“解释文字”。在金融零售场景里，解释是一种受治理的产品界面：它必须绑定正式决策、事实证据、政策版本、reason code、客户下一步、可争辩路径和审计证据。

AI release governance 不能只围绕“模型版本”设计。上线后的 AI 系统会因为 prompt、RAG 语料、index、embedding、reranker、tool contract、policy rule、eval set、vendor、UI、人工流程、监控阈值和数据留存变化而改变行为。很多客户风险不是来自一次大版本发布，而是来自看似局部的配置、知识源或流程变更。

AI continuous control monitoring 的核心不是“多做一个 dashboard”，而是把 AI 系统的风险控制从发布前评审改造成持续运行的 assurance loop。金融零售里的 AI workflow 会因为模型版本、prompt、RAG 语料、工具权限、客户群体、政策文本和人工复核容量变化而改变行为；只靠一次性验证无法证明控制在生产中仍然有效。

AI resilience is proven in degraded mode, not in the happy path.

AI Management Information / Board Reporting Architecture 不是把 AI 项目周报换成董事会格式，也不是堆更多图表。它要把 AI portfolio 的事实、价值、风险、控制有效性、客户伤害、事件、供应商集中度、采用质量和整改动作做成可追溯的信息产品，让管理层、董事会和审计委员会能监督、挑战、投资、暂停、扩张或要求整改。

Closed-loop learning 不是“把用户反馈喂回模型”。在金融零售 AI 中，闭环学习应被设计成 corrective action architecture：识别问题、界定影响、找到根因、关联变更、验证修复、监控复发，并保留完整证据。反馈本身只是信号，不是事实；模型更新只是可能的修复动作之一，不等于问题关闭。

AI regulatory horizon 不应停留在法规新闻转发、法律备忘录归档或季度培训。金融零售 AI 的外部约束会持续来自 laws、guidance、regulatory speeches、supervisory priorities、standards、vendor notices 和 peer incidents。真正有价值的是把外部信号转成内部可查询、可分派、可测试、可上线门禁、可

AI Exception Architecture 是把“暂时不能满足标准控制”转成有边界、有补偿、有到期、有证据、有升级、有硬停止条件的风险接受系统。

AI BOM is the component-level traceability layer for AI systems: model, data, prompt, tool, eval, human operation, telemetry and vendor components must be versioned, provenanced, signed, monitored and

Human review 不是页面上多一个“人工确认”按钮，而是一套生产运营能力。它需要定义 review unit、队列、技能、SLA/OLA、容量、校准、质量抽样、升级、疲劳控制、override governance 和证据。没有这些能力，human-in-the-loop 会变成控制剧场：形式上有人，实际上无法发现、理解或阻断风险。

Segregation of duties prevents efficient automation from becoming concentrated, unchallenged authority.

在 AI 架构中，consent 和 preference 不是前端勾选框，而是运行时数据边界。金融零售 AI 会在 prompt、RAG、工具调用、memory、personalization、training/eval、日志和人工复核中反复使用客户数据；如果 purpose 没有被系统执行，所谓授权会变成一次性同意被无限复用。

Shadow AI governance architecture 是把“员工绕开正式路径使用 AI”转成可发现、可分级、可引导、可治理、可迁移和可审计的 enterprise control system。

AI conduct risk 不是普通 hallucination 风险。它关注 AI 如何影响客户选择、产品推荐、销售话术、费用解释、投诉处理、困难客户对待和员工激励。当 AI 参与排序、推荐、next best action、销售草稿或客户承诺时，系统必须控制的不只是事实准确性，还包括适当性、利益冲突、披露、脆弱客户保护、禁止性 claim、升级和补救。

AI records architecture 解决的是：哪些 AI 事件构成业务记录、监管记录、客户沟通记录、模型治理证据或潜在诉讼证据；这些记录应保留多久、如何保全、如何检索、如何出示、何时删除，以及 legal hold 与隐私删除请求冲突时如何处理。AI 系统如果只把 prompt 和 response 当 debug log，就会在客户投诉、监管检查、法律保全和 eDiscovery 中

AI data residency 不是数据库部署区域选择，而是端到端数据路径控制。一次 AI 请求可能经过客户源数据、RAG 检索、prompt assembly、模型 endpoint、工具 payload、日志、trace、eval sample、人工复核队列、供应商 telemetry、备份和密钥服务。任何一个环节跨境，都可能改变 privacy、bank secrecy、outsourc

AI 客户沟通的核心风险不是“模型会不会写错几句话”，而是机构是否还能证明每一段客户可见内容在生成、审核、发布、归档、监控和补救时都处于受控生命周期内。金融零售里的沟通材料往往同时承载营销、产品解释、适当性边界、费用披露、服务承诺和投诉处理，一旦 AI 把静态文案变成动态交互，传统的物料审批机制会被击穿。

AI financial crime architecture 的成熟度不取决于“模型找出更多 alerts”或“SAR narrative 写得更快”，而取决于机构能否证明 typology、scenario、red flag、data signal、alert、case evidence、human decision 和 SAR narrative 之间存在可追溯控制链。

AI content rights architecture 的目标不是在生成内容末尾加免责声明，而是把输入、语料、检索、生成、人工贡献、发布、再利用、来源证明和下架补救做成可运行的权利控制系统。金融零售机构的内容不仅是营销资产，也是客户教育、顾问沟通、客服脚本、产品披露、培训材料和记录证据，权利问题会同时触发 IP、合同、隐私、广告合规、records 和供应商风险。

Deepfake 和 synthetic identity 风险不是一个“更强 liveness 检测”可以解决的问题。金融零售身份架构要证明从 identity proofing、enrollment、authenticator binding、session authentication、transaction intent、step-up、human review 到 fraud ops e

Workforce AI 的治理重点不是“HR 或运营团队用了多少 AI 工具”，而是任何影响候选人、员工、排班、绩效、培训、晋升、薪酬、纪律、离职、监控或工作体验的 AI，都必须有清晰的决策边界、数据最小化、人工责任、公平性评测、告知解释、申诉路径和持续监控。

AI incident response 不是把普通 IT incident 加一个 model id。金融零售 AI 可能造成误导性客户沟通、错误建议、差别影响、隐私泄露、模型失控、供应商故障、自动化操作越权、证据缺口和客户补救失败。真正的架构目标是把事实确认、客户影响、披露支持、责任边界、保险通知、供应商追责、沟通审批和证据保全接成一个可运行机制。

Post-quantum AI architecture 的核心不是预测量子计算何时可用，而是让 AI 系统中的加密依赖、长期证据、签名、密钥、证书、供应商、协议和归档对象可以被发现、分级、替换、验证和审计。金融零售 AI 的证据和客户数据往往需要多年保密和可验证，PQC 准备不足会同时影响 confidentiality、integrity、non-repudiation、records 和监管

APP scam intervention 不是一个更激进的 fraud stop button。它是一套实时支付决策架构：在客户本人已认证、正在授权 push payment 的情况下，识别其意图是否被 deception、coercion、impersonation、romance/investment grooming、remote-access coaching 或 mule networ

AI agent marketplace 不是服务目录，也不是把 internal tools 放进一个漂亮页面。它是一套 permissioned capability platform：把 agent、tool、prompt、MCP server、API、RAG corpus、workflow 和 eval pack 都当作可治理的业务能力，要求它们在被发现之前先被描述，在被复用之前先被认证，

Inclusive AI 不是“更有同理心的 chatbot”。在金融零售里，它是一套 customer-outcome control system：把客户在某段旅程中的支持需求、可访问性需求和高伤害风险识别出来，用最小侵入的方式提供帮助，并证明客户没有因为处境困难、沟通障碍或数字无障碍需求而受到更差服务。

AI dispute architecture 不是自动拒付、自动退款或自动解释法规的引擎。它是一套 evidence-governed operating system：先把 payment event、customer assertion、rail/product context、rule catalog、deadline、evidence 和 communication 放在同一个可重放模型

AI collections architecture 不是让系统“更会催”。它是一套 customer-treatment control system：在管理信用损失、现金流和运营容量的同时，证明客户被相称联系、获得可负担和可访问的方案、没有被高压或误导，困难情境没有被当成收入提取机会。

Contact-center AI 不是单纯的效率层。它是客户沟通控制平面：治理一通电话或聊天中什么被听见、转写、推断、建议、说出、记录、披露、升级、质检、投诉、补救和改进，并防止 AI inference 被误当成客户事实或机构承诺。

AI identity wallet architecture 不是“让模型要身份证”。它是一套 trust decision system：把 issuer-attested claims、holder-mediated disclosure、authentication signals、relying-party policy、fraud context、AI inference、custom

Consented financial data sharing 不是“AI 可以读取银行数据”。它是一套 purpose-bound、revocable、API-mediated trust architecture：把客户授权、第三方角色、API scope、数据质量、AI 允许用途、撤销传播和行动授权统一成运行时可执行的边界。

AI personalized pricing 不是更聪明的 campaign engine。它是一套 governed economic decisioning system：决定客户看到的 rate、fee、limit、promotion、retention offer、loyalty incentive 或 servicing term，也决定机构如何解释、复核、补救和证明这些差异化待遇。

Document intelligence 不是 “OCR + LLM summary”。在金融运营里，它是一套 evidence system：把非结构化文档转换成有 provenance、source coordinate、confidence calibration、validation、human review、records/hold metadata、workflow policy 和

Privacy clean room architecture 不是“把两个客户表上传后匹配”。它是一套 governed collaboration system：在任何 insight 被信任、导出或进入 AI pipeline 前，先约束 purpose、data minimization、identifier handling、query surface、output disclosure

信贷 AI 不是一个审批分数模型，而是一套会改变客户准入、客户成本、信用敞口、机构损失、投诉风险和证据责任的生命周期决策系统。成熟架构要把预筛、审批、定价交接、额度管理、原因码、公平借贷、人工覆盖、champion/challenger、组合监控和客户救济连成可治理的信用决策工厂。

财富建议类 AI 的核心不是“会不会解释投资概念”, 而是能否把教育、个性化建议、组合构建、交易执行、人工交接、利益冲突、披露、监督和证据做成同一个可控系统。语言模型如果直接面向客户生成建议, 它就不再只是内容体验问题, 而是进入 conduct risk、模型风险、销售合规、客户伤害和可追责边界的交叉区。

Treasury AI 不是“预测明天余额”的模型问题，而是把流动性生存、ALM 决策、FTP 激励、压力情景、应急资金和董事会挑战连接起来的 forecast-to-action 系统。真正的架构重点，是让每个预测、假设、人工覆盖、资金动作和压力证据都能被解释、追溯、挑战和审计。

投诉智能不是给工单打标签，而是把客户原话转成客户伤害信号、AI 贡献分析、根因、产品或控制修复、监管证据和管理层行动的治理闭环。金融零售 AI 投诉架构的价值，不是更快写回复，而是让 complaint-to-control loop 可追溯、可复盘、可整改。

开户 AI 不是选择一个 IDV 组件，而是一套受监管的决策与证据架构。难点在于把准入资格、身份可信度、CIP/KYC/CDD、欺诈、AML 交接、账户激活、客户沟通和审计证据分清楚，避免所有失败都被压成一句含混的“KYC 未通过”。

AML Alert Triage / Investigation Workbench 不是“给告警队列加一个聊天框”，也不是自动决定是否提交 SAR 的系统。它的本质是一个 evidence operating system：把告警、客户风险画像、交易时间线、实体网络、规则/模型信号、调查证据、人工判断、质量复核、调参反馈和审计轨迹组织成可追溯、可复核、可持续改进的生产控制体系。

Payment operations AI 的价值不是判断客户争议谁对谁错，也不是识别诈骗话术，而是把支付事件、文件、清算、结算、核心账务、总账、现金和操作证据连成可解释、可修复、可审计的 production control system。它要解决的是 payment processing 和 reconciliation 的时间、金额、状态、规则、账务和责任不一致。

金融机构的监管报送不是报表生产线，而是把监管义务、业务事实、风险数据、转换规则、对账控制、签署责任、提交证据和更正闭环组合成一套可证明的事实系统。AI 可以提升说明书解析、异常聚类、证据检索和叙事起草效率，但不能替代口径定义、例外处置、签署、提交和更正判断。

核心银行现代化不是把旧主机替换成新核心包，而是把账户、余额、利息、费用、额度、交易、总账、运营流程、客户影响和审计证据从旧环境逐步迁移到可治理的目标能力。AI 可以帮助理解遗留规则、生成测试、聚类差异和分析 cutover 演练，但不能拥有核心写入、事实源切换、客户影响 cutover 或迁移风险接受。

AI Requirements Mining 不是把 PRD、SOP、工单和会议纪要丢给大模型生成 user stories。高成熟做法是把它设计成 requirements and process intelligence control plane：在权限、来源权威、证据引用、领域词表、流程变体、冲突检测、质量评分、traceability graph、验收/eval contract 和人工

AI 系统的 UAT 不是上线前让业务用户点几遍页面并签字，而是证明某个业务能力在特定模型、prompt、RAG、工具、数据、workflow、policy 和控制版本下可接受、可运营、可回滚、可监控。验收产物应是一套可查询的 acceptance evidence architecture，而不是一封 sign-off 邮件。

AI 让企业更容易新增 copilot、RAG、agent、workflow automation，也更容易堆积重复能力、模型成本、供应商依赖、隐性运营负担和架构债。成熟的产品组合治理不是继续加功能，而是把产品、能力、应用、API、模型、prompt、RAG、工具和供应商依赖放到同一张证据图上，用客户价值、经济性、风险、约束和迁移可行性决定保留、合并、迁移、冻结或下线。

AI adoption 不是登录次数、席位激活、prompt 数量或培训完成率, 而是目标人群在真实工作流中持续改变行为, 并且这种改变能带来可验证的流程结果、风险状态和经济价值。没有行为证据的 adoption dashboard 只能证明“有人碰过工具”, 不能证明 AI 改变了 work-as-done。

AI 高管投资叙事不是把模型能力包装成 ROI, 而是把不确定的 AI 机会转成可治理的管理选择权。成熟的 board decision package 要同时回答 outcome thesis、option architecture、causal value logic、cost-to-learn、risk appetite、architecture dependency、benefits re

AI stakeholder alignment 不是软性沟通, 而是交付架构的一部分。金融零售 AI 项目会同时触达客户权益、员工工作流、模型风险、信息安全、隐私、合规、内审、供应商、运营容量和品牌信任。成熟做法不是维护 stakeholder list, 而是把 authority、concern、incentive、harm、forum、requirement、control 和 evide

AI Workforce Capability Academy 的核心价值不在“教会大家使用 AI”，而在建立一套可验证的组织能力系统：谁可以负责 AI use case、谁可以签署 eval/release evidence、谁可以改动高风险流程、哪些岗位仍存在 skills debt、这些能力变化是否真的改善了 adoption、quality、risk 和 business outcome。

AI delivery assurance 是把不确定的 AI 工作转化为阶段性证据、决策信心、残余风险归属和上线后学习的运行纪律。它不是把项目管理再包装成更多审批, 而是回答一个更硬的问题:

AI Product Operations 是上线后的证据系统: 它把运行时行为、采用、结果、风险、成本、事故和变更发布转成可重复的产品与组合决策。

AI reference implementation 不是示例代码，也不是组件目录。它是一个经过治理、可运行、带证据的可复用模式实现：团队复用的不只是 prompt、RAG、tool gateway 或 UI skeleton，还要复用质量门禁、安全控制、eval baseline、observability、证据包、偏差处理、版本生命周期和适用边界。

AI 战略最容易失效的地方，不是少看了某个新模型或新框架，而是把未来当成趋势清单或固定路线图。金融零售机构面对的是一组同时变化的变量：模型能力、推理成本、供应商策略、开源成熟度、agentic workflow 安全、数字身份欺诈、监管预期、劳动力重构、客户信任与竞争对手动作。单点预测没有足够韧性，真正需要的是一套把不确定性转化为可治理决策的架构。

AI 产品责任不是把“人、模型、供应商、业务方”写进一张责任表就结束。真正的问题是: 产品对用户承诺了什么, 哪些判断会影响客户、员工或机构风险, 谁有权让 AI 进入这些判断, 出错后谁能解释、纠正、赔付、暂停和改进。

很多 AI 事故会被描述为“模型幻觉”或“RAG 召回错了”。在金融零售企业里，更深层的问题通常是 context supply chain failure：过期政策仍在向量索引里、用户上传文档夹带 indirect prompt injection、CRM 自由文本被当作权威事实、工具输出没有 freshness 和 schema 校验、一次性例外被写入长期 memory、低权威外部资料压过内部

Agentic process audit 不是给 AI agent 加一层普通日志, 而是把意图、计划、工具动作、策略决策、人工批准、例外处理、输出和学习信号组织成可审阅、可重放、可质询的 evidence architecture。它的核心问题不是“模型回答得好不好”, 而是“当 agent 成为流程参与者时, 组织能否证明关键行为受到边界、权限、证据和控制约束”。

组织记忆不是把文档放进向量库, 也不是让 AI 记住更多上下文。对金融零售 AI 来说, memory 是一个控制面: 决定哪些知识可以被记住、引用、复用、挑战、过期、删除和替换。AI 的回答质量、责任边界和治理能力, 很大程度取决于组织记忆是否被当作知识资产治理问题处理。

AI Eval Dataset Lifecycle Architecture 是把测试数据从一次性样本升级为可版本化、可治理、可度量、可审计、可退役的质量资产供应链。它不只回答“模型分数高不高”，而是回答：哪些业务风险被覆盖，哪些失败模式被阻断，哪些证据足以支撑上线，生产失败如何回流为 regression asset。

Synthetic user simulation 不是把传统 persona 换成 AI 头像, 也不是让 LLM 随机扮演客户。它是一套用于产品发现、架构验证和上线证据管理的行为测试架构:

AI 人因不是“界面更清楚一点”或“加一个人工复核按钮”。在金融零售运营里, 人是生产控制系统的一部分: 他们处理 AML、欺诈、授信、投诉、催收、客服和例外审批。AI 改变信息呈现、判断顺序、信任结构和队列压力, 也就改变了人的认知负荷和错误模式。

AI procurement intake 是企业 AI 架构的第一道控制点：它把业务 idea、vendor pitch 和本地试点转成可测量的 outcome、workflow、data boundary、risk tier、sandbox evidence 和 build-buy decision。成熟组织不会让供应商 demo 定义问题，而是先定义用例是否值得进入 AI option sp

Reasoning budget 是运行时策略：系统在面对不同业务价值、客户影响、证据缺口、监管风险和时延约束时，决定是快速回答、检索证据、深度拆解、调用工具、运行 verifier、拒答，还是升级人工。Test-time compute 不是“让模型多想一会儿”，而是成本、质量、权限、证据和治理之间的动态资源分配。

AI model portfolio governance 解决的不是“哪个模型最好”，而是对每个业务任务、风险等级、数据边界、延迟约束、成本约束、安全要求和审计要求，哪个模型家族在当前证据下被批准使用，什么时候需要 challenger，什么时候必须退役。它把模型选择从 vendor demo 和 leaderboard 偏好，升级为持续的组合治理。

AI uncertainty UX 不是 tooltip，也不是把 confidence_score 暴露给用户。它是一个运行时 decision-control architecture：系统在每一次交互中判断 AI 应该回答、限定回答、部分回答、追问、拒答、升级、阻断，还是只保留证据等待人工处理。

AI risk quantification 的价值不是把所有风险精确算成一个数字，而是把“AI 可能出错”翻译成可以比较、可以挑战、可以投资、可以复核的经济决策语言。

AI 系统的证据风险不只来自“模型答错”，还来自证据对象可被重写、提示和上下文不可重放、生成内容与人工判断混在一起、日志只能观测不能证明、审计导出缺乏完整性验证。Tamper-evident audit ledger 的目标不是把所有内容放到区块链，而是让关键证据在生成、引用、修改、审批、导出和保留过程中具备可验证的完整性、来源、时间、责任和派生关系。

Shadow mode 不是“悄悄上线看看效果”, 而是在真实业务上下文中运行 AI, 同时不让它影响客户、员工动作、系统状态或监管承诺。它的价值在于暴露离线测试看不到的问题: 输入分布、流程噪声、工具调用失败、结果延迟、人工行为、队列压力、边界越权和证据缺口。

合成数据不是“假数据所以安全”, 也不是把真实客户数据丢给生成器后自动得到可共享资产。对金融零售 AI 来说, synthetic data 是一种受治理的数据产品: 它有来源许可、生成方法、隐私攻击面、效用边界、保真度限制、适用场景、发布门禁和持续监控。

AI Three Lines Governance 是把 AI 产品、业务运营、风险合规、内部审计和架构治理连接成一套可决策、可挑战、可取证、可整改、可追踪的 operating model。它不是多开几个委员会，也不是让风险、合规或审计替第一线承担上线责任；核心是把“谁拥有业务决策和残余风险”“谁解释政策、挑战证据和提出条件”“谁独立验证治理与控制是否如声明运行”拆清楚。AI 系统里的 prom

把现有 AI 论文解读、playbook、case drill 和治理材料重新组织成一条系统学习路径。旧内容不删除；本文件负责告诉你先读什么、怎么读、哪些内容第一遍先跳过。

当前 AI 内容最大问题不是数量不足，也不是网站入口不够，而是正文阅读体验失焦。

本文件是 AI 2026+ 新扩展的资产入口, 负责把历史新增材料组织成可检索的学习地图。

这套 AI 扩展不是单纯学习 prompt，也不是堆工具清单。它训练的是企业 AI 时代更稀缺的一组复合能力：

面向 10 年金融零售、业务分析、产品决策和开发背景，把经验迁移到企业 AI 架构、治理和运营能力。

第一遍学习不要逐批追全量覆盖。先按能力模块读：

现有体系已经很强：

把 AI Agent 从 demo、聊天框、自动化脚本提升为企业级运营能力。

以下资料作为学习锚点与术语校准来源，不构成法律意见、合规结论或监管解释。

Data Contract Specification（datacontract.com）作主线 → 已并入 ODCS，只作历史对照

AI 转型最缺的不是概念，而是把模糊诉求变成可执行决策的肌肉。

2026+ 企业 AI 能力正在从单点 prompt / chatbot 能力, 转向跨职能的 AI operating capability.

这是新增学习资产, 不替代既有 Web3, 架构, ABPA 学习计划。

这些资料作为本 playbook 的方法基线。学习时不需要背标准, 但要能把图和标准的关注点对齐。

当前仓库已经不是单一学习计划, 而是一个多阶段能力资产库:

把已有 AI、金融零售、架构、EvalOps、治理和 Web3 学习资产整理成可复盘、可审查、可持续升级的复杂系统经验。

AI 采购和落地不是 "选一个模型".

AI 需求一旦进入生产环境，就不再只是“系统应该怎样响应”的描述，而是一个可执行的质量和风险契约。Requirements-to-Eval 的工作，是把业务需求、AI 行为、失败模式、测试数据、评分方法、阈值、owner、release gate、monitoring signal 和 incident loop 连成一条链。本文偏向金融零售场景，重点处理政策问答、调查辅助、信贷材料、支付异常、财

这些来源提供运行模型语言。正式项目仍需结合机构政策、司法辖区、业务域和技术架构确认。

AI 架构评审不能只看模型、API 和一张系统图。它要证明一个概率型能力可以被插入业务流程，并且在数据、知识、权限、工具、评估、人类控制、运维、成本和价值上保持可管理。本文把 AI 架构评审拆成从 intake 到季度复审的门禁体系，适合金融零售企业中的客服、信贷、支付、反欺诈、反洗钱、财富合规和内部知识工作场景。

这些来源作为学习锚点, 不构成法律、合规或采购建议。

阅读 AI 架构, RAG, Agent, EvalOps, Governance 资料只能建立概念框架。复杂项目和真实交付需要的是另一种能力:

企业 AI 沟通的核心不是展示模型知识, 而是帮助决策者回答:

AI 应用可以一个一个做，但企业真正规模化时，会遇到重复问题：

AI regulatory response 不是临时合规 memo, 而是把监管信号、业务流程、AI 系统边界、控制设计和证据链连接成可运行的治理能力。

AI data product 不是一个表、一个文档库或一个向量库, 而是一组有 owner、有 contract、有质量 SLO、有权限和治理边界、能被 AI 工作流稳定消费的数据能力。

board-level AI governance 的重点不是展示 AI 项目进展, 而是让董事会、审计委员会、风险委员会和 AI governance committee 能监督 material AI systems、portfolio risk、control effectiveness、residual risk、accountability、audit evidence、incident

每个能力维度 0-4 分：

不再把 RAG 当成“向量库 + 大模型问答”, 而是把企业知识系统做成可评估、可审计、可上线、可复盘的生产能力。

这些来源是本实验室的学习锚点, 用于建立术语、风险分类和治理语言。它们不构成法律、监管或审计意见。

本模拟包连接三份既有学习资产:

本 workbook 把金融零售 AI case drill 从单点方案推进到可评审的系统学习材料，重点训练复杂案例设计、架构取舍、上线治理、董事会沟通和证据化复盘。

生产级 AI memory 不是把聊天历史塞进 prompt，而是设计“AI 能保留什么、何时使用、谁能控制、如何删除、如何审计、如何评估”的系统能力。Context、memory、business state 和 audit 必须分开建模：context 是当前调用可见的信息包，memory 是被授权保留并可能在未来使用的信息，state 来自业务系统的权威状态，audit 用于追溯和问责而不是

这些来源是学习锚点，不构成法律、合规、审计意见。金融零售场景落地时，应由合规、法务、模型风险、安全和业务 owner 共同确认控制要求。

AI observability、cost management 和 risk-tiered SLO 共同构成 AI 系统的运营控制面。一个可上线的 AI service 不只要“能回答”，还要能解释每次回答经历了什么、花了多少钱、慢在哪里、质量是否稳定、风险是否被拦截、用户是否真的采用、业务结果是否改善。没有 trace、span、quality signal、cost ledger、SLO、i

企业 AI agent 的关键能力不只是生成文本，而是能在明确边界内连接外部工具、资源、提示、供应商服务和其他 agent。协议化的价值不是让模型自由调用更多能力，而是把外部能力变成可发现、可授权、可审计、可回滚、可治理的系统接口。

本文把 AI assurance / safety case 视为可信性论证系统, 目标是把“负责任地使用 AI”这类原则口号转换成可审查、可追溯、可挑战、可复核的 evidence structure。

本文把传统金融 Model Risk Management（MRM）的心智模型迁移到 LLM / RAG / Agent 系统；重点不是背诵 SR 11-7，而是理解 AI 系统如何成为可登记、可验证、可监控、可变更、可审计的风险对象。

Requirements-to-Eval 定义“测什么”, RAG Eval 定义“证据是否找对”, Data Product 定义“数据如何被治理”, Synthetic Eval Data 定义“测试样本如何系统化产生、审核、扩展、隔离和复用”。

企业 AI 转型的瓶颈通常不是缺少 use case，而是缺少把 use case 变成可投资、可治理、可停止、可规模化组合的运营机制。AI Value Office 的任务，是把分散试点、平台能力、风险证据、采用数据和收益兑现放进统一的 portfolio operating system。

Human oversight 不是在 AI 流程末端增加审批按钮, 而是把人类判断、授权、证据、升级、覆盖、撤销、停机和复盘设计成一套可运行的控制系统。

金融零售 AI 安全不能只靠 prompt。LLM / RAG / Agent 的风险来自身份、数据边界、检索权限、工具网关、策略引擎、记忆写入、MCP / A2A 连接、第三方模型、日志证据、红队评测和事故响应共同组成的系统链路。

版本：v1.0

AI adoption 不是“上线模型 + 发培训通知”，而是把目标行为、工作流、角色责任、AI literacy、支持模型、治理证据和收益兑现连接成可运行的组织系统。对金融零售企业来说，AI 采用失败往往不是模型单点失败，而是流程、责任、控制、激励和运营证据没有同步改变。

本文把金融零售 AI 系统的隐私、数据保护与 PII 治理放进完整生命周期, 从 use case 定义、数据最小化、目的限制、同意与告知, 一直延伸到 RAG 权限、工具调用、记忆、日志、评测、供应商、留存删除、DSAR 和持续监控。

AI 第三方风险管理的关键不是记住供应商清单，而是把 foundation model、cloud AI、RAG SaaS、agent platform、data vendor、eval vendor、系统集成商和外包团队放进同一个风险生命周期，分析它们如何改变数据流、模型行为、运营责任和机构可控性。

本文把 process mining、task mining、BPMN、流程指标和 ROI evidence 组织成金融零售 AI 自动化之前的系统学习框架。

客户可见受监管 AI 不是“更聪明的聊天机器人”，而是一套带披露、边界、人工升级、客户救济、持续监控和审计证据的服务系统。

金融零售 AI 的知识能力不是把文档上传到向量库, 而是把权威来源、业务语义、权限、版本、证据和运行责任组织成可治理的 knowledge product。

AI semantic layer is the governed contract between business meaning, data implementation, AI evaluation and executive decision-making.

当 AI 系统在生产中出现错误回答、错误检索、工具误用、PII 泄露、成本失控、延迟退化、模型漂移或 prompt injection 时，可靠性体系必须同时完成止血、影响界定、证据保全、复盘、纠正行动、防复发和治理升级。

AI Product Architecture 研究的是如何把分散的 AI use case、模型能力、数据资产、平台组件、治理要求和投资决策组织成一套可复用、可审计、可扩展的产品架构决策系统。

EvalOps 是企业 AI 的质量与风险控制面, 不是上线前跑一次测试表。它把 dataset、evaluator、experiment、release gate、production monitoring 和 evidence binder 连成持续发布系统。

AI ROI = observed outcome - credible counterfactual - risk / quality / adoption adjustments.

当企业 AI Agent 跨 CRM、支付、KYC、AML、工单、核心银行、通知和审批系统协作时, 重点不是“模型能否调用工具”, 而是每个动作是否有契约、权限、审批、幂等、补偿、事件证据、审计轨迹和恢复路径。

AI 信任体验不是免责声明、品牌语气或聊天界面, 而是把披露、证据、不确定性、控制权、升级、申诉和审计记录纳入同一套产品治理架构。

金融零售 AI 决策自动化的关键, 是把政策、权限、审批、解释和审计从 prompt 中外置出来, 形成可测试、可版本化、可审批、可回滚的控制架构。

金融零售个性化推荐不是“猜你喜欢”组件，而是受同意、资格、适当性、公平性、渠道能力和审计证据约束的决策基础设施。

实时 AI 决策不是“模型 API 加几个实时字段”。它是一套以 entity/time 语义、feature contract、低延迟 online serving、历史一致训练集、决策编排、监控回放和治理门禁为中心的平台能力。实时特征平台的架构价值在于把“当时可知的信息”严格绑定到“当时允许执行的决策”，从而让训练、推理、审计和复盘共享同一套时间语义。

版本：v1.0

PET 不是“隐私增强插件”, 而是一组围绕 purpose limitation、PII minimization、data-in-use protection、privacy budget、可证明控制和残余风险管理的架构选择。

以下 primary / official sources 作为术语和架构锚点。本文把它们转成 AI agent workflow、金融零售流程、平台治理和可审计证据语言。

AI 平台进入生产后，成本问题会从“模型 API 账单偏高”变成一组更难的产品和架构问题：

模型组合策略的重点不是选择“最大模型”或“最便宜模型”，而是把 frontier model、small / specialist model、distillation、compression、quantization、routing 和 governance 组织成可评估、可回滚、可审计的运营体系。

AI digital twin 的系统价值，是在真实流程、客户、员工、agent、风控策略和运营容量上做变更前，先用可校准、可验证、可治理的仿真系统回答“如果这样改，会发生什么”。它不是 3D 可视化、预测仪表盘或供应商演示概念，而是一组围绕实体、事件、状态、政策杠杆、约束、反馈回路和上线门禁组织起来的决策基础设施。

AI Experimentation Platform = assignment、exposure、metrics、eval、release gate、ramp、rollback、evidence 和 learning loop 的统一控制面。

AI 数据治理不是“数据清洗”和“字段说明”, 而是为 AI use case 提供可签约、可追溯、可测试、可变更、可问责、可复盘的数据控制面。

以下来源用于建立术语、控制映射和运营语言。正式项目应记录访问日期、版本、内部 policy mapping 和控制 owner。

以下资料用于校准术语、模型边界与治理框架。本文不是论文复述，而是面向金融零售、零售、电商、客服与容量规划的产品架构转译。

本文把 anomaly detection / risk monitoring 视为金融零售企业的实时风险控制面，而不是单一模型报警器；重点是如何把业务异常、模型漂移、安全事件、运营事故和成本波动统一到可解释、可处置、可审计的监控体系。

[DoWhy](https://www.pywhy.org/dowhy/)：用于把因果问题拆成建模、识别、估计、反驳检验的工程流程，适合把业务 DAG 转成可审计的因果估计管线。

这些来源作为术语、架构和治理锚点。本文把它们转成 AI 产品、金融零售运营和企业架构可执行的工作语言。

Contextual bandits 的系统价值不在于把传统实验包装得更自动，而在于把高频决策纳入一个可约束、可记录、可评估、可回退的在线学习闭环。每一次决策都必须同时记录 context、eligible action set、selected action、propensity、exposure、outcome 和 guardrail result，否则后续的 offline policy e

Reinforcement learning 在企业 AI 中的核心位置，不是“让模型自动找到最优解”，而是把连续决策、长期反馈、动作约束、人工审批和治理证据组织成可上线的 policy decision capability。当系统需要决定下一步做什么、由谁做、何时做、用什么工具做、在什么风险边界内做，监督学习的 score 或 recommendation 只解决了输入信号的一部分，真正的架构

在金融零售，最小化 regret 不只是更快找到高分配置，还要减少客户暴露、人工审核、云成本和合规风险上的学习成本。

以下来源是本文的技术和治理锚点。本文把它们转成产品、架构、评估、上线门禁和治理证据要求，不把任何论文或工具文档直接等同于监管合规结论。

programmatic labeling 不是批量规则脚本，而是把 weak supervision、Snorkel/data programming、SME review、label quality、dataset documentation 和 release gate 组合成可上线、可审计、可迭代的数据中心型 AI 生产体系。

以下来源是本文的技术和治理锚点。本文把它们转成产品架构、运营流程、评估门禁和模型风险证据要求，不把任何论文、框架或工具文档直接等同于监管合规结论。

以下来源是本文的技术和治理锚点。本文把它们转成产品、架构、监控、上线门禁和治理证据要求，不把任何论文或框架直接等同于监管合规结论。

以下来源是本文的管理体系、AI 风险治理和 GenAI 风险画像锚点。本文把它们转成产品、架构、治理论坛、证据包和上线门禁，不把任何标准、框架或公开资料直接等同于法律合规结论。

以下来源是本文的技术和治理锚点。本文把它们转成产品、架构、债务治理、上线门禁和审计证据要求，不把任何论文、课程或框架直接等同于监管合规结论。

当 AI 系统的 code、data、feature、model、prompt、RAG index、tool schema、policy 和 eval 同时变化时，持续交付的核心不再是“部署一个服务”，而是建立可复现、可审计、可回滚、可分级放量的 AI release system。

Human-AI Interaction 在受监管金融零售 AI 中不是界面润色，而是交互控制平面。它决定用户如何形成 mental model、如何看见证据和不确定性、如何保留控制权、如何恢复错误，以及组织如何证明信任被校准而不是被营销话术放大。

本手册把 AI ADR 视为组织级决策知识系统, 用来保存 AI 系统为何这样设计、证据如何支持、风险由谁接受、以及哪些条件会推翻原决策。

AI 需求工程的核心，不是把“做一个智能助手”写成若干用户故事，而是把一个概率型能力放入真实业务流程，并把它转化为可度量、可评估、可门禁、可监控、可审计、可持续改进的行为契约。对已有金融零售、流程治理、需求管理和架构经验的人来说，难点不在于理解“AI 能回答问题”，而在于把业务价值、模型行为、数据边界、人类控制、监管风险和生产反馈组织成同一个闭环。

AI ATAM 用质量属性场景、utility tree、sensitivity point、tradeoff point、ADR、eval gate 和 monitoring trigger 证明 AI 架构是否足够可控, 而不是证明某个模型“聪明”。

以下来源作为学习锚点。本文把它们转成 AI / Agent 系统安全工程语言, 不把任何框架简化成单一检查清单。正式项目应记录访问日期、版本、适用性判断、控制映射和审批记录。

本文把金融零售 AI 系统从“模型功能”升级为由人、流程、模型、数据、工具、治理和反馈共同构成的 sociotechnical work system。

AI capability-based planning 研究的是企业如何把零散 AI 场景升级为可复用、可治理、可度量、可融资的业务能力组合。

Wardley Mapping 用 user need、value chain、evolution axis、doctrine、climatic patterns 和 strategic gameplay 建立 AI 产品、平台、供应商和架构投资的共同决策语言。

本文把 Conway's Law、Team Topologies、cognitive load 和 platform operating model 迁移到企业 AI 平台和金融零售 AI 产品组织，用来解释组织通信结构如何塑造系统架构、平台边界、风险责任和交付流。

AI 工程生产力不是代码生成量、story point 或工具 license 激活率，而是组织在可控风险下把业务意图转成生产价值的系统能力。

AI Continuous Discovery 把 stakeholder idea、模型能力、流程痛点和风险假设，转成可验证的 outcome、opportunity、solution、assumption、eval 和 pilot decision。

本文用 Jobs-to-be-Done 和 Outcome-Driven Innovation 建立 AI use case 选择系统, 防止路线图被 demo、模型能力、供应商话术或内部热点牵引。

模型指标是 release evidence 的一部分, 不是 AI 产品价值的终点。

AI product operating model 研究的是组织如何把 AI 从项目制交付升级为持续发现、持续交付、持续治理的工作系统。

这些来源作为学习锚点, 不构成法律、合规、审计、财务或监管咨询意见。

AI service blueprint 把 AI customer journey 升级为可运营、可审计、可治理的信任校准系统。

AI BPR 研究的是如何重新分配人、模型、规则、系统和控制点在端到端流程中的职责, 而不是给旧流程追加一个 Copilot。

AI Risk Appetite / Policy Product Management 的重点不是讲风险管理基础, 而是把 board / executive risk appetite 转成 AI 产品约束、risk-tiered controls、policy-as-product 生命周期、运行时 guardrails、监控指标、例外处理、证据包和产品路线图。

企业 AI 需要从单点项目方案升级为可复用、可治理、可观测、可审计的 reference architecture 与 control plane。

企业 AI 规模化不能靠复制更多 POC, 而要把多个 AI 应用视为同一产品族中的可治理变体。

这些来源作为学习锚点, 不构成认证、审计、法律、合规或监管意见。正式组织评估必须由 business owner、enterprise architecture、risk、compliance、privacy、security、model risk、data owner、technology owner、internal audit 和 management review 机制共同确认。

AI 控制库不是一张 checklist, 而是一套能证明“哪些 AI 风险在什么边界内被哪些控制降低到可接受水平”的证据系统。

AI Domain-Driven Design 是把 DDD 的 bounded context、ubiquitous language、aggregate、domain event、context map 和 anti-corruption layer 转成 AI 产品的任务边界、知识边界、RAG 边界、评估词表和架构治理能力。

以下 primary / official sources 作为术语和架构锚点。本文把它们转成 AI workflow discovery、agent orchestration、金融零售流程治理和可审计证据语言。访问日期按 2026-06-29 记录。

AI 知识工作重设计不是把 Copilot 分发给员工, 而是重新设计 task、decision、artifact、handoff、control、metric 和 accountability 之间的工作系统。

企业 AI 平台不能停留在“能力清单”或统一模型 API, 而要被设计成可发现、可自助、可治理、可复用、可度量的内部产品体系。

以下来源作为术语和方法锚点. 本文是学习、证据链和架构沟通训练材料, 不构成认证、合规、审计或法律意见. 正式项目需要按机构政策、监管地区、数据类型、供应商合同和模型风险要求复核.

Tests prove components work. Controls define governance expectations. Fitness functions continuously prove architecture decisions still hold.

当 AI agent 要调用 tool, API, event stream, workflow task 和外部系统时, 设计重点是用 contract-first 方法定义边界、权限、副作用、输出结构、eval、审计和版本治理, 而不是依赖 prompt 文本约定。

AI traceability 不是把 PRD 条目连到测试用例, 而是证明一个 AI 能力在特定业务结果、风险边界、系统版本和运行证据下可被测量、控制、追责和持续治理。

以下来源作为术语和方法锚点. 本文是学习和架构沟通训练材料, 不构成认证, 法律, 合规, 审计或采购意见. 正式项目需要按机构政策, 监管地区, 数据类型, AI 风险等级, 模型供应商合同和内部架构治理流程复核.

这些来源作为行业参考模型和 AI 风险治理锚点, 不构成法律, 合规, 审计或供应商选型意见。落地时仍需结合所在国家/地区监管, 银行内部数据标准, 模型风险管理和架构治理流程。

Semantic interoperability for AI = 用可交换事实、明确语义和可执行约束, 降低 AI 幻觉、概念混淆、字段错配、指标歧义和审计不可追踪。

AI Value Stream Management 研究的是 AI 价值如何从业务问题、证据、发布、采用流向可确认收益, 不是统计功能数量或模型调用量。

AI regulatory architecture 不是把 EU AI Act、NIST AI RMF、ISO/IEC 42001 和 OECD AI Principles 改写成清单, 而是把它们组合成企业 AI 控制平面。

这份 playbook 解决一个高级问题:

版本：v1.0

本 Playbook 面向金融零售场景下的 AI 数据生命周期治理，重点覆盖从业务源数据进入 AI 系统，到检索、提示词、评估、日志、反馈、模型适配，再到保留、删除、审计取证的端到端架构。它不是一份泛泛的数据治理说明，而是一套可用于架构评审、监管问询、模型上线门禁、供应商尽调和审计证据准备的工作框架。

Autonomy is not intelligence. Autonomy is delegated decision/action authority under explicit boundaries.

本 playbook 用于系统学习 Agentic AI 在生产环境中的身份、授权、委托、同意、审计、撤销与高风险操作审批。重点不是复述 OAuth 术语，而是把 Agent 身份治理设计成可落地的业务与技术控制体系：每一次 Agent 行动都必须有可归属主体、有限授权、明确目的、可撤销边界、工具层强校验和审计证据。文档聚焦 IAM、平台、安全、合规、模型治理和业务运行之间的控制接口。

本文关注的不是“把日志打全”这类普通 logging，而是如何把 AI 在生产运行中的 prompt、context、retrieval、tool calls、human approvals、model config、cost、quality、policy decisions 与 incident evidence 设计成可观测、可审计、可追责、可学习的运行证据体系。运行证据要回答业务负责人、监管

核心判断：

重要说明：本文用于学习、架构设计和内部治理训练，不构成法律意见、合规结论、审计意见、模型验证报告、监管解释或赔偿建议。正式项目必须由 Legal、Compliance、Risk、Model Risk、Fair Lending、Privacy、Security、Accessibility、Operations、Business Owner、Technology Owner 和管理层结合机构类型、司法

以下官方来源是本手册的锚点。使用方式不是复制条文, 而是把监管和标准语言转成产品需求、控制目标、架构边界、评估设计、监控指标和 evidence binder。

以下官方来源是本文的治理锚点。本文把它们转成产品、流程、架构、评估和证据语言，不把任何法规或框架简化成单一检查项。

本文不是通用 change management，也不是“上线前开个审批会”。它训练的是高级 AI 变更影响分析与发布治理能力：把每一次 AI 变更视为一个跨模型、知识、工具、规则、流程、数据、供应商和监控体系的系统性 release decision。成熟治理需要把业务意图、流程影响、控制要求、验收标准、impact graph、regression gate、runtime telemetry

本文不是基础业务分析教程, 也不是通用审计材料。它面向已经理解 AI control library、audit evidence binder、model risk、business process、requirements traceability 和 financial retail controls 的高级学习者。重点不是“有哪些控制”, 而是“控制是否持续运行、是否有效、是否弱化、谁负责

AI operational resilience 研究的不是模型是否在线, 而是 AI 参与客户可见或受监管流程后, 关键运营在依赖故障、质量降级、证据缺失或人工队列过载时是否还能保持受控服务。

Board pack 是展示层; MI architecture 是 metric contracts、lineage、thresholds、data quality、cadence、RACI、validation 和 action log 的操作系统。

以下官方来源是本文的治理锚点。本文把它们转成产品、流程、架构、证据和管理层语言，不把任何框架直接等同于监管合规结论。

AI Regulatory Horizon / Obligation Intelligence 是一套能力:

AI Exception / Risk Acceptance / Waiver Architecture 是一套把“暂时不能满足标准 AI 控制”转成有业务理由、有风险归属、有补偿控制、有到期、有证据、有升级、有硬停止条件的治理机制。

版本：v1.0

Human review 不是“有人审核”这句话, 而是可运营、可扩容、可校准、可审计、可恢复的生产控制体系。

AI segregation of duties 的核心不是多配几个角色，而是防止不相容职责在 agentic workflow 中被同一人、同一 agent、同一服务账号、同一供应商或同一自动化链条合并。

Consent、preference 和 purpose limitation 在金融零售 AI 中不是同意弹窗或隐私文案, 而是运行时数据使用控制。系统必须能在每次 RAG、tool、memory、log、vendor 和 open banking 数据路径中判断并证明“此数据能否为此目的被此 AI 能力使用”。

Shadow AI 与 citizen development 治理的核心不是压制员工真实需求，而是把未批准 AI 工具、自建 Bot、浏览器插件、低代码 Agent 和个人账号中的 uncontrolled AI use 转成可发现、可分级、可引导、可控制、可审计和可迁移的平台化能力。

金融销售、推荐、服务和催收场景中的 AI 不能只按通用 trust UX 管理, 必须被治理为 conduct-controlled decision support。

AI records / retention / legal hold / eDiscovery architecture 把 AI records 从“日志保存”升级为可分类、可保留、可保全、可检索、可生产、可删除、可审计的金融零售生产能力。

AI data residency / cross-border / sovereign AI architecture 把 data residency、cross-border transfer 和 sovereign AI 从法律和风险语言转成运行时数据路径、供应商控制、证据链、密钥治理和系统性 release gate。

AI 可以起草、改写、翻译、总结和个性化客户沟通, 但机构必须治理完整 content lifecycle。受监管沟通不是 free-form model output, 而是带 taxonomy、claim、disclosure、approval、channel capture、surveillance、complaint linkage 和 remediation 的内容对象。

Financial crime AI 的核心不是把 alert 或 SAR narrative 自动化, 而是把 typology、scenario、red flag、evidence、human decision 和 audit replay 组织成可治理的 coverage architecture。

AI intellectual property / content rights / provenance architecture 把 AI 内容生产从“能生成”升级为可分类、可授权、可追踪、可审查、可发布、可下架、可审计的金融零售生产能力。

AI 时代的身份欺诈防御不是购买单点 liveness、deepfake detector 或 MFA 能力, 而是把身份可信度、媒体完整性、认证上下文、交易意图、人工复核和证据回放组织成可运营的 identity fraud control architecture。

Workforce AI 不是普通企业效率工具, 它可能影响候选人和员工的机会、评价、排班、晋升、培训、纪律、调查和工作体验。治理重点是把 AI 输出放回 employment decision chain, 明确目的、数据、模型、人工判断、沟通、申诉、监控和证据的边界。

AI incident disclosure / liability / risk transfer 不是基础 incident response, 而是把 AI 事故从“技术故障”升级为事实保全、客户影响界定、披露支持、责任边界、保险权利保留、供应商追偿和 board-ready 证据架构。

核心判断:

本文把 authorized push payment scam 从“客户自己转账”重构为一套 real-time customer protection architecture。学习重点不是背诵反欺诈话术, 而是理解如何把 payment rail、scam typology、intent confidence、beneficiary/mule intelligence、frontline e

本文不是基础服务目录建设指南, 而是把 agents、tools、prompts、MCP servers、APIs 和 reusable AI capabilities 做成一个可运营、可认证、可授权、可审计、可退出的 internal platform product。

Vulnerability-aware / inclusive AI 不是给客户贴标签, 而是把 support need recognition、accessible channel、proportional intervention、human handoff、agent-assist guardrails、complaint linkage 和 evidence replay 设计成 cus

本文把 AI payment-dispute capability 从“客服自动回复”重构为一套 evidence、clock、rule catalog、customer communication、complaint linkage and audit replay control plane。学习重点不是背诵 chargeback 或 Reg E / Reg Z 术语, 而是理解不同产品、支付

本文把 AI collections 从“自动化催收”重构为 customer-treatment architecture。学习重点不是更高频地触达客户, 而是理解 early delinquency signal、hardship option、contact control、repayment treatment、vulnerable-customer signal、agent assist

本文把 voice bots、real-time transcription、agent assist、call summarization、next-best-action、speech analytics、QA automation、workforce coaching、disclosures、recording consent、accessibility、fraud/social engin

Digital identity wallet / verifiable credential 不是“少传一次证件”的前端体验, 而是 issuer trust、claim minimization、holder consent、RP policy、fraud control、AI boundary 和 evidence replay 共同构成的信任决策系统。

open banking 的核心不是“连接账户”, 而是把 consent、API access、data lineage、model use、third-party obligations、revocation 和 audit evidence 组织成一个可撤销、可解释、可审计的 data-sharing operating system。

personalized pricing 的难点不是“更懂客户”, 而是把 risk-based pricing、relationship value、offer relevance、experimentation、fair lending、conduct risk、privacy 和 customer harm 放进同一个受控 decisioning system。

Document intelligence 不是 OCR 自动化, 而是把 raw artifact、layout、extraction、validation、human review、records/legal hold、workflow action 和 complaint replay 串成 evidence-grade operating system。

Privacy clean room 不是更安全的文件交换工具, 而是 purpose-bound collaboration、measurement science、output disclosure control、AI-use restriction 和 evidence governance 共同构成的数据协作系统。

AI 信用生命周期治理的对象不是某个 underwriting 模型, 而是从准入、定价、额度、解释、人审、投诉到组合反馈的一套受控 decisioning operating system。

Wealth AI 的成熟度不取决于它是否“更会聊投资”, 而取决于教育、产品事实、个性化推荐、组合构建、交易执行、人工升级、披露、监督、投诉和模型风险能否形成一套可证据化的 advice boundary architecture。

Treasury AI 的学习重点不是预测一个更准的 liquidity number, 而是把预测、假设、压力情景、人工挑战、行动记录和董事会管理信息组织成 forecast-to-action system。

重要说明: 本文是架构与内部治理参考, 不构成法律意见、合规结论、监管解释、客户赔付建议、审计意见、模型验证报告或正式投诉回复建议。正式项目必须由 Legal、Compliance、Risk、Complaint Operations、Model Risk、Privacy、Security、Data Governance、Business Owner、Technology Owner 和管理层结合机

本文把 account opening、digital onboarding、KYC/CIP/CDD、identity proofing、KYB/UBO、risk-tiering、exception queue、funding activation、fraud/AML handoff、客户沟通和 audit evidence 组织成可运行、可复核、可治理的 onboarding decision

AML alert triage AI 的成熟目标不是更快关闭告警, 而是把 alert、CDD/EDD context、entity graph、evidence workspace、human-owned disposition、SAR boundary、QA、tuning feedback、model risk 和 audit replay 组织成受控调查系统。

Payment ops AI 的成熟交付物不是“自动对账率”, 而是把 file、core posting、GL、settlement cash、suspense、repair queue、cut-off SLA、dual control、evidence 和 incident response 串成 controlled exception operating system。

regulatory reporting 的核心对象不是静态报表, 而是被定义、被控制、被签署、被提交、被追溯、可纠错的 reportable fact。

核心银行现代化的主线不是“旧核心到新核心”的技术搬迁, 而是事实源、客户影响、运营责任和审计证据的受控迁移。

Requirements mining 不是把文档丢给大模型生成 backlog，而是把多源业务、流程、控制和生产证据转成可追溯、可评估、可验证、可治理、可复用的 requirement and process knowledge assets。AI 可以扩大证据面、发现冲突、聚类噪声和生成候选资产；人类专家负责解释、取舍、授权、治理和上线责任。

AI UAT 的核心不是 sign-off, 而是证明某个 AI release 在明确业务边界、风险阈值、控制覆盖、运营准备和回滚条件下可以被接受。

本手册把 AI product portfolio rationalization、capability decommission、application portfolio management、feature/API/model sunset、vendor exit、records/legal-hold control、customer migration 和 architecture gov

AI 系统上线后，真实问题不是“有多少人点开过”，而是 AI 是否改变了受治理的工作行为，并且在质量、风险、成本和组织承载能力都可控的前提下产生了可持续净价值。Adoption analytics 不是使用量报表，而是 work-as-done baseline、行为事件、telemetry、outcome attribution、value leakage 和 scale/stop decisi

本手册把 AI investment narrative、business case 和 board decision pack 视为同一个决策系统, 目标是让 AI 投资能被资助、挑战、放行、暂停或停止。

Stakeholder alignment 不是软性沟通任务, 而是 AI delivery architecture。谁能批准、阻断、出资、运营、审计、采用或受伤害, 必须像 model、data、RAG、tool 和 control 一样被设计、追踪和验证。

当企业出现以下信号时, 使用本 playbook:

AI delivery assurance control tower 的目标不是增加审批, 而是把 discovery、pilot、release、scale 和 post-release assurance 中的关键决策变成有证据、有节奏、有责任、有回滚的治理系统。

AI 产品上线后仍在持续变化, 因为模型、prompt、知识库、数据、tool permission、policy、workflow 和用户行为都会改变结果与风险。Product Operations 的学习重点不是会议模板, 而是 post-launch operating system。

版本: v1.0

本手册研究企业如何把 AI 技术、监管、供应商、成本、安全和组织信号转成可执行的战略前瞻系统。

Important note: this playbook is a governance and architecture learning guide. It is not legal advice, regulatory advice, audit opinion, model validation, contract interpretation, liability conclusion

Context is not a bag of text. Prompts, RAG sources, embeddings, metadata, tool outputs, memory, user profiles, policy snippets and workflow state form a governed context supply chain that can change m

版本: v1.0

These anchors provide the operating vocabulary for risk, management systems, architecture description, provenance, lineage, and trustworthy AI. They do not replace local legal, compliance, privacy, re

这份 playbook 用于建立一套可执行的 AI eval dataset operating model：

Use the lab to test behavior assumptions before real-world exposure, then use real-world evidence to recalibrate the lab.

This playbook helps teams design AI operations where human attention, judgment and authority are treated as production architecture. It gives practical templates for operator load, automation bias, tr

使用本 playbook 解决五类问题:

版本: v1.0

使用本 playbook 建立一套可执行的模型组合治理机制：

重要说明: 本 playbook 是学习、架构训练和内部治理讨论材料, 不构成法律意见、合规结论、投资建议、信贷审批建议、AML/SAR 决策、投诉处理意见、模型验证报告或审计结论。正式项目必须由 Legal、Compliance、Risk、Model Risk、Privacy、Security、Operations、Business Owner、Technology Owner 和管理层结合机构

本 playbook 用于回答一个高级问题:

版本: v1.0

Shadow mode / counterfactual evaluation / silent launch 的目的, 是在 AI 真正影响客户或一线员工之前, 生成可审计、可比较、可决策的 evidence:

版本: v1.0

版本: v1.1

保留历史：旧计划、旧笔记、旧代码、旧模板默认保留；它们记录学习意图、认知演进和未来任务池。

The ABPA plan is not another note-writing track. The output is a set of business decision artifacts that can survive interviews, consulting discussions, architecture reviews, and delivery governance.

1. Read AML_ABPA_10_DAY_STARTER.md from top to bottom.

1. Which part of evidence gathering takes the most time?

把 10-day starter pack 从 v0.1 的方向确认和初始资产，深化为 portfolio-grade artifact：能证明你如何把金融犯罪合规场景中的模糊业务痛点，转成数据准备、流程改造、需求验收、eval、控制架构、运营模型、采用指标和商业价值。

STAR-T 是主线，ABPA 是证据层：

Questions:

flowchart TD A[Start] --> B[Task] B --> C{Decision} C -->|Yes| D[Task] C -->|No| E[Exception] D --> F[End] E --> F

-

Score each item from 1 to 5.

R = responsible, A = accountable, C = consulted, I = informed.

The goal is not to say "I understand AI BA / AI PM / AI Architecture".

《Blur vs OpenSea：NFT 市场双极格局与产品取舍》

Compound 由 Robert Leshner 于 2018 年创立，是以太坊上最早的算法借贷协议之一。它率先实现了"供给即挖矿"的资金池模式，用户存入资产自动获得 cToken 作为存款凭证，利率由算法根据资金利用率实时调整。Compound 在 2020 年 DeFi Summer 中通过 COMP 流动性挖矿引爆了整个 DeFi 赛道，是借贷协议的开创者和标杆。

学习计划中的产品分析产出汇总，便于查找与作品集整理。

「10年金融经验 + 270天系统化专家深度（机构DeFi×量化×AI×密码学）」 — 在地球上找到第二个的概率几乎为零。

文件：docs/TRADFI_DEFI_BRIDGE_WHITEPAPER.md

文件：docs/CRYPTO_QUANT_RESEARCH_METHODOLOGY.md

文件：docs/FINANCE_AGENT_PROJECT.md（1,799行，~30页架构文档）

白皮书：docs/ZK_PRIVACY_TRANSACTION_SYSTEM.md（2,147行 ≈ 30+页）

[ ] 6份RWA协议拆解（BUIDL/Ondo/Centrifuge/Maple/Goldfinch/Backed）

初级架构师：知道模式名称，能照着文档实现 中级架构师：理解何时用什么模式，能做trade-off分析 高级架构师：能识别反模式，能在约束下做最优决策，能主导评审 首席架构师：能定义架构愿景，能影响组织结构，能治理技术资产 ↑ 目标在这里

第一阶段检验标准：

每个系统用3天完成，共6周（含缓冲）：

1. <$5k 量化 ≠ 副业收入，定位是「3-5 年 edge 沉淀的训练账户」。真正的赚钱杠杆是 ① edge → ② 扩规模 → ③ 复利时间。

Web3 的核心特征是数据公开透明，这给产品经理带来了独特优势：