最近读到不少关于“AI只是资本泡沫”的评论Ed Zitron 的声音是其中最常被转发的一类。他对AI行业的批评很直接大量公司靠一套漂亮PPT拿到巨额融资真实业务却撑不起估值大模型训练和推理成本居高不下普通用户却找不到“非用不可”的理由。连带着他对“AI改变生产力”的说法也表示怀疑。我第一次读到时确实被说服了因为从市场角度看AI行业的膨胀方式确实很像历史上许多技术泡沫的前夜。但后来我发现一个偏差评论家们讨论的是股票、融资、算力和产业宏观趋势而我身边的工程师讨论的是某个具体模块能否借助大模型少写大量重复代码。这两个话题都叫“AI”实际却是两个世界。Ed Zitron 的价值在于提醒大家不要被品牌宣传骗了但当他从“行业存在大量泡沫”进一步推导出“AI没有实际价值”时我认为他的判断开始失真。他真正错的地方是拿资本市场的镜头去拍摄工程现场的细节。资本市场需要宏大故事工程现场需要的是把一个重复任务稳定地完成。泡沫是否存在与技术工具是否能在给定场景里省下时间是两个可以分开回答的问题。下面我想从自己观察到和经历过的工程实践出发把这场争论拆到一个更具体的层面AI应该被当作什么它真正解决了什么以及什么样的人适合听信哪种判断。1. 两种AI叙事经常被混为一谈为什么同一个AI有人觉得是生产力有人觉得是大泡沫因为他们在谈论不同的对象。现在至少有两条AI叙事线一条是资本市场的一条是工程现场的它们都借用“AI”这个词但评估标准完全不同。Ed Zitron 那类批评大多数时候盯着第一条线然后试图给第二条线下结论这是典型的错位。1.1 资本市场版AI永远在讲宏大故事资本市场需要故事需要增长曲线需要“未来十年改变所有行业”的蓝图。融资阶段一个技术概念是否有具体落地场景并不重要重要的是它足够宏大能覆盖足够多的想象空间。于是你会看到大量“AI应用”本质上是在普通产品上加了聊天框或者把已有规则系统包装成“自主智能体”业务问题没有解决产品标题倒是很激进。这类现象确实值得批判。Ed Zitron 嘲讽这些项目我认为没有问题。一个行业如果出现太多靠PPT融资的公司那么这个行业一定存在严重的资源错配和评价失真。但问题也随之而来你不能因为一个技术领域同时存在大量骗局就宣布这项技术本身无效。二手车市场里有骗子不代表汽车是没用的云计算早期也有很多“云”只是把服务器放在托管机房不代表云计算不成立。资本叙事里混入了太多杂质不代表底层技术真正产生的改善不存在。如果评论者只盯着资本版AI他看到的必然是一个又一个荒诞的产品和一轮又一轮融资过山车。长期处在这种信息环境里很容易得出“AI没有真实价值”的结论。但这个结论只是评价对象的产物不是技术事实。1.2 工程技术版AI具体任务里的确定性提升工程现场对AI的理解更朴素它不需要拥有通用智能甚至不需要懂得自己在做什么只要能在明确定义的子任务上稳定降低人力成本它就有价值。这就像你接入一个函数输入是一段文本或代码输出是经过处理的结构化结果。它不一定每次都对但你可以用规则和人工兜底把错误率压到业务可接受的范围。我见过最典型的场景是数据清洗。一家公司收到几百份来自不同系统的表格字段名不统一日期格式混乱地址写法千奇百怪。传统做法是写大量正则表达式覆盖了主要场景然后陷在无穷无尽的新版式里。用大模型做字段抽取后核心思路变了不再追求“一条规则走天下”而是让模型理解自然语言中的语义边界把“从这段文本里抽出供应商名称和金额”当成一个阅读理解题再让程序校验输出格式。这种应用不会登上科技新闻头条也没有“改变世界”的故事性。但它在真实工作流里每天都在发生生成测试数据、转换接口文档、给历史代码补注释、把非结构化日志整理成结构化事件。这些任务单独拿出来都很小合在一起却占据了普通开发者相当大一部分工作时间。评论家在地铁上看融资新闻当然看不到这类场景除非他真的坐在开发者旁边看一个实习生用提示词在半小时内搭出一个原来需要两天的数据提取脚本。所以当 Ed Zitron 说“AI并没有带来生产力革命”时他可能是在说“公开市场的AI叙事没有兑现成足够宏大的经济增量”。这是另一个问题。技术价值的起步往往非常细碎先在一个低风险任务里省下一点时间再慢慢扩展到更多流程最后变成一种长期能力。它不是一道闪电而是一点一点渗入工作缝里的变化。2. 真正让我改变态度的不是理论而是三次具体任务我对AI的态度经历过几次变化。最初看演示视频觉得很多炫酷功能是剪出来的后来读了几篇批判文章觉得这可能又是新一轮泡沫真正改变我的不是某篇论文或某次发布会而是几个非常普通的任务场景。它们都不属于“改变世界”的项目却让我重新理解AI的生产力价值。2.1 第一次写接口对齐代码省下的是大量“类型搬运”后端项目里经常要对接外部接口。接口文档几十页字段有几百个你需要照着文档生成对应的数据对象、序列化配置和基础单元测试。这种事不需要太多创造性但极其占用时间。过去我通常下午开始手写写完已经很疲惫。后来我把接口文档片段直接复制进一个编程助手告诉它“生成Java数据类字段命名用驼峰日期类型用LocalDate金额类型用BigDecimal”几秒钟后得到一份初稿。这里的关键不在于模型写得有多惊艳而在于它把“类型搬运”这种纯体力工作压缩到了几秒。人只需要做两件事第一把需求边界描述清楚第二逐行审查输出是否正确。如果把AI的输出当作最终答案直接复制当然会出问题但只要把它当作一个需要人工复核的初稿效率提升就是实在的。在真实项目里这类工作远不止对接接口。还有大量DTO转换、字段映射、配置文件生成、测试桩代码。它们共同特征是重复性高、规则容易描述、出错后果不严重。AI是否“理解业务”根本不重要它能帮你把初稿铺好就已经省下了最枯燥的那段时间。这也让我第一次意识到评价AI不能只看它能不能独立完成一个复杂系统而要看它在重复劳动中节省了多少注意力。2.2 第二次几十份格式各异的旧单据被压成可接受的成本另一个例子来自一批历史采购单。单据来自不同供应商、不同年份有的是PDF有的是扫描件有的表格里还混着备注。团队成员最讨厌这类任务看起来简单实际操作起来全是例外情况必须打开每一份文件人工把供应商名称、金额、日期填进系统。我们试过两条路线。第一条是继续写规则正则加关键词匹配覆盖了大概七成的文件剩下三成是新变体每处理一个都要给规则打补丁。第二条是让模型直接做文档抽取并要求它输出JSON再让程序做一次字段格式校验校验不通过的文件进入人工队列。后者不是万能的也会出现金额错位和日期识别错误但它至少把体力工作从一个一个看文档变成了只在机器不敢判断时看少数几条样本。这套流程的关键不是模型准确率有多高而是我们为“模型可能犯错”设计了缓冲。它出错程序能检测到它识别不了程序能转给人工。整个过程不需要模型完美只需要模型把原本需要人工浏览一遍的内容压缩到只处理异常项。最后团队负责人愿意用因为同一批单据的处理时间从按周计算变成了按天计算。这件事让我明白AI在生产中的价值经常以“搭一套带错误兜底的流程”的形式出现。单独评价模型当然会得出“它不可靠”的结论但如果你把它放进一个允许试错、有后置校验的工程系统里它就变成了一个有用的组件。这正是只站在外部观察AI的人看不懂的部分。2.3 第三次Agent 不是全自动而是把任务拆得更清楚AI Agent 是近两年被过度包装的词。很多演示视频给用户的预期是“你只需要说一句话Agent 就能像员工一样完成整个任务。”这种预期对真实生产极不友好因为一旦任务变长模型出现一次判断错误整个链条就全错而且很难定位是哪一步出了岔子。所以我一直不太信任“放一个Agent全自动跑流程”的工程方案。但我也见过一种更务实的Agent用法让模型做任务路由。比如一个工单系统用户提交一句话描述问题Agent先做意图识别和信息抽取然后决定应该走自动回复、调用业务接口还是转给人工客服。它不负责给出最终答复只负责判断问题属于哪一类以及把关键参数抽出来。即使模型抽错了后续人工处理也能发现不会直接产生严重后果。这里的核心价值发生了转移。Agent 不是替代整个决策过程而是替你把用户请求的结构先理清。真实业务中最困难的一步往往不是执行而是明确“现在这个需求应该走到哪个流程”。AI Agent 能把这一步从人工判断变成自动化就已经减少了大量人员负担。所以评论家说“Agent只是脚本编排”时我不反对但脚本编排在很多业务流程中恰恰是高价值动作。问题不在于Agent能不能全自主而在于你是否找准了它的任务颗粒度。3. AI评论家通常看不到的三层价值如果把AI的价值只理解为“让机器像人一样工作”你会觉得它距离好用还很远。但一个技术带来的改变往往是分层出现的先是替代一些重复动作再造出一些可复用的流程最后改变人们的任务设计能力。这三层价值分别处在不同周期面向不同对象。3.1 表层价值替代重复劳动而不是替代人很多批判者喜欢论证“AI不能独立完成创造性工作”。这不是一个新发现。真正被一线使用的工作方式并不是让AI独立完成某个完整岗位而是让AI完成岗位上最重复、最容易被描述清楚的那部分动作。比如一个数据分析师每天要花时间清洗Excel一个后端工程师每天要写重复的序列化配置一个产品运营每天要把大量用户反馈归门别类。这类任务不产生核心竞争力但它们就在那儿每天都在消耗精力。把这一步替代掉人的时间并没有被释放成完全的空闲而是被移动到更值得做的事里。有人可能会说这不就是让AI给每个人当实习生吗对就是这样。“实习生”的价值不是让你失业而是让你有余力去处理更复杂的判断。现实中大量组织的问题不是缺少高端的战略能力而是高级人员被低端重复劳动淹没。AI在表层做的事情是把人从低端事项里捞出来只是这种价值太分散很难被“一项革命性技术”的故事所概括。评论家如果只看宏观经济数据很难捕捉到这种分布式的效率改善。它不体现为某家公司突然利润倍增而体现为无数个团队在具体任务上减少了工时。这些工时分散到各处加起来是一个不容忽视的量。3.2 中层价值可复用的流程和结构化输出我最看重的一点是模型不再只活在一个聊天窗口里而是可以通过接口被程序调用。文本输入、文本输出看起来简单却让模型变成了一个可以嵌入现有系统的模块。你可以要求它返回JSON可以把它的输出接进数据库、消息队列可以在它犯错后设置超时和重试。这种“API化”让AI从对话工具变成了软件基础设施。当一项技术变成基础设施之后它的评价标准就从“它是否聪明”变成了“它是否稳定、可控、可运维”。你不需要在与它聊天时因为一句错误回复而否定它你只需要在程序里加一层校验如果返回格式不合法就请求重试如果两次重试仍失败就转给人工。这很像我们在微服务架构里对下游系统所做的容错处理。任何一个外部依赖都有失败的可能负责任的系统不会因为依赖可能失败而不接入它而会为失败设计降级路径。这种结构化集成意味着AI的价值可以被度量。你可以统计调用量、成功率、平均节省时间、转人工比例而不是停留在“我觉得它挺聪明”或“我觉得它是骗局”的主观判断上。这也是为什么我更建议开发者从“聊天框使用AI”转变成“API使用AI”因为只有后者才能进入工程体系才能被测试、被观察、被持续改进。3.3 长期价值让个人和团队能处理更大的复杂域还有一个容易被忽略的长期收益为了把任务交给AI你必须学会拆解任务。一个完整的需求往往很难直接丢给模型你需要思考它包含哪些子步骤每一步的输入是什么输出应该是什么样出现某种错误该交给谁处理。这个过程对个人的结构化思考能力训练非常明显。我以前认识一位做运营的同事最初只会把Excel文件上传给AI让它“帮我分析一下”。效果当然不稳定。后来他开始学习写一点脚本为了调用模型他学会了如何用Python读取表格如何用JSON保存结果如何处理异常。几个月后他不再满足于简单问答而是开始设计一个批处理流程清洗数据、分批请求模型、校验输出、把通过和失败的记录分开。他没有上过正式的编程课但自动化意识已经被训练出来了。这种变化放在团队里就是集体的复杂任务处理能力提高了。当每个人都知道“一个大任务可以分成指令、执行、校验三个阶段”时团队的协作模式会发生变化。讨论不再只是“你想让AI做什么”而是“你想让AI承担哪一段哪些环节需要人来兜底”。这种思考方式不会因为具体模型被人遗忘而失效。它会沉淀成一种工程素养长期伴随个人成长。这种价值很难用一次商业数据衡量但也正是我认为很多外部评论家看不到的那一层。4. 真正要讨论的不是“有没有用”而是“怎么用才有用”围绕AI的争论经常变成非黑即白。但在工程实践里AI适配性和任务特征高度相关。同一个模型在一个场景里是生产力工具在另一个场景里就是昂贵玩具。所以与其争论AI整体有没有用不如建立一个“判断自己的任务是否适合AI”的框架。4.1 判断AI是否适合自己的四个问题我一般会建议团队先问自己四个问题这个任务多久发生一次如果一年只做一次不必为它搭建AI流程人工更好。出错后果有多严重如果是医疗诊断、法律判决、敏感数据删改现阶段不能完全交给模型。你能不能把任务输入和输出边界写清楚越清晰越容易让模型稳定发挥。你有没有资源做最后一道人工检查如果没有人工兜底就应该把AI限制在低影响场景。把这些维度整理成一张表会更直观评估维度适合引入AI暂时不合适任务频率高频重复每周至少出现低频一次性任务错误代价低风险可人工复核高风险无法接受错误输入输出边界清晰可结构化描述模糊开放依赖大量上下文兜底机制有校验层、人工审核或规则检查没有任何后置保护从这张表能看出一个趋势AI最适合的场景不是“越难越好”而是“越有边界越好”。它更像是一个被你封装起来的智能模块外面必须有一层协议和一层校验。如果你把一个没有任何边界的大问题直接丢给模型它的表现大概率会让你失望但这不代表方向错只说明任务拆解不到位。4.2 从最小闭环开始的落地顺序一旦确认一个任务适合尝试正确的落地顺序通常不是马上把整个流程自动化而是先做一个最小闭环。这里有一个可以参考的四步法抽出单个样本先手工跑通模型调用确认输入输出格式正常。把输出接到下游写一个最简校验比如JSON格式判断、字段存在性判断。用小批量样本例如10到50条继续跑记录失败类型不要只看成功案例。根据失败数据决定是否扩大范围并补充异常重试和人工兜底。为什么不要一上来就批量执行因为大模型输出具有概率性。刚才那一条成功了不代表下一条同样格式的内容也能成功。模型可能在很长的文本里突然漏掉一个字段也可能在JSON里引入了一个非法字符。如果小批量测试发现了五种失败模式后续扩大时你至少知道要在哪里加重试、哪里加规则、哪里转人工。如果完全没有失败模式数据后续出问题时你会非常被动既不知道是哪步的问题也不知道是模型问题还是流程问题。我的建议是第一次接触某个AI任务时以“把一条样本跑通并记录错误”为目标而不是以“把一万条数据处理完”为目标。单次跑通只代表流程没有断不代表结果稳定可用。4.3 需要避免的三种失败方式根据我自己和新手团队协作的经验最容易导致AI项目失败的往往不是模型能力而是使用方犯了三类错误第一没有定义“正确答案”就上模型。感觉型需求最容易翻车。比如你说“帮我优化这段文案”但你没说清楚是要更正式还是更活泼、要不要保留具体数字、输出多长。模型只能猜猜完你不满意然后你觉得它答非所问。这其实不是模型的问题是需求描述本身不够工程化。第二把模型输出当作最终结果没有校验层。生产任务不是写论文格式错误会导致下游程序直接崩溃。模型返回“25,000”和“25000”之间差异巨大。没有校验层等于把你的流程暴露在所有状态空间下。第三把所有步骤一次性塞进对话不设中间验证点。一个长任务链条越长出错定位越难。更好方式是把任务切成多个子步骤每个子步骤独立输出独立校验。如果最后结果异常沿着子步骤日志查找很快能锁定出问题的那一段。模型接入后如果要排查生产问题建议沿这条链路走先看输入是否干净很多错误来自源数据本身再看模型返回是否完整是否触发截断接着看程序里的JSON解析是否对错误格式做了兜底然后看日志里有没有超时、重试、权限异常最后看校验规则是否覆盖了业务里最常见的异常分支。大多数AI应用故障都不是什么高深问题而是把模型当成万能函数之后忘了给它加异常处理。5. 悲观评论的价值以及它错在哪里前面写了这么多也许有人会觉得我在给所有AI造势。其实不是。Ed Zitron 这类怀疑论者提出的问题非常重要比如模型训练成本、版权争议、算力消耗以及对产品概念的包装。如果完全没有这类人整个行业会被硅谷式乐观语境彻底吞没。我反对的是那种把技术全盘否定的结论而不是反对批评本身。5.1 悲观派说对的部分从行业宏观层面看现在存在大量“为了做AI而做AI”的产品。很多企业采购AI不是因为用户真的需要而是因为老板觉得不拥抱AI就会被淘汰。这种需求驱动的项目上线之后常常连一个像样的评测集和验收标准都没有最后沦为演示用品。同时模型训练和推理的资源消耗确实高得惊人。无论是训练一块大模型所需电力还是云端推理所需的算力成本都不是“所有人都能用得起的公共资源”。这种资源错配让小团队和个人开发者更难参与底层创新也让大公司更容易利用资本壁垒垄断话语权。我相信任何人都应该为此保持警惕。还有版权问题。模型训练数据中哪些素材获得授权生成内容是否涉嫌复制和抄袭目前在法律上仍然充满争议。如果把这些议题放在显微镜下任何一家AI公司都可能有让人担忧的部分。悲观派坚持把这些黑箱问题摊在桌面上是必要的。批评不是破坏而是技术走向成熟前的一次次压力测试。5.2 乐观派经常掩盖的部分乐观派喜欢展示成功的demo但很少主动告诉你模型距离可稳定使用还有多远。幻觉是最常被提起的问题模型会在明明不确定的时候给出一本正经的答案。很多乐观派选择忽略这种不确定性或者轻描淡写地说“只要配合提示词就能解决”。在低风险场景里确实可以解决但当任务变复杂后幻觉仍然会以隐蔽方式出现。更麻烦的是“输出漂移”。同一个提示词同一家公司升级模型后可能返回完全不同的结构和风格。这意味着你无法在把提示词写好后一劳永逸。每一次上游模型版本更新都可能影响下游系统稳定性。因此如果你把AI做进生产流程最好锁住模型版本单独做回归测试而不是无脑跟随最新模型。评测也是一个长期问题。很多公开榜单和分数只能代表特定数据集上的表现与你自己业务数据分布差别很大。一个模型在某个综合榜单上排名靠前不代表它能正确理解你公司的术语。所以最可靠的评测始终是你自己的小批量业务样本上的人工评估。那些包装过头的“真实案例”通常省略了失败率或者只选取了对产品有利的样本看多了容易把人带到坑里。5.3 怎样形成自己的判断而不是站队网络争辩里最廉价的事就是站队。有人因为看到AI骗局而否定一切有人因为押注AI叙事而拒绝承认问题。更务实的做法是建立一手的证据链。我的建议是“三步开地图法”。第一步找出三个会高频影响你工作的任务。第二步用相同的输入集分别跑“纯人工”和“AI辅助”两条路径记录耗时时长、出错次数和修复成本。第三步得出一个有限的结论“在我手里的数据分布上任务A和任务B值得用AI任务C不值得。”这个结论可能不能 generalize 到全行业但至少能指导你自己的下一步决策。这种验证方式会让人很快意识到AI的效用是高度情境化的。它可能在一个公司是效率引擎在另一个公司却因为数据格式和业务口径太特殊而表现平平。不要用别人的成败来定义自己的选择。获得第一手证据后你自然能同时理解悲观派和乐观派为什么各执一词他们很可能是在用不同数据样本评价同一个东西。6. 从“Ed Zitron 错了”到“把AI当成工程材料”回到最初的问题Ed Zitron 真的错了吗如果只看“AI行业存在大量泡沫”这一点他没有错。但他如果因此断定AI技术没有真实价值那就错了。真实价值未必以那种“宏大叙事”的方式存在而可能以非常普通的方式潜伏在每一行自动生成的代码、每一个被压缩的数据清洗任务、每一段被结构化提取的文档里。6.1 AI不是魔法也不是骗局而是概率性的工程材料一个比较接近工程事实的类比是AI不是魔法也不是骗局而是一种概率性材料。就像混凝土它刚被用于建筑时很多工程师担心它不如传统石材稳固。它确实可能开裂但如果设计时考虑荷载、湿度和养护条件它就能成为城市最广泛应用的结构材料。AI也一样你不可能要求一个概率模型像确定性代码一样每次输出相同结果所以你必须为它的概率性设计缓冲。在工程系统里“会出错的组件”并不少见。数据库会超时下游服务会抖动第三方接口会偷偷变更协议。工程师不会因为这些可能风险就拒绝使用它们而是会用重试、降级、熔断、监控、人工兜底等方式把风险控制起来。真正造成灾难的往往不是组件本身会出错而是设计者没有预想到它会出错。所以如果你要长期使用AI最重要的能力不是掌握某个提示词技巧而是会用工程手段管理不确定性。定义输出协议加入格式校验设计失败分支记录每一次异常。当你把这些事情做完AI才从“一个聪明的聊天者”变成了“一个可被测试的服务组件”。6.2 从“写代码”到“设计任务”对于开发者来说AI带来的最大变化短期看是代码生成辅助长期看则是角色重心的迁移。传统开发模式里我们要花大量时间把业务需求转成可执行代码但每个重复函数、每段模板代码未来都可能由模型生成。人的价值会更多落到“设计任务”上把模糊业务问题拆成可执行的子任务为每个子任务定义输入输出和质量标准最后再把各阶段结果组装成完整系统。这听起来不像是普通程序员的工作但正在逐渐成为日常工作的一部分。你和AI协作时最重要的一步不是回车运行而是提前想清楚它的输出要被什么系统消费、出错时该怎么办。这种思路和设计API、设计模块边界非常像。换句话说未来最稀缺的能力不是都会写某一种语法而是能通过提示词、上下文、工具调用等多种方式把没有清晰结论的问题变成一个可以通过计算机一步步验证和修正的流程。这也是我为什么并不焦虑AI写作、AI编程等概念的影响。工具会