AI 扩展计划 / Playbooks

AI 面试作品集叙事 Playbook

复用资产:

627 行AI_INTERVIEW_PORTFOLIO_STORYLINE_PLAYBOOK.md

AI Interview Portfolio Storyline Playbook

目标: 把已有 AI, BA, PM, 架构, EvalOps, 金融零售和 Web3 学习资产转成面试可讲, 作品集可看, 招聘方可验证的证据叙事. 定位: 本文件是 higher-level storyline layer, 不替代旧学习计划, 不删除旧笔记, 不重写已有 case. 它把已有资产包装成 job-market evidence. 使用范围: 学习和面试准备 guidance, 不是法律意见, 合规意见或监管解释. 标准和法规只作为方法锚点.

0. Use This With Existing Assets

复用资产:

docs/abpa/interview/AI_BA_PM_ARCHITECT_INTERVIEW_BANK.md: 面试题库, STAR-T, eval, control, ROI.
docs/abpa/templates/12-portfolio-evidence-map.md: claim-to-evidence, proof pack, freshness label.
docs/AI_ROLE_COMPETENCY_MATRIX_2026.md: AI BA, AI PM, AI Solutions Architect, EvalOps, FDE 角色边界.
docs/FINANCIAL_RETAIL_AI_CASE_PORTFOLIO.md: 金融零售 AI case source.
docs/AI_ARCHITECTURE_DIAGRAM_PLAYBOOK.md: Capability Map, BPMN, C4, RAG, Agent, Eval, Risk/Control 图谱.

本文件新增价值:

把 "学过什么" 转成 "能证明什么".
把每个 case 压缩成 30 秒, 2 分钟, deep-dive 三种讲法.
把同一个 case 按岗位切换表达.
把标准, 架构, eval, control, adoption, ROI 统一到同一条 storytelling spine.

核心原则:

Preserve old learning assets -> Select evidence -> Package storyline -> Rehearse proof -> Refresh gaps

1. Source And Standard Anchors

这些 anchor 不需要背全文. 面试中要把它们转成 artifact, control, eval, architecture decision, operating model.

Anchor	面试中如何使用	可展示 artifact
NIST AI RMF	用 Govern, Map, Measure, Manage 说明 AI risk lifecycle	AI Control Pack, release gate, monitoring plan
EU AI Act	用 risk-based lens 说明 high-risk context, transparency, human oversight	Risk classification memo, audit evidence
ISO/IEC 42001	用 AI management system 语言讲 accountability 和 continual improvement	AI operating model, RACI, governance cadence
OWASP LLM Top 10	用 prompt injection, sensitive information disclosure, excessive agency 设计 controls	Threat model, red-team backlog, tool permission matrix
TOGAF	用 capability, target architecture, roadmap, architecture governance 讲转型	Capability map, architecture review pack
BPMN	用 AS-IS, TO-BE, exception flow, handoff, human task 表达流程	BPMN process map, pain metrics
BIAN	用 banking service domain 组织金融零售 capability 和 integration boundary	Domain map, service boundary

Interview translation:

不说 "我熟悉 NIST AI RMF". 要说 "我把 Govern, Map, Measure, Manage 转成 control register, eval gate, incident review 和 owner cadence".
不说 "我了解 EU AI Act". 要说 "在 credit 或 wealth compliance 场景里, 我先界定 decision boundary, human oversight, documentation 和 audit trail".

2. Role Positioning Narratives

Role	Positioning narrative	Hiring team validates	Lead evidence	Weak answer to avoid
AI Solutions Architect	我把金融零售业务流程, 数据边界, RAG/Agent 架构, eval gate, risk control, observability 和 implementation constraints 连成可落地的 AI solution.	能否从业务流程推导系统边界, 解释 RAG/agent/rules/vendor/custom build 取舍, 处理权限, 审计, latency, cost, fallback.	C4, ADR, data readiness, eval architecture, risk/control architecture, runbook.	"我会接模型 API, 用向量数据库, 做 chatbot."
AI Business Architect	我把企业 AI 机会从单点 use case 提升到 capability map, value stream, operating model, governance 和 transformation roadmap.	能否把高层 AI 战略落到业务能力, 处理效率/合规/数据/技术冲突, 组合 portfolio.	AI capability map, case portfolio, cross-case pattern, business case, RACI.	"我负责推动公司用 AI, 大家都可以提需求."
AI PM	我负责把 AI 机会变成可验证的用户价值, MVP scope, success metrics, eval gate, launch plan 和 adoption loop.	能否选择 worth-building opportunity, 定义 trust/quality/outcome/adoption/ROI, 平衡速度和风险.	Opportunity canvas, PRD, metric tree, requirements-to-eval, adoption dashboard, executive memo.	"我会设计 AI 功能, 用户可以聊天, 效率会提升."
AI BA	我把模糊 AI 需求转成业务问题证据, stakeholder map, BPMN workflow, decision rules, requirements-to-eval 和 acceptance criteria.	能否区分 pain/want/constraint, 建模 exception path 和 handoff, 把需求变成 eval.	Stakeholder map, BPMN, requirements-to-eval, decision inventory, data readiness inputs.	"我会收集需求, 然后让技术团队实现 AI."
EvalOps/Product Ops	我把 AI quality 从一次性测试变成持续运营, 包括 golden dataset, eval suite, release gate, monitoring, feedback loop 和 incident review.	能否定义上线门槛, 监控 drift/retrieval/unsupported claims/override/cost, 把反馈接回 roadmap.	Eval design, release gate, quality dashboard, feedback taxonomy, incident review.	"上线后看用户反馈, 有问题再调 prompt."
FDE/Forward Deployed AI Engineer	我能在客户现场从 ambiguous problem 出发, 快速做 discovery, prototype, integration, eval, pilot, handoff.	能否处理 messy data, legacy systems, changing requirements, 并把 demo 变成可运营 pilot.	Field notes, prototype README, integration assumptions, pilot report, handoff checklist.	"我现场快速帮客户做一个 AI 工具."

Role-specific strong lines:

AI Solutions Architect: "我不把 LLM 当成系统中心, 我把 workflow, evidence, policy, eval, control 和 audit log 当成系统中心."
AI Business Architect: "我把 AI transformation 讲成 capability change, 不讲成 tool rollout."
AI PM: "我不会用 usage 替代 value, 我会同时看 task success, quality, trust, control, and business impact."
AI BA: "AI BA 的核心不是写 prompt, 是把不确定需求变成可验证的业务和质量契约."
EvalOps: "对 AI 产品来说, eval 是产品能力, 不是 QA 后置工作."
FDE: "我不是只交 demo, 我会把 demo 推到客户 workflow, eval gate, operating owner 和 handoff pack."

3. Reusable Storytelling Framework

所有 portfolio story 都用同一条主线:

Claim -> Evidence -> Architecture -> Eval -> Control -> Business Value -> Adoption -> Reflection

Layer	面试中要说清楚什么	Strong proof	Weak pattern
Claim	你要证明的能力, 不是职位愿望	"我能把高风险金融运营设计成 HITL copilot."	"我熟悉 AI."
Evidence	可展示, 可追问, 可复述的资产	diagram, matrix, PRD, ADR, dashboard, prototype, eval set	只有学习笔记
Architecture	workflow, data, AI pattern, integration, control, operating boundary	C4, BPMN, RAG/Agent, risk architecture	只有 LLM box
Eval	需求如何变成上线门槛	requirement, eval data, grader, threshold, owner, cadence	只说准确率
Control	为什么能在 regulated setting 使用	preventive, detective, corrective, governance controls	prompt 当控制
Business Value	baseline 到 outcome 的变化	cycle time, QA defect, backlog, loss avoided, ROI	"效率提升" 无基线
Adoption	用户如何安全改变工作方式	activation, repeat usage, override, trust, manager cadence	培训完成即 adoption
Reflection	证据如何改变判断	assumption -> evidence -> decision -> residual risk -> next step	只讲成功

Minimum proof pack for each story:

One artifact link.
One metric or eval.
One architecture decision.
One risk control.
One adoption or business value signal.
One reflection sentence.

Architecture rehearsal question:

If this AI system fails, where would you notice it, who owns it, and how do you stop damage?

Eval categories to reuse:

Groundedness and citation accuracy.
Retrieval hit rate and source freshness.
Red flag recall.
Unsupported claim rate.
Policy violation rate.
Human override rate.
Latency and cost per task.
Adoption and trust.

Control categories to reuse:

Preventive: RBAC, source allowlist, policy guardrail, tool permission, PII minimization.
Detective: citation validation, output monitoring, audit sampling, anomaly alerts.
Corrective: fallback, rollback, human escalation, incident review, eval set refresh.
Governance: release gate, model change approval, owner cadence, risk acceptance.

Interview rule:

Never describe high-risk financial AI as autonomous final decisioning unless the case explicitly supports it.

Reflection structure:

What I first assumed -> What evidence changed -> What I decided -> What risk remained -> What I would improve next

4. Flagship Story Selection Matrix

Story	Best role fit	Risk level	Best proof angle	First artifact to show
AML Copilot	AI Solutions Architect, AI BA, EvalOps	High	Investigation workflow, red-flag eval, control pack	BPMN + requirements-to-eval
KYC Remediation	AI BA, AI PM, Business Architect	High	Data quality, remediation workflow, customer outreach	Opportunity canvas + data readiness
Customer Service RAG	AI PM, Solutions Architect	Medium	RAG governance, agent assist, adoption metrics	RAG architecture + adoption dashboard
Payments Exception Agent	FDE, Solutions Architect, PM	Medium	Exception workflow, tool-use boundary, ROI	Sequence diagram + control matrix
Lending Assistant	Solutions Architect, EvalOps, Business Architect	High	Decision support, fair lending, reason codes	Control pack + ADR
Fraud Operations	FDE, PM, Solutions Architect	High	Speed-control tradeoff, action agency levels	Agent workflow + permission matrix
Regulatory Change Impact	Business Architect, BA, Solutions Architect	High	Capability impact, obligation mapping, governance	Capability heatmap + executive memo
Wealth Compliance Guardrail	PM, EvalOps, Solutions Architect	High	Policy guardrails, advisor workflow, supervision	Risk/control architecture
Product Knowledge RAG	PM, BA, FDE	Low/Medium	Low-risk MVP, eval set, content governance	Data readiness + eval set
AI Governance/EvalOps Platform	EvalOps, Business Architect, Solutions Architect	Enterprise	Platform operating model, release gates, monitoring	Eval architecture + governance dashboard

5. Flagship Portfolio Stories

Story 01: AML Copilot

Target roles: AI Solutions Architect, AI BA, EvalOps/Product Ops, AI Business Architect.
30-second pitch: AML Copilot 的核心不是让模型决定是否提交 SAR, 而是帮助 investigator 更快聚合证据, 检查 red flags, 生成有 citation 的 case narrative, 并保留 human approval 和 audit trail. 我会把它设计成 RAG + workflow copilot + control pack, 用 evidence recall, citation precision, unsupported claim rate, QA rework 和 cycle time 衡量是否值得扩展.
2-minute version: Context: analyst 在 alerts, KYC, adverse media, sanctions, historical cases, SOP 之间切换. Claim: 高风险合规工作要做 decision support, 不是 autonomous decision engine. Architecture: Case UI -> orchestration -> rules/policy -> retrieval -> transaction/entity features -> summarizer -> reviewer workflow -> audit log. Eval: evidence coverage, red flag recall, citation precision, unsupported claim rate. Control: no autonomous SAR decision, maker-checker, RBAC, source citation, stop rule. Value: time-to-first-draft, QA defect, case completeness. Adoption: evidence summary pilot -> narrative draft.
Deep-dive structure: Claim: 可审计的人机协同调查系统. Evidence: BPMN, requirements-to-eval, control pack, redacted before/after narrative. Architecture: evidence retrieval, checklist, draft, review, decision 分层. Eval: critical miss 不能被 overall accuracy 掩盖. Control: NIST AI RMF + OWASP LLM controls. Business Value: backlog, touch time, QA rework, audit issue. Adoption: trust 来自 citation, editable draft, override capture. Reflection: first feature should be evidence pack and missing evidence prompt.
Evidence artifacts to show: docs/FINANCIAL_RETAIL_AI_CASE_PORTFOLIO.md, docs/abpa/templates/03-bpmn-pain-metrics.md, docs/abpa/templates/04-requirements-to-eval-matrix.md, docs/abpa/templates/05-ai-control-pack.md, docs/AI_ARCHITECTURE_DIAGRAM_PLAYBOOK.md.
Likely interviewer follow-ups: How do you prevent hallucinated AML conclusions? What is the minimum release gate? What should the model never do? How do you handle analyst over-reliance?
Weak answer to avoid: "AML 很适合 AI, 因为模型可以自动分析交易并判断可疑行为."

Story 02: KYC Remediation

Target roles: AI BA, AI PM, AI Business Architect, FDE.
30-second pitch: KYC remediation 的价值不在于生成客户邮件, 而在于把 data quality gaps, policy validation, document collection, customer outreach, reviewer approval 和 customer master update 串成可审计闭环. AI 做 gap classification, outreach draft, document extraction 和 prioritization, 高风险客户和 UBO 变更进入人工审批.
2-minute version: Context: 周期 review 或 regulatory remediation 中, UBO, tax, source of funds 等字段缺失. Claim: 数据质量和客户体验可设计成 AI-assisted remediation workflow. Architecture: data quality engine -> gap classifier -> risk queue -> outreach generator -> OCR/extraction -> policy RAG -> reviewer workbench -> golden source update. Eval: missing-field recall, extraction accuracy, invalid-document false accept, cycle time. Control: PII minimization, jurisdiction policy, approved messaging, source lineage. Value: backlog burn-down, days to complete, manual touches, deadline hit rate. Adoption: expired ID reminder 起步.
Deep-dive structure: Claim: data + workflow + compliance + customer communication. Evidence: opportunity canvas, data readiness, BPMN, control register, dashboard. Architecture: classifier, RAG, OCR, CRM task, golden source update 分层. Eval: false accept 比 false reject 更危险. Control: high-risk customers, UBO changes, sanctions/PEP mandatory review. Business Value: SLA, backlog, contact success. Adoption: RM/Ops 需要 clear priority 和 status. Reflection: bottleneck 可能是 source-of-truth ownership.
Evidence artifacts to show: docs/FINANCIAL_RETAIL_AI_CASE_PORTFOLIO.md, docs/abpa/templates/01-ai-opportunity-canvas.md, docs/abpa/templates/07-data-readiness-pack.md, docs/abpa/templates/05-ai-control-pack.md, docs/abpa/templates/10-adoption-dashboard.md.
Likely interviewer follow-ups: How do you handle jurisdiction policies? What data should not enter model context? How do you prevent invalid documents? What is the no-AI boundary?
Weak answer to avoid: "AI 可以自动补齐客户 KYC 信息."

Story 03: Customer Service RAG

Target roles: AI PM, AI Solutions Architect, AI BA, EvalOps.
30-second pitch: Customer Service RAG 的目标不是建 generic chatbot, 而是让客服在已认证客户上下文和 approved knowledge base 之间更快给出准确, 有引用, 可审计的答复. 我会把知识治理, metadata, effective date, citation, no-answer behavior, policy guardrail 和 QA feedback 放在产品核心.
2-minute version: Context: agents 在 CRM, core system, KB, SOP, complaint rules 之间切换. Claim: RAG 要从 demo 变成 governed agent-assist product. Architecture: desktop -> authenticated context -> intent detector -> knowledge RAG -> policy guardrail -> response composer -> QA analytics. Eval: correctness, citation coverage, retrieval recall, policy violation, no-answer correctness, AHT, CSAT. Control: no disclosure before authentication, RBAC retrieval, source versioning, stale content block. Value: AHT, FCR, transfer rate, QA defect, ramp time. Adoption: internal assist first.
Deep-dive structure: Claim: service AI 是受控知识和客户上下文的工作流助手. Evidence: RAG spec, eval matrix, dashboard, memo. Architecture: RAG 不替代 authorized account tools. Eval: answer must satisfy correctness, citation, compliance, escalation. Control: no-answer path 比编造答案重要. Business Value: AHT and QA score together. Adoption: source link, editability, feedback. Reflection: key dependency is knowledge management maturity.
Evidence artifacts to show: docs/FINANCIAL_RETAIL_AI_CASE_PORTFOLIO.md, docs/AI_ARCHITECTURE_DIAGRAM_PLAYBOOK.md, docs/abpa/templates/04-requirements-to-eval-matrix.md, docs/abpa/templates/08-ai-architecture-adr-set.md, docs/abpa/templates/10-adoption-dashboard.md.
Likely interviewer follow-ups: How do you handle outdated articles? What if sources conflict? Agent-facing or customer-facing first? How do you prioritize MVP intents?
Weak answer to avoid: "把知识库放进向量数据库, 客服就可以问问题."

Story 04: Payments Exception Agent

Target roles: FDE, AI Solutions Architect, AI PM, AI BA.
30-second pitch: Payments exception handling 适合展示 bounded agent thinking. AI 可以查询 payment status, 识别 return reason, 生成 investigation summary, 推荐 next action, pre-fill case tasks, 但 refund, reversal, manual repair, customer communication 必须受权限, rule engine 和 human approval 控制.
2-minute version: Context: ACH, card, wire, instant payment 或 merchant settlement exception 跨 gateway, ledger, network code, dispute system, CRM. Claim: agent 是 bounded tool-use workflow, 不是 unrestricted automation. Architecture: queue -> status tool -> return code RAG -> ledger check -> summarizer -> recommender -> human approval -> action API -> audit log. Eval: taxonomy, source accuracy, recommendation precision, wrong-action prevention, tool-call success. Control: tool allowlist, least privilege, idempotency, action risk tiers, reconciliation. Value: aging, handoffs, investigation time, customer resolution. Adoption: assistant -> pre-fill -> low-risk task creation.
Deep-dive structure: Claim: agentic workflow 必须可控, 可回滚, 可审计. Evidence: sequence diagram, taxonomy, permission matrix, ROI model, runbook. Architecture: read-only tools 和 write/action tools 分层. Eval: final answer + tool path correctness. Control: excessive agency, injection, sensitive information disclosure 在 gateway 处理. Business Value: SLA and reconciliation breaks. Adoption: users need evidence, reason code, next step. Reflection: convenience 不能绕过 ledger controls.
Evidence artifacts to show: docs/FINANCIAL_RETAIL_AI_CASE_PORTFOLIO.md, docs/AI_ARCHITECTURE_DIAGRAM_PLAYBOOK.md, docs/abpa/templates/03-bpmn-pain-metrics.md, docs/abpa/templates/08-ai-architecture-adr-set.md, docs/abpa/templates/11-business-case.md.
Likely interviewer follow-ups: Which actions can be automated? How do you make tool calls idempotent? What if status sources disagree? How calculate ROI?
Weak answer to avoid: "Agent 可以自动处理支付异常并通知客户."

Story 05: Lending Assistant

Target roles: AI Solutions Architect, EvalOps, AI Business Architect, AI PM.
30-second pitch: Lending Assistant 不能被包装成黑盒 credit decision model. 我会把 deterministic calculations, policy eligibility, document summarization, reason-code suggestion, memo drafting 和 fair lending controls 分层. AI 辅助 underwriter, 但 regulated credit decision, adverse action, exception approval 保留人类责任和审计证据.
2-minute version: Context: 贷款审批整合 application, income, debt, collateral, bureau, policy, exception memo. Claim: regulated decision support, not LLM final decision. Architecture: LOS -> document processing -> financial extraction -> deterministic rules -> policy RAG -> underwriting assistant -> reason-code service -> review -> decision record. Eval: extraction, policy citation, missing-risk detection, memo completeness, reason-code consistency, subgroup performance. Control: fair lending review, no protected-class proxy, deterministic calculations separated from prose. Value: faster review, fewer rework cycles. Adoption: already decisioned files -> shadow mode.
Deep-dive structure: Claim: 区分 evidence, calculation, recommendation, decision. Evidence: requirements-to-eval, fair lending control pack, ADR, ROI. Architecture: rules/calculations deterministic, LLM handles explanation. Eval: reason-code consistency and subgroup error rates visible. Control: EU AI Act lens where applicable. Business Value: cycle time, committee prep, exception leakage. Adoption: citation, checklist, editable memo. Reflection: safer MVP is post-decision memo quality.
Evidence artifacts to show: docs/FINANCIAL_RETAIL_AI_CASE_PORTFOLIO.md, docs/abpa/templates/04-requirements-to-eval-matrix.md, docs/abpa/templates/05-ai-control-pack.md, docs/abpa/templates/07-data-readiness-pack.md, docs/abpa/templates/11-business-case.md.
Likely interviewer follow-ups: How prevent unfair treatment? How separate rules from LLM output? What data excluded? What stops rollout?
Weak answer to avoid: "模型可以根据客户资料判断是否批贷."

Story 06: Fraud Operations

Target roles: FDE, AI PM, AI Solutions Architect, EvalOps.
30-second pitch: Fraud Operations 的难点是速度和控制并存. AI 可以解释 alert, 聚合 device/session/transaction evidence, 生成 customer contact script, 推荐 next step, 但冻结账户, 拒赔, law enforcement referral 等动作需要按风险等级进入 analyst confirm 或 supervisor approval.
2-minute version: Context: fraud ops 面对 CNP, ATO, mule, scam reimbursement, false positives. Claim: action agency 分成 suggest, pre-fill, human approve, execute-with-control. Architecture: console -> entity resolution -> feature store -> rules/model score -> explainer -> recommendation -> approval -> action API. Eval: missed fraud, false positive friction, recommendation precision, explanation usefulness. Control: least privilege, redaction, high-risk approval, hallucinated rationale monitoring. Value: faster resolution, loss prevented, lower false positive hold time. Adoption: case explainer -> recommendations -> pre-filled actions.
Deep-dive structure: Claim: speed-control tradeoff. Evidence: TO-BE workflow, eval matrix, permission matrix, control pack, dashboard. Architecture: action gateway enforces risk tiers. Eval: false negative cost and false positive friction. Control: freeze, denial, legal escalation are gated. Business Value: loss avoided, MTTR, release time. Adoption: compact evidence timeline. Reflection: AI should not hide uncertainty.
Evidence artifacts to show: docs/FINANCIAL_RETAIL_AI_CASE_PORTFOLIO.md, docs/abpa/templates/03-bpmn-pain-metrics.md, docs/abpa/templates/04-requirements-to-eval-matrix.md, docs/abpa/templates/05-ai-control-pack.md, docs/abpa/templates/10-adoption-dashboard.md.
Likely interviewer follow-ups: Which actions need approval? Cost of false positive vs false negative? How capture analyst feedback? How avoid hallucinated rationale?
Weak answer to avoid: "Fraud 要快, 所以 AI 应该自动冻结和放行."

Story 07: Regulatory Change Impact

Target roles: AI Business Architect, AI BA, AI Solutions Architect, AI PM.
30-second pitch: Regulatory Change Impact 是展示 BA + architecture 的强案例. AI 不是给法律结论, 而是辅助 clause extraction, obligation mapping, impacted capability/process/system/control analysis, owner assignment 和 executive decision memo. 最终 interpretation 和 approval 由 legal/compliance 完成.
2-minute version: Context: 新规则, enforcement action, regulator letter 或 internal policy change 需要判断影响哪些产品, 流程, 系统, 控制. Claim: 文本变化转成 capability, process, system, control, roadmap. Architecture: intake -> clause extractor -> RAG -> BIAN mapper -> impact heatmap -> backlog -> owner review -> memo. Eval: obligation recall, false impact rate, owner accuracy, citation, backlog completeness. Control: legal review, source hierarchy, versioned register, change board. Value: shorter cycle, fewer missed assets, reduced workshops, audit readiness. Adoption: internal policy pilot first.
Deep-dive structure: Claim: structured impact analysis, not legal judgment. Evidence: heatmap, memo, RACI, control pack. Architecture: obligations map to internal assets, humans validate. Eval: missed obligation more severe than extra false impact. Control: citation, version, owner review, approval status. Business Value: speed, completeness, traceability. Adoption: one impact board. Reflection: connects text, policy, process, system, control.
Evidence artifacts to show: docs/FINANCIAL_RETAIL_AI_CASE_PORTFOLIO.md, docs/abpa/templates/06-executive-decision-memo.md, docs/abpa/templates/02-stakeholder-evidence-map.md, docs/abpa/templates/05-ai-control-pack.md, docs/abpa/templates/09-operating-model-raci.md.
Likely interviewer follow-ups: How prevent legal advice? What is source hierarchy? How map text to systems? Who owns final approval?
Weak answer to avoid: "AI 可以自动解读监管条文并告诉公司怎么改."

Story 08: Wealth Compliance Guardrail

Target roles: AI PM, EvalOps, AI Solutions Architect, AI BA.
30-second pitch: Wealth Compliance Guardrail 的好切入点不是让 AI 当投资顾问, 而是在 advisor 发出客户沟通或建议前做 suitability, disclosure, prohibited phrase, product eligibility 和 policy citation 检查. AI 可以做 pre-send review 和 rewrite suggestion, 但客户建议和交易指令仍由 licensed advisor 和 supervisory workflow 负责.
2-minute version: Context: advisor 解释产品, 风险, fee, suitability, market commentary, 但沟通不当会带来 mis-selling risk. Claim: AI guardrail 嵌入 workflow. Architecture: draft -> client/product context -> policy/suitability RAG -> prohibited detector -> rewrite -> advisor review -> supervisor sampling. Eval: violation detection, citation precision, false block, unsuitable recommendation detection. Control: suitability gates, templates, no unauthorized advice, supervision evidence. Value: lower defects, faster approval, fewer complaints. Adoption: generic draft checking -> client-specific suitability.
Deep-dive structure: Claim: compliance-by-design AI product. Evidence: guardrail matrix, control pack, RACI, before/after email. Architecture: checks sit before send. Eval: false negatives breach, false positives kill adoption. Control: human advisor owns message, AI shows policy basis. Business Value: review time, defects, complaints. Adoption: actionable rewrite, not only blocked. Reflection: UX must be strict and useful.
Evidence artifacts to show: docs/FINANCIAL_RETAIL_AI_CASE_PORTFOLIO.md, docs/AI_ARCHITECTURE_DIAGRAM_PLAYBOOK.md, docs/abpa/templates/04-requirements-to-eval-matrix.md, docs/abpa/templates/05-ai-control-pack.md, docs/abpa/templates/09-operating-model-raci.md.
Likely interviewer follow-ups: Hard-block versus warn? How handle jurisdiction rules? How prevent unsuitable advice? What evidence do supervisors review?
Weak answer to avoid: "AI 可以帮理财顾问写投资建议."

Story 09: Product Knowledge RAG

Target roles: AI PM, AI BA, FDE, AI Solutions Architect.
30-second pitch: Product Knowledge RAG 是最适合作品集 MVP 的 case, 因为风险相对低, 数据可控, 演示性强. 但我会强调它不是向量库 demo, 而是 content governance, metadata, effective date, source citation, conflict handling, no-answer behavior 和 eval set 的综合系统.
2-minute version: Context: 产品规则, fee schedule, eligibility, SOP, campaign terms 经常变化. Claim: 用低风险 case 展示 enterprise-grade RAG. Architecture: approved content -> ingestion -> chunking -> metadata -> hybrid retrieval -> rerank -> answer -> citation -> feedback queue. Eval: curated questions, expected source, citation precision, retrieval recall, stale content rejection, conflict detection. Control: content owner approval, retired content quarantine, RBAC retrieval, source allowlist. Value: lookup time, QA defect, search success, training time. Adoption: one product line, internal users.
Deep-dive structure: Claim: RAG 从 PoC 转成 governed knowledge product. Evidence: data readiness, eval set, RAG ADR, dashboard, sample Q/A. Architecture: source-of-truth remains document system. Eval: stale document traps and conflict traps. Control: no valid source means refuse or escalate. Business Value: faster lookup only counts with correctness. Adoption: knowledge owners own article fixes. Reflection: fastest credible first portfolio story.
Evidence artifacts to show: docs/FINANCIAL_RETAIL_AI_CASE_PORTFOLIO.md, docs/AI_ARCHITECTURE_DIAGRAM_PLAYBOOK.md, docs/abpa/templates/01-ai-opportunity-canvas.md, docs/abpa/templates/07-data-readiness-pack.md, docs/abpa/templates/04-requirements-to-eval-matrix.md.
Likely interviewer follow-ups: What metadata is required? How handle effective dates? How choose chunking? What is content governance workflow?
Weak answer to avoid: "把 PDF 放进向量库就能问答."

Story 10: AI Governance / EvalOps Platform

Target roles: EvalOps/Product Ops, AI Business Architect, AI Solutions Architect, AI PM.
30-second pitch: AI Governance/EvalOps Platform 是把多个 AI case 规模化的中台故事. 它不是审批官僚系统, 而是把 requirements, eval sets, release gates, monitoring signals, incidents, model/prompt versions, control evidence 和 adoption metrics 放进同一条 operating loop, 让 AI 产品持续可控.
2-minute version: Context: 多个 AI pilots 后, 质量口径不同, 控制证据分散, model/prompt 变更不可追踪. Claim: enterprise AI operating capability. Architecture: registry -> risk classification -> eval repository -> golden dataset -> eval runner -> release gate -> telemetry -> monitoring -> incident review. Eval: pass rate, regression failure, invalid citation, critical miss, override, latency, cost, feedback. Control: NIST AI RMF lifecycle, ISO/IEC 42001 accountability, OWASP controls, EU AI Act lens. Value: faster controlled rollout, fewer repeat defects, better audit readiness. Adoption: product teams get templates and dashboards.
Deep-dive structure: Claim: governance should be operational platform, not policy PDF. Evidence: eval architecture, release gate, dashboard, incident review, RACI. Architecture: platform supports cases, business owners keep decision accountability. Eval: domain evals plus shared signals. Control: risk tier determines artifacts and cadence. Business Value: reduce duplicate work, accelerate compliant launch. Adoption: governance must help PM and engineers. Reflection: governance must be a product.
Evidence artifacts to show: docs/AI_ROLE_COMPETENCY_MATRIX_2026.md, docs/AI_ARCHITECTURE_DIAGRAM_PLAYBOOK.md, docs/abpa/templates/04-requirements-to-eval-matrix.md, docs/abpa/templates/05-ai-control-pack.md, docs/abpa/templates/10-adoption-dashboard.md, docs/abpa/templates/12-portfolio-evidence-map.md.
Likely interviewer follow-ups: How avoid slowing teams? What is centralized vs product-owned? Minimum artifacts by risk tier? How do incidents update evals?
Weak answer to avoid: "我们需要一个 AI 治理委员会审批所有 AI 项目."

6. Portfolio Page And Deck Structure

Use one public portfolio page, one role-specific deck, and deep-dive appendices.

Public portfolio page sections:

Header: "AI Business Architect / AI Product Architect for Financial Retail AI".
One-sentence positioning: problem evidence -> AI architecture -> eval/control -> business value.
Role tags: AI Solutions Architect, AI PM, AI BA, EvalOps, FDE.
Flagship case cards: 3 to 5 strongest stories, not all 10.
Evidence map: each claim links to artifacts.
Standards anchor: NIST AI RMF, OWASP LLM Top 10, BPMN, TOGAF, BIAN, ISO/IEC 42001.
Historical assets: Web3, architecture, Solidity, AI notes are preserved as background learning assets.
Contact and target roles.

Case card format:

Case name:
Business problem:
My role lens:
AI pattern:
Artifacts:
Eval/control:
Business value:
What I learned:

Recommended 12-slide interview deck:

Positioning and target roles.
Evidence map: claims and proof assets.
Case portfolio overview.
Flagship Story 1: AML Copilot.
Flagship Story 2: Customer Service RAG or Product Knowledge RAG.
Flagship Story 3: Regulatory Change or AI Governance/EvalOps.
Architecture pattern: RAG, copilot, bounded agent, regulated decision support.
Eval and release gate.
Risk/control.
Adoption and ROI.
First 90 days.
Appendix index.

Deck rules:

Each case slide shows one problem, one artifact, one metric/eval, one control, one business value.
Do not lead with tool names.
Lead with "I can make regulated AI useful, measurable, and controllable".

Deep-dive appendix for each flagship story:

1-page case study.
BPMN AS-IS/TO-BE.
C4 or RAG/Agent architecture diagram.
Requirements-to-eval matrix.
Control pack.
Business case or ROI model.
Adoption dashboard.
Reflection note.

7. GitHub / README Structure

Suggested repository structure:

ai-financial-retail-portfolio/
  README.md
  cases/
    aml-copilot/
      README.md
      bpmn.md
      requirements-to-eval.md
      control-pack.md
      architecture-adr.md
    product-knowledge-rag/
      README.md
      data-readiness.md
      rag-architecture.md
      eval-set.md
      adoption-dashboard.md
    regulatory-change-impact/
      README.md
      capability-impact-map.md
      executive-memo.md
      operating-model-raci.md
  standards-map/
    nist-ai-rmf-map.md
    owasp-llm-top10-controls.md
    bpmn-bian-togaf-map.md
  interview/
    30-second-pitches.md
    2-minute-stories.md
    follow-up-questions.md

Top-level README outline:

# AI Financial Retail Portfolio

## Positioning
Financial retail domain + AI BA/PM/architecture + eval/control/adoption.

## What This Portfolio Proves
- Claim 1 -> Evidence link.
- Claim 2 -> Evidence link.
- Claim 3 -> Evidence link.

## Flagship Cases
| Case | AI pattern | Business value | Eval/control | Artifact |

## Architecture Patterns
RAG, copilot, bounded agent, regulated decision support, EvalOps platform.

## Standards Lens
NIST AI RMF, OWASP LLM Top 10, ISO/IEC 42001, BPMN, TOGAF, BIAN.

README anti-patterns:

Too many badges, too little evidence.
Code demo without business context.
Architecture diagram without tradeoffs.
Generic AI vocabulary without financial retail specificity.
Legal/compliance claims without disclaimer and human review boundary.

8. Interview Rehearsal Routine

Daily 45-minute routine:

5 minutes: Pick one role and one story.
5 minutes: Speak the 30-second pitch out loud.
10 minutes: Speak the 2-minute version without reading.
10 minutes: Answer 3 follow-ups.
10 minutes: Show one artifact and explain why it proves the claim.
5 minutes: Write one improvement note.

Weekly role rotation:

Day	Role lens	Story focus	Artifact focus
Monday	AI BA	KYC, Regulatory Change, AML	BPMN, stakeholder map, requirements-to-eval
Tuesday	AI PM	Customer Service RAG, Product Knowledge RAG, Wealth Guardrail	PRD, metric tree, adoption dashboard
Wednesday	AI Solutions Architect	AML, Payments, Lending	C4, ADR, RAG/Agent architecture
Thursday	EvalOps/Product Ops	AML, Lending, AI Governance	Eval suite, release gate, monitoring
Friday	FDE	Payments, Fraud, Product Knowledge RAG	Prototype README, integration assumptions, pilot report
Saturday	Business Architect	Regulatory Change, AI Governance, KYC	Capability map, roadmap, operating model
Sunday	Portfolio packaging	Best 3 stories	Deck, README, evidence map

Pressure-test prompts:

What would you cut from the MVP and why?
What is the most dangerous failure mode?
What data do you need, and what if it is not available?
What does the model never get to do?
Which metric would make you stop rollout?
How would this change the user's daily workflow?
How do you prove ROI without overclaiming?
How would you explain this to compliance?
How would you explain this to engineering?
How would you handle a skeptical frontline user?

Answer quality checklist:

Did I name the business problem?
Did I show evidence?
Did I identify human decision boundary?
Did I describe eval and control?
Did I connect to business value?
Did I mention adoption?
Did I include a tradeoff?
Did I avoid pretending AI is autonomous in regulated decisions?

9. Gap Remediation Plan

Role gap table:

Role	Likely current strength	Common gap	Remediation asset
AI BA	Process, domain, requirements thinking	More stakeholder evidence and exception flows	3 BPMN maps with pain metrics
AI PM	Case selection and business framing	Metrics and adoption baselines	3 metric trees and adoption dashboards
AI Solutions Architect	Architecture learning assets	More ADRs with tradeoffs and reversal triggers	3 architecture ADR sets
EvalOps/Product Ops	Eval concepts	Concrete sample eval cases and release gates	50-case golden set sample
FDE	Problem solving background	Working prototype and integration assumptions	Product Knowledge RAG demo README
Business Architect	Financial retail and architecture context	Portfolio-level capability roadmap	AI capability map and 12-month roadmap

Minimum viable proof pack before applying aggressively:

3 polished case studies.
1 role-specific deck.
1 public README.
1 evidence map.
1 architecture diagram per flagship case.
1 requirements-to-eval matrix per flagship case.
1 control pack for a high-risk case.
1 adoption dashboard draft.
1 business case or ROI model.
1 reflection note per case.

Fastest gap fixes:

Add a 30-second pitch to each existing case.
Add a "decision boundary" paragraph to each high-risk case.
Add one eval table to each case.
Add one control table to each case.
Add one business metric and one adoption metric.
Add "what I would do next" to prove reflection.
Add freshness labels to older Web3, architecture and AI notes.

Freshness labels:

Current: ready for portfolio and interview.
Needs refresh: useful but missing 2026 context, metric, diagram or eval.
Historical: preserved learning record, use as background only.
Draft: do not lead with it until improved.

Rule:

Never delete historical learning assets. Add a freshness label, update note, and portfolio angle.

10. 30/60/90-Day Interview Preparation Roadmap

Day 1-30: Package evidence foundation

Goal: turn raw assets into interview proof.

Weekly focus:

Week 1: Select target roles and top 10 claims.
Week 2: Pick 3 flagship stories and map evidence.
Week 3: Build 30-second and 2-minute scripts.
Week 4: Create first portfolio page and role-specific deck draft.

Concrete outputs:

Top 3 target role positioning statements.
Claim-to-evidence matrix.
10 story index.
3 deep-dive case pages.
1 standards anchor page.
First mock interview notes.

Quality gate:

Every claim has at least two evidence assets.
Every flagship story includes eval, control, business value, adoption.
No story depends only on "I learned about X".

Day 31-60: Build deep-dive credibility

Goal: make stories defensible under follow-up questions.

Weekly focus:

Week 5: Create architecture diagrams for 3 flagship stories.
Week 6: Create requirements-to-eval matrices and sample eval cases.
Week 7: Create control packs and governance mapping.
Week 8: Create adoption dashboards and ROI assumptions.

Concrete outputs:

AML Copilot deep-dive pack.
Product Knowledge RAG or Customer Service RAG deep-dive pack.
Regulatory Change or AI Governance deep-dive pack.
30 follow-up questions with answers.
Gap remediation tracker.

Quality gate:

You can explain why each architecture choice was made.
You can state one rejected alternative per case.
You can name release gates and stop rules.
You can explain what the model must never do.

Day 61-90: Interview execution and market iteration

Goal: convert portfolio into interview performance and job-market feedback.

Weekly focus:

Week 9: Run mock interviews by role.
Week 10: Publish portfolio v1 and README.
Week 11: Apply to target roles and collect feedback.
Week 12: Refresh weak stories and add missing artifacts.
Week 13: Prepare final interview loops and role-specific deep dives.

Concrete outputs:

Public portfolio v1.
Role-specific deck v1.
GitHub README or portfolio README.
Interview question bank customized to target companies.
Feedback log from applications and mocks.
Portfolio v1.1 with fixes.

Quality gate:

You can open any artifact in under 10 seconds during interview prep.
You can answer "what did you personally do?" without vague team language.
You can answer "how would this fail?" with concrete failure modes.
You can answer "how do you know it works?" with eval and production signals.
You can answer "why should we hire you?" with a portfolio-backed claim.

11. Role-Specific Closing Narratives

AI Solutions Architect:

My edge is connecting regulated financial workflows to AI architecture that is measurable and controllable. I can move from BPMN and domain requirements to RAG or agent architecture, ADRs, eval gates, audit logs, observability and rollout controls.

AI Business Architect:

My edge is translating AI ambition into capability change. I can map where AI creates value, what workflows and controls must change, which cases should be prioritized, and how governance and adoption scale across a portfolio.

AI PM:

My edge is productizing AI with eval and adoption built in. I define the user problem, MVP, quality gates, risk controls, launch metrics and feedback loop, so AI becomes a measurable product outcome rather than a demo.

AI BA:

My edge is turning ambiguous AI ideas into testable requirements. I use stakeholder evidence, workflow mapping, decision boundaries, requirements-to-eval and control requirements to make AI delivery concrete.

EvalOps/Product Ops:

My edge is making AI quality operational. I design golden datasets, release gates, monitoring signals, incident reviews and governance dashboards that keep AI systems useful after launch.

FDE:

My edge is working from messy real-world constraints to a working pilot. I can do field discovery, prototype quickly, integrate with systems, capture user feedback, define evals and hand off an operating solution.

12. Final Operating Principle

The portfolio should not say:

I studied AI, Web3, architecture and product management.

It should prove:

I can identify high-value AI opportunities, turn them into requirements and architecture, evaluate quality, control risk, measure business value, drive adoption, and explain tradeoffs clearly under interview pressure.

The strongest story is the one where the interviewer can see:

why the business problem matters.
what evidence you used.
how the architecture works.
how quality is evaluated.
how risk is controlled.
how value is measured.
how users adopt it.
what you learned and would improve next.