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

装修场景的微信工作流选型

装修获客闭环里，抖音侧已跑通「评论→意向打分→小艳起草→人审→发送」。下一段是「加微信后」——把同一套大脑搬进微信，做场景a 半自动关系维系和场景b 全自动聊到到店。这页只回答一个工程问题：这套微信工作流是自建还是买第三方 SCRM，以及自建的话走哪条通道。

结论
自建（复用 chatReply 大脑 + 克隆 DM 管线 + 选一个微信通道 substrate），不买第三方 SCRM。真正待拍板的只剩通道 substrate 三选一——企微 kf API（待 ICP 备案）／ 企微 PC UI ／ WDA iPhone。
自建
build vs buy 决策：大脑已是护城河，框架/SCRM 都不引入
100%
大脑层复用率：chatReply 人设/知识库/few-shot/画像全现成，缺的只是微信管道
3 选 1
唯一待拍：通道 substrate（kf API / 企微PC / WDA）
copilot
第三方 SCRM 的 AI = 销售助手，非客户侧代答，做不了我们要的事

§1这页拍什么

承接①框架横评的结论，落到装修微信场景的 build-vs-buy + 通道选型

①号页《框架横评》已经定调：编排层不引入 LangGraph/Dify 这类框架，Akke 自研的 cron + 状态机 + 护栏闸门已经够用。这页是它的下一跳——把同一个判断方法用到「微信场景」上，回答两个递进问题：

  1. Build vs Buy：微信里的「小艳自动回复业主」，是自己造，还是买现成的企微 SCRM（卫瓴/微伴/句子互动）？
  2. 若自建，走哪条微信通道：大脑不变，但「消息怎么进、回复怎么出」这层 substrate 有三条候选路，得选一条先上。
刹车点：别把这页读成「该选哪个 AI 框架」。装修微信工作流的大脑（chatReply）早已存在且在线上跑，这页不评估大脑，只评估「自己接管道 vs 买打包方案」，以及自建时的通道地基。

§2Build vs Buy：为什么是自建

两条轴一摆，象限就唯一了

把决策拆成两个二元判断：大脑是不是我们的护城河？（是 → 不能外包给 SCRM）通道是不是现成可买？（部分是 → 但买的是错的东西）。落到 2×2：

图1 · Build vs Buy 决策矩阵
通道
买不到 / 不合身
通道
有现成方案
大脑是
护城河
★ 我们在这里
大脑=chatReply 已是护城河；可买的通道是 copilot 不是代答 → 自建大脑 + 自接通道
买 SCRM 的 AI
把核心能力外包给黑盒，等于交出护城河；且它根本不替客户代答
大脑非
护城河
纯自建（没必要）
若大脑不重要，自建只是重复造轮子
直接买打包 SaaS
通用客服场景才适用，与装修高客单深聊不匹配
两轴判断都指向左上格：大脑必须自有（护城河），通道虽有现成 SCRM 但它做的是「销售 copilot」而非「客户侧 AI 代答」，买来也用不上。src/lib/llm.ts chatReply

✓ 自建（复用 chatReply）

  • 大脑已是护城河：小艳人设 + 装修知识库 + few-shot + 蒸馏决策规则 + 跨会话客户画像，全部已上线、抖音侧验证过 src/lib/llm.ts
  • 客户侧 AI 代答第三方做不到：SCRM 的 AI 是给销售看的 copilot，不替客户应答
  • 数据自主：家装高客单客户的对话/画像留在自己的 Supabase，RLS 多租户隔离，不外流
  • 管道已写好大半：企微 kf 全链路代码已上线，DM 管线四 RPC 现成可克隆

✗ 买第三方 SCRM（卫瓴/微伴…）

  • AI=销售 copilot 非客户代答：实测综述一致——AI 智能回复是「同步话术/完善标签/提醒跟进」，辅助人，不无人值守替客户答 36氪企服点评微伴官网
  • 合同制黑盒：企业合同、价格不公开（卫瓴 20 席起售），能力边界与封号责任不透明
  • 家装客户数据外流：高客单线索 + 聊天记录进第三方平台，合规与资产风险
  • 大脑被锁死：换不进我们的 chatReply 人设与报价逻辑
定性证据强度：「SCRM 的 AI = copilot 非代答」目前是 B 级（多点小样本）——卫瓴/微伴两家公开材料一致，但句子互动/智齿/瓴羊未逐一验证，勿当铁律外推到全行业。deep-research wf_747e36ab-9cf

§3自建怎么落：克隆 DM 管线到微信

这是「移植」不是「新造」——抖音侧每个零件都有对应件

「自建」听着重，其实地基已经铺好。抖音侧的 DM 自动回复管线（src/lib/dm-reply/，含 gate.test.ts 回归）是现成的状态机；微信侧落地 = 把它逐件克隆、换掉收发端口。四个 RPC 都在 migrations/20260618173500_dm_reply_drafts.sql 里现成存在：

图2 · DM 管线 → 微信管线 1:1 克隆
INBOUND
record_dm_inbound
→ 微信入站
记录客户来消息
SELECT
dm_conversations_
awaiting_reply
→ 微信待回会话
挑出该答的
BRAIN
chatReply
阶段感知 +
新增 store_invite
GATE
gate.ts + adjust.ts
护栏闸门 + 改写
原样移植
CLAIM
claim_dm_replies
→ 微信 claim
锁定待发草稿
SEND
poll agent 微信支线
wuying_poll_agent.py
加微信通道
DONE
complete_dm_reply
→ 微信完成
回写状态
每个零件都有抖音侧原件，迁移点已在 WBS 主题4「接驳」段逐条列明：dm_reply_drafts 四RPC → wechat_reply_drafts · gate/adjust 移植 · chatReply 阶段 + store_invite · memory.ts 画像带入 · poll agent 微信支线。src/lib/dm-reply/{gate,adjust,run}.ts wuying_poll_agent.py
大脑：零改动复用
chatReply 已有 ice_break / nurture / decision 三阶段系统提示，只需加一个 store_invite（到店邀约）阶段 src/lib/llm.ts
画像：跨平台续接
memory.ts 按 (org_id, user_id) 浅合并客户画像；微信侧靠备注解析回填 douyin_user_id 即可把抖音对话续上
护栏：已有测试兜底
gate.ts 拦「机器崩的草稿」，gate.test.ts 是现成回归；移植即得防护

§4通道 substrate 三选一（真正待拍的）

大脑和管线都不纠结；唯一的开放决策是「消息从哪个口子进出」

自建确定后，剩下的不确定性全压在通道 substrate 上——同一套大脑可以挂在三个不同的微信端口上，三条路各有合规/横扩/成熟度的取舍：

图3 · 三条微信通道 substrate 对比
substrate合规可横扩现状卡点
A 企微 kf 官方 API
src/lib/wecom/		 最合规 官方唯一支持 AI 代答外部客户 服务端 无机器数量上限 全链路代码已上线 PR #268；回调 + 加解密 + 固定出口 IP 209.71.88.154 就绪 ICP 备案 回调域名要企业备案主体匹配，vercel.app/fly.dev 全被拒
B 企微 PC Windows UI
probe_wecom_ui.py		 较合规 官方客户端，非协议破解 多机 一机多会话，可堆但偏重 可行性探针就绪 PR #277/#278，待 Windows 实机跑 待探针 需装企微的 Windows 机；读消息路线（无障碍树/OCR/存档API）未定
C WDA iPhone 个微 UI
wechat_reply_wda.py		 灰色 个微自动化违协议、封号风险 单机 一机一号，不可横扩 PoC PASS 已跑通：WDA 读未读 → 桥接 chatReply（nurture）→ 发回 不可扩 一台 iPhone 一个号；号失=好友+记录+朋友圈全丢
三行都已落地到代码/探针/PoC，不是纸面方案。WDA 的 PoC 通过 scripts/wechat-reply-gen.ts 桥接进 chatReply（stage=nurture）已实证。worker/wechat_reply_wda.py
推荐排序： A（kf API） > B（企微 PC） > C（WDA）。A 最合规且能横扩、代码已就绪，唯一拦路是 ICP 备案——一旦域名通过，代码零改动复活，应是主攻方向。B 作为「不依赖备案」的合规备胎并行推进。C 仅作个微场景（朋友圈点赞等企微做不到的动作）的试水通道，用非主力小号 2–4 周测封号率，不上主号。

§5场景 a / b 落地差异

同一套管线，闸门松紧不同 → 先上低风险的半自动

场景 a · 半自动关系维系
运营一点即发：维系触发器 + 进度节点起草，复用 needs_human 人审闸门。机器只起草、人按发送键 → 风险最低，建议先上。物料由主题5 话术库供血。
场景 b · 全自动聊到到店
无人值守冷启→到店：靠 gateWechatDraft 护栏 + 越权承诺兜底。先跑「自己加自己 + 公海号源」自测闭环验证范式可迁移，再放真客户。
护栏拦得住崩、拦不住「越权」：闸门能挡掉机器抖出的乱码草稿，但挡不住「合理但越权的承诺」（错误报价 / 承诺工期 / 虚假优惠）。哪些话术必须人工过（首次报价 / 合同条款）需 PM 定红线——这是场景b 上线前的合规前置，非工程问题。

§6决策 + 把精力投哪

大脑别再纠结，精力全压在三个真瓶颈上

一句话决策：装修微信工作流 = 自建，复用 chatReply 大脑 + 克隆 DM 管线，不买第三方 SCRM、不引入编排框架。大脑层已结题，别再开会评估「用哪套」。

真正决定能不能上线的，是下面三件——精力应当全投这里，而非框架选型：

① 攻 ICP 备案
解锁 kf API（最优通道）的唯一拦路石。子域 CNAME / 个人备案变更 / 新域名企业备案三选一，已建 Lark task 56623faa 跟进。
② substrate 拍板
在 ICP 落地前，并行推进 企微 PC（B） 探针实机验证，或 WDA（C） 小号试水，给 kf 留备胎，不空等备案。
③ 报价数据源
场景话术的原料（主题3）。无人值守聊到到店要敢报价，没有可信的品类×城市×面积基准价，全自动话术就是空壳。

§资料来源

WBS 2026-06-26-五大战略-WBS拆解.md memory project_akke_wecom_kf_integration.md src/lib/dm-reply/ + gate.test.ts src/lib/wecom/ + crypto/process.test.ts api/wecom/kf/callback/route.ts migrations/20260618173500_dm_reply_drafts.sql worker/wechat_reply_wda.py worker/scripts/wecom-chat/probe_wecom_ui.py deep-research wf_747e36ab-9cf 36氪企服点评·卫瓴 2026 微伴助手官网 weibanzhushou.com 2026

仓库论断均经 grep/Read 命中验证（dm-reply 四 RPC、wecom 全链路代码、WDA PoC 桥接 chatReply、ICP 备案硬阻塞）。第三方 SCRM「AI=copilot 非代答」为 B 级多点小样本综述，未全行业外推。