AI 扩展计划 / Playbooks
AI Product Architecture Strategy Playbook
这些来源作为架构治理、AI 风险管理和管理体系的官方锚点。本文不是法律、合规、采购或审计意见；正式项目必须由 legal、compliance、risk、security、privacy、procurement、data owner 和 business owner 审查。
834 行AI_PRODUCT_ARCHITECTURE_STRATEGY_PLAYBOOK.md
AI Product Architecture Strategy Playbook
适用对象：AI PM、Product Architect、AI Architect、Enterprise Architect、AI 平台负责人、金融零售 AI 转型负责人。 核心问题：如何把分散的 AI use case、模型能力、数据资产、平台组件、治理要求和投资决策组织成一套可复用、可审计、可扩展的产品架构决策系统。 学习目标：不是学习 BA 基础需求分析，而是训练高级产品架构判断力：何时做平台，何时做 point solution，何时 build / buy / hybrid，何时 scale，何时 stop，以及如何用 executive memo 和 architecture artifacts 证明决策质量。 作品集定位：本文可直接转化为 AI 产品架构 portfolio evidence，包括 capability map、decision portfolio、architecture runway、funding gate、ARB pack、scale/stop rule、executive memo 和金融零售案例设计。
Source Anchors
这些来源作为架构治理、AI 风险管理和管理体系的官方锚点。本文不是法律、合规、采购或审计意见；正式项目必须由 legal、compliance、risk、security、privacy、procurement、data owner 和 business owner 审查。
| Anchor | Official / primary source | 在本 playbook 中的用法 |
|---|---|---|
| TOGAF Standard - Architecture Governance | https://pubs.opengroup.org/togaf-standard/architecture-governance/ | 用 architecture board、compliance review、governance repository、exception / dispensation 语言组织 AI 架构评审和决策责任 |
| TOGAF ADM | https://pubs.opengroup.org/togaf-standard/adm/ | 用 ADM 的迭代式架构开发思路组织 capability、target architecture、roadmap、migration planning 和 governance |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern、Map、Measure、Manage 组织 AI risk、eval、monitoring、control 和 operating model |
| NIST AI RMF Generative AI Profile | https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence | 用于 GenAI 特有风险：hallucination、data leakage、content provenance、harmful content、misuse、over-reliance、incident response |
| ISO/IEC 42001 | https://www.iso.org/standard/42001 | 用 AI management system 思路组织政策、责任、生命周期、风险、供应商、持续改进和管理评审 |
标准到作品集证据的映射：
| Source lens | 可以产出的 evidence | 面试时的表达 |
|---|---|---|
| TOGAF Architecture Governance | ARB charter、architecture compliance checklist、exception log、decision register | “我把 AI 架构决策纳入正式治理节奏，而不是让 PoC 自行绕过生产门禁。” |
| TOGAF ADM | capability roadmap、transition architecture、architecture runway、migration plan | “我用目标能力和过渡架构管理 AI 组合，而不是按项目临时堆功能。” |
| NIST AI RMF | risk tiering、control pack、eval gate、monitoring plan | “每个 AI capability 都有风险分类、可测门槛、上线控制和持续监控。” |
| NIST GenAI Profile | GenAI risk checklist、red-team backlog、incident taxonomy | “我把生成式 AI 的错误输出、引用、滥用、内容来源和过度信任当成产品架构问题处理。” |
| ISO/IEC 42001 | AI operating model、AI system inventory、management review pack | “我能把单个 AI 产品设计上升为企业 AI 管理体系的一部分。” |
1. 高级定位：Product Architecture 是决策系统
AI 产品架构不是一张系统图，也不是“选模型 + 接 API”。它是一个持续运行的决策系统，用来回答：
- 哪些业务能力值得 AI 化，哪些只需要流程、规则、数据质量或系统改造。
- 哪些能力应该沉淀为平台能力，哪些保持业务团队 point solution。
- 哪些组件应该 build、buy、partner 或 hybrid。
- 哪些模型、数据、工具、上下文、eval 和治理能力必须统一，哪些可以本地化。
- 哪些 use case 应该 scale，哪些应该停掉、降级、替代或合并。
- 如何把短期 pilot 转化为 architecture runway，而不是形成不可维护的 PoC 债务。
1.1 从“项目交付”升级到“架构决策”
| 普通项目视角 | 产品架构视角 | 高级问题 |
|---|---|---|
| 这个 AI 功能能不能 demo | 这个 AI capability 是否值得进入企业能力地图 | 它是否改变核心流程、风险责任和平台复用能力 |
| 选择哪个模型 | 模型策略如何支持多 use case、成本、延迟、风险和可替换性 | 需要 model gateway、routing、fallback、eval replay 吗 |
| 做一个知识库助手 | 企业知识架构如何管理 source of truth、权限、版本和引用 | 检索前授权、文档有效期、引用质量谁负责 |
| 做一个 agent | 工具权限、人工审批、事务一致性和 kill switch 如何设计 | agent 能 read、recommend、draft、act 到哪一步 |
| 上线一个 pilot | 组合级 funding gate 和 scale/stop rule 是否清晰 | 何时扩展，何时停止，何时抽象成平台 |
1.2 AI Product Architecture 的七类决策
| 决策域 | 关键决策 | 错误决策的代价 | 必备 artifact |
|---|---|---|---|
| Capability | 哪些业务能力进入 AI portfolio | 资源分散，低价值 demo 堆积 | Capability map、AI opportunity scorecard |
| Pattern | RAG、copilot、agent、workflow automation、fine-tuning、rules 的选择 | 过度自动化或用错技术形态 | AI pattern decision matrix、ADR |
| Platform | 平台化还是 point solution | 过早平台化或重复建设 | Platform boundary map、reuse thesis |
| Sourcing | Build、buy、partner、hybrid | 锁定供应商、成本失控、内部能力空心化 | Build/buy/hybrid memo、vendor architecture review |
| Risk | 风险等级、控制强度、人工监督 | 合规风险、客户伤害、审计失败 | Risk tier、control pack、HITL design |
| Roadmap | 架构 runway、投资节奏、迁移路径 | PoC 债务、无法规模化 | Architecture runway、transition roadmap |
| Portfolio | Scale、stop、merge、retire | 资源长期沉没在无效 AI 应用 | Decision portfolio、scale/stop rules |
2. Advanced Framework：PADS 决策系统
PADS = Product Architecture Decision System。它把 AI 产品从 idea 管到 portfolio review。
PADS loop
Capability intent
-> workflow and decision boundary
-> AI pattern selection
-> architecture decomposition
-> sourcing strategy
-> runway and roadmap
-> funding gate
-> pilot evidence
-> scale / stop / merge decision
-> platform reuse or retirement
2.1 PADS 七层框架
| Layer | 目标 | 核心输出 | 决策问题 |
|---|---|---|---|
| L1 Capability Strategy | 把业务战略转成能力投资主题 | AI capability map、value theme | 哪些能力值得 AI 化，为什么现在做 |
| L2 Workflow Architecture | 定义 AI 介入流程的位置和责任边界 | AS-IS / TO-BE workflow、decision boundary | AI 是读、找、总结、建议、草拟、执行还是决策 |
| L3 Solution Pattern | 选择 AI pattern 和系统边界 | Pattern ADR、C4 context/container | RAG、copilot、agent、rules、workflow automation 如何组合 |
| L4 AI Stack Decomposition | 拆解 model / data / tool / context / eval / governance | AI stack map、control points | 哪些组件可复用，哪些必须本地化 |
| L5 Sourcing and Platform | 决定 build / buy / hybrid 和平台边界 | Sourcing memo、platform capability map | 哪些买，哪些建，哪些必须由企业控制 |
| L6 Runway and Governance | 建立架构 runway、门禁和变更治理 | Roadmap、ARB pack、funding gates | 如何让 pilot 不变成孤岛 |
| L7 Portfolio Operations | 组合级 scale、stop、merge、retire | Decision portfolio、quarterly review pack | 哪些扩展，哪些停止，哪些沉淀为平台 |
2.2 决策原则
| Principle | 操作化解释 | 反例 |
|---|---|---|
| Architecture follows decision rights | 先确定 AI、人和系统的决策责任，再设计模型和流程 | 先做 agent，再补审批 |
| Platform only after repeatability evidence | 至少两个高价值 use case 证明相同能力可复用，再进入平台 backlog | 第一个 demo 就建大平台 |
| Eval is product contract | eval 不只是测试，是产品承诺、上线门禁和风险边界 | 上线靠主观体验 |
| Context is controlled infrastructure | 上下文不是 prompt 拼接，是权限、来源、版本、时效和证据链 | 把文档扔进向量库就算 RAG |
| Governance must be executable | 治理要体现在审批、日志、阈值、kill switch 和 release gate | 写政策但系统不可执行 |
| Reversibility is a design requirement | 关键 AI 决策必须有 rollback、fallback、exit 和 stop rule | 供应商或模型不可替换 |
3. Capability-to-Architecture Mapping
高级 AI 产品架构的起点不是用户故事，而是能力地图。能力地图回答“我们要增强哪类企业能力”，架构映射回答“这类能力需要哪些 AI 平台、数据、流程和控制”。
3.1 能力分层
| Capability layer | 金融零售例子 | AI 架构含义 | 投资判断 |
|---|---|---|---|
| Strategic capability | AML 风险识别、信贷决策支持、客户信任经营 | 需要长期平台能力、治理和审计 | 可进入多年 roadmap |
| Operational capability | KYC 审查、贷后监控、客服知识答复、支付异常处理 | 需要 workflow integration、HITL、case management | 适合 pilot 后规模化 |
| Analytical capability | 异常检测、客户分群、政策影响分析 | 需要数据平台、特征、模型监控 | 要确认数据 owner 和指标 |
| Experience capability | 客户-facing AI、员工 copilot、智能搜索 | 需要 UX trust、引用、拒答、handoff | 以 adoption 和 trust 为核心 |
| Control capability | eval、audit、risk tiering、policy guardrail | 需要平台化和强治理 | 优先沉淀为企业公用能力 |
3.2 Capability 到架构组件映射表
| AI capability | Workflow insertion point | Core architecture | Shared platform capability | Local domain capability | Review owner |
|---|---|---|---|---|---|
| AML investigation copilot | Case triage、evidence gathering、narrative draft | RAG + entity graph + case summarization + HITL | Model gateway、retrieval service、audit log、eval harness | AML taxonomy、red flags、SAR policy boundary | Financial crime, risk, architecture |
| KYC policy assistant | Analyst question answering、document checklist、policy comparison | Policy RAG + citation + versioned knowledge | Knowledge ingestion、permission filter、prompt registry | Jurisdiction policy、product rules、effective date | Compliance, operations |
| Credit copilot | Loan memo draft、policy citation、missing data check | RAG + rules + structured extraction + human approval | Tool gateway、eval、observability | Credit policy、risk appetite、exception reason codes | Credit risk, lending ops |
| Customer-facing AI | Customer answer, guided servicing, escalation | Conversational AI + retrieval + intent routing + guardrails | Model gateway、policy filters、conversation logs | Product terms、customer eligibility、tone policy | CX, legal, compliance |
| Payments operations agent | Exception detection、case routing、read-only investigation | Event stream + anomaly model + workflow agent | Tool gateway、idempotency control、kill switch | Rail rules、SLA、settlement calendar | Payments, ops risk |
3.3 Capability fit scorecard
| Dimension | 1 分 | 3 分 | 5 分 |
|---|---|---|---|
| Strategic relevance | 边缘效率需求 | 支持部门目标 | 支持企业级战略能力 |
| Workflow leverage | 独立小任务 | 改善一个流程节点 | 改变端到端流程表现 |
| Data and knowledge readiness | owner 不清 | 关键源可用但需治理 | source of truth、权限、版本清楚 |
| Risk controllability | 无法定义控制 | 可用 HITL 限制 | 风险边界、eval、monitoring 清楚 |
| Reuse potential | 单一团队 | 2 个相关场景可复用 | 多业务可复用平台能力 |
| Differentiation | 普通自动化 | 改善运营成本 | 形成客户、风控或运营优势 |
| Adoption likelihood | 用户不信任或无流程入口 | 有 pilot 用户 | 真实 workflow 中有明确使用节奏 |
评分解释：
- 28-35：进入 architecture runway 候选，要求 funding gate 和 ARB 审查。
- 20-27：适合受控 pilot，需明确 scale trigger。
- 12-19：先补数据、流程或 owner，不直接进入 AI build。
- 低于 12：停止或改用非 AI 改进方案。
4. AI-Native Workflow Design
AI-native workflow 不是把 chatbot 放进旧流程，而是重新设计“人、模型、规则、工具、数据和控制”的分工。
4.1 AI 介入等级
| Level | AI 角色 | 典型架构 | 适用场景 | 不适用场景 |
|---|---|---|---|---|
| L0 Inform | 检索、解释、引用 | RAG + citation | 政策查询、知识助手 | 需要执行动作 |
| L1 Draft | 草拟文本、摘要、表单预填 | RAG + template + human edit | 案件摘要、贷审 memo、客服回复草稿 | 输出直接影响客户权益且无复核 |
| L2 Recommend | 给出建议和理由 | Model + rules + scoring + HITL | AML 优先级、补件建议 | 法规禁止或责任无法划分 |
| L3 Act with approval | 生成动作，人工批准执行 | Agent + tool gateway + approval queue | 创建 case、发内部请求、更新低风险字段 | 高风险自动支付、自动拒贷 |
| L4 Act autonomously | 在边界内自动执行 | Agent + policy engine + monitoring + kill switch | 低风险、可逆、频繁、规则清晰动作 | 不可逆、客户影响大、审计要求高动作 |
4.2 Workflow architecture checklist
| 设计项 | 必须明确的问题 | Artifact |
|---|---|---|
| Decision boundary | 哪些决定由 AI 影响，哪些必须由人或规则系统决定 | Decision boundary map |
| Human role | 人是 reviewer、approver、coach、exception owner 还是 accountable decision maker | HITL design |
| Evidence path | AI 输出依据哪些来源，如何展示引用和置信信号 | Evidence and citation design |
| Exception path | AI 失败、拒答、低信心、工具失败时如何处理 | Exception workflow |
| Rework loop | 用户纠错如何进入 eval、知识更新或 prompt 改进 | Feedback-to-eval loop |
| Control point | 哪些节点需要 policy check、dual approval、logging、sampling | Control map |
| Operational ownership | 谁维护知识、eval、prompt、policy、tool permission、incident | RACI |
4.3 金融零售 AI-native workflow patterns
| Pattern | Before | AI-native design | 关键控制 |
|---|---|---|---|
| AML case preparation | Analyst 手工查多系统、复制证据、写 narrative | AI 汇总交易、实体、历史案例和 red flags，生成带引用的 narrative draft | SAR 决策保留给人，证据来源可追溯，敏感字段最小化 |
| KYC policy interpretation | Analyst 在多个 PDF 中搜索政策 | AI 按 jurisdiction、产品、客户类型检索有效政策并生成 checklist | 引用 effective date，过期政策拒用，合规 owner 审批内容 |
| Credit memo drafting | RM / underwriter 手工整理客户资料和政策条款 | AI 预填 memo、列出缺失材料、引用政策例外 | 不自动做 credit decision，不替代评分卡和审批 |
| Customer-facing servicing | 客服或客户自己搜索 FAQ | AI 根据客户身份、产品和授权范围回答，必要时升级人工 | 不承诺未授权豁免，不输出个性化金融建议，完整 conversation audit |
5. Platform vs Point Solution
平台不是目标，复用才是目标。point solution 不是低级，错误的平台化才危险。
5.1 决策矩阵
| 判断维度 | Point solution 倾向 | Platform 倾向 |
|---|---|---|
| Use case 重复性 | 单一流程、特殊规则多 | 多流程共享模型接入、检索、eval、审计 |
| 风险和控制 | 低风险、本地控制足够 | 高风险，需要统一 policy、audit、release gate |
| 数据和知识 | 专属小数据集 | 多团队共享知识源、权限和元数据标准 |
| 技术变化 | 快速探索，模式未稳定 | 模式已经被多个 use case 验证 |
| 组织能力 | 单团队可维护 | 需要平台 team、SRE、security、governance 支持 |
| 成本结构 | 小规模成本可接受 | 多团队重复成本明显 |
| 供应商依赖 | Vendor UI 已覆盖需求 | 需要统一 vendor abstraction 和 exit path |
5.2 平台化候选能力
| Capability | 何时平台化 | 不宜平台化的信号 |
|---|---|---|
| Model gateway | 多团队接入多个模型，需要 routing、quota、logs、fallback | 只有一个低风险 demo |
| Knowledge ingestion | 多业务使用文档、政策、产品资料，需要权限和版本 | 文档 owner 不清，source of truth 混乱 |
| Retrieval service | 多个 RAG 用例共享 chunking、metadata、rerank、citation | 每个 use case 的 retrieval 逻辑完全不同且未验证 |
| Tool gateway | AI 需要调用内部系统、读写动作、审批和审计 | 只有只读知识问答 |
| Eval harness | 多个 AI release 需要统一测试、阈值、报告 | 团队还没有稳定 failure taxonomy |
| Prompt/config registry | prompt、policy、guardrail 需要版本化、审批和回滚 | 仍处于个人实验阶段 |
| AI observability | 需要跨 use case 查看质量、成本、延迟、风险和 adoption | 没有生产流量 |
| Governance workflow | AI inventory、risk tier、release approval、exception 管理 | 组织没有 owner 承接 |
5.3 平台边界模板
| Boundary item | 平台负责 | 业务 use case 负责 | Governance owner |
|---|---|---|---|
| Model access | Approved model list、routing、quota、fallback、logging | 任务级模型选择理由、业务验收 | AI platform, security |
| Knowledge | Ingestion pipeline、metadata schema、permission filter | Source owner、内容质量、有效期 | Data governance, compliance |
| Prompt and policy | Registry、versioning、approval workflow、rollback | Domain prompt、policy rule、tone guide | Product, risk |
| Tools | Tool catalog、RBAC、audit、approval hooks | Tool use case、业务动作、异常处理 | Architecture, system owner |
| Eval | Runner、report format、release gate workflow | Gold set、rubric、failure taxonomy | EvalOps, business owner |
| Observability | Trace、metric、cost、incident dashboard | Threshold、business KPI、triage | Platform ops, product ops |
6. Build / Buy / Hybrid Strategy
AI product architecture 的 sourcing 决策不能只看速度。金融零售场景必须同时看差异化、控制权、审计、数据边界、供应商锁定、成本曲线和退出能力。
6.1 选项定义
| Option | Definition | 适合 | 主要风险 |
|---|---|---|---|
| Buy | 购买 SaaS、vendor product 或 managed platform | 通用流程、成熟产品、快速落地 | 锁定、黑盒、合同和审计不足 |
| Build | 内部构建核心能力 | 差异化能力、强控制、规模经济 | 交付风险、运营成本、人才要求 |
| Partner | 与 vendor、SI、咨询或 domain expert 共建 | 缺少领域实施能力或加速交付 | 依赖外部、知识转移不足 |
| Hybrid | 买通用能力，建控制层和差异化层 | 金融零售大多数高价值场景 | 边界复杂，需要强架构治理 |
6.2 Component-level sourcing matrix
| Component | Buy 倾向 | Build 倾向 | Hybrid 推荐 |
|---|---|---|---|
| Foundation model | 使用主流模型 API 或托管模型 | 极少数有专有数据和训练能力的企业 | 通过 model gateway 抽象供应商 |
| Embedding / reranker | 通用质量足够 | 特定语言、文档结构或召回要求高 | 托管模型 + 内部 eval 选择 |
| Vector DB / search | 托管服务满足数据边界 | 严格数据驻留和成本控制 | 托管 infra + 内部权限和 retention policy |
| Knowledge ingestion | Vendor connectors 覆盖 | 企业文档复杂、权限细、版本多 | 买 connector，建 metadata 和 governance |
| Agent runtime | 低风险内部自动化 | 高风险动作、复杂事务和审批 | 买 runtime，建 tool gateway 和 approval layer |
| Eval tooling | 通用 test management 和 dashboard | 领域 gold set、rubric、release policy | 买 runner，建领域 eval 和 gate |
| Policy guardrails | 通用内容安全 | 金融政策、合规边界、客户权益 | 通用 guardrail + 内部 policy engine |
| Audit evidence | Vendor 能导出完整 evidence | 审计链必须跨系统重建 | Vendor logs 汇入内部 evidence binder |
6.3 Build / Buy / Hybrid memo 模板
# AI Sourcing Decision Memo
## Decision
Recommend: Hybrid
Scope: Buy model access and extraction accelerators; build governance, eval, tool permission and audit evidence layer.
## Business capability
- Target capability:
- Workflow affected:
- Business outcome:
- Risk tier:
## Options compared
| Option | Delivery speed | Control | Cost curve | Auditability | Exit ability | Recommendation |
|---|---:|---:|---:|---:|---:|---|
| Buy | 5 | 2 | 3 | 2 | 2 | Not enough control for regulated workflow |
| Build | 2 | 5 | 3 | 5 | 5 | Too slow for first pilot |
| Hybrid | 4 | 4 | 4 | 4 | 4 | Best balance |
## Architecture implication
- Vendor-controlled components:
- Enterprise-controlled components:
- Data boundary:
- Model upgrade policy:
- Exit trigger:
## Funding request
- Gate requested:
- Evidence already available:
- Evidence required before scale:
- Stop rule:
7. Model / Data / Tool / Context / Eval / Governance Decomposition
高级架构评审必须拆解 AI 系统，而不是把它当成一个“智能黑盒”。
7.1 Decomposition map
| Layer | 架构问题 | 设计产物 | 常见失败 |
|---|---|---|---|
| Model | 哪些模型可用，如何 routing、fallback、升级、回滚 | Model strategy、model gateway ADR | 模型版本静默变化，质量不可复现 |
| Data | 哪些数据进入 prompt、index、logs、eval、analytics | Data flow、classification、retention | PII 泄露，数据 owner 不清 |
| Tool | AI 能调用哪些系统和动作 | Tool catalog、RBAC、approval policy | Excessive agency，越权写入 |
| Context | 上下文来源、权限、时效、引用、压缩策略 | Context architecture、retrieval design | 幻觉、过期政策、引用错误 |
| Eval | 如何证明质量、风险和业务效果 | Eval matrix、gold set、release gate | demo 好看但生产失败 |
| Governance | 谁审批、谁监控、谁处理例外、谁承担残余风险 | ARB pack、RACI、exception log | 治理停留在文档 |
7.2 AI stack decision register
| Decision ID | Layer | Decision | Options considered | Evidence | Owner | Review trigger |
|---|---|---|---|---|---|---|
| ADR-AI-001 | Model | Use model gateway with approved model allowlist | Direct vendor API, single cloud model, gateway | Cost, audit, routing and fallback needs | AI architect | New model class or risk tier change |
| ADR-AI-002 | Context | Retrieval must enforce permission before generation | Post-generation filter, pre-retrieval ACL, separate index | Data leakage risk | Data architect | New corpus or entitlement model |
| ADR-AI-003 | Tool | Write actions require approval queue | Direct tool call, approval, read-only | Customer and financial impact | Product architect | Expansion to new action type |
| ADR-AI-004 | Eval | Release blocked by critical failure class | Manual review, offline eval, production sampling | Regulated output risk | EvalOps lead | Prompt/model/policy update |
| ADR-AI-005 | Governance | High-risk use cases require ARB signoff | Product approval only, ARB, committee | Enterprise risk | Enterprise architect | Gate 3 and Gate 5 |
7.3 Control design by layer
| Layer | Preventive control | Detective control | Corrective control |
|---|---|---|---|
| Model | Approved model list、routing rule、temperature policy | Model drift metric、quality trend、latency/cost alerts | Rollback、fallback、model freeze |
| Data | Data minimization、redaction、access control | Data leakage scan、log review、source freshness monitor | Delete/reindex、source quarantine、permission fix |
| Tool | RBAC、scope-limited tokens、approval gate | Tool call anomaly detection、audit sampling | Kill switch、credential rotation、action reversal |
| Context | Metadata filter、effective date、citation requirement | Citation accuracy eval、retrieval miss analysis | Rechunking、rerank tuning、source correction |
| Eval | Required gold set、failure taxonomy、release threshold | Production sampling、human override analysis | Regression fix、release block、prompt rollback |
| Governance | Risk tiering、ARB approval、exception expiry | Quarterly review、exception aging report | Retire、scope reduction、risk re-acceptance |
8. Architecture Runway and Roadmap Governance
Architecture runway 是未来多个 AI use case 可以复用的技术、数据、治理和运营基础。没有 runway，AI portfolio 会变成一堆无法规模化的 demo。
8.1 Runway 类型
| Runway | 解决的问题 | 代表能力 | 触发条件 |
|---|---|---|---|
| Technical runway | AI 应用重复建设基础设施 | Model gateway、retrieval service、tool gateway、observability | 2 个以上 use case 重复搭建 |
| Data runway | 知识和数据不可用、不可信、不可授权 | Source inventory、metadata、data quality、lineage | AI 输出依赖多个核心源 |
| Eval runway | 上线没有统一质量证据 | Eval harness、gold set library、failure taxonomy | 多个 AI release 需要门禁 |
| Governance runway | 风险和审批不可执行 | AI inventory、risk tier、ARB、exception workflow | 高风险 use case 增多 |
| Adoption runway | 做完没人用或使用不可证明 | Training、workflow integration、adoption analytics | Pilot 价值依赖用户行为改变 |
8.2 12 个月 roadmap governance 模板
| Quarter | Product theme | Architecture runway | Use case delivery | Governance gate | Evidence |
|---|---|---|---|---|---|
| Q1 | Prove high-value workflow | Model gateway MVP、eval report format、AI inventory | AML copilot pilot、KYC assistant pilot | G0-G4 | Opportunity score、ADR、data readiness |
| Q2 | Controlled production | Retrieval permission filter、prompt registry、audit log | AML limited release、credit copilot pilot | G5-G7 | Eval report、HITL metrics、incident runbook |
| Q3 | Reuse and platformization | Tool gateway、central observability、gold set library | Customer-facing AI controlled rollout | G8 | Adoption dashboard、cost per task、risk review |
| Q4 | Portfolio optimization | Scale/stop engine、exception management、quarterly ARB | Expand winners、retire weak pilots | Quarterly review | Decision portfolio、ROI and risk-adjusted funding |
8.3 Roadmap governance rules
| Rule | Why it matters | Evidence |
|---|---|---|
| 每个 use case 必须绑定一个 capability | 避免零散 demo | Capability map |
| 每个 pilot 必须声明 platform reuse hypothesis | 让试点产生架构学习 | Reuse thesis |
| 每个 release 必须有 eval 和 rollback | 防止不可控上线 | Eval report、rollback plan |
| 每个季度必须做 portfolio review | 停止低价值项目，释放资源 | Decision portfolio |
| 每个 exception 必须有 expiry | 防止临时豁免永久化 | Exception log |
9. Decision Portfolio
AI portfolio 不是项目清单，而是决策组合。每个条目都应说明：为什么投、投到哪一阶段、风险如何控制、何时扩展、何时停止。
9.1 Portfolio board
| Use case | Capability | Pattern | Stage | Sourcing | Risk tier | Reuse potential | Funding status | Next decision |
|---|---|---|---|---|---|---|---|---|
| AML investigation copilot | Financial crime operations | RAG + copilot + HITL | Limited production | Hybrid | High | High | Fund scale readiness | Scale after critical failure = 0 for 2 cycles |
| KYC policy assistant | Compliance operations | Policy RAG | Pilot | Buy + internal governance | Medium | Medium | Fund controlled pilot | Expand jurisdictions if citation accuracy passes |
| Credit copilot | Lending operations | RAG + rules + draft | Discovery | Hybrid | High | Medium | Fund architecture discovery | Proceed only after data owner and policy eval |
| Customer-facing AI | Customer experience | Conversational AI + guardrails | Discovery | Buy + platform controls | High | High | Fund risk design only | Pilot after legal-approved answer boundaries |
| Payments ops agent | Payments operations | Event + workflow agent | Parked | Build control layer | High | Medium | Hold | Revisit after tool gateway runway |
9.2 Scale / stop rules
| Decision | Trigger | Evidence required | Action |
|---|---|---|---|
| Scale | Business value proven, critical risk controlled, adoption stable | Eval pass, no critical incidents, usage in target workflow, cost per task acceptable | Expand users, integrate deeper, fund platform reuse |
| Hold | Value plausible but evidence incomplete | Mixed eval, weak adoption, unresolved data issue | Limit scope, run targeted fix, re-review in next gate |
| Merge | Multiple use cases share same platform need | Duplicate model/RAG/eval/tool components | Combine into platform backlog |
| Reduce scope | Risk or cost too high for current automation level | High override rate, expensive tool calls, low trust | Move from recommend/act to inform/draft |
| Stop | No measurable workflow value or unacceptable residual risk | Low adoption, poor eval, no owner, risk rejection | Retire pilot, archive evidence, release budget |
| Retire | Production capability no longer meets quality, policy or cost threshold | Drift, stale knowledge, vendor issue, low usage | Sunset, migrate users, update portfolio |
9.3 Funding gates
| Gate | Funding decision | Required evidence | Budget type |
|---|---|---|---|
| Gate 0 Intake | Fund discovery or reject | Capability fit score、owner、initial risk tier | Small discovery budget |
| Gate 1 Architecture | Fund prototype / vendor eval | Workflow design、pattern ADR、data readiness | Timeboxed architecture and eval budget |
| Gate 2 Pilot | Fund controlled pilot | Control pack、eval plan、pilot success metric | Pilot budget with stop rule |
| Gate 3 Production | Fund production hardening | Eval report、security/risk signoff、runbook、RACI | Production engineering and ops budget |
| Gate 4 Scale | Fund expansion and platformization | Adoption dashboard、ROI、risk trend、reuse evidence | Scaling and platform runway budget |
| Gate 5 Optimize | Continue, merge, retire | Quarterly review pack | Portfolio budget reallocation |
10. Architecture Review Board for AI
AI ARB 不应变成“审批委员会”。它的价值是让复杂决策有清晰证据、责任和例外管理。
10.1 AI ARB charter
| Area | Charter |
|---|---|
| Scope | 高风险 AI use case、平台能力、供应商架构、模型策略、工具调用、客户-facing AI、重大变更 |
| Decision rights | Approve、approve with conditions、reject、request redesign、grant time-limited exception |
| Required attendees | Enterprise architect、AI architect、product owner、security、privacy、risk、compliance、data owner、platform owner、business sponsor |
| Artifacts reviewed | Capability map、ADR、data flow、risk tier、eval plan/report、control pack、runbook、sourcing memo |
| Cadence | Discovery gate、architecture gate、release gate、scale gate、quarterly portfolio review |
| Output | Decision record、conditions、owner、due date、exception expiry、next review trigger |
10.2 ARB submission pack template
# AI Architecture Review Pack
## 1. Decision requested
- Approve architecture direction / pilot / production release / scale / exception
## 2. Capability and business context
- Capability:
- Workflow:
- Users:
- Value metric:
- Risk tier:
## 3. Architecture summary
- Pattern:
- Model strategy:
- Data and context sources:
- Tools and actions:
- Human oversight:
- Platform dependencies:
## 4. Key decisions
| Decision | Options | Recommendation | Evidence | Residual risk |
|---|---|---|---|---|
## 5. Controls and eval
- Preventive controls:
- Detective controls:
- Corrective controls:
- Eval threshold:
- Critical failure classes:
## 6. Operating model
- Product owner:
- Data owner:
- Eval owner:
- Incident owner:
- Risk owner:
## 7. Decision log
- Approved / conditional / rejected:
- Conditions:
- Exception expiry:
- Next review:
10.3 AI architecture compliance checklist
| Checklist item | Pass criteria |
|---|---|
| Capability fit | Use case maps to approved capability theme and has owner |
| Decision boundary | AI role and human accountability are explicit |
| Data boundary | Prompt、index、logs、eval、analytics data flows documented |
| Permission | Retrieval and tool access enforce user/use-case entitlement |
| Eval | Offline eval and production monitoring cover critical failures |
| Governance | Risk tier、approval、exception and rollback are documented |
| Sourcing | Vendor/internal boundaries and exit triggers are clear |
| Observability | Quality、cost、latency、adoption、incident metrics are defined |
| Runbook | Incident, kill switch, fallback and owner escalation exist |
| Portfolio | Scale/stop rule and funding gate are defined |
11. Financial Retail Cases
11.1 AML platform
| Dimension | Architecture decision |
|---|---|
| Product intent | 提升 investigator 的证据收集、case narrative 和 red flag 一致性，不自动决定 SAR filing |
| AI pattern | RAG + entity graph + summarization + workflow copilot |
| Platform capability | Model gateway、audit evidence、entity resolution、case trace、eval harness |
| Local domain asset | AML typology、red flag library、SAR narrative standard、case disposition codes |
| Build/buy/hybrid | Hybrid：买通用 extraction / summarization 能力，内部控制 audit、HITL、policy boundary 和 case workflow |
| Eval focus | Evidence completeness、citation accuracy、false narrative、missed red flag、overstatement |
| Scale rule | 两个 review cycle 无 critical factual error，case prep time 降低，analyst trust 稳定 |
| Stop rule | AI narrative 引入高风险错误、用户绕过人工判断、审计链无法重建 |
AML portfolio artifact：
| Artifact | 证明什么 |
|---|---|
| AML capability map | 能把 financial crime operations 分解成可投资能力 |
| AML AI decision boundary | 能说明 AI 不替代合规判断 |
| AML eval matrix | 能把监管风险转成可测 failure classes |
| AML audit evidence pack | 能重建输入、检索、模型、输出、人工审批和最终动作 |
11.2 KYC policy assistant
| Dimension | Architecture decision |
|---|---|
| Product intent | 让 KYC analyst 快速解释政策、生成补件 checklist、比较 jurisdiction 差异 |
| AI pattern | Policy RAG + citation + effective-date filter + answer boundary |
| Platform capability | Knowledge ingestion、metadata schema、permission filter、prompt registry |
| Local domain asset | KYC policy hierarchy、jurisdiction、customer type、product eligibility |
| Build/buy/hybrid | Buy + internal governance：买知识助手能力，内部管理政策版本、引用标准和合规审批 |
| Eval focus | Citation correctness、policy freshness、jurisdiction match、refusal on unknown policy |
| Scale rule | Citation accuracy 达标，policy owner 更新流程稳定，analyst adoption 高 |
| Stop rule | 引用过期政策、跨 jurisdiction 混答、无法证明有效版本 |
11.3 Credit copilot
| Dimension | Architecture decision |
|---|---|
| Product intent | 支持 RM、underwriter 和 credit officer 准备贷款 memo、政策引用和补件建议 |
| AI pattern | RAG + rules + structured extraction + controlled draft |
| Platform capability | Tool gateway、document processing、eval runner、approval queue |
| Local domain asset | Credit policy、risk appetite、评分卡边界、例外审批规则 |
| Build/buy/hybrid | Hybrid：买 OCR/extraction，内部构建 credit policy control、decision boundary 和 audit |
| Eval focus | Missing document detection、policy citation、unfair bias signal、unsupported recommendation |
| Scale rule | Memo prep cycle time 下降，policy citation 准确，审批人 override reason 可学习 |
| Stop rule | AI 暗示最终 credit decision，输出偏见风险不可控，用户过度信任 |
11.4 Customer-facing AI
| Dimension | Architecture decision |
|---|---|
| Product intent | 提供合规、可引用、可升级人工的客户服务，不替代受监管建议或客户权益决定 |
| AI pattern | Conversational AI + retrieval + intent routing + guardrails + human handoff |
| Platform capability | Model gateway、conversation audit、policy filters、PII redaction、handoff integration |
| Local domain asset | 产品条款、客户资格、费用政策、投诉处理话术 |
| Build/buy/hybrid | Buy + platform controls：买成熟对话能力，内部控制知识、合规边界、审计和升级路径 |
| Eval focus | Unauthorized promise、wrong fee/term、privacy leak、failure to escalate、tone and clarity |
| Scale rule | Escalation quality、containment with safety、complaint trend、customer trust 达标 |
| Stop rule | 造成客户误导、输出未授权承诺、投诉或合规事件上升 |
12. Executive Memo Language
高级产品架构师必须能把复杂架构决策翻译成 executive language：价值、风险、选择、证据、资金和责任。
12.1 Executive framing
| 技术表达 | Executive memo 表达 |
|---|---|
| 我们要建 model gateway | 我们需要统一模型接入和审计控制，否则每个 AI 项目会形成不可见成本、不可追溯输出和供应商锁定 |
| 我们要做 RAG | 我们要让 AI 回答绑定到批准的知识源、权限和有效版本，而不是让模型凭记忆回答 |
| 我们需要 eval | 我们需要把 AI 质量从主观体验变成上线前门禁和上线后风险指标 |
| 我们要 tool gateway | 在 AI 调用内部系统前，需要统一权限、审批、审计和 kill switch |
| 我们建议 hybrid | 速度来自采购成熟组件，控制权保留在数据、政策、eval、审计和高风险动作层 |
12.2 One-page executive memo template
# Executive Decision Memo: AI Product Architecture
## Recommendation
Approve a controlled hybrid architecture for [capability], funding Gate [x] with explicit scale/stop rules.
## Why now
- Business pressure:
- Operational pain:
- Risk of inaction:
- Strategic capability built:
## Options
| Option | Value | Risk | Time | Control | Recommendation |
|---|---|---|---|---|---|
## Architecture decision
- AI pattern:
- Platform capabilities reused:
- Components bought:
- Components built:
- Human decision boundary:
- Data and audit boundary:
## Evidence
- Baseline:
- Eval result:
- Pilot/adoption evidence:
- Risk review:
- Cost model:
## Funding gate
- Approved spend:
- Gate duration:
- Required evidence before next funding:
- Stop rule:
## Executive ask
- Decision requested:
- Named accountable owner:
- Next review date:
12.3 典型 executive decision statements
| Situation | 可直接使用的 statement |
|---|---|
| 过早平台化 | “We should not fund a broad AI platform until two or more priority workflows prove repeatable requirements for model access, retrieval, eval and audit.” |
| 供应商方案过黑盒 | “The vendor can accelerate the user workflow, but production approval requires enterprise-controlled audit, eval, data retention and exit rights.” |
| 高风险自动化 | “This workflow can use AI to prepare and recommend, but accountable decisions remain with trained staff until eval and oversight evidence justify further automation.” |
| 需要停掉 pilot | “The pilot produced learning value but not enough workflow value or risk control to justify scaling; funding should move to the shared retrieval and eval runway.” |
| 需要 architecture runway | “The bottleneck is no longer model access; it is reusable context, eval, tool permission and operating controls across multiple AI use cases.” |
13. Portfolio Artifacts
这些 artifact 可以直接作为求职作品集、内部评审材料或面试讲解素材。
13.1 Artifact map
| Artifact | 目标读者 | 证明的高级能力 | 最小内容 |
|---|---|---|---|
| AI Capability Map | Executive, EA, Product | 能把业务战略转成 AI 投资主题 | Capability、value、workflow、risk、reuse |
| AI Pattern ADR Set | Architect, PM, Risk | 能做架构取舍并记录证据 | Options、decision、evidence、risk、reversal trigger |
| Platform Boundary Map | Platform, business teams | 能控制平台化边界 | Shared vs local responsibility |
| Build/Buy/Hybrid Memo | Executive, procurement | 能做 sourcing strategy | Options、cost、control、lock-in、exit |
| Architecture Runway Roadmap | EA, engineering, sponsor | 能把 pilot 变成可复用能力 | Quarter、runway、use case、gate、evidence |
| Decision Portfolio Board | Executive, PMO | 能做组合管理 | Stage、funding、risk、scale/stop |
| AI ARB Pack | Architecture board | 能组织正式评审 | Decision request、architecture、controls、owners |
| Scale/Stop Rule Sheet | Sponsor, product ops | 能防止沉没成本 | Trigger、evidence、action |
| Executive Memo | Senior leadership | 能用高管语言表达架构决策 | Recommendation、why now、options、funding |
13.2 Portfolio evidence narrative
# Portfolio Story: AI Product Architecture Strategy
## Situation
Financial retail organization had multiple AI PoCs in AML, KYC, credit and customer service, but no consistent architecture runway, eval gate, governance or sourcing strategy.
## Task
Create a portfolio-level AI product architecture strategy that identifies reusable platform capabilities, defines build/buy/hybrid boundaries and establishes funding gates.
## Actions
- Built capability-to-architecture map across four regulated workflows.
- Defined model/data/tool/context/eval/governance decomposition.
- Created ARB submission pack and scale/stop rules.
- Recommended hybrid sourcing for high-risk workflows.
- Converted pilot evidence into architecture runway roadmap.
## Result
- Reduced duplicated AI infrastructure decisions.
- Created clear production gates for high-risk AI.
- Identified shared platform investments: model gateway, retrieval, eval, audit and tool gateway.
- Established executive funding language for scale, hold and stop decisions.
## Artifacts
- Capability map
- Architecture runway
- Decision portfolio
- Build/buy/hybrid memo
- ARB pack
- Executive memo
14. 30-Day Lab
目标：用 30 天产出一套可展示的 AI Product Architecture Strategy portfolio。每天不做基础 BA 练习，只做高级决策资产。
| Day | Focus | Output |
|---|---|---|
| 1 | 选择金融零售企业背景和 4 个 AI use case | Portfolio scenario brief |
| 2 | 定义企业 AI capability themes | AI capability map v1 |
| 3 | 为 AML、KYC、credit、customer AI 评分 | Capability fit scorecard |
| 4 | 设计每个 use case 的 workflow insertion point | Decision boundary map |
| 5 | 选择 AI pattern：RAG、copilot、agent、rules、workflow | Pattern decision matrix |
| 6 | 拆解 model/data/tool/context/eval/governance | AI stack decomposition |
| 7 | 产出 3 个关键 ADR | ADR set v1 |
| 8 | 设计 platform vs point solution boundary | Platform boundary map |
| 9 | 定义 reusable platform capabilities | Platform capability backlog |
| 10 | 做 build/buy/hybrid matrix | Sourcing strategy table |
| 11 | 为 AML 写 sourcing memo | AML build/buy/hybrid memo |
| 12 | 为 KYC 写 policy RAG architecture | KYC architecture one-pager |
| 13 | 为 credit copilot 写 risk boundary | Credit decision boundary memo |
| 14 | 为 customer-facing AI 写 guardrail design | Customer AI control map |
| 15 | 定义 eval failure taxonomy | Eval taxonomy and thresholds |
| 16 | 设计 ARB charter | AI ARB charter |
| 17 | 完成 ARB submission pack | ARB pack v1 |
| 18 | 定义 funding gates | Funding gate model |
| 19 | 写 scale/stop rules | Scale/stop rule sheet |
| 20 | 建立 12 个月 architecture runway | Roadmap v1 |
| 21 | 建 decision portfolio board | Portfolio board |
| 22 | 设计 operating model RACI | AI product architecture RACI |
| 23 | 设计 executive dashboard metrics | Portfolio metrics |
| 24 | 写 executive memo | One-page executive memo |
| 25 | 做 quarterly review pack | Quarterly AI review pack |
| 26 | 进行自我红队：找出平台化过度点 | Red-team notes |
| 27 | 进行自我红队：找出供应商锁定点 | Lock-in and exit analysis |
| 28 | 进行自我红队：找出治理不可执行点 | Governance execution gaps |
| 29 | 整理 portfolio narrative | Portfolio story |
| 30 | 准备面试讲解脚本 | 10-minute architecture strategy pitch |
30-day acceptance criteria
| Evidence | Done standard |
|---|---|
| Capability map | 至少 4 个 use case 映射到 capability、risk、reuse、value |
| ADR set | 至少 5 个关键架构决策，有 options、evidence、risk、trigger |
| Platform boundary | 清楚区分 shared platform 和 local domain responsibility |
| Sourcing memo | 至少一个高风险 use case 有 build/buy/hybrid 推荐 |
| ARB pack | 能支持 approve / conditional / reject 决策 |
| Roadmap | 包含 runway、use case、gate、evidence、quarterly review |
| Executive memo | 一页内说清 recommendation、why now、funding gate、stop rule |
15. Interview Answers
Q1：AI Product Architect 和 AI PM 的区别是什么？
30 秒回答：
AI PM 主要对用户价值、产品范围、adoption 和业务结果负责；AI Product Architect 进一步负责把多个 AI use case 组织成可复用、可治理、可演进的产品架构决策系统。它不仅问“做什么功能”，还问“哪些能力平台化，哪些本地化，如何 build/buy/hybrid，如何定义架构 runway、eval gate、风险控制和 scale/stop 规则”。
2 分钟回答：
在金融零售企业里，一个 AI PM 可以成功交付 KYC assistant 或 AML copilot，但如果每个团队都单独接模型、做 RAG、建 eval、写审计日志，企业会形成 PoC 债务。AI Product Architect 的价值是把单个产品判断上升到 portfolio 和 architecture runway：统一 model gateway、knowledge ingestion、eval harness、tool permission、audit evidence，同时保留 AML、credit、KYC 的领域差异。这个角色需要同时懂产品策略、架构治理、供应商策略、风险控制和高管沟通。
Q2：什么时候应该做 AI 平台，什么时候只做 point solution？
30 秒回答：
当多个高价值 use case 反复需要相同能力，比如模型接入、RAG、eval、审计、tool permission 和 observability，就应该平台化；当 workflow 独特、风险低、模式未验证时，先用 point solution 学习，不要过早建平台。
2 分钟回答：
我的判断标准是 repeatability evidence。第一个 AI demo 不足以证明平台需求。至少要看到两个或更多优先 workflow 共享相同架构痛点，例如每个团队都要权限过滤的检索、prompt 版本控制、release eval 和审计证据。此时平台化能降低重复成本并提升治理一致性。但业务领域规则、政策解释、failure taxonomy 和用户体验通常仍由本地 use case owner 负责。平台负责横向能力，业务负责领域语义和价值结果。
Q3：Build、buy、hybrid 怎么决策？
30 秒回答：
我按组件而不是按整个系统决策。通用模型、OCR、基础对话能力可以 buy；差异化流程、政策边界、eval gold set、审计、tool permission 和高风险决策控制通常要 build 或企业控制。金融零售高价值场景多数是 hybrid。
2 分钟回答：
整包 buy 的风险是 vendor 黑盒、数据和审计不足、退出困难；全 build 的风险是速度慢、运营成本高。更实用的是 hybrid：采购成熟组件加速，如模型、提取、对话 UI 或基础检索；内部构建控制层，如 model gateway、policy guardrail、eval gate、audit evidence、tool approval 和 exit abstraction。AML copilot 就是典型 hybrid：可以买 summarization 和 extraction，但 SAR 决策边界、证据链、人工复核和审计必须由企业控制。
Q4：如何把 AI pilot 转成 architecture runway？
30 秒回答：
每个 pilot 一开始就要声明 reuse hypothesis：它会验证哪些未来可复用能力。pilot 结束不只看业务效果，也要提炼平台 backlog、ADR、eval 模板、control pattern 和 roadmapping evidence。
2 分钟回答：
我会在 pilot gate 要求三类证据：业务证据、风险证据、复用证据。业务证据证明 workflow value；风险证据证明 eval、HITL、audit 和 incident path 可控；复用证据证明哪些能力可抽象为平台，例如 retrieval permission、prompt registry、tool gateway 或 eval runner。如果 pilot 价值一般但发现了关键平台瓶颈，可能不 scale use case，但仍投资 architecture runway。这样避免把失败 pilot 当成纯浪费。
Q5：AI 架构评审委员会应该看什么？
30 秒回答：
AI ARB 不应只看系统图，而要看 decision boundary、data flow、model strategy、context design、tool permission、eval threshold、risk controls、rollback、owner 和 scale/stop rule。
2 分钟回答：
传统架构评审关注服务、API、数据库和部署。AI ARB 还要关注模型输出如何影响业务决定，检索是否按权限过滤，工具调用是否越权，prompt/model/knowledge 变更是否回归测试，高风险输出是否人工复核，线上质量和成本如何监控。评审输出应该是 approve、conditional approve、reject 或 time-limited exception，并记录 owner、条件、到期日和下次触发点。
Q6：如何向高管解释为什么需要 model gateway 和 eval harness？
30 秒回答：
我不会从技术组件讲起。我会说：model gateway 是控制模型成本、审计、权限、fallback 和供应商替换的企业控制面；eval harness 是把 AI 质量从主观体验变成上线门禁和持续风险指标。
2 分钟回答：
如果每个团队直接接不同模型，企业无法回答哪些数据发给了谁、哪个模型产生了哪个输出、成本归属在哪里、模型升级后是否破坏业务质量。model gateway 解决的是控制权和可替换性。eval harness 解决的是证据问题：它让我们知道模型、prompt、知识和政策变更是否引入关键错误。高管不需要听 token 和 embedding 细节，但需要知道这些能力直接降低生产风险、审计风险、供应商锁定和无效扩张。
Q7：客户-facing AI 的 scale rule 怎么定义？
30 秒回答：
客户-facing AI 不能只看 containment 或调用量。scale rule 必须同时看正确性、授权边界、升级质量、投诉趋势、隐私事件、客户信任和成本。
2 分钟回答：
我会把客户-facing AI 的 scale rule 分成四类：第一，质量，关键问题的正确率和引用准确性达标；第二，安全，不产生未授权承诺、个性化金融建议或隐私泄露；第三，运营，handoff 到人工时上下文完整且不增加投诉；第四，经济性，cost per resolved case 合理。只要出现客户误导、合规事件、投诉上升或无法审计，就应该 hold 或 rollback，而不是因为 deflection rate 高就继续扩张。
Q8：如何证明你具备 Enterprise Architect 级别的 AI 产品判断？
30 秒回答：
我会展示不止一个 PRD，而是一组组合级 artifacts：AI capability map、architecture runway、decision portfolio、build/buy/hybrid memo、ARB pack、scale/stop rule 和 executive memo。它们证明我能从单点功能上升到企业能力、治理、投资和演进。
2 分钟回答：
Enterprise Architect 级别的判断体现在三点：第一，能把业务战略转成 capability 和 target architecture，而不是从功能列表出发；第二，能治理多个 AI use case 的共性和差异，明确平台能力、本地领域能力和供应商边界；第三，能管理生命周期，包括 funding gate、architecture review、risk exception、scale/stop 和 retirement。我的 portfolio 会围绕 AML、KYC、credit 和 customer AI 四个金融零售案例，展示如何建立可复用架构 runway 和决策组合。
16. Final Checklist
| Area | 高级检查问题 |
|---|---|
| Capability | 是否能解释这个 AI use case 属于哪个企业能力，为什么值得投资 |
| Workflow | 是否明确 AI 的角色是 inform、draft、recommend、act with approval 还是 autonomous act |
| Architecture | 是否拆解 model、data、tool、context、eval、governance |
| Platform | 是否有平台化证据，而不是凭直觉建平台 |
| Sourcing | 是否按组件做 build/buy/hybrid 决策 |
| Runway | 是否能从 pilot 提炼 reusable capability |
| Governance | 是否有 ARB、funding gate、exception、rollback 和 owner |
| Portfolio | 是否有 scale、hold、merge、stop、retire 决策规则 |
| Executive language | 是否能把技术架构翻译成价值、风险、控制、资金和责任 |
| Portfolio evidence | 是否能把上述产物打包成面试和求职作品集 |
一句话总结：
AI Product Architecture Strategy 的核心不是“让 AI 做更多事”，而是让企业知道哪些 AI 能力值得投资、如何被安全复用、何时扩张、何时停止，以及每个决策背后的证据和责任。