Akke · 微信触达自动化 · 决策评估（第二轮）

朋友圈点赞 + 聊天对话自动化
个人微信 vs 企业微信 · 最佳双路线

把「朋友圈点赞」和「AI 聊天代回」两个动作，放进个人微信 / 企业微信两个平台里逐格评估，给出两条互斥的最佳路线、卡点、风险，以及条件式结论。2026-06-26

一句话结论：「朋友圈点赞」把平台选型直接锁死——只有个人微信能做（企微看不到客户的个人朋友圈，是产品边界、非工程量）。而且点赞和聊天必须在同一个号上，无法拆成「企微聊天 + 另一个个人小号点赞」。所以真正的取舍只有两条路：① 个人微信一体化（拿全功能，赌封号） vs ② 企微统一（弃点赞，求稳与可继承）。

0第二轮评估：修正上一版的逻辑漏洞

上一版的「混合方案」不成立。之前提过「聊天走企微、朋友圈点赞用一个独立个人小号」——但那个小号不是客户的微信好友，照样看不到、点不了客户的朋友圈。要给某客户朋友圈点赞，点赞的号必须是该客户的好友；而客户只会加一个号（个人 or 企微），不会为了被点赞再加第二个。

结论修正：朋友圈点赞 ⇒ 客户必须加个人微信 ⇒ 聊天也落在同一个个人号。点赞与聊天不可分离。因此本轮只评估两条平台级互斥路线，不再有中间的「双号混合」。

1四格能力底牌（平台 × 操作）

	个人微信	企业微信
朋友圈点赞	✅ 唯一可行官方无 API，靠 GUI 自动化（打开客户资料→朋友圈→点赞）。微信风控重点行为	❌ 能力不存在企微看不到客户个人朋友圈；官方「客户朋友圈」只能企业→客户单向发，无法点赞客户的
聊天 AI 代回	⚠️ 可做（全灰）无官方 API，GUI 自动化 / 协议逆向（wechaty 灰产 token）	✅ 半官方 kf API 代回外部客户（方案 A，官方支持，被备案卡）；好友单聊→GUI（方案 B，进行中）

↑ 左下角是唯一同时点亮两个操作的格子组合。右上角是永久死格——企微再怎么推进都给不了朋友圈点赞。

2两条最佳路线

路线一 · 拿全功能

🟣 个人微信一体化

能力

朋友圈点赞 ✅ 聊天 ✅
一个个人号、同一好友关系上点赞+聊天闭环。客户加微入口 = 这个个人号。

架构（复用方案 B 的 loop + chatReply 大脑）

个人微信客户端常驻 loop（手机 ADB / PC）
 ├ 聊天支线
 │   读新消息 → 去重 → 拉 Supabase 历史
 │   → chatReply(小艳人设，零改动)
 │   → 拟人延迟 5-20s → GUI 打字回车
 │   → 落库 channel='wechat_personal'
 └ 朋友圈支线（低频·与聊天错峰）
     遍历目标客户 → 资料页→朋友圈
     → 点赞最新一条 → 去重落库 → 限流

技术选型

手机 ADB + uiautomator2（推荐）：复用抖音图文/DM 自动化家族，不引入黑产依赖
PC 客户端 hook（wxhelper 类 DLL）：更稳但黑产味重、版本脆，不做 V1
iPad/Mac 协议（padlocal）：付费灰产 token、封号高发，不推荐

卡点

点赞+聊天均无官方 API，全 GUI
无稳定 userid，靠显示名+会话位置定位，重名串台
微信改版会让读/点适配器失效，需探针验底

风险登记

封号（最高档）：点赞+自动回组合 = 营销号典型特征，微信风控比抖音/企微都狠

后果不可控：号失 = 好友+聊天记录+朋友圈全失，个人资产不可继承

客户串台（重名/无 userid 回错人、点错朋友圈）

客户端改版导致 GUI 失效

合规：自动化个人号违反微信 ToS

路线二 · 求稳可继承

🔵 企业微信统一

能力

朋友圈点赞 ❌ 聊天 ✅
放弃点赞（产品边界做不到），聊天合规且客户资产沉淀在企业。

架构（现成，大半已上线）

聊天-方案A（kf API，官方代回外部客户）
  回调 /api/wecom/kf/callback
   → process.ts → chatReply
   → wecom-proxy 固定出口 → kf/send_msg
  状态：代码全上线，停机冻结(待备案域名)

聊天-方案B（好友单聊 GUI，进行中）
  Windows 企微客户端 UIAutomation
  状态：卡可行性探针

技术选型

kf API：官方唯一支持「AI 代回外部客户」，最合规
方案 B GUI：好友单聊官方不可代写时的兜底

卡点

朋友圈点赞做不到，无中间态
方案 A：ICP 备案主体校验卡死（境外域名/裸 IP 全拒）+ 客户需多点一次客服链接
方案 B：好友单聊只能 GUI；企业认证主体下违规反而更显眼

风险登记

朋友圈点赞能力缺失（最大短板，无解）

方案 A 复活依赖公司拿备案域名（5 天~3 周，不可控）

封号后果可控：客户资产沉淀企业、员工离职可继承

合规相对最好（kf 官方支持）

3加权评分（满分 10）

维度	权重	个人微信一体化	企微统一
朋友圈点赞能力	★★★	10	0
聊天 AI 代回	★★★	8	9
合规度	★★	2	8
封号安全度（高=不易封）	★★	2	6
后果可控/资产可继承	★★	2	9
落地速度（现有进度）	★	4	7
运营复杂度（高=简单）	★	6	7
若「朋友圈点赞」是硬需求（点赞权重×3）		胜	—
若「朋友圈点赞」可砍		—	胜

评分的唯一摆动项就是「朋友圈点赞」：把它当硬需求，路线一靠 10:0 的独占能力反超全部短板；把它当可选，路线二在合规、安全、可继承、落地速度上全面占优。

4条件式结论 + 推荐落地

判断只看一件事：朋友圈点赞值不值得拿主力客户关系赌微信风控？

✅ 推荐（综合风险最优）：路线一，但用「小号试水」分阶段控爆炸半径，不一上来就押主力号。

朋友圈点赞是增量动作，不放弃；但不拿主力客户关系直接赌。
先用非主力个人号跑 2~4 周，实测封号率 + 点赞被风控拦截率，跑稳再扩。
企微方案 B（合规、可继承）保留为聊天备胎，备案域名到了随时复活方案 A。

分阶段 Roadmap

P0 · 可行性探针（个人微信，只读不点不发）
装好客户端+登录小号，验三件：① 能否稳定定位某客户资料页→朋友圈；② 能否读单聊新消息+发送方；③ 能否抠到稳定身份键。出 PASS/FAIL 再定读法。

P1 · 朋友圈点赞支线（小号）
ADB 自动化：目标客户→朋友圈→点赞最新；落库去重表 + 每日上限/错峰/工作时间门风控。先只点赞、不聊天，单独观测封号信号。

P2 · 聊天支线并入（小号）
复用方案 B loop + chatReply，channel=wechat_personal；与点赞错峰、共用风控。观测「点赞+聊天」组合下的封号率。

P3 · 扩量决策
小号稳活 2~4 周 → 评估是否把客户加微入口正式切到个人号、多号分散风险；不稳 → 退回企微聊天、朋友圈点赞作罢。

5卡点总表

卡点	属于	性质	破解
企微看不到客户朋友圈	路线二	产品边界·无解	要点赞只能换个人微信
个人号封号（点赞+自动回）	路线一	不可消除	小号试水+风控降概率，多号分散
点赞/聊天无官方 API	路线一	工程	GUI 自动化（ADB），探针验底
无稳定 userid·客户串台	路线一	设计	显示名+会话位置；探针若读到 id 优先用
ICP 备案主体校验	路线二·方案A	外部依赖	公司备案域名子域 CNAME（不可控周期）
kf 需客户多点一次链接	路线二·方案A	体验	桥接卡片引导，或走方案 B

来源：本仓 docs/claude-memory/project_akke_wecom_kf_integration.md · docs/superpowers/specs/2026-06-11-wecom-chat-ai-1on1-design.md · src/lib/wecom/* · wecom-proxy/main.py。第二轮评估修正：删除不成立的「双号混合」方案，收敛为平台级互斥两条路线。

本页为决策评估稿，未发布到 upio.ai。