实测微信小微：一个“生在微信里”的AI，边界在哪里|app|中小微|满血版模型

一个长在微信里的AI助手，到底能替你做多少事，它的使用边界又在哪里？

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

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

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

小微能做什么？

从小微的自我介绍不难看出，“生在微信里”意味着它天然接入了微信的聊天、小程序、支付体系；同时，它的手也只伸得到这一圈。绕开纸上谈兵，我们先看实测中它到底能做到什么。

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

这是目前较为成熟的使用场景，不过整个过程仍不算完美。在重复多次让小微点咖啡后发现，小微还做不到所谓的“一句话点咖啡”：有时它会卡在配送方式的选择上，有时卡在加购弹窗的确认上，每次都需要用户手动介入至少一次。可见，小微擅长的是“填参数”，一旦“做选择”就会被退回交给用户。

这个“停在付款前”的设计并非小微独有，阿里旗下的千问App在点咖啡时同样止步于支付前最后一步。但相同的终点背后，是两条不同的技术路径：千问走的是API接口方案，直接调用淘宝闪购和支付宝的系统级接口，在App内以卡片形式完成推荐和确认，整体流程更顺滑，部分订单还能叠加平台优惠；小微走的是小程序参数协议，能填参数，但面对复杂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中间层。从这个角度看，不苛求小微“完美”，可能是微信现阶段的最佳策略。