衡堕

DeepSeek 与 AI 幻觉：机制、评测与应对策略

Fri, 31 Jul 2026 00:00:00 GMT

AI 幻觉是当前大语言模型最受关注的问题之一。它并非简单的模型缺陷，而是统计概率驱动下的"合理猜测"——模型在缺乏可靠数据时，以最高概率路径补全输出，导致事实性或忠实性偏差。

本文基于清华大学人工智能学院张家铖博士后团队的评测数据（38 页报告，2025 年 2 月），梳理幻觉的产生机制、推理模型带来的双向效应、不同场景下的风险等级，以及从普通用户到技术层面的应对策略。

一、什么是 AI 幻觉

学术定义： 模型生成与事实不符、逻辑断裂或脱离上下文的内容，本质是统计概率驱动的"合理猜测"。

两种类型

类型	定义	示例
事实性幻觉	内容与可验证的现实世界事实不一致	"蜂蜜适合糖尿病患者稳定血糖"（实际含大量果糖，会升高血糖）
忠实性幻觉	内容与用户指令或上下文不一致	问"蜂蜜能否代替糖"→ 回答蜂蜜富含维生素（事实正确但偏题）

二、为什么会产生幻觉

原因	说明	示例
数据偏差	训练数据中的错误或片面性被放大	医学领域过时论文导致错误结论
泛化困境	难以处理训练集外的复杂场景	南极冰层融化对非洲农业的影响预测
知识固化	过度依赖参数化记忆，缺乏动态更新	2023 年后的事件完全虚构
意图误解	用户提问模糊时，模型"自由发挥"	"介绍深度学习"可能偏离实际需求

三、幻觉评测数据

清华大学团队在不同维度上测试了主流大模型的幻觉率。

通用提示语测试（100 条，模拟普通用户）

模型	幻觉率
DeepSeek V3	2%
DeepSeek R1	3%
Qianwen 2.5-Max	2%
豆包	0%

事实性幻觉测试（300 道，涵盖健康/科学/历史/文化/音乐）

模型	幻觉率
DeepSeek V3	29.67%
Qianwen 2.5-Max	27.67%
DeepSeek R1	22.33%
豆包	19%

排名：V3 > Qianwen > R1 > 豆包。通用提示下幻觉率仅在 0–3%，但事实性测试中飙升至 19–30%——说明模型在日常对话中表现可靠，但在需要精确知识时风险显著上升。

幻觉类型分类

常识错误：歌词出处混淆（将《北京有个金太阳》说成《阿佤人民唱新歌》）
逻辑陷阱：见钱眼开的人为何被金钱蒙住双眼
虚构事件：李逵大闹五台山（实际是鲁智深）

四、推理与幻觉的双向关系

推理能力的增强对幻觉率存在双向作用：既能降低某些类型的错误，也可能在某些场景下增加虚构。

推理增强 → 幻觉率降低

逻辑准确性与错误减少：多步推理能力减少臆测
上下文理解与信息关联：精准捕捉上下文，避免断章取义

推理增强 → 幻觉率增加

逻辑过度外推：在已知事实间建立"超合理"的虚构连接（已知发明 A 技术→自动补全获诺贝尔奖）
认知置信度错位：高推理模型生成符合概率分布的"自信错误"
错误前提下的正确推理：初始假设错误，但基于此展开正确推理

Vectara 数据（摘要任务）

模型	幻觉率
DeepSeek V3	3.9%
DeepSeek R1	14.3%

推理模型在摘要任务中幻觉率显著更高——R1 的幻觉率是 V3 的 3.7 倍。这意味着推理链越长，模型在重构信息时越容易引入虚构内容。

五、普通用户应对 AI 幻觉的三种方式

方式 1：联网搜索

联网搜索对降低幻觉率效果显著：

模型	通用幻觉率	事实性幻觉率
DeepSeek V3	2% → 0%	29.67% → 24.67%
DeepSeek R1	3% → 0%	22.33% → 19%

通用幻觉可降至 0%，事实性幻觉率也有 5–10 个百分点的改善。

方式 2：双 AI 验证

用一个模型生成答案，再用另一个模型审查，进行交叉验证。这种方法不依赖外部数据源，但能有效捕获单模型产生的明显事实错误。

方式 3：提示词工程

A. 知识边界限定

技术	说明	示例
时间锚定法	用时间维度规避虚构	"基于 2023 年之前的公开学术文献，分步骤解释量子纠缠现象"
知识锚定法	限定权威来源	"基于《中国药典》回答，若不明确请注明'暂无可靠数据支持'"
领域限定符	添加专业身份限定	"作为临床医学专家，请列举 FDA 批准的 5 种糖尿病药物"
置信度声明	减少绝对化断言	"如果存在不确定性，请用[推测]标签标注相关陈述"
上下文嵌入	嵌入权威数据片段	"根据《2024 全球能源转型报告》显示…请基于此数据分析…"
生成参数控制	降低随机性	"请以 temperature=0.3 的严谨模式…"

B. 对抗性提示（大模型自审查）

技术	说明	示例
反幻觉检测	强制暴露推理脆弱点	"请用格式回答：主要答案 + [反事实检查]列出可能导致错误的 3 种假设"
预设验证条件	迫使模型交叉检查	"请先回答问题，然后从 3 个角度验证答案可靠性"
链式验证	四步验证链	①陈述观点 → ②列出三个权威数据源 → ③检查矛盾 → ④最终结论（标注可信度）

六、幻觉高发场景风险矩阵

场景类别	风险等级	防护建议
未来事件预测	极高	声明预测性质 + 概率分布呈现
医疗诊断	极高	明确非专业建议 + 医疗数据库
金融预测	极高	风险提示 + 历史回报率说明
安慰性回应（重症患者）	极高	情感剥离响应 + 理论应用提示
数学证明延伸（未解决猜想）	极高	中断机制 + 当前研究进展说明
开放域生成	高	创作范围限制 + 事实性标注
多跳推理	高	分步验证 + 外部知识库检索
复杂业务流程咨询	高	对话历史摘要 + 关键事实复核
长文本生成	中	阶段一致性检查 + 人物属性维护
矛盾数据源	中	矛盾点对比 + 最新研究成果优先

七、技术层面应对方案

RAG 框架：检索增强生成，先搜索权威数据库再生成答案
外部知识库：结合外部知识库，砍通用知识，强化垂直领域
精细训练：针对不同任务类型进行微调或强化学习
评估工具：开发自动化幻觉识别工具

八、AI 幻觉的创造力价值

"AI 幻觉像一面棱镜，既折射出技术的局限性，也投射出超越人类想象的可能。"——DeepSeek R1

领域	案例
蛋白质设计	大卫·贝克团队利用 AI"错误折叠"启发新型蛋白质结构，获 2024 诺贝尔化学奖
文艺设计	"超现实引擎"，突破人类思维定式
游戏娱乐	虚拟环境、角色设计、故事创作
自动驾驶	DeepMind 发现图像分割中的"超现实边界"提升极端天气识别精度
科研新范式	"AI 幻觉 → 实验验证 → 理论重构"三阶段研究流程

九、总结

AI 幻觉并非需要彻底消除的缺陷，而是需要理解和管理的一体两面。有效的应对策略可以归纳为：

三角验证法：交叉比对多个 AI 回答或权威来源
警惕"过度合理"：越细节丰富的回答越需谨慎（如 AI 虚构论文标题与作者）
场景优先：判断场景风险等级（参照风险矩阵），选择对应防护策略
工具前置：优先联网搜索（通用幻觉可降至 0%），再叠加知识边界限定
模型选型：R1 在摘要任务中幻觉率高于 V3（14.3% vs 3.9%），摘要类任务慎用推理模型

理解幻觉，才能有效使用 AI。在需要精确性的场景中，做好约束与验证；在需要创意的场景中，可以有条件地利用幻觉带来的意外发现。

本文数据来源：清华大学人工智能学院 / 新闻与传播学院新媒体研究中心，张家铖博士后，2025 年 2 月。

把 AI Agent 当成操作系统，而不是聊天工具

Mon, 20 Jul 2026 00:00:00 GMT

大多数人使用 AI，仍停留在“问一句、答一句”的阶段。这种方式适合快速获取答案，却无法积累稳定的工作能力：下一次对话要重新解释背景，做过的事情无法复用，复杂任务也很难验证。

可以把 Agent 看成一个轻量的操作系统。模型只是推理核心；真正让系统持续工作的，是外围的几个层次。

四层结构

1. 上下文：让 Agent 知道正在解决什么

上下文不等于把所有资料塞进对话。有效的上下文应当包含：当前目标、必要约束、已有结论、可用工具和下一步的验证标准。

过量上下文会让重点稀释，过少又会导致反复解释。一个实用原则是：注入索引，不注入仓库；按需展开，不一次全读。

2. 记忆：区分事实、流程与临时状态

记忆最容易失控。把所有内容都写入长期记忆，最终只会得到一份过期、冗长、互相矛盾的说明书。

信息按生命周期可以这样划分：

稳定事实：环境、偏好、长期约束；适合长期保存。
可复用流程：多次出现且可验证的操作方法；适合沉淀成 Skill。
任务进度：当前分支、临时文件、一次性结论；留在会话或项目记录中。

这不是文档分类游戏，而是降低未来判断成本的机制。

3. Skill：把经验变成可执行的能力边界

一段说明文字并不会自动变成能力。一个可用的 Skill 至少需要回答：何时触发、需要什么输入、做哪些步骤、如何验证结果、哪些场景不适用。

例如“部署一个服务”太宽泛；“在 Windows 上以隔离 Python 虚拟环境部署某个服务，并在端口探测通过后验证首页”才是可操作的流程。

4. 工具与验证：输出不等于完成

Agent 最危险的失败方式，是给出看起来合理但从未执行过的结果。因此，工具调用应该有边界，交付应该有证据。

实际交付时，一项工作至少应有一种可重复验证：构建日志、测试结果、接口响应、文件存在性、页面截图或可访问链接。没有验证的“完成”，只能算假设。

一个实用的工作顺序

一个可以参考的工作顺序：

先确认目标与限制；
读取最少量的真实信息；
选择已有 Skill，或拆出可验证的子任务；
在写入、删除、发布前停下来确认影响范围；
用真实输出收尾，而不是用一段总结收尾。

模型能力会继续进步，但这套结构不会很快过时。它解决的不是“怎么让 Agent 显得更聪明”，而是“怎么让它在多轮、多天、多项目之后仍然可靠”。

上下文工程的核心，是管理信息预算

Sun, 19 Jul 2026 00:00:00 GMT

上下文窗口越来越长，很多人自然会得出一个结论：既然能装下更多内容，那就把所有资料、日志和历史对话都塞进去。

实践中，这往往适得其反。

长上下文解决的是容量问题，不自动解决注意力问题。模型仍然需要从输入中判断什么重要、什么过期、什么彼此矛盾。当无关资料持续累积，真正关键的约束反而会被淹没。

把上下文当作预算

上下文可以看成一笔有限预算，而不是仓库。每一段内容进入窗口前，都应该回答一个问题：它会改变这一步的决策吗？

如果不会，先不要放进去。

这条原则会带来三个动作。

保留“决策记录”，而不是完整过程

一个任务进行了二十轮讨论，不代表第二十一轮需要读取全部二十轮。通常真正需要保留的是：

已确认的目标与禁止项；
已验证的事实与证据位置；
关键取舍及原因；
当前未解决问题和下一步。

这类信息应该被压缩成短小、可追溯的 handoff，而不是复制整段聊天记录。

用检索代替常驻注入

环境文档、项目资料、历史会议纪要可以存在外部知识库中。需要时检索相关片段，而不是默认注入全部。

这种做法的收益很直接：减少噪声、降低成本、让信息更新只发生在一个来源。对于不断变化的项目资料尤其重要。

在任务边界主动“清场”

任务切换时，旧任务的临时细节不应继续占用新任务的注意力。一个好的阶段交接应当把旧上下文压缩成结论，并让新任务从明确的起点开始。

一个检查清单

每次准备给 Agent 加更多上下文时，可以检查：

这段内容是事实、约束、证据还是纯背景？
它是否与当前步骤直接相关？
是否有更短的摘要或可检索的原始出处？
它是否已经过期，或可能与新事实冲突？
如果删除它，当前决策会不会改变？

最后一问最有效。答案是否定的内容，通常不值得占用窗口。

上下文工程不是“塞更多”，而是“留下更少但更有用的东西”。

Vibe Coding 不是随意编程，而是更严格地表达意图

Sat, 18 Jul 2026 00:00:00 GMT

Vibe Coding 常被描述成“用自然语言写程序”。这句话只说对了一半。

自然语言确实降低了直接操作代码的门槛，但它没有消灭工程复杂度，只是把复杂度从语法层转移到了意图、约束与验证层。如果需求说不清楚，AI 只会更快地产生更多不确定的代码。

从“怎么做”转向“要什么”

传统开发里，开发者会先把需求翻译成接口、数据结构和函数调用。AI 编程把这层翻译交给模型，于是人的工作重心变成：说清楚结果、边界与验收方式。

一个模糊请求是：

做一个好看的博客。

一个可执行请求是：

用 Astro 搭建可部署到 GitHub Pages 的中文博客；文章来自 Markdown；深色、单栏、内容优先；保留项目页；构建和移动端都要验证。

差别不是措辞漂亮，而是后者包含了技术选择、范围、视觉方向和验收条件。

小步推进，比一次性许愿可靠

AI 编程可以拆成四个小循环：

观察：读取现有结构和真实约束；
设计：明确本次要改变的最小范围；
实现：只改与目标相关的文件；
验证：运行构建、测试或实际页面。

每一轮只推进一个可验证的切片。这样即便模型理解偏了，也能很快止损，而不是在数千行改动后才发现方向错误。

需要提前说出的边界

AI 最容易在未被约束时“自作主张”。因此下面几类信息应该前置：

哪些文件或功能不能动；
是否允许增加依赖；
是否涉及删除、覆盖、发布；
哪些视觉元素必须保留；
什么才算完成。

这也是为什么 Vibe Coding 的关键能力不是提示词花样，而是产品判断力：你得知道什么值得做，什么不该做，以及如何判断它做对了。

最后仍要回到工程基本功

AI 可以写出实现，但不能替你承担上线后的维护成本。依赖是否必要、边界是否清晰、错误是否可恢复、变更是否可回滚，这些问题仍然需要工程判断。

好的 Vibe Coding，不是放弃结构；恰恰相反，是用更少的代码操作，换取对结构更高的要求。

学习大型代码库：不要通读，先建立地图

Fri, 17 Jul 2026 00:00:00 GMT

拿到一个大型开源项目时，很多人的第一反应是从目录第一个文件开始读。这个方法看似勤奋，实际效率很低：读了大量局部实现后，仍然不知道系统如何启动、状态如何流动、最关键的抽象在哪里。

更好的方法是先建立地图，再挑核心路径精读。

第一步：先验证项目是否可信

在投入时间前，先看几个基础信号：

是否有明确的依赖清单，例如 package.json、Cargo.toml 或 pom.xml；
是否有 README、许可证和版本控制痕迹；
是否存在锁文件与测试目录；
入口脚本和构建脚本是否能对应起来。

这一步并不保证项目安全，但能快速发现不完整 dump、伪源码或无法复现的资料。

第二步：只扫顶层，不钻细节

先获得这些信息：目录树两层、主要语言、最大文件、配置入口、构建命令、测试命令。

目标不是理解代码，而是知道系统的边界。比如一个 Web 项目通常会有入口、路由、状态管理、数据访问和 UI 五类区域；一个 Agent 项目则常见主循环、工具层、记忆层、模型适配层和权限层。

第三步：挑 5 到 7 个文件精读

优先级一般是：

程序入口和主循环；
最核心的抽象或接口；
状态机、任务调度或数据流；
外部通信和持久化；
最重要的一个业务子系统。

不要一开始读工具函数、图标组件或零散配置。它们重要，但通常不能解释系统的骨架。

第四步：每读一处，都记录“为什么”

笔记不应只是代码摘抄。每个核心文件可以记录：职责、输入输出、依赖关系、失败方式，以及它与其他模块的连接点。

当这些笔记串起来时，代码库会从文件集合变成一张可讨论的架构图。

大型代码库的学习，本质不是阅读速度竞赛。关键是先定位少数能解释全局的杠杆点，再向外扩展。

一个 Cloudflare 域名邮箱系统，应该怎样拆分职责

Thu, 16 Jul 2026 00:00:00 GMT

域名邮箱是一个很适合练习 Serverless 架构边界的场景：它同时涉及 HTTP 服务、邮件接收、数据持久化、认证、静态前端和第三方发信。

研究 Cloud Mail 时最有价值的不是某个部署命令，而是职责拆分。

组件各做一件事

一个简化的架构可以这样划分：

Email Routing：接收域名邮件，并把事件交给 Worker；
Worker：处理 HTTP 请求、邮件事件和权限校验；
D1：保存需要查询、关联和长期保留的数据，例如邮件元数据、账号和设置；
KV：保存适合键值访问的短期状态和缓存；
R2：保存体积较大的附件或媒体；
第三方发信服务：承担向外投递邮件的能力。

这个划分的重点是：不要把 KV 当成通用数据库。KV 的读性能很好，但高频写入会受到额度和一致性模式的约束。长期记录、计数和可查询业务数据，更适合进入 D1。

一条邮件的流动路径

入站邮件通常是：DNS/MX → 邮件路由 → Worker 邮件处理器 → 元数据写入 D1 → 附件进入对象存储 → 前端通过 Worker 查询。

出站邮件则是：用户操作 → Worker 鉴权与限流 → 写入发送记录 → 调用发信服务 → 接收状态回调。

把入站和出站分开理解，会更容易设计错误重试、配额控制和日志追踪。

应优先防的三个问题

高写入频率

每日计数、登录状态或轮询结果如果每次都写 KV，很容易消耗掉免费额度。应该通过批量、缓存窗口或迁移到更适合的存储来控制写入。

凭证泄漏

邮件服务会接触 API Key、域名配置和用户身份信息。它们只应存在于平台 secret 或本地环境变量中，不能写入仓库、文档或客户端代码。

处理失败不可追踪

邮件事件天生异步。至少应保留可关联的事件 ID、状态和错误摘要，避免用户只看到“发送失败”却无法定位发生在哪一层。

Serverless 的优势不是“没有服务器”，而是让每个组件的职责和成本更透明。前提是你不要用一个存储或一个 Worker 硬塞所有事情。

用 AI 写中文：先保护信息，再谈“去 AI 味”

Wed, 15 Jul 2026 00:00:00 GMT

“去 AI 味”正在变成一个流行需求，但它也很容易被误解成：把句子改得口语化，删掉结构词，再加一点情绪。

对于技术写作、工作汇报和公开文章而言，这远远不够，甚至有风险。文字变自然的同时，路径、数字、命令、引用和责任主体也可能被悄悄改坏。

写作流程应该有顺序

更可靠的顺序是下面四层，而不是一上来就做语言润色。

1. 保真层

先锁住不能变的内容：事实、数字、专有名词、文件路径、命令、日期、责任主体和来源链接。它们是文章的骨架。

2. 结构层

检查文章是否真的回答了问题。很多“AI 味”并非来自某个词，而是来自先抛大话、后给空泛总结的结构。把结论放前面，用具体过程支撑，通常比替换形容词有效。

3. 语言层

这一层才处理模板化转折、堆叠的形容词、无意义的“值得注意的是”，以及看似完整却没有信息量的结尾。

中文的自然感来自准确的动词、恰当的停顿和明确的对象，不来自刻意模仿口语。

4. 场景层

聊天、项目状态、内部文档和公开长文需要的改写强度不同。聊天可以简短；公开文章需要保留论证；技术文档则应优先可执行性。

一个简单的验收标准

完成润色后，可以用四个问题验收：

原有事实有没有丢失或被改写？
读者能否在一分钟内说出文章结论？
每一段是否提供了新信息？
把“漂亮句子”删掉后，文章还能成立吗？

如果最后一问答案是否定的，说明文章可能只有语气，没有内容。

AI 可以帮助整理和表达，但不应该替代作者对事实、结构和读者的负责。自然，是准确之后的事情。