实测微信小微：一个“生在微信里”的AI，边界在哪里

一个深度嵌入微信生态的实测AI助手，究竟能替代用户完成多少操作？微信微信其能力的边界又由什么划定？

随着微信8.0.75版本开启原生AI助手“小微”的灰度内测，这一超级App内的小微智能体正式进入公众视野。入口位于首页左上角，个生或通过主界面右滑直接召唤。边界小微的实测核心模型为腾讯自研的WeLM，并在特定场景下调用DeepSeek作为补充。微信微信

基于该灰度版本，小微我们对小微进行了系统性实测，个生覆盖单链路执行、边界复合指令拆解、实测复杂小程序操控、微信微信社交语义理解、小微财报分析及隐私边界等关键场景。个生旨在探究当一个AI Agent被嵌入拥有14亿月活的边界超级App时，其能力的天花板究竟在哪里——厘清哪些“不能”是技术瓶颈，哪些是产品主动选择。

当输入第一条指令“你是谁？”时，小微对自身的定义清晰而克制：“腾讯微信团队的小微，生在微信里。”

小微的能力圈：从“填参数”到“做选择”

“生在微信里”不仅是一句口号，更意味着小微天然接入了微信的聊天、小程序及支付体系，但其触角也仅止于此。抛开理论推演，实测数据揭示了其真实效能。

1. 单链路执行：点咖啡的“最后一公里”

“帮我点一杯瑞幸的生椰拿铁，去冰，埃塞金烘，不加糖。”这是典型的单链路场景。小微识别意图后，自动调起瑞幸小程序，精准选择参数，直至订单确认页。

关键限制：小微不会代为支付。

尽管流程看似成熟，但“一句话点咖啡”尚未完全实现。多次测试发现，小微常卡在配送方式选择或加购弹窗确认环节，需用户至少手动介入一次。这表明：小微擅长“填参数”，但在“做选择”时倾向于退回给用户。

这种“停在付款前”的设计并非孤例，阿里千问App在类似场景中也止步于支付前。然而，两者背后的技术路径截然不同：

• 千问（API接口方案）：基于阿里系闭环，直接调用淘宝闪购和支付宝系统级接口，以卡片形式完成推荐，流程顺滑且可叠加优惠。
• 小微（小程序参数协议）：面对微信生态内数百万第三方小程序，逐一深度适配的工程量和协调成本极高。因此，小微能填参数，但面对复杂UI控件时需用户介入，且无平台级补贴机制。

2. 群聊总结：API通道下的数据透视

在信息过载的微信群中，小微可被唤起以压缩对话。在科技/创投资讯群实测中，小微能按日期梳理脉络，提取人名、金额及动态，并判断群聊风格。

稳定性与底层逻辑：
* 成功率波动：同一指令执行结果不稳定。
* 技术揭秘：失败时，小微回复“接口暂时出了点小状况”，并暴露底层接口名list_message_edge。这证实小微通过微信内部API通道获取数据，而非视觉模拟识别。它“看得见”内容，但数据源是结构化的API，而非屏幕像素。

3. 生成小工具：从“人人是产品经理”到现实落差

指令“帮我做一个记账的小工具”，小微可生成包含收支汇总、分类标签的完整小程序雏形。

局限：
* 耗时较长：生成约需2分半钟。
* 不可迭代：不支持对已生成工具追加修改。
* 封闭性：目前仅支持个人使用，无法分享。

4. 代发消息与朋友圈：克制的社交观察

• 代发消息：小微能精准定位联系人/群并生成内容，但发送需用户手动点击。它负责“最后一厘米”的准备，而非执行。
• 朋友圈总结：能将好友动态按生活、工作、旅行分类，并打上情绪标签，附带跳转链接。
• 视野限制：仅覆盖最近2天动态，无法回溯更早内容。

小结：目前小微胜任的任务多为“单线程、单任务、止步于最后一步”。一旦指令复杂化，局面即开始失控。

复合指令的断裂点：状态管理的缺失

当多任务打包为一条指令时，小微的表现出现显著衰减。

测试指令：“点一杯瑞幸生椰拿铁去冰 + 找附近4.5分以上火锅店 + 给光头强发委婉的加班拒绝消息。”

执行结果分析：

1. 任务一（点咖啡）：表现稳定，正常调起小程序并停在付款前。
2. 任务二（搜火锅）：上下文污染。因前序任务涉及“咖啡”，检索结果仍为咖啡相关小程序，导致失败。建议用户手动打开大众点评。
3. 任务三（发消息）：状态隔离失效。生成的消息内容错误地引用了上一轮测试的遗留内容（“可以出发了”），而非本次指令的“不想加班”。

对比：单独执行时，小微能生成高质量的委婉拒绝语（如“今天可能不太想加班，你看咱们能不能稍微灵活一点？”）。

结论：三个子任务质量呈梯度下降。这并非Token窗口限制，而是任务编排层的状态管理缺陷：
* 上下文污染干扰检索目标。
* 缓存覆盖导致消息草稿错误。
* 关键参数（如“附近”）透传断链。

核心短板：小微缺乏可靠的状态管理框架，导致“做着做着就乱了”。

链路深处的边界：程序化交互的代价

将任务限定为单件，但拉长操作链路，自动完成度呈现清晰衰减曲线。

1. 短链路：打车（最顺畅）

指令：“叫车去北京南站出发大厅。”
* 结果：调起滴滴小程序，填好目的地，停在付款前。接近“一句话搞定”预期。

2. 中链路：订酒店（出现偏差）

指令：“订杭州西湖附近明天入住的5星级酒店，价格500以下。”
* 结果：卡在授权页；价格筛选反向（点击“¥400以上”而非“500以下”）。
* 自我纠正：小微发现错误后尝试重置，但最终未能完成筛选，转交用户手动操作。
* 轨迹：错误 → 自纠正 → 再试 → 放弃。

(注：原图链接修正，保持结构)

3. 长链路：买高铁票（复杂UI受阻）

指令：“买明天北京到上海高铁票，上午出发，靠窗座位。”
* 结果：基础参数（出发地、目的地、日期、车型）填写准确。
* 瓶颈：卡在选座和乘客信息填写。此类复杂UI控件涉及多步跳转和表单交互，超出当前自动化边界。

技术路线差异：
* 微信方案（程序化交互）：通过小程序内部接口定位控件。优势是安全、不越权；劣势是依赖控件开放接口，复合UI控件（筛选面板、选择器）极少开放此类入口。
* 竞品方案（视觉模拟）：如豆包、智谱AutoGLM，通过识别屏幕像素模拟点击。

策略选择：微信选择“简单页面优先适配，复杂页面暂放”。这是“浅层桥接”定位下的必然选择，深度集成仍需时间。

失败时的两副面孔：产品红线与工程兜底

小微在面对失败时，展现出两种截然不同的话语体系。

1. 主动拒绝：产品设计的红线

当要求“每天8点定时发早安”或“读取特定群记录”时，小微明确拒绝。
* 结构：清晰区分“产品无此能力”与“AI无此权限”。
* 替代方案：提供快捷指令或闹钟建议。
* 情感连接：末尾追问动机，使用温和语气和Emoji。

2. 尝试后失败：工程实现的兜底

当群聊总结失败、搜索无果或回溯查询失败时，小微采用模糊化话术。
* 话术：“接口暂时出了点小状况”、“检索到的都是咖啡相关”、“系统暂时不支持”。
* 逻辑：将原因归咎于外部接口或系统，而非承认自身能力不足。

本质：“主动拒绝”是预设的产品边界；“尝试后失败”是工程能力的暂时局限。

结语：14亿用户场景下的“60分”哲学

综合实测，小微可定义为“有条件的60分助手”。

• 短板：任务编排能力滞后于意图理解能力。多任务或长链路下，完成度显著滑坡。
• 长板：底层模型能力过硬。财报分析零幻觉，群聊总结高效，WeLM与DeepSeek路由切换流畅。

“60分”的价值：
在14亿用户的规模下，任何微小的自动化增量都能带来巨大的效率提升。
* 群聊总结虽不稳定，但能节省大量时间。
* 点咖啡、叫车等短链路已满足日常高频需求。

微信需要的并非一个完美的AI管家，而是一个不出错、可预期、边际成本极低的AI中间层。不苛求完美，而是追求稳定与可控，这可能是微信现阶段的最优策略。

本次测试基于微信8.0.75灰度内测版。所有指令均在真实环境下执行，单场景重复测试2次，复合及长链路场景重复3次，以排除偶发误差。

（本文首发钛媒体APP，文 | 散落拾获，作者 | 贾雨微）

(责任编辑：百科)