AI 扩展计划 / Playbooks
AI Architecture Views / C4 / arc42 / 42010 Playbook
以下来源作为术语和方法锚点. 本文是学习, 作品集和架构沟通训练材料, 不构成认证, 合规, 审计或法律意见. 正式项目需要按机构政策, 监管地区, 数据类型, 供应商合同和模型风险要求复核.
740 行AI_ARCHITECTURE_VIEWS_C4_ARC42_42010_PLAYBOOK.md
AI Architecture Views C4 / arc42 / ISO 42010 Playbook
目的: 训练 AI Product / Enterprise Architect / Solution Architect / AI BA 把 AI 系统从一张大图升级为可沟通, 可评审, 可发布, 可审计, 可作品集化的架构视图体系. 适用对象: 已有 10 年金融零售 PM / BA / Developer 经验, 且已具备 CBAP 能力的人. 本文不讲需求和架构基础, 重点是 AI 产品, 企业架构, 解决方案架构, 架构沟通和作品集表达. 核心观点: C4 解决结构表达, arc42 解决架构文档叙事, ISO 42010 解决 stakeholder / concern / viewpoint / view 的治理语言. AI 架构要把 model, RAG, tool, eval, policy, observability, evidence, human accountability 和 release gate 放进同一套视图系统.
Source Anchors
以下来源作为术语和方法锚点. 本文是学习, 作品集和架构沟通训练材料, 不构成认证, 合规, 审计或法律意见. 正式项目需要按机构政策, 监管地区, 数据类型, 供应商合同和模型风险要求复核.
| Anchor | Link | 本文使用方式 |
|---|---|---|
| C4 Model | https://c4model.com/ | 用 Context, Container, Component, Code 的分层结构表达 AI 系统边界, 运行单元, 关键组件和实现责任. |
| arc42 | https://arc42.org/ | 用 arc42 的架构文档结构组织目标, 约束, 上下文, building blocks, runtime, deployment, cross-cutting concepts, ADR, quality 和 risk. |
| ISO/IEC/IEEE 42010 | https://www.iso.org/standard/74393.html | 用 stakeholder, concern, architecture viewpoint, architecture view, correspondence 和 rationale 思路建立可治理的视图体系. |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern, Map, Measure, Manage 的风险管理语言把 AI risk, eval, monitoring, evidence 和 improvement 接入架构视图和 release gate. |
One-Sentence Positioning
AI Architecture Views = 用 ISO 42010 定义谁关心什么, 用 C4 展示 AI 系统如何组成和交互, 用 arc42 写清楚架构决策和质量属性, 再用 NIST AI RMF 风险语言把 eval, policy, observability, evidence 和 release gate 变成架构交付物.
更短的面试表达:
我不会只画一张 AI 大图. 我会为不同 stakeholder 建立 view package: 业务价值看 capability view, CTO 看 C4 container 和 integration view, risk 看 policy / eval / evidence view, delivery team 看 component / runtime / deployment view, audit 看 42010-style stakeholder-concern traceability.
1. 为什么 AI 架构表达不能只有一张大图
AI 项目进入企业生产后, 最大问题通常不是图不够漂亮, 而是同一张图承担了过多职责:
| 一张大图想表达的内容 | 实际问题 | 更好的视图安排 |
|---|---|---|
| 业务流程, 模型调用, RAG, 工具, 审批, 监控全部放一起 | 读者无法判断哪些是业务边界, 哪些是技术边界, 哪些是控制边界 | 用 capability / workflow view 表达业务, 用 C4 表达结构, 用 control view 表达风险控制 |
| 只显示 app, LLM, vector DB, API | 看不到数据权限, 知识来源, 工具动作, 人工责任和证据 | 增加 data / knowledge view, tool / action view, human accountability view, evidence view |
| 用一张 sequence diagram 说明所有事情 | 无法回答架构评审中的质量属性, 失败模式和 release gate | 单独建立 runtime view, quality view, failure mode view 和 gate view |
| 把治理写成旁注 | Risk, compliance, audit 无法基于图提出有效挑战 | 用 ISO 42010 的 concern traceability 连接 stakeholder, concern, viewpoint, evidence |
| 把模型当成普通外部服务 | 忽略模型版本, prompt, eval, drift, hallucination, data leakage 和 judge calibration | 在 C4 和 arc42 中加入 model, prompt, eval, monitoring, policy 的专门视图 |
企业 AI 架构表达要同时服务五类沟通:
| 沟通对象 | 他们真正关心的问题 | 推荐视图 |
|---|---|---|
| Business sponsor | AI 是否嵌入真实业务流程, 价值如何实现, 人类责任是否清楚 | Capability view, workflow view, human accountability view |
| Product / BA | 用户旅程, 数据输入, 输出责任, fallback, 采用指标 | Experience view, process view, outcome metric view |
| CTO / Enterprise Architect | 系统边界, 平台复用, 集成方式, 技术债, 演进路线 | C4 context / container, integration view, roadmap view |
| Solution / Delivery team | 组件职责, API, runtime sequence, deployment, SLO, failure handling | C4 component, runtime view, deployment view, observability view |
| Risk / Compliance / Audit | 风险等级, 控制, 审批, eval 证据, 运行监控, 例外处理 | Policy view, eval gate view, evidence view, 42010 traceability |
关键转变:
从: 画一个 AI solution diagram
到: 设计一组 architecture viewpoints, 每个 view 回答明确 stakeholder concern, 并指向证据和决策.
2. Viewpoint Taxonomy
Viewpoint 是看架构的规则: 为谁看, 看什么 concern, 用什么模型, 产出什么 evidence, 用于什么决策. View 是按这个规则画出来或写出来的具体架构内容.
2.1 AI Architecture Viewpoint Catalog
| Viewpoint | Primary stakeholders | Concerns | Model kinds | Evidence outputs |
|---|---|---|---|---|
| Business Capability View | Business sponsor, Enterprise Architect, Product | 哪些业务能力被 AI 增强, 哪些能力需要平台支撑 | Capability map, value stream, heatmap | capability-to-use-case map, investment rationale |
| Experience / Human Accountability View | Product, BA, Ops, Compliance | AI 在哪个用户旅程节点介入, 人类是否保留最终责任 | journey map, swimlane, responsibility matrix | human-in-the-loop rule, user disclosure, escalation design |
| C4 System Context View | CTO, EA, Security, Product | AI 系统边界, 用户, 外部系统, 供应商, 数据边界 | C4 context diagram | system boundary, external dependency list |
| C4 Container View | Solution Architect, Platform, Security | app, orchestration, model gateway, RAG, tool gateway, eval, observability 如何部署和交互 | C4 container diagram | container responsibilities, integration contracts |
| C4 Component View | Engineering, QA, SRE | 关键容器内部组件如何分工 | component diagram, interface table | component ownership, API and event contracts |
| Data / Knowledge / RAG View | Data owner, Knowledge owner, Security, Model Risk | 知识源, 权限, freshness, retrieval, citation, poisoning risk | lineage diagram, RAG pipeline, source registry | source card, retrieval eval, entitlement test |
| Model / Prompt / Policy View | AI Architect, Model Risk, Platform | 模型路线, prompt 版本, policy-as-code, risk-tiered routing | model route diagram, prompt lifecycle, policy matrix | model card, prompt record, policy decision log |
| Tool / Action View | Solution Architect, Security, Operations, Compliance | Agent 可以调用什么工具, 动作风险, 幂等, 审批, 回滚 | tool catalog, action tier map, sequence diagram | tool card, approval record, action ledger |
| Runtime / Failure Mode View | Delivery, SRE, Operations | 正常路径, fallback, timeout, degradation, kill switch | sequence, state machine, fault tree | runbook, incident drill, rollback condition |
| Eval / Release Gate View | Product, Model Risk, QA, Compliance | 如何证明当前版本适合用途, 何时能 pilot / release / scale | eval contract, gate checklist, scorecard | eval report, release memo, risk acceptance |
| Observability / Evidence View | SRE, Audit, Model Risk, Management | 生产请求如何追踪, 质量如何监控, 审计证据如何形成 | trace schema, dashboard, evidence binder map | trace sample, dashboard link, evidence index |
| Portfolio / Roadmap View | CTO, PMO, AI Transformation Lead | 哪些 AI 用例共享平台能力, 哪些控制复用, 投资优先级如何定 | portfolio matrix, dependency map, maturity radar | roadmap, reuse metrics, risk exception summary |
2.2 View Package By Architecture Question
| Architecture question | Minimum view package |
|---|---|
| 这个 AI use case 值得做吗? | Capability view, value hypothesis, risk tier, adoption metric view |
| 这个系统边界清楚吗? | C4 context, external dependency list, data boundary view |
| 这个方案能否上线给客户使用? | Experience view, RAG view, policy view, eval gate view, monitoring view |
| 这个 Agent 是否能安全调用工具? | Tool / action view, policy matrix, runtime sequence, approval and action ledger |
| 这个系统是否可运维? | Container view, deployment view, SLO, observability view, incident runbook |
| 这个 release 是否可审计? | Stakeholder-concern matrix, eval report, release memo, evidence binder |
| 这个项目能否成为作品集? | C4 pack, arc42 summary, decision matrix, case narrative, portfolio evidence pack |
2.3 AI Viewpoint 设计原则
| Principle | 架构含义 |
|---|---|
| Concern first | 先定义 stakeholder concern, 再决定画什么图. |
| Separate structure from control | C4 讲结构, control view 讲允许, 拒绝, 审批, 降级和证据. |
| Treat data and knowledge as architecture | RAG 不是实现细节, 它影响权限, 时效, 引用, 责任和审计. |
| Treat eval as release architecture | Eval 不是 QA 附件, 而是 release gate 和风险接受的核心证据. |
| Keep human accountability explicit | 所有高风险 AI 输出都要说明谁 review, 谁 approve, 谁最终负责. |
| Make observability evidence-ready | trace 不只是 debug, 还要服务模型风险, audit, incident 和 management review. |
| Portfolio over single use case | 企业架构价值来自复用 model gateway, RAG, eval, policy, tool, observability 和 evidence. |
3. C4 For AI Systems
C4 的优势是让复杂系统从高层到低层逐步展开. 对 AI 系统而言, 关键不是把 LLM 画成一个外部 box, 而是把 AI-specific responsibilities 放在正确层级.
3.1 C4 Level 1: System Context
Context view 回答: 这个 AI 系统存在于哪个业务环境中, 与哪些人, 系统, 供应商和控制边界交互.
AI context view 必须显示:
| Element | AI-specific content |
|---|---|
| Human users | customer, employee, analyst, reviewer, approver, auditor |
| Business systems | CRM, core banking, LOS, case management, payment, product catalog, knowledge base |
| AI platform services | model gateway, RAG service, eval service, policy engine, observability, evidence binder |
| External providers | LLM provider, embedding provider, monitoring vendor, data provider |
| Trust boundary | customer data boundary, vendor boundary, region boundary, regulated process boundary |
| Human accountability | final decision owner, review owner, escalation path |
Context view 不能只写 "User -> AI App -> LLM". 对金融零售, 最小上下文应该能回答:
- 这个 AI 输出是客户可见, 员工内部, 决策支持, 还是工具动作?
- 哪些客户数据和业务系统进入上下文?
- 哪些第三方模型或供应商可能接触数据?
- 输出是否影响客户权益, 资金, 合规报告或投诉处理?
- 哪个角色保留最终业务责任?
3.2 C4 Level 2: Container
Container view 回答: 系统由哪些可部署或可运行单元组成, 它们如何交互.
AI container view 推荐包含:
| Container | Responsibility | Key controls |
|---|---|---|
| AI-enabled application | 用户体验, workflow entry, feedback, disclosure | role-based access, human review UX, fallback |
| Orchestration service | prompt assembly, workflow state, agent step, retries | step budget, deterministic wrapper, state limit |
| Model gateway | model route, version pinning, quota, fallback, cost | allowlist, data boundary, audit log |
| RAG service | ingestion, retrieval, reranking, citation, index version | entitlement, freshness, source owner, retrieval eval |
| Tool gateway | tool schema, auth, dry run, execution, result wrapping | action tier, approval, idempotency, action ledger |
| Policy engine | runtime decisions, data and action rules, exception handling | policy-as-code, version, decision log |
| Eval service | offline eval, regression, red-team, release scorecard | thresholds, critical failures, judge calibration |
| Observability pipeline | traces, metrics, logs, cost, quality signals | masking, retention, trace completeness |
| Evidence binder | release evidence, approvals, exceptions, monitoring links | immutable index, owner signoff, audit export |
Container view 中最常见的遗漏:
| Omitted container | Consequence |
|---|---|
| Policy engine | 规则散落在 prompt 和 app code, 无法复用或审计. |
| Eval service | release gate 靠主观 UAT, 版本变更后无法回归. |
| Tool gateway | Agent 直接拿业务系统权限, 动作不可控. |
| Evidence binder | 审计时补材料, 无法证明版本和批准链. |
| Observability pipeline | 出错时只能查应用日志, 看不到 model / retrieval / tool / policy path. |
3.3 C4 Level 3: Component
Component view 回答: 某个 container 内部有哪些组件, 每个组件承担什么职责.
以 Customer-facing RAG container 为例:
| Component | Responsibility | AI architecture concern |
|---|---|---|
| Source registry adapter | 读取已批准知识源, owner, effective date, audience | source authority, lifecycle, audit |
| Ingestion pipeline | parse, chunk, classify, embed, index | chunking policy, PII handling, index version |
| Entitlement filter | 按用户角色, 产品线, 地区, 文档状态过滤 | permission-before-retrieval |
| Hybrid retriever | keyword + vector + metadata retrieval | recall, freshness, query intent |
| Reranker | 对候选片段重排 | relevance, latency, model route |
| Citation builder | 将答案绑定到 source ids 和段落 | groundedness, evidence |
| No-answer classifier | 判断没有足够证据时拒答或升级 | unsupported claim prevention |
| RAG eval hook | 记录 query, retrieved docs, answer, citation, score | eval and monitoring feedback |
以 Tool gateway container 为例:
| Component | Responsibility | AI architecture concern |
|---|---|---|
| Tool catalog resolver | 根据 workflow 和 role 返回可用工具 | least privilege, allowed use |
| Schema validator | 验证模型提出的 tool arguments | deterministic control |
| Policy decision client | 请求 policy engine 判断 allow / review / deny | runtime control |
| Dry-run executor | 对 write action 生成预览和影响分析 | human review quality |
| Idempotency manager | 防止重复执行同一业务动作 | operational safety |
| Approval router | 将高风险动作送人工或双控 | human accountability |
| Action ledger writer | 记录请求, 参数, 策略, 审批, 执行结果 | audit and incident replay |
3.4 C4 Level 4: Code
Code view 不需要成为每个 AI 项目的默认交付物. 只有当关键风险集中在实现细节时才深入到代码层:
| Code-level concern | 需要 Code view 的原因 |
|---|---|
| Tool argument validation | 小错误可能导致错误退款, 错误状态更新或越权查询. |
| Policy decision wrapper | 必须证明所有高风险动作都调用同一 control point. |
| PII redaction and logging | 需要验证敏感字段不会进入 prompt, logs 或外部供应商. |
| Eval gate implementation | CI / CD 中 gate 的阻断条件必须可测试. |
| Kill switch and fallback | 需要证明关停按 use case, model, tool, tenant 或 route 生效. |
Code view 的作品集表达不要贴大段代码. 更好的方式是:
- 展示关键 wrapper 或 policy check 的伪代码.
- 说明它保护哪个 architecture concern.
- 连接到 test evidence, trace sample 或 release gate.
3.5 C4 Checklist For AI Systems
# C4 Checklist For AI Systems
## Context
- system_boundary_defined: AI system, AI platform, business systems and external providers are separated.
- user_roles_defined: customer, employee, reviewer, approver, operator and auditor roles are explicit.
- data_boundary_defined: customer data, confidential knowledge and vendor boundary are visible.
- human_accountability_defined: final decision owner and escalation path are shown.
- regulated_process_identified: credit, AML, complaints, payments, KYC or customer commitment boundaries are marked.
## Container
- model_gateway_present: application does not call models directly for production use.
- rag_service_present_if_needed: knowledge retrieval, citation and source lifecycle are explicit.
- tool_gateway_present_if_agentic: tool execution is mediated by schema, policy, approval and action ledger.
- policy_engine_present: data, action and workflow rules are runtime controls, not prompt-only text.
- eval_service_present: release quality is measured by use-case eval and regression, not demo-only review.
- observability_present: model, retrieval, tool, policy, approval and output traces are captured.
- evidence_binder_present: release, approval, exception and monitoring evidence are linked.
## Component
- component_ownership_defined: each critical AI component has business, technical or control owner.
- versioned_assets_defined: model, prompt, index, tool schema, policy and eval set are versioned.
- failure_modes_defined: fallback, no-answer, timeout, deny, degrade and kill switch are handled.
- data_minimization_defined: prompt and logs contain only necessary context.
- feedback_loop_defined: production feedback can update eval set, knowledge source, policy or prompt.
## Code
- high_risk_wrappers_tested: policy, tool execution, redaction, logging and release gate code paths are covered.
- deterministic_checks_present: model output is validated before business action.
- audit_fields_written: trace_id, use_case_id, risk_tier, model_version, prompt_version and policy_decision are recorded.
4. arc42 For AI Systems
arc42 的价值是把架构从图转成完整叙事. 对 AI 系统, arc42 不只是文档模板, 而是帮助架构师把 product intent, constraints, risk, building blocks, runtime behavior, deployment, quality and decisions 串成可评审资产.
4.1 arc42 Section Map For AI
| arc42 section | AI architecture interpretation | Required AI content |
|---|---|---|
| 1. Introduction and Goals | 为什么做这个 AI 系统, 成功如何度量 | business outcome, user workflow, AI role, adoption metric, non-goals |
| 2. Architecture Constraints | 监管, 数据, 供应商, 安全, 平台, 组织约束 | data residency, model allowlist, policy, procurement, risk tier, human oversight |
| 3. Context and Scope | 系统边界和外部依赖 | C4 context, actors, business systems, AI platform services, vendor boundary |
| 4. Solution Strategy | 核心架构路线和取舍 | RAG vs fine-tune, agent vs workflow, gateway vs direct API, HITL strategy |
| 5. Building Block View | 结构分解 | C4 container / component, model gateway, RAG, tool, eval, policy, evidence |
| 6. Runtime View | 关键场景如何运行 | happy path, no-answer, tool approval, policy deny, fallback, incident sequence |
| 7. Deployment View | 部署和运行环境 | environments, model route, network boundary, secrets, logging, regional constraints |
| 8. Cross-cutting Concepts | 横切设计原则 | identity, data classification, prompt versioning, observability, eval, security, evidence |
| 9. Architecture Decisions | 关键 ADR | model selection, RAG architecture, tool gateway, eval threshold, release gate |
| 10. Quality Requirements | 质量属性和场景 | accuracy, groundedness, safety, latency, cost, availability, explainability, auditability |
| 11. Risks and Technical Debt | 风险, 例外, 技术债 | hallucination, leakage, stale knowledge, tool misuse, judge drift, vendor lock-in |
| 12. Glossary | 统一语言 | use case, risk tier, model route, prompt, index, citation, trace, evidence binder |
4.2 arc42 AI 写作重点
| Section | 不要只写 | 应该写成 |
|---|---|---|
| Goals | 提升效率, 提升体验 | 降低客服平均处理时长 15%, 但客户承诺类回复必须人工确认. |
| Constraints | 使用公司 AI 平台 | 必须通过 model gateway, RAG source 需 owner 批准, 高风险 release 需 eval gate. |
| Solution strategy | 用 RAG 回答问题 | 用 governed RAG: source registry, entitlement filter, citation, no-answer, eval and monitoring. |
| Runtime view | 用户提问后模型回答 | 展示 retrieval, policy, model, citation, human review, fallback and trace. |
| Quality | 准确率高 | unsupported customer-facing claim = 0, citation correctness >= 95%, stale policy answer = 0. |
| Risks | 模型可能出错 | 对每个高影响 failure mode 给出 detection, control, owner and release evidence. |
4.3 AI Quality Scenarios
质量属性要写成可评审场景, 而不是抽象形容词.
| Quality attribute | Scenario | Gate evidence |
|---|---|---|
| Groundedness | 当客户询问费用政策时, 回答必须引用当前有效政策源, 不得生成没有来源的承诺 | citation eval, no unsupported claim failures |
| Permission safety | 员工只能检索其角色, 地区和产品线允许访问的知识 | entitlement test, retrieval trace |
| Human accountability | 涉及退款, 信贷, AML 或投诉升级的输出只能作为草稿或建议 | workflow control, approval record |
| Tool safety | Agent 提出 write action 时必须先做 schema validation 和 policy decision | tool gateway test, action ledger |
| Release confidence | 模型, prompt, index 或 policy 变更后必须跑 regression set | eval report, release gate memo |
| Operational resilience | 模型供应商不可用时系统进入人工或规则路径, 不隐藏失败 | fallback drill, incident runbook |
| Auditability | 任一客户可见输出可以追溯到用户, source, model, prompt, policy 和 reviewer | trace sample, evidence binder |
| Cost control | 每个 accepted answer 或 completed case 有成本归因 | cost dashboard, route-level metrics |
4.4 ADR Patterns For AI Architecture
| Decision | Typical options | AI-specific rationale |
|---|---|---|
| Model route | public API, private hosted, hybrid by risk tier | 平衡能力, 数据边界, 成本, latency, vendor risk |
| RAG strategy | per-app index, shared RAG service, federated knowledge plane | 平衡复用, 权限, freshness, domain autonomy |
| Agent control | autonomous agent, workflow-constrained agent, copilot draft only | 按动作风险和可逆性决定自动化程度 |
| Tool execution | app direct API, model-held token, tool gateway | 工具动作必须可审批, 可审计, 可回放 |
| Eval gate | manual UAT, generic benchmark, use-case eval contract | 金融零售需要场景化 eval, critical failure 和 slice analysis |
| Evidence | static document folder, runtime evidence binder | 证据应从 trace, approval, eval and monitoring 自动沉淀 |
5. ISO 42010 Stakeholders / Concerns / Views
ISO 42010 的实用价值不是让文档更学术, 而是让架构沟通从 "我画了几张图" 变成 "我知道谁关心什么, 我用哪种 viewpoint 回答, 这些 view 之间如何保持一致".
5.1 Core Mapping
| 42010 concept | AI architecture usage |
|---|---|
| Stakeholder | 对 AI system 有利益, 决策, 风险或运营责任的人或组织. |
| Concern | stakeholder 关心的系统属性, 如安全, 成本, 解释性, 审计, 可用性, 客户影响. |
| Architecture viewpoint | 规定如何表达某类 concern 的视角, 包括模型类型, 规则和证据. |
| Architecture view | 按 viewpoint 产生的具体图, 表, 文档或 dashboard. |
| Model kind | C4 diagram, sequence, BPMN, capability map, eval scorecard, policy matrix, trace schema 等. |
| Correspondence | 不同 view 之间的对应关系, 如 container 中的 RAG service 必须对应 evidence view 中的 retrieval trace. |
| Rationale | 为什么这样设计, 取舍是什么, 通过 ADR, release memo 或 decision matrix 记录. |
5.2 Stakeholder Concern Matrix
| Stakeholder | Concerns | Required viewpoints | Evidence |
|---|---|---|---|
| Business sponsor | 业务价值, adoption, 风险接受, 投入产出 | capability view, outcome metric view, portfolio view | value hypothesis, adoption dashboard, roadmap decision |
| Product Manager | 用户旅程, AI role, fallback, release scope | experience view, workflow view, release gate view | PRD slice, workflow map, release memo |
| Business Analyst | 流程, 规则, 数据输入输出, 人机分工 | process view, data view, human accountability view | swimlane, business rule catalog, RACI |
| Enterprise Architect | 业务能力, 平台复用, integration, 技术债 | capability view, C4 context / container, roadmap view | architecture canvas, dependency map, ADR |
| Solution Architect | 组件职责, runtime, deployment, failure modes | C4 component, sequence, deployment, observability view | API contracts, runbook, trace sample |
| AI Platform Owner | model, RAG, tool, eval, policy, observability 复用 | platform service view, catalog view, golden path view | service catalog, reuse metrics, platform SLO |
| Data Owner | 数据用途, 权限, freshness, lineage, retention | data / knowledge view, RAG view | source card, entitlement test, lineage record |
| Security | 身份, secrets, DLP, egress, least privilege, incident | security view, threat model, policy view | control test, DLP report, incident drill |
| Model Risk | 适用性, eval, drift, versioning, monitoring | model view, eval view, monitoring view | model card, eval report, review cadence |
| Compliance / Legal | 客户影响, disclosure, prohibited use, recordkeeping | policy view, human accountability view, evidence view | policy decision log, approval record, evidence binder |
| SRE / Operations | SLO, failure, fallback, cost, support | deployment view, runtime view, observability view | dashboard, alert rule, runbook |
| Audit | 追溯性, 控制有效性, 例外管理 | evidence view, correspondence matrix | evidence index, sample trace, exception record |
5.3 View Correspondence Rules
不同 view 不能各说各话. 建议在架构包中维护 correspondence rules:
| Rule | Why it matters |
|---|---|
| Every AI use case in capability view must have an owner, risk tier and release status | 防止作品集和治理清单脱节. |
| Every external model provider in context view must appear in model route and data boundary view | 防止供应商和数据外发风险被漏掉. |
| Every RAG source in data view must have source owner, freshness rule and entitlement rule | 防止知识源过期或越权. |
| Every tool in tool view must have action tier, schema, policy decision and audit record | 防止 agentic action 不可控. |
| Every high-risk workflow step must appear in human accountability view and release gate | 防止人工复核只是口头承诺. |
| Every release gate metric must map to quality requirement and production monitoring signal | 防止上线前 eval 与上线后监控脱节. |
| Every critical container must emit trace fields used by evidence view | 防止审计证据依赖人工补录. |
| Every ADR must link to affected views and follow-up monitoring | 防止决策停留在文档中而不进入运行管理. |
5.4 Viewpoint Description Template
# Architecture Viewpoint
## Identity
- viewpoint_id: AI-VP-EVAL-RELEASE-GATE
- viewpoint_name: Eval and Release Gate Viewpoint
- owner: AI Architecture / Model Risk
- lifecycle_stage: pilot, release, scale, major change
## Stakeholders
- Product Manager
- Model Risk
- Compliance
- Solution Architect
- Operations
## Concerns Addressed
- whether the AI system is fit for intended use
- whether critical failures are blocked before release
- whether model, prompt, RAG index, tool schema and policy changes are regression-tested
- whether residual risk is accepted by the correct owner
## Model Kinds
- eval contract
- scorecard
- critical failure table
- slice analysis
- release gate memo
- production monitoring mapping
## Required Inputs
- use_case_id and risk_tier
- intended use and prohibited use
- model_version, prompt_version, index_version, tool_schema_version and policy_version
- golden set, regression set and red-team set
- quality thresholds and critical failure definitions
## View Outputs
- eval result summary
- gate decision: go, limited go, no-go, exception
- risk acceptance and approver
- monitoring signals and review cadence
- evidence binder entry
## Correspondence Rules
- every release metric maps to a quality requirement
- every critical failure maps to a policy, eval or human control
- every limited go decision maps to scope restriction and monitoring
- every exception has owner, expiry and compensating control
6. Financial Retail Case: Customer-Facing RAG / Agent
6.1 Case Background
一家零售银行希望在 contact center console 中加入 AI assistant. 它有两个能力:
- Customer-facing RAG: 根据产品条款, 费用政策, 投诉处理手册和客户当前 case 生成带引用的回复草稿.
- Agent workflow: 在员工确认后, 可以创建 follow-up task, 更新 case note, 或发起退款审批草稿. 不能自动退款, 不能自动关闭投诉, 不能做信贷或法律结论.
业务目标:
| Goal | Target |
|---|---|
| 降低客服平均处理时长 | pilot 阶段降低 10%-15% |
| 提高政策答复一致性 | 高风险政策问题 citation correctness >= 95% |
| 保留人类责任 | 客户可见回复必须由客服确认, 退款和承诺类语句进入审批 |
| 建立可审计 release | 所有 pilot 输出有 trace, eval result, policy decision and evidence binder entry |
6.2 View Package
| View | Purpose | Key artifact |
|---|---|---|
| Capability view | 说明 AI 增强哪些客服能力, 哪些能力仍由人类或规则系统负责 | service capability heatmap |
| Experience / human accountability view | 说明客服, supervisor, compliance reviewer 的责任边界 | swimlane and RACI |
| C4 context view | 展示 contact center, CRM, policy knowledge, AI platform, model provider, evidence binder | context diagram |
| C4 container view | 展示 app, orchestration, RAG, model gateway, tool gateway, policy engine, eval, observability | container diagram |
| RAG view | 展示 source registry, ingestion, entitlement, retrieval, citation, no-answer | RAG pipeline |
| Tool / action view | 展示 case note, task creation, refund approval draft 的 action tier | tool catalog and action tier matrix |
| Runtime view | 展示 answer draft, policy denial, refund approval, fallback | sequence diagrams |
| Eval / release gate view | 展示 golden set, red-team, thresholds, critical failures | release gate memo |
| Observability / evidence view | 展示 trace schema, dashboard, evidence binder | trace and evidence map |
6.3 C4 Context Sketch
Customer
-> Contact Center Agent
-> Contact Center Console with AI Assistant
Contact Center Console with AI Assistant
-> CRM / Case Management
-> Product and Fee Policy Knowledge Base
-> AI Platform Control Plane
-> Approved Model Provider
-> Evidence Binder
AI Platform Control Plane
-> Model Gateway
-> RAG Service
-> Tool Gateway
-> Policy Engine
-> Eval Service
-> Observability Pipeline
Key context decisions:
| Decision | Rationale |
|---|---|
| AI assistant is employee-facing, not directly customer-facing | 保留客服对客户回复的最终责任, 降低误导和承诺风险. |
| Policy knowledge is retrieved through governed RAG | 保证 source owner, entitlement, freshness and citation. |
| Write actions go through tool gateway | 防止模型直接更新 CRM 或触发退款流程. |
| Release requires eval and evidence binder | 客户可见输出需要可追溯质量证据. |
6.4 Container View Summary
| Container | Responsibility | Financial retail controls |
|---|---|---|
| Contact center console | 展示 AI draft, citation, risk flag, edit and approve actions | role access, supervisor escalation, customer disclosure rules |
| AI orchestration service | 组装 case context, route RAG query, call model, propose actions | step budget, prompt version, fallback |
| RAG service | 检索有效政策和产品条款, 返回引用 | source owner, freshness block, entitlement filter |
| Model gateway | 调用 approved model route | model allowlist, data boundary, cost and version log |
| Tool gateway | 执行 case note, task creation, refund approval draft | schema validation, action tier, approval, idempotency |
| Policy engine | 判断回复内容和工具动作是否允许 | complaint escalation, refund threshold, legal phrase block |
| Eval service | 运行 RAG, tone, policy and tool trajectory eval | critical failure gate, regression |
| Observability pipeline | 收集 trace, quality, latency, cost, override, complaint signals | masked logs, retention, dashboard |
| Evidence binder | 汇聚 architecture review, eval, approval, release and monitoring | release evidence, audit export |
6.5 Runtime Sequence: Policy Answer Draft
Agent opens authenticated customer case
-> Console sends use_case_id, agent role, customer scope, case id to orchestration
-> Orchestration requests policy decision for context assembly
-> RAG service retrieves current policies with entitlement and freshness filters
-> Model gateway generates answer draft with source citations
-> Policy engine checks prohibited claims, complaint escalation and refund language
-> Console shows draft, citations, risk flags and edit controls
-> Agent edits and confirms response
-> Trace and final response metadata enter observability and evidence binder
6.6 Runtime Sequence: Refund Approval Draft
Agent asks assistant to help prepare refund request
-> Orchestration classifies requested action as customer-impacting write
-> Tool gateway validates refund draft schema and performs dry run
-> Policy engine requires supervisor approval based on amount and complaint status
-> Model drafts rationale with policy citations and customer case facts
-> Supervisor reviews amount, rationale, source citations and policy decision
-> Approved draft is sent to refund workflow, not executed directly by the model
-> Action ledger stores request, dry run, approval and execution reference
6.7 Release Gate
| Gate area | Minimum gate |
|---|---|
| RAG groundedness | citation correctness >= 95%, unsupported claim critical failures = 0 |
| Knowledge freshness | expired or superseded policy citation critical failures = 0 |
| Permission | restricted document retrieval critical failures = 0 |
| Complaint handling | mandatory escalation cases correctly flagged >= 99% |
| Tool action | write action without policy decision or approval critical failures = 0 |
| Human accountability | all customer-visible responses have agent confirmation trace |
| Monitoring readiness | dashboard shows quality, latency, cost, override, complaint and incident signals |
| Evidence completeness | architecture review, eval report, approvals, exception records and monitoring plan linked |
6.8 Portfolio Evidence For This Case
| Evidence artifact | What it proves |
|---|---|
| Stakeholder-concern matrix | 你能从 BA/CBAP 能力升级到 architecture viewpoint design. |
| C4 context and container diagrams | 你能讲清系统边界, AI platform services, 供应商和数据边界. |
| RAG and tool action views | 你能把 AI-specific risks 结构化, 不只停留在 app + LLM. |
| Eval release memo | 你能把质量, 风险和 release decision 连接起来. |
| Evidence binder map | 你能设计审计可追溯性, 而不是上线后补材料. |
| Interview narrative | 你能面向 PM, BA, Architect, CTO, Risk 讲同一套方案的不同版本. |
7. Artifact Templates
7.1 Stakeholder-Concern Matrix
# Stakeholder-Concern Matrix
## Use Case
- use_case_id: CS-RAG-AGENT-001
- use_case_name: Contact Center RAG and Agent Assistant
- business_domain: Retail Banking Customer Service
- risk_tier: High for customer-facing drafts and customer-impacting write actions
- release_scope: limited pilot for authenticated servicing calls
| Stakeholder | Decision rights | Concerns | Required views | Evidence |
|---|---|---|---|---|
| Business Sponsor | approve value and pilot scope | AHT reduction, CSAT, customer risk | capability view, adoption view | pilot metric dashboard |
| Product Owner | define workflow and release scope | user journey, fallback, feedback | experience view, runtime view | PRD slice, release memo |
| BA / Process Owner | validate rules and process fit | handoff, exception, business rule | swimlane, rule catalog | process signoff |
| Enterprise Architect | approve architecture fit | platform reuse, integration, tech debt | C4 context, container, roadmap | architecture review record |
| Solution Architect | approve design implementation | components, APIs, failure modes | component view, sequence, deployment | design review notes |
| Data Owner | approve knowledge sources | source authority, freshness, access | RAG view, data lineage | source card, entitlement test |
| Security | approve security controls | identity, DLP, secrets, egress | security view, policy view | security test result |
| Model Risk | approve AI fitness | eval, drift, monitoring | model view, eval gate view | eval report |
| Compliance | approve customer impact controls | disclosure, prohibited claims, recordkeeping | policy view, evidence view | policy decision samples |
| Operations | accept run and support model | SLO, escalation, incident, training | operating view, observability view | runbook, training pack |
| Audit | review traceability | control evidence, exception handling | evidence view, correspondence matrix | evidence binder export |
7.2 Viewpoint Catalog
# AI Architecture Viewpoint Catalog
| viewpoint_id | viewpoint_name | primary_concerns | model_kinds | minimum_evidence |
|---|---|---|---|---|
| AI-VP-001 | Capability and Value View | capability impact, value hypothesis, portfolio fit | capability map, value stream | business outcome metric |
| AI-VP-002 | Experience and Human Accountability View | user journey, AI role, human responsibility | journey, swimlane, RACI | human review rule |
| AI-VP-003 | C4 System Context View | system boundary, external dependency, trust boundary | C4 context | dependency and boundary list |
| AI-VP-004 | C4 Container View | deployable units, platform services, integration | C4 container | container responsibility table |
| AI-VP-005 | C4 Component View | internal responsibilities, APIs, ownership | component diagram, interface table | component owner and contract |
| AI-VP-006 | Data / Knowledge / RAG View | source, lineage, entitlement, freshness, citation | source registry, RAG pipeline | source card and retrieval eval |
| AI-VP-007 | Model / Prompt / Policy View | model route, prompt lifecycle, runtime control | model route, prompt registry, policy matrix | model card and policy log |
| AI-VP-008 | Tool / Action View | tool permission, action risk, approval, audit | tool catalog, action tier, sequence | action ledger sample |
| AI-VP-009 | Eval / Release Gate View | fitness for use, regression, critical failures | eval contract, scorecard, gate memo | eval report and release decision |
| AI-VP-010 | Observability / Evidence View | traceability, monitoring, audit readiness | trace schema, dashboard, evidence map | trace sample and evidence index |
7.3 arc42 Section Map
# arc42 AI Section Map
| arc42 section | Required AI questions | Evidence |
|---|---|---|
| Introduction and Goals | What business workflow changes, who uses AI, what outcomes matter, what is outside scope? | goal statement, adoption metric |
| Constraints | Which data, vendor, regulatory, platform and human oversight constraints bind the design? | constraint list, policy references |
| Context and Scope | Which users, systems, model providers, data sources and platform controls are in scope? | C4 context |
| Solution Strategy | Why this route for RAG, model, agent, tool, eval and release? | decision matrix |
| Building Block View | Which containers and components implement the system and controls? | C4 container / component |
| Runtime View | What happens for happy path, no-answer, policy deny, tool approval and fallback? | sequence diagrams |
| Deployment View | Where does it run, how are secrets, network, logs and model routes controlled? | deployment view |
| Cross-cutting Concepts | How are identity, data classification, prompt, eval, observability and evidence handled? | cross-cutting control table |
| Architecture Decisions | Which tradeoffs were decided and why? | ADR set |
| Quality Requirements | Which measurable quality and risk scenarios define release readiness? | quality scenario table |
| Risks and Technical Debt | Which residual risks remain and who owns them? | risk register and compensating controls |
| Glossary | Which terms must be consistent across business, risk and engineering? | glossary |
7.4 Architecture Review Questions
| Area | Review questions |
|---|---|
| Business fit | Which business capability is improved, and what metric proves adoption or value? |
| AI role | Is AI generating a draft, recommendation, explanation, classification or business action? |
| Human accountability | Who confirms customer-visible outputs and who owns final decisions? |
| Data boundary | What data enters prompt, retrieval, logs and vendor systems? |
| RAG | Are source owner, freshness, entitlement, citation and no-answer behavior defined? |
| Model route | Which models are allowed for this risk tier and what happens when model version changes? |
| Prompt | Are prompt versions owned, tested and linked to eval results? |
| Tool action | Which tools can be called, at what action tier, with which approval and rollback? |
| Policy | Are controls implemented in runtime policy, or only described in documents and prompts? |
| Eval | Does eval cover golden cases, regression, red-team, slices and critical failures? |
| Release | What conditions allow pilot, scale, restrict or rollback? |
| Observability | Can a production issue be replayed across identity, prompt, retrieval, model, tool, policy and output? |
| Evidence | Can audit see architecture decision, eval, approval, exception, monitoring and incident evidence in one binder? |
| Portfolio | Which platform capabilities are reused, and which one-off choices become technical debt? |
7.5 Portfolio Evidence Pack
# Portfolio Evidence Pack
## Case Narrative
- domain: retail banking customer service
- problem: policy answer inconsistency, high handling time, weak AI release evidence
- solution: governed customer-service RAG with constrained agent workflow
- audience: AI Product Manager, Enterprise Architect, Solution Architect, AI BA
## Architecture Views
- capability_view: customer servicing capability heatmap
- c4_context: users, systems, AI platform, model provider, evidence binder
- c4_container: application, orchestration, model gateway, RAG, tool gateway, policy, eval, observability
- rag_view: source registry, ingestion, entitlement, retrieval, citation, no-answer
- tool_action_view: action tier, schema validation, dry run, approval, ledger
- runtime_view: policy answer, refund approval, policy deny, fallback
- eval_release_view: eval contract, critical failures, thresholds, release decision
- evidence_view: trace schema, dashboard, evidence binder mapping
## Decisions
- ADR-001: Use governed RAG service rather than per-app vector index
- ADR-002: Use tool gateway rather than direct CRM updates
- ADR-003: Keep AI as employee-facing assistant for pilot
- ADR-004: Require eval release gate for customer-visible drafts
- ADR-005: Link production trace to evidence binder
## Metrics
- value: average handling time, first contact resolution, agent acceptance
- quality: citation correctness, unsupported claim, no-answer correctness
- risk: policy blocks, approval bypass attempts, complaint escalation misses
- operations: latency, cost per accepted answer, fallback rate, incident count
- adoption: weekly active agents, edited vs accepted drafts, feedback reason
## Interview Proof Points
- shows CBAP-level stakeholder and concern analysis
- shows architecture-level C4 and arc42 communication
- shows AI-specific control design across model, RAG, tool, eval and evidence
- shows release governance for financial retail AI
8. Interview Expression
8.1 30 秒版本
我会把 AI 架构表达成一组 views, 而不是一张大图. C4 帮我讲系统结构: context, container, component and code. arc42 帮我写完整架构叙事: goals, constraints, runtime, deployment, quality, ADR and risk. ISO 42010 帮我把 stakeholder, concern, viewpoint and evidence 对齐. 对 AI 系统, 我会额外强调 model, RAG, tool, eval, policy, observability, evidence, human accountability and release gate, 因为这些才决定企业 AI 能否安全上线和持续治理.
8.2 2 分钟版本
我不会从 app + LLM + vector DB 这种图开始. 我会先问 stakeholder concerns: 业务 sponsor 关心价值和采用, CTO 关心平台复用和集成, solution architect 关心组件和运行, risk 关心 eval 和控制, audit 关心证据. 然后为这些 concern 设计 viewpoint catalog.
结构表达我用 C4. Context view 讲用户, 外部系统, AI platform 和供应商边界. Container view 展示 application, orchestration, model gateway, RAG service, tool gateway, policy engine, eval service, observability and evidence binder. Component view 展开 RAG entitlement, citation, no-answer, tool schema validation, approval router 等高风险组件. Code view 只用于 policy wrapper, redaction, tool validation, release gate 这些关键实现点.
文档表达我用 arc42. 它让我把目标, 约束, 上下文, building blocks, runtime, deployment, cross-cutting concepts, ADR, quality and risks 写完整. AI 特别需要把 eval 写成 release architecture, 把 observability 写成 evidence architecture, 把 human accountability 写成流程责任.
治理表达我用 ISO 42010. 每张 view 都要能回答某类 stakeholder concern, 并通过 correspondence rules 保持一致. 比如 container view 里有 RAG service, evidence view 里就必须有 retrieval trace 和 citation evidence. tool view 里有 refund draft tool, policy view 里就必须有 action tier, approval rule and action ledger.
8.3 AI Product / BA 版本
Q: 作为 PM / BA, 你为什么要关心 C4, arc42 和 42010?
A: 因为 AI 产品的风险不只在功能需求里, 还在系统边界, 数据流, 模型行为, 工具动作和上线证据里. PM / BA 如果只写 user story, 很容易漏掉 human accountability, eval gate, policy control and evidence. 我会用 42010 做 stakeholder-concern matrix, 用 C4 把系统边界和组件讲清楚, 用 arc42 把目标, 约束, runtime, quality, ADR 和风险写成可评审材料. 这能把 CBAP 的需求分析能力升级到 AI solution architecture 和 architecture communication.
Q: AI 产品需求和 AI 架构视图如何连接?
A: 每个高风险需求都应该映射到至少一个 architecture concern. 比如 "客服可生成退款说明" 对应 customer impact, tool action, approval, evidence. 它不能只写成一个功能, 还要在 tool view 中定义 action tier, 在 policy view 中定义审批阈值, 在 eval view 中测试错误承诺, 在 observability view 中记录 trace, 在 release memo 中明确 pilot 范围.
8.4 Enterprise / Solution Architect 版本
Q: 你如何避免 AI 架构图变成组件堆砌?
A: 我会先建立 viewpoint taxonomy. C4 只负责结构分层, 不强行承载所有 governance 信息. 对 AI-specific concerns, 我会单独建立 RAG view, model route view, tool action view, policy view, eval gate view, observability view and evidence view. 然后用 42010 correspondence rules 连接这些 views, 确保结构, 控制, 运行和证据一致.
Q: 什么时候 C4 不够用?
A: 当问题从 "系统由什么组成" 转到 "谁关心什么, 哪些控制有效, 哪些证据证明 release readiness" 时, C4 不够. 这时需要 arc42 组织架构叙事和 ADR, 需要 42010 管理 stakeholder concerns and viewpoints, 需要 eval / policy / evidence views 处理 AI 风险. C4 是结构骨架, 不是完整治理体系.
Q: 你如何在金融零售 AI 项目中设计 release gate?
A: 我会从 intended use 和 prohibited use 定义 eval contract. 对 customer-facing RAG, gate 包括 citation correctness, unsupported claim, stale policy, permission leakage, no-answer behavior, complaint escalation. 对 Agent tool action, gate 包括 tool selection, argument correctness, approval bypass, idempotency, action ledger. Gate 结果进入 release memo, 并映射到 production monitoring 和 evidence binder.
8.5 Portfolio Pitch
这个作品集不是展示一张漂亮 AI 架构图, 而是展示我能把金融零售 AI use case 变成可交付的 architecture view package. 我从 stakeholder concerns 出发, 用 C4 表达结构, 用 arc42 表达完整架构叙事, 用 ISO 42010 保证视图和证据可追溯. 在 Customer Service RAG / Agent 案例中, 我展示了业务能力, 人机责任, RAG 权限和引用, tool action 风险, eval release gate, observability trace and evidence binder. 这体现的是 AI Product, BA and Architecture 的组合能力, 而不是单纯会画图.
8.6 自检问题
- 是否先定义 stakeholder concerns, 再决定画哪些 views?
- C4 context 是否显示用户, 外部系统, AI platform, 供应商和数据边界?
- C4 container 是否包含 model gateway, RAG, tool gateway, policy, eval, observability and evidence?
- RAG view 是否说明 source owner, entitlement, freshness, citation and no-answer?
- Tool view 是否说明 action tier, schema validation, approval, idempotency and ledger?
- arc42 是否写清 goals, constraints, runtime, quality, ADR and risk?
- ISO 42010 matrix 是否连接 stakeholder, concern, viewpoint, view and evidence?
- Eval gate 是否连接 intended use, critical failures, release decision and production monitoring?
- Observability 是否能支持 debug, model risk, audit and incident replay?
- 作品集是否能面向 PM, BA, CTO, Architect, Risk and Audit 讲不同版本?
Final Principle
AI 架构沟通的成熟标志不是图有多少组件, 而是每个关键 stakeholder concern 都能被一个清晰 view 回答, 每个 view 都能连接到架构决策, 风险控制, release gate 和运行证据.
一句话总结:
C4 gives the structure, arc42 gives the story, ISO 42010 gives the stakeholder logic, and AI architecture maturity comes from connecting all three to model, RAG, tool, eval, policy, observability, evidence and human accountability.