1965年哲学家Hubert Dreyfus写了一份后来很有名的报告《Alchemy and AI》。这份报告不是教人怎么搭模型也不是介绍某个框架而是直接质疑当时AI研究的主流路线把智能问题当成一个可以快速攻克的工程问题结果做出很多看起来很厉害、实际上经不起推敲的系统。今天再看这份报告我觉得它最值得关注的地方不是“Dreyfus对不对”而是它提供了一套判断AI项目是否靠谱的思考方式。如果你最近在研究AI Agent、AI编程、AI模型部署或者正在用Cursor、Spring AI这类工具做应用这篇内容可以帮你把项目里的虚火挑出来。为什么现在还要提一份1965年的报告因为AI技术变了但“看起来能行”和“真的能落地”之间的落差没有变。Dreyfus当年说AI研究像炼金术这句话放到今天依然可以拿来检验很多项目。看到“跑通了”“效果好”“智能体已经能自主完成任务”这些描述时先别急着兴奋先问一句验证条件是什么失败边界在哪里这篇文章会把Dreyfus的判断翻译成一套现代AI工程里可以落地的检查方法。1. 一份1965年的报告为什么今天还要读它1.1 它到底在批评什么Dreyfus在报告里提出一个很尖锐的类比当时的AI研究就像中世纪炼金术。炼金术士目标宏大想点石成金想找到长生不老药听起来比普通化学高尚得多。但实际操作上实验记录往往孤例拼凑既没有统一的理论框架也没有可重复的实验规范。一次偶然成功会被放大成突破大量失败被轻轻带过。Dreyfus认为1965年前后的AI研究也有这种味道用几个经过挑选的例子演示程序能“下棋”“解谜”“证明定理”就急着宣布已经找到了智能的核心机制。要理解这个批评需要先知道当时的AI环境。二十世纪五十年代末到六十年代中期计算机刚刚从纯粹的计算工具走向符号处理。研究者发现计算机不仅能做算术还能处理符号、匹配规则、逻辑推理。这个发现催生了很多乐观判断只要把人类知识编码成规则再交给计算机去搜索和匹配就可能造出通用人工智能。于是出现了大量“玩具问题”程序在特定棋盘上下棋、在特定迷宫找出口、做简单的逻辑归约。这些程序在演示时确实能运行但换一个环境、换一组输入往往就失效。Dreyfus自己是一个哲学家不是程序员。他的质疑角度不是“程序跑不通”而是“问题定义错了”。他提出人类智能大量依赖身体经验、情境感知和隐性常识这些内容不是靠几千条规则能编码出来的。比如你看见一杯水快洒了会本能地伸手扶一下这个动作背后涉及空间判断、物体重量估计、对液体行为的预期写进规则会非常复杂而且不同场景规则互相冲突。当时AI研究普遍低估了这种“常识”的难度。1.2 炼金术这个类比为什么扎心炼金术的问题不在于目标错误而在于方法不科学。它没有系统的理论框架没有可重复的实验规范也没有对失败案例的严肃分析。AI研究如果只追求“能不能跑出效果”而不追问“为什么有效、什么时候失效、怎么验证”就会滑向炼金术。我第一次读这篇报告的时候印象最深的不是哲学论证而是它对“演示成功”的警惕。Dreyfus明确提醒一个系统能运行和它真的解决了问题是两回事。把这句话记在心里再看今天很多AI项目会非常有帮助。一个模型能在某个公开榜单上排前面不一定代表它适合你的业务一个Agent能在演示视频里完成“帮我订餐厅”的流程不一定代表它能在你的真实数据上稳定跑通。演示是单点工程是面上覆盖。这里要稍微平衡一下不是要否定当时的AI研究。没有那些早期探索也不会有今天的深度学习。但Dreyfus的价值在于他迫使研究者回答一个经常被跳过的问题你凭什么说你已经解决了智能问题这个问题到现在依然有效只是问法变成了“你凭什么说这个模型在你的业务场景里可靠”。1.3 报告后来变成了什么这份报告的内容后来被Dreyfus继续扩展最终发展成一本书核心观点延续了“炼金术”的批评。对于非哲学背景的读者来说读报告原文不一定轻松因为里面有不少现象学和存在主义的讨论。但核心思想非常清晰不要被演示成功冲昏头脑。从技术发展史来看这份报告在当时属于“少数派”。主流AI圈很多人并不认同Dreyfus的判断觉得他不了解计算机也不了解进展速度。但后来AI经历过几次寒冬很多早期承诺没有按期兑现这份报告反而被反复提起。今天我们读它不是为了站队而是为了借它训练一种习惯看到AI能力展示时先区分“这是产品能力”还是“这是某个特定条件下的实验结果”。2. Dreyfus眼里的AI和今天的AI有什么不同2.1 当时AI的主流假设当时的主流思路可以概括成把知识表示成规则把推理变成符号操作。只要规则库足够大、搜索策略足够好计算机就能表现出智能。这个思路在逻辑推理、棋类游戏等领域确实有进展但一旦遇到日常场景比如理解一句带歧义的话、判断一个物体是否适合抓取就立刻失效。这种路线后来被称为符号主义。它的优点是精确、可解释、逻辑性强缺点是知识获取极其困难规则边界很难维护。为了让程序在某个任务上表现好研究者往往要手工写大量特设规则这些规则只在该任务里成立。这正好呼应Dreyfus说的“炼金术”看起来在追求普遍智能实际上每个演示都是一堆特设技巧的堆叠。Dreyfus认为人类智能不是这样工作的。人在大多数情况下不是靠规则推理而是靠大量“当然如此”的直觉反应。你走进一个房间不需要逐条分析门的位置、桌椅摆放、地面材质就能自然找到可以坐的地方。这种能力来自身体经验而不是符号规则。因此他认为AI研究只靠形式化符号处理走不到真正的智能。2.2 今天看似不同其实仍踩同一条线今天的大模型走的是另一条路不写规则靠海量数据训练出参数。表面上差别很大但实际上很多项目仍然默认“只要数据够多、模型够大能力就会自然涌现”。于是出现了一种新的乐观什么任务都往里塞遇到效果不好就加数据、加算力、加Prompt技巧。这种做法不是完全没道理机器学习本来就需要大量数据和算力。但它和Dreyfus批评的炼金术有一个共同点缺乏对能力边界的严肃审视。模型能生成一段看起来合理的文本不代表它理解这句话的含义能通过几个测试用例不代表它能处理长尾场景。如果你把“测试通过”当成“能力成立”很容易在项目上线后踩到AI幻觉的坑。另外还要注意一个区别Dreyfus当时批评的是“把智能问题当成符号处理问题”今天很多系统确实能在具体任务上做得很好比如OCR、翻译、摘要、代码生成。所以不能简单把Dreyfus的描述套到今天说“AI不可能成功”。更合适的读法是他提醒我们每一个AI系统都要明确自己的适用范围。超出范围系统很可能给你一个流畅但错误的答案。2.3 从符号规则到神经网络改变的是什么神经网络和深度学习改变了知识获取方式。以前是人写规则现在是机器从数据里学。这个改变很关键它让AI在图像识别、自然语言处理等领域获得了真正的突破。但随之而来的是新的“炼金术”风险模型内部变成黑盒解释性变差评估难度变大。过去符号系统失败时你可以打开规则库看看是哪里写错了。现在你很难说清楚一个大模型为什么在这个输入上成功、在那个输入上失败。能做的只有两件事扩大测试覆盖范围建立更严密的验收闭环。如果你不这样做就会退回到Dreyfus批评的状态只看到了几个成功案例就相信整个系统是可靠的。所以从符号规则到神经网络改变的是技术路线没有改变的是工程要求任何一个AI系统都必须有明确定义的任务、输入、输出、测试集和失败处理机制。没有这些再新的架构也只是一个更复杂的实验室演示。3. 从“Alchemy and AI”到AI工程怎么避免做出炼金术项目3.1 把“能力”翻译成“可验证任务”做AI应用开发第一件事不是选模型而是把“能力”拆成“任务”。比如“让AI写周报”不是一个可验证任务“把本周的5条工作日志转成一段200字左右的周报并保留关键数据”才是。差异在于后者有明确的输入格式、输出格式、关键信息保留标准。这一步看起来简单实际上能筛掉很多不靠谱需求。如果你的需求方说“AI要能理解用户意图”你要追问理解的输入是什么理解的输出是什么判断理解正确的标准是什么如果答不上来这个需求还停留在口号阶段。我们经常看到“AI测试”这个词。但测试的前提是任务定义明确。没有固定的输入范围没有可接受的输出标准测试集就无从谈起。Dreyfus报告里那句“看起来能行”和“真的能行”的区别对应的工程操作就是定义输入范围定义输出格式定义测试集。没有测试集就没有资格谈能力。3.2 先跑最小样例再谈批量很多人一上来就开最大并发、处理整批文件结果出了问题都不知道是模型的问题还是自己代码的问题。我一般会先把流程拆成三步单条输入、单条输出连续5到10条输入观察稳定性最后才上批量。这个顺序看起来慢其实最快。因为批量任务一旦出错你还要面对日志混杂、输出命名混乱、失败重试逻辑不全等问题。先跑通一条再跑通一小批才能把“模型效果”和“工程稳定性”分开排查。在模型选择上我也建议不要一上来就选最大的模型。现在的模型服务很丰富有本地部署的开源模型也有各种API。先用手头最容易获取的模型把整条流程跑通再根据效果决定是否换更大模型。这样做的好处是流程里涉及的数据读取、提示词构造、结果解析、异常处理这些工程问题不会依赖具体模型。换模型时只需要改调用层不需要重写业务逻辑。3.3 定义成功标准别用感觉验收另一个常见问题是验收标准太模糊。“效果不错”“看起来挺自然”这种话在项目里没有意义。靠谱的做法是定义几个可量化指标成功率多少条输入得到了可接受输出。格式合规率输出是否符合JSON、表格、固定模板等要求。关键信息保留率比如转写、摘要任务里核心实体是否还在。失败可重试性出错时能否自动重试还是需要人工介入。这组指标不复杂但能让你在“感觉很好”和“实际可用”之间建立一道闸门。我见过一个团队做客服摘要模型的文字非常流畅但经常把客户提出的“退款金额”漏掉。如果只读摘要文本会觉得“挺好”一旦把关键信息抽出来核对问题立刻暴露。所以我会建议在输出阶段加一层结构化解析把摘要里的金额、日期、诉求单独提出来做校验。这一步不是模型能力问题是工程问题。3.4 AI工具选型别把工具当答案现在AI开发工具很多有Spring AI这类集成框架也有PyCharm、IDEA里的AI插件还有专门的AI编程工具。选型时容易犯的错误是把工具本身当成能力提升的全部。实际上工具解决的是“接入”问题模型解决的是“生成”问题工程解决的是“质量”问题。三者不能互相替代。比如你用Cursor辅助写代码它能帮你快速生成一个函数骨架但不会自动保证这段代码满足你的边界条件。你用Spring AI封装大模型调用它能帮你统一接口、管理上下文但不会自动帮你做好测试集和结果校验。工具的价值在于降低接入成本而不是替你做判断。判断能力边界、设计验证方案这些仍然是人的工作。4. AI Agent、AI编程、模型部署里的“炼金术”陷阱4.1 AI Agent链路越长越要分步验证AI Agent开发是这两年很热的方向。一个Agent通常要经历规划、调用工具、读取结果、再决策的循环。这个循环越长错误累积越明显。第一步理解错了后面几步再准也没用。我见过不少Agent项目Demo里能完成一个多步任务但实际跑起来经常卡在工具返回格式不对、上下文被撑爆、模型把中间步骤的失败当成成功。解决方案不是堆更多Prompt而是把每一步的输入输出都打印出来设置明确的校验节点。只要某一步结果不符合预期就停下来重试或交给人工。具体操作时我会给Agent加一个“步骤日志”模块。每次调用大模型之前记录当前目标、可用工具、输入参数调用之后记录模型返回结果、解析结果、下一步动作。这些日志在开发阶段非常重要。因为Agent的错误往往是隐性的单看最终结果可能觉得“差不多”但你说不清是哪里出了问题。有了分步日志就能把问题定位到某一跳。还要注意上下文窗口。Agent执行多步任务时历史记录会不断增长如果不做摘要或裁剪很快会超过模型上下文限制。上下文一旦被无关内容填满模型后面几步的表现会明显下降。这时候不一定要换更大模型可以先做上下文压缩把已经完成的中间步骤压缩成几条摘要。4.2 AI编程能生成代码不等于能维护代码AI编程工具确实能提高写代码速度但“生成代码”和“理解代码”是两回事。一个类、一个函数能跑通不代表它满足边界条件更不代表后期能维护。用AI编程的时候我建议把提示词当成需求文档来写明确输入、输出、异常处理、依赖版本。生成后不要直接合入先跑单元测试再做一次人工Code Review。这和Dreyfus批评“看起来能行”本质上是同一件事代码能运行只是最低标准。有一个很实际的问题AI生成的代码经常会引入你没注意到的依赖或者为了通过当前用例写死一个特例。如果你不审查短期可能没事长期维护时会非常痛苦。我的习惯是让AI写第一版然后我会重点看三处输入校验、错误处理、边界条件。这三处是AI最容易偷懒的地方。另外要注意提示词的作用范围。AI编程的提示词不是越复杂越好关键是把需求讲清楚。一个包含输入样例、输出样例、异常情况说明的提示词比单纯说“帮我写一个文件上传功能”要可靠得多。写提示词本身也是一种工程能力需要反复迭代。4.3 模型部署先确认资源边界再看效果模型本地部署最容易被忽略的是资源边界。很多人在低配置机器上跑通了一个小模型就以为可以照搬到生产环境。实际上显存、内存、磁盘、并发数都会影响最终效果和稳定性。我一般会在部署前列一张表模型参数量、单次推理占用、最大上下文长度、并发上限、单次延迟。先拿一张小图或短文本测再逐步加大输入长度和并发。这里不要一上来就把参数拉满否则你会分不清是OOM还是模型效果问题。关于“AI模型部署”还有一点不同推理框架的差异比想象中大。同一个模型用不同框架加载显存占用可能差一倍。所以不要只盯着模型文件大小一定要实测。最稳妥的做法是先做一个小规模压力测试固定输入长度逐渐增加并发数观察显存峰值、平均延迟、错误率。达到某个并发后延迟会急剧上升这个点就是你的资源边界。4.4 AI测试到底测什么很多团队做AI测试时喜欢问“模型准不准”。这个问题太宽泛。更有效的问法是对哪一类输入准对哪一类输入不准在什么条件下会出错出错后能不能被发现我建议把AI测试分成四层单元测试验证单个功能模块回归测试确认模型版本更新后旧能力没被破坏集成测试验证AI模块与数据库、外部接口的协作端到端测试模拟真实用户完整走一遍流程。每一层的关注点不同不能只靠一个“准确率”打天下。这四层测试并不需要很复杂但能有效避免“演示成功”带来的错觉。一个端到端流程在演示环境里跑通不代表它能在测试环境里稳定复现。在AI项目里环境差异、数据扰动、模型概率性都会导致结果不稳定这是正常现象。关键是要把这些不稳定性暴露出来而不是藏起来。5. AI幻觉问题可以按这个顺序排查5.1 输出看起来合理不代表事实正确Dreyfus报告里隐含了一个重要提醒系统生成的答案在形式上可能完全正常但内容并不对应真实世界。今天的AI幻觉问题本质上就是这个提醒的现代版本。模型不是数据库它在生成时不是查表而是按概率组合token。所以它完全可能用流畅的句子讲一个不存在的事实。遇到这种现象不要急着怪模型“笨”而是先问自己任务的真实性要求有多高如果是写歌、起名、头脑风暴幻觉问题不大如果是做客服、写合同、生成知识库内容就必须加上事实校验。我自己的经验是幻觉问题很难彻底消除但可以通过工程手段大幅降低影响。最有效的方式是给模型提供可引用的材料。比如做知识库问答时把相关文档片段作为上下文交给模型并要求答案里带上引用的段落编号。这样做有两个好处模型不容易凭空编造就算编了下游校验也能发现。5.2 排查顺序输入、上下文、参数、结果校验如果你发现AI输出里的“幻觉”比例偏高我建议按这个顺序排查排查层重点看什么常见问题输入原始材料是否完整是否被截断文件编码错误、字段缺失上下文关键信息是否在上下文窗口内无关内容太多关键信息被挤掉参数temperature、top_p、max_tokens温度太高导致发散输出长度被截断结果校验关键实体、日期、金额、编号缺少正则或外部接口核对这个顺序可以避免一个常见误区一看到错误就调Prompt结果发现是输入文件编码错了。另一个常见误区是忽略max_tokens。如果回答被截断后半部分内容会丢失看起来像模型“不知道”实际上是输出长度不够。5.3 给模型加“可引用源”在知识库类应用里我会强制要求模型在回答中引用来源。具体做法是把文档切成片段每个片段带编号检索到相关片段后把片段内容和编号一起放入提示词最后要求模型按“结论引用编号”的格式输出。如果模型给了一个答案但没有任何引用编号系统可以判定为不可信转人工处理。这个做法并不能完全解决幻觉但它把幻觉从“不可发现”变成了“可发现”。你可以在下游加一道校验检查引用的编号是否真实存在检查答案中的关键数字是否能在对应片段里找到。这样即使模型出错也不会直接输出给用户而是在系统内部被拦下来。6. 这篇报告留给今天的几组判断标准6.1 六个问题检验项目是炼金术还是工程我把Dreyfus的批评翻译成一组可以直接用的检验问题有没有固定的输入范围还是拿什么都能试有没有测试集测试集和演示样例是不是同一批有没有失败记录失败的时候能不能定位到原因有没有重复运行同一个输入跑三次输出是否稳定有没有资源边界显存、内存、延迟、成本有没有测算有没有人工审核兜底关键场景能不能允许AI单独做决定这六个问题如果答不上来项目再热闹也属于炼金术阶段。反过来如果一个项目能把这六点都讲清楚哪怕模型效果不是最顶尖它至少是一个可以继续迭代的工程系统。比如第一个问题很多AI项目根本没有明确的输入范围用户拿什么来问都可以。模型能答就答答错了算“幻觉”。这种系统看起来能力很广实际上连测试集都建不起来。不如把范围收窄先做一个特定场景比如“只处理退换货政策相关提问”这样效果和稳定性都会更好。第六个问题也经常被忽略。AI不能承担所有责任。在客服、金融、医疗等场景必须有一个人工审核环节。一个AI系统是否可用不是看它能处理多少正常输入而是看它遇到边界输入时是否知道把问题转给人类。6.2 给学习者和团队的实际建议如果你只是学习AI默认配置、公开API、小数据集完全够用。先把“单条任务跑通”和“小批量稳定”做好再考虑模型部署和Agent开发。如果你在团队里做技术选型我建议把“能力演示”和“工程验收”分成两个阶段演示通过不叫验收通过还要跑回归测试、压测、失败重试。对于网上那些“三个步骤跑通AI应用”的教程我建议用Dreyfus的视角去看它有没有告诉你测试集是什么有没有告诉你失败场景有没有告诉你在什么情况下不适用如果都没有那它只是一次演示不是一份工程指南。你可以照着学习但不要直接搬到生产环境。AI学习路线也容易踩同样的坑。很多人习惯从“跑通一个Demo”开始然后越学越迷茫。更好的顺序是反过来的先选择一个具体场景定义