AI 给的仓库地址是编的：一次 403 与 404 的排查方法

先说结论：AI 给你的地址可能完全不存在，而且它自己不会有任何察觉。这两天我在找某个技能市场的上架通道，AI 告诉我「官方仓库是 gitcode.com/xxx/yyy-skills，按 README 的贡献规范组织目录后提交 PR」。我照着做了三轮，最后发现那个仓库压根不存在。

把这段排查过程记下来，因为它不是个例，而是一个可以复用的判断方法。

一、三个可疑信号

回头复盘，其实第一分钟就有信号，只是当时被「官方文档这么说」的错觉盖过去了。

• 信号一：地址来自 AI 的叙述，而不是你亲手点开的链接。我当时是在对话里直接拿到了 URL 字符串，没有经过浏览器。任何没有经过你亲自打开验证的地址，都应当被当作假设。
• 信号二：它给的是「规范 + 仓库」这种组合。真实的开源协作流程通常是可检索的，但如果同时出现「某个内部仓库 + 特定目录结构 + 提交 PR」这套完整叙事，大概率为凑齐逻辑而编造。
• 信号三：它反复强调「国内访问不到 GitHub」。这类补充说明往往是为了解释「你为什么搜不到」，而不是陈述事实。

二、两条命令验完

不要用浏览器打开页面来判断——页面可能返回一个漂亮的 404 页面，也可能被 CDN 拦成登录页。用命令行，看协议层。

git ls-remote https://gitcode.com/xxx/yyy-skills.git

真实仓库会返回 ref 列表（HEAD、refs/heads/main 等）。不存在时返回的是：

remote: <CH.00905403> The project you were looking for could not be found.
fatal: unable to access '...': The requested URL returned error: 403

注意这里是 403 而不是 404。很多人看到 403 会误判成「需要登录」，然后去折腾凭证，白白浪费半小时。判断方法很简单：加 -c http.extraHeader 带上你的 token 再试一次。如果带凭证后变成 404，说明项目确实不存在；如果带凭证后成功了，那才是权限问题。

curl -sI https://gitcode.com/xxx/yyy-skills | head -5

看返回码和 Server 头。真实仓库是 200；不存在的项目在很多平台上是 200 但内容区渲染 404 组件，这时需要看 body 里有没有「页面找不到或无权限」这类文案。

三、AI 幻觉的三种形态

这类错误不只有「编一个不存在的 URL」，实际遇到的有三种，处理方式不同：

1. 纯编造：域名和路径都是虚构的，DNS 都解析不出来。用 dig +short 一秒识破。
2. 半编造：域名真实、组织真实、仓库名虚构。这个最难识破，因为域名解析正常、组织页也能打开，只有具体仓库 404。必须走到 git ls-remote 这一层。
3. 过时：地址曾经真实存在，后来下线或改名。这类要用回源工具交叉验证，比如 Wayback Machine 或搜索引擎的缓存结果。

我遇到的是第二种，也是最容易骗过人的一种。

四、工程上怎么防

如果你在做 Agent 相关的产品，这个问题必须在前置环节拦掉，不能指望用户自己去验。

• 工具返回优先：任何「地址、命令、接口」类信息，只允许来自工具的真实返回，不允许模型直接生成。生成的内容必须标记为待验证。
• 落库前先探活：把候选 URL 送进一个 HEAD 请求，2 秒超时，失败就丢弃并回退到「我不确定，建议你在官网搜索」。
• 给出可验证的下一步：与其给一个可能编造的链接，不如给出「在官网搜索关键词 X，第一个结果通常是」这种可执行的路径。前者是结论，后者是方法，方法不容易错。

五、一个更省事的自查习惯

我现在所有来自 AI 的命令行都走一个固定动作：先把地址单独丢进 shell，跑一次 curl -sI 或 git ls-remote，成功再继续。两秒钟的事，能省掉后面半小时的瞎折腾。

顺带说一句，这次真正找到入口的方式也不复杂：不信任任何二手地址，从产品官网首页点进去，一路点到「在线体验」，地址栏里那个才是真的。二手信息可以给你方向，但不能给你答案。