Ed Zitron 对 AI 的整体判断是近两年科技圈最容易被转发的观点之一。他批评AI营销话术、企业为概念买单、估值和真实收益严重脱节这些批评放在很多发布会场景里确实成立。但我做完一批AI编程、AI Agent、AI应用开发的落地测试之后越来越觉得至少在“AI没有真实价值”这个方向性结论上Ed Zitron 的判断是错的。把AI当成一个悬浮在PPT里的概念确实看不到价值把AI当成一组有明确边界、可验证、可迭代的工具价值会变得非常具体。这篇不是要全面否定一位评论者而是要把“AI到底有没有用”从一个情绪问题改造成一个工程问题。1. 为什么“AI是泡沫”很流行却解释不了大量真实工具在跑1.1 批评者的素材来源大多停留在发布会和财报Ed Zitron 式的批评能引发共鸣是因为他提供了很多看起来特别真实的素材一家公司改个名字股价就涨、一个产品发布会讲了一堆愿景但没有具体性能、一个平台投入巨大却看不到用户留存。这些话术在资本市场上确实大量存在很多企业高管也确实说不清楚自己为什么要上AI项目。但这里有一个容易被混淆的地方资本市场的现象不能直接等同于技术能力。估值涨跌反映的是参与者的预期和情绪不是模型在代码补全、文本抽取、工单分类、知识库问答这些具体任务上的实际输出质量。如果想要判断AI是不是泡沫应该看生产环境里的调用日志、错误率、人工修正量、用户实际使用时长而不是只看新闻标题。我最早也容易被这类批评带偏。后来连续参与几个内部AI项目才发现那些在舆论上没有影响力的工具可能正在每天处理几万条工单。它们没有开发布会不叫“大模型产品”只是一个很小的AI服务嵌在审批流里辅助分类但价值是能算出来的。1.2 “估值贵”和“能力假”是两件完全不同的事很多人把“AI创业公司估值过高”直接理解成“AI技术上做不到”。这是两回事。一个领域可以同时具备两个特征资本层面有泡沫技术层面有真实进展。20世纪90年代互联网也有大量泡沫但网络基础设施、在线交易、信息检索这些能力后来都被证明是真实价值。批评者如果只看到泡沫就会错过一个更重要的问题泡沫破掉之后哪些能力会留下来。现在可以观察到的一个趋势是AI基础设施、AI编程、AI Agent、私有化部署、AI数据分析这些方向不是靠发布会撑起来的而是靠开发者一遍遍调用跑出来的。一个工具如果连续几个月都有稳定的调用量那它一定解决了某些人的某些问题。1.3 被大量评论忽略的中间层AI不只有对话机器人公开报道里AI总是被塑造成一个全知全能的通用助手。但在真实生产环境里AI最常见的形态是小任务、窄场景、低姿态。比如用户反馈自动分类客服对话摘要合同条款信息抽取代码注释和单测生成商品标题改写会议纪要素材整理这些场景不会出现在科技媒体的头条里因为它们不够性感也不具备“颠覆一切”的戏剧冲突。但恰恰是这些任务让AI在很低的容错成本下产生了明确收益。这里的关键不是模型能不能像人一样思考而是流程设计者能不能找到那些“输入输出稳定、重复度高、错误可修正”的任务。注意判断AI有没有用不能只看一个演示视频也不能只听一篇评论文章。正确做法是选一两个具体任务跑完几十条真实样本再下结论。2. 批评者最常犯的错把一次糟糕的演示当成全部结论2.1 用错误的任务去测试文本生成模型很多针对AI的批评测试方式本身就存在问题。有人拿一个没有联网能力、没有内置实时数据接口的模型去问“今天北京的天气怎么样”得到错误答案后就宣布“AI是弱智”。这其实是把信息检索任务和语言理解任务混在了一起。大语言模型本质上是概率性的文本生成器它既不是一个完整知识库也不是搜索引擎。如果你需要实时天气应该给它查询天气的API如果你问的是私有知识库内容应该先接RAG如果你要算精确财务数据应该用代码执行引擎而不是让模型直接心算。这就像一个测试者要求一把锤子去拧螺丝失败后得出结论“所有工具都没用”。问题不在模型而在需求定义。2.2 单次主观体验好或坏不能替代统计验证AI输出存在随机性。同一个问题两次问可能得到不同的表述甚至有个别错误。批评者很容易抓住一次离谱的回答支持者也很容易展示一次惊艳的回答。这两种方式都是典型的采样偏差。我在做评测时一般会这样做把temperature调到一个合适水平固定模型版本用同一条输入反复跑20到50次再统计错误类型。很多看似“智力不够”的问题拆开来看其实是两类第一类答案内容是对的但格式不满足要求。第二类关键字段出现幻觉属于事实错误。第一类通过约束输出格式、增加解析校验就能解决。第二类需要加检索、工具、人工兜底或者调整任务边界。如果批评者把所有错误都归结为“AI不行”就错过了非常具体、可修的工程问题。2.3 拿“不能替代人”去否定“不能辅助人”另一个常见的逻辑跳跃是拿“AI不能自动完成整个岗位的工作”来否定AI的价值。这个标准定得太高了。现实中几乎没有任何软件能直接替代一个完整岗位但几乎每个软件都可以提升某个环节的效率。拿客服场景来说AI客服单独回答用户问题确实可能只有70%的准确率如果让AI直接面对所有用户会产生灾难性体验。但如果换一种用法让AI先处理重复度高、规则明确的前置问题再把复杂问题转给人工效果就完全不同。它没有替代客服但减少了客服的重复劳动让有经验的客服能把时间花在真正需要判断的沟通上。AI编程也一样。它不能自己理解一套乱糟糟的业务需求并完成系统重构但它可以帮你生成样板代码、补一个单元测试、解释一个陌生报错、把一段长函数拆成更小的模块。这些收益不需要AI达到“全自动程序员”水准只需要比“从零开始写代码”少花十分钟就已经是正向收益。3. 正确判断AI有没有用先给任务分类再定验收指标3.1 不是所有任务都适合用大模型最容易翻车的AI项目往往是从“这事看起来很适合”开始而不是从“这事在工程上可以被校验”开始。判断任务适不适合用大模型可以先看几个条件任务描述是不是清晰输入输出是否可以被结构化记录错误是否容易被发现和修正数据量是否足够支撑效果评估业务能否容忍一定比例的错误或者是否有兜底机制如果这些条件大部分成立项目就值得小规模尝试。如果任务本身模糊、没有固定输入格式、结果也无法评判那无论用多少层语义推理都会变成黑箱。3.2 任务分类是选型的第一步在实际落地时可以把任务粗略分成三类A类任务信息抽取、格式转换、标题生成、摘要、关键内容归类、代码片段辅助。这类任务通常只需要模型在给定文本上做转换输出容易验证错误成本低适合直接使用大模型。B类任务专业问答、数据分析、企业知识库服务。这类任务需要接入外部知识库、数据库或工具不能单靠模型记忆。它同样可行但工程复杂度明显上升。C类任务关键业务决策、高精度计算、实时状态判断、需要严格审计的流程。尽量避免让纯模型直接完成最终判断应该把模型结果当作草稿由规则、程序或人来复核。3.3 最小验证实验怎么设计如果条件允许我更建议做一个最小可行实验而不是先争论“AI有没有用”。实验流程大概是选择一条真实业务流程中的具体任务。收集20到100条历史输入最好覆盖不同写法、不同长度、不同风格的样本。由业务方先给出参考输出作为质量基准。先用规则、模板或人工方式记录基线耗时和正确率。再用大模型对同样样本生成结果。让人对输出做盲评判断结果是否可用、需要改多少、单条能节省多少时间。为什么要用20条以上因为2条样本只能给你一个方向性感觉覆盖不了输入多样性。为什么一开始不用1000条因为标注成本太高而且还不确定方案是否值得投入。先用小样本把方向走通再扩大样本量是比较稳妥的路径。3.4 验收指标要提前定好很多AI项目失败不是模型调用失败而是没有在开始前定义“什么叫做成功”。建议至少记录以下几个维度指标含义判断口径可用率输出不需要修改或仅轻微修改就能使用的比例由业务方按自己标准打分人工修正量每个输出平均需要改多少字或多少字段修正量越小自动化价值越高单条耗时从调用到返回结果需要多少秒要和业务流程可接受时延对比失败率输出空、超时、解析失败的占比生产环境必须记录单条成本包括模型调用、人工审核、重试费用的总成本不计失败和审核的成本没有意义这些指标不能拍脑袋。如果某个任务人工处理一共需要两分钟AI处理后还需要业务人员改三分钟那这个项目就不该继续。好与不好要看数据说话。注意设置temperature、max tokens、重试次数等参数时一定要先确认线上使用的模型版本和评测时一致。否则你辛苦调好的效果可能换一个模型版本就完全变了。4. AI Agent、AI编程和模型部署从 Demo 到生产的细节4.1 Demo能跑通不代表任务能闭环很多AI项目在Demo阶段表现非常好。给一段输入模型输出一段像模像样的结果所有人都很高兴。但放到生产环境后问题才会逐渐暴露输入文档可能带扫描噪声用户可能传了一个十几页的PDF某个字段可能为空网络请求可能超时返回结果可能被截断。以AI编程工具为例单个函数的自动补全可能让人惊喜但放到真实项目里还要面对依赖版本冲突、编译错误、测试失败、代码风格不一致等问题。工具能帮你补全一段函数但它不能保证这段函数能融入现有架构。所以我一般建议任何AI能力在上线前都要拆成两层看第一层单次能力是否可用。第二层连续跑20次甚至100次后错误率、稳定性、异常处理是否可接受。单次能力像一道闪光连续跑完一批真实输入才像一盏稳定的台灯。你要的是灯不是闪光。4.2 生产环境需要盯住的核心参数模型部署和API调用不是把请求发出去就完事了。以下是几个最容易被忽略、但对结果影响很大的参数参数影响常见处理思路模型版本不同版本能力差异很大测试、灰度、生产必须锁定同一个版本temperature影响随机性抽取、分类任务调低创意写作可稍高max tokens输出太长会截断太短不够用根据任务最大输出预留余量超时时间请求阻塞会拖垮流程按任务耗时给合理超时避免无限等待重试次数网络抖动可能造成偶发失败设置重试但要防止雪崩并发数同时请求太多会被限流小样本测试时不要一上来就开高并发prompt 版本每次修改都会改变输出建议对prompt做版本管理输出格式模型可能不按格式来用JSON Schema或正则校验失败重试这些参数不存在统一的“最佳配置”。每类任务的合理值不同。比如代码生成任务适合稍微高一点的temperature因为它需要多样性合同信息抽取任务则应该尽量让输出固定所以temperature要低。4.3 AI Agent的评价不能只看最终结果AI Agent 比单纯的大模型调用更复杂。它可能会拆解任务、调用工具、读取结果、再次决策形成多轮操作。这时如果只看它最终返回的结果你很难判断问题出在哪一步。建议对Agent的每次运行都记录以下信息任务输入和预期结果Agent拆解出的步骤列表每一步调用了什么工具工具返回了什么内容每一步耗时和token消耗最终结果是否满足预设格式连续多次运行的成功率如果Agent经常失败先不要急着换更大的模型先看日志里哪一步出错。很多失败来自工具参数不对、搜索返回内容不相关、输入文本太长、Agent在步骤中陷入循环。这些问题通过增加最大步数上限、优化工具描述、补充错误提示就能解决。5. 什么时候批评是对的什么时候批评会误导选型5.1 Ed Zitron式批评在哪些场景成立Ed Zitron 的批评并不是完全没有道理。如果一个企业的立项理由是“别人都在做AI”那么它大概率会失败。如果一个项目不定义业务指标只看模型演示效果那么它也确实可能成为成本黑洞。如果管理者相信AI可以完全替代有经验的专业人员而不考虑错误兜底这类项目翻车只是时间问题。在这些场景里批评者不是无聊而是在给过热的市场降温。AI行业确实有太多只是为了故事而存在的产品。看到这些项目翻车并提醒大家谨慎是有价值的。5.2 但“AI公司有泡沫”推导不出“AI工具没有价值”Ed Zitron 那类观点最值得商榷的地方在于把资本市场上的泡沫等同于技术能力上的虚妄。很多AI公司估值高是因为资本集中在头部玩家手里不是因为每一家大模型公司都能兑现所有承诺。同样很多AI项目失败是因为选错了任务、定义不清指标、没有工程兜底不是因为底层模型完全没用。我在使用AI编程工具时大量样板代码、重复性测试、格式转换工作确实被明显压缩了。这个收益不需要依赖某一家公司的股价上涨。只要模型能稳定完成一个具体任务哪怕它有明显边界它的价值就是可以被测量的。评论者可以嘲笑PPT里的宏大叙事但不应该忽略代码编辑器里实实在在的补全建议。5.3 更准确的说法是什么如果让我把“Ed Zitron Was Wrong About AI”翻译成一个更精确的观点我会这样说他把“很多AI公司在浪费钱”和“AI没有创造真实价值”混成了一个判断。前一句话在不少公司身上成立后一句话在大量实测任务里不成立。一篇好的技术批评应该指出技术被夸大的地方也承认技术已经改变的部分。如果批评最后变成一个全称否定它就会误导一批本来能从AI辅助中获益的普通用户和中小企业。他们可能因为一篇文章拒绝尝试一个实际能提升效率的小工具。5.4 别被舆论钟摆带着跑技术舆论经常在两个极端之间摆动。今天说AI万能明天说AI是骗局。对于长期做实操的人来说这两种姿态都是噪声。正确的做法是回到自己的任务里用一组真实的输入、明确的指标、可接受的人机协作方式去验证它到底适不适合自己。资本市场的情绪会波动模型版本会迭代但一个稳定跑通的任务闭环不会因为一篇评论消失。6. 与其争论AI有没有用不如跑一轮样本测试6.1 一个团队可以快速执行的验证思路如果现在你的团队还在因为“AI到底有没有用”争论不休我建议花三到五天做一轮最小的验证。不要一开始就规划一个大型AI平台先选一条具体的、重复度高的业务动作。比如把客服对话整理成结构化摘要把销售线索描述归类到对应行业把代码补全工具接入编辑器试用把产品评论自动生成简短标签然后按下面这个节奏推进第一天收集20到100条真实历史数据。第二天让业务人员给出参考输出建立基础答案。第三天用规则或人工跑一遍基线记录耗时和成本。第四天调用大模型接口或部署一个开源模型尝试生成同样输出。第五天让业务人员盲评同时记录成本和修正量。这一轮结束后你不需要看任何人的观点文章也能知道AI在这个任务上是否值得投入。6.2 成本不能只算API费用很多人在评估AI成本时只算显式费用比如每次调API花多少钱或者买显卡花多少钱。但真正落地时还有隐性成本让业务方写参考输出要时间产品经理调prompt要时间开发人员接接口和写校验逻辑要时间线上出现异常时人工排查也要时间。所以成本测算至少应该包含以下几块模型调用费用或本地部署资源数据准备和输入清洗成本Prompt开发和版本维护成本输出格式校验、错误重试处理成本人工审核或修正成本线上日志、监控和问题修复成本把这几项全部摊到单条任务上再对比原有人工处理的单位成本结论才有说服力。6.3 什么情况下可以说“这条任务真的有效”当满足以下几个信号时基本可以认为AI在任务中产生了实际价值连续跑完一批真实样本后可使用率达到业务方接受的范围。人工修正每条结果所花的时间明显少于从零处理同样任务的时间。单条总成本低于原有处理成本或者虽然略高但处理速度换来了更大价值。错误类型可以追溯并且能通过规则校验、更清晰的prompt或检索增强来降低。流程在连续运行一段时间后仍然稳定不会因为个别异常输入直接崩溃。如果这些信号一条都不满足那批评者的观点在这个具体项目里就是成立的。你就不该继续投入更不要强行包装概念。这时果断停下来反而是明智的决策。6.4 最终判断要落到样本和指标上我看过太多讨论AI价值的场合最后都变成立场之争支持的人反复强调某个惊艳案例反对的人不断引用某个翻车现场。这两种讨论都不能帮一个具体业务负责人做出决定。真正能决定“要不要用”的只有你自己的场景、样本和指标。评论文章可以提醒风险发现容易踩坑的地方但它替代不了你对真实输入的处理。Ed Zitron 那些批评给我最大的提醒是不要为了一个宏大概念去投入资源。反过来他对AI价值全盘否定的趋势也会让一部分人在可能有效的任务前浪费一次低成本验证机会。与其说服别人不如花两天时间收集100条真实样本跑一轮评测。数据和结果是争论里最有说服力的东西。