AI Case Drill Workbook 30 Days

定位: 面向金融零售复杂 AI 系统能力的 30 天高强度 case drill 工作簿。 目标: 把金融零售场景中的 AI 机会, 业务流程, 需求, 架构, eval, 风险控制和 adoption 训练成可复用的系统能力资产。 使用方式: 每天完成一个 case drill, 每周做一次复盘, 第 30 天形成一套可用于系统叙事和系统证据复盘的 evidence pack。

2026-07-01 结构升级：全部 30 天已改为「题面先行、答案后置」（质量标准 §3.6）。每天先做「先做题」小节的空白产出，再看参考答案；原有内容全部保留未删。

---

1. 为什么需要 30 天 Case Drill

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

• 能从模糊业务痛点中判断是否适合 AI。
• 能把 AI 方案放进真实流程, 而不是停留在聊天界面。
• 能在同一 case 中同时处理需求澄清、价值取舍和系统设计。
• 能把 "准确, 安全, 有用" 转成可测试的 eval 和 release gate。
• 能在金融零售语境下说清 human-in-the-loop, audit trail, model risk, data governance 和 adoption。

本工作簿不是替代既有学习计划, 而是连接以下资产的实战训练层:

• AI 系统训练实验室: 练习方法和能力循环。
• 金融零售 AI 深度案例库: 金融场景 case source。
• docs/AI_REQUIREMENTS_TO_EVAL_COOKBOOK.md: 需求到 eval 的转换方法。
• docs/AI_OPERATING_MODEL_RACI_RUNBOOK.md: 上线后的运营模型和事故处理。
• docs/AI_ARCHITECTURE_REVIEW_GATE_CHECKLISTS.md: AI 架构评审 gate。
• docs/AI_CONTEXT_ENGINEERING_PLAYBOOK.md: RAG, context stack 和 evidence-first 输出。
• docs/abpa/README.md: ABPA 模板资产栈。

---

2. 30 天训练目标

完成 30 天后, 你应能输出并复盘:

1. 10 个以上金融零售 AI use case 的 business problem, baseline 和 success metric。
2. 10 张 AS-IS / TO-BE 流程或 decision flow, 标出 AI 插入点, 人工复核点和异常路径。
3. 10 组 requirements-to-eval matrix, 覆盖 functional, quality, guardrail, adoption 四类需求。
4. 6 份 architecture decision notes, 说明 RAG, rules+LLM, classifier, workflow agent, human-in-the-loop, observability 的取舍。
5. 6 份 risk/control register, 覆盖 PII, bias, hallucination, excessive agency, prompt injection, vendor risk, audit gap。
6. 3 个 flagship evidence packs: 一个低风险知识助手, 一个中风险运营 copilot, 一个高风险受监管决策辅助。
7. 一套系统摘要、复盘主线、深度审查三层 evidence narrative library。

---

3. 使用方式

每日节奏: 90-120 分钟

每周节奏

• 第 1-4 天: 每天完成一个独立 drill。
• 第 5 天: 完成当周综合 drill, 并把前 4 天产出收敛为一个 case pack。
• 每周末: 用 Rubric 给 5 个 drill 打分, 选 1 个升级为系统证据资产。

工作规则

• 默认所有金融关键决策保留 human-in-the-loop。
• 默认 AI 输出必须区分事实, 推断, 建议和无法判断。
• 默认所有引用型回答要有 evidence source。
• 默认涉及客户权益, 资金, 信贷, 合规结论的动作需要审批和审计。
• 不把 prompt 当成产品方案; 需要流程, 数据, 权限, eval, monitoring 和 adoption。

---

4. 评分 Rubric

每个维度 0-4 分, 单日满分 32 分。低于 20 分说明只是完成了文本, 还没有形成可执行方案。高于 26 分可以进入系统证据候选。

单日通过线

• 20 分: 合格练习, 可保留。
• 24 分: 可作为复盘材料。
• 26 分: 可扩展为系统证据 case。
• 30 分: 可直接升级为 flagship evidence pack。

---

5. 标准输出模板

每个 day 结束时都要保存以下 7 项:

1. Business problem: 谁在什么流程中遇到什么损耗, 现状基线是什么。
2. AI opportunity: AI 插入哪一步, 解决速度, 质量, 风险, 体验还是规模化问题。
3. Workflow and requirement task: stakeholder, AS-IS / TO-BE, 输入输出, 规则, 例外, 数据和验收。
4. 产品判断: MVP scope, success metric, ROI, no-AI alternative, product trade-off。
5. Architect design point: pattern, components, integration, permissions, context, observability, fallback。
6. Eval / Risk / Adoption: 测试集, 指标, threshold, controls, pilot, RACI, monitoring。
7. 当天产物: 一页 memo, matrix, process map, ADR, risk register, dashboard sketch 或 system narrative record。

---

6. 30 天训练总表

---

7. 每周主题

Week 1: AI Opportunity And Workflow Fit

重点训练从业务流程出发, 判断 AI 是否该介入, 介入哪一步, 责任边界在哪里。覆盖 AML, KYC, 客服知识, 支付争议四类基础场景。

Week 2: Regulated Decision Support

重点训练高风险金融决策辅助。关注信贷, 欺诈, 财富推荐, 催收等场景中的客户权益, 公平性, 合规审查和 human oversight。

Week 3: Operations Copilot And Agent Workflow

重点训练运营 copilot, 受控 agent, 工具调用, RACI 和 runbook。目标是能设计一个可上线, 可监控, 可回退的 AI 运营能力。

Week 4: Retail, Inventory, Promotion And Supply Chain AI

重点训练零售业务中的预测, 优化和建议型 AI。关注预测不等于决策, 需要把 AI 输出嵌入采购, 促销, 供应链和门店管理流程。

Week 5: Governance, EvalOps And Architecture Review

重点训练跨场景治理能力。输出 quality dashboard, release gate, vendor due diligence, compliance reporting controls 和 architecture review board pack。

Week 6: Evidence And System Narrative Conversion

重点训练把 case drill 升级成系统证据和系统叙事案例叙事。最终形成三个 flagship case, 一个 executive memo, 一套 evidence narrative library。

---

8. Daily Case Drills

Day 1: AML Alert Triage Copilot

• 业务问题: AML 团队每天收到大量 transaction monitoring alerts, investigator 把时间消耗在查客户资料, 交易链路, counterparty, 历史 case 和规则命中原因上, 高误报导致 backlog 增长。
• AI 机会: 设计 evidence-first copilot, 自动汇总 alert context, 生成 red flag checklist, 找出缺失证据, 草拟 case narrative, 但不自动关闭案件或决定是否提交 SAR/STR。

先做题（30-60 分钟，做完再看参考答案）

• 空白产出：闭卷写出 ①AS-IS/TO-BE 流程要点与干系人 ②MVP 边界与成功指标 ③架构组件链 ④eval/风险/adoption 要点 ⑤当天产物清单。
• 提示：先想清楚哪个动作绝不能自动化（案件关闭与 SAR/STR 提交的责任属于谁），以及 MLRO/BSA officer 应出现在流程哪一步。

参考答案

• 业务分析任务: 画 AS-IS alert investigation flow; 标出 investigator, supervisor, MLRO/BSA officer, data team; 定义输入字段, 输出 schema, 低置信度路径, supervisor QA 和 audit note。
• 产品与价值判断: MVP 只做 evidence gathering + narrative draft; 成功指标为 time-to-first-summary, QA rework rate, backlog age; 不以 SAR 数量增加作为单一成功指标。
• Architect 设计点: Case UI -> orchestration service -> transaction/profile retrieval -> policy and typology RAG -> LLM summarizer -> citation store -> review workflow -> immutable audit log。
• Eval/Risk/Adoption: 用历史 QA cases 建 golden set; 指标包括 evidence recall, citation precision, narrative factuality, missing-evidence detection; 风险包括 hallucinated rationale, prompt injection from adverse media, PII leakage; pilot 选择 senior analysts shadow mode。
• 当天产物: AML opportunity canvas, AS-IS / TO-BE 流程, AI 输出模板, 10 条 eval cases, risk/control register。

常见错误（对照空白产出自查）

• 把 SAR/STR 提交或案件关闭决策交给模型，而不是限定在证据汇集与 narrative 草稿。
• 成功指标选了 SAR 数量而不是 time-to-first-summary、QA rework rate、backlog age。
• 漏掉 adverse media 带来的 prompt injection 与 hallucinated rationale 风险，eval 里没有 missing-evidence detection。

评分标准

• 2 分（合格）：五项空白产出齐全且能自圆其说。
• 3 分：明确划出「AI 只做证据汇集+叙事草稿，不关案、不定 SAR」的边界，且指标避开 SAR 数量陷阱。
• 4 分：给出参考答案之外的风险/证据点（如 typology 覆盖盲区、citation store 被污染时的检测手段），且能被追问 10 分钟不失守。

Day 2: KYC Remediation And Document Gap Assistant

• 业务问题: KYC 周期复核和监管整改中, 客户资料缺件, 证件过期, UBO 信息不一致, tax form 缺失, 运营团队反复联系客户且完成周期长。
• AI 机会: 用 AI 识别缺口, 提取文档字段, 生成客户友好的补件说明, 推荐优先级, 但高风险客户和关键身份变更必须人工审批。

先做题（30-60 分钟，做完再看参考答案）

• 空白产出：闭卷写出 ①AS-IS/TO-BE 流程要点与干系人 ②MVP 边界与成功指标 ③架构组件链 ④eval/风险/adoption 要点 ⑤当天产物清单。
• 提示：先区分哪些缺件属于低风险可自动提醒、哪些身份信息变更绝不能绕过人工；干系人别只写运营团队——想想还有谁在被反复联系。

参考答案

• 业务分析任务: 建立 stakeholder map: KYC ops, RM, customer service, compliance, data quality, customer; 定义缺件 taxonomy, 文档状态, 字段冲突, 客户沟通模板和审批规则。
• 产品与价值判断: 先从低风险 expired ID reminder 和 address mismatch 开始; 指标为 remediation cycle time, first-contact completion, reviewer override rate, customer complaint rate。
• Architect 设计点: Data quality rules engine -> gap classifier -> document OCR/extraction -> policy RAG -> task queue -> communication generator -> reviewer workbench -> customer master update API。
• Eval/Risk/Adoption: 测试 field extraction accuracy, missing-field recall, false accept of invalid docs; 控制包括 PII minimization, role-based access, policy versioning, four-eyes review; adoption 通过 RM 和 ops 双角色 pilot。
• 当天产物: KYC gap taxonomy, remediation workflow, requirements-to-eval matrix, customer outreach examples, data lineage sketch。

常见错误（对照空白产出自查）

• 让 AI 直接更新 customer master 或放行高风险客户身份变更，绕过 four-eyes review。
• MVP 从高风险 UBO 不一致切入，而不是低风险 expired ID reminder / address mismatch。
• eval 只测 field extraction accuracy，漏掉 false accept of invalid docs 与 missing-field recall。

评分标准

• 2 分（合格）：五项空白产出齐全且能自圆其说。
• 3 分：MVP 从低风险缺件切入且高风险身份变更保留人工审批，指标包含 reviewer override rate 与 remediation cycle time。
• 4 分：给出参考答案之外的控制点（如 PII minimization 的具体落点、data lineage 断点排查或客户投诉侧证据），且能被追问 10 分钟不失守。

Day 3: Customer Service Knowledge Assistant

• 业务问题: 客服处理账户, 卡, 贷款, 费用, 退款, 投诉等问题时需要查多个系统和知识库, 答复不一致, AHT 高, 监管禁语和版本过期风险明显。
• AI 机会: 建立 RAG-based knowledge assistant, 根据客户问题检索权威知识, 给 agent 提供答案草稿, 引用来源, 风险提醒和下一步操作, 不直接面向客户自动承诺。

先做题（30-60 分钟，做完再看参考答案）

• 空白产出：闭卷写出 ①AS-IS/TO-BE 流程要点与干系人 ②MVP 边界与成功指标 ③架构组件链 ④eval/风险/adoption 要点 ⑤当天产物清单。
• 提示：先想清楚每条答案必须随身携带哪些元信息才敢给 agent 用，以及「找不到答案」和「两个来源打架」时系统该走哪条路。

参考答案

• 业务分析任务: 梳理知识源: 产品手册, SOP, FAQ, 费率表, 投诉政策, 合规禁语; 定义回答必须包含 source, version, confidence, escalation flag; 建立无答案和冲突答案路径。
• 产品与价值判断: MVP 聚焦 20 个高频非交易类问题; success metrics 包括 first-contact resolution, AHT, answer QA score, policy error rate, agent adoption。
• Architect 设计点: Agent desktop plugin -> query rewriting -> retrieval over approved KB -> reranker -> answer generator -> citation validator -> CRM note helper -> feedback capture。
• Eval/Risk/Adoption: golden queries 覆盖高频, 边界, 版本冲突, 注入攻击; 风险包括 hallucination, stale policy, unauthorized advice; pilot 采用 side-by-side answer with mandatory agent confirmation。
• 当天产物: RAG requirements, knowledge source inventory, answer schema, 30 条 golden queries, agent feedback loop。

常见错误（对照空白产出自查）

• 让助手直接面向客户自动答复或承诺，而不是给 agent 草稿并强制人工确认。
• 答案 schema 缺 source/version/confidence/escalation flag，拦不住过期政策与监管禁语。
• golden queries 只覆盖高频问题，漏掉版本冲突、无答案和注入攻击三类边界用例。

评分标准

• 2 分（合格）：五项空白产出齐全且能自圆其说。
• 3 分：答案 schema 带引用与版本、有无答案/冲突答案路径，MVP 收敛到 20 个高频非交易类问题。
• 4 分：给出参考答案之外的证据点（如 stale policy 的更新 SLA、citation validator 失效时的降级路径），且能被追问 10 分钟不失守。

Day 4: Payment Dispute Intake And Case Packet Agent

• 业务问题: 银行卡支付争议涉及客户陈述, 交易记录, 商户信息, 卡组织规则, 证据材料和 SLA, 人工 intake 容易漏材料, 导致补件和超时。
• AI 机会: 设计受控 agent 协助争议 intake, 识别争议类型, 检查材料完整性, 生成 case packet, 提醒 SLA, 关键提交动作由人工确认。

先做题（30-60 分钟，做完再看参考答案）

• 空白产出：闭卷写出 ①AS-IS/TO-BE 流程要点与干系人 ②MVP 边界与成功指标 ③架构组件链 ④eval/风险/adoption 要点 ⑤当天产物清单。
• 提示：这是 agent workflow 题——先画状态机再谈模型；想清楚哪个提交动作绝不能自动化、agent 失控时的紧急停止装在哪一层。

参考答案

• 业务分析任务: 定义 dispute taxonomy, required evidence by type, SLA, customer communication, exception path; 画 agent state machine: intake -> evidence check -> draft -> review -> submit -> monitor。
• 产品与价值判断: MVP 不自动提交 chargeback, 只做材料清单和草稿; 指标为 first-pass completeness, cycle time, SLA breach rate, customer repeat contact。
• Architect 设计点: Dispute case UI -> workflow engine -> card transaction API -> rule library retrieval -> document parser -> packet generator -> human approval -> submission connector -> replay log。
• Eval/Risk/Adoption: eval 覆盖争议类型分类, 材料缺失识别, 规则引用准确性; 风险包括 excessive agency, wrong submission, sensitive data exposure; adoption 从一个卡组织和两类争议开始。
• 当天产物: dispute state machine, tool permission matrix, evidence checklist, eval cases, kill-switch design。

常见错误（对照空白产出自查）

• 让 agent 自动提交 chargeback，缺人工确认与 kill-switch，excessive agency 失控。
• 没有按争议类型定义 required evidence 与 SLA，材料完整性检查无从落地。
• 漏掉 tool permission matrix 与 replay log，出错后无法追溯 agent 每一步动作。

评分标准

• 2 分（合格）：五项空白产出齐全且能自圆其说。
• 3 分：给出完整 state machine（intake→evidence check→draft→review→submit→monitor），且提交动作保留人工确认。
• 4 分：给出参考答案之外的控制点（如 kill-switch 触发条件、错误提交的回滚与客户补偿路径），且能被追问 10 分钟不失守。

Day 5: Week 1 Synthesis - AI Fit Comparison Memo

• 业务问题: 团队容易把 AML, KYC, 客服, 支付争议都说成 "AI 提效", 但这些场景风险等级, 数据准备度, 上线边界和成功指标完全不同。
• AI 机会: 建立 AI fit comparison matrix, 比较 RAG, classifier, rules+LLM, workflow agent, no-AI process improvement 的适用性。

先做题（30-60 分钟，做完再看参考答案）

• 空白产出：闭卷写出 ①AS-IS/TO-BE 流程要点与干系人 ②MVP 边界与成功指标 ③架构组件链 ④eval/风险/adoption 要点 ⑤当天产物清单。
• 提示：这是横向对比题不是单场景题——先给四个场景分风险档再排优先级，并想想哪些平台能力四个场景可以共用。

参考答案

• 业务分析任务: 汇总前四天的 stakeholder, workflow point, data source, exceptions, audit needs; 用统一模板列出每个场景的 baseline 和 pain metric。
• 产品与价值判断: 给四个 use case 排 MVP 优先级: 客服知识助手优先做低风险演示, KYC 做运营效率, 支付争议做 agent workflow, AML 保持高控制 pilot。
• Architect 设计点: 对比四类模式的 shared platform capability: identity/access, retrieval, workflow, eval service, audit log, monitoring dashboard。
• Eval/Risk/Adoption: 建立 risk-tiered release gate: low-risk answer assistant, medium-risk workflow copilot, high-risk regulated investigation; 每档定义 human approval, evidence, monitoring 和 incident path。
• 当天产物: 1 页 AI fit comparison memo, use case priority matrix, shared architecture capability map, Week 1 self-score。

常见错误（对照空白产出自查）

• 把 AML/KYC/客服/支付争议都写成「AI 提效」，没有按风险等级、数据准备度和上线边界区分。
• 只对比 AI pattern，漏掉 shared platform capability（identity/access、retrieval、eval service、audit log）。
• release gate 一刀切，没有 low/medium/high 分档的 human approval 与 incident path。

评分标准

• 2 分（合格）：五项空白产出齐全且能自圆其说。
• 3 分：产出风险分档的 release gate 与四场景 MVP 优先级排序，且排序理由能自圆其说。
• 4 分：给出参考答案之外的对比维度（如数据准备度、组织阻力）并推导出不同的优先级结论，且能被追问 10 分钟不失守。

Day 6: Lending Pre-Screening And Underwriting Assistant

• 业务问题: 小微或个人信贷审批需要整合申请表, 收入, 流水, 征信, 负债, 抵押品, 行业风险和政策例外, underwriter 写 memo 慢且风格不一致。
• AI 机会: AI 做资料摘要, policy checklist, risk factor extraction, memo draft 和 adverse action reason suggestion, 但不做最终信用决策。

先做题（30-60 分钟，做完再看参考答案）

• 空白产出：闭卷写出 ①AS-IS/TO-BE 流程要点与干系人 ②MVP 边界与成功指标 ③架构组件链 ④eval/风险/adoption 要点 ⑤当天产物清单。
• 提示：受监管决策辅助——先划 AI 与最终信用决策的责任边界，再想公平性（不同客群的一致性）应从哪个指标进 eval。

参考答案

• 业务分析任务: 定义贷款流程中的 AI 插入点: document intake, income normalization, policy check, memo drafting; 标出 underwriter, credit officer, compliance, model risk, borrower。
• 产品与价值判断: MVP 从已人工决策案件的 memo draft shadow mode 开始; 成功指标为 memo completeness, policy citation accuracy, rework rate, time-to-decision, subgroup consistency。
• Architect 设计点: LOS -> document processing -> deterministic calculation service -> policy RAG -> LLM memo assistant -> reason-code service -> underwriter review -> decision record。
• Eval/Risk/Adoption: golden set 使用历史 approved/declined files; 指标覆盖 calculation extraction, missing risk detection, reason-code consistency; 风险包括 bias, proxy features, overreliance, adverse action wording error。
• 当天产物: underwriting requirements-to-eval matrix, decision authority boundary, fair lending control list, shadow-mode pilot plan。

常见错误（对照空白产出自查）

• 让 AI 参与最终信用决策或自动批贷，而不是限定在资料摘要、policy checklist 与 memo 草稿。
• 忽略 fair lending：没有 subgroup consistency 指标，没排查 proxy features 与 bias。
• 直接上生产辅助，而不是从已人工决策案件的 memo draft shadow mode 起步。

评分标准

• 2 分（合格）：五项空白产出齐全且能自圆其说。
• 3 分：决策权边界清晰（AI 不做信用决策）+ shadow mode 起步 + 指标包含 subgroup consistency。
• 4 分：额外覆盖 adverse action wording 风险或 deterministic calculation 与 LLM memo 的分离设计，且能被追问 10 分钟不失守。

Day 7: Credit Card Fraud Alert Prioritization

• 业务问题: 信用卡实时欺诈告警误报多, 客户被错误拦截会投诉, 但漏报会造成 fraud loss 和监管压力。
• AI 机会: 设计 AI ranking layer, 结合交易金额, 商户, 位置, 设备, 历史行为和规则命中, 推荐优先级和验证方式, 不直接冻结账户。

先做题（30-60 分钟，做完再看参考答案）

• 空白产出：闭卷写出 ①AS-IS/TO-BE 流程要点与干系人 ②MVP 边界与成功指标 ③架构组件链 ④eval/风险/adoption 要点 ⑤当天产物清单。
• 提示：核心取舍是误拦客户的成本 vs 漏放欺诈的损失——先想清楚哪一类告警绝不允许被 AI 降级，再谈排序。

参考答案

• 业务分析任务: 画 fraud alert handling flow; 定义 high-risk non-downgrade rules, customer verification paths, analyst override, feedback to fraud strategy。
• 产品与价值判断: trade-off 不是单纯降低告警量, 而是优化 false positive cost 与 fraud loss; MVP 用 shadow mode 排序, 不改变现有拦截策略。
• Architect 设计点: Fraud event stream -> feature service -> existing rules/model score -> LLM case explainer -> action recommendation -> analyst console -> feedback pipeline。
• Eval/Risk/Adoption: 指标包括 missed fraud, false positive release time, analyst agreement, explanation usefulness; 风险包括模型漂移, 欺诈对抗, 客户备注注入; adoption 需要 fraud strategy 每周 review。
• 当天产物: fraud prioritization PRD, risk-tiered action table, eval metric tree, monitoring dashboard sketch。

常见错误（对照空白产出自查）

• 把目标写成「降低告警量」，而不是优化 false positive cost 与 fraud loss 的联合损失。
• 让 AI 直接冻结账户或改变现有拦截策略，而不是 shadow mode 排序不动存量策略。
• 漏掉 high-risk non-downgrade rules 与欺诈对抗风险（客户备注注入、模型漂移）。

评分标准

• 2 分（合格）：五项空白产出齐全且能自圆其说。
• 3 分：有 non-downgrade 规则 + shadow mode MVP + missed fraud 作为核心防守指标。
• 4 分：额外给出对抗性演化的监控设计（如 feedback pipeline 被欺诈者污染的检测），且能被追问 10 分钟不失守。

Day 8: Wealth Suitability And Advisory Guardrail

• 业务问题: 理财/财富顾问需要推荐基金, 保险, 投资组合或再平衡建议, 但必须满足 suitability, risk profile, disclosure 和销售合规要求。
• AI 机会: AI 提供产品知识检索, 客户需求摘要, 适当性检查提示和话术 guardrail, 不直接替代持牌顾问建议。

先做题（30-60 分钟，做完再看参考答案）

• 空白产出：闭卷写出 ①AS-IS/TO-BE 流程要点与干系人 ②MVP 边界与成功指标 ③架构组件链 ④eval/风险/adoption 要点 ⑤当天产物清单。
• 提示：先想确定性规则与 LLM 在链路中的先后顺序（谁给谁兜底），以及持牌顾问的法律责任如何在流程中保留。

参考答案

• 业务分析任务: 定义客户风险等级, 产品风险等级, 投资目标, 禁售规则, disclosure, exception approval; 梳理 advisor, compliance, customer, product team。
• 产品与价值判断: MVP 做 advisor-facing compliance co-pilot, 不做自动个性化投资建议; 指标为 unsuitable recommendation prevention, disclosure completeness, advisor adoption, complaint rate。
• Architect 设计点: CRM/profile -> suitability rules engine -> product knowledge RAG -> advisory draft assistant -> compliance guardrail checker -> advisor approval -> interaction record。
• Eval/Risk/Adoption: 测试产品匹配, 禁售规则, disclosure presence, hallucinated return promises; 控制包括 deterministic suitability rules before LLM, audit transcript, compliance sampling。
• 当天产物: suitability control matrix, advisory answer schema, red-team cases, advisor workflow adoption plan。

常见错误（对照空白产出自查）

• 让 AI 直接生成个性化投资建议替代持牌顾问，而不是 advisor-facing compliance co-pilot。
• 没有把 deterministic suitability rules 放在 LLM 之前，禁售规则只靠提示词兜底。
• red-team 没覆盖 hallucinated return promises 与 disclosure 缺失两类高危输出。

评分标准

• 2 分（合格）：五项空白产出齐全且能自圆其说。
• 3 分：规则引擎前置于 LLM + advisor 审批保留 + unsuitable recommendation prevention 作为核心指标。
• 4 分：额外给出 compliance sampling / audit transcript 的抽检设计或 exception approval 路径，且能被追问 10 分钟不失守。

Day 9: Collections Next-Best-Action Assistant

• 业务问题: 逾期催收团队需要在合规边界内选择提醒, 分期, 减免, 升级或暂停联系, 既要控制损失, 又要保护客户权益和品牌声誉。
• AI 机会: AI 汇总账户, 还款历史, 联系记录和政策, 推荐 next-best-action 选项和话术, 但不得越过催收法规和人工审批。

先做题（30-60 分钟，做完再看参考答案）

• 空白产出：闭卷写出 ①AS-IS/TO-BE 流程要点与干系人 ②MVP 边界与成功指标 ③架构组件链 ④eval/风险/adoption 要点 ⑤当天产物清单。
• 提示：合规边界先行——先列出禁止话术、必须披露内容和弱势客户的升级路径，再考虑推荐什么动作；别忘了逾期客户本身也是要保护的干系人。

参考答案

• 业务分析任务: 建立 delinquency stage taxonomy, hardship signals, contact rules, vulnerable customer escalation, complaint path; 定义禁止话术和必须披露内容。
• 产品与价值判断: MVP 从低风险 early-stage reminder 和 agent script suggestion 开始; 成功指标为 promise-to-pay conversion, complaint rate, QA defect, agent handle time。
• Architect 设计点: Collections platform -> customer/account context -> policy rules -> hardship classifier -> script generator -> QA checker -> agent approval -> outcome feedback。
• Eval/Risk/Adoption: 指标包括 policy compliance, vulnerable customer detection, tone QA, wrong-action rate; 风险包括 unfair treatment, prohibited contact, coercive language; adoption 需培训和 QA 抽检。
• 当天产物: collections workflow, compliant script examples, risk/control register, pilot QA checklist。

常见错误（对照空白产出自查）

• 让 AI 直接对客户执行催收话术或动作，跳过 agent approval 与 QA checker。
• 只优化 promise-to-pay conversion，忽略 complaint rate、vulnerable customer detection 与 QA defect。
• 没有定义禁止话术与必须披露清单，coercive language 风险完全裸奔。

评分标准

• 2 分（合格）：五项空白产出齐全且能自圆其说。
• 3 分：MVP 限定 early-stage reminder + 话术建议，且有 vulnerable customer escalation 与禁语清单。
• 4 分：额外设计 tone QA 的量化抽检或 wrong-action rate 的回溯归因机制，且能被追问 10 分钟不失守。

Day 10: Week 2 Review Gate - Regulated Decision Support Memo

• 业务问题: 信贷, 欺诈, 财富, 催收都接近客户权益和资金风险, 如果用同一套 "AI 助手" 表达, 会掩盖监管和责任差异。
• AI 机会: 建立 regulated decision support review gate, 明确哪些 AI 输出可以 read/summarize, 哪些可以 recommend/draft, 哪些不得 decide/act。

先做题（30-60 分钟，做完再看参考答案）

• 空白产出：闭卷写出 ①AS-IS/TO-BE 流程要点与干系人 ②MVP 边界与成功指标 ③架构组件链 ④eval/风险/adoption 要点 ⑤当天产物清单。
• 提示：把 read/summarize、recommend/draft、decide/act 三档能力逐一对到信贷、欺诈、财富、催收四个场景的 decision rights 上——差异比共性更重要。

参考答案

• 业务分析任务: 汇总四个场景的 decision rights, data sensitivity, human review, audit evidence, exception paths; 标注所有会影响客户权益的节点。
• 产品与价值判断: 形成 go / pilot / no-go 判断; 优先上线低 agency, 高可审计, 高 adoption 的流程片段; 对高风险动作要求 mandatory approval。
• Architect 设计点: 设计 shared guardrail pattern: deterministic rules before LLM, policy citation, confidence, reviewer attestation, immutable logs, rollback。
• Eval/Risk/Adoption: 输出 release gate: minimum eval threshold, red-team pass, compliance sign-off, model risk review, pilot scope, monitoring owner。
• 当天产物: regulated AI decision support memo, risk-tiered capability matrix, Week 2 system narrative record draft。

常见错误（对照空白产出自查）

• 用同一套「AI 助手」语言描述四个场景，掩盖 decision rights 与监管责任差异。
• release gate 只有 eval threshold，缺 red-team pass、compliance sign-off 与 model risk review。
• 没有标注影响客户权益的节点，shared guardrail 缺 reviewer attestation 与 rollback。

评分标准

• 2 分（合格）：五项空白产出齐全且能自圆其说。
• 3 分：产出 read/recommend/decide 三档能力矩阵，且每档有对应的 human approval 与 audit evidence 要求。
• 4 分：给出 go/pilot/no-go 的具体判断依据，并能为其中某个场景的 no-go 结论辩护，且能被追问 10 分钟不失守。

Day 11: Payments Exception Operations Copilot

• 业务问题: 支付失败, 重复扣款, 清算差异, 退款卡单和 settlement mismatch 需要跨支付网关, 核心账务, 清算文件和客服工单排查。
• AI 机会: AI 聚合交易状态, 解释错误码, 推荐处理路径, 生成操作记录, 但不直接改账或发起资金调整。

先做题（30-60 分钟，做完再看参考答案）

• 空白产出：闭卷写出 ①AS-IS/TO-BE 流程要点与干系人 ②MVP 边界与成功指标 ③架构组件链 ④eval/风险/adoption 要点 ⑤当天产物清单。
• 提示：先划 no-action boundary——copilot 能读哪些系统、绝不能碰哪些资金动作；再想交易状态过期时诊断结论会怎么误导人。

参考答案

• 业务分析任务: 定义 exception taxonomy: authorization fail, capture fail, refund pending, chargeback, settlement mismatch; 梳理 ops, finance, payments engineering, customer service。
• 产品与价值判断: MVP 聚焦 top 10 error codes 和只读诊断; 指标为 mean time to diagnose, handoff count, SLA breach, incorrect escalation。
• Architect 设计点: Ops console -> transaction timeline service -> gateway/core/ledger connectors -> error-code knowledge RAG -> recommendation engine -> approval workflow -> audit note。
• Eval/Risk/Adoption: 测试 root-cause classification, evidence completeness, recommendation safety; 风险包括 stale status, wrong refund advice, unauthorized financial action; adoption 先给 senior ops 只读使用。
• 当天产物: payment exception flow, API/data source inventory, no-action boundary, eval set, runbook entry。

常见错误（对照空白产出自查）

• 让 copilot 直接改账、发起退款或资金调整，而不是只读诊断加建议。
• MVP 铺开全部 error code，而不是聚焦 top 10 error codes 与只读场景。
• 忽略 stale status 风险——交易状态过期导致 wrong refund advice 与 incorrect escalation。

评分标准

• 2 分（合格）：五项空白产出齐全且能自圆其说。
• 3 分：有明确 no-action boundary + top 10 error codes 只读 MVP + mean time to diagnose 指标。
• 4 分：额外覆盖跨系统数据时效/一致性的验证手段或错误升级路径的防护设计，且能被追问 10 分钟不失守。

Day 12: Complaint Classification And Root Cause Analysis

• 业务问题: 投诉来自电话, 邮件, App, 分行和社交渠道, 分类口径不一致, 严重投诉升级慢, 产品团队难以看到系统性问题。
• AI 机会: AI 自动分类, 多标签识别, 根因聚类, 严重投诉优先级和监管标签提示, 但最终分类和监管上报由人工确认。

先做题（30-60 分钟，做完再看参考答案）

• 空白产出：闭卷写出 ①AS-IS/TO-BE 流程要点与干系人 ②MVP 边界与成功指标 ③架构组件链 ④eval/风险/adoption 要点 ⑤当天产物清单。
• 提示：想清楚哪一类投诉被漏掉的代价最大——你的 eval 指标应该向它倾斜而不是向整体准确率；另外 taxonomy 变了谁说了算。

参考答案

• 业务分析任务: 定义 complaint taxonomy, severity levels, regulatory tags, product line, root cause, channel; 设计人工复核和 taxonomy change process。
• 产品与价值判断: MVP 做 post-call/post-ticket classification; 成功指标为 classification agreement, severe complaint recall, root-cause actionability, product feedback cycle time。
• Architect 设计点: Complaint ingestion -> PII redaction -> classifier -> embedding cluster -> taxonomy manager -> reviewer queue -> analytics dashboard -> product action log。
• Eval/Risk/Adoption: golden set 覆盖低频高风险投诉; 指标关注 severe complaint recall 高于整体准确率; 风险包括严重投诉降级, 偏见分类, privacy leakage。
• 当天产物: complaint taxonomy, classification eval plan, dashboard sample data, escalation control rules。

常见错误（对照空白产出自查）

• 只优化整体分类准确率，忽略 severe complaint recall——严重投诉被降级才是最大风险。
• 让 AI 直接决定监管上报标签，跳过人工确认与升级控制。
• 没有 PII redaction 前置与 taxonomy change process，分类口径继续漂移。

评分标准

• 2 分（合格）：五项空白产出齐全且能自圆其说。
• 3 分：severe complaint recall 优先于整体准确率 + 监管标签人工确认 + taxonomy 治理流程齐备。
• 4 分：额外给出低频高风险投诉的采样/增广策略或偏见分类的检测手段，且能被追问 10 分钟不失守。

Day 13: Frontline Staff Knowledge Assistant

• 业务问题: 分行员工和一线运营频繁查询产品政策, 资格条件, SOP, 费率, 促销和例外处理, 但不同角色权限不同, 误答会影响销售合规和客户体验。
• AI 机会: 建立 role-aware internal knowledge assistant, 按员工角色和地区返回授权答案, 引用政策来源, 对冲突或无权限问题拒答并升级。

先做题（30-60 分钟，做完再看参考答案）

• 空白产出：闭卷写出 ①AS-IS/TO-BE 流程要点与干系人 ②MVP 边界与成功指标 ③架构组件链 ④eval/风险/adoption 要点 ⑤当天产物清单。
• 提示：与 Day 3 的关键差异在权限——想清楚按角色/地区的隔离应该发生在检索前还是生成后，以及「无权限」时系统的正确行为是什么。

参考答案

• 业务分析任务: 盘点知识源, 角色权限, 地区差异, 产品版本, 禁止回答范围; 设计 frontline query journey 和 feedback process。
• 产品与价值判断: MVP 从低风险 SOP 和产品 FAQ 开始; 指标为 self-service resolution, answer helpfulness, policy error rate, employee adoption, escalations avoided。
• Architect 设计点: SSO/RBAC -> query router -> permission filter -> retrieval -> conflict detector -> answer generator -> citation validator -> feedback and analytics。
• Eval/Risk/Adoption: 测试权限隔离, 制度冲突, jailbreak, 过期政策; 控制包括 source allowlist, version labels, no-answer behavior; adoption 通过 branch champion 和 weekly office hour。
• 当天产物: permission-aware RAG design, role-answer matrix, golden query set, adoption dashboard。

常见错误（对照空白产出自查）

• 权限过滤放在生成之后或只靠 prompt 声明，检索层没有 permission filter 与 SSO/RBAC 前置。
• 漏掉地区差异与产品版本标签，把过期或异地政策答给了错误角色。
• 没有 no-answer/拒答升级路径，jailbreak 与制度冲突用例在 eval 中缺失。

评分标准

• 2 分（合格）：五项空白产出齐全且能自圆其说。
• 3 分：检索前 RBAC/permission filter + source allowlist + 版本标签 + 拒答升级路径齐全。
• 4 分：额外设计权限隔离的对抗测试（越权提问用例集）或超出 branch champion 的反馈闭环机制，且能被追问 10 分钟不失守。

Day 14: Regulatory Change Impact Analysis Assistant

• 业务问题: 监管新规或内部政策变更发布后, 需要判断影响哪些产品, 流程, 文案, 系统, 数据字段和报表, 人工影响分析慢且容易漏。
• AI 机会: AI 解析条款, 检索内部制度, 映射流程和系统, 生成影响清单和证据引用, 但法律解释和整改结论由合规确认。

先做题（30-60 分钟，做完再看参考答案）

• 空白产出：闭卷写出 ①AS-IS/TO-BE 流程要点与干系人 ②MVP 边界与成功指标 ③架构组件链 ④eval/风险/adoption 要点 ⑤当天产物清单。
• 提示：先明确法律解释权归谁；再想在「漏判一条义务比多列十条影响更致命」的前提下，eval 指标应该向哪边倾斜。

参考答案

• 业务分析任务: 定义 regulation-to-control mapping, affected asset inventory, impact severity, owner, due date; 设计 compliance, legal, product, architecture, operations 协作流程。
• 产品与价值判断: MVP 做 evidence-backed impact draft; 成功指标为 impact recall, time-to-first-impact-list, reviewer acceptance, missed obligation rate。
• Architect 设计点: Regulation ingestion -> clause extraction -> policy/process/system retrieval -> impact graph -> task generator -> reviewer workflow -> change log。
• Eval/Risk/Adoption: golden set 使用历史监管变更和整改记录; 风险包括漏判, 过度解释, 引用错误; adoption 需要合规 reviewer 标注 rejection reason 反哺检索。
• 当天产物: impact analysis template, RAG retrieval strategy, reviewer workflow, eval cases, governance gate。

常见错误（对照空白产出自查）

• 让 AI 输出法律解释与整改结论，而不是 evidence-backed impact draft 交由合规确认。
• eval 只看 precision，忽略 impact recall 与 missed obligation rate——漏一条义务的代价远大于多列一条。
• 没有把 reviewer rejection reason 反哺检索策略，影响清单质量不随整改记录进化。

评分标准

• 2 分（合格）：五项空白产出齐全且能自圆其说。
• 3 分：合规保留解释权 + recall 导向的 eval + regulation-to-control mapping 带 owner 与 due date。
• 4 分：额外给出用历史监管变更构建 golden set 的方法或过度解释（over-interpretation）的抑制手段，且能被追问 10 分钟不失守。

Day 15: Week 3 Operating Model And Runbook Pack

• 业务问题: 多个运营 copilot 上线后, 部门往往缺少统一 owner, 质量监控, 事故升级, 知识更新和反馈闭环, 造成 AI 资产不可持续。
• AI 机会: 为 Week 3 场景设计 operating model, 让支付异常, 投诉分类, 前线知识, 合规影响分析共享质量管理和 runbook。

先做题（30-60 分钟，做完再看参考答案）

• 空白产出：闭卷写出 ①AS-IS/TO-BE 流程要点与干系人 ②MVP 边界与成功指标 ③架构组件链 ④eval/风险/adoption 要点 ⑤当天产物清单。
• 提示：这是运营题不是建模题——先写 RACI 再写架构，特别注意最容易被漏掉的角色（谁对模型风险负责？谁做访问审查？），以及事故类型不止幻觉一种。

参考答案

• 业务分析任务: 定义 RACI: business owner, product owner, 业务分析, data owner, engineering, compliance, security, operations lead, model risk; 梳理 change request 和 incident process。
• 产品与价值判断: 指标要覆盖 business outcome, model quality, risk signals, cost, adoption; 不能只看回答满意度。
• Architect 设计点: Shared AI operations layer: logging, eval service, feedback, knowledge versioning, access review, incident dashboard, rollback config。
• Eval/Risk/Adoption: 定义 hallucination incident, prompt injection, data leakage, provider outage, eval regression 的 runbook; adoption 以 monthly governance review 驱动。
• 当天产物: operating model RACI, AI incident runbook, weekly quality dashboard, Week 3 synthesis memo。

常见错误（对照空白产出自查）

• RACI 漏掉 model risk、security 或 data owner，事故发生时无人 accountable。
• 指标只看回答满意度，缺 business outcome、model quality、risk signals、cost 四类。
• runbook 只写 hallucination，没覆盖 provider outage、prompt injection、data leakage 与 eval regression。

评分标准

• 2 分（合格）：五项空白产出齐全且能自圆其说。
• 3 分：RACI 覆盖全部关键角色 + 五类事故 runbook（幻觉/注入/泄漏/宕机/eval 回归）齐备。
• 4 分：额外设计 knowledge versioning / access review 的周期性机制或跨 copilot 的共享成本分摊模型，且能被追问 10 分钟不失守。

Day 16: Retail Inventory Replenishment Forecast Assistant

• 业务问题: 零售门店和仓库需要决定补货数量, 传统规则难以同时考虑季节, 促销, 天气, 价格, 库存周转, 供应延迟和门店差异, 造成缺货或积压。
• AI 机会: AI 提供 demand forecast, stockout risk, overstock risk 和补货建议解释, 采购经理保留最终下单权。

先做题（30-60 分钟，做完再看参考答案）

• 空白产出：闭卷写出 ①AS-IS/TO-BE 流程要点与干系人 ②MVP 边界与成功指标 ③架构组件链 ④eval/风险/adoption 要点 ⑤当天产物清单。
• 提示：预测不等于决策——想清楚 planner 的最终下单权如何保留、他不采纳建议时系统该记录什么，以及 backtesting 不分层会掩盖什么。

参考答案

• 业务分析任务: 定义 SKU-store-day 粒度, 需求信号, 库存状态, lead time, substitution, markdown, service level; 画 replenish decision flow。
• 产品与价值判断: MVP 选择高销量且供应稳定的品类; 成功指标为 stockout rate, inventory days, forecast bias, planner override rate, gross margin。
• Architect 设计点: POS/ERP/WMS data -> forecast model -> business rules -> explanation generator -> planner UI -> order approval -> actuals feedback。
• Eval/Risk/Adoption: backtesting 按 SKU, store, season 分层; 风险包括过度依赖预测, 数据延迟, 促销漏录; adoption 需要显示 why + override capture。
• 当天产物: inventory forecast problem statement, feature/data map, planner workflow, evaluation design, adoption plan。

常见错误（对照空白产出自查）

• 让 forecast 直接生成订单跳过采购经理审批，混淆 prediction 与 decision。
• MVP 选了长尾或供应不稳品类，而不是高销量且供应稳定的品类。
• backtesting 不分层（SKU/store/season），forecast bias 被平均数掩盖。

评分标准

• 2 分（合格）：五项空白产出齐全且能自圆其说。
• 3 分：planner 保留下单权 + override capture + 分层 backtesting + stockout 与 inventory days 双向指标。
• 4 分：额外覆盖促销漏录/数据延迟的数据质量防线，或 explanation 设计对 planner 信任度的影响，且能被追问 10 分钟不失守。

Day 17: Retail Promotion Recommendation And Margin Guardrail

• 业务问题: 促销活动要平衡销量, 毛利, 库存清理, 会员增长和品牌定位, 手工选择 SKU 和折扣容易造成低利润或 cannibalization。
• AI 机会: AI 推荐促销组合, 预测 uplift, margin impact 和库存消化, 并标记不适合促销的商品或客群。

先做题（30-60 分钟，做完再看参考答案）

• 空白产出：闭卷写出 ①AS-IS/TO-BE 流程要点与干系人 ②MVP 边界与成功指标 ③架构组件链 ④eval/风险/adoption 要点 ⑤当天产物清单。
• 提示：先列出 marketing、merchandising、finance、store ops 之间的目标冲突和不能促销的排除规则，再谈 uplift 模型；销量涨了毛利未必涨。

参考答案

• 业务分析任务: 定义 promotion objective, eligible SKUs, customer segments, constraints, exclusion rules, approval workflow; 明确 marketing, merchandising, finance, store ops 的冲突。
• 产品与价值判断: MVP 做 decision support 而非自动定价; 指标包括 incremental revenue, margin, sell-through, cannibalization, customer complaints。
• Architect 设计点: Customer/product/sales data mart -> uplift model -> optimization constraints -> scenario simulator -> approval workflow -> campaign monitoring。
• Eval/Risk/Adoption: A/B test 或 geo split 测 uplift; 风险包括歧视性定价, 过度促销, 库存错误; adoption 需要 scenario comparison 和 finance sign-off。
• 当天产物: promotion AI canvas, constraint list, experiment design, margin guardrail matrix。

常见错误（对照空白产出自查）

• 做成自动定价而不是 decision support，缺 scenario simulator 与 finance sign-off。
• 只看 incremental revenue，忽略 margin、cannibalization 与 sell-through。
• 没有 exclusion rules 与歧视性定价检查，客群维度的 fairness 风险裸奔。

评分标准

• 2 分（合格）：五项空白产出齐全且能自圆其说。
• 3 分：decision support 定位明确 + 约束与排除规则清单 + A/B 或 geo split 实验设计完整。
• 4 分：额外给出 cannibalization 的度量口径或 scenario simulator 的多目标对比维度，且能被追问 10 分钟不失守。

Day 18: Supply Chain Delay Risk Early Warning

• 业务问题: 供应商延迟, 物流拥堵, 港口问题, 原材料短缺和异常天气会影响到货, 业务团队通常在缺货临近时才发现。
• AI 机会: AI 结合采购订单, ASN, 物流轨迹, 供应商历史, 新闻和天气信号, 预测 delay risk, 推荐替代供应或库存调拨。

先做题（30-60 分钟，做完再看参考答案）

• 空白产出：闭卷写出 ①AS-IS/TO-BE 流程要点与干系人 ②MVP 边界与成功指标 ③架构组件链 ④eval/风险/adoption 要点 ⑤当天产物清单。
• 提示：外部信号可靠性与 alert fatigue 是这道题的暗礁——先想告警阈值怎么分级、谁是 escalation owner、预警接到哪个既有决策节奏里。

参考答案

• 业务分析任务: 定义 risk signal taxonomy, decision owner, escalation path, alternative sourcing rules, supplier communication templates。
• 产品与价值判断: MVP 聚焦关键 SKU 和高价值供应商; 指标为 early warning lead time, precision of high-risk alerts, avoided stockout value, planner action rate。
• Architect 设计点: ERP/SCM/TMS connectors -> external signal ingestion -> risk scoring -> explanation and evidence layer -> planner workflow -> supplier action log。
• Eval/Risk/Adoption: backtest 历史延迟; 风险包括外部数据不可靠, alert fatigue, supplier relationship impact; adoption 通过 weekly S&OP review 嵌入。
• 当天产物: supply chain risk map, signal inventory, alert threshold design, response playbook。

常见错误（对照空白产出自查）

• 信号全量报警没有阈值分级，alert fatigue 让 planner 停止响应。
• 忽略外部数据（新闻/天气）不可靠时的降权处理，误报直接伤害 supplier relationship。
• 预警没有嵌入 weekly S&OP 等既有决策节奏，沦为没人看的 dashboard。

评分标准

• 2 分（合格）：五项空白产出齐全且能自圆其说。
• 3 分：alert threshold 分级 + decision owner/escalation path 明确 + 嵌入 weekly S&OP review。
• 4 分：额外给出 early warning lead time 与 precision 的取舍分析或替代采购的触发规则，且能被追问 10 分钟不失守。

Day 19: Store Workforce Scheduling Assistant

• 业务问题: 门店排班需要平衡客流预测, 员工技能, 劳动法规, 休假, 成本和公平性, 手工排班耗时且员工不满。
• AI 机会: AI 预测客流和工作量, 推荐排班方案, 标记法规冲突和公平性问题, 门店经理保留调整权。

先做题（30-60 分钟，做完再看参考答案）

• 空白产出：闭卷写出 ①AS-IS/TO-BE 流程要点与干系人 ②MVP 边界与成功指标 ③架构组件链 ④eval/风险/adoption 要点 ⑤当天产物清单。
• 提示：被排班的员工也是干系人——先列劳动法规硬约束和公平性约束，再想经理 override 与员工申诉如何留痕。

参考答案

• 业务分析任务: 定义 shift rules, skill matrix, availability, overtime, break rules, fairness constraints, manager override reason。
• 产品与价值判断: MVP 做 schedule suggestion + violation checker; 指标为 schedule creation time, labor cost variance, service level, employee satisfaction, override reasons。
• Architect 设计点: Workforce system -> traffic forecast -> constraint optimizer -> explanation layer -> manager UI -> employee notification -> feedback loop。
• Eval/Risk/Adoption: 测试法规合规, fairness distribution, forecast accuracy; 风险包括员工感到被算法管理, 隐私, 不公平班次; adoption 需要透明解释和 appeal path。
• 当天产物: workforce scheduling flow, constraint catalog, fairness eval plan, manager adoption script。

常见错误（对照空白产出自查）

• 只优化人力成本，漏掉劳动法规硬约束与 fairness distribution 检查。
• 没有 manager override reason 记录与员工 appeal path，「被算法管理」的抵触无处安放。
• 把客流 forecast accuracy 当成唯一 eval，缺 schedule violation checker 与公平性评测。

评分标准

• 2 分（合格）：五项空白产出齐全且能自圆其说。
• 3 分：法规约束前置 + fairness eval + override reason 记录 + appeal path 四件齐全。
• 4 分：额外设计员工公平感知的度量方法或排班解释的透明化方案，且能被追问 10 分钟不失守。

Day 20: Week 4 Retail Case Pack - Prediction To Decision Support

• 业务问题: 零售 AI 常被误解成 "预测越准越好", 但实际价值来自预测如何进入采购, 促销, 供应链和排班决策。
• AI 机会: 将 Week 4 四个场景统一成 prediction-to-decision framework, 明确 forecast, recommendation, optimization, human approval 和 feedback。

先做题（30-60 分钟，做完再看参考答案）

• 空白产出：闭卷写出 ①AS-IS/TO-BE 流程要点与干系人 ②MVP 边界与成功指标 ③架构组件链 ④eval/风险/adoption 要点 ⑤当天产物清单。
• 提示：这道题的骨架是把 model accuracy、decision quality、business outcome 三层指标分开——预测错误在四个场景各自砸到哪个业务后果上。

参考答案

• 业务分析任务: 汇总数据源, 决策频率, 责任人, override reason, downstream impact; 标出预测错误的业务后果。
• 产品与价值判断: 选择一个最适合系统证据的零售 case, 说明为什么它有清晰 baseline, 可测试指标和可落地 adoption。
• Architect 设计点: 设计 shared retail AI pattern: feature store, forecast service, constraint engine, scenario UI, approval workflow, monitoring。
• Eval/Risk/Adoption: 指标区分 model accuracy, decision quality, business outcome; 风险包括 forecast drift, optimization side effects, user override fatigue。
• 当天产物: Week 4 case pack, shared architecture sketch, prediction-to-decision rubric, retail system narrative record。

常见错误（对照空白产出自查）

• 用「预测越准越好」组织整个 case pack，没有 prediction-to-decision framework。
• model accuracy、decision quality、business outcome 三层指标混为一谈。
• 挑系统证据 case 只看技术炫度，不看 baseline 清晰度、可测试指标与 adoption 可落地性。

评分标准

• 2 分（合格）：五项空白产出齐全且能自圆其说。
• 3 分：四个零售场景统一进 prediction-to-decision framework，且三层指标清晰分离。
• 4 分：能论证所选 flagship case 的反方（为什么不选另外三个），并覆盖 override fatigue 等运营副作用，且能被追问 10 分钟不失守。

Day 21: Regulatory Reporting Quality Check Assistant

• 业务问题: 合规报送和监管报告需要从多个系统汇总数据, 核对口径, 生成解释和 sign-off 证据, 错报或漏报可能导致监管处罚。
• AI 机会: AI 检查报表一致性, 解释异常变动, 生成 reviewer checklist 和 evidence pack, 但不替代报送负责人签署。

先做题（30-60 分钟，做完再看参考答案）

• 空白产出：闭卷写出 ①AS-IS/TO-BE 流程要点与干系人 ②MVP 边界与成功指标 ③架构组件链 ④eval/风险/adoption 要点 ⑤当天产物清单。
• 提示：报送签署责任不可转移——先想确定性校验与 AI 解释各管什么，数值核对绝不能交给谁；再想 lineage 断点会让解释失去什么。

参考答案

• 业务分析任务: 定义 report inventory, field lineage, validation rules, materiality threshold, reviewer sign-off, correction workflow。
• 产品与价值判断: MVP 从报送前 quality check 开始; 指标为 defect detection rate, review time, late correction, audit finding reduction。
• Architect 设计点: Data warehouse/reporting mart -> lineage metadata -> deterministic validation -> anomaly explanation assistant -> reviewer workflow -> sign-off archive。
• Eval/Risk/Adoption: golden set 使用历史报送缺陷; 风险包括错误解释, data lineage gap, unapproved correction; adoption 需财务/合规 reviewer 共同定义 materiality。
• 当天产物: reporting control checklist, lineage map, anomaly explanation schema, release gate。

常见错误（对照空白产出自查）

• 让 AI 替代报送负责人签署或直接修改报表数据，绕过 correction workflow。
• 用 LLM 做数值校验，而不是 deterministic validation 前置、AI 只做异常变动解释。
• 没有 field lineage 与 materiality threshold，异常解释无锚点、重要性无标准。

评分标准

• 2 分（合格）：五项空白产出齐全且能自圆其说。
• 3 分：deterministic validation 与 AI 解释分工明确 + sign-off 保留人工 + materiality 有定义。
• 4 分：额外给出用历史报送缺陷构建 golden set 的方法或 unapproved correction 的阻断控制，且能被追问 10 分钟不失守。

Day 22: Finance Reconciliation Exception Explainer

• 业务问题: 月末对账差异来自总账, 子账, 支付流水, 发票, 调整分录和时间差, 财务团队需要大量人工查找原因。
• AI 机会: AI 聚合证据, 生成差异原因候选, 推荐下一步核查, 草拟 reconciliation note, 不自动入账或改分录。

先做题（30-60 分钟，做完再看参考答案）

• 空白产出：闭卷写出 ①AS-IS/TO-BE 流程要点与干系人 ②MVP 边界与成功指标 ③架构组件链 ④eval/风险/adoption 要点 ⑤当天产物清单。
• 提示：职责分离（segregation of duties）是底线——先列全差异类型清单（别漏时间差和汇兑），再想哪一步绝不能让 AI 碰分录。

参考答案

• 业务分析任务: 定义 exception types: timing difference, duplicate, missing invoice, fee mismatch, FX difference, manual adjustment; 定义 approval 和 segregation of duties。
• 产品与价值判断: MVP 选 payment/settlement reconciliation; 指标为 time-to-explanation, accepted explanation rate, unresolved aging, audit adjustment。
• Architect 设计点: GL/subledger/payment/invoice connectors -> matching engine -> exception classifier -> evidence retriever -> explanation generator -> finance approval。
• Eval/Risk/Adoption: 测试解释准确性, evidence completeness, inappropriate action prevention; 风险包括财务误导, unauthorized adjustment, data freshness; adoption 从 read-only note draft 开始。
• 当天产物: reconciliation exception taxonomy, data mapping table, explanation template, approval control。

常见错误（对照空白产出自查）

• 让 AI 自动入账或调整分录，破坏 segregation of duties 与 approval 链。
• exception taxonomy 不全（漏 timing difference / FX difference / manual adjustment），解释器无从分类。
• 指标只看 time-to-explanation，缺 accepted explanation rate 与 unresolved aging。

评分标准

• 2 分（合格）：五项空白产出齐全且能自圆其说。
• 3 分：read-only note draft 定位 + 完整 exception taxonomy + finance approval 流程明确。
• 4 分：额外覆盖 data freshness 对解释正确性的影响或 audit adjustment 的闭环证据设计，且能被追问 10 分钟不失守。

Day 23: AI Vendor Model Due Diligence And Build Vs Buy

• 业务问题: 企业采购 AI 平台或模型供应商时, 常只比较演示效果和价格, 忽略数据保护, model risk, SLA, exit plan, eval ownership 和集成成本。
• AI 机会: 建立 vendor due diligence framework, 评估 foundation model, RAG platform, contact center AI, fraud AI 或 document AI 的适配性。

先做题（30-60 分钟，做完再看参考答案）

• 空白产出：闭卷写出 ①AS-IS/TO-BE 流程要点与干系人 ②MVP 边界与成功指标 ③架构组件链 ④eval/风险/adoption 要点 ⑤当天产物清单。
• 提示：别只比 demo 和价格——先想三个最容易被漏掉的维度：怎么退出、eval 由谁做主、供应商静默更新模型时你怎么发现。

参考答案

• 业务分析任务: 收集业务需求, 数据类型, 合规限制, integration needs, operational support, vendor documentation; 设计 vendor response matrix。
• 产品与价值判断: build vs buy 不只看速度; 比较 total cost, differentiation, lock-in, control, time-to-market, internal capability; 明确 pilot success criteria。
• Architect 设计点: 评估 deployment model, data residency, encryption, audit logs, API limits, eval hooks, observability, fallback, portability。
• Eval/Risk/Adoption: 要求供应商通过企业 golden set, red-team, latency/cost test; 风险包括 data leakage, opaque model update, SLA failure, weak deletion controls。
• 当天产物: vendor scorecard, build-vs-buy decision memo, contract control checklist, exit plan sketch。

常见错误（对照空白产出自查）

• 只比较演示效果和价格，漏掉 exit plan、data deletion controls 与 lock-in 成本。
• 把 eval ownership 交给供应商，没有要求通过企业自己的 golden set 与 red-team。
• build vs buy 只算 time-to-market，不算 total cost、differentiation 与 internal capability。

评分标准

• 2 分（合格）：五项空白产出齐全且能自圆其说。
• 3 分：vendor scorecard 覆盖 data residency/audit logs/eval hooks/portability，且要求自有 golden set 验证。
• 4 分：额外给出 opaque model update 的合同控制（version pinning/change notice）或退出演练方案，且能被追问 10 分钟不失守。

Day 24: AI Quality Dashboard Across Use Cases

• 业务问题: 多个 AI 助手上线后, 管理层只听到 adoption 或 demo 反馈, 但看不到质量, 风险, 成本, 漂移, 投诉和业务价值的综合状态。
• AI 机会: 设计 AI quality dashboard, 汇总 offline eval, online quality, user feedback, incident, cost, latency, business KPI 和 adoption。

先做题（30-60 分钟，做完再看参考答案）

• 空白产出：闭卷写出 ①AS-IS/TO-BE 流程要点与干系人 ②MVP 边界与成功指标 ③架构组件链 ④eval/风险/adoption 要点 ⑤当天产物清单。
• 提示：dashboard 是治理工具不是汇报工具——每放一个指标先问：它变红时会触发什么动作、由谁执行？

参考答案

• 业务分析任务: 定义指标字典, 数据来源, owner, refresh cadence, severity, drill-down; 区分每个 use case 的 guardrail metric。
• 产品与价值判断: Dashboard 服务治理决策, 不是炫技; 指标必须能触发 continue, pause, rollback, retrain, knowledge update, training 的动作。
• Architect 设计点: App logs -> eval service -> feedback store -> incident system -> cost telemetry -> BI layer -> governance dashboard -> alert workflow。
• Eval/Risk/Adoption: 检查 dashboard 自身的数据质量和解释一致性; 风险包括 vanity metrics, false confidence, missing denominator; adoption 通过 monthly AI governance meeting 使用。
• 当天产物: AI metrics hierarchy, dashboard wireframe in text, alert rule table, governance action playbook。

常见错误（对照空白产出自查）

• 堆 vanity metrics（调用量/满意度），指标触发不了 continue/pause/rollback/retrain 任何治理动作。
• 漏掉 denominator 与 dashboard 自身数据质量校验，给管理层 false confidence。
• 没有区分各 use case 的 guardrail metric，用一套指标硬套所有场景。

评分标准

• 2 分（合格）：五项空白产出齐全且能自圆其说。
• 3 分：指标字典带 owner/refresh cadence/severity，且每个关键指标挂接明确的治理动作。
• 4 分：额外设计 dashboard 数据质量自检机制或 alert 分级防疲劳策略，且能被追问 10 分钟不失守。

Day 25: Week 5 AI Architecture Review Board Pack

• 业务问题: AI use case 如果没有 gate, 容易在数据未准备, 风险未识别, eval 不充分, owner 不清的情况下进入 pilot 或 production。
• AI 机会: 为任一前 24 天案例准备 Architecture Review Board pack, 覆盖 G0 intake 到 G7 release 的核心证据。

先做题（30-60 分钟，做完再看参考答案）

• 空白产出：闭卷写出 ①AS-IS/TO-BE 流程要点与干系人 ②MVP 边界与成功指标 ③架构组件链 ④eval/风险/adoption 要点 ⑤当天产物清单。
• 提示：评审 pack 的骨架是证据链——逐个 gate 想「缺哪种证据会被打回」，并准备好用 option analysis 给出可辩护的 recommendation。

参考答案

• 业务分析任务: 准备 business fit, stakeholder evidence, process map, data readiness, requirements-to-eval, risk/control, adoption plan。
• 产品与价值判断: 用 option analysis 给出 recommendation: reject, discovery, prototype, controlled pilot, limited release; 说明业务价值和风险边界。
• Architect 设计点: 提供 component view, sequence flow, data classification, access model, model/provider choice, logging, fallback, incident flow。
• Eval/Risk/Adoption: 明确 minimum release threshold, red-team results, owner sign-off, runbook, monitoring cadence; 设计 rollback trigger。
• 当天产物: AI architecture review pack, 深度审查审查材料, gate decision record。

常见错误（对照空白产出自查）

• 只给 component view，缺 data classification、access model 与 fallback/incident flow。
• recommendation 没有 option analysis（reject/discovery/prototype/controlled pilot/limited release），直接推上线。
• 没有 rollback trigger 与 monitoring owner，minimum release threshold 成了空数字。

评分标准

• 2 分（合格）：五项空白产出齐全且能自圆其说。
• 3 分：pack 覆盖 business fit 到 adoption plan 全链证据 + option analysis 给出明确 recommendation。
• 4 分：额外预答评审委员会最刁的追问（如数据未就绪时的降级路径、red-team 不过关时的处置），且能被追问 10 分钟不失守。

Day 26: Flagship Case Upgrade - AML Investigation Copilot

• 业务问题: 把 Day 1 从练习升级成系统证据 case, 展示你能处理高风险金融调查 AI, 而不是只做普通 RAG。
• AI 机会: 深化 AML copilot 的 business architecture, AI pattern, eval, controls, operating model 和 system narrative record。

先做题（30-60 分钟，做完再看参考答案）

• 空白产出：闭卷写出 ①AS-IS/TO-BE 流程要点与干系人 ②MVP 边界与成功指标 ③架构组件链 ④eval/风险/adoption 要点 ⑤当天产物清单。
• 提示：与 Day 1 的差异在深度不在重做——先盘点从练习升级到系统证据还缺哪些硬证据（对抗用例？审计日志粒度？分阶段 gate？），再决定补什么。
• 注意：升级对象的基线 = 已部署的 /aml-copilot（全库唯一 AML flagship，见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 第 8 节）；Day 1 的纸面产物是它的迭代输入，不要另起炉灶。

参考答案

• 业务分析任务: 完成 redacted sample case: alert reason, customer profile, transaction timeline, red flags, missing evidence, investigator notes, supervisor QA。
• 产品与价值判断: 给出 phased roadmap: read-only evidence assistant -> narrative draft -> QA checklist -> typology learning; 每阶段都有 release gate。
• Architect 设计点: 补齐 evidence citation store, graph relationship view, typology library, prompt injection control, case-level audit log, access segmentation。
• Eval/Risk/Adoption: 建立 20 条 AML golden cases, 5 条 adversarial cases; 控制 SAR decision boundary, MLRO approval, QA sampling; adoption 使用 senior analyst champion。
• 当天产物: AML flagship case pack, evidence map, 系统摘要和复盘主线证据。

常见错误（对照空白产出自查）

• 把升级做成重做一遍 Day 1，没有新增 typology library、graph relationship view 与 access segmentation。
• phased roadmap 没有每阶段 release gate，从 read-only 直接跳到 narrative draft。
• golden cases 只有正例，缺 5 条 adversarial cases 与 prompt injection control 的验证。

评分标准

• 2 分（合格）：五项空白产出齐全且能自圆其说。
• 3 分：在 Day 1 基础上补齐 evidence citation store、case-level audit log、SAR decision boundary，并给出分阶段 gate。
• 4 分：额外给出 redacted sample case 的完整证据链或 MLRO approval / QA sampling 的量化抽检设计，且能被追问 10 分钟不失守。

Day 27: Flagship Case Upgrade - Customer Service RAG Assistant

• 业务问题: 把 Day 3 升级为低风险但高 adoption 的 flagship case, 展示你能把 RAG 做成 enterprise-grade product。
• AI 机会: 深化知识治理, answer quality eval, versioning, permissions, feedback loop 和 contact center ROI。

先做题（30-60 分钟，做完再看参考答案）

• 空白产出：闭卷写出 ①AS-IS/TO-BE 流程要点与干系人 ②MVP 边界与成功指标 ③架构组件链 ④eval/风险/adoption 要点 ⑤当天产物清单。
• 提示：enterprise-grade 的差异在治理与 ROI，不在检索技巧——先想知识由谁负责更新下架，以及 ROI 用什么保守假设才经得起 finance 追问。

参考答案

• 业务分析任务: 准备 30 条 representative queries, 5 条 conflict policy cases, 5 条 no-answer cases, 5 条 prompt injection cases。
• 产品与价值判断: 定义 MVP, pilot group, knowledge owner workflow, adoption dashboard; 计算 AHT reduction 和 QA defect reduction 的 conservative ROI。
• Architect 设计点: 补齐 chunking/reranking strategy, metadata filter, citation validator, policy conflict detector, CRM integration, live feedback pipeline。
• Eval/Risk/Adoption: 指标包括 answer groundedness, citation precision, policy version correctness, refusal correctness, agent helpfulness; adoption 设计 coach and QA loop。
• 当天产物: Customer service RAG flagship case pack, ROI model, eval set, adoption dashboard, 深度审查复盘材料。

常见错误（对照空白产出自查）

• 只堆检索技术（chunking/reranking）不建知识治理——没有 knowledge owner workflow 与版本控制。
• ROI 用乐观口径（全量 AHT 下降），没有 conservative 假设与 QA defect reduction 佐证。
• eval set 缺 conflict policy / no-answer / prompt injection 三类边界用例。

评分标准

• 2 分（合格）：五项空白产出齐全且能自圆其说。
• 3 分：45 条用例分类齐全（30 代表 + 5 冲突 + 5 无答案 + 5 注入）+ knowledge owner workflow + conservative ROI。
• 4 分：额外给出 refusal correctness 的度量方法或 live feedback pipeline 的闭环设计，且能被追问 10 分钟不失守。

Day 28: Flagship Case Upgrade - Lending Underwriting Assistant

• 业务问题: 把 Day 6 升级为高风险受监管决策辅助 case, 展示你理解 credit decision, fairness, explainability 和 human oversight。
• AI 机会: AI 只进入 document summarization, policy checklist, memo draft, reason-code consistency, 不进入自动批贷。

先做题（30-60 分钟，做完再看参考答案）

• 空白产出：闭卷写出 ①AS-IS/TO-BE 流程要点与干系人 ②MVP 边界与成功指标 ③架构组件链 ④eval/风险/adoption 要点 ⑤当天产物清单。
• 提示：想清楚为什么「不自动化审批」本身就是方案卖点，以及计算、规则、叙事、理由码四类组件为何必须物理分离才能各自被审计。

参考答案

• 业务分析任务: 准备 sample loan package: application, income summary, debt profile, policy checklist, exception note, underwriter memo outline。
• 产品与价值判断: 说明为什么不把 approval 自动化作为 MVP; 路线为 historical file shadow eval -> live shadow mode -> assisted checklist -> controlled memo draft。
• Architect 设计点: 分离 deterministic calculation, policy rules, LLM narrative, reason-code service, underwriter attestation, audit record。
• Eval/Risk/Adoption: 设计 subgroup performance review, missing-risk detection, adverse action wording check, override logging; 控制 protected attribute exclusion 和 proxy review。
• 当天产物: Lending flagship case pack, fair lending controls, architecture ADR, model risk briefing, system review follow-up answers。

常见错误（对照空白产出自查）

• 把 deterministic calculation、policy rules、LLM narrative、reason-code 混在一个组件里，无法分别审计与回归。
• 说不清为什么不把 approval 自动化作为 MVP——把监管约束当障碍而不是设计输入。
• 缺 protected attribute exclusion 与 proxy review，subgroup performance review 没有分组方案。

评分标准

• 2 分（合格）：五项空白产出齐全且能自圆其说。
• 3 分：四层组件分离 + 分阶段路线（shadow eval→live shadow→assisted checklist→controlled memo draft）+ fair lending 控制清单。
• 4 分：额外准备 model risk briefing 的追问预案（如 override logging 如何防止形同虚设、adverse action wording 的回归检查），且能被追问 10 分钟不失守。

Day 29: Executive Decision Memo For AI Investment

• 业务问题: 高层不会因为 "用了 AI" 批预算, 需要看到明确业务损耗, 可控方案, 投资选项, 风险边界, ROI 和决策请求。
• AI 机会: 从前三个 flagship case 中选一个, 写 executive decision memo, 请求进入 controlled pilot 或 limited release。

先做题（30-60 分钟，做完再看参考答案）

• 空白产出：闭卷写出 ①AS-IS/TO-BE 流程要点与干系人 ②MVP 边界与成功指标 ③架构组件链 ④eval/风险/adoption 要点 ⑤当天产物清单。
• 提示：高管看的是决策请求不是技术方案——先想投资选项怎么摆才公允，以及你敢不敢把 stop criteria 白纸黑字写进 memo。

参考答案

• 业务分析任务: 汇总 problem evidence, stakeholder pain, process impact, data readiness, operational constraints, regulatory considerations。
• 产品与价值判断: 给出 3 个选项: no-AI/process improvement, limited AI copilot, broader workflow automation; 推荐一个并说明 trade-off。
• Architect 设计点: 用一页文字架构说明 integration, security, privacy, eval, monitoring, rollback; 不用模型术语堆砌。
• Eval/Risk/Adoption: 说明 pilot success criteria, stop criteria, RACI, runbook, review cadence, investment and operating cost。
• 当天产物: 2 页 executive decision memo, executive brief, one-page risk and ROI appendix。

常见错误（对照空白产出自查）

• memo 里堆模型术语而不是一页文字架构，高管看不到 integration/security/rollback 怎么落地。
• 只给一个方案，没有 no-AI process improvement / limited copilot / broader automation 三选项对比与 trade-off。
• 只写 pilot success criteria 不写 stop criteria 与 operating cost，决策请求不完整。

评分标准

• 2 分（合格）：五项空白产出齐全且能自圆其说。
• 3 分：三选项对比 + 明确推荐 + pilot success/stop criteria + 投资与运营成本齐全。
• 4 分：额外预判 CFO/CRO 各自最关心的追问并写进一页 risk and ROI appendix，且能被追问 10 分钟不失守。

Day 30: System Evidence Library And Design Review Pack

• 业务问题: 练习产出如果不能转成可审查证据, 就无法证明你真正理解复杂 AI 系统。
• AI 机会: 将 30 天材料整理成 evidence narrative library, 用需求流程、价值取舍、系统架构、评测治理四个视角复盘同一案例。

先做题（30-60 分钟，做完再看参考答案）

• 空白产出：闭卷写出 ①AS-IS/TO-BE 流程要点与干系人 ②MVP 边界与成功指标 ③架构组件链 ④eval/风险/adoption 要点 ⑤当天产物清单。
• 提示：检验标准是「可审查」——先把设计审查六问（AI 错了/如何证明有效/数据不够/合规不同意/用户不用/供应商换模型）逐一对到你的证据材料上，看哪问答不出来。

参考答案

• 业务分析任务: 为三个 flagship case 各写 problem, stakeholders, workflow, data, requirements, exceptions, acceptance。
• 产品与价值判断: 为三个 flagship case 各写 MVP, metrics, ROI, roadmap, go/no-go, adoption strategy。
• Architect 设计点: 为三个 flagship case 各写 architecture pattern, integration, context, eval, controls, observability, rollback。
• Eval/Risk/Adoption: 准备设计审查问题: AI 错了怎么办, 如何证明有效, 数据不够怎么办, 合规不同意怎么办, 用户不用怎么办, 供应商换模型怎么办。
• 当天产物: 系统摘要 x 3, 复盘主线 x 3, 深度审查 x 3, evidence checklist, final capability score。

常见错误（对照空白产出自查）

• 只做材料汇编不做证据映射——claim 对不上具体 evidence artifact，审查追问即失守。
• 三个 flagship 用同一套模板复述，没有体现低/中/高风险 case 的边界与控制差异。
• 设计审查问题只准备正面答案，没有「数据不够/合规不同意/用户不用」的降级预案。

评分标准

• 2 分（合格）：五项空白产出齐全且能自圆其说。
• 3 分：三个 flagship 各自完成四视角复盘（需求流程/价值取舍/系统架构/评测治理），且风险分层清晰。
• 4 分：每个 claim 都能指向具体 evidence artifact，并经得起任一设计审查问题的 10 分钟追问不失守。

---

9. 每周产出清单

Week 1 Output

• 4 个 use case canvas: AML, KYC, 客服知识, 支付争议。
• 4 张 TO-BE workflow。
• 1 张 AI fit comparison matrix。
• 1 个 shared platform capability map。

Week 2 Output

• 4 份 regulated decision support notes: 信贷, 欺诈, 财富, 催收。
• 1 张 risk-tiered capability matrix。
• 1 份 model risk and release gate memo。

Week 3 Output

• 4 个 operations copilot / agent workflow 设计。
• 1 份 RACI。
• 1 份 incident runbook。
• 1 张 AI operations dashboard。

Week 4 Output

• 4 个零售运营 AI case。
• 1 套 prediction-to-decision framework。
• 1 张 retail AI shared architecture sketch。

Week 5 Output

• 1 个合规报送 quality control pack。
• 1 个财务对账 exception explainer pack。
• 1 份 vendor due diligence scorecard。
• 1 张 AI quality dashboard。
• 1 份 architecture review board pack。

Week 6 Output

• 3 个 flagship case pack。
• 1 份 executive decision memo。
• 1 套 system narrative record bank。
• 1 份 evidence checklist。

---

10. 最终系统证据包

30 天结束后, 把材料整理成以下 12 个 evidence artifacts:

1. AI use case selection matrix。
2. AML Investigation Copilot case pack。
3. Customer Service RAG Assistant case pack。
4. Lending Underwriting Assistant case pack。
5. Requirements-to-eval matrix sample。
6. AI control register sample。
7. Architecture ADR sample。
8. Operating model RACI。
9. AI quality dashboard design。
10. Executive decision memo。
11. System evidence narrative library。
12. Evidence map: 每个 claim 对应哪份证据。

每个 case pack 推荐包含:

• 核心业务问题。
• AS-IS / TO-BE 流程。
• AI pattern 和 no-AI alternative。
• 输入、输出、数据源、权限。
• Requirements-to-eval matrix。
• Risk/control register。
• Architecture sketch。
• Pilot and adoption plan。
• ROI 和 success metrics。
• 系统摘要、复盘主线、深度审查问题。

---

11. 案例复盘框架

每个 case 从四层复盘, 不再按短讲模板组织。

11.1 系统摘要

Case:
Business loss:
AI boundary:
System pattern:
Eval contract:
Key controls:
Operating metric:
Open risk:

要求: 摘要必须能让审查者在一页内看到系统边界, 不能只写“用了 RAG / Agent”。

11.2 复盘主线

1. Context: 业务流程和损耗。
2. Boundary: AI 读什么、写什么、不能做什么。
3. Decision: 为什么选择这个 AI pattern, 为什么不自动化最终决策。
4. Design: 流程、数据、架构、eval、controls。
5. Operation: 目标指标、pilot 方式、adoption、runbook。
6. Reflection: 最大风险、剩余假设和下一轮证据。

11.3 深度审查

1. Business architecture: capability, workflow, stakeholders, baseline。
2. Product strategy: MVP, success metric, ROI, roadmap, adoption。
3. Solution architecture: components, data flow, context, model/provider, integration。
4. EvalOps: golden set, metrics, thresholds, monitoring, regression。
5. Risk and governance: human oversight, audit, privacy, security, model risk, incident。
6. Trade-offs: speed vs control, automation vs accountability, build vs buy, accuracy vs explainability。
7. Decision request: pilot, funding, gate, owner。

11.4 设计审查问题

---

12. 自评与复盘方法

每日复盘

回答 5 个问题:

1. 这个 case 的业务 baseline 是否足够具体。
2. AI 插入点是否清楚, 是否避免了过度自动化。
3. eval 是否能真的阻止错误上线。
4. 风险控制是否有 owner, trigger 和 evidence。
5. 复盘主线是否能讲清价值、边界和剩余风险。

每周复盘

给本周 5 个 drill 排序:

• 最适合升级为系统证据的 1 个。
• 最能体现需求与流程能力的 1 个。
• 最能体现价值取舍能力的 1 个。
• 最能体现系统架构能力的 1 个。
• 最大风险但最值得深挖的 1 个。

最终复盘

用以下句式总结 30 天:

我通过 30 个金融零售 AI case drill, 建立了从 business problem 到 AI architecture, eval, risk control 和 adoption 的完整方法。
我最强的三个案例是 [case 1], [case 2], [case 3]。
它们分别展示我能处理 [低风险知识助手], [中风险运营 copilot], [高风险受监管决策辅助]。
我的核心方法不是追逐模型能力, 而是把 AI 放进可审计, 可评估, 可采用的业务流程。

---

13. 最终原则

AI case drill 的质量不取决于术语多少, 而取决于你能否把一个真实业务问题变成:

• 可证据化的问题定义。
• 可执行的流程改变。
• 可测试的需求。
• 可解释的架构。
• 可控的风险。
• 可持续的 adoption。
• 可复盘的系统证据。

金融零售 AI 的成熟表达是:

I do not start from the model.
I start from the workflow, decision rights, evidence, controls and adoption path.
Then I decide where AI can responsibly create value.

---

SOTA 检查 (2026-07-01)

• 本 workbook 为场景演练题库（第二遍输出层，见 AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md §9），场景设定不依赖具体模型版本；涉及的架构模式时效性以各配套 playbook 的 SOTA 段为准。
• 2026-07-01 完成「题面先行」结构升级（质量标准 §3.6/P1 项）。