企业云电脑 × 企业微信 · 链路讲解

让云电脑
替人坐在企微前面

客户在企业微信里发来一句话，云端 Windows 截屏把它读出来，服务器想好怎么答，再回到那台机器上一个字一个字打出去。全程无人值守。

// 没有官方接口、没有网页 DOM —— 这条链路唯一的输入是一张截图，唯一的输出是模拟键鼠
// 数据截至 2026-07-30，均为线上直查

4 台云电脑 · 成都 ×2 / 杭州 ×2 VL 读屏 · 无 API 无 DOM FLY 东京中转 0.56–0.82s 336 会话 / 1,118 条消息 投递半程 P50 34.5s 甲方审定话术优先命中
SCROLL / 向下滚动
01
The Loop · One Message, Full Round-trip

一条消息怎么跑完一圈

三层各管一件事，互不越界：云电脑只负责「看屏幕、打字」，服务器只负责「想」，中间那一跳只负责「绕过国内连不上 Vercel 这件事」。

Layer 3 · 执行

云电脑 · 手和眼

阿里无影 Windows，挂着登录好的企业微信。截屏 → 视觉模型认字 → 鼠标点 → 逐字打字 → 再截屏确认。一台机器一个窗口，所有会话串行。

Layer 2 · 中转

Fly 东京 · 只做透传

国内云电脑直连 Vercel 不通，所以走 akke-worker-prod.fly.dev 纯转发，不持密钥、不做任何判断。实测往返 0.56–0.82s，是整条链路里最稳的一环。

Layer 1 · 大脑

Vercel + Supabase · 想和记

独立仓 wecom-chat 的 /api/wecom/chat/reply：取料、认身份、组话术、生成、清洗、落库、记成本。账本和判断全在这一层，云电脑不碰。

云电脑
发现 像素 diff ＋ 红点扫描找出哪个会话有新消息，打开、滚到底 双通道：轮询当前会话 ＋ 遍历左侧红点，防「聚焦时秒回不弹红点」漏触发
视觉模型
读消息 截屏交给 Qwen3-VL 按序列出全部气泡，再由代码取最后一条 刻意不信 VL 判「哪条最新 / 谁说的」——归属改成确定性几何规则
Fly
中转 POST 到东京，透传给大脑端点
大脑
先查话术库 甲方审定过的话术优先命中：够像就原文直发、跳过大模型；不够像就钉成硬约束 见第 04 节 · 阈值由 4,950 对真实问句量出来
大脑
生成 认身份（哪个销售号）→ 取料（品牌 / 知识 / 示例 / 规则）→ Qwen3-235B 写这一句 → 清洗 生成本身 p50 5.0s / p90 12.3s（近 10 天 9,153 次调用）
云电脑
发送前重认人 身份门：发送前重读窗口标题，确认还是这个人才打字 没有 DOM 可问时，这是防发错人的唯一防线——宁可不发
云电脑
打字发出 拟人延迟 → 点输入框 → 逐字敲 → 回车；按自然段切气泡、封顶 3 条 延迟随字数线性增长：≤40 字 19.3s / 41–90 字 25.9s / >90 字 43.6s（p50）
回执
落库 真发出去了才回调记账——没发成就不记，等客户下一句再跑一圈 confirm 三次重试 + wecom_msgid 幂等指纹，防「服务端没落库→下轮重发」

// 两段式的意义：「拿到回复」和「真的发出去」是两件事。中间隔着身份门和 GUI，任何一步没成，这条消息就不进账本，下一轮从头再来。

02
Why Screen-reading · Four Dead Ends

为什么只能靠「看屏幕」

这不是偷懒的选择。想拿到企微好友单聊的内容，能想到的四条「正经路」逐条实测都是死的——已判死，别再重探。

读控件树（UIA） 企微 PC 主界面是 Skia 自绘原生 UI，控件树恒空 ✕
挂网页调试（CDP / DOM） 只挂得上「文档」那个 webview，聊天窗口拿不到 ✕
官方接口（微信客服 kf API） 不给好友单聊代写；且回调域名撞上 ICP 备案主体校验，境外域名全被拒 ✕
官方会话存档 API 技术上最干净（确定性文本 ＋ 稳定 userid），但和「装成真人」的前提冲突，另需 ~¥1,800/号/年 ＋ 客户侧合规提示 → 已拍板不接 ✕
截屏 ＋ 视觉模型认字 ＋ 模拟键鼠 唯一走得通的路。代价是「每次判断都要重新看一遍屏幕」——这也是全部性能问题的根源 ✓
这条路的天生软肋

眼睛是视觉模型、手是盲打：只要前台不是企微窗口（有人开了记事本、弹窗、召回把窗口切到群聊），打出去的字就会错位、错人、错窗口。看起来像「脚本乱了」，实际是焦点乱了。

所以工程上做的每一件事，本质都是同一句话：把能用确定性代码判定的东西，从视觉模型手里拿回来。

03
The Fleet · 4 Cloud PCs, One Persona Each

四台机器，四个销售身份

一台机器 = 一个企微销售号 = 一个人设，不共用、不串台。四台都是 6 核 12G 企业版，2026-07-30 直查阿里云均为 Running。

小顾
成都 · XIAOGU
  • 读屏模型 VL-235B
  • 打字 unicode 逐字
  • 空闲轮询 5–12s
  • 主漏点：回声环
夏伟
成都 · XIAWEI
  • 读屏模型 VL-30B
  • 唯一开着 7 天召回
  • 空闲轮询 12–30s
  • 主漏点：身份门中止
野荞
杭州 · XIAOWEN
  • STOP 挂着，未真发
  • 脚本落后两版
  • 删 STOP 前必须先升级
  • 否则旧代码直接上生产
夏夏
杭州 · XIAOXIA
  • 读屏模型 VL-30B
  • 唯一 paste 粘贴模式
  • 通过率最高 64%
  • 限流最严 20/8/6
同一份代码，三种效率 —— 差的是配置不是版本

三台在跑的机器脚本 md5 完全一致（74BA7E7C / 178,011 字节 / v2026-07-29.recall-draft-clipboard-verified）——2026-07-25 起 loop 每 20 轮比对远端 md5，发现新版就自己干净退出、让 launcher 拉新版重启，改代码不用再手粘脚本。

但 .env 还在四个人手里各改各的：读屏模型、轮询节奏、日限、裁剪比例，九项参数没有一项一致。坐标裁剪比三台差 3 倍是正常的（客户端版本不同、必须逐台实测），模型和节奏不一致没有任何理由——这是「同代码三种效率」的直接原因，也让任何优化都无法归因。下一步要把 .env 收敛成服务端下发。

04
The Brain · Approved Replies First

先翻甲方审定过的话术，再让模型开口

2026-07-30 上线。甲方要的效果是「遇到类似问题优先用审定过的话术」，所以做成生成之前先检索命中，而不是塞进 few-shot 里赌模型照抄。

0.80 改写线
0.88 直发线
0.968 真·同题
0.862 必须挡住
0.499 中位（无关）
Verbatim · ≥0.88

原文直发，跳过大模型

还要同时满足：单段、无客户专属数字、最近没发过。更快也更省。

Constrain · ≥0.80

钉成硬约束

把审定原话抹平换行嵌进 prompt，模型只许改称呼和衔接。

None · 其余

完全走原逻辑

正常生成。开关 APPROVED_REPLY_MODE，出事先降档再关。

阈值是量出来的，不是拍的

4,950 对真实问句的相似度分布：中位 0.499（无关）、p99 0.727。真·同题能到 0.968。两条必须挡在直发之外的边界是画线的依据 —— 「把户型图发我吧」↔「发个两室一厅的户型图」= 0.862；「预算 3 万 110 平」↔「我在武汉…3 万能不能做」= 0.855（城市决定要不要报远程服务费，直发会丢掉这条上下文）。两条已写成回归用例。

Corpus · 料甲方标注台喂进来的

免登页 /annotate/<token> 让甲方逐条标「好 / 要改 + 改后文案」，结果搬进话术库打 tag。当前 100 条已标注案例、206 条话术示例在库。

Memory · 记撑得住长对话

确定性画像抽取 ＋ 滚动摘要，治「过 8 轮就只剩 5 轮记忆」。当前 76 个会话有客户画像、21 个有滚动摘要；最长一条聊到 54 条消息。

Model · 选型回滚过一次

07-15 试过推理型 kimi：初评质量更优、编店更少，但红蓝风洞暴露延迟高 ＋ 话术漂移 → 07-21 回滚。

qwen/qwen3-235b-a22b-2507
05
Guardrails · Send Like A Human

每一条都要过完这排闸

主号没有隔离，被封一次代价是真实客户资产。所以阈值写死在代码里、只允许 env 收紧，一条消息要顺次过完这些门才准发出。

工作时段 9–21 点 单号日限 单号时限 同客上限 三重去重 指纹幂等 身份门重认人 ✓ 打字发出 STOP 文件一键急停 连败 3 次自动熔断

节奏是自适应的

活跃对话 8–18s 快轮询、空闲照旧慢跑，别让客户等在那儿。拟人延迟按字数算——越长等越久，逐字敲的速度本身就是「像不像人」的一部分。

清洗有两层

一层管「像话术但不该说的话」（推微信号、免费量尺、编造前文、复读记账标记）；07-30 起补第二层管「根本不是话」——聊天模板词、日文假名、代码残渣、HTML 实体，命中就改发安全兜底句。

企微和抖音是两套口径，刻意不共用

同一个后端，企微严禁「免费量尺」（抖音相反）、一律用「您」、绝不推微信号、按真实门店就近分派。渠道隔离靠 tag 和人设，混一次就是给客户发错承诺。

06
The Bottleneck · Screen-reading Economics

贵的不是模型，是次数

2026-07-30 逐行还原三台生产机的日志（30,648 行）＋ Supabase 369 次真实往返。结论有点反直觉：97.8% 的轮次没有产出一条消息。

0
一天看屏幕的次数
（三台合计）
0
同期真发出的消息数
0.5s
投递半程 p50
（p90 67.2s · 369 次配对）
$3.7/日
读屏成本（三台合计）
九成花在零产出轮次上

空转的四张账单 —— 都在日志里明码标价，逐条可数：

「智能文档」永不消失的红点小顾 · 占其读屏调用 48% 2,243 次/日
确认「没有新消息」正确判断，但要花一次全读 967 次/日
一个没关的记事本夏伟 · .env - Notepad 被当会话 898 次/日
回声环：把自己的话读成客户消息跑完读屏＋跨境往返才被服务端挡回 330 次/日
↳ 同期真发出对照 119 条/日

同一份代码，三台的「有效轮占比」：

夏夏 · 杭州最健康 · 通过率 64% 3.5 %
小顾 · 成都每发 1 条要读屏 54.5 次 2.2 %
夏伟 · 成都每发 1 条要读屏 231 次 1.1 %
先修哪个 · 按杠杆排序

① 硬校验前台是企微窗口（并关掉生产机上的编辑器）→ 夏伟约 900 轮/日空转直接归零，分钟级就能做。② 系统会话红点本地永久黑名单 → 小顾读屏调用 −48%。③ 回声判据下沉到云电脑本地（本地缓冲实测命中 0 次，等于没生效）→ 省 330 趟跨境往返。④ 身份门失败的话术缓存下轮重投，别直接扔（夏伟生成 218 条、只发出 15 条）。⑤ .env 服务端下发，收敛成一份事实源。

换更便宜的读屏模型只省 29%，砍空转能省 90% 以上 —— 优化方向是次数，不是模型。

07
Current Status

跑到哪一步了

口径：channel='wecom_chat' 生产库直查，2026-07-30。不是估算、不是样例。

0
企微会话总数
0
消息总量
客户 668 / AI 450
0
近 7 天有消息的会话
0
已推进到 decision 阶段
（另有 4 个已转人工）

✅ 已上线跑通

  • 四台云电脑端到端无人值守真发
  • loop 自愈自升级（比 md5 自己拉新版）
  • 自适应节奏：活跃对话快轮询
  • 首触自动打招呼（新好友通过即发）
  • 7 天召回：沉默客户每天推一个话题
  • 甲方审定话术优先命中（07-30）
  • 免登标注台 /annotate（首批 100 条）
  • 50+ 轮对话记忆：画像 ＋ 滚动摘要
  • 抖音会话 ↔ 企微联系人搭桥
  • 红蓝对抗信任风洞 ＋ 确定性回归闸
  • 代码独立仓 wecom-chat ＋ 6 条 cron

🚧 进行中 / 待做

  • 砍空转四件事（第 06 节，未开工）
  • .env 服务端下发，收敛配置
  • 野荞那台：先升级再删 STOP 才能上线
  • 夏伟 watchdog 仍 Disabled（唯一无兜底的生产机）
  • 外部群聊认发言人（沿用单聊左右归属，分不清谁在说）
  • 到店指标 ＋ 漏斗日报（目前仅 3 例已承诺到店）
  • 四台到期日跨 8/21–8/27，建议拉齐并开自动续费

🧗 结构性边界

  • 读屏靠视觉模型单点，误读只能靠一致性门和可观测收敛
  • 身份靠显示名，同号同名仍会串（GUI 拿不到官方 userid）
  • 确定性根治两者都指向会话存档 API —— 已拍板不接
  • 一台机器一个窗口、全部串行，吞吐上限硬约束
  • 坐标严禁跨机套用：客户端版本变了就全失效，必须逐台重量
  • 方案 A（kf 官方 API）代码已合但冻结待 ICP 备案
一句话总括：这套系统把「企业微信」当成一个没有接口的黑盒来对付 —— 用截图当输入、用键鼠当输出，判断和账本全部收到服务器上。它已经能无人值守地接住真实客户，瓶颈不在网络也不在模型，而在「每一次判断都要重新看一遍屏幕」。下一步的全部功夫，都是把确定性的活从视觉模型手里拿回来。

数据来源　① Supabase 生产库直查 channel='wecom_chat'（会话 / 消息 / stage / 画像，2026-07-30）
　　　　　② 阿里云 ecd describe-desktops 直查四台云电脑状态（2026-07-30）
　　　　　③ 三台生产机 _loop.log 逐行还原 30,648 行 ＋ 369 次紧邻配对往返（2026-07-30 效率解剖）
已知偏差　投递半程不含「客户发出 → 被读到」那半程（库里没有这个时间戳）；成本为「读屏次数 × 实测 token × 官方单价」估算；日志窗口是尾部 1.2MB 不是完整自然日。