识聊AI在微信自动化：通用VLM很好，但我们为什么还要自研视觉模型？
一、先讲背景：微信自动化的核心卡点，从来都不是“能不能回”，而是“能不能快”
做微信AI自动化的同行应该都有体感：这件事的门槛从来不是“让AI看懂消息然后回复”——现在随便一个大模型都能把消息理解和回复做得很漂亮。
真正的死穴，是前端的视觉感知环节。
微信这个场景很特殊：它没有开放的消息推送API，所有自动化都得走“视觉识别+模拟操作”的路线。你得先看见哪里有未读、点进聊天窗口、提取消息内容、判断是文字还是图片语音，最后才能交给大模型去想怎么回。
这一整套视觉流程，放在两年前基本靠OpenCV模板匹配+传统OCR硬扛，准确率惨不忍睹，微信一改版就全崩。
直到去年开始，通用视觉大模型（VLM）爆发，千问、豆包、DeepSeek、腾讯混元都陆续放出了很强的识图能力，我们第一时间就把这套方案用上了。
二、MVP阶段：站在国产大模型的肩膀上，我们用一个月跑通了全链路
2.1 为什么第一版果断用通用VLM？两个字：效率
做产品MVP，核心是快速验证可行性。当时我们的判断很明确：
- 国产大模型的视觉能力已经足够用：千问VL对UI元素的理解精度很高，豆包的中文场景识别很准，DeepSeek的视觉token消耗很低、性价比极高；
- 从零训一个模型成本高、周期长，先用现成方案跑通业务逻辑才是第一位；
- 文本侧的智能回复、知识库检索、Agent任务规划，本身就重度依赖这些大模型的能力，视觉也用同一路技术栈，对接成本极低。
2.2 第一版架构：全链路通用大模型方案长什么样？
我们当时的完整流程是这样的：
- 看懂屏幕→ 调用视觉大模型检测微信会话的未读
- 定位到具体聊天→ 知道是需要跟谁回复消息
- 消息内容提取→ 区分消息类型（文字/图片/语音/文件）并提取内容
- 语义理解与回复生成→ 把提取的文本发给大模型，生成回复话术
- 发送校验→ 确认回复
简单说就是：每一步操作前，都调用一次通用视觉大模型“看一眼”屏幕，确认状态再执行下一步。
这套方案最大的优点就是快——我们一个月就把完整的“未读→消息→AI回复”全链路跑通了。而且因为用的都是成熟的国产大模型，基础识别准确率非常能打，常规文字消息的提取准确率能到95%以上。
毫不夸张地说，没有国产大模型这几年的飞速进步，我们的MVP至少要晚半年才能出来。
三、踩坑：30秒延迟的魔咒，通用VLM的性能天花板
跑通是跑通了，但上线后客户反馈给我们浇了一盆冷水：太慢了。
3.1 拆解一下：回复一条消息，30秒到底花在哪了？
我们做了详细的延迟埋点，平均一次完整的消息回复，耗时在28-32秒之间。拆解下来，核心问题很明显：一次完整的自动化交互，要调用3-4次视觉大模型，每次都是“截图→上传→推理→返回”的完整链路。通用VLM再快，也架不住这么多次串行调用。
3.2 比慢更致命的，是业务场景的天花板
30秒是什么概念？
- 客服场景：用户发消息半分钟才收到回复，体验已经很差了；
- 销售线索场景：客户咨询的黄金响应时间是5秒内，30秒过去，客户可能已经找了别家；
- 群聊运营场景：消息刷屏的时候，等你识别完上一条，下面已经刷了十几条。
更麻烦的是，这套方案高度依赖外部API。一旦遇到网络波动、服务限流，整个自动化就直接卡住。那段时间我们的客户满意度一直上不去，很多对时效性有要求的场景，我们根本不敢接。
不是通用大模型做得不好，而是它面向的是通用场景。它要能识别万物、看懂各种图片视频，能力很全，但也意味着它不可能针对“微信界面”这个单一垂直场景做极致优化。就像你开一辆全地形越野车去跑城市赛道，能跑，但永远跑不过专门的赛车。
四、抉择：为什么一定要自研？我们到底自研了什么？
当时团队内部有很大争论：有人说继续优化调用策略，比如批量截图、并行调用；有人说直接换更快的模型。但最后我们拍板：针对微信UI场景，做自己的轻量化视觉模型。
4.1 先划清边界：自研不是全栈重做，该用大模型的地方还用
这里必须先说明白：我们不是要从零做一个通用大模型，也不是要替代千问、豆包、DeepSeek。恰恰相反，我们的自研只聚焦在“微信界面元素检测”这一个极小的领域。
具体分工是这样的：
- ✅自研负责：微信消息的快速分类
- ✅国产大模型负责：消息内容深度理解、回复生成、知识库问答、智能体任务规划、复杂图片内容解析
说白了就是：粗活累活（定位、检测、分类）我们自己做，重脑力活（理解、推理、生成）依然交给专业的大模型。
4.2 我们的技术路线：小模型+知识蒸馏+场景微调
我们没有盲目堆参数，而是走了“小而精”的路线：
- 基座选择：选用轻量级的检测模型作为基座，参数量比通用VLM少N个数量级；
- 知识蒸馏：用大模型的“知识”去教小模型；
- 场景微调：针对不同版本的微信PC端、移动端界面做专项微调，覆盖深色模式、浅色模式、不同缩放比例；
- 端侧部署：模型直接跑在用户本地，不需要上传截图到云端，既快又安全。
五、效果与总结：技术取舍的本质，是找到最适合业务的平衡点
5.1 自研之后，带来了哪些变化？
最直观的就是速度：单轮消息响应从平均30秒，降到了10秒以内。而这部分的体验，反而还在持续受益于国产大模型的不断升级。
更重要的是，我们终于能切入那些对实时性要求高的业务场景了：客服秒回、线索实时响应、群聊消息实时监控，这些之前想都不敢想的场景，现在都能做。
5.2 最后聊聊我们的技术观：生态共赢，而非重复造轮子
经常有人问：现在大模型这么强，你们还要自研，是不是重复造轮子？
我们的答案一直很明确：不，我们是在给轮子做适配。
通用大模型是这个时代的水电煤，是基础设施。千问、豆包、DeepSeek、腾讯混元这些国产模型的快速发展，是所有AI应用开发者的福气。我们绝大多数的智能能力，都建立在这些基础设施之上。
但基础设施解决的是“有没有”的问题，而具体到每一个垂直业务场景，“好不好用”、“够不够快”、“成本能不能接受”，这些都需要应用层的团队去做针对性优化。
自研视觉模型，不是否定通用大模型的价值，恰恰是为了让大模型的能力能更好地落地到微信自动化这个具体场景里。把前端感知的速度和准确率提上来，后面大模型的聪明才智才能真正发挥价值。
技术选型从来没有标准答案，不是越新越好，也不是越全越好。找到适合自己业务场景的平衡点，知道什么该自己做、什么该站在巨人肩膀上，这才是最重要的。道阻且长，这是识聊AI团队的经验之谈，也希望帮到其他的AI创业者
