AI Core Banking Modernization：核心现代化与绞杀者证据架构
核心银行现代化不是把旧主机替换成新核心包，而是把账户、余额、利息、费用、额度、交易、总账、运营流程、客户影响和审计证据从旧环境逐步迁移到可治理的目标能力。AI 可以帮助理解遗留规则、生成测试、聚类差异和分析 cutover 演练，但不能拥有核心写入、事实源切换、客户影响 cutover 或迁移风险接受。
AI Core Banking Modernization / Legacy Strangler / Evidence Architecture 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_CORE_BANKING_MODERNIZATION_STRANGLER_EVIDENCE_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
核心导读
核心银行现代化不是把旧主机替换成新核心包，而是把账户、余额、利息、费用、额度、交易、总账、运营流程、客户影响和审计证据从旧环境逐步迁移到可治理的目标能力。AI 可以帮助理解遗留规则、生成测试、聚类差异和分析 cutover 演练，但不能拥有核心写入、事实源切换、客户影响 cutover 或迁移风险接受。
重要说明：本文是学习、作品集和内部架构训练材料，不构成法律意见、监管解释、合规结论、审计意见、核心迁移批准意见、供应商选型建议或生产 cutover 指令。具体适用范围、监管义务、会计处理、数据保留、客户通知、外包与第三方责任、业务连续性要求和上线批准，必须由机构授权角色结合司法辖区、牌照、产品、客户群、监管关系、合同和内部政策确认。访问日期按 2026-06-30 记录。
Source Anchors
| Source | Official link | 本文使用方式 |
|---|---|---|
| FFIEC Architecture, Infrastructure, and Operations IT Handbook | https://ithandbook.ffiec.gov/it-booklets/architecture-infrastructure-and-operations/ | 用 enterprise architecture、data flow、technology asset、change、operations、resilience 和 third-party oversight 组织核心现代化架构控制。 |
| FFIEC Development, Acquisition, and Maintenance IT Handbook | https://ithandbook.ffiec.gov/it-booklets/development-acquisition-and-maintenance/ | 用 development/acquisition/maintenance governance、risk management、testing、change 和 acquisition 组织核心包改造、集成与迁移生命周期。 |
| FFIEC Management IT Handbook | https://ithandbook.ffiec.gov/it-booklets/management | 用 IT governance、risk management、enterprise architecture、project management、monitoring/reporting 组织 transformation accountability。 |
| FFIEC Business Continuity Management IT Handbook | https://ithandbook.ffiec.gov/it-booklets/business-continuity-management | 用 BIA、risk assessment、business continuity strategies、plan、training、exercises、maintenance、board reporting 组织 cutover、rollback 和 degraded mode。 |
| NIST SP 800-160 Vol. 1 Rev. 1 Engineering Trustworthy Secure Systems | https://csrc.nist.gov/pubs/sp/800/160/v1/r1/final | 用 systems security engineering 和 trustworthy secure systems 思维设计核心银行系统边界、可信交互和生命周期控制。 |
| NIST SP 800-218 Secure Software Development Framework | https://csrc.nist.gov/pubs/sp/800/218/final | 用 secure SDLC、prepare/protect/produce/respond 组织核心现代化代码、配置、供应链和缺陷响应。 |
| NIST AI Risk Management Framework | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 界定 AI 辅助现代化的用途、风险、度量、控制和持续改进。 |
| ISO/IEC 42001 AI management systems | https://www.iso.org/standard/81230.html | 用 AI management system、责任、运行控制、绩效评价和持续改进组织 AI 工具在核心转型中的治理。 |
1. 核心问题：核心现代化迁移的是事实和责任
低成熟度叙述通常是：
旧核心太老
-> 买一个新核心包
-> 做数据迁移
-> 周末 cutover
-> 关掉旧系统
这个叙述忽略了核心银行系统承载的东西不是普通 CRUD。
核心系统同时承载：
- 客户账户、余额、可用余额、利息、费用、额度、冻结、还款、冲正、争议和交易历史。
- 渠道、柜面、呼叫中心、支付、卡、贷款、总账、风控、对账、报表、催收、投诉和运营流程。
- 监管、审计、客户争议、财务控制、数据保留、业务连续性和供应商责任证据。
因此高级架构问题不是“新系统什么时候上线”，而是：
| 问题 | 低成熟度答案 | 成熟答案 |
|---|---|---|
| 谁是事实源 | 新系统上线后就是新系统 | 每个 capability、data object、posting type、as-of period 都有 source-of-truth 迁移状态 |
| 如何降低风险 | 多测几轮 | 用 capability slice、shadow ledger、parallel run、reconciliation gate 和 rollback design 控制客户影响 |
| AI 怎么参与 | 让 AI 帮忙迁移和写代码 | AI 辅助理解、建议、生成测试和分析缺陷，但不拥有核心写入、迁移批准和 cutover 决策 |
| 审计怎么证明 | 保存项目文档 | evidence architecture 自动连接需求、映射、代码、数据快照、对账、审批、异常、客户影响和恢复演练 |
成熟的核心现代化主线应写成：
legacy constraints and customer harm model
-> domain / capability slicing
-> anti-corruption layer and canonical contracts
-> event capture and read replica
-> controlled coexistence
-> dual-run / parallel-run / reconciliation
-> evidence-backed cutover
-> rollback / BCP / operational readiness
-> source-of-truth retirement by capability
2. 方法：从能力切片做 Strangler，而不是从系统清单切片
Strangler modernization 的关键不是“旧系统外面包一层 API”，而是逐步把业务能力、数据事实、运营责任和证据链迁移到新平台。
Channels / operations / partners
|
v
Experience and process layer
|
v
Anti-corruption layer
intent API | canonical model | mapping | validation | policy | evidence
|
+--------------------+
| |
v v
Legacy core estate Modernized capability
mainframe / package product service / ledger service / workflow
| |
v v
Event capture Read model / shadow ledger / reconciliation
\____________________/
|
v
Evidence and control plane
能力切片的优先顺序应由四个维度决定：
| Dimension | 问题 | 高优先迁移信号 | 低优先迁移信号 |
|---|---|---|---|
| Business value | 迁移后能否释放产品速度、运营效率或风险控制价值 | 新产品发布慢、渠道体验被旧核心阻塞、人工操作多 | 低变化、低收益、历史查询为主 |
| Coupling | 与日终、总账、支付、贷款生命周期耦合度 | 可通过 ACL 隔离，读多写少，规则边界清楚 | 高频 posting、复杂利息/费用、跨产品勾稽 |
| Evidence readiness | 是否能证明旧新一致、客户影响可控 | 有稳定 source extract、mapping、recon、test oracle | 旧规则隐式、数据质量差、异常案例多 |
| Operational readiness | 运营、客服、风险、财务是否能支撑 coexistence | SOP、培训、rollback、queue、issue playbook 准备充分 | 人工队列脆弱，供应商环境不可控 |
这使迁移顺序不再由组织偏好决定，而由价值、耦合、证据和运营 readiness 共同决定。
3. 必须尊重的遗留约束
核心现代化失败通常不是因为目标架构不会画图，而是没有尊重旧系统真实约束。
| Constraint | 典型表现 | 架构含义 |
|---|---|---|
| Mainframe batch window | 夜间批处理、利息计提、费用入账、日终、月终、报表抽取互相挤占窗口 | 不能只按 API latency 设计，必须理解 batch calendar、freeze time、as-of semantics |
| COBOL / copybook / VSAM / DB2 complexity | 字段复用、压缩格式、历史编码、隐式规则、job dependency 不透明 | 需要 code/document mining、data profiling、lineage 和 business rule evidence |
| Core package parameterization | 产品、费用、利率、额度、状态机通过参数和脚本配置 | 迁移对象不只是代码，还包括 parameter book、product catalog、operating procedures |
| Vendor release cadence | 核心包升级、补丁、接口变更由供应商节奏约束 | architecture runway 要包含 vendor dependency、contractual SLA、environment availability |
| Channel coupling | 网银、移动、柜面、IVR、CRM、支付、卡系统直接依赖核心字段 | strangler 需要 anti-corruption layer，不能让渠道直接理解两套核心语义 |
| Ledger and subledger integrity | 存款、贷款、交易、费用、利息、总账勾稽 | 任何 migration 或 dual-write 都必须有 reconciliation and accounting evidence |
| Customer harm exposure | 错误余额、错误费用、拒绝交易、重复扣款、错误征信或错误催收 | cutover gate 必须绑定 customer harm scenario，不是只看技术成功率 |
这些约束会决定 modernization tempo。不是每个 bounded context 都适合先迁，也不是每个读模型都能升级成事实源。
4. Anti-Corruption Layer：语义防火墙
Anti-corruption layer 不是普通 adapter。它是新旧核心之间的语义防火墙，防止旧系统字段、状态码、批处理假设和异常路径污染目标域模型。
| ACL capability | 核心问题 | 证据 |
|---|---|---|
| Intent API | 渠道表达业务意图，而不是直接写旧核心字段 | API contract、consumer mapping、approval history |
| Canonical model | account、customer、product、transaction、balance、interest、fee、hold、loan schedule 等核心概念统一 | model version、field lineage、semantic decision log |
| Mapping and validation | 新旧字段、状态、金额、日期、精度、币种、时区、as-of 语义可证明 | mapping table、rule tests、exception samples |
| Policy gate | 哪些写入、查询、客户影响动作允许、拒绝、升级 | policy version、decision log、override evidence |
| Idempotency and sequencing | 防止重复交易、乱序事件、重复入账和恢复重放风险 | idempotency key、sequence check、replay test |
| Evidence emission | 每次转换、调用、回写、拒绝、异常都产生 evidence event | trace id、event id、source snapshot、approval id |
如果 ACL 只是技术转发层，它会把 legacy complexity 复制到新平台；如果 ACL 管理语义、控制和证据，它才是 strangler 的治理边界。
5. Event Capture、Read Replica 与 Shadow Ledger
Event capture 适合把旧核心变化转成新世界可消费的事实流：
legacy transaction / batch / table change
-> capture
-> normalize
-> validate
-> publish canonical event
-> build read model / reconciliation set / operational dashboard
关键不是“有没有事件”，而是事件是否能说明业务事实、发生时间、生效时间、触发主体、源记录版本、batch run、job id、sequence、checksum、可重放和可去重能力。
Read replica 可以降低渠道和分析系统对旧核心的查询压力，但不能被误当成事实源。
| 使用方式 | 可以 | 不可以 |
|---|---|---|
| 客户资料查询 | 缓存非实时或准实时 profile，标注 freshness | 用 replica 覆盖核心客户主数据 |
| 账户余额展示 | 展示可用余额和账面余额，显示 as-of time | 在时效不明时承诺最终余额 |
| 运营查询 | 支持客服、投诉、对账工作台 | 用它执行核心 write 或 regulatory fact change |
| AI 辅助 | 作为 RAG / tool read source，带 lineage 和 freshness | 让 AI 基于过期 replica 直接行动 |
Shadow ledger 适合在迁移前验证新 ledger / posting engine 与旧核心是否一致：
legacy posting stream
-> canonical transaction event
-> new posting engine in shadow mode
-> balance / interest / fee / GL projection
-> daily reconciliation
-> break classification
-> defect / rule / data correction loop
Shadow ledger 不是生产事实源。它的价值是产生 confidence evidence：新旧余额差异、利息和费用差异、还款和冲正差异、冻结和追溯调整差异、GL projection 差异，以及每个 break 的责任和关闭证据。
6. Migration Evidence：迁移质量必须可证明
核心现代化的高级控制不是“迁移完成率 100%”，而是每个迁移对象有可证明的迁移质量。
| Evidence object | 说明 | 关键字段 |
|---|---|---|
| Migration population manifest | 本次迁移覆盖哪些客户、账户、产品、合同、交易历史、余额和状态 | population id、source extract time、record count、hash、exclusion reason |
| Mapping decision record | 字段、状态、产品参数、利率、费用、异常路径如何映射 | source field、target field、rule id、owner、approval、test sample |
| Data quality profile | 源数据缺失、异常、重复、历史编码和不可迁移项 | defect type、severity、population impact、fix path |
| Reconciliation report | 新旧余额、交易、利息、费用、GL、客户状态是否一致 | tolerance、break count、break value、aging、owner |
| Parallel-run scorecard | 新旧系统在同一业务场景下输出是否一致 | scenario id、input set、legacy result、target result、variance |
| Cutover readiness pack | 技术、业务、运营、供应商、BCP、客户影响和证据是否达标 | gate status、exceptions、risk acceptance、approvers |
| Rollback evidence | 失败时如何恢复旧路径、补偿交易、通知运营和保护证据 | trigger、decision owner、recovery point、data replay plan |
Dual-run 和 parallel-run 要保持：
same population
same business date
same product rule
same fee / interest / posting semantics
same reconciliation tolerance
same defect classification
same approval evidence
只跑 happy path 不能证明核心迁移可上线。必须覆盖追溯调整、冲正、冻结、异常利率、提前还款、收费豁免、长期未动户、已销户、争议交易、死亡/破产/欺诈标记、合并客户、历史产品代码等高风险案例。
7. Customer Harm 与 Operational Readiness
核心迁移必须从客户伤害模型反推控制。
| Harm scenario | 可能根因 | 必须控制 |
|---|---|---|
| 错误余额或可用余额 | 迁移余额错误、事件延迟、hold 语义不同 | balance reconciliation、as-of disclosure、customer service script |
| 重复扣款或漏扣 | idempotency 缺失、重放错误、cutover 队列处理不当 | idempotency key、queue drain proof、duplicate detection |
| 错误利息或费用 | 产品参数、日计息规则、豁免规则迁移错误 | shadow calculation、fee/interest tolerance、sample disclosure |
| 交易被错误拒绝 | 渠道路由、风险状态、冻结标记映射错误 | pre-cutover eligibility check、real-time monitoring |
| 投诉和争议无法处理 | 客服看不到旧新两边证据 | unified case view、runbook、evidence retrieval |
| 财务或报表差异 | subledger / GL mapping 不一致 | GL reconciliation、adjustment approval、period close gate |
Operational readiness 不是培训材料签收。它应包括 command center RACI、业务/技术/供应商/风险/客服/财务/合规联动、runbook version、decision log、communication templates、rollback checklist、客户影响监控、投诉监控、交易拒绝率、余额差异、queue backlog、error budget、演练证据和值班表。
Cutover gate 应同时看技术健康、客户影响、运营容量、供应商响应、对账差异、BCP/degraded mode 和 rollback authority。
8. AI Assist Boundary：AI 可辅助，但不能拥有核心责任
AI 可以提升核心现代化的理解、搜索、映射、测试和运营分析效率，但必须被放在 evidence-backed human decision loop 中。
| AI assist area | 可做什么 | 必须保留的控制 |
|---|---|---|
| Requirements mining | 从 BRD、FRD、SOP、Jira、会议纪要、监管说明、供应商文档抽取规则和冲突 | 引用来源、置信度、BA/SME 审核、冲突清单 |
| Code/document understanding | 解释 COBOL、copybook、batch job、parameter file、接口说明 | 只读访问、片段引用、专家复核、不可直接生成生产结论 |
| Mapping suggestion | 建议旧字段到 canonical/target 字段、状态码和规则映射 | mapping owner 审批、样本验证、diff history |
| Data profiling | 发现异常值、空值、重复、格式漂移、历史编码、边界案例 | 数据分类、脱敏、profiling 结果可复算 |
| Test generation | 生成边界案例、回归案例、parallel-run oracle 草稿 | QA/SME 选择、测试数据控制、结果不可被 AI 自评闭环 |
| Cutover rehearsal analysis | 分析演练日志、耗时、队列积压、错误聚类、依赖瓶颈 | runbook owner 复核、时间线证据、手工决策 |
| Defect clustering | 把 recon breaks、UAT defects、production issues 聚类成根因候选 | issue owner 确认、根因证据、不得自动关闭问题 |
| Runbook copilot | 帮值班和 cutover command center 检索步骤、影响、联系人、历史事故 | 只读、引用 runbook version、禁止自行执行客户影响动作 |
禁止边界必须通过工具权限和治理流程落地：
| 禁止边界 | 原因 | 控制表达 |
|---|---|---|
| Final migration decision | 涉及客户、财务、监管、运营和风险接受 | Migration Authority / Steering Committee 签署 |
| Unreviewed core writes | 核心写入可能改变余额、费用、状态、额度和客户权利 | tool gateway 写操作默认禁止，高风险动作双人审批 |
| Customer-impacting cutover | cutover 会影响服务可用性、交易、余额展示、通知和投诉 | command center 人工决策，evidence gate，rollback authority |
| Source-of-truth changes | 事实源变更影响审计、争议、报表和运营责任 | SoT registry 版本化，data owner / system owner 审批 |
| Autonomous reconciliation closure | 差异关闭代表接受风险或确认事实 | recon owner 审核，materiality rule，exception disclosure |
| Regulatory/audit conclusion | AI 不能替代授权合规、法务、审计或监管关系判断 | AI output 标注为辅助草稿，人工批准和引用来源 |
9. 为什么有效：迁移每一步都有可复盘证据
这套架构有效，是因为它把核心现代化从“交付新系统”改造成“逐步迁移事实责任”。
第一，capability slice 降低风险集中度。不是在一个周末迁移所有产品、账户和流程，而是按价值、耦合、证据 readiness 和运营准备度分批迁移。
第二，ACL 防止语义污染。渠道和新能力不直接继承旧字段、状态码和批处理假设，而是通过 intent API、canonical model、policy gate 和 evidence event 建立清晰边界。
第三，shadow ledger 和 parallel run 提供上线信心。团队不是相信目标系统正确，而是用同一 population、同一业务日期、同一产品规则和同一容忍度对比结果。
第四，customer harm model 让上线 gate 不被技术指标绑架。余额、费用、交易拒绝、投诉、财务对账和客服可解释性都成为 cutover 控制。
第五，evidence architecture 把监管、审计、投诉、财务和事故复盘需要的证据在运行时生成，而不是项目后期补截图。
10. 局限和误用
核心现代化常见误用包括：
| Anti-pattern | 后果 | 替代做法 |
|---|---|---|
| Big-bang replacement | 周末风险集中，rollback 模糊，客户影响不可控 | capability strangler with readiness gates |
| API wrapping without semantics | 新渠道继承旧字段和状态码混乱 | ACL with canonical model and mapping evidence |
| Data migration as ETL job | 只关注装载成功，不证明业务事实正确 | migration evidence factory and reconciliation gates |
| AI-generated mapping accepted by default | 字段误映射导致余额、费用或状态错误 | AI suggestion + SME approval + sample testing |
| Parallel run without defect taxonomy | 差异无法归因，上线信心虚高 | break classification and closure evidence |
| Cutover gate dominated by technology | 忽视客服、投诉、财务、运营和客户沟通 | enterprise readiness gate with customer harm lens |
| Vendor package treated as black box | 参数、升级、接口和数据语义不可控 | vendor control pack and contract-backed evidence |
| Evidence captured after the fact | 审计和事故复盘依赖截图与会议记忆 | evidence-by-design events、manifests and decision logs |
这套架构也有现实限制。它需要长期建设 SoT registry、canonical model、event standards、reconciliation engine、parallel-run environment 和 evidence plane；不能被包装成一次工具采购。对高度耦合、低文档、数据质量差的 legacy estate，前期可能需要大量 profiling、rule mining 和运营补偿。
11. Architecture Runway：让每个切片可安全迁移
核心现代化的 architecture runway 不是“先搭平台”，而是让每个 capability slice 可以被安全迁移的前置能力。
| Runway capability | 为什么重要 |
|---|---|
| Source-of-truth registry | 明确每类事实当前归属，支持逐步迁移和责任交接 |
| Canonical model and event standards | 降低渠道、核心包、主机、新服务之间的语义污染 |
| ACL and tool gateway | 保护 legacy and target writes，管理幂等、策略和证据 |
| Evidence event bus | 把迁移、对账、审批、异常、cutover、rollback 变成可查询事件 |
| Reconciliation engine | 支持余额、交易、利息、费用、GL、状态、客户影响的自动对账 |
| Data quality workbench | 在迁移前暴露源数据风险，不把脏数据推给 cutover 周末 |
| Parallel-run environment | 支持真实数据规模、时间窗口、批处理和 replay |
| Operational cockpit | 在 coexistence 阶段监控交易、错误、队列、供应商、客户影响 |
| AI governed workspace | 支持文档/代码理解和测试生成，同时保留引用、访问控制和审查 |
这些能力应被纳入 transition architecture，而不是作为项目边缘工具临时搭建。
12. 金融零售系统案例：存款账户能力分阶段迁移
场景：一家区域银行计划把存款核心从主机迁到新核心包，同时建设新的账户服务和客户体验层。
直接 big-bang 的风险包括：夜间批处理窗口不可预测、利息计提规则隐式、旧渠道直接读主机字段、客服只能看到旧系统记录、GL 对账在月末才发现差异、部分老产品参数已无人完整理解。
更稳妥的切片路径：
| 阶段 | 迁移对象 | 控制重点 |
|---|---|---|
| 1 | 只读客户/账户 profile replica | freshness、lineage、channel disclosure、no write |
| 2 | 账户查询和客服统一视图 | ACL、canonical model、case evidence、privacy controls |
| 3 | 低风险非资金类服务请求 | policy gate、idempotency、workflow replay、rollback |
| 4 | Shadow ledger for deposit posting | interest/fee/balance/GL reconciliation、break taxonomy |
| 5 | Limited cohort cutover | customer harm monitoring、parallel run、command center、rollback |
| 6 | Source-of-truth retirement by product group | attestation、records retention、evidence archive、post-cutover review |
AI 在该案例中可以帮助从 COBOL/copybook、产品参数、SOP 和历史缺陷中抽取规则候选；也可以生成边界测试，例如 dormant account、fee waiver、returned item、manual hold、interest backdated adjustment。所有 AI 输出必须进入 SME 审核和 sample validation，不能直接变成生产 mapping。
迁移成功的证据不是“新核心可以开户”，而是对任意一个客户账户，团队能解释旧新系统在同一业务日期下的余额、可用余额、利息、费用、交易状态、GL impact、客服可见证据和 rollback path。
13. 架构和产品价值
对有金融零售软件经验的人来说，这篇文章的价值是把核心现代化从 IT 替换项目提升为可运营、可审计、可分阶段证明的业务能力迁移。
它要求在需求、架构和治理中持续追问：
| 追问 | 应落到的架构对象 |
|---|---|
| 这个能力是否适合先迁 | capability slice scorecard、coupling map、evidence readiness |
| 这个事实当前由谁拥有 | source-of-truth registry、data owner、system owner |
| 新旧语义如何隔离 | ACL、canonical model、mapping decision record |
| 新系统结果如何证明正确 | shadow ledger、parallel-run scorecard、reconciliation report |
| 客户伤害如何发现和恢复 | customer harm scenarios、monitoring、runbook、rollback evidence |
| AI 参与到哪里为止 | AI use register、read-only workspace、review/approval log、tool gateway |
成熟的 core modernization 不是用一句“目标架构更现代”说服管理层，而是用证据展示每个阶段降低了哪些风险、释放了哪些能力、迁移了哪些责任、关闭了哪些遗留依赖。
14. 学习验证
完成本文后，应能解释以下问题，并把回答落到可执行的架构机制。
| 验证问题 | 合格回答应包含 |
|---|---|
| 如何设计核心银行现代化的 strangler 架构 | capability slicing、ACL、canonical model、event capture、read replica、shadow ledger、reconciliation engine、evidence plane、readiness gates |
| 为什么核心迁移需要 evidence architecture | migration manifest、mapping decision、data quality profile、parallel run、reconciliation break、approval decision、cutover log、rollback record、customer impact signal |
| 如何控制 AI 在核心现代化中的风险 | AI 只做理解、建议、测试、聚类和检索；不做核心写入、迁移批准、cutover 决策、SoT 变更和审计结论 |
| 如何判断一个 capability slice 可以 cutover | 同一 population 的新旧结果可解释、关键 breaks 关闭或授权接受、客户伤害监控和 rollback 就绪、运营和供应商 readiness 达标 |
| 如何避免新平台复制旧复杂度 | ACL 管理语义和控制，canonical model 明确核心概念，legacy code/parameter 规则进入受控 mapping，而不是直接暴露给渠道 |
最终判断标准：
Can the bank prove which facts moved, which responsibilities changed,
which customers were exposed, which differences were accepted,
and how it would recover if the cutover caused harm?
如果答案是否定的，问题不是核心包不够现代，而是现代化还没有成为事实责任迁移的可证明系统。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。