我在做一个真实的小工具：拾玖搜证台。它用来手动保存 AI 搜索回答、引用链接和核对结论，数据放在浏览器本地，可以导出 JSON、CSV、Markdown。它本身不自动提问，也不调用模型 API。
这次想验证的问题很具体：在豆包新对话里，不提供网址，只给工具名称，或者只描述适用需求，系统能否自行找到公开来源、介绍正确功能，并给出支持信息的链接？
截至 2026 年 11 月 5 日上午，我们保存了 20 条正式采样回答和 3 条单列的检索链路诊断。独立发现仍未成功。
这是一份维护者自己的实验记录，不是第三方测评，也没有证明某一种修改能提高推荐概率。
先把结果完整摆出来
| 测试组 | 回答数 | 实际观察 |
|---|---|---|
| 固定名称题 N01 | 4 | 0 条达到主体、具体事实和支持来源标准 |
| 固定需求题 S01、S03 | 8 | 0 条正确推荐本工具 |
| 原有 q1 问题集的追加覆盖 | 5 | 本轮首次执行，均未达标，不能当作已有基线的改善 |
| 正式网址诊断 D01—D03 | 3 | 其中 1 条内容与完整来源核对通过，另外两条引用不完整 |
| 完整文章标题搜索 | 1 | 未找到对应文章 |
| 限定域名搜索 | 1 | 未找到对应页面 |
| 给新根站网址读取 | 1 | 正确识别署名和功能，并给出根站链接 |
前四组是 20 条正式记录；后三组提供过文章标题、域名或网址线索，单列，不计独立发现成绩。
按正式记录的路径汇总，名称路径 0/7、需求推荐 0/10。这两个分母覆盖了不同问题。做前后比较时，应该先看保持原题的 N01、S01、S03，不能只拿总数判断有没有改善。
所有问题都在豆包网页端、已登录账号、快速模式下新建对话。但它们仍使用同一账号，跨对话个性化没有排除；当前电脑的网络地区未核实，不代表国内直连或 App。判定由 AI 助手逐条核对，尚未做第二人复核。
100 分到底检查了什么
本 demo 使用 Fangx-AI 的开源项目 GEO 医生来整理事实、管理问题、生成事实站和检查公开页面。根站上线后，我运行了原版技术检查，结果是 100/100、14 项通过。
这次检查使用普通 HTTP 请求，并加了 --no-probe，没有模拟爬虫身份。通过的内容包括：
- HTTP 返回 200，没有异常跳转；
- 不运行 JavaScript，原始 HTML 已有标题和完整产品说明；
- 没有发现禁止索引的响应头或 HTML 标记；
- canonical 指向当前页面；
- 域名根目录有 robots.txt 和站点地图；
- 页面有 WebSite、Person、SoftwareApplication 结构化数据。
这些检查支持“当前请求能取得正文，技术配置基本具备”的判断。检查器根据规则显示爬虫可以抓取，也只说明规则判定；我们没有经过身份核验的源站或 CDN 请求日志，不能宣布真实爬虫已经来过。
原始检查报告已经公开：根站技术报告。
一处值得纠正的细节：robots.txt 的位置
我们的工具最初放在 GitHub Pages 项目子路径。子目录里的 robots.txt 返回 200，内容也是允许抓取；但域名根目录的 /robots.txt 当时返回 404。
按 RFC 9309，标准规则文件应位于服务的顶层路径 /robots.txt。子目录里有一个同名文件，不代表域名规则已经生效。
这里还有一个容易误判的地方：根目录 404 本身也不等于禁止抓取。协议允许爬虫在规则文件不可用的相应情况下访问资源。所以不能把这个发现直接写成“找到豆包未收录的原因”。
我们随后建立了根站，补上根目录规则和站点地图索引，原有作品站和记录器地址保留。根站现在是 nineting19.github.io。
这项修改让入口和规则更清楚，实际搜索效果还要另测。
网址能读，搜索仍找不到
我参考了方鑫三个金《如何给个人博客做 GEO》的排查方式，把条件进一步拆开：允许抓取、真实访问、搜索发现、答案引用，分别需要证据。
我们后来做了三项额外诊断：
- 给完整掘金文章标题搜索，豆包表示未找到；
- 给出域名并要求搜索相关页面，仍表示未找到；
- 直接给根站网址，能够说出作者署名、localStorage 本地保存、导出格式和 JSON 去重合并，并给出完整来源链接。
这些观察支持一个有限结论：本次给网址后，内容识别和引用能够完成；本次标题搜索和限定域名搜索没有找到页面。
没有源站日志，我们仍不能仅凭正确复述，判断文字一定来自当次实时抓取。它也不能证明页面已进入平台的独立检索范围。
看未命中时，也要看它检索到了什么
名称题的来源面板里出现了推理、剧本杀和同名内容；一个使用问题甚至把本工具误认为剧本杀网页工具。我们把它记为主体描述错误，没有因为回答碰巧提到了 localStorage 就判为识别成功。
需求题主要推荐了其他 diff、RAG、可观测或网页批注工具。本文没有逐项核实那些产品的能力，也不把模型原答当成对它们的推荐依据。
据此，我们把真实名称和功能类别放进根站标题、公开仓库说明和原有掘金文章标题，保持作者、产品和限制的表达一致。但这仍是基于观察做出的调整，尚未获得独立发现改善的证据。
通知搜索系统，也要保留状态边界
新根页只提交了一次 IndexNow 通知，接口返回 202。按官方文档，这是已接收、密钥验证待处理；它不代表已经建立索引。
GitHub 站内仓库搜索可以找到两个自有仓库，这也是另一种范围内的发现证据。我们没有据此把豆包的未命中改成成功，更没有把待发布稿、技术评分或通知回执计入效果。
下一轮怎么做
保留固定问题，分清首次执行和重复执行，继续记录完整回答、实际引用和测试环境。取得索引或访问证据时，再注明来自哪个系统、哪条路径和哪个时间窗口。
如果出现第一次正确介绍，也要打开引用核对具体事实，并检查当前检索资料是否包含目标来源。一次命中不能直接归因于某个标题修改；同账号影响、时间差和多项同时变更都需要保留说明。
完整原文和截图留在本地实验资料中；公开页面只给出聚合结果和判定条件，不公开账号资料或聊天侧栏。
体验、依据与归属
- 拾玖搜证台根站
- 打开本地记录器
- 公开实验状态与条件
- 此前的工具操作教程
- 上游 Fangx-AI / GEO 医生
- 参考：方鑫三个金《如何给个人博客做 GEO》
- RFC 9309：robots.txt 位置与不可用状态
- IndexNow 官方文档
作者：拾玖。本文为项目维护者自己的实验记录。GEO 医生及其上游工作归 Fangx-AI；浏览器本地记录器和本次公开页面为本 demo 新增实现。
内容说明：本文使用 AI 辅助生成与编辑，数字、功能与限制以实际实现和保存的采样记录为依据；独立发现尚未成功，不承诺收录、推荐或排名。
