开工前先做实验

搭 GEO 诊断工具的时候，我给自己定了一条规矩：没写一行业务代码之前，先验证最要命的技术假设——用 API 批量问 AI，和真实用户在网页/App 里问，看到的答案是一回事吗？

如果是一回事，那太好了，API 便宜、稳定、好批量。如果不是一回事，那整个工具的技术路线都得换。

实验很简单：同一个问题——“苏州园林设计公司哪家做别墅庭院景观比较靠谱”——分别问四个地方：DeepSeek API、DeepSeek 网页版（开智能搜索）、豆包 API（方舟）、豆包网页版（默认联网）。

结果：三处致命差异

第一，API 不联网，引用永远是空的。 两家的 API 返回的引用字段都是空数组。DeepSeek API 自己都在回答里承认：这是训练期的知识，建议你自己联网搜索。而网页版是真联网的——DeepSeek 网页版显示”已阅读 12 个网页”，豆包搜了 3 组关键词、参考了 16 篇内容。GEO 诊断的核心输出之一就是”AI 引用了哪些来源”，用 API 跑，这个字段永远是空的，等于诊断报告缺了半边。

第二，豆包 API 连具体公司名都不给。 这是最夸张的一处。豆包网页版会实实在在地点名推荐：融景、理池、雍景、绿立方、金螳螂……有名字有理由。而豆包 API 的回答里几乎全是”XX 造园""XX 景观工作室”这种占位符，只讲一套筛选方法论。这意味着什么？如果用豆包 API 做诊断，所有客户的”是否被提及”都会是”否”——不是客户 GEO 没做好，是 API 压根不输出实体名。 你会拿着一份数据齐全但结论全错的报告去见客户。

第三，只有联网版有时效性。 DeepSeek 网页版在推荐之余，还点名预警了两家”经营异常/已注销”的公司——这种信息只有实时联网查工商数据才可能给出。API 靠训练期的老知识，推荐的可能是已经不存在的公司。

另外还有个技术细节：即使在网页版里，豆包的引用链接也不在页面文字里（只显示”今日头条”几个字），要从网络请求的数据包里去抠。而且这个接口在我开发期间还变过一次——所以每接一个新平台，都要重新做小验证，不能类推。

结论，以及一个防割韭菜的问题

实验结论写进了项目文档，还加了一句话：“勿凭记忆改动，除非重新验证。“最终方案：诊断一律走真实浏览器（Playwright 驱动真实 Chrome，登录真实账号），API 只用来干辅助活——生成问题、判重、判断描述准确性这些不影响诊断真实性的任务。

代价当然有：浏览器自动化慢、脆、会遇到风控（我实测中浏览器断连过、标签页空白过、豆包静默禁用过发送按钮），所以工具里做了失败跳过、补跑、随机间隔这些兜底。但慢而真实，好过快而全错。

最后送你一个实用问题。现在市面上做 GEO 服务的人越来越多，如果有人拿着一份漂亮的诊断报告向你收钱，就问他一句：

“这些数据是真人视角从浏览器里抓的，还是接口批量跑的？”

答不上来，或者答”接口跑的”，直接 pass。你已经知道为什么了。