AI BA x Product x Architect 180-Day Plan

定位: AI 时代的业务分析师 / 产品经理 / 解决方案架构师融合训练。 目标: 把 10 年金融零售 PM+BA+dev 经验升级为可验证的 AI transformation 能力：能发现真问题、重构流程、定义可测需求、设计 AI 控制、推动落地和复盘收益。 适用对象: 已完成 Web3、架构、LLM、AIPA 等深度计划后，需要补强「业务分析 + 产品决策 + 架构落地 + 组织变革」的人。 节奏: 180 天，18 个 10 天 block。默认 10-15h/周；压缩模式可按 2-3 倍强度推进。 配套进度: docs/daily/ABPA_PROGRESS.md 本计划不替代 AIPA-120: AIPA 偏 AI Solutions Architect 作品变现；本计划补齐 BA/PM 的上游发现、需求、组织、流程、治理和 adoption。 保留原则: 本计划是增量补强线，不删除、不覆盖 Web3、架构、Solidity、LLM、AIPA 等历史计划。旧内容保留为长期知识库，ABPA 只负责把它们重新组织成 AI 时代 BA/PM/架构可用的决策资产。

---

0. 为什么需要这条线

现有体系已经很强：

但 AI 时代真正值钱的复合角色，往往不是单纯「会写 AI demo」或「懂架构图」，而是能回答这些问题：

1. 这个业务问题真的值得用 AI 吗？
2. 现在流程的瓶颈、等待、返工、风险点在哪里？
3. 哪些需求可以变成 eval / 自动化验收？哪些必须保留人工判断？
4. 数据、知识、权限、审计、模型行为是否足够支撑上线？
5. 上线后怎么证明它带来了效率、质量、风险、体验或收入变化？
6. 如何让业务、法务、风控、技术、运营都愿意采用，而不是只看一个 demo？

这就是 AI BA / AI Product Architect 的空间。它不是传统 BA 的文档自动化，而是把 BA 的核心工作升级为：

业务问题 -> 流程证据 -> 决策模型 -> 需求契约 -> Eval 验收 -> 架构控制 -> Adoption 指标 -> 投资组合决策

---

1. 2026-06 基准资料和复查规则

学习计划会过时。每个 block 开始前，先按本节重新复查资料版本和监管时间线。

1.1 Source Links

每个 block 的 SOTA 复查清单：

• 搜索 AI business analysis 2026, AI transformation BA 2026, AI product requirements evals 2026
• 复查 EU AI Act / NIST / ISO / IIBA / MCP / OpenAI / Anthropic 的最新页面
• 更新「过时风险」：哪些工具、法规、平台状态、岗位要求发生变化
• 在 block 总结里写明：本 block 的方法是否仍然有效，哪些是经典不变，哪些要换版本

---

2. 角色定位：从 BA 到 AI Business Architect

2.1 传统 BA 不会消失，但工作重心会迁移

AI 不会替代 BA 的核心判断。AI 会替代大量低价值动作：会议纪要初稿、用户故事草稿、竞品扫描、流程初图、边界用例枚举、测试点生成。留下来的高价值工作是：

2.2 目标角色组合

2.3 一句话定位

我不是「会用 AI 写需求的 BA」，而是「能把业务变革、产品价值、AI 能力、架构控制和组织采用放到同一张可验证路线图里的 AI Business Architect」。

---

3. 能力矩阵

---

4. Artifact Ladder：每个阶段都要留下证据

本计划不以「读完多少资料」为目标。每个 block 必须产出一个可复用资产。

---

5. 180 天总览

---

6. 逐 Block 计划

B1: AI BA 角色重塑与问题定义 (D1-10)

学习重点

• IIBA Business Analysis Standard：outcome-driven、organizational context、six knowledge areas。
• AI 项目失败根因：不是模型不够强，而是问题定义错、数据不够、流程不可改、控制缺失、用户不信任。
• 区分 automation、augmentation、agentic delegation、decision support。

实战任务

1. 选一个业务场景：AML 调查、贷款审批、支付差错、客服质检、商品补货、营销活动审批任选其一。
2. 写 AI Opportunity Canvas：
   • 业务目标
   • 当前痛点
   • 用户与任务
   • 现状成本
   • AI 适配度
   • 不能用 AI 的边界
   • 成功指标
   • 最大风险
3. 做 3 个版本：
   • BA 版：问题、需求、流程、干系人
   • PM 版：用户、价值、指标、路线图
   • Architect 版：数据、集成、控制、成本、运维

验收门

• 不能出现「提升效率」这类空话，必须写成可测指标：例如 average handling time、first-pass quality、manual review rate、false positive rate、cycle time。
• 至少列出 3 个 no-AI / workflow-only 场景。

面试问题

• Q: 如何判断一个需求是否适合用 AI？
• 30 秒答法: 先看任务是否有语言/知识/判断复杂度，再看数据、风险、可验收性、人工兜底和 ROI；如果流程固定、规则明确、风险高且审计强，优先 deterministic workflow。

---

B2: 干系人、访谈、需求引出 (D11-20)

学习重点

• Elicitation 不是问「你想要什么功能」，而是还原 job、约束、冲突和决策权。
• AI 可辅助准备访谈、生成问题、整理会议，但不能替代判断。
• 金融零售场景常见干系人：一线操作、主管、合规、风控、IT、数据、法务、审计、客户体验、运营、管理层。

实战任务

1. 为 B1 场景建立 Stakeholder Evidence Map。
2. 设计 6 组访谈脚本：
   • 一线用户
   • 主管/运营负责人
   • 风控/合规
   • 数据/IT
   • 架构/安全
   • 管理层 sponsor
3. 每组至少写 10 个问题，按目的分类：
   • 事实问题
   • 异常问题
   • 约束问题
   • 指标问题
   • 信任问题
   • 变更阻力问题

验收门

• 每个问题必须标注「期望得到什么证据」。
• 至少识别 5 个冲突：效率 vs 风险、自动化 vs 控制、业务速度 vs 数据质量、用户体验 vs 合规、短期节省 vs 长期维护。

模板

## Stakeholder Interview Card

- Stakeholder:
- Decision power:
- Success definition:
- Fear / resistance:
- Current workaround:
- Evidence needed:
- Questions:
- What would change their mind:

---

B3: 流程发现与 BPMN 基线 (D21-30)

学习重点

• BPMN 是 AI transformation 的核心，不是老派画图。
• Agent 只能优化流程中的某些任务，不会自动修复跨部门等待、权限缺失、数据分散、责任不清。
• 当前流程 baseline 是 ROI 的分母。

实战任务

1. 画当前流程 BPMN：
   • happy path
   • exception path
   • manual review
   • escalation
   • rework
   • audit / compliance checkpoints
2. 给每个 task 加指标：
   • cycle time
   • wait time
   • rework rate
   • error rate
   • risk severity
   • automation suitability
3. 识别 AI 候选点：
   • summarize
   • classify
   • retrieve
   • draft
   • recommend
   • validate
   • monitor

验收门

• 不能只画 happy path。
• 至少找出 3 个「不应先用 AI，而应先改流程/数据/权限」的问题。

输出

• AS-IS BPMN
• Pain Metrics Table
• AI Candidate Point Map

---

B4: 决策建模、规则、异常处理 (D31-40)

学习重点

• AI 项目经常失败在「业务判断不可解释」。
• 先建决策模型，再决定哪部分交给规则、模型、LLM 或人工。
• DMN / policy table / decision tree 是 BA 到架构的桥。

实战任务

1. 建一个 Decision Model：
   • decision name
   • inputs
   • rules
   • thresholds
   • exceptions
   • human override
   • audit evidence
2. 把决策分成四类：
   • deterministic rule
   • statistical model
   • LLM judgment
   • human-only
3. 写 10 个边界案例。

验收门

• 每个 LLM judgment 都必须有 fallback 和 review rule。
• 每个高风险 decision 必须有 explainability 和 audit field。

模板

decision: approve_sar_draft
inputs:
  - typology_match_score
  - evidence_count
  - missing_required_fields
  - analyst_confidence
automation_mode: human_review_required
rules:
  - if: missing_required_fields > 0
    then: reject_for_completion
  - if: typology_match_score < 0.65
    then: escalate_to_senior_analyst
audit_fields:
  - model_id
  - evidence_ids
  - reviewer_id
  - override_reason

---

B5: 业务能力、领域、服务域架构 (D41-50)

学习重点

• TOGAF / capability map 用来回答「组织该建设什么能力」。
• DDD / BIAN 用来回答「系统边界和服务域该怎么切」。
• BA 的需求如果不进入能力和领域模型，就很容易变成孤立功能。

实战任务

1. 为场景画 L0-L2 capability map。
2. 标注每个 capability 的：
   • pain level
   • AI leverage
   • data readiness
   • risk level
   • owner
3. 将能力映射到 domain / bounded context / service domain。
4. 写 3 条 architecture implication。

验收门

• 至少指出一个「业务上看似一个流程，架构上必须拆成多个 bounded context」的点。
• 至少指出一个「技术上能做，但组织 owner 不清导致不应启动」的点。

---

B6: 需求到 Eval 的转换 (D51-60)

学习重点

• AI 项目的需求不是写完 user story 就结束。
• 每条需求都应落到 eval data、grader、threshold、owner 和 observability。
• 这正是 BA/PM 区别于 demo builder 的地方。

实战任务

1. 写 15 条需求：
   • 5 条功能需求
   • 5 条非功能需求
   • 5 条治理/审计需求
2. 每条需求映射：
   • business outcome
   • acceptance criteria
   • eval dataset
   • grader type
   • threshold
   • production signal
   • owner
3. 建 Requirements-to-Eval Matrix。

验收门

• 至少 5 条需求要能被 deterministic code check 验收。
• 至少 3 条需求必须标注「只能人工抽检」。
• 至少 3 条需求必须进入上线后 observability。

模板

| Req ID | Requirement | Business Outcome | Eval Data | Grader | Threshold | Prod Signal | Owner |
|---|---|---|---|---|---|---|---|
| R-001 | SAR 草稿必须引用实际交易证据 | 降低不可提交草稿 | 100 labeled cases | code check | 100% evidence_id valid | invalid citation rate | Compliance Ops |

---

B7: 指标体系、统计和实验设计 (D61-70)

学习重点

• AI PM/BA 必须知道点估计不够，需要置信区间、样本量、power 和 guardrail metrics。
• 指标树要覆盖业务结果、产品使用、模型质量、风险和成本。

实战任务

1. 建 metric tree：
   • North Star Metric
   • outcome metrics
   • input metrics
   • guardrail metrics
   • diagnostic metrics
2. 设计一个实验：
   • baseline
   • treatment
   • sample unit
   • minimum detectable effect
   • stop rule
   • failure criteria
3. 写一页「为什么这个实验不会骗自己」。

验收门

• 每个 success metric 必须配 guardrail。
• 至少包含一条成本指标和一条风险指标。

---

B8: 数据 Readiness 与知识治理 (D71-80)

学习重点

• AI 项目的数据 readiness 不是「有没有数据库」。
• 要评估 source of truth、freshness、permissions、PII、lineage、label quality、知识更新机制。

实战任务

1. 建 Data Readiness Pack：
   • source inventory
   • field dictionary
   • owner
   • data quality checks
   • access control
   • retention
   • refresh frequency
   • PII / sensitive tags
2. 建 knowledge map：
   • policies
   • SOPs
   • transaction records
   • case notes
   • regulatory references
   • user feedback
3. 指出 RAG / long context / fine-tune / tool API 各自适用边界。

验收门

• 至少列出 10 个数据质量检查。
• 至少指出 3 个不能进入 LLM context 的字段或材料。

---

B9: Workflow / Agent / RAG 方案选择 (D81-90)

学习重点

• 不要默认 agent。
• BA/PM 要能用业务任务性质和风险解释架构选择。

实战任务

1. 对 B1 场景中的任务做分类：
   • deterministic workflow
   • LLM-assisted step
   • retrieval-heavy assistant
   • multi-step agent
   • human-only
2. 为每类写 ADR：
   • context
   • options
   • decision
   • consequences
   • eval evidence
3. 做成本/延迟/风险对比。

验收门

• 至少写 5 个 ADR。
• 至少一个 ADR 的结论必须是「不用 AI」。

---

B10: AI 风险、合规、控制设计 (D91-100)

学习重点

• NIST AI RMF / GenAI Profile、ISO 42001、EU AI Act 不应只作为文档引用，而要转成需求和控制。
• 合规即架构：日志、权限、解释、透明、human oversight、incident response 都要进入系统设计。

实战任务

1. 建 AI Control Pack：
   • risk statement
   • control objective
   • preventive control
   • detective control
   • corrective control
   • evidence
   • owner
   • review cadence
2. 至少覆盖：
   • hallucination
   • prompt injection
   • privacy leakage
   • biased outcome
   • over-reliance
   • unsafe automation
   • stale knowledge
   • model/provider outage
   • audit failure
3. 把 Article 50 / AI transparency 转成 UI/流程要求。

验收门

• 每个 risk 都必须有 production evidence。
• 至少 3 个 control 必须能自动检测。

---

B11: 产品原型、HITL、错误恢复 (D101-110)

学习重点

• AI 产品 UX 的重点不是炫酷对话框，而是 trust、control、review、repair。
• HITL 不是一句「人工审核」，而是明确 review queue、confidence、override、reason code、audit trail。

实战任务

1. 做一个可点击原型：
   • intake
   • AI suggestion
   • evidence view
   • review / override
   • error recovery
   • audit export
2. 做 5 人可用性测试。
3. 记录：
   • task success
   • confusion point
   • trust issue
   • missing control
   • suggested change

验收门

• 原型不能只有 happy path。
• 必须展示 AI 错误时用户如何恢复。

---

B12: Build-vs-Buy 与供应商评估 (D111-120)

学习重点

• AI transformation 很多时候不是自己建模型，而是选择 vendor、平台、云服务、MCP server、workflow 工具。
• BA/PM/Architect 必须能做选型矩阵，不被 vendor demo 带着走。

实战任务

1. 建 vendor due diligence pack：
   • capability fit
   • data residency
   • security
   • auditability
   • integration cost
   • model choice
   • eval support
   • observability
   • exit strategy
   • total cost
2. 做 3 个方案：
   • build
   • buy
   • hybrid
3. 写 build-vs-buy ADR。

验收门

• 至少指出一个 vendor lock-in 风险。
• 至少写一个 exit plan。

---

B13: Operating Model 与 RACI (D121-130)

学习重点

• AI 项目上线后，需要 owner、support、risk review、model update、prompt change、incident response、knowledge update。
• 这不是技术细节，是 operating model。

实战任务

1. 建 AI operating model：
   • product owner
   • business owner
   • model owner
   • data owner
   • risk owner
   • incident owner
   • support owner
2. 建 RACI：
   • requirement change
   • prompt/tool change
   • model change
   • policy update
   • incident response
   • quarterly review
3. 建 SOP skeleton。

验收门

• 每个 production control 必须有 owner。
• 每个 change type 必须有 approval path。

---

B14: 变更管理与 Adoption 设计 (D131-140)

学习重点

• 好的 AI 产品会死在 adoption。
• 需要把培训、激励、反馈、trust-building、champion network、usage analytics 设计进去。

实战任务

1. 建 adoption funnel：
   • invited
   • activated
   • first successful task
   • repeat use
   • trusted use
   • power use
2. 设计 training pack：
   • quick start
   • do/don't
   • escalation
   • examples
   • feedback path
3. 设计 feedback taxonomy。

验收门

• 至少定义 5 个 adoption 指标。
• 至少设计 3 个减少用户抵触的机制。

---

B15: 商业价值、ROI、投资组合 (D141-150)

学习重点

• AI 项目的价值要分清 hard saving、soft saving、risk reduction、revenue uplift、experience improvement、strategic option value。
• ROI 必须风险调整。

实战任务

1. 建 business case：
   • baseline volume
   • current cost
   • expected improvement
   • implementation cost
   • run cost
   • risk cost
   • adoption ramp
   • sensitivity analysis
2. 建 initiative portfolio：
   • value
   • feasibility
   • risk
   • data readiness
   • time to impact
   • dependency
3. 输出 go/no-go recommendation。

验收门

• 至少做 3 个敏感性场景：base / optimistic / conservative。
• 必须写清「何时应该停止项目」。

---

B16: 金融 / 零售 AI 转型案例库 (D151-160)

学习重点

• 用过往金融零售经验形成差异化案例，不做泛泛 AI。

案例方向

1. AML / fraud investigation copilot
2. Loan origination assistant
3. Payment reconciliation agent
4. Complaint handling QA copilot
5. Retail replenishment decision assistant
6. Promotion planning and post-campaign analysis
7. Branch / store operations copilot
8. Credit policy impact simulator
9. Customer 360 knowledge assistant
10. Compliance evidence pack generator

实战任务

• 每个案例写一页：
  • problem
  • current workflow
  • AI candidate task
  • data needed
  • risk
  • eval
  • architecture
  • adoption
  • ROI hypothesis

验收门

• 10 个案例必须至少覆盖金融、零售、风控、运营、数据 5 类能力。

---

B17: 面试、售前、咨询表达 (D161-170)

学习重点

• 未来角色经常需要像 consultant / SA / PM 一样表达。
• 你要能从不同听众角度讲同一个方案。

实战任务

1. 准备 5 个版本的 pitch：
   • CEO / sponsor: business value
   • COO / operations: workflow and adoption
   • CRO / compliance: control and evidence
   • CTO / architect: integration and NFR
   • frontline user: daily workflow
2. 准备 30 道面试题：
   • AI BA
   • AI PM
   • AI architect
   • AI governance
   • financial domain
3. 录 10 分钟方案演示脚本。

验收门

• 每个 pitch 不能超过 2 分钟。
• 每个版本必须改变重点，而不是复读同一段话。

---

B18: Capstone 端到端方案 (D171-180)

目标 把前 17 个 block 的资产串成一个完整的 AI transformation portfolio。

Capstone 推荐题目

「为一家中型零售银行设计 AML 调查 Copilot / 贷款审批 Copilot / 支付差错 Copilot，从问题定义到上线治理的 90 天落地方案。」

最终交付

1. Executive one-pager
2. AI Opportunity Canvas
3. Stakeholder Evidence Map
4. AS-IS / TO-BE BPMN
5. Decision Model
6. Capability + Domain Map
7. Requirements-to-Eval Matrix
8. Data Readiness Pack
9. C4 + ADR Set
10. AI Control Pack
11. Prototype + Usability Report
12. Build-vs-Buy Matrix
13. Operating Model + RACI
14. Adoption Dashboard
15. Business Case
16. 10-minute demo script

验收门

• 任意一个 artifact 被追问时，必须能指出它的证据来源、假设、风险和下一步验证方式。
• 如果只能讲愿景，不能讲证据，就不算完成。

---

7. AI BA 常用模板

7.1 AI Opportunity Canvas

# AI Opportunity Canvas

## 1. Business Problem
- Current pain:
- Affected users:
- Business impact:
- Current workaround:

## 2. Baseline
- Volume:
- Cycle time:
- Error / rework:
- Cost:
- Risk:

## 3. AI Fit
- Language / knowledge / judgment complexity:
- Deterministic alternative:
- Data readiness:
- Human review requirement:

## 4. Success Metrics
- Outcome:
- Quality:
- Cost:
- Risk:
- Adoption:

## 5. Risk / Controls
- Top risks:
- Required controls:
- Audit evidence:

## 6. Recommendation
- Go / no-go:
- First 30 days:
- Open questions:

7.2 Requirement-to-Eval Card

# Requirement-to-Eval Card

- Requirement ID:
- User / stakeholder:
- Business outcome:
- Acceptance criteria:
- Eval data:
- Grader:
- Threshold:
- Manual review:
- Production signal:
- Failure mode:
- Owner:
- Review cadence:

7.3 AI Control Register

| Risk | Scenario | Preventive Control | Detective Control | Corrective Control | Evidence | Owner |
|---|---|---|---|---|---|---|
| Hallucinated citation | AI invents a policy reference | Source-bound retrieval only | Citation validity check | Block draft + require review | invalid_citation_rate | Compliance Ops |

7.4 Workflow vs Agent Decision Tree

Is the task rule-stable, deterministic, and audit-critical?
  -> yes: workflow / rules first
  -> no: continue

Does the task require language understanding, synthesis, retrieval, or judgment?
  -> no: workflow / UI automation
  -> yes: continue

Can success be evaluated with data, rubrics, or human review?
  -> no: do not automate yet
  -> yes: continue

Is the downside of error acceptable with HITL / controls?
  -> no: decision support only
  -> yes: LLM-assisted or agentic workflow

---

8. 面试题库

AI BA

1. 如何把模糊的「我们想用 AI 提效」变成可执行项目？
2. AI 项目中 BA 和传统项目 BA 最大差异是什么？
3. 如何写一条可以被 eval 验收的需求？
4. 什么时候你会建议不要用 AI？
5. 如何处理业务方过度相信 AI 输出？
6. 如何设计 AI 项目的 UAT？
7. 如何识别流程瓶颈是数据问题、权限问题还是模型问题？
8. 如何做 AI 项目的干系人管理？
9. 如何把法规要求转成系统需求？
10. 如何评估 AI 供应商 demo 是否可信？

AI Product Manager

1. AI 产品的 North Star Metric 怎么设计？
2. 如何评价一个 Copilot 是否真的有价值？
3. 如何设计 human-in-the-loop 的产品体验？
4. 如何做 AI 产品灰度和实验？
5. AI 产品上线后看哪些 adoption 指标？
6. 如何平衡自动化率和风险？
7. 如何解释「准确率高但用户不用」的问题？
8. 如何做 AI 产品路线图？
9. 如何设计 feedback loop？
10. 如何衡量 AI 成本是否可接受？

AI Solutions Architect

1. Workflow、RAG、agent、fine-tune 怎么选？
2. 如何设计 AI 系统的审计日志？
3. 如何做 model gateway 和 provider fallback？
4. 如何设计 prompt / tool / model change governance？
5. 如何把 NIST AI RMF 落到架构组件？
6. 如何处理敏感数据进入 LLM context？
7. 如何设计 production observability？
8. 如何做 build-vs-buy？
9. 如何设计 AI incident response？
10. 如何解释 C4 图中的 AI 控制边界？

金融零售域

1. AML Copilot 为什么是金融 AI 的好落点？
2. 贷款审批中哪些环节不能交给 AI 自动决策？
3. 支付差错处理如何用 AI，但不破坏账务一致性？
4. 零售补货 AI 如何避免黑箱建议？
5. 客服质检 AI 如何衡量质量而不是只衡量速度？
6. 监管审计时如何证明 AI 决策可追溯？
7. 如何避免 AI 在高风险客户群体上产生偏差？
8. 如何设计金融 AI 的人工复核机制？
9. 如何处理模型供应商变更？
10. 如何向风控委员会汇报 AI 项目？

---

9. 反模式清单

---

10. 与现有计划的衔接

---

11. 每周执行节奏

周一: SOTA / 资料复查 + 明确本周 artifact
周二: 读标准 / 案例 / 现有仓库资产
周三: 产出草版 artifact
周四: 用 AI 辅助生成反例、边界、风险
周五: 自审 + 补证据 + 写英文摘要
周末: 复盘：这个 artifact 能否被面试官追问 10 分钟？

每周复盘问题

1. 本周 artifact 解决了哪个真实业务问题？
2. 它依赖哪些证据？证据弱在哪里？
3. 哪些假设还没验证？
4. 哪个指标能证明它有效？
5. 哪个风险会让它不该上线？
6. 如果 CTO / CRO / COO / 一线用户分别追问，我怎么回答？

---

12. 完成标准

完成本计划不是「180 天都写了笔记」，而是你拥有一套可以展示、面试、咨询、持续复用的 AI transformation playbook。

硬性产出

• 1 套完整 AI transformation capstone
• 12 类 BA/PM/Architect artifact 模板
• 10 个金融/零售 AI 转型案例
• 30+ 道面试答案
• 5 个英文 one-pager
• 1 个 10 分钟方案演示脚本

能力验证

• 能判断一个 AI 需求是否值得做
• 能把业务流程转成可量化 baseline
• 能把需求转成 eval 和 production signal
• 能设计 HITL、fallback、audit、control
• 能做 build-vs-buy 和 vendor due diligence
• 能设计 adoption 和 change management
• 能用金融零售经验讲出差异化案例
• 能用一页纸让高管做 go/no-go 决策

---

13. 下一步建议

优先从 AML Copilot 入手，因为仓库已有 PRD、AIPA 长文、评测、合规蓝图和 agent platform，可以最快把本计划的 BA artifact 串起来。

首个 10 天最小闭环

1. D1-D2: 为 AML Copilot 写 AI Opportunity Canvas
2. D3-D4: 写 Stakeholder Evidence Map
3. D5-D6: 画 AS-IS BPMN + pain metrics
4. D7-D8: 写 10 条 Requirements-to-Eval
5. D9: 写 AI Control Pack v0
6. D10: 写 Executive Decision Memo v0

已创建 starter kit：

• docs/abpa/README.md
• docs/abpa/templates/
• docs/abpa/capstone-aml/AML_ABPA_10_DAY_STARTER.md

如果这 10 天跑通，后续 170 天就不是继续「泛泛学习 AI」，而是在持续打磨一套可出售、可面试、可复制的 AI BA / Product Architect 方法论。