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

一个扎根在微信里的AI助手，究竟能做多少事？它的能力边界划在哪？

微信8.0.75版本的灰度内测中，原生AI助手“小微”悄悄上线了。入口藏在首页左上角，也可以在主界面右滑直接召唤。小微的主模型是腾讯自研的WeLM，部分场景则调用了DeepSeek。

借着这个灰度版本，我们对小微进行了一次系统性的实测。测试覆盖了单链路执行、复合指令拆解、复杂小程序操控、社交语义理解、财报分析、隐私边界等多个场景。说到底，就是想摸清楚：一个AI Agent被嵌入到一款拥有14亿月活的超级App后，它的能力天花板到底在哪里。哪些“不能”是技术限制，哪些又是主动的选择。

向小微发送的第一条消息，是“你是谁？”它对自身身份的概括很简短：“腾讯微信团队的小微，生在微信里。”

小微能做什么？

“生在微信里”，这句话已经点明了小微的根基——它天然接入了微信的聊天、小程序、支付体系。同时，它的能力范围也被限定在这个圈子里。不绕弯子，直接看实测结果。

点咖啡是个典型且简单的场景。对小微说：“帮我点一杯瑞幸的生椰拿铁，去冰，埃塞金烘，不加糖。”它能识别意图，调起瑞幸小程序，正确选好参数，稳稳停在订单确认页——付款前最后一步。注意，它不会替你付钱。

这个场景已经比较成熟，但过程并不完美。多次重复测试后我们发现，小微还做不到真正“一句话点咖啡”：有时卡在配送方式的选择上，有时又在加购弹窗的确认环节需要用户手动介入。它擅长的是“填参数”，一旦遇到“做选择”的环节，就会被退回交给用户。

这个“停在付款前”的设计并非小微独有。阿里旗下的千问App在点咖啡时同样止步于支付前。但两条路径背后是不同的技术路线：千问走的是API接口方案，直接调用淘宝闪购和支付宝的系统级接口，流程更顺滑，还能叠加平台优惠；小微走的是小程序参数协议，能填参数，但面对复杂UI控件时就需要用户手动介入，也没有平台级补贴。差异的根源在于生态结构——千问的能力基于阿里系闭环，接口打通是内部工程；小微面对的则是微信生态内数百万第三方小程序，逐一深度适配的工程量级完全不同。

群聊总结是另一个高频场景。微信群消息多了容易刷屏，小微可以在聊天框内被唤起，把最近的对话压缩成几句话。在一个偏科技/创投资讯群内实测，小微能按日期梳理话题脉络，提取具体人名、金额数据和产品动态，还能给出群聊整体风格的判断。

不过，这个功能的成功率并不稳定，同一指令有时成功有时失败。多次尝试后还发现，失败时小微会回复“接口暂时出了点小状况”，随后在对话中暴露了底层接口名称list_message_edge——这其实是个普通用户平时看不到的微信消息系统内部API字面量。这个细节也说明，小微获取群聊数据走的是微信内部API通道，而不是通过屏幕识别再理解。换句话说，它能“看见”消息内容，但数据通道是API，而非视觉模拟。

生成小工具是不少报道中“人人是产品经理”的卖点。实测中，简单说一句“帮我做一个记账的小工具”，它就能生成一个界面完整的记账小程序雏形，包含收支汇总、分类标签和新增入口。不过，生成耗时要两分半钟左右，有点偏慢；而且不支持对已生成工具追加修改。更关键的是，目前生成的小工具只能自己用，不能分享给别人。

代发消息体现了微信一向的克制。小微能找到正确的群或联系人，生成准确的消息内容，但最终发送需要用户手动点击绿色“发送”按钮。和点咖啡时停在付款前一样，它把一切准备到最后一厘米，然后停下来。

朋友圈总结也值得单独说说。让小微“看看朋友圈最近有什么新鲜事”，它会按生活日常、工作分享、旅行打卡等类别，把好友发布的内容分门别类整理出来。小微不仅能叫出每个人的名字，还给每条动态配上情绪标签，摘要旁边附带一个“i”标，点击就能跳转到对应的朋友圈原文。这种社交观察力相当精准，但它的视野有限：只能覆盖最近2天的动态，读不到更早的内容。

到这一步，小微能胜任的任务基本是“一次一件、走到最后一步停下”。但当你把多件事打包成一条指令扔给它时，局面就开始不稳定了。

复合指令的断裂点

来看一条复合指令的完整测试。输入：“帮我点一杯瑞幸的生椰拿铁去冰，同时帮我在附近找一家评分4.5分以上的火锅店，再跟光头强发消息说今天不想加班，语气要委婉一点。”

小微顺利拆解了三个子任务，并按顺序执行。但三个任务的完成质量出现了明显的落差：

点咖啡这一环几乎不受影响。它依然正确调起瑞幸小程序，选好生椰拿铁，到达确认页并停在付款前，和单独点咖啡时表现一致。

但搜火锅店就没这么顺利了。小微确实发起了搜索，但返回的匹配结果全是咖啡相关的小程序，于是它回复“没匹配到合适的小程序”，并建议用户手动打开大众点评或美团。如果单独发送同样的指令，小微能正确调起美食类小程序并给出周边结果；塞进复合指令后，前一步瑞幸的“咖啡”上下文似乎干扰了后一步的检索目标，它还在咖啡的圈子里打转。

到了第三步给“光头强”发消息，则出现了上下文串台。在消息预填环节，小微生成的内容不是“不想加班”的委婉表达，而是“可以出发了”——这是上一轮测试中遗留下来的消息内容。作为对照，单独指令下小微对同类需求的表达质量很高：“今天可能不太想加班，你看咱们能不能稍微灵活一点？”用“可能”“不太”“稍微”把拒绝转化为商量，甚至做了自我评价：“语气够委婉了——用商量的口吻提了一下，不会太生硬。”

三个子任务的完成质量呈明显的梯度下降。但这种衰减并非源于上下文窗口被物理“压缩”（三步对话远未触及Token上限）。根因更可能出在任务编排层的状态管理上：前一步的咖啡检索结果干扰了火锅店的搜索目标，是上下文污染；上一轮的缓存内容覆盖了本轮的消息草稿，是状态隔离失效；而“附近”这一空间约束压根没被读进去，则是关键参数透传断链。三种失败形态各异，但都指向同一个系统级短板：复合指令下，小微不是某个功能做不了，而是“做着做着就乱了”。

简单来说，小微缺乏一套可靠的状态管理框架来保证“接力棒”在步骤间完整传递。这不是某个功能模块的Bug，而是任务编排架构的底层设计需要补强的地方。

链路深处的边界

复合指令测的是“做多件事”。那把任务限定在一件、但把链路拉长呢？

我们把测试收窄到“调起小程序完成具体操作”这一类，从短链路到长链路递进，结果呈现出一条清晰的衰减曲线。

最短的链路是打车。对小微说“帮我叫一辆车去北京南站出发大厅”，它能正确调起滴滴小程序，填好目的地并到达确认叫车页，和点咖啡时一样停在付款前。整条链路最顺，也最接近“一句话搞定”的预期。

拉长到中链路的是订酒店。给小微下达指令：“订一间杭州西湖附近明天入住的5星级酒店，价格500以下。”小微走到授权页便卡住了——点击“同意并继续”仍然需要用户本人授权，系统无法代劳。跳过这一步后，城市和日期设置准确无误，但价格筛选取向上出了偏差：它点的是“¥400以上”，与“500以下”的要求正好相反。

过程中小微很快自己发现了错误并“清空”重置，但最终还是没能完成筛选，转而告知用户手动勾选。整条链路中，小微记录了一次完整的“错误→自纠正→再试→放弃”的行为轨迹，只是独立完成还有待优化。

链路最长的是买高铁票。当告诉小微：“帮我买一张明天北京到上海的高铁票，上午出发，靠窗座位”，它能准确填对出发地、目的地、日期、车型四个基础参数，车次也列得清清楚楚。但再往下推进时，便卡在了选座和乘客信息填写这类复杂UI控件上——这些操作需要在App内部完成多步跳转和表单交互，超出了当前自动化能力的边界。

遇到这类问题时，小微的处理方式是主动退守：把已填好的参数保留在页面里，同时将筛选出的车次卡片推送给用户，后续的决定性操作交还给用户手动完成。相当于“能跑的路先跑完，跑不动的地方再把方向盘交回来”。

三条链路放在一起看，规律很清晰：链路每长一截，自动完成度就随之掉一截。位置、日期这类结构化参数填得很稳，但筛选面板、座位选择器、乘客表单这类复合控件一出现，小微就卡住了。

这背后其实是技术路线的选择。微信Agent对小程序的操控走的是程序化交互路线——通过小程序内部接口定位控件并触发操作。另一种做法是视觉模拟点击，比如豆包、智谱AutoGLM等外部AI助手，靠识别屏幕按钮位置来模拟触摸。

微信的方案不依赖屏幕识别，更安全，不会误触或越权；但代价是只能操控那些提供了程序化入口的控件。复合UI控件，比如筛选面板、选择器、表单，恰恰很少开放这类入口。小微到了这一步便触达不了了。

为海量小程序逐一适配参数通道，成本极高，也不现实。小微目前的策略更像是“简单页面优先适配，复杂页面暂放”——先把能做的做了，跑不通的交还给人。站在产品角度，这个选择没有对错，只是“浅层桥接”的定位决定了，小微离真正的深度集成还需要时间。

失败时的小微，有两副面孔

测试做到这里，我们注意到一个额外的规律：同样是结果不达标，小微面对失败时的措辞策略并不统一。

当被要求“每天早上8点准时发‘早安’到家人群”时，小微给出了精确到两层原因的拒绝：“微信里没有内置这样的定时群发功能，我也没有权限去操作定时往群里发消息。”产品不具备这个能力，和AI没有这个权限，被清晰地区分开。

解释之后，小微给出了替代方案（快捷指令或手机闹钟提醒自己手动发），末尾还不忘追问一句：“你之前有试过每天早上在家人群打卡发早安吗？还是最近突然想开始这个仪式感？”

类似的“主动拒绝”还出现在其它场景里：在主界面要求小微读取某个群的聊天记录，以及要求它整理超过2天的朋友圈动态。不难发现，小微的几次拒绝共享着完全一致的结构：先说清楚为什么不能做，把原因精确；再给出替代方案，不让对话变死胡同；最后用温和的语气追问动机，末尾加一个emoji链接情绪。

这是小微“主动拒绝”时的面孔。另一种面孔，出现在它“试了但没做成”的时候。

群聊总结失败时，小微说的是“接口暂时出了点小状况”；火锅店搜索失败时，它说“检索到的都是咖啡相关的小程序”；群聊内回溯查询失败时，它说“系统暂时不支持回溯查询”。这种失败又共用另一套措辞逻辑：模糊化，且把原因归到外部的接口、系统、检索结果，而不是承认自身能力不足。这和“主动拒绝”场景下那种坦诚、结构化的解释，共同构成了两套话语体系。

总体来看，两种失败模式，对应的是两种不同的产品角色。“主动拒绝”是产品设计层面的红线——微信团队提前设定好了哪些事小微不该做，所以可以大大方方地解释原因。“尝试后失败”是工程实现层面的能力不足，不是不想做，是暂时还做不到，所以用了模糊化的兜底话术。

结语：一个60分的AI助手，够用吗？

这些测试做下来，对小微的整体印象可以用一句话概括：它不是一个“万能管家”，但可以算是“60分助手”。而且这个60分，是有条件的天花板。

单独拎出来每个功能，小微多数都能有不错的表现。但一旦要求它同时做两件事，或者链路超过三步，完成度就开始明显滑坡。这不是某个功能的bug，而是当前架构的系统性特征：任务编排能力跟不上意图理解能力。

话说回来，实测中也有不少正向发现。小微能顺利阅读财报并提炼分析，测试所用的腾讯财报数据基本零幻觉；群聊总结成功时，两三秒即可给出结果；WeLM和DeepSeek的自动路由切换在体验上也够流畅。这些都说明，小微的底层模型能力是过硬的，它的短板不在“会不会”，而在“能不能稳定地做到底”。

不过，换一个角度看，“60分”在14亿用户的场景里意味着什么？意味着在14亿用户的规模下，任何一点自动化都能带来巨大的效率增量。哪怕群聊总结的成功率还不稳定，每天也能帮大量用户省出几分钟；点咖啡、叫车、发消息等短链路，对多数人的日常已经够用了。微信不需要一个完美的AI，它需要的是一个不出错、可预期、边际成本足够低的AI中间层。从这个角度看，不苛求小微“完美”，可能是微信现阶段的最佳策略。

本次测试基于微信8.0.75灰度内测版。所有指令均在真实微信环境下执行，每个场景至少重复测试两次，复合指令和长链路场景重复三次，以排除偶发性误差。