重画后的引擎架构
拖动任意组件重排；点击组件，右侧显示它能干什么、怎么实现、口径、取数来源、做什么判断。
已验证可跑
数据有但口径未定
尚未接入
共 28 个组件
100%
← 点击左侧任意组件查看详情。
可以拖动组件重新排列，连线会跟着走。
可以拖动组件重新排列，连线会跟着走。
与 GPT 那版架构图的三处差异：
① 加了基线归一层——原图没有，导致 detector 会把周末和大盘波动当成异常；
② 归因不是 detector，是循环——原图把 Narrative / Change / Insight Detector 串成三个并列触发器，但归因会反向回去取数，是个带回路的引擎；
③ 五个语义型 detector 合并成一个 Content Reader——它们跑同一份数据、同一次读取，拆开就是 token 五倍。
① 加了基线归一层——原图没有，导致 detector 会把周末和大盘波动当成异常；
② 归因不是 detector，是循环——原图把 Narrative / Change / Insight Detector 串成三个并列触发器，但归因会反向回去取数，是个带回路的引擎；
③ 五个语义型 detector 合并成一个 Content Reader——它们跑同一份数据、同一次读取，拆开就是 token 五倍。
需求清单
两场对齐会提出的全部需求，按类型归组。
| 类型 | 需求 | 说明 |
|---|---|---|
| 归因 要原因，不要数据陈列 | 是什么让 Top20 大R 冲了这么多钱 | 单纯呈现数据无价值——需求侧自己也能拉到 |
| 某人为什么 4 月充很多、8 月充很少 | 需给出候选原因：CP 是否断、家族是否退、当期是否有活动 | |
| 潜在大R 为什么突然愿意花钱 | 成因比结果重要 | |
| 荣耀等级跃升成因不明 | 「很多人上了 S7，不知道为什么」 | |
| 主动监控 不等人来问 | 每天记录 Top20 大R 在玩什么 | 关注平常看不到的细节，不是充值榜 |
| 新活动、新产品上线要有自动监控 | 捕捉功能／活动／实验的上线节奏，不依赖运营主观反馈 | |
| 每个模块的今日大事件 | 抽奖／概率游戏／家族／CP 各自出 | |
| 单个用户送礼量突变 | 整体指标里看不出来 | |
| 群聊内的冲突与情绪 | 今天跟谁吵架、最近跟谁玩得好 | |
| 趋势判断 | 10 连抽大R 集中度 → 玩法是否该迭代 | 大R 抽得特别多即说明该模块需要迭代 |
| 每个模块的风向、问题、机会点 | — | |
| 情侣抽奖的用户结构 | 已上线四五次，需要用户侧分析 | |
| 协作与口径 | 专属名词（军火商等）建立统一口径 | 全公司一套定义 |
| 主动式对话、追问、计划模式 | 低门槛了解某人或某群人 | |
| 把 PRD 作为业务背景注入 | 作为分析时的补充信息 | |
| 活动结束出复盘报告 | 可减少复盘时间，并对结论形成背书 | |
| 数据缺口 | 语音／上麦内容 | 约 1 万元/月，未接入 |
两类使用者，诉求不同：一类只要每日结论，越简越好；一类要原因与前置提醒。已定：按完整版做，简化版另出一个。
多数需求指向同一件事：不要数据，要原因。「为什么 8 月充得少」「为什么突然愿意花钱」「是什么让他们冲了那么多钱」是同一类问题。因此引擎里最该重投入的不是 Detector，是归因链路。
已有一项质疑需要单独回答：接口接上 AI 也能自己读库、列字段，为何还需要 Matrix。
相对自建方案，差异只有四项：① 每日快照的历史存量（diff 的地基）② 统一口径沉淀 ③ 无人提问也会推的节奏 ④ 语音（需付费接入）。这四条讲不清楚，自建方案的使用者不会转过来。
相对自建方案，差异只有四项：① 每日快照的历史存量（diff 的地基）② 统一口径沉淀 ③ 无人提问也会推的节奏 ④ 语音（需付费接入）。这四条讲不清楚，自建方案的使用者不会转过来。
现在到底能拿到什么
2026-08-11 全部实测，非估计。
| 能力 | 表 / 来源 | 实测耗时 | 状态 |
|---|---|---|---|
| 基础画像 + SVIP + 荣耀等级 | dw_user_basic_info_ad JOIN ods_user_level_ad JOIN ods_com_wealth_level_ad | < 2 秒 | 可用 |
| CP 关系 / 家族归属 | ods_com_couple_value_stat_record_ad · ods_com_family_member_ad | < 2 秒 | 可用 |
| 充值逐日全量 | ods_com_cash_order_ad | 0.9 秒 | 可用 |
| 金币消费 / 收入分场景 | ods_com_coin_bill_ad | 1.0 秒 | 可用 |
| 私聊关系统计（逐日轮数） | dm_soc_chat_session_msg_v1_sd | 3.9 秒 | 可用 |
| 私聊原文 | ods.ods_soc_chat_msg_v1_sd | 1.4 秒（批量） | 可用 |
| 群聊原文 | rt.rt_log_message_sd | 1.4 秒 | 可用 |
| 全量分档聚合（1,038 人） | ods_com_coin_bill_ad 聚合 | 2.4 秒 | 可用 |
| 分区域 Top 榜（三表 join + 窗口函数） | 三表 JOIN | 2.1 秒 | 可用 |
| 房间进出 / 上麦时长 | ods_flw_log_message_sd（JOIN_ROOM／EXIT_ROOM／OPEN_MICRO）JOIN ods_soc_chat_room_ad | 4.3 秒（聚合 780 万条） | 可用 |
| 活动起止时间 / 玩法说明 | 服务端开关 · 后台配置 · 活动说明文档 | — | PDF 待接 |
| 活动渗透率 | 无来源 | — | 完全缺失 |
| 语音内容 | 外部转写 | — | 约 1 万/月 |
结论已经变了。一天之内这个判断改了三次，每次都是实测推翻转述。最终只剩两件事真的拿不到：活动元数据（活动说明文档到位即解）和语音（约 1 万/月）。
房间行为、私聊原文、群聊原文全部实测可读。
房间行为、私聊原文、群聊原文全部实测可读。
两个类型坑：①
ods_flw_log_message_sd 的 uid 是 varchar，必须 cast(uid as varchar)='...'——写成 uid=123 返回空、写成 uid='123' 会抛连接异常。② 单人单日用 f_uid=X or t_uid=X 查私聊原文要 16.3 秒（两列 OR 做不了分区裁剪），但 uid IN (watchlist) 批量查 200 人成本几乎相同。设计文档里「批量不循环」这条决策是对的。需求支撑矩阵
逐条对照。✅＝现在就能给出判断 ⚠️＝能给一半，缺关键一环 ❌＝完全撑不住
| 需求 | 靠哪些组件 | 能否 | 缺什么 |
|---|---|---|---|
| Top20 大 R 在 app 里玩什么 | 分区域 Top 榜 → 个人档案 → SQL-7 场景分布 | ✅ | 已跑通：印尼 Top20 近 30 天 1,373 万金币，概率游戏 80.5%／群聊抽奖 16.5% |
| 是什么让他们冲了那么多钱 | 归因引擎 + Event Causality + 关系事件 | ⚠️ | 口径问题不是数据问题——支出去向≠充值动机。需定义「充值前 24h 窗口内哪些因素在场」的共现口径 |
| 今天在群里跟谁吵架了 | Content Reader（群聊原文） | ✅ | 表已验证可读，缺的是语义识别 prompt |
| 新活动新产品上线要有自动监控 | Event Causality + Baseline | ⚠️ | 缺活动起止时间。活动说明文档到位后即可解 |
| 为什么 4 月充很多、8 月充很少 | 归因引擎（五假设 + 对照组 + 脉冲历史） | ✅ | 已完整跑通。四条独立数据线交叉验证，风险由高下修为中 |
| 是 CP 断了？家族退了？还是 4 月有活动他参加了 | SQL-2 CP + SQL-3 家族 + Event Causality | ⚠️ | 前两项已能答（CP 未断、家族未退），第三项缺活动元数据 |
| 很多人莫名其妙上了 S7，不知道为什么 | Emerging Big-R + 归因引擎 | ✅ | 荣耀等级跃升可检出，成因可归因 |
| 某个人突然送礼很多／很少，整体看不出来 | Spending Δ + Baseline（个体级） | ✅ | SQL-6 礼物流转现成，缺阈值 |
| 功能上线后真的有人在充值并领奖励吗 | Event Causality + 活动元数据 | ⚠️ | 同上，缺上线时间锚点 |
| 帮我背书，减少复盘时间 | 活动看板 + 复盘报告生成 | ⚠️ | 报告结构已定，缺真实活动样本 |
| 10 连抽有钱人抽得特别多 → 模块该迭代了 | Whale Concentration Shift | ✅ | 已跑出基线：大R 占人数 7.0%、占金币 51.7%、人均 14.1×。缺的只是时间序列跑起来 |
| 潜在大 R 怎么突然愿意花钱了 | Emerging Big-R + 归因引擎 | ✅ | 同上 |
| 分析玩情侣抽奖的用户情况 | SQL-7 + 大R 名单取交集 | ✅ | CP 抽奖 1,571 人已跑出，取交集是一条 SQL |
| 把 PRD 喂给它当补充信息 | — | ❌ | 没有对应组件。需要「业务背景注入」机制，即模块 Agent 应长期携带的内容 |
| 每个模块的风向、问题、机会点 | Game Trend + 业务看板 | ⚠️ | 趋势能出，「机会点」需要 Insight 层积累 |
| 在页面上收敛一个大问题 | 问题线程（四阶段收敛） | ⚠️ | 流程已设计，问答接口没开 |
| 语音内容 | — | ❌ | 约 1 万/月，未接 |
| 「AI 自己就能读库」这一质疑的回应 | 每日快照库 + 口径沉淀 + 主动推送 | ⚠️ | 快照库尚未建立，这是回答该质疑的第一项依据 |
| 全公司统一口径 | 问题线程 + 口径提拔 | ⚠️ | 机制已设计，缺一个真正被多人复用的样例 |
| 主动式对话、追问、计划模式 | 问题线程 | ⚠️ | 同上，卡在接口 |
| 每个模块的今日大事件 | 每日大事件 + 各模块 detector | ⚠️ | 框架有，各模块口径需业务侧定义 |
21 条需求：8 条现在就能答，11 条缺一环，2 条完全撑不住。
而缺的那 11 条里，有 5 条卡在同一个东西——活动元数据（起止时间 + 玩法说明）。活动说明文档到位后，可答条数从 8 条增至 13 条。
另外 3 条卡在问答接口没开，2 条卡在每日快照库还没建。
而缺的那 11 条里，有 5 条卡在同一个东西——活动元数据（起止时间 + 玩法说明）。活动说明文档到位后，可答条数从 8 条增至 13 条。
另外 3 条卡在问答接口没开，2 条卡在每日快照库还没建。
真正没有对应组件的只有两条：「把 PRD 喂进去」和「语音」。前者不是数据问题——它要的是业务背景注入，也就是让某个模块 Agent 长期带着这个玩法的设计意图，而不是每次提问都重讲一遍。对应「AI 不理解产品概念」这一既有问题。
Detector 到底要不要 AI
2026-08-11 用真实数据逐条跑过。样本＝印尼 504 名持有有效荣耀等级的用户，数据日 2026-08-10，全部为当天实跑结果。
结论：15 条里 8 条完全不用 AI、5 条必须用 AI、2 条根本不是 Detector。但今天跑下来最重要的发现不是这个分类——是不用 AI 的那批，真正的难点在口径，不在算法。我把三条「纯 SQL 就能做」的 detector 按最直觉的写法跑了一遍，三条结果全部错误。
① 不用 AI 的那批：三条我故意用直觉写法跑，三条全错
| Detector | 最直觉的写法 | 实测命中 | 口径修正后 | 差多少 |
|---|---|---|---|---|
| Family Change 家族变化 | 逐日快照对比 family_id 变了就报 | 35,514 条 watchlist 被撑成 38,459 | 加 status=1（在册）1 加入 + 3 退出 + 1 转会 | 5 条 差 7,100 倍 |
| Relationship Change 核心关系变化 | valid=1 当作「当前 CP」逐日 diff | 跑不了 426 人有 valid 记录，其中 409 人不止一条 | 人均 28.2 条 valid=1，最多的一个人 193 条——valid=1 是「这段关系曾经成立过」，不是「现在是 CP」 | 纯 diff 完全不可用，得先定「当前 CP」怎么取 |
| Spending Surge / Drop 消费异常 | 近 7 日 vs 前 7 日，涨 100% 或跌 50% 就报 | 189 人 / 504 surge 74 ＋ drop 115 ＝37.5% 的人天天被点亮 | 叠加绝对量门槛（任一周 ≥50 万金币） surge 3 人 ＋ drop 2 人 | 5 人 差 38 倍 |
这三条从头到尾一行 AI 都没用到，也不需要用。「用原数据堆砌」这个说法对了一半——确实是堆数据，但堆之前必须有人把口径钉死。Detector 的成本不在写 SQL，在定义。
还有一个更隐蔽的问题：纯百分比阈值会把两件不同的事混在一起。实测消费涨幅第一名是 12927899，prev7＝694 金币、cur7＝908,056 金币，涨了 13 万 %——但他不是 Spending Surge，他是 Emerging Big-R（从零起量）。同一条规则打中了两个完全不同的业务事件，这也是口径问题，不是模型问题。
还有一个更隐蔽的问题：纯百分比阈值会把两件不同的事混在一起。实测消费涨幅第一名是 12927899，prev7＝694 金币、cur7＝908,056 金币，涨了 13 万 %——但他不是 Spending Surge，他是 Emerging Big-R（从零起量）。同一条规则打中了两个完全不同的业务事件，这也是口径问题，不是模型问题。
② 必须 AI 的那批：关键词方案实测下来是这个样子
同一批 504 人，2026-08-10 一天的私聊纯文本消息共 5,918 条，179 人发过。用最标准的关键词方案跑：
| Detector | 关键词方案 | 实测命中 | 为什么关键词不行 |
|---|---|---|---|
| Competitor Mention 竞品提及 | soul｜litmatch｜yalla｜mico｜tango｜hago｜bigo｜azar | 0 条 | 不是没人提竞品——是用户根本不说品牌名。抽样里的原话是「di ig apa fb apa di apk lain」（在 ig 还是 fb 还是别的软件）。关键词方案会直接给出「今天没有竞品问题」的错误结论 |
| Off-platform Migration 站外导流（全称） | whatsapp｜telegram｜wechat | 0 条 | 没有人打全称 |
| Off-platform Migration 站外导流（缩写） | \bwa\b｜\btg\b｜\big\b | 94 条 | 命中率较高，抽样 45 条中多数为真实导流意图（「boleh minta WA kamu」＝能给我你 WA 吗、「lempar no wa nya」＝把号扔过来、「yaudah lanjut WA」＝那就转 WA 聊）。但关键词分不清三种完全不同的状态：正在导流 / 早就在站外了 / 抱怨对方把自己拉黑了。噪音里还混进了「wa'alaikumsalam」这种问候语 |
| Gift Stop 劝阻送礼 | (jangan｜stop｜jgn) ＋ (kirim｜gift｜hadiah) | 1 条 | 劝阻的说法有无数种，枚举不完。而且真正该抓的是语气不是词 |
| Product Complaint 产品吐槽 | —— | 没有方案 | 情绪判断，压根没有可枚举的关键词 |
| Activity Mention 活动讨论 | event｜acara｜promo｜diskon | 14 条 | 分不清「在讨论这次活动」和「随口说了个 event」 |
注意这五条的失败方式和上面三条正好相反。上面是命中太多——假告警淹没人；这里是命中太少——假安静。竞品提及关键词一天跑出 0 条，会让人以为「竞品不是问题」，而实际上用户天天在说「别的软件」。
这就是 AI 唯一不可替代的地方：它读的是意思，关键词读的是字。而且这五条跑的是同一份数据、同一批人、同一次读取，所以在架构里应该合并成 一个 Content Reader 输出多标签，拆成五个 detector ＝ 读五遍 ＝ token 五倍。
这就是 AI 唯一不可替代的地方：它读的是意思，关键词读的是字。而且这五条跑的是同一份数据、同一批人、同一次读取，所以在架构里应该合并成 一个 Content Reader 输出多标签，拆成五个 detector ＝ 读五遍 ＝ token 五倍。
③ 两条根本不是 Detector
| 清单里的位置 | 实际是什么 | 实测状况 |
|---|---|---|
| 14. Consumption Driver 消费驱动力 | 归因层任务 | 它问的是「为什么花钱」，答案不可能由一条规则触发。而且用 commodity_name 分类做出来的是支出去向图，不是驱动力图 |
| 15. Event Causality 事件因果 | 归因层任务 ＋缺数据 | 今天把 information_schema 全库搜了一遍：activity / campaign / operat 三个词只命中 4 张表，全部是推送日志和内容审核记录（ods_opr_operation_record_ad 里是「Drop Post-Meaningless」这类审核动作）。数仓里没有任何一张活动元数据表，这条现在一条都跑不出来。 |
这也是为什么 GPT 说「重点把 14＋15 做好」这句话方向对、位置错。它俩确实是最值钱的，但它俩不在 Detector 层——把它们和 Spending Surge 并列，等于把「量体温」和「做诊断」写在同一张清单上。
④ 最干净的一条，也是最该先做的一条
Emerging Big-R
潜在大R
- 全平台每天新增持有荣耀等级的用户 1–9 人，近 30 天合计 74 人（实测逐日：8/10 三人、8/9 三人、8/8 一人、8/7 四人、7/31 九人）
- 纯 SQL，零噪音，不需要阈值也不需要 AI——它不是「超过某个数就报」，是一个离散事件
- 对应需求「荣耀等级跃升成因不明」
- 难的部分不在检出，在回答「为什么他上来了」——那是归因引擎的活
⑤ 那 AI 到底用在哪：三个位置，一条禁区
| 位置 | 要 AI 吗 | 理由 |
|---|---|---|
| 采集（12 条 SQL 定时跑） | 不要 | 确定性管道，每天必须跑出一样的东西 |
| Baseline 基线层 | 不要 | 统计，不是判断 |
| 结构化 Detector（8 条） | 不要 | 规则必须可复现。这三处若交给 AI 现写 SQL，它每天漏的地方还不一样——昨天 5 条今天 35,514 条 |
| Content Reader | 要 | 上面 ② 那五条的执行体，唯一不可替代 |
| 归因引擎 | 要 | 要提假设、要决定下一步跑什么、要判断什么时候数据枯竭 |
| 汇总层 | 要 | 发现跨模块同步性——单个模块永远看不出来 |
禁区：不要让 AI 自己写 detector 的判定 SQL。口径必须是人钉死的常量，写在配置里，改动留痕。这三个案例——
status=1、valid=1 的真实语义、绝对量门槛——没有一个是从字段名能猜出来的，都是打开原始数据看了才知道。让 AI 每天现猜，就会出现「为什么昨天说 A 今天说 B」，那是最难解释的一类问题。⑥ 这些信息够不够做最终的归因判断
不够。Detector 回答「什么变了」，归因还要三样东西，而这三样 detector 一个都不产出。
| 归因需要 | Detector 给不给 | 实测例子 |
|---|---|---|
| 对照组 「这根本不是他个人的事」 | 不给 | Detector 是单人视角。Witcher 那次能排除大盘因素，靠的是「同期印尼荣耀用户日充值 8/7 达 4,128 万、8/8 达 4,275 万，均为近期高点」——这个数字任何单人 detector 都不会产出 |
| 历史纵深 「这只是间歇期」 | 不给 | Detector 比的是昨天，归因要比这个人自己的节奏。Witcher 是 4 月爆 3,908 万 → 6 月整月零 → 7 月再爆 3,321 万；本次静默仅 11 天，远短于上一轮的 48 天，所以风险从高下修为中 |
| 外部事件 「那天上了什么」 | 不给 而且现在没有数据 | 数仓 0 张活动元数据表。8/8 那次只能靠跨模块同步性反推「有全局事件」，推不出是哪个活动 |
所以 GPT 那条链我同意，但要改两处：
① 在 Detector 前面插一层 Baseline——不然 Detector 产出的全是噪音，链路后面再漂亮也没用；
② Event → Narrative 之间不是单向箭头，归因引擎会回头去查原始数据（查对照组、查这个人自己的历史）。它是一个会反向取数的循环，不是流水线。
它那句「现在最该做的不是继续增加 Detector 数量」是对的，而且今天的数据给出了更强的版本：加数量的边际收益是负的——每多一个没定口径的 detector，就多几万条假告警。
① 在 Detector 前面插一层 Baseline——不然 Detector 产出的全是噪音，链路后面再漂亮也没用；
② Event → Narrative 之间不是单向箭头，归因引擎会回头去查原始数据（查对照组、查这个人自己的历史）。它是一个会反向取数的循环，不是流水线。
它那句「现在最该做的不是继续增加 Detector 数量」是对的，而且今天的数据给出了更强的版本：加数量的边际收益是负的——每多一个没定口径的 detector，就多几万条假告警。
Detector 清单与优先级
在 GPT 那 15 条基础上：合并 5 个语义型、去掉同群传染（并入 Family Change）、把 Consumption Driver 与 Event Causality 拆出 Detector 层、补 5 个。逐条的实测依据见「Detector 要不要 AI」页。
排序原则改了。原来按「价值高低」排，跑完数据后改成按口径确定度排——因为实测下来，口径没定的 detector 不是「效果差一点」，是直接产出几万条假告警（Family Change 差 7,100 倍、Spending Surge 差 38 倍）。一个没定口径的 detector 的价值是负的。
| 优先级 | Detector | 为什么是这个位置 | 状态 |
|---|---|---|---|
| P0 | Baseline Breaker｜基线过滤器 | 前置层，非并列项。不先做则下游全是噪音 | 待建 |
| P0 | Churn Signal｜流失信号（含 Anomaly Silence） | 今天完整跑通 Detector→Insight 全链 | 已验证 |
| P0 | Emerging Big-R｜潜在大R | 两方需求都指向它；冬的案例已验证 | 已验证 |
| P0 | Event Causality｜事件因果 | 8/8 案例已验证；活动看板的地基 | 已验证 |
| P1 | Content Reader｜原文综合阅读 | 合并竞品／吐槽／活动讨论／劝阻送礼／站外导流五项，一次读完出多标签 | 表可读 |
| P1 | Whale Concentration Shift｜集中度漂移 | 「大R 是否已不满足现有玩法」的直接指标 | 口径待定 |
| P1 | Family Change｜家族变化（含生态异常、多人） | 已发现 74 人贡献 1,342 万的背离案例 | 口径待定 |
| P1 | Supply Chain｜军火商 | v2 已跑出，暴露三处口径漏洞 | v3 待定 |
| P1 | Spending Surge / Drop | 必须先接 Baseline，否则每个周末报一次 | 依赖 P0 |
| P2 | Game Trend｜玩法趋势 | 数据现成，但价值弱于集中度漂移 | 可跑 |
| P2 | Reciprocity Break｜互动失衡 | 私聊数据已验证可用 | 可跑 |
| P2 | First-time Behavior｜首次行为 | 依赖存量档案库，没有它做不出「第一次」 | 依赖档案库 |
| P2 | Room Migration｜房间迁移 | 实测可跑，卡在「主场房间」怎么定义 | 口径待定 |
| P3 | 语音类 detector | 约 1 万/月，先接一个月试 | 未接入 |
被移出 Detector 层的两个：Consumption Driver（14）和 Event Causality 的分析部分（15）。它们不是触发器而是分析任务——把它们和 Spending Surge 并列，像把「量体温」和「做诊断」写在同一张清单上。Event Causality 保留了它可触发的那一半（跨模块同步性检验），分析部分归到归因引擎。
关于「消费驱动力」怎么才算做对：用
commodity_name 分类做出来的是支出去向图，不是驱动力图。
实测印尼 Top20 大R 近 30 天 1,373 万金币里，概率游戏占 80.5%、群聊抽奖 16.5%、礼物与关系类合计只有 0.64%。
但 Witcher 的案例显示：动机在关系，支出在概率游戏——8/7 充值和 8/8 私聊是连着的。
要测「为什么花钱」，得看每笔充值前 24 小时窗口里哪些因素在场，做共现频次，而不是看钱花到哪去了。落地路线
按依赖关系排，不按重要性。
第 0 步
现在就能做
- 建每日快照库——Daily Brief 的本质是 diff 不是当日快照，没有存量什么都做不了。而且它同时是 Timeline 与 Snapshot 的地基
- 做 Baseline Breaker——三条基线：周末/工作日、大盘同期、用户自身历史节奏
第 1 步
P0 三个 detector
- Churn Signal · Emerging Big-R · Event Causality，每个都带完整归因链，而不是只会报警
- 此时可以对外说：Matrix 能回答「为什么」，不只是「是什么」
第 2 步
卡在别人手上，越早发起越好
- 行为宽表（研发侧）——按 UID 查当天全部行为再按时间排序，先覆盖群聊
- 活动宽表规范（数仓侧）——固定字段
key／source／变量，各活动 DIY 部分统一塞ext。字段规范由需求侧给出，已达成一致；该窗口有时效 - 活动上下线自动打点——服务端开关有上线群告警，后台配置也能取，都不用人工
- 问答接口——目前未开放
第 3 步
只有 PM 能做
- 军火商 v3 定义（补：排除自送自收、官方运营号白名单、币来源须为充值）
- 家族生态、今日大事件的口径
- 风险等级与星级的阈值规则
- 「可跑全量 vs 只能 TOP5-10 举例」的数据清单
悬而未决
需要先拍板
- 简化版与完整版拆不拆——已定：按复杂的做，简化版另出一个
- 多人共用时记忆串不串在一起
- 语音要不要接（约 1 万/月），以及一个月后的去留判据