如果你长期关注 AI 行业应该能感受到一个明显的撕裂一边是铺天盖地的模型发布与融资新闻另一边是不断有评论家站出来唱衰。过去两年里Ed Zitron 的“AI 高估”叙事在国内技术社区传播很广他的核心论点听起来也确实很有冲击力AI 公司烧掉了太多钱、产品留不住用户、商业闭环迟迟没有出现“AI 泡沫即将破裂”只是时间问题。本文不想站在情绪一边去争论“AI 会不会改变世界”而是想从工程视角把这场争论拆开看。我们会先还原 Ed Zitron 那套说法的逻辑再用生产环境里真正跑起来的研发辅助、RAG、Agent、成本下降和开源模型这几条线索逐条对比。最后会附上一套给技术团队实际使用的“AI 价值验收清单”帮助大家避开营销话术也不错过真实效率收益。如果你是 AI 应用开发者、技术负责人或者正在犹豫要不要把大模型接入业务系统这篇文章会比较适合你。1. 背景Ed Zitron 的“AI 无用论”为什么能成为热点1.1 他到底在批评什么Ed Zitron 是科技行业评论员长期关注科技公司与资本市场的错位。过去一年他连续撰写文章认为 AI 行业被严重高估。把散落在各篇文章里的观点整理出来他的核心判断主要有四点。第一AI 公司普遍陷入“高投入、低产出”的循环。训练和推理成本非常高但面向消费者的 AI 产品付费意愿却很弱。第二很多所谓“杀手级应用”留不住用户。用户试用聊天机器人只是尝鲜很难形成稳定使用习惯。第三AI 技术本身缺乏商业护城河。他认为 API 调用层没有壁垒各模型很快会被同质化最终变成低利润的底层服务。第四资本开支与收入增长严重不匹配一旦融资放缓行业就会开始收缩。这一套观点在中文互联网被简化之后变成了一句很流行的结论AI 是资本用巨额算力堆出来的幻象投入产出不成正比马上就要凉。1.2 为什么技术圈也愿意转发这些观点一个很现实的原因是“AI 过度承诺”的现象确实存在。我们在各种发布会里看到模型写诗、画画、做视频但真到了自己公司的业务场景却经常遇到回答胡说八道、上下文长度受限、接口价格偏贵、私有化部署困难等问题。这些体验上的落差会让开发者觉得“AI 被吹过头了”于是天然倾向于接受高估论。此外技术人普遍对“估值叙事”有戒心。过去几年云计算、元宇宙、Web3 都经历过炒作周期最后很多没有落地。用历史规律推断 AI 也一样会遇到低谷这种思维惯性是可以理解的。但这些观点有一个共同的盲区它们把“对 AI 概念的炒作高估”等价于“AI 技术本身没有价值”。这是两件事。如果我们把目光从新闻头条移开去认真看一看 Cursor、GitHub Copilot、企业内部知识库问答这类已经跑了一两年的真实落地场景会得到完全不同的结论。2. 拆解“AI 没有商业价值”这个命题2.1 错的不是技术是观察单位Ed Zitron 的论述经常拿“某家模型厂商亏了多少钱”作为切入点这确实很有说服力因为数字是真实的。但这里存在一个观察单位的问题模型厂商亏损不等于使用 AI 的企业不赚钱模型厂商没有找到商业模式不等于 AI 能力没有经济价值。基建行业和基建使用者从来不处在同一个财务风险周期里。我们可以拿云计算做类比。早期云计算厂商同样经历了大规模资本投入很多年都不盈利。但与此同时使用云服务的创业公司却大幅降低了服务器采购成本和运维人力。你不能因为卖铲子的公司还在亏损就说挖金子的人也没挖到。放到 AI 领域这个逻辑更清晰。模型厂商烧钱训练大模型是一种极高风险的前置研发投入。但如果一家软件公司把大模型接进自己的客服系统把客诉分类准确率从 70% 提到 90%那它获得的是确定的运营收益。模型厂商亏损与否不影响这家公司自己的 ROI 模型。所以如果我们真要讨论“AI 有没有价值”应该测量的不是某家模型公司的利润表而是所有使用 AI 能力的企业在完成具体任务时相比以前的效率差和成本差。2.2 聊天机器人的留存率说明不了企业级价值高估论里经常提到“ChatGPT 流量在下滑”“用户打开率下降”。这些指标对于面向 C 端的搜索替代品有意义但不能代表 AI 在企业内部的使用情况。企业内部工具与 C 端产品有完全不同的留存逻辑。一个客服坐席每天用 AI 辅助系统处理 150 张工单他不会像普通用户一样“因为无聊而流失”。这个 AI 工具不是内容产品而是生产工具。只要它能让坐席处理速度提升公司就会继续付费。所以我们看到的现象是个人用户对通用聊天机器人的热情可能略有降温但企业对 AI 的采购预算仍在持续扩张。这两者并不矛盾。真正的问题始终是AI 在具体场景里能不能稳定地创造价值而这个问题已经被越来越多生产案例回答了。3. 研发辅助场景已经被验证的“确定性收益”3.1 从补全到 AgentAI 编程经历了质变如果要在所有 AI 应用场景里挑一个“最早跑通价值闭环”的答案一定是 AI 辅助编程。它不需要像自动驾驶那样经历复杂的物理世界验证也不像通用对话那样难以量化收益它天然处在一个可以快速反馈的环境里。最早的 AI 编程工具只是做代码补全。Copilot 在 2021 年推出时大家发现它能基于上下文推荐出下一行代码。当时的体验是惊喜但不稳定很多人把它当作高级自动补全。但到了 Cursor 出现后体验发生了质变AI 不仅能补全单行代码还能理解整个文件、操作多个文件、执行终端命令。再到 Claude Code、Codex、通义灵码这类 Agent 形态工具出现后开发者已经可以把“实现某个功能”这样一句话式的任务交给 Agent 去完成。这种工具带来的收益是极度清晰的减少重复性样板代码编写、减少对陌生框架 API 的检索时间、让开发者把精力集中到架构设计上。团队内外大量真实录屏都展示了从需求到代码的完整链路虽然不同工具表现有波动但整体方向是确定的。下面是 CSDN 技术圈里一个常见的 AI Agent 开发流程图用于说明“人在环上”而非“人在环中”的工作模式。我用文字描述一下需求说明 - Agent 拆解任务 - 检索代码库 - 修改多个文件 - 运行测试 - 反馈结果 ^ | |------------------------------ 人工审核并修正 -----------------------|这个循环的价值在于AI 承担了 80% 的机械性编码工作而开发者只负责审核关键节点和纠正方向。3.2 代码接受率到底能说明什么很多唱衰者喜欢引用“AI 代码接受率不高”的研究。GitHub 的官方数据显示 Copilot 的代码接受率大约在 30% 左右另外也有一些研究认为 AI 辅助会引入更多 bug。只看这个数字确实会觉得“AI 编程不靠谱”。但这里有个数据分析的问题接受率衡量的是“AI 写的代码被完整接受的几率”而实际开发流程中开发者经常只采纳 AI 给出的部分片段再手动修改几行。这种部分采纳很难通过接受率指标体现。更重要的是AI 编程的价值不只在于一口气生成几十行代码还在于它改变了提问方式。开发者以前遇到不熟悉的 API需要打开文档、搜索 Stack Overflow、写测试用例。现在可以直接把报错信息和业务需求粘贴给模型几秒钟内得到一个带解释的解决方案。这种“快速跳过信息检索过程”的能力很难用一个简单的代码接受率去量化。说到底一个技术工具是否有价值不应该只看某个单点指标而应该看整个研发流程的总工时变化。目前主流的真实反馈是中低级开发者在写 CRUD 接口、写单元测试、写 SQL 时效率能提升 30% 到 50%高级开发者虽然提升幅度小一些但可以把省下来的时间用于设计评审。这不是玄学是很多研发团队内部统计出来的趋势。4. 成本下降与开源生态正在改写 AI 的经济账4.1 推理成本的快速下降Ed Zitron 的观点形成于大模型最昂贵的阶段。在他写那篇知名文章时调用顶级模型的 API 确实很贵上下文长度也有限加上当时 GPU 采购价格高给人留下的印象是“AI 成本不可控”。但过去一年里推理成本的变化速度快于绝大多数人的预期。新发布的模型不断在同等能力下把价格压低各家都在卷输入输出的每百万 token 单价。与此同时蒸馏技术让中等规模模型能够在小参数条件下逼近大模型的多数能力。DeepSeek 等团队的论文也公开了一个重要结论通过架构优化可以用显著低于传统方案的推理成本达到接近顶级模型的性能。我没法在这里给出一个完全不过时的价格表格因为模型定价变化实在太快。但你可以记住一个趋势判断2024 年到 2025 年间单位智能的推理成本大致经历了数量级级别的下降。这意味着半年后昨天“用不起”的方案可能变得“完全可接受”。4.2 开源模型让“私有化部署”从幻想变成标配另一个被高估论忽略的趋势是开源模型能力的迅速上升。早几年企业要在内网私有化部署一个可用的大模型基本没有太多选择。而现在开源大模型已经覆盖了从手机端小模型到服务器端中大规模模型的完整谱系。这对企业意味着什么意味着数据安全场景不再被卡住。银行、保险、政务、制造业这些对数据合规要求极高的行业以前完全无法使用云端大模型。而现在他们可以购买几台服务器部署一套开源模型把企业知识库放进去构建 RAG数据不出内网就能实现智能问答。当这样的需求开始释放AI 的采购逻辑就从“要不要上云”变成了“本地要多大算力、多久能回本”。我们看一组更务实的成本对比。虽然具体数字需要按硬件情况测算但思路是通用的。方案A云端 API 接入 - 优点零硬件投入、模型能力最强、维护成本为零 - 缺点数据出域、按量计费、长期用量大时成本可能更高 方案B私有化部署开源模型 - 优点数据不出内网、支持深度定制、单个请求边际成本接近零 - 缺点需要采购 GPU 服务器需要算法或运维工程师支持 方案C混合部署 - 常见做法敏感数据走本地小模型通用创造力走云端大模型 - 适合业务数据分级的企业或预算有限、希望逐步验证的团队4.3 成本低下会让更多“低毛利场景”变成可能AI 是否具有商业价值不能只看单次调用的绝对利润率。有些场景之所以之前没有跑通不是逻辑不行而是成本压不住。一旦推理成本降到足够低原本无利可图的场景就会自然涌现。比如电商评论的分类。假设一个平台每天产生 10 万条评论传统方案是人工标注或者简单关键词过滤。用大模型做精准分类如果单条成本降到 0.001 元以下那么一天只需要 100 元就能完成全量处理。对平台来说这个支出远远小于多请两个运营人员的工资并且分类质量更高。这类场景在成本降下来之前不可能成为生意但成本降下来之后就是日常操作。Ed Zitron 的经济账是基于 2024 年级别的成本计算出来的。但技术行业有一个残酷规律当你用今天的成本去否定一个技术方向时很可能还没等文章发出来成本已经降了一个量级。5. 面向工程实践的思考框架AI 该应用于哪些位置5.1 判别原则能否形成“反馈闭环”聊到这里我们可以提炼一个真正有用的判断标准了。一个 AI 应用是否值得投入不应该看你是否相信“大模型无所不能”而应该看它是否满足三个条件。第一任务必须有明确的结构化输入输出。任务边界越清晰AI 的效果越可控。比如“把这段客服对话分成投诉、咨询、建议三类”就比“帮我处理一下客户”更容易落地。第二错误代价必须可控。AI 会犯错关键不在于它是否犯错而在于犯错之后能否被低成本纠正。在代码辅助场景里AI 生成错误代码会被编译器和测试用例发现纠正成本很低。在医疗诊断场景里错误代价极大就需要严格的兜底方案。第三使用反馈必须能回流到系统。如果 AI 每次回答都独立运行、不积累经验那长期价值就会受限。如果 AI 系统能记录哪些回答被用户采纳、哪些被纠正并将这些信号用于后续优化那它就形成了一个反馈闭环。你可以拿这三个条件去检查那些唱衰者举的“失败案例”。大部分失败项目都至少违背一条原则它们要么把 AI 用于过于开放的任务要么没有设计人工兜底机制。5.2 给团队试点的可执行路径在企业内部做 AI 落地我主推一条“从点到线再从线到面”的渐进路线。第一步是选取一个部门内部的重复性任务例如客服工单分类、周报摘要生成、代码规范检查。这个任务最好每周都消耗部门 5 到 10 个小时的人工时间。第二步是针对这个任务做小范围验证。不要一上来就采购昂贵的大模型平台先用几个星期时间通过调用现有的开源或云端模型编写一段几十行的自动化脚本把成本和准确率跑出一个基础数据。第三步是用真实数据做对照。统计这个任务原来的人工耗时、错误率、处理量再统计使用 AI 之后的数据。如果 AI 方案能在成本不超标的前提下显著节省时间或者提高质量那就可以进入正式开发阶段。更具体一点我给出一个更简单的 Python 判断脚本你可以输入一批手工处理时长和 AI 处理时长自动计算每月节省成本。这不是生产级代码而是给团队算 ROI 用的最小示例。# 文件路径scripts/ai_roi_demo.py # 作用估算“使用 AI 处理固定任务”的月度成本节省 # 使用方式python ai_roi_demo.py def calculate_roi( monthly_task_count: int, manual_minutes_per_task: float, ai_minutes_per_task: float, labor_cost_per_hour: float, api_cost_per_task: float, ) - dict: # 原来人工的总成本 manual_hours monthly_task_count * manual_minutes_per_task / 60 manual_cost manual_hours * labor_cost_per_hour # 使用 AI 后的人工审核成本 ai_hours monthly_task_count * ai_minutes_per_task / 60 ai_labor_cost ai_hours * labor_cost_per_hour # API 调用成本 api_cost monthly_task_count * api_cost_per_task total_ai_cost ai_labor_cost api_cost monthly_saving manual_cost - total_ai_cost return { manual_cost: round(manual_cost, 2), ai_cost: round(total_ai_cost, 2), monthly_saving: round(monthly_saving, 2), } if __name__ __main__: # 示例参数每月 5000 条客服工单人工每条 3 分钟 # AI 辅助后缩到 1 分钟人工成本按 50 元/小时单条 API 成本 0.02 元 result calculate_roi( monthly_task_count5000, manual_minutes_per_task3, ai_minutes_per_task1, labor_cost_per_hour50, api_cost_per_task0.02, ) print(result)运行这个脚本你就能得到一个本地环境下可复现的经济账。示例结果大致如下{manual_cost: 12500.0, ai_cost: 4266.67, monthly_saving: 8233.33}这说明在该参数下AI 每月能为这个任务节省约 8000 多元。它的前提是任务量大、重复性高、结构清晰。如果任务量很少例如每月只有 100 条这个数字就不一定有什么吸引力。所以企业 AI 落地本质上是一个“找场景、做度量、逐步扩展”的工程而不是一个全有或全无的技术信仰问题。5.3 不要忽略 AI 工程化的隐性成本单纯比较 API 费用不算完整AI 工程化还有几块隐性成本不能被忽视。推理服务稳定性、上下文管理、提示词维护、输出格式校验、多轮对话中的状态保持每一项都需要投入开发资源。举一个最简单的例子。当你用 LLM 生成业务需要的 JSON 数据时模型偶尔会在 JSON 外面包裹 markdown 代码块导致解析失败。直接使用字符串截取是一种做法但更稳妥的是使用专门的结构化输出能力或者设置严格的提示词并加入后置校验。这种问题听起来很小但在生产环境里消耗的调试时间远高于写第一版代码的时间。所以我建议团队在做 AI 落地之前先把确切的评估指标和人工兜底路径想好再开始进入编码否则很容易陷在“模型随机不可控”的泥潭里。下面给一个简单的 JSON 后置校验工具示例很多团队在处理 LLM 结构化输出时都会需要# 文件路径utils/llm_json_utils.py # 作用从 LLM 原始输出中提取并校验 JSON import json import re from typing import Any def extract_json_from_llm_response(text: str) - dict[str, Any]: 从 LLM 返回的文本中提取 JSON 对象。 if not text: raise ValueError(模型输出为空无法提取 JSON) # 常见的偷懒写法模型把 JSON 包在 json 代码块里 code_block_pattern r(?:json)?\s*([\s\S]*?) match re.search(code_block_pattern, text) if match: content match.group(1).strip() else: content text.strip() # 防止模型在 JSON 前后输出多余说明文字 # 找到第一个 { 和最后一个 } start_idx content.find({) end_idx content.rfind(}) if start_idx -1 or end_idx -1: raise ValueError(模型输出中找不到 JSON 对象) json_str content[start_idx : end_idx 1] try: return json.loads(json_str) except json.JSONDecodeError as e: raise ValueError(fJSON 解析失败{e}原始内容是{json_str}) from e if __name__ __main__: test_text 好的我理解了你的需求我返回下面的数据结构 json {code: 200, data: {name: CSDN, tags: [AI, 工程]}} print(extract_json_from_llm_response(test_text))在真实开发中这类“模型后处理”工作量并不小。如果一个团队没有提前建立这种基础工具库很容易觉得 LLM API 很难用进而产生“AI 无用”的体验偏差。可实际上问题往往不是 AI 没有价值而是我们需要围绕概率模型重新设计工程体系。 ## 6. 争论背后开发者的正确姿势 ### 6.1 哪些批评值得保留 Ed Zitron 的观点不是全无价值。至少有两部分内容我认为值得开发者记住。第一是对“AI 估值泡沫”保持警惕。任何技术热潮都会过度夸大短期影响如果一家公司只是因为“AI 概念”就获得高估值那么它的商业模式确实需要被质疑。第二是对“一键解决一切”的宣传保持怀疑。大模型是概率系统天生存在幻觉和不确定性把它当作完全可靠的基础设施一定会出问题。 这些批评本质上是在说别盲目相信营销叙事要用数据和反馈做判断。 ### 6.2 哪些批评应该被抛弃 但那些否定 AI 工具实际生产力的说法正在被越来越多工程实践证伪。判断依据很简单你去和那些每周用 Cursor 写代码、用 Coze 搭建 Agent、用开源模型做私有化知识库的一线工程师聊一聊会发现这些人很少会认为 AI 是纯泡沫。他们会一边吐槽 AI 偶尔抽风一边依赖它完成自己不想手写的重复工作。 这就像当年云计算刚兴起时也有很多声音说“企业不可能把核心系统放到别人的服务器上”。后来的故事我们都知道了。技术人最需要的不是站队而是掌握判断工具在具体业务场景里找到反馈指标持续验证。 ## 7. 总结与行动建议 如果你问我“AI 到底是不是泡沫”我的回答是把 AI 概念当成资本叙事来看确实有泡沫成分把 AI 能力当成工程工具来用价值已经真实存在。这两句话同时为真。 对技术团队的下一步我给五条实际建议。 第一不要因为某篇高估论文章就停止探索 AI 应用。你自己选的场景、跑出的数据才是决策依据。第二尽量选择边界清晰、反馈快速的任务比如代码辅助、文档摘要、客服打标、报表生成这些场景最容易见效。第三在可行性验证阶段优先考虑 API 调用或开源模型私有化部署先别一上来就自训模型那是绝大多数团队都不需要做的事。第四设计好错误兜底机制AI 输出一定要有格式校验和人工审核节点。第五把 AI 应用当成普通软件工程来做回归代码规范、测试覆盖、日志追踪和版本管理。 如果你按照这条路线走大概率会得出一个自己的结论AI 没有许多自媒体吹得那么神但它确实已经成了一个能稳定提升效率的工程选项。而当一个技术方向同时满足“真实使用量持续增长”和“单位成本持续下降”这两个条件时再给它贴上“完全无用”的标签就显得不太公平了。 AI 高估论错在哪？从工程实践看大模型与 RAG 的真实价值
如果你长期关注 AI 行业应该能感受到一个明显的撕裂一边是铺天盖地的模型发布与融资新闻另一边是不断有评论家站出来唱衰。过去两年里Ed Zitron 的“AI 高估”叙事在国内技术社区传播很广他的核心论点听起来也确实很有冲击力AI 公司烧掉了太多钱、产品留不住用户、商业闭环迟迟没有出现“AI 泡沫即将破裂”只是时间问题。本文不想站在情绪一边去争论“AI 会不会改变世界”而是想从工程视角把这场争论拆开看。我们会先还原 Ed Zitron 那套说法的逻辑再用生产环境里真正跑起来的研发辅助、RAG、Agent、成本下降和开源模型这几条线索逐条对比。最后会附上一套给技术团队实际使用的“AI 价值验收清单”帮助大家避开营销话术也不错过真实效率收益。如果你是 AI 应用开发者、技术负责人或者正在犹豫要不要把大模型接入业务系统这篇文章会比较适合你。1. 背景Ed Zitron 的“AI 无用论”为什么能成为热点1.1 他到底在批评什么Ed Zitron 是科技行业评论员长期关注科技公司与资本市场的错位。过去一年他连续撰写文章认为 AI 行业被严重高估。把散落在各篇文章里的观点整理出来他的核心判断主要有四点。第一AI 公司普遍陷入“高投入、低产出”的循环。训练和推理成本非常高但面向消费者的 AI 产品付费意愿却很弱。第二很多所谓“杀手级应用”留不住用户。用户试用聊天机器人只是尝鲜很难形成稳定使用习惯。第三AI 技术本身缺乏商业护城河。他认为 API 调用层没有壁垒各模型很快会被同质化最终变成低利润的底层服务。第四资本开支与收入增长严重不匹配一旦融资放缓行业就会开始收缩。这一套观点在中文互联网被简化之后变成了一句很流行的结论AI 是资本用巨额算力堆出来的幻象投入产出不成正比马上就要凉。1.2 为什么技术圈也愿意转发这些观点一个很现实的原因是“AI 过度承诺”的现象确实存在。我们在各种发布会里看到模型写诗、画画、做视频但真到了自己公司的业务场景却经常遇到回答胡说八道、上下文长度受限、接口价格偏贵、私有化部署困难等问题。这些体验上的落差会让开发者觉得“AI 被吹过头了”于是天然倾向于接受高估论。此外技术人普遍对“估值叙事”有戒心。过去几年云计算、元宇宙、Web3 都经历过炒作周期最后很多没有落地。用历史规律推断 AI 也一样会遇到低谷这种思维惯性是可以理解的。但这些观点有一个共同的盲区它们把“对 AI 概念的炒作高估”等价于“AI 技术本身没有价值”。这是两件事。如果我们把目光从新闻头条移开去认真看一看 Cursor、GitHub Copilot、企业内部知识库问答这类已经跑了一两年的真实落地场景会得到完全不同的结论。2. 拆解“AI 没有商业价值”这个命题2.1 错的不是技术是观察单位Ed Zitron 的论述经常拿“某家模型厂商亏了多少钱”作为切入点这确实很有说服力因为数字是真实的。但这里存在一个观察单位的问题模型厂商亏损不等于使用 AI 的企业不赚钱模型厂商没有找到商业模式不等于 AI 能力没有经济价值。基建行业和基建使用者从来不处在同一个财务风险周期里。我们可以拿云计算做类比。早期云计算厂商同样经历了大规模资本投入很多年都不盈利。但与此同时使用云服务的创业公司却大幅降低了服务器采购成本和运维人力。你不能因为卖铲子的公司还在亏损就说挖金子的人也没挖到。放到 AI 领域这个逻辑更清晰。模型厂商烧钱训练大模型是一种极高风险的前置研发投入。但如果一家软件公司把大模型接进自己的客服系统把客诉分类准确率从 70% 提到 90%那它获得的是确定的运营收益。模型厂商亏损与否不影响这家公司自己的 ROI 模型。所以如果我们真要讨论“AI 有没有价值”应该测量的不是某家模型公司的利润表而是所有使用 AI 能力的企业在完成具体任务时相比以前的效率差和成本差。2.2 聊天机器人的留存率说明不了企业级价值高估论里经常提到“ChatGPT 流量在下滑”“用户打开率下降”。这些指标对于面向 C 端的搜索替代品有意义但不能代表 AI 在企业内部的使用情况。企业内部工具与 C 端产品有完全不同的留存逻辑。一个客服坐席每天用 AI 辅助系统处理 150 张工单他不会像普通用户一样“因为无聊而流失”。这个 AI 工具不是内容产品而是生产工具。只要它能让坐席处理速度提升公司就会继续付费。所以我们看到的现象是个人用户对通用聊天机器人的热情可能略有降温但企业对 AI 的采购预算仍在持续扩张。这两者并不矛盾。真正的问题始终是AI 在具体场景里能不能稳定地创造价值而这个问题已经被越来越多生产案例回答了。3. 研发辅助场景已经被验证的“确定性收益”3.1 从补全到 AgentAI 编程经历了质变如果要在所有 AI 应用场景里挑一个“最早跑通价值闭环”的答案一定是 AI 辅助编程。它不需要像自动驾驶那样经历复杂的物理世界验证也不像通用对话那样难以量化收益它天然处在一个可以快速反馈的环境里。最早的 AI 编程工具只是做代码补全。Copilot 在 2021 年推出时大家发现它能基于上下文推荐出下一行代码。当时的体验是惊喜但不稳定很多人把它当作高级自动补全。但到了 Cursor 出现后体验发生了质变AI 不仅能补全单行代码还能理解整个文件、操作多个文件、执行终端命令。再到 Claude Code、Codex、通义灵码这类 Agent 形态工具出现后开发者已经可以把“实现某个功能”这样一句话式的任务交给 Agent 去完成。这种工具带来的收益是极度清晰的减少重复性样板代码编写、减少对陌生框架 API 的检索时间、让开发者把精力集中到架构设计上。团队内外大量真实录屏都展示了从需求到代码的完整链路虽然不同工具表现有波动但整体方向是确定的。下面是 CSDN 技术圈里一个常见的 AI Agent 开发流程图用于说明“人在环上”而非“人在环中”的工作模式。我用文字描述一下需求说明 - Agent 拆解任务 - 检索代码库 - 修改多个文件 - 运行测试 - 反馈结果 ^ | |------------------------------ 人工审核并修正 -----------------------|这个循环的价值在于AI 承担了 80% 的机械性编码工作而开发者只负责审核关键节点和纠正方向。3.2 代码接受率到底能说明什么很多唱衰者喜欢引用“AI 代码接受率不高”的研究。GitHub 的官方数据显示 Copilot 的代码接受率大约在 30% 左右另外也有一些研究认为 AI 辅助会引入更多 bug。只看这个数字确实会觉得“AI 编程不靠谱”。但这里有个数据分析的问题接受率衡量的是“AI 写的代码被完整接受的几率”而实际开发流程中开发者经常只采纳 AI 给出的部分片段再手动修改几行。这种部分采纳很难通过接受率指标体现。更重要的是AI 编程的价值不只在于一口气生成几十行代码还在于它改变了提问方式。开发者以前遇到不熟悉的 API需要打开文档、搜索 Stack Overflow、写测试用例。现在可以直接把报错信息和业务需求粘贴给模型几秒钟内得到一个带解释的解决方案。这种“快速跳过信息检索过程”的能力很难用一个简单的代码接受率去量化。说到底一个技术工具是否有价值不应该只看某个单点指标而应该看整个研发流程的总工时变化。目前主流的真实反馈是中低级开发者在写 CRUD 接口、写单元测试、写 SQL 时效率能提升 30% 到 50%高级开发者虽然提升幅度小一些但可以把省下来的时间用于设计评审。这不是玄学是很多研发团队内部统计出来的趋势。4. 成本下降与开源生态正在改写 AI 的经济账4.1 推理成本的快速下降Ed Zitron 的观点形成于大模型最昂贵的阶段。在他写那篇知名文章时调用顶级模型的 API 确实很贵上下文长度也有限加上当时 GPU 采购价格高给人留下的印象是“AI 成本不可控”。但过去一年里推理成本的变化速度快于绝大多数人的预期。新发布的模型不断在同等能力下把价格压低各家都在卷输入输出的每百万 token 单价。与此同时蒸馏技术让中等规模模型能够在小参数条件下逼近大模型的多数能力。DeepSeek 等团队的论文也公开了一个重要结论通过架构优化可以用显著低于传统方案的推理成本达到接近顶级模型的性能。我没法在这里给出一个完全不过时的价格表格因为模型定价变化实在太快。但你可以记住一个趋势判断2024 年到 2025 年间单位智能的推理成本大致经历了数量级级别的下降。这意味着半年后昨天“用不起”的方案可能变得“完全可接受”。4.2 开源模型让“私有化部署”从幻想变成标配另一个被高估论忽略的趋势是开源模型能力的迅速上升。早几年企业要在内网私有化部署一个可用的大模型基本没有太多选择。而现在开源大模型已经覆盖了从手机端小模型到服务器端中大规模模型的完整谱系。这对企业意味着什么意味着数据安全场景不再被卡住。银行、保险、政务、制造业这些对数据合规要求极高的行业以前完全无法使用云端大模型。而现在他们可以购买几台服务器部署一套开源模型把企业知识库放进去构建 RAG数据不出内网就能实现智能问答。当这样的需求开始释放AI 的采购逻辑就从“要不要上云”变成了“本地要多大算力、多久能回本”。我们看一组更务实的成本对比。虽然具体数字需要按硬件情况测算但思路是通用的。方案A云端 API 接入 - 优点零硬件投入、模型能力最强、维护成本为零 - 缺点数据出域、按量计费、长期用量大时成本可能更高 方案B私有化部署开源模型 - 优点数据不出内网、支持深度定制、单个请求边际成本接近零 - 缺点需要采购 GPU 服务器需要算法或运维工程师支持 方案C混合部署 - 常见做法敏感数据走本地小模型通用创造力走云端大模型 - 适合业务数据分级的企业或预算有限、希望逐步验证的团队4.3 成本低下会让更多“低毛利场景”变成可能AI 是否具有商业价值不能只看单次调用的绝对利润率。有些场景之所以之前没有跑通不是逻辑不行而是成本压不住。一旦推理成本降到足够低原本无利可图的场景就会自然涌现。比如电商评论的分类。假设一个平台每天产生 10 万条评论传统方案是人工标注或者简单关键词过滤。用大模型做精准分类如果单条成本降到 0.001 元以下那么一天只需要 100 元就能完成全量处理。对平台来说这个支出远远小于多请两个运营人员的工资并且分类质量更高。这类场景在成本降下来之前不可能成为生意但成本降下来之后就是日常操作。Ed Zitron 的经济账是基于 2024 年级别的成本计算出来的。但技术行业有一个残酷规律当你用今天的成本去否定一个技术方向时很可能还没等文章发出来成本已经降了一个量级。5. 面向工程实践的思考框架AI 该应用于哪些位置5.1 判别原则能否形成“反馈闭环”聊到这里我们可以提炼一个真正有用的判断标准了。一个 AI 应用是否值得投入不应该看你是否相信“大模型无所不能”而应该看它是否满足三个条件。第一任务必须有明确的结构化输入输出。任务边界越清晰AI 的效果越可控。比如“把这段客服对话分成投诉、咨询、建议三类”就比“帮我处理一下客户”更容易落地。第二错误代价必须可控。AI 会犯错关键不在于它是否犯错而在于犯错之后能否被低成本纠正。在代码辅助场景里AI 生成错误代码会被编译器和测试用例发现纠正成本很低。在医疗诊断场景里错误代价极大就需要严格的兜底方案。第三使用反馈必须能回流到系统。如果 AI 每次回答都独立运行、不积累经验那长期价值就会受限。如果 AI 系统能记录哪些回答被用户采纳、哪些被纠正并将这些信号用于后续优化那它就形成了一个反馈闭环。你可以拿这三个条件去检查那些唱衰者举的“失败案例”。大部分失败项目都至少违背一条原则它们要么把 AI 用于过于开放的任务要么没有设计人工兜底机制。5.2 给团队试点的可执行路径在企业内部做 AI 落地我主推一条“从点到线再从线到面”的渐进路线。第一步是选取一个部门内部的重复性任务例如客服工单分类、周报摘要生成、代码规范检查。这个任务最好每周都消耗部门 5 到 10 个小时的人工时间。第二步是针对这个任务做小范围验证。不要一上来就采购昂贵的大模型平台先用几个星期时间通过调用现有的开源或云端模型编写一段几十行的自动化脚本把成本和准确率跑出一个基础数据。第三步是用真实数据做对照。统计这个任务原来的人工耗时、错误率、处理量再统计使用 AI 之后的数据。如果 AI 方案能在成本不超标的前提下显著节省时间或者提高质量那就可以进入正式开发阶段。更具体一点我给出一个更简单的 Python 判断脚本你可以输入一批手工处理时长和 AI 处理时长自动计算每月节省成本。这不是生产级代码而是给团队算 ROI 用的最小示例。# 文件路径scripts/ai_roi_demo.py # 作用估算“使用 AI 处理固定任务”的月度成本节省 # 使用方式python ai_roi_demo.py def calculate_roi( monthly_task_count: int, manual_minutes_per_task: float, ai_minutes_per_task: float, labor_cost_per_hour: float, api_cost_per_task: float, ) - dict: # 原来人工的总成本 manual_hours monthly_task_count * manual_minutes_per_task / 60 manual_cost manual_hours * labor_cost_per_hour # 使用 AI 后的人工审核成本 ai_hours monthly_task_count * ai_minutes_per_task / 60 ai_labor_cost ai_hours * labor_cost_per_hour # API 调用成本 api_cost monthly_task_count * api_cost_per_task total_ai_cost ai_labor_cost api_cost monthly_saving manual_cost - total_ai_cost return { manual_cost: round(manual_cost, 2), ai_cost: round(total_ai_cost, 2), monthly_saving: round(monthly_saving, 2), } if __name__ __main__: # 示例参数每月 5000 条客服工单人工每条 3 分钟 # AI 辅助后缩到 1 分钟人工成本按 50 元/小时单条 API 成本 0.02 元 result calculate_roi( monthly_task_count5000, manual_minutes_per_task3, ai_minutes_per_task1, labor_cost_per_hour50, api_cost_per_task0.02, ) print(result)运行这个脚本你就能得到一个本地环境下可复现的经济账。示例结果大致如下{manual_cost: 12500.0, ai_cost: 4266.67, monthly_saving: 8233.33}这说明在该参数下AI 每月能为这个任务节省约 8000 多元。它的前提是任务量大、重复性高、结构清晰。如果任务量很少例如每月只有 100 条这个数字就不一定有什么吸引力。所以企业 AI 落地本质上是一个“找场景、做度量、逐步扩展”的工程而不是一个全有或全无的技术信仰问题。5.3 不要忽略 AI 工程化的隐性成本单纯比较 API 费用不算完整AI 工程化还有几块隐性成本不能被忽视。推理服务稳定性、上下文管理、提示词维护、输出格式校验、多轮对话中的状态保持每一项都需要投入开发资源。举一个最简单的例子。当你用 LLM 生成业务需要的 JSON 数据时模型偶尔会在 JSON 外面包裹 markdown 代码块导致解析失败。直接使用字符串截取是一种做法但更稳妥的是使用专门的结构化输出能力或者设置严格的提示词并加入后置校验。这种问题听起来很小但在生产环境里消耗的调试时间远高于写第一版代码的时间。所以我建议团队在做 AI 落地之前先把确切的评估指标和人工兜底路径想好再开始进入编码否则很容易陷在“模型随机不可控”的泥潭里。下面给一个简单的 JSON 后置校验工具示例很多团队在处理 LLM 结构化输出时都会需要# 文件路径utils/llm_json_utils.py # 作用从 LLM 原始输出中提取并校验 JSON import json import re from typing import Any def extract_json_from_llm_response(text: str) - dict[str, Any]: 从 LLM 返回的文本中提取 JSON 对象。 if not text: raise ValueError(模型输出为空无法提取 JSON) # 常见的偷懒写法模型把 JSON 包在 json 代码块里 code_block_pattern r(?:json)?\s*([\s\S]*?) match re.search(code_block_pattern, text) if match: content match.group(1).strip() else: content text.strip() # 防止模型在 JSON 前后输出多余说明文字 # 找到第一个 { 和最后一个 } start_idx content.find({) end_idx content.rfind(}) if start_idx -1 or end_idx -1: raise ValueError(模型输出中找不到 JSON 对象) json_str content[start_idx : end_idx 1] try: return json.loads(json_str) except json.JSONDecodeError as e: raise ValueError(fJSON 解析失败{e}原始内容是{json_str}) from e if __name__ __main__: test_text 好的我理解了你的需求我返回下面的数据结构 json {code: 200, data: {name: CSDN, tags: [AI, 工程]}} print(extract_json_from_llm_response(test_text))在真实开发中这类“模型后处理”工作量并不小。如果一个团队没有提前建立这种基础工具库很容易觉得 LLM API 很难用进而产生“AI 无用”的体验偏差。可实际上问题往往不是 AI 没有价值而是我们需要围绕概率模型重新设计工程体系。 ## 6. 争论背后开发者的正确姿势 ### 6.1 哪些批评值得保留 Ed Zitron 的观点不是全无价值。至少有两部分内容我认为值得开发者记住。第一是对“AI 估值泡沫”保持警惕。任何技术热潮都会过度夸大短期影响如果一家公司只是因为“AI 概念”就获得高估值那么它的商业模式确实需要被质疑。第二是对“一键解决一切”的宣传保持怀疑。大模型是概率系统天生存在幻觉和不确定性把它当作完全可靠的基础设施一定会出问题。 这些批评本质上是在说别盲目相信营销叙事要用数据和反馈做判断。 ### 6.2 哪些批评应该被抛弃 但那些否定 AI 工具实际生产力的说法正在被越来越多工程实践证伪。判断依据很简单你去和那些每周用 Cursor 写代码、用 Coze 搭建 Agent、用开源模型做私有化知识库的一线工程师聊一聊会发现这些人很少会认为 AI 是纯泡沫。他们会一边吐槽 AI 偶尔抽风一边依赖它完成自己不想手写的重复工作。 这就像当年云计算刚兴起时也有很多声音说“企业不可能把核心系统放到别人的服务器上”。后来的故事我们都知道了。技术人最需要的不是站队而是掌握判断工具在具体业务场景里找到反馈指标持续验证。 ## 7. 总结与行动建议 如果你问我“AI 到底是不是泡沫”我的回答是把 AI 概念当成资本叙事来看确实有泡沫成分把 AI 能力当成工程工具来用价值已经真实存在。这两句话同时为真。 对技术团队的下一步我给五条实际建议。 第一不要因为某篇高估论文章就停止探索 AI 应用。你自己选的场景、跑出的数据才是决策依据。第二尽量选择边界清晰、反馈快速的任务比如代码辅助、文档摘要、客服打标、报表生成这些场景最容易见效。第三在可行性验证阶段优先考虑 API 调用或开源模型私有化部署先别一上来就自训模型那是绝大多数团队都不需要做的事。第四设计好错误兜底机制AI 输出一定要有格式校验和人工审核节点。第五把 AI 应用当成普通软件工程来做回归代码规范、测试覆盖、日志追踪和版本管理。 如果你按照这条路线走大概率会得出一个自己的结论AI 没有许多自媒体吹得那么神但它确实已经成了一个能稳定提升效率的工程选项。而当一个技术方向同时满足“真实使用量持续增长”和“单位成本持续下降”这两个条件时再给它贴上“完全无用”的标签就显得不太公平了。