近日，有开发者在技术社区反馈，在使用 DeepSeek 网页版进行联网搜索并分析 GitHub 开源项目代码时，遇到了显著的可靠性问题。该用户指出，当向 DeepSeek 提供一个 GitHub 上的源码文件链接时，AI 模型在首次请求中显示“读取失败”。推测这可能是因为触发了 GitHub 的访问频率限制，或者未能正确处理 GitHub 的网页渲染结构。值得注意的是，当用户手动将链接替换为 `raw.githubusercontent.com` 域名后，DeepSeek 成功获取了文件内容。然而，这一过程暴露了当前 AI 编程助手在处理网络请求失败时的鲁棒性缺陷。更令人担忧的是，当 DeepSeek 无法成功抓取代码内容时，并没有向用户报错或尝试重试，而是倾向于基于常识“伪造”代码。这种行为导致了严重的“幻觉”问题，即模型生成了看似合理但实际并不存在的代码。对于依赖 AI 进行代码审查、漏洞分析或辅助开发的开发者而言，无法区分“真实读取的代码”与“模型伪造的代码”是一个巨大的潜在风险，这极大地削弱了开发者对工具的信任度。
事件分析
该事件技术层面涉及 RAG（检索增强生成）流程中的异常处理与数据源适配。GitHub 托管页面的 HTML 结构复杂，直接解析难度大，而 `raw` 链接提供纯文本，是 AI 读取源码的标准路径。模型在请求失败（如 429 Too Many Requests 或超时）后未触发明确的错误中断，反而继续执行生成任务，说明其底层提示词工程或联网插件缺乏“置信度校验”机制。这反映出当前主流大模型在“接地气”能力上的短板：即模型尚不能有效区分“由于网络限制导致的知识缺失”与“本身不具备该知识”。在 AI 编程领域，这种“一本正经地胡说八道”比拒绝回答更危险，因为它会向开发者注入逻辑错误甚至安全漏洞。未来的工具优化方向必须引入严格的“数据来源验证”，一旦检索失败，必须强制模型输出无法分析的结论，而非利用训练数据进行概率填充。
💡 核心观点：DeepSeek的“断网幻觉”暴露了RAG链路的关键短板：在数据获取失败时，AI必须学会“说不知道”而非强行生成，否则代码辅助将沦为效率陷阱。
原文链接：Linux.do
评论前必须登录！
立即登录 注册