第三十一章:AI 时代

本章总结图

前三十章建好了系统。AI 能做什么、不能做什么？

VCC 是一个强监管、强一致、零容忍的领域：

余额错 $0.01 → 对账不平授权多批一次   → 超卖Ledger 被 AI 改 → 审计灾难

但 AI 在 VCC 领域并非无用 — 关键在于把 AI 放在正确的位置。

本章五个话题：

AI Review      — AI 帮你看代码和架构AI Coding      — AI 帮你写代码，但 Ledger 不能交给它Payment Agent  — AI 帮用户花钱Risk Agent     — AI 帮系统防风险Settlement Agent — AI 帮财务对账

一个总原则贯穿全章：

AI 可以建议、可以辅助、可以自动化「读」和「分析」— 但「写钱」必须走确定性路径（Ledger Insert-Only、幂等、人工兜底）。

AI 在 VCC 架构中的位置

① AI Review

是什么

用 AI 审查 VCC 系统的代码、架构、PR、配置变更 — 在合并前发现可能导致资金事故的问题。

为什么 VCC 特别需要 AI Review

普通 SaaS bug：页面错了，修就好VCC bug：  · UPDATE balance 而非 INSERT Entry     → 第二十二章违反  · 手续费扣卡余额而非 Wallet            → 第二十一章违反  · Webhook 无幂等                       → 第二十九章违反  · JIT 路径走 MQ                        → 第三十章违反  · Processor 金额用 float               → 第二十八章违反这些 bug 不会导致编译错误 — 只有 AI Review 或资深工程师能抓

Review 什么

AI Review 工作流

AI Review Prompt 示例（概念）

你是 VCC 支付系统的高级架构 Reviewer。审查以下 PR diff。必须检查：1. 是否有 UPDATE balance / available / pending 字段？   → 应使用 Ledger Entry INSERT 或原子 SQL2. 手续费是否事后从 Card Available 扣除？   → Per-Card 应扣 Wallet Unallocated，Account Pool 应扣 Pool Available；     只有开卡 all-in 可在分配前从 Allocation 内扣（第二十一、二十三章）3. Webhook handler 是否先验签再处理？4. 金额是否使用 float/double？   → 应使用 string 或 DECIMAL5. POST 写操作是否有 Idempotency-Key？6. JIT 路径是否把 MQ、额外 HTTP 或 AI 推理放进同步链（超出附录 C 校准起点）？输出：- 🔴 BLOCK：必须修复- 🟡 WARN：建议修复- 🟢 PASS：符合规范- 每条发现引用具体行号和章节

AI Review 示例输出

PR #247: feat/add-transaction-fee-inline🔴 BLOCK — line 89: transaction-fee.service.ts  feeService.deductFromCard(cardId, feeAmount)  → 违反第二十一章：平台费应扣账户级 Customer Funds Source，    不得事后扣 Card Available  → 可能导致授权失败（卡 available 被 silently 减少）🟡 WARN — line 134: webhook-handler.ts  Webhook 处理完才返回 200  → 违反第二十九章：应先 INSERT inbox 再返回 200  → 建议：Inbox 模式🟢 PASS — line 201: fee 使用了 DECIMAL 类型🟢 PASS — Idempotency-Key 已加

AI Review 的边界

AI Review 不能替代：  · 安全渗透测试  · PCI DSS 正式审计  · Sponsor Bank 合规审查  · 生产发布的人工 Sign-offAI Review 擅长：  · 模式匹配（「这个 diff 有没有 UPDATE balance」）  · 跨文件一致性（「OpenAPI 和 Handler 字段是否对齐」）  · 历史 bug 回归（「这个写法和上次生产事故一样」）

② AI Coding

是什么

用 AI 辅助编写 VCC 系统代码 — 从 OpenAPI spec 生成 Handler，从 Ledger 规则生成 Entry 模板，从 Processor 文档生成 Adapter。

为什么 VCC 的 AI Coding 需要特殊规范

AI 生成的代码在普通项目里「能跑就行」在 VCC 项目里「能跑」远远不够 — 必须「不能错」AI 常见错误：  · balance += amount          ← 直觉写法，致命  · parseFloat(amount)         ← 精度丢失  · await processWebhook()     ← 阻塞返回 200  · if (processor == 'marqeta') ← 硬编码  · DELETE FROM entry          ← 违反 Ledger 铁律

AI Coding 工作流

适合 AI 生成的部分

Spec-Driven AI Coding

最佳实践：给 AI 的不是「帮我写个充值功能」而是：  「根据第二十八章 OpenAPI 的 POST /wallets/{id}/topups   和第二十二章 DEPOSIT_FUNDS_RECEIVED / DEPOSIT_CREDIT Journal 模式   和第二十九章 Transactional Outbox 模式   生成 TopupService，要求：   1. 金额用 string 转 DECIMAL   2. 同一事务写 Ledger + Outbox   3. Idempotency-Key 去重   4. 不 UPDATE balance，INSERT wallet_ledger」  → AI 输出质量大幅提升  → 因为约束来自本书的章节规范，不是 AI 的「直觉」

本书作为 AI Coding 的 Context

VCC 架构实践书籍 = AI Coding 的 System Prompt  第四～七章：产业链 → AI 知道 Processor 和 Issuer 的分工  第八～十一章：谁赚钱 → AI 知道 Interchange 与 PM 定价  第二十一章：Wallet  → AI 知道手续费扣 Wallet  第二十二章：Ledger  → AI 知道 Insert-Only  第二十四章：交易流水 → AI 知道 authorization / clearing 分表  第二十七章：Processor → AI 知道 Adapter 模式  第二十八章：OpenAPI  → AI 知道 API 规范  第二十九章：Webhook  → AI 知道 Inbox + Outbox  第三十章：高并发  → AI 知道 JIT 路径不能用 MQ  把相关章节作为 context 喂给 AI → 生成的代码符合架构

③ Payment Agent

是什么

Payment Agent — AI 代理帮用户决策和操作支付 — 自动开卡、分配预算、选择商户、执行支付策略。

传统 VCC 用户：  手动开卡 → 手动设限额 → 手动在 Google Ads 绑定 → 手动监控Payment Agent 用户：  「帮我用 $500 跑 Google Ads 本周 campaign」  → Agent 开卡 → 设 MCC 7311 → 设限额 $500 → 监控消费 → 花完通知

Agent 架构

Agent 能做什么

Agent 不能做什么

❌ Agent 不能直接写 Ledger Entry❌ Agent 不能绕过风控规则❌ Agent 不能修改 Fee 规则❌ Agent 不能访问 PAN/CVV 明文（PCI）❌ Agent 不能在没有用户确认的情况下充值 / 提现大额✅ Agent 通过 OpenAPI 操作 — 和人类用户一样的权限边界✅ Agent 的所有操作留 audit log✅ 超额操作需 Human-in-the-Loop 确认

Human-in-the-Loop

阈值示例：  开卡 ≤ $1,000        → Agent 自动  开卡 > $1,000        → 用户确认  充值任何金额          → 用户确认  提现任何金额          → 用户确认  冻结 / 销卡          → Agent 自动（安全操作）

Payment Agent 与 OpenAPI 的关系

Payment Agent 不是新接口 — 是 OpenAPI 的智能客户端：  Agent Tools = OpenAPI Endpoints 的封装  tool: create_card    → POST /v1/cards    → 参数从 Agent 推理得出  tool: get_balance    → GET /v1/wallets/{id}/balance/summary  好处：    · Agent 和 API 客户端共用同一套后端逻辑    · 权限、幂等、Ledger 规则一致    · Agent 不能「走捷径」绕过系统

④ Risk Agent

是什么

Risk Agent — AI 增强第二十六章的风控系统 — 不是替代规则引擎，而是在规则之上做智能分析和异常检测。

第二十六章风控 = 确定性规则（Velocity、MCC、Country...）Risk Agent  = AI 补充（异常模式、新威胁、复杂关联）

分工

Risk Agent 不得

出现在 JIT 同步决策边上。它只异步写入 risk_signal；下一次授权最多读取已经提交的信号。Approve / Decline 只能由确定性规则引擎（加余额 / Ledger 提交）做出。

Risk Agent 做什么

1. 异常模式检测

输入：过去 30 天该用户的交易数据AI 发现：  · 该用户通常只在 US 商户消费  · 今天突然出现 5 笔 NG（尼日利亚）MCC 7995 交易  · 规则引擎：NG 在 greylist，但未 Block  · Risk Agent：异常分数 85 → 建议 Block + 人工 Review

2. 商户风险画像

输入：merchant_name + mcc + 历史 chargeback 率AI 输出：  · 「XX Trading Ltd」— 新商户，MCC 5999，类似已知欺诈模式  · 建议：Block or 强制 3DS  · 置信度：72%

3. BIN 声誉监控

输入：BIN 421767 过去 7 天数据AI 发现：  · Decline 率从 5% 升到 18%  · 主要 Decline 原因：MCC 7995 占比 60%  · 建议：临时 Block MCC 7995 for this BIN  · 通知运维 + Sponsor Bank

4. Chargeback 预测

输入：交易特征（MCC、金额、商户、用户历史）AI 输出：  · 该笔交易 30 天内 Chargeback 概率：12%  · 高于阈值 5% → 标记 REVIEW  · 不自动 Block — 仅标记

Risk Agent 不能做什么

❌ 不能绕过硬规则（制裁国永远 Block）❌ 不能自动修改 Ledger，也没有 Ledger 写权限❌ 不能在 JIT HTTP 内 Approve / Decline 或阻塞模型推理❌ 训练数据、日志、prompt 不能包含 PAN / CVV / Track✅ 只写入 `risk_signal`；JIT 最多只读已提交信号✅ 可以异步分析后建议冻结卡（须规则 / 人工执行）✅ 可以生成 Risk Review 报告供人工决策

Risk Agent 架构

                    ┌─────────────────────┐                    │  Risk Agent          │                    │                     │  交易数据 ────────→│  · 异常检测模型      │  商户数据 ────────→│  · 商户风险画像      │──→ 风险评分 + 建议  BIN 指标 ────────→│  · BIN 声誉监控      │  Chargeback ──────→│  · CB 预测           │                    └─────────────────────┘                              │                              ▼                    ┌─────────────────────┐                    │  确定性规则引擎       │──→ 最终决策                    │  （第二十六章）           │                    └─────────────────────┘  AI 写入 risk_signal → 规则引擎最终决策 → 高风险进入人工 Review 队列

⑤ Settlement Agent

是什么

Settlement Agent — AI 辅助对账和清算 — 第十二～十五章的五个资金视图、第二十二章的 Ledger、第二十四章的 clearing/settlement 记录，在日终 / 月终对齐时，AI 帮发现差异、分析原因、建议修复。

对账为什么适合 AI

对账差异的类型：  · 金额差 $0.01        → 可能是 FX 四舍五入  · 缺一笔交易           → 可能是 Webhook 丢失  · 多一笔交易           → 可能是重复处理  · 时间差 T+1 vs T+2   → 正常，但需确认  · 未知差异             → 需要人工排查数小时  AI 擅长：从大量数据中找模式、分类差异、建议根因  AI 不擅长：决定「是否调整 Ledger」（必须人工 Approve）

Settlement Agent 工作流

对账等式（第十五章）+ AI

第十五章的分层检查：  CHECK0  Journal Debit = Credit  CHECK1  Eligible Safeguarded Assets ≥ Customer Funds Liabilities  CHECK2-P  Wallet Unallocated + Withdrawal Hold          + Σ(Card Available + Auth Hold)          = Customer Funds Liabilities  CHECK2-A  Pool Available + Withdrawal Hold + Σ(Auth Hold)          = Customer Funds Liabilities  CHECK2-J  JIT Effective Outstanding Hold = Σ(JIT Auth Hold)          且每个 APPROVED JIT Authorization          ↔ 唯一已提交 AUTHORIZATION Journal  CHECK3  Clearing Position = Network Settlement Payable  CHECK4  Settlement Statement = Bank Cash Movement  CHECK5  Payment Rail Statement = Deposit / Withdrawal Orders ± ReturnsSettlement Agent 检查：  1. 从 Ledger Entry 重算客户资金负债与 Payable → 计算值 A  2. 从 balance_cached 读取                     → 缓存值 B  3. 从 Bank Statement 读取资产与现金变动        → 银行值 C  4. 从 Processor / Network 报告读取清算净额      → 外部值 D  A = B？  → 缓存是否准确  CHECK1？ → 客户资金是否足额覆盖  CHECK2-A + CHECK2-J？→ JIT Pool 构成是否平衡，是否存在 orphan Approve / Hold / 重复 Journal  CHECK3？ → Processor / Network 与 PM 是否一致  CHECK4？ → Network Statement 与银行现金是否一致  CHECK5？ → Payment Rail 与入出金订单 / Return 是否一致  不等 → AI 分析：    · 「差异 $1.50 = 3 笔 $0.50 Decline Fee 未扣」    · 「差异 -$100 = tx_abc123 已授权但未清算，Authorization Hold 状态」    · 「差异 $0.01 = FX 四舍五入，可忽略」

Settlement Agent 能力

AI 建议修复 vs 人工 Approve

Settlement Agent 发现差异 $1.50：  AI 输出：    根因：Entry #789 重复写入（webhook 重复）    建议：INSERT 冲正 Journal      Entry: liability:wallet:user_123 CREDIT $1.50      Entry: liability:fee_payable_to_pm DEBIT $1.50      ref_id: "reversal:entry_789"    置信度：92%  流程：    AI 建议 → 写入 reconciliation_suggestion（含 evidence_bundle 草稿）    → 财务 / 运维 Dashboard 审核    → 人工 Approve 后，由合规工作流调用 Ledger Facade INSERT    → Reject → 保持建议状态，人工另案处理  ❌ AI 不自动 INSERT Ledger Entry，无论置信度或金额  ❌ 不存在「高置信度小额自动 EXECUTE」  ✅ EXECUTED 必须同时有 reviewed_by、reviewed_at、evidence_bundle、executed_journal_id

生产 DDL 与 CHECK 约束以第二十五章 reconciliation_suggestion为准。本章不重复建表。

Settlement Agent 与 Processor 文件

Processor 每日提供：  · Clearing File（T+1）  · Settlement Report（T+2）  · Exception ReportSettlement Agent：  1. 解析 Processor 文件  2. 与 card_transaction + clearing + settlement 表比对  3. 与 Ledger Entry 比对  4. 差异 → AI 分类 + 建议  5. 生成日终对账报告  第十五章的 Network Settlement 在此落地：    Settlement Cash 实际划款 vs Safeguarded Assets 覆盖 vs Processor 报告    三方对齐 — AI 帮找哪一方错了

五个 Agent 协作全景

AI 时代的 VCC 团队

角色变化

工程师的新核心能力

AI 时代 VCC 工程师的价值不在于「写代码速度」在于：  1. 判断 AI 生成的代码是否违反 Ledger 铁律  2. 设计 AI 不能碰的确定性边界  3. 维护本书级别的架构规范（AI 的 System Prompt）  4. Review AI 建议的 Ledger 冲正是否正确  5. 在 AI 不确定时做最终决策  「懂 VCC 业务 + 懂架构约束」比「会写代码」更值钱

构建 AI-Ready 的 VCC 系统

前十五章的设计决策，恰好让系统 AI-Ready：

还需要补充的

1. Audit Log 全覆盖   · 所有写操作 → 谁、何时、什么、为什么   · AI Agent 的操作单独标记 agent_id2. 结构化 Metadata   · card.metadata、transaction.metadata   · Agent 决策上下文存入 metadata3. 自然语言 → API 的 Tool Registry   · Payment Agent 的 tools 从 OpenAPI 自动生成4. 对账 Suggestion 表   · Settlement Agent 的建议持久化 + 人工 Approve 流5. AI Review CI 集成   · 每 PR 自动跑 AI Review   · BLOCK 级别禁止合并

常见误区

本章小结

五个 AI 应用

一个原则

┌─────────────────────────────────────────────────────┐│                                                     ││   AI 负责「读」和「建议」                             ││   确定性系统负责「写钱」                              ││   人类负责「Approve 和兜底」                          ││                                                     │└─────────────────────────────────────────────────────┘

第六部分闭环

第一～七章：理解 VCC 商业本质与产业链第八～十九章：理解钱怎么流（谁赚 + 资金 + 交易）第二十～三十章：设计确定性系统（含第二十章架构全景）第三十一章：AI 在确定性系统之上增强 — 但不替代第三十二～四十九章：把系统、资金和合作方纳入可执行运营控制  没有前三十章的确定性基础  AI 只会更快地制造生产事故

下一章：第三十二章：VCC 运营模型 — 把异常、资金、责任和升级路径组织成日常运营闭环。