〇、对应测试链接
KIMI：正在建设
GLM+EXA：正在建设
一、测试目的
因发现网络上“迷信AI搜索结果”的例子越来越多，本人家里也有因为我推荐开始使用AI的亲戚朋友（比如我妈在用蚂蚁阿福、我朋友和我表妹在用豆包）
本次测试主要观察不同 AI 搜索方案在真实问题下的表现，重点关注三个方面：信息来源是否专业、结论是否准确、回答是否具备可验证性
测试对象包括自集成搜索能力早期和现在比较突出的：
豆包网页端、Kimi 网页端
还有我自己的EXA + GLM-5.1
本次测试不重点比较模型闲聊能力，而是关注它们作为“AI 搜索工具”时，能否稳定给出高质量、有来源、可追溯的答案
本次测试不对问题进行过度工程化优化，因为真实用户提问往往就是模糊、口语化和带上下文缺失的。测试重点不是看 AI 能否完成精确指令，而是看它在自然提问下的理解能力和信源选择能力，测试时均使用厂商默认选中的+网络搜索能力，尽量模仿第一次下载安装使用模型的情况
为什么没有DeepSeek\千问，emmmm我太懒了的说
二、测试维度
本次测试采用 5 个维度进行观察：
-
来源专业性
是否优先引用官网、论文、技术文档、权威媒体、标准组织等高质量来源 -
来源准确性
引用内容是否真实存在，是否存在“看起来像引用但点开不相关”的情况 -
信息时效性
面对最新版本、最新政策、最新事件时，是否能检索到较新的资料 -
结论一致性
回答结论是否和引用来源一致，是否存在来源说 A、模型总结成 B 的问题 -
可验证性
是否提供链接、出处、发布日期、原文信息，方便人工复核
三、测试问题设计
为了避免单一问题造成偏差，本次测试设计了几类问题：
第一类是技术类问题，例如：
“请对比 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 地址族”
这些问题可以同时测试搜索深度、来源质量、总结能力和事实核查能力
四、简要观察记录模板
测试对象 来源专业性 准确性 时效性 可验证性 简评 豆包网页端 Kimi 网页端 EXA + GLM-5.1- 分值越高越好、具体分值在各个子报告页面里面
五、测试结论
从初步测试思路来看，AI 搜索能力不能只看回答是否“像那么回事”，更重要的是看它是否能提供可靠来源，并且回答内容是否真正来自这些来源
网页端 AI 产品的优势是使用门槛低、交互体验好，适合快速了解一个问题的大致情况。缺点是搜索策略通常不可控，用户很难知道它具体检索了哪些内容、过滤了哪些来源
自建 EXA + GLM-5.1 的优势是链路可控，可以自行决定搜索关键词、召回数量、来源过滤规则和总结方式，更适合做专业场景下的定制化搜索。但它也对使用者要求更高，需要设计检索策略、去重机制、来源排序和事实校验流程
因此，本次自测更倾向于把 AI 搜索分成两类来看：
一类是通用网页端 AI 搜索，适合快速获取信息、初步理解问题
另一类是自建检索增强链路，适合专业场景、可控流程和可复现测试
最终判断 AI 搜索能力时，不应只看回答是否完整，而应重点看三点：来源是否权威、引用是否真实、结论是否忠于原文
搜索还得是grok和gpt，正常情况下的GPT，像个无口理工小萝莉（我给她的人设）
深刻的体验AI瞎扯时，戳到了某处专业点belike（回形针diss）：
1 个帖子 - 1 位参与者