关于 AI 泡沫的争论每隔一段时间就会出现一次“爆款”。Ed Zitron 是这类批评声音里很有代表性的一位。他的核心观点概括起来并不新鲜很多 AI 产品没有真实需求模型公司烧钱规模巨大技术成果可能只是资本叙事。这个判断听起来很有逻辑尤其在 C 端产品增长放缓、明星模型商业化困难的时候几乎每个开发群里都会有人转发类似观点并感慨“这次可能真的是泡沫”。我对这种质疑持保留态度不是因为它提醒估值风险不对而是因为它衡量 AI 的方式停留在两年前。Ed Zitron 的批评几乎都落在“聊天机器人使用体验”和“公司财务模型”上却很少认真看待模型接入生产系统之后发生的变化。过去一年我观察到的行业信号不是“用户不再玩 AI”而是 AI 正在从聊天工具变成可以被评估、被灰度、被回滚的软件模块。这才是判断 AI 是否有真实价值时更值得关注的维度。这篇文章不打算证明“所有悲观论都错了”。技术圈需要泡沫警告否则容易在概念炒作里过度投入。但我想把争论拉回工程界面当你不再以日活、下载量、发布会演示来衡量 AI而以推理成本、任务完成率、失败回退、可观测性来衡量时会看到一条完全不同的曲线。读完这篇文章你可以得到一套更完整的判断框架也可以通过一个最小实验验证你所在团队的 AI 流程到底有没有用。1. Ed Zitron 的批评结构真正错在评价坐标系1.1 批评声音中很有价值的部分先说他“对”的地方。如果只看一个模型公司的收入模型和估值确实会发现很多不对等训练一次大模型的成本极高而应用层的付费意愿仍然脆弱。AI 行业存在明显的“军备竞赛”特征模型能力一旦被开源社区追平闭源厂商的定价权就会迅速削弱这是今天很多 AI 公司面临的实际经营问题。Ed Zitron 式的批评者敏锐地捕捉到了这一点。他们提醒创业者不要天真地认为“只要有 AI 就能带来增长”也提醒企业不要在没有评估指标的情况下空转一个 AI 系统。这种警惕性对技术行业是有益的它会让预算决策者从“要不要跟风”变成“凭什么相信它能产生回报”。如果所有讨论都像这样停在“财务与营销层面”我会认为这是一个健康的预警机制。1.2 被忽略的工程时间差问题出在这一步之外。批评者普遍把 2022 到 2024 年的用户体验当作 AI 技术能力的终局用“聊天机器人留存率不高”推出“AI 没有实用价值”。这是一个典型的评价坐标系错位。任何通用技术进入产业时都会经历一个时间差。第一代应用往往直接复刻旧的交互模式比如把人工搜索改成对话框搜索把规则问答改成生成式问答。用户一开始觉得惊艳随后很快疲劳接下来会问它到底替我解决了什么问题这个阶段确实会看到增长回落但这不代表底层技术没有意义。更准确的解释是人们仍然在寻找和底层能力匹配的交互形态。等这个时间差过去之后AI 的价值会移动到平时不容易被用户看见的模块里它帮你把 10 万份客服工单先分类一遍帮你把需求文档转成测试用例帮你在 CI 阶段分析一次变更可能影响哪个模块帮你在检索库中把知识切块后再送入生成流程。这些都不是“聊天机器人日活”能反映的指标但它们是真实的工程生产力。1.3 认知差异消费者技术 vs 基础设施技术聊天机器人属于消费者技术而大模型在今天更像一种基础设施计算单元。消费者技术要回答“用户为什么每天打开”基础设施技术要回答“处理每单位任务需要多少成本、多少延迟、多少人工复核”。用消费者技术的指标衡量基础设施技术自然会得出“没有需求”的结论。今天我们不会问“数据库为什么没有留存率”也不会问“消息队列为什么不够有趣”但会关心它们的吞吐、稳定性和运维成本。AI 进入成熟期后应该被当成一种新型的“软件构建原材料”而不是另一个互联网应用。这正是我判断 Ed Zitron 观点存在结构性问题的地方。他指出的财务泡沫可能为真但他用来证明“AI 无用”的证据大多数只适用于消费级聊天机器人这一个早期品类。2. 为什么用“聊天机器人日活”衡量 AI 是过时的坐标系2.1 从单轮对话到多工具调用两年前的 AI 应用大多是单轮问答用户给一句话模型补一个后续然后退出。这种形态的留存天然不稳定因为高频需求有限模型也无法主动改变业务流程。批评者看到的“用户玩几天就不再玩”就是这种交互形态的直接结果。今天工程上更有价值的使用方式已经变成多步骤工具调用。用户提出一个目标模型把目标拆解为多个子任务然后按顺序调用检索模块、业务 API、数据库查询或代码解析器等外部工具再把结果汇总成最终输出。这个流程不再像一个聊天窗口更像一个自动化工作流而用户关心的也不是每一轮“对话是否有趣”而是最终那个任务是否被完成。举个例子一个客服 Agent 收到用户投诉后要完成用户意图识别、订单状态查询、退款政策匹配、生成回复文案、提交工单这五步。每一步都可能调用不同的系统最终以工单关闭率作为评估指标。这时讨论“用户是否愿意一直和它聊天”就变得很奇怪了用户当然不想和系统聊天用户只想知道退款进度。2.2 RAG、Agent、MCP 为什么不是营销词经常被讨论的 RAG检索增强生成并不是一种新玩法而是一种降低成本、控制幻觉的工程手段。它让模型在生成答案前先从企业知识库中检索相关片段然后再基于片段作答。没有 RAG 的方案要求模型记住所有业务知识这既昂贵又不稳定。Agent 则把模型从“文本生成器”升级为“任务规划器”。它不一定要自己完成所有动作而是学会调用搜索结果、代码解释器、业务 API并在失败后尝试别的路径。MCP模型上下文协议一类的标准化尝试本质上是在给不同工具定义统一的接入格式让 Agent 不再每个项目重写一套函数调用协议。这些概念并不解决“用户会不会聊天”的问题却决定了模型能否真正进入业务流程。2.3 观察窗口不同的两种结论如果观察窗口停留在对话文本AI 很容易被描述成“成本高昂的自动补全”。如果观察窗口放到端到端的任务链AI 是在替代过去需要大量 if else、状态机、规则引擎和人工运营才能维护的自动化系统。同样一个模型嵌入不同的技术架构产出的效果差异可能非常大。这也解释了为什么有些团队觉得大模型只是玩具有些团队却已经在用几个小模型组合解决过去需要上百条规则才能解决的事。真正拉开差距的不是模型本身而是工程系统是否把模型放进了正确的位置。3. 成本曲线决定 AI 是否有真实价值的关键变量3.1 成本下降往往比舆论转向更真实每次“AI 泡沫论”出现都有很多人举出“某次推理调用成本为何这么高”的例子。这里的逻辑容易误导人他们常拿超大参数模型的定价作为全部 AI 成本的代表但工程上真正推动采用率增加的是成本曲线的快速下移。一个稳定健康的 AI 系统不会在所有请求上都调用最强模型。系统会根据问题难度做路由简单的分类任务交给小模型复杂推理任务才交给更大模型。加上量化、蒸馏、缓存等工程手段使得很多曾经“算不过来”的任务逐渐变得经济上可承受。从公开的模型定价趋势可以看出同一类任务用成熟的中小模型处理成本比早期拼接出来的解决方案有明显下降。这个变化不依赖某一家公司的营销而是由芯片效率、模型结构优化、推理框架成熟度共同推动的。3.2 部署形态决定真实技术成熟度判断 AI 是不是泡沫除了看财务数据还需要看人们如何部署模型。模型部署通常有几个层次调用公有云 API、在私有云中运行开源权重模型、在本地工作站模型跑批任务、在边缘设备上使用量化后的轻量模型。每一层都代表一种工程实践场景。如果 AI 只停留在浏览器搜索引擎的聊天窗口里支撑不了太多产业链但当企业开始把模型权重放进自己的 Kubernetes 集群、给不同部门分配配额、监控推理失败率时它就已经成为系统架构的一部分。从实践变化来看越来越明显的趋势是“默认不自己预训练而是选择开源基座模型并做领域微调”。这与两三年前“只要堆算力就能做出大模型”的叙事有很大差异。真正把 AI 做出生产力的团队往往不是在训练新大模型而是在配置已有模型并让它稳定运行。3.3 一个最小接入示例用兼容接口统一调用不同模型为了让讨论更具体下面通过一个最小示例展示 AI 如何成为可以被代码调用的模块。这里的调用协议采用常见的 OpenAI 兼容接口无论你接云端服务还是接本地通过 vLLM、Ollama 等工具启动的模型都可以用类似结构。# llm_call.py import os import time import requests def chat( prompt: str, model: str local-qwen2.5-7b-instruct, max_tokens: int 1024, ) - tuple[str, float, dict]: 调用一个兼容 /v1/chat/completions 的模型接口。 返回 content: 模型回复文本 elapsed: 调用耗时秒 usage: 接口返回的 token 用量 endpoint os.getenv(AI_ENDPOINT, http://localhost:8080/v1/chat/completions) api_key os.getenv(AI_API_KEY, ) headers {Content-Type: application/json} if api_key: headers[Authorization] fBearer {api_key} payload { model: model, messages: [{role: user, content: prompt}], temperature: 0.1, max_tokens: max_tokens, } start time.time() resp requests.post(endpoint, headersheaders, jsonpayload, timeout60) resp.raise_for_status() elapsed time.time() - start data resp.json() content data[choices][0][message][content] usage data.get(usage, {}) return content, elapsed, usage这个封装看起来简单但在工程上已经有三个可观测点调用耗时、返回文本、token 用量。只要把这三项记录到日志或监控系统AI 请求就不再是不可解释的黑盒。运行命令可以是export AI_ENDPOINThttp://localhost:8080/v1/chat/completions export AI_API_KEY python -c from llm_call import chat; content, latency, usage chat(请用一句话解释大模型部署中的量化是什么意思); print(content); print(latency); print(usage)如果接口返回正常会看到一句模型解释外加耗时和用量。如果启动失败第一步应该检查AI_ENDPOINT对应的服务是否真的在监听端口以及模型名称是否与后端实际加载一致。3.4 成本拆解计算公式一个更完整的成本验证方式是把请求量、单次输入 token、单次输出 token 和部署成本放到同一个表达式里。# cost_estimate.py def estimate_monthly_cost( requests_per_month: int, avg_prompt_tokens: int, avg_output_tokens: int, prompt_price_per_million: float, output_price_per_million: float, fixed_cost: float 0.0, ) - dict: 估算按月调用某个模型 API 的直接费用。 prompt_tokens_total requests_per_month * avg_prompt_tokens output_tokens_total requests_per_month * avg_output_tokens prompt_cost prompt_tokens_total / 1_000_000 * prompt_price_per_million output_cost output_tokens_total / 1_000_000 * output_price_per_million total_cost prompt_cost output_cost fixed_cost return { monthly_prompt_tokens: prompt_tokens_total, monthly_output_tokens: output_tokens_total, monthly_cost: round(total_cost, 2), } if __name__ __main__: result estimate_monthly_cost( requests_per_month100_000, avg_prompt_tokens800, avg_output_tokens200, prompt_price_per_million2, output_price_per_million8, fixed_cost100, ) print(result)这个脚本的意义不在于得出一个精确财务数字而在于提醒你上线任何 AI 功能之前必须把 token 用量当成数据库查询次数一样对待。当你能把一次任务的成本算清楚你也就具备了回答“AI 是否值得用”的基本能力。4. 反泡沫实验怎样证明一条 AI 流程真的有效4.1 不要争论概念先建立评测基线“AI 到底有没有用”不应该停留在观点交锋上。更务实的做法是选择一个具体的重复性任务建立离线评测集然后测量模型改造前后的效果差异。这就像给 AI 写单元测试一样先定义什么是“它答对了”再让模型反复跑。建议选择的第一个任务要有三个特点第一你已经有历史数据或业务答案可以标注答案第二任务本身会反复出现而不是一次性需求第三结果的正确性可以由人工快速复核。例如客服工单分类、退款原因归类、日志异常类型判断都很适合作为新手实验。4.2 准备一个小型评测集下面用一个非常简单的“客服诉求分类”任务来演示。先把少数几条实际案例放入 JSON 文件[ { id: case-001, text: 我刚付款就取消了订单为什么一直没有给我退款, expected: 退款申请 }, { id: case-002, text: 我收货地址填错了能帮我改成公司地址吗, expected: 订单修改 } ]评测脚本会逐个调用模型判断模型输出是否落在期望类别中。为了让结果更稳定可以在 prompt 中要求模型只输出类别不要展开解释。# eval_classify.py import json import os from llm_call import chat LABELS [退款申请, 订单修改, 账号安全, 其他] def classify(text: str) - str: prompt ( 请判断以下客户诉求属于哪个类别。\n 可选类别退款申请、订单修改、账号安全、其他。\n 只输出一个类别词不要解释。\n f客户原文{text} ) content, _, _ chat(prompt, modelos.getenv(MODEL_NAME, local-qwen2.5-7b-instruct)) content content.strip() for label in LABELS: if content label or content.startswith(label): return label return 其他 def main(dataset_path: str) - None: with open(dataset_path, r, encodingutf-8) as f: cases json.load(f) total len(cases) correct 0 wrong_cases [] for case in cases: pred classify(case[text]) if pred case[expected]: correct 1 else: wrong_cases.append({id: case[id], expected: case[expected], pred: pred}) print(f数据集样本数: {total}) print(f正确数: {correct}) print(f准确率: {correct / total:.2f}) print(f错误案例: {wrong_cases[:5]}) if __name__ __main__: main(eval_dataset.json)运行方式python eval_classify.py预期输出不是“某个神奇分数”而是一个可以直接对照的准确率。如果准确率低于预期通常不是模型“不聪明”而是问题定义不够清楚、标注标准不一致或者 prompt 没有限制输出格式。这时候应该先检查少数错误案例观察模型输出的真实形态。4.3 先关心趋势再追求绝对值任何小规模评测集都会存在过拟合风险。你请模型处理 20 条案例得到 90% 准确率但它未必能推广到全部线上请求。所以更稳妥的做法是给这个实验增加两个维度第一个维度是先做小批量人工复核。把无法判断题干的案例收集起来由业务人员写批注。这个动作看起来原始却是 AI 项目里最有价值的数据积累。第二个维度是把离线准确率和线上业务指标分开记录。分类任务对应“人工二次复核率下降了多少”生成任务对应“编辑修改率下降了多少”。只有当线上业务指标发生变化时才能证明 AI 确实贡献了价值。这也是“AI 是泡沫论”中最常忽略的部分。许多批评只看到模型当前还存在错误却不理解工程实践正是在错误中建立评估和校正机制的。5. AI 编程最容易验证也最需要工程纪律5.1 为什么 AI 编程场景很难用“日活”评估AI 编程经常被低估为“代码自动补全”。原因是工程师使用的 AI 插件不是每天要打开两次的独立 App它嵌在 IDE 里一次代码联想可能只帮助减少了 10 秒查找时间。但如果你统计一个开发团队的“上下文切换次数”AI 编程的价值会非常明显它减少了从编辑器切到搜索引擎、再切到文档站点查找语法的频率。真正发挥作用的不是“让 AI 直接写完整功能”而是“让 AI 在明确约束下完成一个小步骤”。比如写单元测试、生成数据迁移脚本初稿、将一段老旧代码翻译成新版本语法、解释一段难以读懂的异常日志。这些任务都有相对固定的正确标准容易被人工复查也适合用来建立信任。5.2 把 AI 代码审查放入 CI 而不只是 IDE如果把 AI 编程局限在开发者本地那么很难形成团队级经验。更推荐的实践是让 AI 在 CI 流程里做一次“预检查”。可以先从一段小型 diff 摘要开始让模型读取git diff的输出尝试总结变更范围并标记是否涉及危险函数。这里的关键不在“AI 能不能替代代码审查”而在于把 AI 的能力纳入现有工程流程中保留人类控制权。自动生成代码审阅结果后仍然需要由人工处理其中的高风险提示。任何直接让 AI 改写并合并代码的做法在大多数组织中风险都过高。5.3 不要忽视统计代码被采纳的过程为了证明 AI 编程有价值需要统计“AI 建议被采纳的比例”。许多 IDE 插件本身提供了类似的统计但团队也可以用最原始的方式记录每次通过 AI 辅助生成并最终提交的代码都打一个特殊前缀或关联一个任务标签。不要信任“屏幕时间”之类的间接数据更可靠的是代码提交记录里的引用标识。当团队统计到某个重复性样板代码的生成采纳率超过 70% 时通常说明这个场景值得继续投入。如果始终低于 30%就应该调查是 prompt 约束不够还是任务类型根本不适合模型处理。这个统计过程本身就是一次管理上的“反泡沫校验”。6. AgentAI 工程化的下一层试金石6.1 Agent 不再只是概念而是系统设计问题Agent 的成熟度是判断 AI 是否真进入工程化的又一关键指标。所谓 Agent不是说给模型一个开放权限让它随意行动而是给它定义一组受限工具、一套调用策略、若干失败返回路径并记录所有中间决策。当模型只能在允许的工具范围内行动时它才算是可以进入生产系统的软件组件。一个典型的 Agent 由四个部分组成模型、工具集合、任务规划器、安全边界。模型负责理解任务和生成下一步动作工具包括搜索、数据库查询、HTTP 请求等任务规划器决定先调用哪个工具安全边界限制模型能访问的资源和可执行的高风险操作。6.2 高风险工具必须默认关闭这种能力很容易被误解为“Agent 什么都能做”。实际工程中恰恰相反越是自动化能力强的系统越需要细化权限。默认情况下Agent 应该只能读取白名单数据不能执行修改、删除、退款、发布等高风险操作。下面给出一个最小配置示例重点不是为了复刻某个框架而是表达一种权限设计思路# configs/customer_agent.yaml agent: name: customer-refund-agent model: fast-model fallback_model: strong-model max_steps: 6 timeout_ms: 15000 tools: - name: search_order permission: read timeout_ms: 3000 allowed_operations: - GET /api/v1/orders - name: create_ticket permission: write timeout_ms: 5000 allowed_operations: - POST /api/v1/tickets - name: refund permission: disabled # 高风险操作默认不开放在这里“refund”被显式关闭。即使模型规划出退款动作系统也会因为工具权限不足而拒绝执行。这个设计的重要意义在于Agent 的价值不是“完全代替人”而是“在有限权限内帮助人更快完成任务”。6.3 Agent 必须有日志链路和人工可干预切口Agent 和普通 API 调用的最大区别在于它会连续进行多次工具调用并产生一个决策路径。如果这个过程没有日志一旦出现错误排查难度会迅速上升。生产级 Agent 至少应该记录四类信息每次模型生成的原始消息、每个工具的入参与出参、每次调用的耗时、最后的终止原因。这样当业务方反馈“某个 Agent 结果不对”时可以回放这个决策序列找出是模型理解错了、工具返回异常还是权限配置阻止了正确操作。对任何涉及资金、数据删除、权限变更的 Agent 动作都应该加入“人工确认”的闸门。这不能靠提示词里的“请你先询问用户”来实现而应该在系统流程中强制增加审批节点。7. 常见误区与问题排查7.1 误区对照AI 讨论中经常出现几个重复性误区这里用一张表说明我的判断误区更接近事实的判断AI 没有杀手级应用杀手级应用会被拆成很多细小的自动化场景不再以独立 App 形态出现模型必须参数量越大越好路由、量化、蒸馏让中小模型在很多任务上已经够用Agent 失败率高就不能用只要保留人工审批和逃生通道部分失败不会导致系统不可控开源模型会迅速抹平闭源优势闭源的优势更多转向服务、工具链和稳定性不再单纯依赖参数调用一次大模型很贵只要控制请求量、缓存和模型路由成本能降到可接受范围只要模型回答流畅就是好用回答流畅不等于任务完成必须绑定业务指标验证7.2 部署与调用排查方法在 AI 应用落地过程中最容易遇到的并不是模型幻觉而是一些枯燥的工程问题。下面是一张排错参考表问题现象可能原因排查方式解决方案请求超时模型服务并发不足或推理队列过长查看模型服务日志和负载指标扩容并发实例或减小单次 max_tokens返回内容为空prompt 触发了内容过滤或解码参数不当检查 raw response 中的 finish_reason调整提示词或在合规范围内调整系统限制结果不稳定temperature 过高复现同一请求观察输出差异把 temperature 调低分类任务尽量设为 0模型称自己不知道上下文未正确传入历史对话或检索结果检查调用 API 时 messages 参数确认 RAG 检索片段进入系统消息而不是只写在用户问题里正确率低于预期评测集标注不一致让两个人独立标注再对比差异先统一标注规范再跑模型生产环境误操作权限未收敛检查 Agent 工具配置默认关闭高风险操作开启人工审批通常情况下第一步永远是看日志而不是反复修改提示词。日志里往往已经记录了问题发生的环节。8. 工程团队可以立刻做的最小实验集如果你是技术负责人不需要等外部争论有结论后再决定要不要投入 AI。可以从四个被反复验证过的场景开始做小范围试验。第一个实验是内部知识库问答。选择 30 个高频问题让模型从团队已有文档中检索并回答由核心成员打分。这个实验能直观展示 RAG 的成效和局限。第二个实验是客服或工单分类。准备过去 2 周的工单用模型打标再与人工标签对比。这里能得到清晰的准确率和召回率。第三个实验是代码变更摘要。拉取最近 20 个拉取请求的 diff让模型生成摘要观察有多少可以直接用于 code review。第四个实验是错误日志初筛。让模型判断一批异常日志的紧急等级和运维人员的判断对比。所有实验都要设置“不通过时的退出条件”。如果准确率低于 60%就暂时不上线如果在 60% 到 80% 之间考虑加入人工复核流程只有超过一个预设阈值再加上业务指标改善后才进入生产。这个流程能有效防止 AI 项目变成一场长期赌注。团队纪律同样重要。每个 AI 项目都要明确所有者、记录错误案例、保存模型配置版本并且不把 prompt 当作无法管理的魔法字符串而是存入版本库像代码一样审查。只有这样当模型或服务升级时团队才能快速定位是数据变了、prompt 变了还是模型权重变了。9. 写在最后不要急着给 AI 下终局结论Ed Zitron 式批评的价值在于提醒所有人AI 不是一个“只要贴上去就能增长”的词。但技术演进并没有停在“聊天机器人”的早期阶段。如果你只站在用户产品体验和短期收入模型的外面观察看到的当然全是泡沫如果你进入系统内部把 AI 作为需要评测、部署、监控和保护的工程模块看到的则会是一条仍然陡峭的生产力曲线。我更愿意相信的判断是这一轮 AI 的价值不在于诞生了多少个爆款 Chatbot而在于它让很多过去只能靠人肉分类、规则引擎和大量低质量文档堆砌的任务第一次具备了自动化处理的可能性。这与“模型是否已经接近人脑”无关也与“公司估值是否过高”无关它只取决于一个简单问题你的系统是否真的因此降低了完成某项任务的复杂度。对开发者和技术团队来说最好的回应不是在网上争论谁对谁错而是回到自己的业务里选一个最少十次会出现一次的重复任务建立评测集跑通基线记录成本再决定下一步。建议你先收藏这篇文章按照评测脚本的思路建一个最小验证而不是急着在讨论区站队。只有当你能用数据证明“引入 AI 后某个指标发生了变化”你才真正参与了这场技术演进的验证。