XingHuo/docs/项目框架设计/表设计/06-用户画像L1-L3设计.md

用户画像 L0～L3 设计框架

用途： 说明画像四层分工、表结构、JSON 字段约定、与 Core / 适当性 / 客户资料的对齐关系。
DDL： 01-mysql-共用底座.sql · L0： Core模拟底座/01-表结构与种子说明.md
记忆分层： 业务记忆管理手册.md · 适当性落库： 07-risk_suitability_log说明.md

---

1. 四层一句话

层	存什么	权威库/表	谁写	谁读
L0	官方 KYC、正式 C1~C5、持仓/流水	jinrong_core	非 Agent	四 Agent 只读
L1	客户侧偏好、规划、行为（不能改 L0 等级）	customer_profile_l1	客户 Agent	客户本人、代理人、风控、分析
L2	代理人服务记录、诉求、待办（客户不可见）	customer_profile_l2	代理人 Agent	代理人、风控、分析
L3	监测分层、评分维度（不改 L0 等级）	customer_profile_l3	风控 Agent	风控、代理人/分析只读

L0（Core）──── 正式风评、收入、资产、产品事实
     ↑ 只读，禁止覆盖
L1（Agent）── 客户说的偏好、规划、阈值摘要
L2（Agent）── 代理人服务过程 enrich
L3（Agent）── 风控监测 enrich

---

2. L0 与 Agent 画像的边界（2026-09-07 对齐客户手册）

L0 已在 Core 扩展（core_customer + core_customer_risk + core_product），对应客户资料《用户信息数据示例》中的 基础信息 / 投资档案 / 产品属性：

客户资料章节	L0 表/字段	Agent 画像能否写
基础信息（性别、学历、收入…）	core_customer.*	❌ 只读
正式风评 C1~C5、问卷得分、过期日	core_customer_risk.*	❌ 只读
产品 R 等级、起购、期限	core_product.*	❌ 只读
C×R 匹配规则	core_suitability_rule	❌ 只读
产品偏好、口头风格、服务诉求	L1 / L2 JSON	✅ Agent enrich
监测评分、异常行为标签	L3 JSON	✅ 风控 enrich

铁律： L1 里客户说「我比较激进」不能把 L0 的 C2 改成 C5；适当性买卖仍以 L0 + R-02 为准。

---

3. MySQL 画像表结构

3.1 customer_profile_l1（一客户一行）

列	类型	含义
customer_id	PK	与 Core 一致
style_tags	JSON	风格/财务/生命周期标签（见 §4.1）
style_questionnaire	JSON	C-07 问卷答卷与得分摘要（非 L0 正式风评）
allocation_plan	JSON	C-08 资金比例规划
behavior_tags	JSON	行为标签（活跃度、咨询频率等）
attribution_pref	VARCHAR	复盘归因偏好（日/周/月）
version	INT	乐观锁；写入 risk_suitability_log.profile_l1_version 可选

3.2 customer_profile_l2（客户 × 代理人 一行）

列	类型	含义
customer_id + advisor_id	UK	归属维度
asset_snapshot	JSON	A-01 查 Core 后的概况快照（非权威账）
demands	JSON	沟通诉求、关注点
follow_up_todos	JSON	待跟进事项
service_tags	JSON	服务标签（VIP 诉求、适老化等）
source_session_id	VARCHAR	来源会话

3.3 customer_profile_l3（一客户一行）

列	类型	含义
monitor_tier	ENUM	normal / watch / high
risk_score	SMALLINT	监测分（≠ L0 正式 C 档）
score_dimensions	JSON	四维/六维评分快照（见 §4.3）
monitor_tags	JSON	AML/行为异常等标签
last_alert_id	VARCHAR	关联最近预警

---

4. JSON 字段约定（对齐客户资料标签体系）

P0：列名已定；JSON 键名约定在实现 L1/L2 写入前按下列 schema 填充，无需改表。

4.1 L1 style_tags 推荐结构

对照《用户信息数据示例》§1.5 画像标签：

{
  "basic": { "age_band": "25-30", "city": "上海", "education": "本科" },
  "financial": { "income_band": "10-20万", "monthly_investable": "3000-5000" },
  "investment": {
    "goal": "购房储蓄",
    "horizon": "1-3年",
    "product_preferences": ["指数基金", "货币基金"],
    "excluded_products": ["私募", "期货"]
  },
  "lifecycle": { "stage": "单身奋斗期", "near_term_goal": "购房" },
  "threshold_pref_summary": "亏损10%提醒"
}

• threshold_pref_summary：C-04 阈值偏好的 摘要；明细在 customer_threshold_config。
• 禁止在 L1 存「正式 C 等级」——以 L0 为准。

4.2 L2 demands / service_tags 示例

{
  "demands": ["了解赎回规则", "子女教育金规划"],
  "service_tags": { "tier": "vip", "prefer_channel": "counter", "elderly_care": true }
}

4.3 L3 score_dimensions 示例

对照《投资者风险画像研判规则》四维（监测用，不写入 L0）：

{
  "basic_attr": 17.5,
  "invest_experience": 17.5,
  "risk_preference": 8.0,
  "behavior_anomaly": 20.0,
  "computed_at": "2026-09-07T00:00:00Z",
  "model_ref": "JR-RULE-2024-001"
}

---

5. 适当性：L1 与 R-02 的边界

L1 仅辅助 R-02 判断（如规划、偏好），不能替代 L0 风评。
计算/落库流程见 07-risk_suitability_log说明.md。

---

6. Redis 缓存

画像 L1/L2/L3 有热缓存（MySQL 为权威，UPDATE 后 DEL）。Key 明细见 02-redis-keys.md。

---

7. 读写权限速查

角色	L0	L1	L2	L3	suitability_log
客户本人	R	W/R 本人	—	—	R 本人
代理人	R	R 名下	W/R 名下	R 名下	R 名下
风控	R	R	R	W	W
数据分析	R	R 脱敏	R 脱敏	R 脱敏	—

JWT 细则见 02-JWT-RBAC鉴权手册.md §7。

---

8. P0 验收

• L0 事实只来自 Core RO；画像 Tool 无 UPDATE Core
• L1 写入后 version 递增；不写入正式 risk_code
• L2 按 customer_advisor_rel 隔离；客户 API 不可见 L2
• L3 不写 L0；监测分与正式 C 档文档区分
• R-02 写入 risk_suitability_log 与 check_suitability 字段一致