AKKE决策调研 · DECISION RESEARCH · 2026
① 框架横评 ② 装修场景选型 ③ RAG 行业建模 ④ 用户建模
任务 4 / 8五大战略 · 主题4 · 微信自动化工作流（加V后两场景）

微信工作流的用户建模：复用现有 + 补跨平台身份

抖音获客 → 加微信 → 「小艳」人设在微信里维系到到店。问题不是"微信场景要不要重做一套用户建模"，而是"抖音 DM 那套阶段 / 记忆 / 物料能不能直接搬过来、还差哪一环"。结论先行：地基已在生产跑，真缺口是跨平台身份贯通，不是重打地基。

结论
复用并扩展现有 memory.ts + 阶段机 + conversation_examples 复用；微信工作流的用户建模地基已在生产跑，真缺口是 跨平台身份贯通（抖音→微信） + 专属物料库，是窄增量不是重打地基。
3
用户建模三要素：阶段 / 记忆 / 专属物料
2.5 件
三要素落地度：阶段评估 + 记忆 在产，物料半成品
复用扩展
决策：不另起 framework，窄增量补环
跨平台身份
微信比抖音 DM 多的关键新缺口（主题4 C2 待建）

01 微信工作流的用户建模：三要素 + 两个新维度

对话式销售要"记住人、读懂阶段、说对话"——三要素是通用框架；微信场景在此之上多了两环。

对话式销售（conversational selling）的用户建模通用框架收敛为三件事：① 阶段（这人现在到漏斗哪一步、该用什么话术）② 记忆（这人是谁、之前说过什么、别重复问）③ 专属物料（用对的案例 / 话术 / 素材打动他）。conversational sales modeling · 通用框架 这三件抖音 DM 侧已全部在产。

微信工作流的用户建模，比抖音 DM 多两个新维度——它们是这次调研的真正增量：

新维度 ① · 跨平台身份贯通
抖音用户 → 微信好友是同一个人。抖音侧靠 douyin_user_id 串起记忆；加微信后若不贯通身份，画像就断片——"加了微信就失忆"。这是微信工作流最关键的新环。
新维度 ② · 到店邀约阶段
抖音 DM 的终态是"加上微信"；微信场景的终态是 store_invite 到店邀约。漏斗多出一段，阶段机要新增一个终态阶段去推进。
大脑（chatReply）复用不变：通道从抖音 DM 换成 微信 kf API / 企微 PC / WDA，但"读阶段 → 调记忆 → 切提示词 → 出草稿 → 护栏闸门"这条 agentic 流水线 1:1 克隆。WBS 主题4 · 接驳（1:1 克隆抖音侧）

02 三件套成熟度评估（核心图表）

grep 核验生产代码：阶段评估 ~95%、记忆 ~75%、专属物料 ~45%。

图1 · 用户建模三要素 · 当前成熟度
阶段评估
95
记忆 / 画像
75
专属物料
45
成熟度 = 该要素在生产代码里跑通的程度（含微信场景所需扩展）。阶段评估缺的只是 store_invite 一个新终态；物料库缺结构化采集与检索。
图2 · 要素 / 现状 / 证据矩阵
要素现状状态代码证据
阶段评估 三态 stage machine 在产（ice_break / nurture / decision），chatReply 按 stage 切系统提示词；classifyDecorationStage 打装修阶段信号。微信新增 store_invite 终态待建。 在产 src/lib/llm.ts:931 case "ice_break"…
记忆 / 画像 按 (org_id, douyin_user_id) 跨会话浅合并 customer_profile JSONB、最近 3 会话、org 隔离；解决"二次触达重问面积/预算 = 最响的机器人信号"。 在产 src/lib/memory.ts:46 loadCustomerHistory
专属物料 conversation_examples（18 条金牌对话，按 stage top-3 注入 buildExampleBlock）已在产；节日话术 / 朋友圈点赞 / 结构化物料库为主题5 + 主题4 场景a 待建。 半成品 src/lib/llm.ts:369 buildExampleBlock
跨平台身份贯通 微信新增 靠 备注解析回填 douyin_user_id + wechat_contacts 表 + memory.ts 画像跨平台带入。 待建 WBS 主题4 · C2

03 阶段机怎么跑（图表）

三态在产 + 微信终态 store_invite —— chatReply 在每个阶段切不同系统提示词。

图3 · 对话阶段状态机（含微信新增终态）
STAGE · 在产
ice_break · 破冰
首条 DM / 冷启动。opener 死禁外发我方微信号（撞抖音风控），走反问要号路径。
STAGE · 在产
nurture · 培育
分品类报价 + 维系。注入 customer_profile + 最近 3 会话画像，不重复问已知信息。
STAGE · 在产
decision · 决策
主动外发 brand_profile.wechat_id + 让客户备注「抖音 + 昵称」，设计师对号入座。67 案例复盘后 2026-06-22 翻转为主动外发。
STAGE · 微信新增 · 待建
store_invite · 到店邀约
微信场景 b 的终态：聊到约客户到店。WBS 主题4 B1 新增（LLM, 2d），抖音 DM 没有这一段。
每个阶段 chatReply 拉不同 Langfuse 系统提示词（dm.ice_break.system / dm.nurture.system / dm.decision.system）；微信侧 store_invite 复用同一切换机制新增一段。src/lib/llm.ts:848 per-stage prompt
口径锚定：当前生产代码只有 ice_break / nurture / decision 三态（grep store_invite 在 src/ 无命中）；store_invite 是微信工作流的待建终态，不是已上线功能。阶段评估成熟度 ~95% 指的是"切换引擎成熟、只差加一态"。

04 跨平台身份贯通（微信特有 · 重点图表）

抖音用户 → 微信好友是同一人。这是微信工作流比抖音 DM 多的关键环，避免"加了微信就失忆"。

图4 · 抖音 → 微信 身份贯通数据流
SOURCE
抖音用户
由 douyin_user_id(sec_uid) 唯一标识，抖音侧记忆已串好。
HANDOFF
加微 + 备注
decision 阶段让客户备注「抖音 + 昵称」。
PARSE
备注解析回填
解析微信备注 → 回填 douyin_user_id，把两个身份对上。
TABLE · 待建
wechat_contacts
微信联系人 ↔ 抖音用户映射表 + RLS（主题4 C2）。
REUSE
memory.ts 带入
同 key 取出 customer_profile，跨平台带入画像。
SINK
微信 chatReply
续接同一人画像 / 阶段 / 历史，无缝接力。
关键设计：身份贯通的"锚"是 decision 阶段那句"备注抖音 + 昵称"——它把客户主动带的标识变成可机器解析的回填键。project_akke_wechat_handoff.md · WBS 主题4 C2
不贯通的代价
客户在抖音说过"120 平、预算 15 万、想要现代简约"；加微信后画像断片，小艳又从零问一遍 → 最响的"这是机器人"信号，高意向客户当场流失。
贯通后的收益
微信第一句就能接"上次您说 120 平那套现代简约……"，无缝接力。复用 memory.ts 现成浅合并逻辑，增量只是 wechat_contacts 一张映射表 + 备注解析。

05 记忆怎么跑（图表）

多 conversation 按 key 浅合并 customer_profile → 注入下一轮。刻意做窄：防 token 爆炸 + 防串味。

图5 · 跨会话记忆浅合并管线
KEY
(org_id, douyin_user_id)
同一用户在同一租户下的所有历史会话。
FETCH
最近 3 会话
HISTORY_LIMIT=3，按 updated_at 倒序取，只读 customer_profile 字段。
MERGE
浅合并 · 旧→新
oldest-first 遍历，新会话覆盖旧 key；空值不覆盖。
LAYER
当前会话压顶
本轮新信息最后叠加，fresh info always wins。
INJECT
注入下轮提示词
渲染成自然语言句子（非 KV 标签）喂给 chatReply。
三条刻意的约束（deliberately narrow）：只合并 customer_profile（不回放历史原文，防 token 爆炸 + 跨上下文串味）、同 org 隔离（Staff 跨 org 切换不泄漏他租户客户笔记，null org 直接跳过而非降级为无租户读）、只读（新信息落当前会话，不回填历史行）。src/lib/memory.ts:14-22 doc + :52 org 守卫
org 隔离不是装饰：loadCustomerHistory 在 douyinUserId 或 orgId 缺失时直接返回空记忆——Staff 会话 accessible_org_ids 跨多租户时，null-org 会话宁可不带记忆也不串味。微信场景沿用同一守卫，wechat_contacts 也必须 RLS 租户隔离。

06 复用 vs 另起 + 缺口矩阵

微信工作流的用户建模 = 在已跑通的地基上加房间，不是推倒重来。

✓ 复用现有栈

  • 阶段机 + chatReply 按 stage 切提示词（只加 1 个 store_invite 态）
  • memory.ts 跨会话浅合并 + org 隔离（一行不改即可跨平台带入）
  • conversation_examples + buildExampleBlock top-3 注入
  • dm-reply 流水线（找待回 → 起草 → 护栏 → 闸门）1:1 克隆到微信通路

✗ 另起 framework / 重建建模

  • 重写一套微信专用用户建模 = 重复造已在生产跑的轮子
  • 引入第三方 agent 框架编排 = 多一层依赖、零增益（见任务①结论）
  • 把记忆 / 阶段 / 物料推倒按微信重设计 = 丢掉抖音侧验证过的资产
图6 · 缺口 / 优先级 / 补法矩阵
缺口优先级补法
① 跨平台身份贯通 wechat_contacts 微信高优 建 wechat_contacts 表 + RLS + 备注解析回填 douyin_user_id（主题4 C2）。这是微信工作流跑起来的前置闸——不通，画像就断。
② 专属物料库 中 建在阶段机下游（主题5）：用现有 stage + customer_profile 当检索键，沉淀节日话术 / 朋友圈素材 / 金牌对话。
③ 记忆字段级溯源 低 当前浅合并无字段级 provenance（哪个 key 来自哪个会话）。按需补 schema，优先级低，不卡微信上线。
④ 阶段流转确定性信号下沉 已留口 "已留微信 → decision"、"已邀约 → store_invite"等确定性信号下沉到代码（非 prompt 抖 if-else），更稳更省 token。判定接口已留。
来源：docs/planning/2026-06-28-AI大脑选型-Gus决策备忘.md 缺口段 + WBS 主题4 C2 / B1。四项里只有 ① 是微信上线的硬前置。

07 收口

地基已在生产跑，别重打。微信工作流的用户建模三要素——阶段评估、跨会话记忆、专属物料——抖音 DM 侧已落地 2.5 件并经真实流量验证。微信场景要做的是加房间：补 跨平台身份贯通（wechat_contacts + 备注回填） 这个微信特有的新环、给阶段机加一个 store_invite 到店邀约 终态、把物料库建在阶段机下游。复用并扩展 memory.ts + 阶段机 + conversation_examples，是窄增量、不是重打地基。把"选框架 / 重建建模"的精力投到 C2 身份贯通和微信通路 PoC——那才是真卡点。

08 资料来源