这次我们来看一个观点性话题Ed Zitron 关于 AI 的批评到底错在哪。Ed Zitron 是英文科技圈里比较知名的 AI 批评者他的观点反复出现在各种播客、专栏和社交媒体讨论里AI 被过度炒作、大模型公司赚不到钱、消费者对 AI 产品并没有真实需求、整个行业更像一场资本叙事而不是技术革命。这个立场听起来很理性也确实抓住了不少现象比如很多 AI 聊天应用留存率不高、部分 AI 公司增收不增利、行业里存在大量同质化产品。但站在工程和落地视角看这套批评越来越像“用消费者互联网的估值模型去丈量生产力基础设施的成长曲线”。它回应了最容易看到的表面问题却漏掉了 AI 已经通过代码生成、Agent 工作流、私有化部署、嵌入式 API 等方式进入企业生产环节的事实。这篇文章不打算逐条复述 Ed Zitron 的所有观点而是想把他的批评拆开放到技术实践里验证哪些看法确实没说错哪些看法低估了 AI 正在发生的工程化转移。如果你关心 AI 产业到底有没有真实价值、大模型除了聊天还能干什么、AI Coding 和 Agent 是不是真有付费场景这篇内容应该能提供一个更落地的判断框架。1. Ed Zitron 的批评到底在批评什么先把批评对象说清楚。Ed Zitron 长期关注科技行业商业逻辑他对 AI 的质疑很少针对模型能力本身更多集中在商业闭环和用户价值上。这类论述比较常见读者应该也见过第一大模型公司投入巨大但收入规模撑不起估值。模型训练成本、算力采购成本、推理成本都很高而 AI 产品的付费意愿并没有跟上。第二普通用户并不真正需要 AI。ChatGPT 这类产品吸引了大量尝鲜用户但“用完就走”的比例很高日活和留存无法与社交产品相提并论。第三AI 生成内容质量不稳定。无论是文字、图片还是视频模型仍然存在幻觉、版权、一致性问题因此很难作为可信赖的正式生产工具。第四企业采购 AI 更多是为了向资本市场讲“AI 转型”的故事而不是为了提高实际效率。单纯看这四点每一条都能找到对应案例。但如果把 AI 看成一个整体行业直接得出“AI 是泡沫、没有价值”的结论就过于粗暴了。这里其实隐藏着一个很容易犯的逻辑错误把大模型聊天产品的市场表现等同于整个 AI 技术栈的价值上限。AI 现在的落地方式已经分化成了完全不同的几条路线表面上都叫 AI但不适合放在同一个框架里评价。2. 被批评者忽略的“工具性 AI”Ed Zitron 的批评视角更接近“观察者叙事”看的是一个普通用户如何体验 AI。而技术行业里真正发生的变化大量集中在“工具性 AI”上。这两种 AI 的区别在哪里聊天型 AI 强调你问它答产品要留住用户要争夺时长本质上接近搜索引擎或社交产品的逻辑。而工具型 AI 不需要用户长时间停留它的价值发生在任务执行链路里辅助工程开发、完成文档结构化、自动生成测试用例、做内容批量处理、在复杂工作流中充当决策节点。同样是大模型判断标准完全不同。聊天产品看日活、留存、广告变现工具型 AI 看的是任务完成率、开发效率提升、接口调用量、故障率、人工复核成本。如果只关注前者就会得出“AI 没用”的结论但如果把注意力放到后者很多批评就不成立了。举个例子。现在大量技术团队已经用 AI 辅助写代码、做 Code Review、生成单元测试、处理重复性文档。这个场景不需要用户爱上 AI不需要模型输出多幽默只需要代码补全质量够高、上下文窗口够大、能减少机械工作量。这类场景的价值是即时反馈的一个功能模块原来写两天用 AI 编码工具辅助后写一天半哪怕最终仍然需要人工检查和修改效率提升也已经落到账面上。这种提高不一定会体现在“AI 产品收入”这个宏观数字里但它确确实实改变了开发流程。如果只统计聊天产品的日活就无法看到这个层面的变化。Ed Zitron 式的批评本质上是用“应用层表现”替代了“价值传导过程”忽略了一个关键事实AI 正在变成基础设施层能力而基础设施的价值往往不容易被终端用户直接感知。3. AI 工程化的三条真实落地路径现在我从工程角度看AI 到底从哪里开始创造真实价值。路径不是消费者端而是工程端、企业流程端和基础设施端。3.1 AI Coding已经被反复验证的付费场景AI 编程是目前争议最小、付费意愿最明确的 AI 方向之一。以 GitHub Copilot、Cursor、Codex 以及 Claude Code 为代表的 AI 编程工具已经大面积进入开发者的日常工作流。这类工具的用户不是为了聊天而付费而是为了提高开发效率付费。对技术团队来说每年为 AI 编程工具支付的订阅成本与省下的开发工时相比往往可以明确算账。这背后是一套相对成熟的交互方式模型读取项目上下文、理解代码库结构、根据任务描述生成代码补丁开发者在 IDE 内审阅并修改。整个过程强调的是可追踪、可修改、可回滚而不是让 AI 自己毫无约束地写代码。AI Coding 的价值还体现在测试上。很多团队开始用模型自动生成单元测试用例、边界条件和 Mock 数据再交给 CICD 流水线执行。模型生成的内容不完全可靠但作为初稿生成器已经能显著节省重复劳动。3.2 Agent 与任务自动化从“对话”到“执行”第二类真实落地是 Agent。这里的 Agent 不是简单聊天机器人而是能读取输入、调用工具、执行步骤、输出结构化结果的自动化程序。典型形态包括文档处理 Agent读取 PDF、抽取表格、按规则命名、归档甚至自动写入数据库。客服工单 Agent理解用户问题匹配知识库生成工单草稿并转给人工复核。数据处理 Agent每天定时从各类数据源抓取信息清洗后生成报表。研发辅助 Agent监听代码仓库变更根据 Issue 描述生成 PR 草稿。这些 Agent 不需要对用户产生“吸引力”它们直接嵌入平台和业务系统里。判断它们好坏的标准不是交互体验而是任务成功率、平均处理时长、人工介入频次。从商业逻辑上说Agent 更像传统软件服务里的“流程自动化工具”只是把逻辑控制权交给了大模型的理解能力。这类需求长期存在需求的规模并不依赖“AI 是否在媒体头条上”。3.3 开源模型与私有化部署AI 退化为普通软件组件第三个重要趋势是开源模型与私有化部署。很多企业并不想把内部数据送到公有云大模型服务而是希望通过私有化部署满足数据安全、权限控制、合规审计和定制化需求。这一块在中国市场尤其典型。以通义千问 Qwen、DeepSeek 等为代表的开源模型体系迅速发展配合 vLLM、Ollama、llama.cpp 等推理框架已经让“本地跑大模型”成为常规工程动作。部署流程大致可以分为几个环节选择合适的开源模型例如量化版模型降低显存要求。下载模型权重配置推理服务。通过 OpenAI 兼容接口暴露给上层应用。根据业务数据做微调或 RAG 检索增强。这个环节里大模型已经不像一个“产品”更像一个软件组件。工程师不需要关心模型是不是爆款只需要看推理速度、显存占用、接口稳定性、输出质量是否满足需求。这种“组件化”的进程恰恰是技术从概念走向基础设施的典型表现。一个简单的本地推理服务启动方式可以用下面的模板表示实际命令需要根据你选择的推理框架和模型名称调整# 以 Ollama 为例拉取开源模型并启动服务 # 具体模型标签需要查看实际可用的模型列表 ollama pull qwen2.5:14b ollama serve # 在另一个终端执行模型对话 ollama run qwen2.5:14b 用一段话描述这个测试用例的设计思路如果你使用 vLLM 部署则启动方式更接近传统服务化流程python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --host 127.0.0.1 \ --port 8000这类部署方式说明一个事实大模型已经具备比较好的工程可集成性。它不是停留在演示视频里的玩具而是可以通过标准化接口接入业务流程的通用组件。4. AI 落地的真实评价指标要跳出“AI 是泡沫”和“AI 是万能”的二元争论最好的办法是建立技术评价体系而不是看市场份额和媒体宣传。如果你是技术负责人或开发工程师当你评估一个 AI 项目是否值得投入时建议从下面几个维度观察评价维度具体观察点判断方法任务完成率模型能否稳定完成指定任务准备 30 到 50 个测试样本统计成功输出比例人工介入程度需要人工修改多少记录一次完整任务中人工修正的时间占比实际收益效率提升是否可量化对比任务原耗时与 AI 辅助后耗时接口稳定性推理服务是否适合生产压测接口吞吐量和错误率显存与成本部署硬件是否可承受监控推理服务显存占用和单次推理成本以 Agent 项目为例技术团队可以先定义好一个具体任务比如“从 PDF 中提取表格并转成 Markdown”。然后准备一份测试文档运行 Agent观察它能否完成解析、是否遵守输出格式、遇到异常表格时会不会报错。这个评估过程中你会得到另一个很重要的结论AI 的价值高度依赖任务边界。只要任务定义得足够清楚、输出格式可校验、失败路径可控AI 就能变成可靠工具。反过来如果任务无限开放、输出没有标准、失败后也没有兜底那么 AI 产品就容易给用户留下“不好用”的印象。真正的工程化 AI重点从来不是把任务全交给模型而是设计好人机协作流程让模型处理擅长部分人工负责决策、审核和异常兜底。5. 接口能力与批量任务AI 价值放大的工程前提再往下一层AI 之所以能进入生产环节和接口能力、批量任务处理能力的成熟密切相关。聊天界面只是 AI 产品的前端真实业务更多走的是后端 API。任务队列把大量文档丢进去模型逐个完成抽取、分类、改写或摘要每隔一段时间自动执行一轮异常任务被标记出来进入人工队列。这种模式下AI 的服务对象不再是单个用户而是一整套自动化流水线。假设你有一个文档处理服务想接入 AI 能力通用调用方式大致如下这里只是给出接口调用骨架实际参数要按你接入的模型服务调整import requests # 假设本地或内网已经有一个兼容 OpenAI 协议的推理服务 # 实际地址、模型名和请求参数需要按部署环境填写 url http://127.0.0.1:8000/v1/chat/completions payload { model: your-model-name, messages: [ {role: system, content: 你是一个文档结构化助手只输出 JSON。}, {role: user, content: 请从下面的合同文本中提取签约方、金额和日期。} ], temperature: 0.1, max_tokens: 1024 } response requests.post(url, jsonpayload, timeout120) result response.json() print(result[choices][0][message][content])技术上这个请求背后的流程并不复杂但一旦跑通它就可以被封装成内部工具集成到 OA 系统、工单平台、内容生产系统甚至 CICD 流水线中。批量任务的工程化要点在于可观测性和失败恢复。给每个任务分配唯一 ID、记录输入输出、设置超时时间、失败自动重试、输出人工审核队列。没有这套基础设施模型能力再强也接不进严肃业务。这类实践已经在大量企业内部存在。它们不像消费者产品那样容易在媒体上引发讨论但它们对生产流程的影响是实质性的。这也是“Ed Zitron 式批评”容易忽略的地带很多 AI 价值不是以新产品形态出现而是安静地嵌入到既有工作流里提升效率降低成本减少重复劳动。6. 批评中真正有价值的部分我不打算把 Ed Zitron 的批评说得一文不值。事实上他的某些提醒对 AI 行业是有价值的。6.1 模型能力的提升不等于商业价值的兑现技术上强大和市场认可完全不是一回事。这一点上批评者的警惕是必要的。很多 AI 公司确实处于“技术很强商业模式模糊”的阶段模型能力提升未必能换来等比例收入增长。6.2 市场存在大量伪需求相当一部分 AI 应用是在强行制造需求。比如在不需要 AI 的场景里硬塞聊天机器人或者在缺少数据基础的条件下做所谓的“智能决策”。这类产品失败后会拖累整个市场对 AI 的信心。6.3 自动化收益分配是真实问题AI 提升效率后收益如何分配没有明确标准。如果效率提升只体现为裁员和压成本而没有被用来创造新产品或改善工作质量社会对 AI 的抵触情绪只会越来越强。这个批评非常现实也确实不能被工程师文化简单化解。6.4 高质量数据与语料版权是长期必然挑战训练数据来源、内容版权、生成内容归属这些问题目前仍处于快速变化中。企业部署 AI 前如果不处理数据和生成内容的授权边界很容易在后续使用中陷入法律风险。Ed Zitron 在这个方向上的追问是有建设性的行业不能只讨论“能不能做”还要回答“凭什么可以做”。正因为这些批评存在AI 技术团队才更需要用克制的方式去推进小范围试点、关键任务人工兜底、内容合成明确标识、数据隐私审计、模型来源与授权链清晰化。这些不是应付审查的流程而是让 AI 从实验走向生产的基本纪律。7. 从“AI 有没有用”到“你的工作流里有没有 AI 的位置”现在回到标题Ed Zitron 到底错在哪我认为他最大的错误是把“AI 没有出现改变行业的杀手级消费应用”和“AI 没有产生生产力价值”混为一谈。实际上AI 的价值转移不是通过一个横空出世的爆款产品完成的而是通过下面这类看起来并不性感的路径慢慢释放的软件开发者用 AI 辅助编程减少重复性编码。产品经理用 AI 整理需求、生成文档初稿。运维工程师用 AI 分析日志定位异常原因。市场营销团队用 AI 批量生成素材初稿再人工修改。企业用 RAG 技术把私有知识库变成可查询的智能问答系统。内容行业用 AI 完成粗剪、字幕生成、语音转写和分词检索。这些场景中AI 的表现不像科幻电影里的超级智能更像一个记性极好、响应极快、但没有常识判断力的初级助手。它需要清晰的任务定义、严格的结果校验、可靠的人工兜底。但只要流程设计得当它就能稳定地带来产量提升。Ed Zitron 批评中真正值得保留的部分是提醒我们不要轻信“AI 一夜之间改变一切”的叙事。真正的技术革命往往是渐进的、混杂着大量试错的、需要和旧系统长期共存的。AI 没有让软件行业消失相反它让软件开发本身变得更需要判断力、架构能力和业务理解能力。一个实用的判断方法是少看 AI 公司发布会的演示多看自己团队中三个具体场景的 AI 使用密度。第一打开你团队代码仓库统计有多少代码提交包含 AI 辅助痕迹。第二观察业务运营中有多少文档处理、报表生成、数据清洗流程已经接入了模型接口。第三问一问团队里最忙的成员他的日常工作中哪一部分可以由 AI 先打草稿再由他修改确认。当这三个问题的答案开始变化时你就会明白AI 的落地速度比许多宏观批评者想象得更快。它只是没有那么集中地体现在某一家公司的估值报告里而是分散在无数条业务流水线的成本结构与交付周期里。这种变化反而更接近过去几十年里软件行业自身的发展逻辑没有哪个企业在某一天突然宣布进入信息时代而是财务、供应链、生产管理各个环节的软件化逐步完成等到人们意识到时软件已经成为商业的基础设施。AI 正在重复这个过程。8. 给技术团队的现实建议针对还在观望的团队我给出几条实际判断和行动推荐。第一不要把所有大模型公司混为一谈。模型层面、应用层、工具层、基础设施层的商业逻辑完全不一样失败案例不能证明整个技术方向失败成功案例也不能说明所有 AI 项目都有未来。第二从高重复、低风险、易验收场景切入。第一类候选场景是文档解析和信息提取数据有边界、输出可校验、失败成本低。第二类是代码生成辅助开发者本身就是最合适的验收者。第三类是内部知识库问答部署在可控网络内数据不外泄。第三关注数据与版权合规。企业内部数据是否需要脱敏模型服务商是否有数据留存政策生成的代码是否引入未知协议依赖这些都是部署前必须查清楚的细节。第四接受“人机协作”而不是“完全替代”。早期阶段把 AI 定位为“效率放大器”更现实。让模型产出初稿人做审核修改和决策然后再逐步扩大模型自主执行的范围。第五建立批量任务的可观测体系。无论你是做 OCR 批量识别、文档批量优化还是表格批量抽取都要设计好输入队列、输出日志、失败重试和人工复核环节。没有这些AI 在规模化后就只会变成新的故障源。第六监测成本和显存。对大模型而言单次体验的成本可以忽略但批量日常化运行后推理成本、显存占用量、GPU 资源调度会变成真正的瓶颈。建议正式上线前做一次成本估算并预留性能监控。9. 结论AI 不需要“杀手级应用”来证明价值我不太认可 Ed Zitron 关于 AI 的这轮判断原因并不复杂AI 真正的大规模落地仍然在进行中但它的形态早已不是“另一个社交 App”而是软件行业的基础能力。它不会突然把一家公司变成垄断巨头却会逐步改写软件产品的研发周期、客服成本、内容生产效率和运维响应速度。如果你的团队还停留在“用 AI 聊天问问题”的阶段那么你观察到的 AI 的确价值有限。但如果你已经开始尝试用开源模型搭私有服务用提示词工程处理标准化任务用 Agent 编排跨系统流程用 AI 编码工具改进日常开发再用接口和队列把这套能力串成批量任务你看到的就是另一番景象。这就是批评者和实践者之间最大的视野差异。前者看的是聚光灯下的表演后者看到的是后台无数条流水线正在被重新连接。真正确认 AI 价值的方式并不是参加更多发布会也不是反复阅读行业预测而是选一个几十条样本可以验证的具体任务动手跑一轮测试。如果能想清楚任务边界、能处理失败、能量化效率提升AI 对你来说就是真实生产力。如果这三件事都做不到哪怕行业指数涨上天AI 在你的业务里也确实还没有价值。从工程实践出发的判断标准永远比宏观叙事可靠。