AI 扩展计划 / Playbooks

AI Domain-Driven Design / Ubiquitous Language Playbook

以下来源作为 DDD、AI 风险管理和 AI 管理体系的学习锚点, 本文把它们转成金融零售 AI 产品的建模、评估和治理资产, 不构成法律、合规、审计或模型验证意见。访问日期按 2026-06-29 记录。

595 行AI_DOMAIN_DRIVEN_DESIGN_UBIQUITOUS_LANGUAGE_PLAYBOOK.md

AI Domain-Driven Design / Ubiquitous Language Playbook

面向对象: AI Product Architect / AI PM / AI BA / Enterprise Architect / Data Product Manager / AI Governance / 金融零售业务架构负责人。核心问题: 如何把 DDD 的 bounded context、ubiquitous language、aggregate、domain event、context map 和 anti-corruption layer 转成 AI 产品的任务边界、知识边界、RAG 边界、评估词表和架构治理能力。学习目标: 能为 AML、信贷、客服、财富等金融零售 AI 场景建立领域模型、业务语言、知识权威、上下文隔离、eval taxonomy 和产品架构证据。前提假设: 读者已具备成熟 BA / CBAP 能力, 本手册不讲基础需求分析, 重点训练 AI 时代的领域建模、架构边界、业务语言治理和落地表达。

Source Anchors

Anchor	Official / primary source	本文使用方式
Domain Language DDD Resources	https://www.domainlanguage.com/ddd/	用 DDD 的核心词汇、strategic design、bounded context、ubiquitous language 和 legacy integration 思路组织复杂业务域。
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 语言组织 owner、policy、lifecycle、operation、performance evaluation、change control 和持续改进。

Standards-to-artifacts:

Source lens	可以产出的 artifact	高级表达
DDD strategic design	Bounded Context Map、Context Relationship Contract、Domain Event Catalog	“我不会把企业 AI 做成一个万能助手, 我会先拆出业务上下文和语言边界。”
DDD tactical design	Aggregate catalog、entity/value object model、domain service boundary	“我会把客户、账户、case、alert、申请、建议等对象的业务不变量建模清楚, 再决定 AI 能读、写、建议还是执行。”
NIST AI RMF	AI Context Risk Map、Eval Failure Taxonomy、Release Gate Evidence	“我把上下文混用、知识误引、越权行动和术语歧义转成可测风险。”
ISO/IEC 42001	AI Domain Governance RACI、Change Control、Management Review Pack	“我把领域语言和知识边界纳入 AI 管理体系, 不是靠 prompt 口头约束。”

1. One-Sentence Positioning / 一句话定位

AI Domain-Driven Design 的核心不是把 DDD 图画得更复杂, 而是:

business domain
-> bounded context
-> ubiquitous language
-> domain model
-> AI task boundary
-> knowledge / RAG boundary
-> eval vocabulary
-> product architecture and governance

一句话:

AI Domain-Driven Design = 用业务上下文和共同语言约束 AI 能理解什么、检索什么、建议什么、调用什么、评估什么、由谁治理。

金融零售 AI 产品最危险的失败, 往往不是模型不会生成答案, 而是模型在错误的上下文里使用了看似正确的业务词:

“高风险客户”在 AML、信贷、财富、客服里的含义不同。
“approved” 可能指信贷批准、合规批准、经理审批、系统状态或模型建议通过。
“case” 可能是 AML case、客服投诉 case、欺诈调查 case、贷后催收 case。
“customer” 在零售银行、商户收单、财富管理和 KYC 里对应不同身份、权限和生命周期。
“policy” 可能是监管政策、内部制度、产品条款、模型策略、风控规则或技术访问策略。

因此 AI PM / Architect 的工作不是写更长 prompt, 而是让每个 AI capability 都能回答:

它属于哪个 bounded context。
它使用哪套 ubiquitous language。
它读取哪些 authoritative sources。
它能触碰哪些 aggregate 和 domain events。
它的输出如何被业务词表、eval taxonomy 和 release gate 约束。
它如何与其他上下文通过 explicit contract 集成, 而不是混用语义。

2. 为什么 AI 产品需要领域驱动设计, 而不是只靠 prompt 和流程图

流程图能表达步骤, prompt 能表达意图, 但两者都不足以管理金融零售 AI 的核心复杂度: 语言歧义、上下文边界、业务不变量、权限分层、知识权威和责任归属。

常见做法	能解决什么	解决不了什么	DDD 补强点
Prompt instruction	让模型按格式、语气和约束回答	不能稳定定义业务词含义、来源权威和跨域边界	用 ubiquitous language 和 domain rules 约束 prompt vocabulary
BPMN / workflow	表达流程步骤和人工节点	不表达对象生命周期、聚合不变量和上下文语言差异	用 aggregate、domain event 和 policy 捕捉业务状态变化
数据字典	定义字段	不表达业务概念在不同上下文中的语义冲突	用 bounded context 管理一词多义
RAG 文档库	提供知识召回	不能自动判断哪个知识源属于哪个业务上下文	用 source authority + context-specific retrieval
API 编排	连接系统能力	不自动保证 AI 任务边界和工具权限正确	用 context map + anti-corruption layer
Eval accuracy	测输出好坏	如果词表和失败分类不清, 指标无法定位问题	用 eval vocabulary 和 failure taxonomy

2.1 AI 时代的 DDD 价值

DDD 能力	AI 产品中的价值	金融零售例子
Bounded Context	防止 AI 把不同业务域的规则、状态和术语混用	AML 的 suspicious activity 不等于信贷的 default risk
Ubiquitous Language	让业务、产品、架构、数据、评估、治理使用同一套词	“EDD” 在 KYC 上下文中定义为增强尽调, 不是客服升级
Aggregate	保护业务不变量, 决定 AI 能否更新状态	Loan Application aggregate 的 approve / decline 不能由 LLM 直接执行
Domain Event	捕捉业务事实变化, 驱动 AI 触发和审计	`AlertEscalated`、`CreditMemoSubmitted`、`ComplaintResolved`
Policy	把规则和判断条件显式化	fee waiver、KYC document requirement、suitability rule
Context Map	明确上下文关系和集成契约	客服助手只消费产品条款和 case 状态, 不直接解释 AML 调查规则
Anti-Corruption Layer	保护核心域不被外部或 legacy 语义污染	把 CRM 的 loose status 映射成受控业务状态后再给 AI 使用

2.2 反模式

反模式	风险	更好的做法
一个 enterprise copilot 回答所有问题	权限、术语、来源和责任混在一起	按 bounded context 拆成多个 capability, 共享平台不共享语义
把流程节点当领域边界	同一流程可能跨多个上下文, 每步语言不同	用业务模型、对象生命周期和 owner 划分边界
让 prompt 解释所有术语	prompt 难以覆盖同义词、版本、地区和上下文差异	维护 glossary、taxonomy、ontology 和 retrieval metadata
把 RAG index 当业务域	index 是技术资产, 不是 source of truth	每个 index 绑定业务上下文、权威来源、权限和版本
用平均准确率评估业务语言	平均值掩盖高风险术语误用	按 term、context、risk tier、policy version 切片评估

3. 核心框架: DDD-AI Boundary Stack

DDD-AI Boundary Stack 用来把领域建模转成 AI 产品架构。它从业务语言开始, 到任务、知识、工具、评估和治理闭环结束。

层	核心问题	关键决策	核心产物
1. Domain Intent	这个 AI 能力服务哪个业务结果	AML 调查效率、信贷 memo 质量、客服一次解决率、财富适当性准备	AI Domain Opportunity Canvas
2. Bounded Context	它属于哪个业务上下文	AML investigation、Credit origination、Customer servicing、Wealth advisory	Bounded Context Map
3. Ubiquitous Language	这个上下文中的核心词是什么	customer、case、risk、approval、policy、exception、recommendation	Ubiquitous Language Glossary
4. Domain Model	AI 接触哪些对象和规则	aggregate、entity、value object、domain service、policy	Domain Model Canvas
5. Domain Events	哪些业务事实触发 AI 或被 AI 记录	alert created、document missing、complaint escalated	Domain Event Catalog
6. AI Task Boundary	AI 能读、总结、建议、草拟、决策还是行动	allowed / blocked / human approval action	AI Task Boundary Matrix
7. Knowledge Boundary	AI 从哪些来源检索, 如何处理冲突	authority、effective date、jurisdiction、permission	RAG Boundary Matrix
8. Integration Boundary	如何连接其他上下文和系统	context map、ACL、API contract、event contract	Context Integration Contract
9. Eval Vocabulary	如何把业务语言转成评估	eval cases、rubric、failure taxonomy、critical terms	Domain Eval Taxonomy
10. Governance	谁维护语言、知识、模型和发布	owner、steward、approver、review cadence	AI Domain Governance RACI

一句话能力表达:

我能把一个 AI use case 从业务上下文拆解到语言、模型、知识、任务、工具、评估和治理边界, 避免企业 AI 因语义混用和责任不清而失控。

4. DDD-to-AI Mapping

4.1 Strategic Design Mapping

DDD 概念	传统含义	AI 产品映射	金融零售例子
Domain	组织要解决的业务问题空间	AI capability 所服务的业务价值域	金融犯罪风险、消费信贷、客户服务、财富咨询
Subdomain	domain 下的能力区域	AI 产品组合和能力地图	AML alert triage、SAR narrative drafting、KYC remediation
Core Domain	产生差异化竞争力的核心业务	需要最严格建模和评估的 AI 能力	信贷风控决策支持、AML 调查质量、财富顾问生产力
Supporting Domain	支撑核心业务的领域	可用平台能力和标准化组件支持	文档检索、客服知识库、流程摘要
Generic Domain	通用能力	可购买、复用或平台化	OCR、translation、PII detection、ticket routing
Bounded Context	模型和语言保持一致的边界	AI prompt、RAG、tools、eval、owner 的边界	Credit Origination Assistant 不能复用 Collections 语言直接判断新贷申请
Context Map	上下文之间的关系	AI capability 之间、业务系统之间的集成模式	客服上下文从账务上下文读取交易事实, 但不解释 AML red flag
Anti-Corruption Layer	防止外部模型污染内部模型	术语映射、状态标准化、权限过滤、输出翻译	把 legacy CRM 的 `VIP` 映射为财富上下文的客户层级, 不能映射为信贷优质客户

4.2 Tactical Design Mapping

DDD 概念	AI 映射	设计问题	Eval / Governance 映射
Entity	有身份和生命周期的业务对象	AI 是否能读取、引用、修改或创建该对象	entity permission test、lineage log
Value Object	用值表达的业务概念	AI 是否正确解释金额、日期、地区、风险等级	term-specific eval、format validation
Aggregate	保护不变量的一组对象	AI 是否被允许改变 aggregate 状态	blocked action test、human approval gate
Aggregate Root	外部访问 aggregate 的入口	工具调用必须通过受控 API 或 service	tool permission contract、audit trail
Domain Service	不自然属于单个 entity 的业务逻辑	AI 是否只能调用服务, 而不绕过规则	service-level policy eval
Domain Event	已发生的业务事实	AI 触发、消费、摘要和审计的事件	event completeness eval、event replay
Repository	访问 aggregate 的集合接口	RAG / tool 不应绕过 repository 读取敏感事实	data access control、query audit
Policy	业务规则或决策策略	AI 输出必须引用或遵守的规则	policy version eval、violation taxonomy
Specification	可组合的判断条件	AI 建议必须暴露哪些条件已满足或缺失	rubric and evidence check

4.3 Context Relationship Patterns for AI

关系模式	AI 架构含义	适用场景	风险控制
Partnership	两个上下文共同演进 AI 契约	AML case 与 KYC remediation 强耦合	联合 owner、共享 eval cases、变更联审
Customer / Supplier	下游消费上游输出	客服助手消费产品知识和账务事实	SLA、schema contract、版本通知
Conformist	下游接受上游模型	分行助手使用总部政策模型	明确上游术语和不可本地改写的规则
Anti-Corruption Layer	需要转换外部语义	Vendor risk score 接入内部信贷模型	mapping table、confidence、exception queue
Shared Kernel	少量共享概念	customer id、product code、jurisdiction	共享范围极小, 变更严格管理
Separate Ways	不集成	财富建议和普通客服 FAQ 风险差异过大	独立 index、prompt、eval、owner

5. AI Task Boundary: 哪些任务属于一个 bounded context, 哪些不能跨上下文混用

AI task boundary 不是按模型能力划分, 而是按业务语言、知识来源、对象生命周期、风险责任和操作权限划分。

5.1 Task Boundary Grammar

AI capability [name]
belongs to bounded context [context]
for role [user role]
can perform [read / retrieve / summarize / recommend / draft / decide / act]
on domain objects [entities / aggregates / events]
using knowledge sources [authority and versions]
under policies [business rules / risk rules]
with required human controls [review / approval / escalation]
and eval gates [rubric / critical failures / thresholds].

5.2 同一上下文内适合组合的任务

组合	为什么可以属于同一 bounded context	例子
Retrieve + summarize	使用同一套术语、来源、权限和引用规则	AML analyst 检索 alert 证据并总结交易模式
Summarize + draft	草稿基于同一业务对象和政策边界	信贷 officer 根据申请材料草拟 credit memo
Recommend + explain	建议和解释引用同一政策与 evidence rubric	客服主管判断 fee waiver 是否应升级
Event trigger + case note	事件和记录属于同一 aggregate 生命周期	`ComplaintEscalated` 后生成主管 review note

5.3 不能跨上下文混用的任务

混用方式	为什么危险	正确边界
用客服 FAQ 回答信贷审批政策	FAQ 语言简化, 不能替代风险政策	信贷上下文只能检索 credit policy、product terms、approved procedure
用 AML red flag 给普通客户打营销风险标签	AML suspicious activity 是调查语义, 不是营销 segment	AML 事件只能通过合规批准的 aggregate / event contract 输出
用财富适当性问卷推断信贷风险	suitability 与 creditworthiness 目标、法规、数据不同	财富上下文与信贷上下文 separate ways 或受控 ACL
用催收话术影响新贷审批建议	collections 语言服务贷后回收, 不应用于贷前判断	新贷审批只能使用 origination context 的政策和数据
用模型记忆跨客户复用 case 细节	侵犯隐私并污染上下文	memory 必须限定 customer / case / role / retention boundary

5.4 Task Boundary Matrix

AI task	Low-risk allowed	Restricted	Blocked
Read domain facts	读取授权用户可见事实	读取敏感事实需 purpose、role、case binding	跨客户、跨 case、跨权限读取
Retrieve policy	检索当前上下文权威政策	检索相关上下文政策需明确 reason 和 citation	用低权威来源覆盖高权威政策
Summarize evidence	摘要已授权证据	高风险摘要需保留关键不确定性和引用	删除或弱化 red flag、complaint、adverse action 信息
Recommend next step	推荐人工可复核动作	高影响建议需条件、证据和人工确认	单独做 approve / decline / freeze / investment recommendation
Draft communication	草拟员工或客户沟通	客户外发前需 policy、tone、compliance check	承诺费用减免、收益、审批结果或监管解释
Call tools	创建低风险 task、更新非关键字段	高影响动作需审批、限额、回滚	直接冻结账户、拒绝贷款、提交 SAR、执行交易

6. Knowledge / RAG Boundary: source authority、term ambiguity、policy version、context-specific retrieval

RAG boundary 是 bounded context 的知识投影。一个生产级 AI capability 不应查询“所有企业知识”, 而应查询“本上下文、当前角色、当前任务、当前政策版本允许使用的知识”。

6.1 Source Authority

Authority level	来源类型	AI 使用方式	冲突规则
A0 External binding authority	法规、监管规则、正式监管函	作为最高约束, 需要合规解释	与内部资料冲突时升级 Compliance
A1 Internal approved policy	经批准的政策、制度、产品条款	高风险回答 primary evidence	覆盖 SOP、FAQ、培训材料
A2 Approved procedure / SOP	操作流程、控制清单	操作步骤和人工升级	不得推翻 A1
A3 System of record	核心账务、CRM、case management	客户、账户、交易、case 事实	事实类问题以系统记录为准
A4 Product / training knowledge	培训材料、产品说明、内部 FAQ	解释、话术、低风险引导	不得作为高风险政策依据
A5 Historical cases / notes	历史工单、调查 note、会议纪要	候选经验和相似案例	必须标记为非权威或专家审核
A6 External vendor / web reference	供应商材料、公开资料	背景知识和功能说明	不替代内部政策和监管解释

6.2 Term Ambiguity Control

术语	上下文 A	上下文 B	RAG 控制
case	AML investigation case	customer service complaint case	`context_type` metadata 必填, query rewrite 不跨域扩展
risk score	transaction monitoring score	credit risk score	glossary 绑定 owner、range、model source、解释限制
approval	loan approval	compliance approval	answer schema 必须声明 approval type
policy	product fee policy	AI tool access policy	source category 与 business domain 分离
customer	retail banking customer	merchant beneficial owner	entity type 和 relationship path 必须显式

6.3 Policy Version Boundary

版本问题	失败模式	设计控制
新旧政策同时命中	回答混合口径	retrieval filter 使用 effective date、expiry date、business date
地区规则差异	引用错误 jurisdiction	metadata 必含 jurisdiction、channel、product、customer segment
草稿误入生产	使用未批准政策	ingestion gate 排除 draft、pending approval、retired source
培训材料滞后	FAQ 覆盖正式政策	authority rank 控制 context packing
模型缓存旧答案	知识已更新但回答仍旧	policy version embedded in trace, release 后清理或标记缓存

6.4 Context-Specific Retrieval Pattern

user role
-> task intent
-> bounded context
-> permitted source classes
-> effective date / jurisdiction / product filters
-> term expansion from context glossary
-> hybrid retrieval
-> authority-aware rerank
-> conflict detection
-> context packing
-> claim-level citation

6.5 RAG Boundary Matrix

Dimension	必备字段	设计问题	Eval case
Context	`bounded_context_id`	这个知识源属于哪个业务语言边界	同一 query 在 AML /客服上下文返回不同证据
Authority	`authority_level`	冲突时信谁	FAQ 与政策冲突时引用政策
Version	`effective_date`、`expiry_date`	问题发生时适用哪个版本	旧政策 hard negative 不进入 context
Jurisdiction	`country`、`state`、`branch`	地区规则是否不同	US 与 EU KYC 规则分开回答
Permission	`role`、`purpose`、`case_id`	用户是否有权检索	无权 chunk 不进入 candidate trace
Term Scheme	`concept_id`、`alt_label`	同义词和缩写如何展开	UBO / beneficial owner / 最终受益人召回一致
Source Status	`approved`、`retired`、`draft`	来源是否可生产使用	draft source 命中即 release blocker
Evidence	`clause_id`、`span_id`	引用能否支撑断言	每个关键断言有 evidence span

7. Eval Vocabulary: 把业务术语转成 eval cases、failure taxonomy、decision rubric

AI eval 不能只写“答案正确、语气友好”。金融零售场景需要把 ubiquitous language 转成评估词表, 让业务、架构、风险和模型团队能讨论同一类失败。

7.1 Term-to-Eval Mapping

业务术语	Eval object	例子	评分关注点
高风险客户	Critical term case	AML 高风险 vs 信贷高风险	是否使用正确上下文定义
例外审批	Policy boundary case	fee waiver exception	是否说明条件、权限和人工审批
适当性	Regulated advice case	wealth suitability checklist	是否避免直接投资建议和收益承诺
可疑活动	Evidence completeness case	unusual transaction pattern	是否保留 red flags 和不确定性
拒绝贷款	High-impact decision case	adverse action draft	是否禁止 LLM 单独决定并保留合规解释
当前有效政策	Version case	2026 fee policy vs 2025 fee policy	是否按 business date 和 effective date 检索

7.2 Failure Taxonomy

Failure category	定义	示例	Severity
Context confusion	使用错误 bounded context 的术语或规则	用客服投诉 case 语言解释 AML case	Critical in regulated workflows
Authority inversion	低权威来源覆盖高权威来源	FAQ 覆盖正式产品条款	Critical
Version error	使用过期或未生效政策	引用旧 KYC 文件清单	High / Critical
Jurisdiction error	地区、国家、渠道规则混用	用 US 规则回答 EU 客户问题	High
Unsupported claim	关键断言无证据	说客户符合豁免但无政策引用	High
Missing red flag	摘要遗漏关键风险信号	AML narrative 省略 structuring pattern	Critical
Excessive agency	AI 执行或承诺超出授权	承诺贷款批准或费用免除	Critical
Data leakage	跨客户、跨 case、跨角色泄露	向客服暴露 AML 调查细节	Critical
Term drift	同一术语在版本或团队间定义漂移	“active customer” 口径变化未入 eval	Medium / High
Rubric mismatch	评分标准与业务语言不一致	judge 把语气流畅误判为合规	High

7.3 Decision Rubric

Score	Business meaning	Release interpretation
5	使用正确上下文、权威来源、当前版本和精确证据, 明确边界和人工责任	可作为目标行为样本
4	业务结论正确, 引用充分, 存在轻微表达或结构问题	可上线但进入改进 backlog
3	大体有用, 但证据粒度、边界说明或术语一致性不足	低风险 pilot 可接受, 高风险不放行
2	存在上下文混用、证据不足、版本不清或遗漏关键条件	不放行, 需要修复
1	越权承诺、错误政策、泄露、遗漏关键风险或错误决策建议	Release blocker / incident candidate

7.4 Eval Case Schema

字段	说明
`case_id`	例如 `AML-CTX-014`、`CREDIT-POLICY-022`
`bounded_context`	AML Investigation、Credit Origination、Customer Servicing、Wealth Advisory
`user_role`	analyst、credit officer、customer service agent、advisor、supervisor
`business_term_under_test`	高风险客户、例外审批、适当性、可疑活动
`query`	用户自然语言输入
`expected_behavior`	answer、refuse、escalate、ask clarification、draft only
`gold_sources`	权威来源和条款
`hard_negatives`	相似但错误的来源
`policy_version_date`	应使用的业务日期
`rubric`	评分规则
`critical_failures`	触发 no-go 的失败
`owner`	业务或风险 owner

7.5 Eval-to-Governance Loop

Eval 信号	可能根因	治理动作
某术语失败率高	glossary 不清或 synonym 未治理	词表 steward 修订定义和 alt labels
某上下文混用频繁	retrieval filter 或 prompt boundary 弱	拆 index、强化 metadata、更新 context map
某政策版本错误	source registry 版本字段缺失	ingestion gate 加 effective / expiry check
judge 与专家分歧	rubric 不够业务化	业务专家重写评分说明和 examples
新事件类型无评测覆盖	domain event catalog 变化	新增 event-driven eval slice

8. Financial Retail Case: AML / 信贷 / 客服 / 财富的 bounded context 与 AI 设计

8.1 Context Map

Bounded context	核心业务语言	AI capability	不能混用的上下文
AML Investigation	alert、case、red flag、suspicious activity、SAR narrative、evidence	证据检索、交易模式摘要、case narrative 草稿、升级建议	客服投诉、营销分层、普通信用风险
KYC / Customer Due Diligence	customer、UBO、CDD、EDD、document requirement、risk rating	文件清单解释、缺失材料识别、remediation checklist	信贷审批、财富推荐、客服优惠
Credit Origination	application、borrower、collateral、DTI、credit memo、approval condition	申请材料摘要、政策引用、memo 草稿、条件缺失检查	催收、营销、AML suspicious activity
Customer Servicing	inquiry、complaint、fee dispute、case status、resolution、escalation	政策问答、客服回复草稿、投诉摘要、转人工建议	AML 调查、信贷最终审批、财富个性化建议
Wealth Advisory	suitability、risk profile、investment objective、disclosure、recommendation rationale	顾问准备、资料摘要、适当性 checklist、风险披露草稿	普通客服、信贷评分、未经授权投资建议

8.2 AML Investigation

设计面	决策
Bounded context	AML Investigation, 独立于客服和营销上下文
Ubiquitous language	alert、case、red flag、typology、counterparty、SAR narrative、evidence
Aggregate	AML Case aggregate: alert、transactions、entities、evidence、analyst notes、case decision
Domain events	`AlertGenerated`、`EvidenceAttached`、`CaseEscalated`、`NarrativeDrafted`、`CaseClosed`
AI task boundary	可检索证据、总结模式、草拟 narrative；不可单独提交 SAR 或关闭 case
RAG boundary	只检索 AML policy、typology guide、case evidence、authorized historical cases
Eval focus	missing red flag、unsupported claim、data leakage、typology mismatch

高级表达:

AML 助手的边界不是“帮分析员写得更快”, 而是围绕 AML Case aggregate 保护 evidence completeness、red flag preservation、SAR narrative traceability 和 analyst accountability。

8.3 Credit Origination

设计面	决策
Bounded context	Credit Origination, 与 Collections 和 Marketing 分离
Ubiquitous language	application、borrower、income verification、DTI、collateral、approval condition、adverse action
Aggregate	Loan Application aggregate: applicant、documents、score inputs、conditions、decision package
Domain events	`ApplicationSubmitted`、`DocumentMissing`、`CreditMemoDrafted`、`ConditionRequested`、`DecisionRecorded`
AI task boundary	可摘要材料、检查政策条件、草拟 memo；不可单独 approve / decline
RAG boundary	credit policy、product terms、approved underwriting procedure、current rate sheet
Eval focus	policy version error、fair lending sensitive attribute misuse、unsupported approval condition

高级表达:

信贷 AI 的关键不是让模型“判断能不能贷”, 而是让它在 Credit Origination 上下文内提升材料完整性、政策引用质量和 memo 可审计性, 同时把最终信贷决策留在受控流程里。

8.4 Customer Servicing

设计面	决策
Bounded context	Customer Servicing, 面向咨询、投诉、争议和服务恢复
Ubiquitous language	inquiry、complaint、fee dispute、resolution、escalation、service recovery
Aggregate	Service Case aggregate: customer inquiry、interaction history、resolution status、escalation record
Domain events	`InquiryReceived`、`ComplaintCreated`、`FeeDisputeOpened`、`EscalationRequested`、`ResponseSent`
AI task boundary	可回答低风险政策、草拟回复、总结互动；高风险承诺需人工确认
RAG boundary	product terms、approved FAQ、service SOP、case status facts
Eval focus	unauthorized commitment、wrong fee policy、poor escalation、privacy leakage

高级表达:

客服 AI 可以追求速度和一致性, 但它的语言边界必须把“解释政策”和“承诺补偿或监管解释”分开。

8.5 Wealth Advisory

设计面	决策
Bounded context	Wealth Advisory, 由适当性、披露和顾问责任约束
Ubiquitous language	suitability、risk profile、investment objective、time horizon、disclosure、advisor rationale
Aggregate	Advisory Session aggregate: client profile、objectives、product materials、disclosures、advisor notes
Domain events	`ProfileUpdated`、`DisclosureReviewed`、`RecommendationPrepared`、`AdvisorApprovedNote`
AI task boundary	可整理资料、生成 checklist、草拟披露说明；不可直接向客户输出个性化买卖建议
RAG boundary	approved product materials、risk disclosure、suitability policy、advisor-approved notes
Eval focus	suitability overclaim、return promise、missing disclosure、role confusion

高级表达:

财富 AI 的边界要把 advisor enablement 和 direct advice 区分开, 让模型支持顾问准备和证据整理, 不替代持牌顾问责任。

9. Artifact Templates

这些模板可直接用于作品集、架构评审、AI governance review 和面试讲述。字段可以按项目规模压缩, 但不要删除 owner、context、source、eval 和 decision boundary。

9.1 AI Domain Model Canvas

字段	内容
Domain / subdomain	业务域和子域, 例如 Financial Crime / AML Investigation
Business outcome	希望改善的业务和风险结果
Bounded context	语言和模型一致的边界
Primary roles	用户、专家、审核人、受影响客户
Core objects	entities、value objects、aggregates
Business invariants	必须保护的业务不变量
Domain events	触发、记录和审计的事件
AI task modes	read、retrieve、summarize、recommend、draft、decide、act
Blocked actions	AI 永远不能单独执行的动作
Knowledge sources	权威来源、版本、权限、owner
Integration points	上下文关系、API、events、ACL
Eval focus	关键术语、失败分类、release blockers
Governance	owner、steward、review cadence、change control

9.2 Ubiquitous Language Glossary

Field	Example
`term_id`	`aml.red_flag`
`preferred_term`	Red flag / 风险信号
`definition`	在 AML Investigation 上下文中表示需要分析员关注的可疑模式、证据或行为。
`bounded_context`	AML Investigation
`allowed_synonyms`	suspicious indicator、typology indicator
`blocked_synonyms`	customer complaint、credit risk flag
`related_terms`	alert、case、typology、SAR narrative
`source_authority`	AML Policy v6.1、Typology Guide v4
`owner`	AML Policy Owner
`eval_cases`	`AML-TERM-001`、`AML-CTX-014`
`change_rule`	定义变更触发 retrieval regression 和 expert review

9.3 Context Map

From context	To context	Relationship	Contract	AI control
Customer Servicing	Core Banking	Customer / Supplier	account status API、transaction display contract	只读授权事实, 不解释账务规则之外的风险
AML Investigation	KYC	Partnership	customer due diligence event、risk rating update	联合评审术语和 red flag handoff
Credit Origination	CRM	Anti-Corruption Layer	customer profile mapping	CRM 标签不能直接作为 creditworthiness
Wealth Advisory	Product Catalog	Customer / Supplier	approved product material feed	只使用当前有效材料和 disclosure
Enterprise AI Platform	All contexts	Generic platform	logging、eval、model gateway、policy engine	平台共享能力, 不共享业务语义

9.4 RAG Boundary Matrix

Field	Example
`rag_boundary_id`	`credit-origination-policy-rag`
`bounded_context`	Credit Origination
`user_roles`	credit officer、credit supervisor、model risk reviewer
`allowed_sources`	Credit Policy、Underwriting SOP、Product Terms、Rate Sheet
`excluded_sources`	Collections scripts、Marketing propensity model、retired policies
`authority_order`	A0 regulation > A1 credit policy > A2 SOP > A3 system facts > A4 training
`metadata_filters`	product、jurisdiction、effective_date、customer_segment、approval_status
`term_scheme`	credit glossary v3
`hard_negative_rules`	retired policy and similar collections terms must not enter final context
`citation_requirement`	claim-level citation for approval conditions and adverse action rationale
`eval_slices`	version, jurisdiction, product, exception, sensitive attribute exclusion

9.5 Domain Eval Taxonomy

Field	Example
`taxonomy_id`	`wealth-advisory-domain-eval-v1`
`critical_terms`	suitability、risk profile、investment objective、disclosure
`failure_categories`	context confusion、unsupported claim、return promise、missing disclosure
`severity_rules`	direct personalized recommendation by AI = critical
`rubric_dimensions`	context correctness、source authority、evidence support、human control、tone
`release_blockers`	unauthorized advice、outdated product material、missing risk disclosure
`monitoring_slices`	advisor role、product type、client risk profile、channel
`owner`	Wealth Advisory Product Owner + Compliance Reviewer

9.6 AI Domain Governance RACI

Activity	Product	Domain Owner	Architecture	Data / Knowledge	Risk / Compliance	Model / Eval
Define bounded context	A	R	R	C	C	C
Maintain glossary	C	A	C	R	C	C
Approve source authority	C	A	C	R	R	C
Design task boundary	A	R	R	C	R	C
Approve tool actions	C	R	R	C	A	C
Build eval taxonomy	A	R	C	C	R	R
Release gate decision	A	R	R	C	R	R
Review incidents	R	A	R	R	R	R

10. Interview Answers

10.1 30 秒版本

我会用 DDD 先划清 AI 产品的 bounded context, 因为金融零售里同一个词在 AML、信贷、客服、财富中的含义可能完全不同。然后把 ubiquitous language 做成 glossary、taxonomy 或 ontology, 绑定权威知识源、RAG 检索边界、工具权限和 eval vocabulary。这样 AI 不是靠 prompt 猜业务含义, 而是在明确的领域模型、知识边界和评估门禁里工作。

10.2 2 分钟版本

我不会从“做一个万能 AI 助手”开始, 而会先问它属于哪个业务上下文。例如 AML investigation、credit origination、customer servicing 和 wealth advisory 都有自己的语言、对象、事件和风险责任。

第一步是 bounded context: 明确这个 AI capability 服务哪个业务结果, 由谁负责, 接触哪些 aggregate, 比如 AML Case、Loan Application、Service Case 或 Advisory Session。

第二步是 ubiquitous language: 把核心词汇定义清楚, 包括同义词、禁用混淆词、权威来源和 owner。比如 “case” 在 AML 和客服里不能混用, “approval” 在信贷和合规里也不是同一件事。

第三步是 AI task boundary: 定义模型可以 read、retrieve、summarize、recommend、draft 到什么程度, 哪些 decide 或 act 必须人工审批或禁止。例如信贷 AI 可以草拟 credit memo, 但不能单独 approve 或 decline。

第四步是 RAG boundary: 检索要按 context、source authority、policy version、jurisdiction、permission 和 term scheme 过滤, 不能让模型查询整个企业知识库。

第五步是 eval vocabulary: 把业务词转成 eval cases、failure taxonomy 和 release blocker。比如 context confusion、authority inversion、version error、unsupported claim、excessive agency 都要能被测试和追踪。

这样产出的不是一个聊天界面, 而是一套可治理的 AI 产品架构: context map、domain model、glossary、RAG boundary matrix、domain eval taxonomy 和 release gate evidence。

10.3 Enterprise Architect 版本

在企业架构视角, 我会把 AI DDD 看成业务架构、数据架构、应用架构和治理架构之间的语义控制层。

业务架构上, bounded context 定义能力边界和 owner, 避免 enterprise copilot 把 AML、信贷、客服、财富的语言混在一起。数据架构上, ubiquitous language 连接 glossary、taxonomy、ontology、source registry、lineage 和 access policy。应用架构上, context map 决定 AI capability 如何通过 API、events、ACL 和 anti-corruption layer 连接 legacy systems 与核心域。治理架构上, NIST AI RMF 和 ISO/IEC 42001 的思路可以落到 risk mapping、measure plan、release gate、change control、incident review 和 management review。

我会重点交付五类架构资产:

Bounded Context Map: 每个 AI capability 的业务边界、owner、核心对象和上下文关系。
Ubiquitous Language Glossary / Ontology: 关键术语、同义词、禁用混淆词、来源权威和治理责任。
AI Task Boundary Matrix: 模型能读、检索、总结、建议、草拟、决策和行动的边界。
RAG Boundary Matrix: source authority、version、permission、jurisdiction、term scheme 和 citation requirement。
Domain Eval Taxonomy: 把业务语言转成 failure taxonomy、rubric、critical failures 和 release blockers。

高级判断标准是: 如果一个 AI 能力无法说明它属于哪个 bounded context、使用哪套语言、检索哪些来源、能触碰哪些 aggregate、如何处理跨上下文语义、用什么 eval vocabulary 放行, 它就不应该进入高风险金融零售生产流程。

11. Portfolio Storyline

作品集不要只展示“我做了一个 RAG chatbot”。更强的叙事是:

业务复杂度: 同一术语跨 AML / 信贷 / 客服 / 财富存在语义冲突
-> 架构方法: 用 DDD 拆 bounded context 和 context map
-> 语言治理: 建立 ubiquitous language glossary、taxonomy、ontology
-> AI 边界: 定义 task boundary、tool boundary、RAG boundary
-> 评估证据: 建立 domain eval taxonomy 和 release blockers
-> 治理闭环: 用 owner、version、incident、change control 持续维护

可展示资产清单:

Artifact	展示什么能力
AI Domain Model Canvas	能把 AI idea 转成领域模型和业务不变量
Bounded Context Map	能识别架构边界和跨域风险
Ubiquitous Language Glossary	能治理术语、同义词和语义冲突
Context Map + ACL	能设计 legacy / vendor / platform 集成边界
RAG Boundary Matrix	能把知识权威、版本、权限和检索设计串起来
Domain Eval Taxonomy	能把业务语言转成评估、门禁和风险证据
Release Gate Memo	能用证据支持 pilot、limited go、no-go 或 rollback

最终一句话:

我的 AI 架构能力不是把模型接到流程里, 而是把金融零售的领域语言、业务边界、知识权威、任务权限和评估门禁连接成一个可运行、可审计、可持续治理的产品系统。