最近一两年身边越来越多技术人开始用“智识的虚妄”这个词来形容当前的 AI 热潮。很多团队把大模型接进系统、嵌入流程、放到产品最显眼的位置换来的却是对话流畅、逻辑自洽但一追问细节就露馅的回答。这让我想起一个很尖锐的提问当 AI 说出的话越来越像人我们是不是误把语言的流畅当成了思考的深度这不是哲学问题而是每个做 AI 工程的人都要面对的工程问题。作为一个日常写代码、部署模型、调 prompt、排查幻觉的开发者的视角来看当前 AI 浪潮里有一种被普遍忽视的错位模型的生成能力在指数级提升但我们围绕它构建的验证、纠错、信任体系还停留在“它能说几句漂亮话”的阶段。真正危险的不是 AI 不够强而是我们把“像智慧的东西”当成了“智慧本身”。这篇文章想聊清楚一件事为什么 AI 目前带来的更多是智识的表象而不是智识本身以及我们这些做工程的人应该用什么样的技术手段去分辨这两者。全文不会只停留在观点层面会从自回归解码机制、幻觉成因、评测失真、编码实践、Agent 可靠性、知识管理这几个技术切面把“虚妄感”到底从哪来拆开来看。1. 真正的判断AI 带来的是智慧的表象不是智慧先给出一个明确的判断AI 大模型目前带来的是高度拟真的“智慧表现”而不是真正意义上的认知能力更准确说是一种“智慧的概念/自负/虚妄”。这里的虚妄不在于它说错了话而在于它用同样自信的口吻说对了和说错了的话从根本上瓦解了我们通过语言来判断可信度的本能。过去我们对一个回答者的信任很大程度上依赖语言本身的连贯性、细节的丰富性和逻辑的自洽性。一个人如果能条理清晰地解释一个复杂问题我们倾向于认为他“懂”。大模型把这条信任链条击穿了。它只用了“预测下一个词”这一个机制就制造出了比绝大多数人类书面表达更流畅、更结构化的文本。这带来一个工程上的必然后果输出质量与知识真实性之间开始脱钩。传统软件系统的输出要么正确要么报错错误是可检测的而 LLM 的输出总是看起来合理错误隐藏在合理性下面。这意味着凡是直接面向用户的 AI 功能如果缺少验证层本质上都在向用户输出不可控的概率文本。更麻烦的是这种虚妄具有传染性。当一个团队的代码、文档、设计稿里大量混入 AI 生成的内容而团队成员没有足够的领域知识去辨别时系统的信息质量会整体下滑。我们以为 AI 在帮我们积累知识资产实际上可能是在积累大量格式化、听起来合理但经不起推敲的文本负债。所以这篇文章真正想和读者达成的共识是应该把 LLM 当作一个“流利的陌生人”而不是“全知的专家”。它擅长的是生成符合语言规律的文本不是判断事实真假。工程上所有的接入方式都应该围绕这个前提设计。2. 为什么“会说话”不等于“会思考”——从自回归解码看起要理解 AI 的“虚妄感”从何而来得先看大语言模型最底层的生成机制。现在的 LLM 绝大多数采用自回归架构它的工作方式可以概括为一句话给定前面所有 token预测下一个 token 的概率分布然后采样一个出来反复执行。这就是全部。没有全局规划没有事实校验没有“我想表达什么”的意图。它只是一个极其复杂的高维条件概率模型在模拟“语言中下一个词最可能是什么”。我们用一个最小示例来回顾这一点。下面是一个简化版的自回归生成逻辑import random def generate_text(model, prompt, max_new_tokens100, temperature0.8): input_ids tokenizer.encode(prompt) for _ in range(max_new_tokens): # 模型根据已有的 token 序列计算下一个 token 的概率分布 logits model(input_ids) probs softmax(logits[-1] / temperature) # 按概率采样下一个 token而不是取最大概率 next_token random.choices( populationrange(probs.shape[0]), weightsprobs.tolist() )[0] input_ids.append(next_token) # 遇到结束符则停止 if next_token tokenizer.eos_token_id: break return tokenizer.decode(input_ids)这个例子把现代 LLM 的生成过程还原到了最朴素的形式。model内部可以有一个巨大的 Transformer经过了海量文本的预训练和人类反馈对齐但它在推理时做的每一件事仍然只是“根据前文算下一个词”。没有哪个环节在检查“这句话是否符合事实”也没有哪个环节在调用外部知识库。一切正确性都依赖于训练数据里是否恰好覆盖了类似的表达模式。这就是为什么 LLM 在数学推理、代码生成这类有明确规则的领域表现惊艳因为这类数据在训练集里存在大量高相似度样本语言规律本身包含了解题规律。但它在开放式事实问答、实时信息、专业判断这类依赖真实世界状态的场景里表现不稳定因为模型没有世界状态只有文本分布。理解这个机制之后很多现象就解释得通了为什么 LLM 会一本正经地编造引用因为它预测到“在某篇论文中研究者发现……”这句话在语言上很自然但它无法核实这篇论文是否存在。为什么 LLM 在同一个问题上有时候对有时候错因为采样过程带有随机性每次走的是概率空间里不同的路径。为什么 LLM 在长上下文里容易前后矛盾因为它的每一步都只关注“下一个词”缺少对整个生成内容的全局一致性约束。所以如果能在工程上记住一句话LLM 模仿的是“答话的形式”不是“答话的依据”。当我们看到一段结构工整、术语密集的输出时应该下意识地问一句它有引用来源吗来源可验证吗验证成本是多少这一套追问流程是抵御虚妄的第一道防线。3. 幻觉不是 Bug而是架构的影子“幻觉”是目前 AI 产品被吐槽最多的问题。很多团队把“减少幻觉”当成一个优化目标仿佛只要调参到位、提示词得当模型就能彻底摆脱幻觉。但如果我们从自回归机制的根源去想会发现一个更冷峻的事实幻觉不是可以被修复的缺陷而是这套架构在原理上的必然产物。原因很简单。模型在训练时学到的全部知识都来自文本里的共现关系。它不知道“杭州”和“浙江省会”之间存在真实世界的因果或行政关联只知道在语料里这两个词经常同时出现。当模型被问到某个生僻问题时如果训练语料中相关模式很少它会转向“语言上最顺”的路径用最常用的句式补充最可能出现的名词。而这个“最顺”的路径经常就是一本正经的编造。从概率角度看幻觉是模型在高熵区域采样时不可避免的结果。所谓高熵就是模型对下一个词没有足够的确定性。在低熵区域比如“11”下一个 token 的概率非常集中基本不会错在高熵区域比如“请介绍一下 XX 公司的历史”候选 token 的概率分布非常平坦采样出来什么样都很“合理”。工程上所有缓解幻觉的手段本质都是在做同一件事降低模型决策的熵值或者把高熵问题转移给外部系统。目前最通用、也被验证比较有效的方案有四种方案原理优点局限检索增强生成RAG先从知识库检索相关片段再让模型基于片段回答答案可溯源、可更新检索质量决定回答上限工具调用Function Calling模型不直接回答事实问题而是生成查询参数调用外部 API事实由外部系统保证需要可靠的工具链和解析层模型自我反思生成多轮候选答案让模型自行评估取舍简单有效可能“自信地坚持错误”约束解码生成时限定输出格式和领域范围从源头减少开放性无法解决开放域事实问题其中最常见的是 RAG。下面是一个典型的工程实现思路# 伪代码示例RAG 最小链路 def rag_answer(query, retriever, llm): # Step 1: 从向量库检索相关片段 docs retriever.top_k(query, k5) # Step 2: 构建带上下文的提示词 context \n\n.join(d[content] for d in docs) prompt f 请根据以下资料回答问题。如果资料中没有相关信息请明确回答资料中未提及。 资料 {context} 问题{query} # Step 3: 让模型基于上下文生成 return llm.generate(prompt)注意这段代码里最关键的不是调用 LLM 那一步而是提示词里的那句“如果资料中没有相关信息请明确回答资料中未提及”。这句话在把“模型自由发挥”的权限收窄把高熵问题转换成低熵问题模型不需要知道正确答案只需要判断资料里有没有然后做摘要。这比直接问模型“XX 是什么”要可靠得多。但 RAG 也不能彻底消除幻觉。如果检索到的资料本身和问题无关模型可能强行建立关联如果资料之间有矛盾模型可能会“和稀泥”如果用户问的问题在资料里完全没有对应内容模型仍然可能为了完成任务而编造。幻觉问题的本质是只要模型还在做文本补全它就有可能在没有任何依据的情况下补出“看起来合理”的内容。我们能做的是在系统层面增加校验层而不是指望模型自己变得诚实的概率越来越高。4. 评测分数的误导Benchmark 为什么在失真在 AI 行业里目前评测文化和模型能力之间出现了明显的错位。各家模型发布时伴随一长串 Benchmark 分数的提升但对于真正使用模型的工程师来说这些数字的意义越来越有限。核心原因有两个。第一个是训练数据污染。很多公开评测集在模型预训练阶段就被模型“读过”了。当模型已经见过题目和答案它的高分只是在做记忆复现而不是推理能力测试。最典型的案例是某些模型在 Math 类 Benchmark 上分数很高但在一道改过数字的简单应用题上就翻车。第二个原因是评测集本身窄化。当前的主流 Benchmark 集中在代码生成、数学推理、百科问答、多轮对话等维度。这些确实是重要能力但它们是“任务导向的语言能力”不是“面向真实生产的系统能力”。真实生产里的 AI 问题是这样的用户的问题有歧义需要追问澄清正确答案不在知识库里需要判断“不知道”并引导用户多个来源的信息互相矛盾需要识别冲突生成结果需要满足合规、品牌、安全约束结果是给下游系统用的格式错误比内容错误更致命。这些能力在 Benchmark 里几乎没有体现。一个模型可能 MMLU 分数极高但在真实客服场景里频繁触犯安全红线一个模型可能 HumanEval 通过率很高但生成的代码在真实项目里无法编译。反过来一个在 Benchmark 上“平庸”的模型如果配合好的检索层、验证层和落库策略可能在实际产品里表现更好。所以做 AI 工程的人应该建立这样一种评测观公开 Benchmark 分数只能说明模型的“语言潜力”不能说明系统的“交付能力”。更可靠的做法是针对自己的业务场景建设私有评测集采集真实用户问题、真实失败案例、真实生成结果用一套可自动化的脚本反复回归。下面这个脚本思路可以用于搭建私有评测流水线# 私有评测集回归脚本示例 import json def evaluate_system(system_fn, test_cases): total 0 passed 0 failures [] for case in test_cases: total 1 question case[question] expected case[expected] # 调用待测系统 actual system_fn(question) # 判定结果这里支持字符串包含或正则匹配 matched expected in actual if matched: passed 1 else: failures.append({ question: question, expected: expected, actual: actual }) return { total: total, passed: passed, pass_rate: passed / total, failures: failures } # 使用示例test_cases 需要结合业务数据人工标注 if __name__ __main__: with open(./test_cases.json, r, encodingutf-8) as f: test_cases json.load(f) result evaluate_system(my_system, test_cases) print(result[pass_rate])这套流程最大的价值不是跑出“98%通过率”而是把每一次模型升级都变成一个可审计的工程变更升级前跑一遍私有集升级后跑一遍私有集任何下降都能被发现而不是等上线后被用户投诉。私有评测集是抵御 benchmark 虚妄的工具。5. 编码场景里的虚妄生成得很快理解得很浅AI 编程是当前普及度最高的 AI 应用之一。从代码补全到整个文件生成从解释报错到自动重构AI 编程助手已经深度嵌入了很多开发者的日常工作。但这里也存在一种很典型的虚妄开发者以为 AI 在“理解”自己的代码实际上 AI 只是在做概率化的模式匹配。举个例子你让 AI 助手解释一段代码它给出的解释往往非常流畅包括“这段代码首先定义了一个函数然后使用了装饰器……”这种描述。但如果你追问为什么这里要用装饰器而不是直接调用如果去掉这个装饰器会有什么影响在高并发场景下这段代码有没有线程安全问题AI 很可能给出一段正确的“套话”但套话经不起真实项目的推敲。AI 编程的边界在哪里从实际工程经验看可以总结为三个层次擅长样板代码生成、常见设计模式实现、单元测试骨架、正则表达式、数据格式转换、简单脚本编写。这些任务在训练语料里有海量示例AI 生成的代码质量往往不错。勉强可用已有代码库内的重构、根据注释生成函数、错误日志解读。需要开发者仔细 review且上下文越长越容易引入隐性错误。不擅长系统架构设计、跨模块依赖分析、性能优化决策、安全边界设计、业务规则推演。这些任务需要全局理解力和价值判断AI 只靠代码文本无法获得这种能力。最大的工程陷阱在于AI 生成的代码语义正确但逻辑错误。所谓语义正确是指它写出来的代码语法完整、API 调用看起来合理所谓逻辑错误是指它在复杂条件分支、边界情况、状态管理上产生了隐藏 bug。这种 bug 在代码审查时很难被发现因为“看起来太规范了”。应对方案只有一个把 AI 生成内容当作一个需要 review的候选提交而不是一个可以直接合并的最终结果。在团队里推行明确的 AI 代码规范要求 AI 生成的代码必须经过人工审查关键模块必须补测试对生成代码的行数、复杂度做限制。下面是一个团队可以落地的 AI 代码审查规范示例# .ai-coding-rules.md ## AI 生成代码的提交要求 1. AI 生成的代码必须由提交者逐行 review禁止直接合并。 2. 涉及金额计算、权限校验、数据删除的代码禁止直接使用 AI 生成代码。 3. AI 生成代码需附带简要说明这段代码要解决什么问题为什么选择这个方案。 4. 若 AI 生成代码超过 50 行必须拆分为小函数并补充单元测试。 5. 所有 AI 生成的正则表达式必须至少包含正例和反例两组测试。 6. 不理解 AI 代码中的任何一行必须在合并前向同事请教或重写。这样的规范不是为了限制 AI 使用而是把 AI 的定位从“替代工程师”重新拉回“辅助工程师”。它承认 AI 生成能力的价值同时建立了一道人工判断的过滤网。工程上最危险的状态是开发者对自己不理解但 AI 生成的代码产生了盲目的信任这种信任会以极高的速度把错误传播到整个系统里。6. 知识管理里的 AI 熵信息变多了智慧变少了大模型带来一个挺反直觉的现象当 AI 生成内容大规模进入我们的文档库、知识库、代码仓库时信息的总量大幅增长但信息的质量反而在下降。我把它叫作“AI 熵”——信息熵上升有效信息密度下降。过去写一篇技术文档作者需要真的理解这个知识点再用自己的语言组织出来。这个过程有认知成本所以文档数量有限但每一篇都有作者思考过的痕迹。现在用 AI 写文档你只需要给一个标题AI 就能生成一篇结构和措辞都很规范的文档。问题在于如果作者自己没有深入理解他无法判断文档里哪些是对的、哪些是 AI 编造或泛化的。这种文档会进入团队的知识库被其他同事检索、引用进而被用来做技术决策。如果文档里有一个小错误它不会像代码错误那样在运行时暴露它会一直安静地躺在那里成为后续所有引用的“错误基座”。知识管理系统的信息越多这种错误基座越多整个系统的信息熵就越高。为了对抗这种“AI 熵”团队需要建立一套新的知识资产验收机制AI 生成的文档必须标注来源哪些部分是 AI 初稿、哪些部分是人工修订至少要让人知道这篇文档经过了哪些人的判断。技术决策类文档禁止纯 AI 生成架构决策、方案选型、安全审查这类文档必须由负责人亲自撰写AI 只能用来搜索资料和整理思路。定期清理低质量文档给知识库建一个“内容健康度”指标比如文档的被引用次数、最近更新时间、作者活跃度。长期没有被引用、没有更新的 AI 生成文档可以归档。更核心的思路是AI 应该用来辅助“思考的过程”而不是替代“思考的结果”。比如让 AI 生成一篇文章的提纲、收集相关的背景资料、把一个复杂问题拆成若干子问题这些是辅助思考让 AI 直接生成一段结论、一个方案、一份评审意见然后不经修改就发布这是替代思考。前者能提高智慧密度后者会稀释智慧密度。7. Agent 热潮里的“伪自主”工具调用不等于目标理解如果说 LLM 本身带来的只是“语言的虚妄”那么 Agent 概念被炒热之后这个虚妄又升级了一层AI Agent 看起来在自主规划、自主决策、自主执行但它的“自主”更多是流程上的自动而不是目标上的理解。一个典型的 Agent 执行链是这样的用户给出目标Agent 把目标拆成多个步骤每一步调用工具搜索、代码执行、API 调用把结果反馈给模型模型再决定下一步动作。从外部看这个过程像是一个有规划能力的智能体在完成一个任务。但从内部机制看它仍然是在做“下一步最可能做什么”的文本预测只是预测的元素从“词”变成了“动作或工具调用”。这里有一个工程上的关键问题模型对“如何调用工具”的建模远比对“为什么需要这个工具”的理解要可靠。换句话说Agent 可以通过训练学会“遇到数学题时调用计算器”但它在“为什么这道题需要计算器”和“计算器返回的结果是否可信”这两件事上仍然是模糊的。这会导致几类典型故障规划链路的错误累积前面一个步骤的工具调用参数错了后面所有步骤都基于错误结果继续执行Agent 却没有判断“中间结果是否合理”的能力。工具选择的表面化模型可能根据工具名字猜测用途把一个需要数据库查询的任务错误地路由到一个搜索引擎工具上。终止条件的缺失Agent 可能在找到答案后继续执行无关步骤也可能在错误路径上反复循环无法自己判断“我已经完成了”。所以在落地 Agent 的时候工程上比模型选择更重要的是自主性边界设计。不能一开始就做一个完全自主的 Agent让它直接操作生产环境。合理的路径是分阶段放开权限第一阶段Agent 只做“推荐”不直接执行。它生成步骤建议和工具调用参数由人来确认再执行。 第二阶段Agent 可以在沙箱环境执行所有动作记录日志结果经过验证模块检查。 第三阶段在准确率、日志、回滚机制足够成熟后允许 Agent 在低风险场景下自主执行。这里可以给一个 Agent 安全执行的工程样例# Agent 动作执行前的安全检查示例 class AgentSafetyPolicy: def check_action(self, action): # 规则 1禁用的动作类型 if action.type in [delete_database, drop_table, rm_rf]: return False, 该动作在生产环境被禁止 # 规则 2只能在白名单环境中执行 if action.env not in [sandbox, staging]: return False, f环境 {action.env} 不在执行白名单中 # 规则 3高风险命令必须人工审批 if action.risk_level high: return False, 高风险动作需要人工审批 # 规则 4可回滚检查 if not action.rollback_plan: return False, 缺少回滚方案禁止执行 return True, 允许执行这套策略的本质是把 Agent 从“自主个体”降级为“需要审批的执行工具”。这个定位可能不够性感但它是当前模型能力下最稳妥的工程姿态。“自主”应该体现在它能把重复性工作自动化而不是体现在它有权做不可逆的重大决策。8. 工程上如何对抗虚妄可验证性、最小权限、人机边界聊了这么多问题最终要落到一个更积极的层面上作为工程师我们不是只能被动接受 AI 的虚妄我们可以通过系统设计主动对抗它。对抗的核心原则有三条可验证性、最小权限、人机边界。可验证性是指 AI 系统的每一个输出都应该有验证手段。要么是自动化的测试用例要么是可供用户核对的来源引用要么是输出格式上的强约束。如果一个 AI 功能的输出无法验证它就不应该被用于任何有后果的决策。检索增强、约束解码、私有评测集都是可验证性的具体实现。最小权限是指在设计 AI 系统的时候默认不信任模型的能力边界只给它完成当前任务所需的最小权限。能读的不要给写权限能访问片段数据的不要给全库权限能在沙箱运行的不要给生产环境权限。这个原则在 Agent 场景里尤其重要因为我们无法预测模型在长链路任务中会做出什么决策只能在权限层面加一道保险。人机边界是指明确划分哪些环节由 AI 独立完成哪些环节必须有人参与。从工程实践看AI 独立完成的环节应该具备“错误可检测、后果可回滚”的特性比如代码补全、文本润色、数据格式转换需要人参与的环节应该是“高影响、低容错、需要价值判断”的比如架构方案选择、安全策略制定、对外发布内容审核。下面是一个团队可以落地的人机边界示例表环节建议的 AI 参与程度理由生成代码草稿AI 辅助人工 review错误可在代码审查和测试中被发现生成架构方案人工主导AI 仅做资料收集架构决策影响面大需要全局判断知识库内容生成AI 初稿人工修订后入库错误会随文档传播需要人工背书客服自动回复AI 生成规则引擎过滤敏感词需要多重校验才能面向用户生产环境变更禁止 AI 直接操作不可逆操作必须人工执行并备份这套边界会随着模型能力的提升而变化但原则不变AI 能接手的是“错误成本低”的环节人必须守住的是“错误成本高”的环节。谁的错误成本高谁就应该保留最终决定权。9. 回到本质智慧到底缺了什么如果只是把问题停在“AI 不靠谱、大家要小心”这篇文章就没多大价值了。更值得追问的是如果我们承认 AI 带来的是“智识的虚妄”那么真正的智慧到底缺了哪几块这个问题的答案恰恰可以指导我们未来做 AI 工程的方向。从技术机制上看真正的智慧至少包含几个当前 LLM 架构尚不具备的要素。第一是世界状态感知。人在做判断时会不断感知现实世界的反馈这一招有没有生效客户有没有满意系统有没有崩溃。当前 LLM 没有这种 feedback loop它只处理文本输入不感知文本之外的现实变化。真正的智能系统应该把模型放在一个能持续接收世界反馈的闭环里而不是让它一次性生成最终答案。第二是可信度建模。人知道自己在某个领域是专家、在另一个领域是新手所以会在不确定的时候谨慎表达。当前 LLM 做不到这一点它对所有问题都采用相似的语气输出无法基于真实能力边界调节确定度。工程上可以通过校准训练、提示词约束、置信度过滤来部分模拟这个过程但距离真正的“知道自己不知道”还有很大差距。第三是目标理解与价值权衡。人做决策时不仅考虑“怎么做”还考虑“该不该做”“做了之后对谁有什么影响”。LLM 没有真实的价值观它的“价值”来自训练文本里隐含的社会共识分布遇到复杂伦理场景时只会输出语料里的立场平均。真正需要智慧的场景恰恰是这种价值冲突的场景而这不是语言模型能解决的。所以关于“AI 是否带来了智慧”这个问题比较诚实的回答是AI 带来了智慧的拟真物它以极高的效率模仿了智慧的表达形式但缺乏智慧赖以成立的世界感知、自我校准和判断力。这不是否定 AI 的价值而是把它的价值放在正确的位置上——它是一种强大的生成工具、流程引擎和知识组织器但它不是一种新的智慧形态。对我们这些实践者来说这个认识非常重要。它决定了我们在接受 AI 的时候是在接受一个可以分担重复劳动的同事还是在接受一个可以托付关键决策的权威。把它当工具我们会把工具用到极致把它当权威我们会在它虚妄的语言迷宫里慢慢失去自己的判断力。这也是整个 AI 时代工程师最需要守住的一条底线。