3.6 KiB
Session: 2026-06-01 14:36:31 GMT+8
- Session Key: agent:main:feishu:direct:ou_e63ce6b760ad39382852472f28fbe2a2
- Session ID: 0a3698ab-0ea1-495c-b8ae-95d0e7cb1f29
- Source: feishu
Conversation Summary
user: 我们来明确一下怎么判断用户是否加微，通过表bi_vala_app_account中的tel_encrypt字段，关联stride_contact_bindings表中的tel_encrypt字段，能匹配上代表已加班主任微信，匹配不上代表未加班主任微信。
assistant: 找到了，stride_contact_bindings 在 vala_class 库。让我看看表结构。
assistant: 表结构确认完毕。来验证一下匹配逻辑和数据量：
assistant: 跨库（vala_bi ↔ vala_class），需要确认 dblink 是否可用：
assistant: 两个表分属不同数据库（vala_bi ↔ vala_class），PostgreSQL 不支持跨库 JOIN，且 dblink 未安装。让我用脚本方式验证匹配逻辑：
assistant: 验证完毕，以下是结论：
加微判断逻辑验证结果
数据源
| 表 | 库 | 记录数 |
|---|---|---|
bi_vala_app_account |
vala_bi |
28,633 非测试账号（有 tel_encrypt） |
stride_contact_bindings |
vala_class |
2,016 条绑定记录，去重 tel_encrypt 1,973 个 |
按 tel_encrypt 匹配
| 状态 | 人数 | 占比 |
|---|---|---|
| 已加微（匹配上） | 1,247 | 4.36% |
| 未加微（未匹配） | 27,386 | 95.64% |
补充验证：与 vala_account_id 对比
stride_contact_bindings 表里也有 vala_account_id 字段（1,278 条有值），我同时用两种方式匹配做了对比：
| 匹配方式 | 人数 |
|---|---|
| 仅 tel_encrypt 匹配 | 1 |
| 仅 vala_account_id 匹配 | 28 |
| 两种都匹配 | 1,246 |
结论：用 tel_encrypt 匹配覆盖了 1,247/1,274 ≈ 97.9%，和用 vala_account_id 匹配的结果高度一致，差的那 27 个是 stride_contact_bindings 有 account_id 但 tel_encrypt 不一致或为空的边界情况。
⚠️ 跨库注意
两个表分别在 vala_bi 和 vala_class 两个数据库，PostgreSQL 不支持直接跨库 JOIN，实际查询时需要在应用层分别取数据后做交集。
用 tel_encrypt 匹配的逻辑没问题，要我把这条口径写入 MEMORY.md 吗？
user: 写进长期记忆，明确提到是否班主任加微，直接用刚刚的脚本匹配
assistant: Now I'll add the 加微判断逻辑 to MEMORY.md, placing it in the core business metrics section near other data rules.
assistant: 再写个日记忆记录一下：
assistant: 已写入长期记忆，内容涵盖：
- 判断方式：
tel_encrypt字段跨库匹配 - 数据源：
vala_bi/vala_class两库分属 - 跨库处理：应用层取交集，不能直接 SQL JOIN
- 验证脚本：
scripts/check_wechat_binding.py - 当前基准数据：28,633 人中已加微 1,247（4.36%）
后续做加微相关统计直接按这个口径来就行。 user: 另外你需要知道，加微分两种情况，第一种是加班主任微信，是购课用户才会有的行为；第二种是加销售微信，是注册用户就会有的行为。不过现在暂时还没有加销售微信的数据。那么提到加班主任微信率，需要用加班主任微信人数/购课人数。 assistant: 已更新。补充了两个关键点：
- 加微类型区分：班主任微信（购课用户）vs 销售微信（注册用户，暂无数据）
- 加班主任微信率口径：
加班主任微信人数 / 购课人数 × 100%，分母是有支付成功订单的非测试账号去重用户数，不是全量注册用户
后续算加微率时按这个分母来。