先厘清一个核心区别：百度AI搜索在处理“微信AI搜索问题”这类查询时，涉及两个完全不同的技术维度——用户身份识别解决的是“谁在问”，而用户意图识别解决的是“问什么、想干什么”。这两条技术路径差异极大，不能混为一谈。

简单说，身份识别靠的是OpenID、UnionID这类静态标识；意图识别则依赖query分词、上下文建模与行为序列这些动态信号。

区分用户身份：靠 openid、unionid 或临时 visitorId

微信生态内，已登录用户会带着稳定标识——openid是单小程序/公众号的专属凭证，同一主体下的多平台用户还能拿到unionid。而没登录的游客没有openid，必须临时生成一个visitorId。具体怎么操作？

方法一：用 openid 作为已登录用户的稳定标识
调用 wx.login() 拿到code，后端用这个code调auth.code2Session接口，返回结果里就带着openid和session_key。openid是微信侧颁发的不可伪造凭证，直接用于绑定用户身份，这个思路最直接也最常用。

方法二：用 unionid 串联多平台用户
前提是小程序已经绑定到微信开放平台。在云函数里通过Cloud.getWXContext()，或者后端调code2Session（需传appid + secret + code），如果用户在这个开放平台的其他应用（比如公众号）已经授权过，返回结果里就会带上unionid。相比于openid，unionid更适合做跨平台的用户统一——如果用户在小程序和你公司的公众号上都有动作，unionid能把两者关联起来。

方法三：为游客生成时间戳+随机数 visitorId
这个就简单了：
let date = new Date();
let time = date.getTime().toString();
let r = (Math.random() * 1000).toFixed(0);
let visitorId = time + r;
把这段逻辑写在小程序onLaunch生命周期里就行。不过必须警惕的是：这个ID只适合前端本地缓存使用，完全不能用于鉴权或敏感操作——因为它太容易被伪造了。

区分用户意图：靠 query 分词 + 上下文建模 + 行为序列

然后是另一条路。百度AI搜索在处理“微信AI搜索问题”这类查询时，根本不关心用户身份，它聚焦的是query文本本身的上下文信号。怎么实现的？分三步。

第一步：对原始 query 做轻量级清洗与标准化
去掉冗余标点、统一空格、转小写、替换同义词（比如“怎么”→“如何”，“弄”→“实现”）。这一步看似基础，但直接影响后续分词的准确率，跳过了，意图分类很容易跑偏。

第二步：提取核心动词+宾语组合
比如“微信小程序怎么区分用户” → 抽出来“区分+用户”；“AI搜索查不到unionid” → 抽出来“查不到+unionid”。模型据此判断这到底是技术咨询类还是报错类意图。

第三步：叠加会话上下文与行为特征
假设用户刚点开过一篇“openid 获取流程”的卡片，紧接着又搜“code2Session 返回 null 怎么办”，系统会把这两次查询的embedding加权合并。这样一来，意图判定就从模糊的“微信开发问题”精准收敛为“登录态调试问题”。

百度AI搜索实际返回结果的意图分层逻辑

当你真的在百度搜索框里输入“微信AI搜索问题怎么区分不同用户意图”，它不会去调你的微信openid，更不会读你手机通讯录。它只解析这句query的语义结构，靠的是三重机制。

方法一：基于预训练大模型的 zero-shot 分类
把query扔给轻量化LLM（比如ERNIE-Speed），模型输出一个意图标签的概率分布。最高分项是“开发者技术疑问”，次高是“产品功能咨询”，像“营销推广”“个人隐私求助”这些不相关的类目都会被排掉。

方法二：匹配知识图谱中的标准问法模板
系统维护着一张《微信开发高频问题-意图映射表》。像“怎么区分……”“如何判断……”“……是什么意思”这样的问法，都指向“概念解释类”；而“报错”“失败”“没反应”这类关键词，则倾向“故障排查类”。当前query匹配到3条模板，置信度最高的那一项就是“技术概念辨析”。

方法三：结合点击反馈动态调权
过去的7天里，搜同一句query的用户中，82%点开了《UnionID 与 OpenID 区别》这篇文档，65%在结果页停留超过45秒。系统会自动提升这篇文档在同类query下的排序权重——这就在强化“区分”动作背后的对比型意图。