AI 搜索能力自测报告：豆包、Kimi、EXA+GLM对比

〇、对应测试链接

豆包： AI 搜索能力自测报告：豆包 - LINUX DO

KIMI：AI 搜索能力自测报告：KIMI - LINUX DO

GLM+EXA：正在建设

一、测试目的

因发现网络上“迷信AI搜索结果”的例子越来越多，本人家里也有因为我推荐开始使用AI的亲戚朋友（比如我妈在用蚂蚁阿福、我朋友和我表妹在用豆包）

本次测试主要观察不同 AI 搜索方案在真实问题下的表现，重点关注三个方面：信息来源是否专业、结论是否准确、回答是否具备可验证性

测试对象包括自集成搜索能力早期和现在比较突出的：

豆包网页端、Kimi 网页端

还有我自己的EXA + GLM-5.1

本次测试不重点比较模型闲聊能力，而是关注它们作为“AI 搜索工具”时，能否稳定给出高质量、有来源、可追溯的答案

本次测试不对问题进行过度工程化优化，因为真实用户提问往往就是模糊、口语化和带上下文缺失的。测试重点不是看 AI 能否完成精确指令，而是看它在自然提问下的理解能力和信源选择能力，测试时均使用厂商默认选中的+网络搜索能力，尽量模仿第一次下载安装使用模型的情况

为什么没有DeepSeek\千问，emmmm我太懒了的说

二、测试维度

本次测试采用 5 个维度进行观察：

1. 
   

   来源专业性
   
   是否优先引用官网、论文、技术文档、权威媒体、标准组织等高质量来源

   
   


2. 
   

   来源准确性
   
   引用内容是否真实存在，是否存在“看起来像引用但点开不相关”的情况

   
   


3. 
   

   信息时效性
   
   面对最新版本、最新政策、最新事件时，是否能检索到较新的资料

   
   


4. 
   

   结论一致性
   
   回答结论是否和引用来源一致，是否存在来源说 A、模型总结成 B 的问题

   
   


5. 
   

   可验证性
   
   是否提供链接、出处、发布日期、原文信息，方便人工复核

   
   

三、测试问题设计

为了避免单一问题造成偏差，本次测试设计了几类问题：

第一类是技术类问题，例如：

“请对比 OSPF 和 IS-IS 在大型运营商网络中的适用场景，并给出权威来源”

第二类是时效类问题，例如：

“请查询Grok当前最新版本、发布时间和主要能力变化”

“济南天桥在维修吗”

“我从大观园坐公交车去济南市动物园，应该坐几路车”

第三类是争议类问题，例如：

“请分析 AI 搜索和传统搜索引擎在信息可信度上的差异，并引用可靠来源”

“Vless代理协议近期有什么纠纷，我继续使用的话安全吗”

“linux.do这个网站主要是做什么的”

第四类是事实核查类问题，例如：

“DeepSeek-V4.1 是多模态模型”

“RIP、OSPF、BGP、Radius一样，如果要支持IPV6的话，就要彻底重写网络协议”

“BGP 是否存在名为 RFC 4271bis 的正式标准版本，如果存在，请给出 RFC 编号或 IETF 官方来源；如果不存在，请说明目前 BGP-4 的主要正式标准来源是什么”

“OSPFv3 是否只能用于 IPv6 网络，是否支持 IPv4 地址族”

这些问题可以同时测试搜索深度、来源质量、总结能力和事实核查能力

四、简要观察记录模板

• 分值越高越好、具体分值在各个子报告页面里面

五、测试结论

从初步测试思路来看，AI 搜索能力不能只看回答是否“像那么回事”，更重要的是看它是否能提供可靠来源，并且回答内容是否真正来自这些来源

网页端 AI 产品的优势是使用门槛低、交互体验好，适合快速了解一个问题的大致情况。缺点是搜索策略通常不可控，用户很难知道它具体检索了哪些内容、过滤了哪些来源

自建 EXA + GLM-5.1 的优势是链路可控，可以自行决定搜索关键词、召回数量、来源过滤规则和总结方式，更适合做专业场景下的定制化搜索。但它也对使用者要求更高，需要设计检索策略、去重机制、来源排序和事实校验流程

因此，本次自测更倾向于把 AI 搜索分成两类来看：

一类是通用网页端 AI 搜索，适合快速获取信息、初步理解问题

另一类是自建检索增强链路，适合专业场景、可控流程和可复现测试

最终判断 AI 搜索能力时，不应只看回答是否完整，而应重点看三点：来源是否权威、引用是否真实、结论是否忠于原文

搜索还得是grok和gpt，正常情况下的GPT，像个无口理工小萝莉（我给她的人设）

深刻的体验AI瞎扯时，戳到了某处专业点belike（回形针diss）：