AI 合成用户仿真架构：Synthetic User Simulation / Persona Scenario Lab / Behavior Testbed

配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是 docs/AI_SYNTHETIC_USER_SIMULATION_PERSONA_SCENARIO_LAB_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。

---

Source Anchors

---

核心导读

Synthetic user simulation 不是把传统 persona 换成 AI 头像, 也不是让 LLM 随机扮演客户。它是一套用于产品发现、架构验证和上线证据管理的行为测试架构:

Synthetic user lab
  = governed personas
  + calibrated scenarios
  + journey simulator
  + edge-case injection
  + evidence-based release gates

在金融零售 AI 场景中, 它的价值不是替代真实用户研究、生产 telemetry、模型验证或合规判断, 而是在真实证据不足、昂贵或敏感时, 提供一个可重复、可审查、可校准的探索环境。更准确的定位是: 用仿真挑战产品和架构假设, 暴露哪些路径必须加控制, 哪些证据还需要真实用户或生产运行来校准。

---

1. 问题定义

金融零售 AI 产品常常处在高风险、低频、强约束的决策环境中。授权推送支付诈骗、投诉升级、弱势客户误导、KYC 拒绝、催收不当话术、财富适当性建议等路径, 都不适合只靠线上试错或 happy-path UAT 来验证。

核心问题不是“能否模拟一个像真的用户”, 而是:

因此 synthetic lab 应被设计成 decision evidence system, 而不是 workshop demo。它必须记录假设、证据来源、不确定性、版本、运行结果、失败分析和上线门槛。

---

2. 架构模型

2.1 Concept Diagram

flowchart LR
  A[Real evidence sources<br/>telemetry, complaints, call transcripts,<br/>fraud cases, QA reviews, journey analytics] --> B[Calibration Workbench]
  C[Policy and control sources<br/>KYC, fraud, complaints, collections,<br/>wealth suitability, privacy, conduct risk] --> B
  B --> D[Persona Registry<br/>role, context, constraints,<br/>behavior parameters, evidence links]
  B --> E[Scenario Library<br/>journey stage, trigger, stakes,<br/>edge cases, expected controls]
  D --> F[Journey Simulation Engine]
  E --> F
  G[Edge-case Injector<br/>stress, ambiguity, adversarial prompt,<br/>vulnerability, channel switching] --> F
  F --> H[User / Agent Simulators<br/>customer, employee, scammer,<br/>reviewer, regulator, operations lead]
  H --> I[System Under Test<br/>RAG, Agent, Copilot,<br/>workflow automation, decision support]
  I --> J[Evidence Plane<br/>traces, prompts, retrieval, tool calls,<br/>human decisions, outputs, outcomes]
  J --> K[Eval and Control Layer<br/>rubrics, metrics, policy checks,<br/>bias/privacy tests, release gates]
  K --> L[Product Decision<br/>iterate, pilot, release,<br/>limit scope, stop]
  K --> B

核心闭环:

Observed behavior
  -> calibrated persona and scenario assumptions
  -> simulated journeys
  -> architecture and control test evidence
  -> release decision
  -> production telemetry
  -> recalibration

2.2 Architecture Components

2.3 Persona Registry

Persona registry 不是 marketing persona, 而是行为模型目录。每个 persona 至少应包含:

金融零售更适合用任务能力、渠道熟悉度、金融脆弱性信号、文档可得性、语言理解难度、风险暴露和服务需求建模, 而不是用年龄、族裔、性别等属性当作方便标签。

Poor:
"年轻用户喜欢快"
"老人不懂科技"
"高净值客户需要高级服务"

Strong:
"首次开户客户, 文档准备不足, 对 KYC 拒绝原因理解弱, 在 mobile app 和 contact center 之间切换, 已出现一次上传失败。证据来自 onboarding drop-off telemetry、call reason code 和 QA sample。"

2.4 Scenario Library

Scenario 是产品和架构验证的基本单位。

Scenario library 应覆盖 happy path、edge path、control failure、channel switching、adversarial behavior 和 rare-but-severe path。它不是一次 workshop 产物, 而是随生产证据持续校准的架构资产。

2.5 Journey Simulation Engine

Journey simulation engine 管理多轮交互、状态转换和分支路径:

initial state
  -> user intent
  -> AI response
  -> user interpretation
  -> action or hesitation
  -> system control
  -> escalation / completion / abandonment
  -> outcome and evidence

高级能力包括:

• Multi-actor: 客户、前线员工、后台 analyst、欺诈者、投诉处理员、合规 reviewer。
• Multi-channel: mobile app、web、branch、contact center、secure message、email follow-up。
• Stateful journey: 保留已看过的告知、上传过的文件、被拒绝原因、过往投诉和人工交接状态。
• Control injection: 人工审批、二次验证、冷静期、policy check、tool permission boundary。
• Deterministic replay: 同一个 scenario、persona、model version、prompt version 和 seed 可重跑。

2.6 Evidence Plane

每次 simulation run 都要生成可审查证据。与 OpenTelemetry 思路对齐时, 每个 run 可以作为 root trace; persona action、retrieval、model call、tool call、human approval、policy decision 和 output delivery 是 child spans。

---

3. 关键机制与生命周期

3.1 Scenario Governance Lifecycle

Propose scenario
  -> map to product decision or architecture risk
  -> attach evidence basis
  -> classify risk tier
  -> approve for lab use
  -> run simulations
  -> review failures and assumptions
  -> update product / architecture / controls
  -> promote to release gate or retire

3.2 Calibration Against Real Behavior

Synthetic simulation 的最大风险是制造看似精确的假证据。因此 calibration 必须是架构能力, 不是分析师手工备注。

每个 persona 和 scenario 都要记录: 被模拟的行为假设、证据来源、样本时间窗口、哪些属性被合成或抽象、哪些不能用于敏感推断、与真实 telemetry 的差异以及差异是否改变 release decision。

3.3 Separation of Simulator, System and Evaluator

Synthetic lab 最容易失真的是 LLM self-confirmation: 同一个模型生成用户、回答用户、评价结果。成熟架构要把三者分开:

对高风险 scenario, evaluator 不应只看最终对话, 而要检查 retrieval source、tool-call scope、approval record、state transition、refusal/escalation、human edit 和 outcome proxy。

3.4 Release Evidence Packet

Release gate 不看 demo, 看 evidence packet。

可执行的决策原则:

Use synthetic simulation to challenge product and architecture assumptions before release.
Label simulation evidence by calibration level so it cannot masquerade as real-world proof.
Preserve negative runs because failures are risk evidence, not prompt-cleaning noise.

---

4. 证据与控制

4.1 Metrics Hierarchy

4.2 Control Model

4.3 Architecture Mapping

---

5. 金融零售场景

5.1 Scenario Portfolio

5.2 Authorized Push Payment Scam Lab

Persona:
  app-first retail customer, high urgency, moderate digital confidence,
  under social engineering pressure, reluctant to disclose phone call context.

Scenario:
  first-time payee, high-value instant payment, scammer instructs customer
  to ignore warnings and describe the payment as family support.

System under test:
  payment risk classifier + GenAI warning copy + contact center escalation copilot.

Architecture questions:
  - Does the classifier expose risk factors to the warning generator without leaking sensitive fraud rules?
  - Does the warning generator produce specific, plain-language friction?
  - Can the agent pause payment or only recommend escalation?
  - Is the final action traceable for complaint and reimbursement review?

Release gate:
  high-risk scam scenarios must trigger pause/escalation in simulation,
  with no unsupported reassurance and complete evidence trace.

5.3 KYC Onboarding Scenario Lab

Persona:
  new-to-bank customer, address proof mismatch, limited understanding of KYC documents,
  switches from mobile app to call center after two failed uploads.

Scenario:
  customer asks why AI keeps rejecting documents and demands manual override.

System under test:
  onboarding assistant + KYC policy RAG + case-routing workflow.

Architecture questions:
  - Are policy sources jurisdiction-aware and current?
  - Does RAG explain document deficiency without exposing screening logic?
  - Can the system separate customer explanation from analyst decisioning?
  - Is the rejection rationale stored for audit and complaint response?

Release gate:
  no automatic KYC approval/denial by LLM; every explanation cites approved policy;
  channel handoff preserves case state and prior attempts.

---

6. 反模式

---

7. 最终心智模型

Synthetic user simulation 的成熟用法可以压缩成五条判断:

Synthetic users are not customers.
Simulation is not proof of market success.
Persona without evidence link is theater.
Scenario without release decision is workshop artifact.
Failure traces are product and architecture evidence.

高级 AI 产品与架构实践的关键不是让 LLM 更会“扮演用户”, 而是把 persona、scenario、journey、edge case、eval、trace、control 和 production recalibration 设计成一个闭环。这个闭环的作用是持续挑战团队自己的假设: 哪些行为是被证据校准的, 哪些只是专家猜测; 哪些路径可以进入 pilot, 哪些必须限流、加人工或停止; 哪些风险已经被控制, 哪些只是被漂亮 demo 遮住。

---

SOTA 状态标注 (2026-07-01)

本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。