AI DDD：通用语言与上下文边界
AI Domain-Driven Design 的核心不是把 DDD 名词套到 AI 项目上，而是用 bounded context、ubiquitous language、domain event 和 context map 约束 AI 的理解、检索、推理和行动边界。大模型最容易制造的系统性风险之一，就是把相似词当作同义词，把局部上下文当作全局规则，把建议型任务误解成决策型任务。
AI Domain-Driven Design / Ubiquitous Language 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_DOMAIN_DRIVEN_DESIGN_UBIQUITOUS_LANGUAGE_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| Domain Language / DDD | https://www.domainlanguage.com/ddd/ | 参考领域驱动设计、bounded context、ubiquitous language 和建模语言 |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 将领域边界与 AI risk mapping、measurement、management 连接 |
| ISO/IEC 42001 | https://www.iso.org/standard/81230.html | 将领域知识、系统责任和管理体系连接 |
核心导读
AI Domain-Driven Design 的核心不是把 DDD 名词套到 AI 项目上，而是用 bounded context、ubiquitous language、domain event 和 context map 约束 AI 的理解、检索、推理和行动边界。大模型最容易制造的系统性风险之一，就是把相似词当作同义词，把局部上下文当作全局规则，把建议型任务误解成决策型任务。
在金融零售场景，领域边界一旦混乱，AI 就可能把营销资格、信贷资格、风险预警、客户投诉和监管解释混在一起。DDD 的价值是让 AI 系统知道“这个词在这个上下文里到底意味着什么，以及它不能跨越哪些边界”。
问题定义
AI 项目的语义失败通常表现为：
- 同一个词在不同部门含义不同，例如 eligible、approved、delinquent、dispute、case。
- 知识库按组织文件夹堆叠，而不是按业务上下文和决策边界组织。
- RAG 检索跨越上下文，导致答案引用了不适用的政策、地区或产品版本。
- agent 工具调用没有明确 aggregate 和 invariant，导致越权更新或破坏流程一致性。
- eval 用例只测“回答是否通顺”，没有测领域语义是否正确。
DDD 要解决的是 AI 系统的 semantic boundary 问题：
| 边界问题 | AI 后果 |
|---|---|
| 概念未定义 | 模型用常识替代业务规则 |
| 上下文未隔离 | 检索和推理跨域污染 |
| 事件未建模 | 无法追踪业务状态变化和责任 |
| invariant 未显性化 | 工具调用可能破坏核心业务约束 |
| 语言未进入 eval | 测试无法发现语义错配 |
核心原理与方法
DDD 转化为 AI 系统设计时，重点是六个对象。
| DDD 对象 | AI 系统中的作用 |
|---|---|
| Bounded Context | 定义知识、术语、规则、工具和权限的有效边界 |
| Ubiquitous Language | 形成 prompt、schema、eval、日志和用户界面的共同词汇 |
| Context Map | 描述上下文之间的 upstream/downstream、translation 和 anti-corruption |
| Aggregate | 定义可被工具修改的业务一致性边界 |
| Domain Event | 记录业务状态变化，支撑 trace、audit 和 workflow orchestration |
| Anti-Corruption Layer | 防止外部模型、供应商、旧系统或通用语言污染核心领域语义 |
AI DDD 的基本方法：
- 从高风险业务流程中抽取关键概念，而不是从数据库表开始。
- 对每个概念写清上下文、定义、同义词、禁用解释、状态转移和责任系统。
- 用 context map 决定 RAG corpus、tool scope、prompt role 和 eval dataset 的边界。
- 对跨上下文交互建立 translation layer，而不是让模型自由解释。
- 把领域语言嵌入 telemetry，便于按概念和事件分析失败。
系统与架构模型
AI DDD 可以落成以下架构：
Domain Context Map
-> Ubiquitous Language Registry
-> Knowledge Boundary / Corpus Policy
-> Task Boundary / Tool Contract
-> Semantic Eval Suite
-> Runtime Trace with Domain Events
关键组件：
| 组件 | 职责 |
|---|---|
| Language Registry | 保存领域术语、定义、上下文、别名、禁用含义和 owner |
| Context-aware Retrieval | 根据业务上下文、产品、地区、客户状态和权限过滤知识 |
| Tool Contract | 以 aggregate、command、precondition、postcondition 定义工具调用 |
| Domain Event Log | 记录 AI 建议、人工确认、工具执行、异常和补偿事件 |
| Semantic Eval | 用领域概念、边界案例和政策冲突测试模型行为 |
| Anti-Corruption Layer | 把外部服务输出转换为内部领域语言和安全 schema |
示例 context map：
| Context | 核心概念 | AI 能做 | AI 不能做 |
|---|---|---|---|
| Customer Service | complaint、case、resolution | 摘要、分类、建议回复 | 承诺赔付或关闭监管投诉 |
| Credit Decisioning | affordability、score、decline reason | 解释已做出的决策 | 改写授信规则或绕过模型 |
| Fraud Operations | alert、case、suspicious pattern | 聚合线索、建议调查步骤 | 单独冻结账户 |
| Marketing | offer eligibility、consent | 生成合规文案草稿 | 使用未授权敏感属性定向 |
关键机制与取舍
AI DDD 的取舍不是建模多细，而是边界放在哪里。
| 取舍 | 判断方式 |
|---|---|
| 细粒度 context vs 交付复杂度 | 高风险概念和规则变动频繁的领域要细分；低风险 FAQ 可粗一些 |
| 通用模型能力 vs 领域约束 | 通用语言适合生成和摘要，决策解释必须受领域词汇和政策约束 |
| RAG 自由召回 vs 上下文过滤 | 召回越宽覆盖率越高，但跨域误用风险越大 |
| 工具抽象简单 vs invariant 完整 | 工具接口越简单越易用，但必须保留 precondition、权限和幂等控制 |
| 单一企业词典 vs context-specific language | 企业词典提供入口，真实执行必须允许上下文差异 |
一个实用规则：凡是会影响客户权益、资金、监管义务或业务状态的概念，都不能只放在 prompt 里，必须进入 schema、tool contract、eval 和 trace。
证据与控制
DDD 在 AI 中的证据不是建模图本身，而是模型行为是否受领域边界约束。
| 控制目标 | 控制活动 | 证据 |
|---|---|---|
| 防止跨上下文误用知识 | 检索按 context、jurisdiction、product 和 entitlement 过滤 | retrieval trace、negative test |
| 保持术语一致 | prompt、UI、schema、eval 使用 language registry | schema review、terminology diff |
| 防止工具破坏业务约束 | tool contract 定义 precondition、postcondition、aggregate owner | contract test、tool trace |
| 发现语义失败 | eval 按领域概念和边界案例分类 | semantic failure report |
| 支持审计解释 | domain event 记录 AI 建议、人工选择和状态变化 | event log、case trace |
语义 eval 应覆盖：
- 同名异义：同一词在不同 context 下应有不同解释。
- 近义误判：相似概念不能混用，例如 complaint 与 inquiry。
- 规则冲突：模型遇到过期政策或地区差异时应说明不适用。
- 越界请求：客户权益、赔付、冻结、授信等动作必须触发限制。
- 工具边界：错误状态下不允许调用更新类工具。
AI 产品与金融零售场景
以信贷解释 AI 为例，DDD 决定它不是“回答贷款问题的聊天机器人”，而是处在清晰上下文中的解释系统。
| 设计对象 | 具体定义 |
|---|---|
| Bounded Context | Credit Decision Explanation，不等同于 underwriting 或 marketing |
| 核心概念 | application、decision、adverse reason、affordability、appeal、disclosure |
| 知识边界 | 当前产品政策、地区法规、已批准解释模板、客户本人申请数据 |
| 工具边界 | 读取申请状态、读取解释原因、创建申诉 case；不能改决策 |
| 事件 | explanation_requested、reason_presented、appeal_created、human_review_required |
| 评测 | 原因解释准确性、禁用承诺、地区政策适用性、敏感属性处理 |
真实取舍在于：客户希望得到清晰答案，但系统不能把“解释已发生决策”滑向“重新做授信判断”。因此架构上要把 explanation context 与 decisioning context 隔离，允许读取决策原因，但不允许模型生成新的授信理由或调用决策工具。
反模式
- 把所有文档放进一个向量库，让模型自己判断上下文。
- 把术语表当成静态文档，不进入 prompt、schema、retrieval、tool 和 eval。
- 只画领域模型，不定义 AI 任务边界和工具边界。
- 将 legacy 系统字段名直接暴露给模型，造成语义污染。
- 用通用问答测试替代语义边界测试。
- 让 AI 在多个 bounded context 中同时执行动作，却没有 translation 和 audit。
最终心智模型
AI DDD 是给概率系统加上业务语义边界。bounded context 决定 AI 在哪里理解，ubiquitous language 决定 AI 如何表达，aggregate 和 tool contract 决定 AI 能否行动，domain event 决定行动如何被追踪。成熟的 AI 系统不是“知道更多”，而是知道哪些知识在当前上下文中有效，哪些动作必须被禁止或升级。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。