付鹏最近关于 AI 泡沫的讨论在社交平台上传得很广很多人的第一反应是AI 是不是要完了我是不是不该学 AI 了手里相关的股票是不是该跑了但站在技术从业者的角度看这个问题问错了。AI 泡沫争论的核心从来不是“AI 有没有用”而是“AI 能不能赚回它烧掉的钱”。这是资本市场的问题不是技术价值的问题。恰恰相反泡沫挤掉的是讲故事的公司留下来的往往是真正在降低成本、提升效率的基础设施和应用层机会。这篇文章我不想从 K 线图、估值模型、宏观经济角度去聊那些不是我擅长的事。我想换一个视角从 AI 的成本结构、工程化路径和普通人的可执行动作出发拆一拆 AI 泡沫这件事对开发者和普通人的真实影响。读完你会发现泡沫怎么解不是你能控制的但你怎么选技术路线、怎么控制推理成本、怎么把 AI 从“聊天玩具”变成“生产工具”这些是你完全能控制的。1. AI 泡沫之争先分清“叙事泡沫”和“基础设施事实”先给结论AI 确实存在泡沫但泡沫主要存在于资本市场叙事里而不是存在于技术基础设施的落地速度里。过去两年AI 领域的融资规模和估值增长速度是惊人的。随便一个大模型创业公司一轮融资就是数亿甚至数十亿美元估值直接跳到百亿级。与此同时算力采购、数据中心建设、GPU 集群扩容的开支也在同步膨胀。这种“左手烧钱、右手融资”的状态天然会催生泡沫——因为市场给 AI 公司的定价是按照“未来几年收入指数增长”来算的而不是按照“今天的利润”来算的。这就是泡沫争论的根源市场到底在为 AI 的未来买单还是为 AI 的叙事买单但从另一个角度看几个不容忽视的事实是客观存在的GPU 算力需求持续增长英伟达的数据中心业务连续多个季度高速增长这是真实需求驱动的不是 PPT 驱动的。大模型 API 的价格在过去两年大幅下降说明模型推理正在从“稀缺资源”变成“规模化商品”这是产业成熟的标志。大量企业已经把 AI 接入了客服、代码生成、内容审批、数据分析等真实业务流程这些项目不是 demo而是有预算、有 KPI、有验收标准的工程交付。所以我的判断是AI 泡沫的真相是“估值跑得太快而企业端的付费意愿和付费能力还没有跟上”。当市场冷静下来靠概念融资的公司会被淘汰但真正把 AI 落地成生产力的团队反而会在泡沫破裂后获得更好的竞争环境。普通人的正确做法不是“远离 AI”而是“降低对 AI 叙事的依赖提高对 AI 工程能力的掌控”。这句话听起来有点绕翻译成大白话就是不要整天追着新模型发布会跑把注意力放在“我能不能用 AI 把一件事做得更快更便宜”上。2. AI 的成本结构为什么大模型很贵回本很难要理解 AI 泡沫为什么存在先要理解 AI 的成本结构。它和传统软件有本质区别。传统软件的成本主要在“开发期”——你雇一个团队写一套系统写完以后部署在服务器上服务器成本是相对可控的边际成本很低多一个用户几乎不会增加你的投入。AI 应用不是这样。AI 应用的成本核心在“推理期”——也就是每次用户提问、每次生成、每次分析都需要调用模型跑一次而每一次调用都在烧 GPU。这里的成本分四块成本项说明占比趋势训练成本预训练一个大模型需要上万张 GPU 跑几个月头部玩家才需要承担应用层公司基本不涉及推理成本每次调用 API 按 Token 计费或者自建 GPU 服务应用层的核心成本占比最高算力折旧GPU 服务器价格高且硬件迭代快折旧压力大自建推理集群时需要重点考虑电力与运维GPU 集群功耗大散热、机房、运维都是持续性支出长期成本容易被忽略举个简单的例子。一个企业做 AI 客服系统每天约 1 万次对话每次对话平均消耗 1000 Token。如果按市场上主流大模型 API 的价格粗略估算一天的 Token 成本可能在几十元到几百元之间一个月就是上千甚至上万元。如果一个客服系统一个月只能帮企业省下 5000 元人力成本那这个项目就活在亏损边缘。这就是“AI 泡沫”最真实的一面不是技术不行而是收入增速跑不赢算力采购成本。反过来这给技术人员指出了一条明确的职业方向——在 AI 产业链里最不缺的就是会用 API 的人最缺的是能把推理成本降下来的人。谁能用更小的模型、更少的 Token、更聪明的缓存策略做同样的业务谁就是 AI 泡沫时代最稀缺的人才。3. 普通开发者的第一课不要追参数要追 ROI很多开发者对 AI 有个习惯性误区模型越强越好参数越大越好。这放在研究场景是对的但放在业务场景里是巨大的浪费。一个 70B 参数的大模型跑一次的成本可能是 7B 小模型的十倍但业务收益不一定是十倍。你在做一个内部知识库问答工具可能 7B 模型已经能覆盖 90% 的问题你在做一个需要复杂推理的代码审查助手那才需要调用更大规模的模型。所谓 ROI投资回报率放在 AI 工程里就是三句话这个任务真的需要大模型吗能用规则、字典、数据库索引解决的问题不要用大模型。这个任务需要多大规模的模型先跑小模型满足不了再升级不要一上来就上最大杯。这个任务的调用频率可以优化吗缓存、批量处理、相似问题合并都能大幅降低 Token 消耗。除了模型规模还有几个同样影响成本的因素经常被新手忽略因素影响优化思路Prompt 长度Prompt 越长每次调用消耗的 Token 越多精简 Prompt把背景信息放到知识库里按需检索上下文管理多轮对话会把历史消息全部带上Token 快速膨胀加滑动窗口只保留最近 N 轮对话模型选择不同模型价格差异很大简单任务用便宜模型复杂任务才用高端模型缓存策略相似问题重复走模型推理纯浪费加一层语义缓存命中直接返回结果这里真正容易踩坑的地方是上下文管理。很多人在开发 AI 客服、AI 助手时直接把所有聊天记录都塞给模型结果发现没聊几轮Token 消耗就爆炸了。这在本地小模型上还不明显一旦接了商业 API账单会非常刺激。所以我说“不要追参数要追 ROI”本质上是劝大家从“能跑起来”走向“跑得便宜”。这也是 AI 工程化和 AI demo 的最大分水岭。4. 实操路线一从云端 API 开始跑通一个最小可用 AI 功能如果你是一个 AI 新手最稳的入门方式不是买显卡搭本地模型而是先用云端 API 跑通一个最小功能。理由很简单速度快、门槛低、成本可控。我建议所有刚接触大模型开发的读者都先做一个“API 调用 参数调优 成本观察”三个环节的完整闭环。只有亲手观察到 Token 是怎么消耗的、参数是怎么影响输出的才能真正理解 AI 工程化的核心。下面是一个完整的 Python 最小示例使用 OpenAI 兼容的接口格式调用大模型 API# 文件路径examples/llm_api_demo.py import os import time import requests # 从环境变量读取 API Key不要硬编码在代码里 API_KEY os.environ.get(LLM_API_KEY) BASE_URL os.environ.get(LLM_BASE_URL, https://api.openai.com/v1) MODEL os.environ.get(LLM_MODEL, gpt-4o-mini) def chat(prompt: str, max_tokens: int 500) - str: 调用大模型 API返回文本结果。 url f{BASE_URL}/chat/completions headers { Authorization: fBearer {API_KEY}, Content-Type: application/json, } payload { model: MODEL, messages: [ {role: system, content: 你是一个简洁、专业的 AI 助手。}, {role: user, content: prompt}, ], max_tokens: max_tokens, temperature: 0.3, } try: resp requests.post(url, headersheaders, jsonpayload, timeout30) resp.raise_for_status() data resp.json() # 统计 token 消耗 usage data.get(usage, {}) print(f[Token] prompt{usage.get(prompt_tokens)} fcompletion{usage.get(completion_tokens)} ftotal{usage.get(total_tokens)}) return data[choices][0][message][content] except requests.exceptions.Timeout: return 请求超时请稍后重试。 except Exception as e: return f调用失败{e} if __name__ __main__: start time.time() answer chat(用三句话解释一下什么是 AI Agent) print(f[输出] {answer}) print(f[耗时] {time.time() - start:.2f}s)这段代码有四个关键细节API Key 通过环境变量读取不硬编码。很多新手把 Key 传到 GitHub 上导致被盗刷这是最常见的安全事故。max_tokens 限制输出长度防止模型生成超长文本导致费用失控。temperature 设置为 0.3适合事实性回答。如果做创意写作再适当调高。打印 Token 消耗每次调用都留一份成本账单这是 AI 工程化从第一天就该养成的习惯。运行方式export LLM_API_KEY你的API Key python examples/llm_api_demo.py运行后你会在控制台看到 Token 消耗和最终输出。到这里你就已经跑通了“AI 应用”最基础的一环。接下来要做的是把这一环接到你的业务场景里并持续优化成本。5. 实操路线二本地部署小模型把单次推理成本降到零云端 API 有它的优势但很多场景下并不合适企业内部数据不能出私有网络不允许调用外部 API。业务调用量极大按 Token 计费的长期成本不可控。有实时性要求网络来回的延迟不可接受。这时候本地部署小模型就成了非常现实的选择。本地部署的收益是单次推理的边际成本趋近于零数据不出内网延迟更低。代价是你需要一台有一定配置的机器并且承担硬件和维护成本。以 Ollama 为例这是目前最简单易用的本地大模型运行工具。它支持 macOS、Linux、Windows也支持通过 GPU 加速推理。5.1 安装 OllamamacOS 或 Windows 用户可以直接从 Ollama 官网下载安装包。Linux 用户用一行命令curl -fsSL https://ollama.com/install.sh | sh安装完成后检查版本ollama --version5.2 拉取一个小模型以 Qwen2.5 7B 为例ollama pull qwen2.5:7b拉取完成后直接运行测试ollama run qwen2.5:7b 用三句话解释什么是大语言模型5.3 让 Ollama 使用 GPU 运行这是很多人困惑的点为什么我本地跑 Ollama 特别慢大概率是因为默认用了 CPU 推理没有走 GPU。如果你用的是 AMD Ryzen AI 9 HX 370 这类自带 NPU/GPU 的处理器或者 N VIDIA 独立显卡都可以在 Ollama 里启用 GPU 加速。先查看当前 Ollama 是否能识别 GPUollama ps如果显示 GPU 列表为空说明没有启用 GPU 加速。NVIDIA GPU 用户通常安装好 NVIDIA 驱动和 CUDA 工具链后Ollama 会自动识别。AMD GPU 用户需要在安装 Ollama 时确认 ROCm 相关配置或参考 Ollama 官方文档中关于 AMD GPU 支持的部分。一个通用的检查方法是看推理时 CPU 占用率。如果 CPU 占用率接近 100% 而 GPU 占用率为 0说明模型没有跑在 GPU 上需要检查驱动和 Ollama 的 GPU 配置。5.4 用 Python 调用本地模型本地模型和云端 API 最大的不同是 Base URL 变了。Ollama 默认提供 OpenAI 兼容接口端口是 11434。# 文件路径examples/ollama_demo.py import requests BASE_URL http://localhost:11434/v1 MODEL qwen2.5:7b def chat_local(prompt: str, max_tokens: int 500) - str: 调用本地 Ollama 服务不产生 API 费用。 url f{BASE_URL}/chat/completions payload { model: MODEL, messages: [ {role: system, content: 你是一个简洁、专业的 AI 助手。}, {role: user, content: prompt}, ], max_tokens: max_tokens, temperature: 0.3, stream: False, } try: resp requests.post(url, jsonpayload, timeout60) resp.raise_for_status() data resp.json() usage data.get(usage, {}) print(f[Token] prompt{usage.get(prompt_tokens)} fcompletion{usage.get(completion_tokens)} total{usage.get(total_tokens)}) return data[choices][0][message][content] except Exception as e: return f调用失败{e} if __name__ __main__: answer chat_local(写一段 Python 代码用二分查找在一个有序列表中查找目标值。) print(f[输出]\n{answer})这段代码和第四节云端 API 的版本几乎完全一样只是 Base URL 改成了本地地址。这就是为什么我说“先跑通 API再切本地部署”是成本最低的学习路径——你的业务代码可以完全不变只是在配置层切换模型来源。5.5 为什么推荐“API 本地”混合架构在实际项目中最稳妥的方案不是“只用云端”或“只用本地”而是混合架构任务类型推荐方案原因高隐私、高稳定性要求本地小模型数据不出内网长期成本可控复杂推理、高智能要求云端大模型 API小模型能力不足必须上大模型高频、低难度任务本地小模型或缓存便宜、快低频、高难度任务云端大模型 API调用量小成本可接受这套混合架构能用最小的成本满足业务需求也是目前企业级 AI 应用最主流的部署方式。6. 实操路线三从“单次问答”到“AI Agent 工程”如果你已经能熟练调用模型 API也掌握了一些成本优化方法下一步就是理解 AI Agent 了。这也是近一年 AI 领域最热的方向之一。先说一个观点AI Agent 和聊天机器人的本质区别不是模型大小而是“有没有行动能力”。聊天机器人只会生成文本。你问它“帮我查一下杭州明天到北京的航班”它只会告诉你“请打开携程查询”或者编一个航班信息给你——因为它没有获取实时数据的能力。AI Agent 则可以做三件事规划拆解一个复杂任务为多个子步骤。行动调用工具查询数据、操作软件、执行代码、访问数据库。反思根据工具返回的结果判断下一步该做什么直到完成任务。用大白话说聊天机器人是“动嘴”AI Agent 是“动手”。6.1 一个最小的 Agent 循环示例下面是一个极简的 Agent 框架示例不依赖任何重量级 Agent 框架只用 Python 实现一个“模型 工具 循环”的雏形# 文件路径examples/mini_agent.py import json import requests # 假设你的模型服务地址OpenAI 兼容格式 LLM_BASE_URL http://localhost:11434/v1 MODEL qwen2.5:7b def call_llm(messages: list) - str: 调用模型返回文本内容。 resp requests.post( f{LLM_BASE_URL}/chat/completions, json{ model: MODEL, messages: messages, temperature: 0.2, }, timeout60, ) resp.raise_for_status() return resp.json()[choices][0][message][content] def get_weather(city: str) - str: 模拟天气查询工具。实际项目可替换为真实天气 API。 # 这里做了简化处理实际应用要调用天气服务商的 API。 weather_map { 北京: 晴15℃, 上海: 小雨20℃, } return weather_map.get(city, 暂无数据) TOOLS { get_weather: get_weather, } def run_agent(task: str) - str: 极简 Agent 循环 1. 让模型决定是否需要调用工具 2. 如果需要解析工具名和参数并执行 3. 把工具结果追加到对话里让模型继续推理。 messages [ {role: system, content: 你是一个可以调用工具的 AI 助手。 如果需要查询天气按以下格式输出 TOOL_CALL: get_weather | 城市名}, {role: user, content: task}, ] # 限制最大循环次数防止 Agent 陷入死循环 for _ in range(3): response call_llm(messages) print(f[模型输出] {response}) if response.startswith(TOOL_CALL:): # 解析模型输出的工具调用 tool_call response.replace(TOOL_CALL:, ).strip() tool_name, param tool_call.split(|) tool_name tool_name.strip() param param.strip() if tool_name in TOOLS: result TOOLS[tool_name](param) print(f[工具返回] {tool_name} - {result}) messages.append({role: assistant, content: response}) messages.append({role: user, content: f工具返回结果{result}请基于结果回答。}) else: return f工具 {tool_name} 不存在 else: # 模型认为不需要调用工具直接返回 return response return Agent 达到最大轮次任务结束。 if __name__ __main__: result run_agent(今天北京天气怎么样需要穿外套吗) print(f[最终回答] {result})这个示例展示了 Agent 最核心的机制让模型生成一个“要不要调工具、调哪个工具、传什么参数”的决定然后由代码执行工具再把结果喂回给模型继续推理。如果你想在真实项目里落地 Agent不需要自己从零写这套循环。当前主流的专业框架已经提供了成熟的工具调用、多 Agent 协作、记忆管理、权限控制能力比如 LangChain、LlamaIndex以及 Spring AI 等面向 Java 生态的框架。对于 Java 团队Spring AI 的优势是和 Spring Boot 体系天然整合对于 Python 团队LangChain 生态更丰富。选型依据是团队技术栈而不是哪个框架热门。6.2 Agent 真正的难点不是“写框架”而是“控边界”很多新手一上来就想做一个能“自动完成一切”的超级 Agent结果发现模型输出不稳定、工具调用格式错乱、Agent 陷入死循环最后项目烂尾。问题不在模型而在工程。真正生产可用的 Agent 必须具备任务拆解有边界不要试图让 Agent 一次处理一个超大任务拆成可验证的小任务。工具粒度要小每个工具只做一件事输入输出都定义清楚。必须加最大轮次限制防止 Agent 在工具调用里死循环浪费 Token。每一步都要有结果校验不能只把 LLM 的输出当真工具执行的结果要有合法性检查。权限最小化如果 Agent 需要操作数据库、发送邮件、执行代码必须走最低权限账号并且有审批机制。说到底Agent 的核心价值不是“炫技”而是把重复性工作自动化。在一个成熟团队里Agent 通常从最不起眼的环节切入比如自动汇总日报、自动回复工单、自动生成测试用例。先跑通一条链路再逐步扩展。7. 普通人的行动清单怎么在 AI 叙事里找到自己的位置AI 泡沫这个话题之所以能在普通人中引发讨论是因为它触及了一个核心焦虑我是不是会错过这波技术浪潮我是不是会成为被 AI 替代的人我的判断是AI 叙事会波动但 AI 技能的应用价值不会消失。与其纠结“泡沫什么时候破”不如把时间投入到以下三件确定性很高的事情上。第一掌握 AI 工程化的基本功。所谓的“AI 工程化”不是调一个 API 那么简单。它包括模型选型、Prompt 设计、上下文管理、成本优化、评估验证、上线监控。这些能力不依赖某一个特定模型不管今后大模型市场怎么洗牌具备这些能力的人都吃得开。第二用 AI 做出一个真实可用的作品。不要只收藏文章、不要只刷视频动手做一个小工具解决一个你自己遇到的问题。比如做一个“自动整理周报”的脚本做一个“智能查快递”的 Agent做一个“本地知识库问答”的小系统。做完以后发到博客、GitHub 或者团队内部这就是你最好的简历。第三认清自己在产业链里的位置。AI 产业链大致分为四层算力层GPU、云服务、模型层大模型公司、工具层框架、平台、应用开发、业务层具体行业的 AI 应用。普通人最容易进入的是工具层和业务层因为不需要动辄几亿的算力投入也不需要训练基础模型。关键是找到具体业务场景用 AI 产生可量化的效率提升。对于有投资需求的人我有三点提醒这也是我认为相对稳妥的态度不要因为概念热度去买自己看不懂的公司。AI 是技术但股市是博弈两者逻辑完全不同。关注企业的真实收入结构看它到底是在卖 AI 产品还是在卖 AI 概念。如果一家公司 90% 的收入来自传统业务AI 只是宣传语那它就只是一个“老公司戴新帽子”。分散配置不要重仓单一赛道。AI 技术迭代极快今天的龙头可能三年后就被替代单一押注的风险极大。以上内容不构成任何投资建议。我更想表达的是与其花时间预测股市涨跌不如花时间提升自己在 AI 时代的生产力。前者是零和博弈后者是复利积累。8. AI 学习与项目落地中的常见误区这里结合我在社区和技术群看到的高频问题整理一张避坑指南误区表现后果正确做法过度追新每出一个新模型就换一个项目永远在迁移工程化无法沉淀成本失控选一个稳定模型把业务跑通再评估是否切换忽略成本只关注模型效果不看 Token 消耗项目上线即亏损无法商业化每次调用都记录 Token用数据做预算上下文无限膨胀多轮对话直接把所有历史记录都发给模型Token 消耗暴涨响应变慢引入滑动窗口、摘要、向量检索来管理上下文盲目上 Agent想让 Agent 一次搞定所有事不可控、难排查、死循环从最小任务开始限制轮次工具做小忽视评估觉得“看起来没问题”就是没问题模型升级后行为变化导致线上事故建立回归测试集每次换模型先跑评测安全边界缺失Agent 直接操作生产数据库、发送邮件数据泄露、误操作按最小权限原则关键操作走人工审批这六个误区里最致命的是“忽视评估”。AI 应用和传统软件不同传统软件你改一行代码可以明确知道影响范围大模型的行为有不确定性可能这次升级后 95% 的回答更好了但 5% 的回答开始出现严重问题。如果没有一套自动化评估机制你根本不知道哪里出了问题。评估机制不需要很复杂一个简单的思路是准备 50 到 100 条测试用例覆盖你的核心业务场景每次换模型或改 Prompt都把测试集跑一遍记录得分。这样至少在模型迭代时你有据可依。9. 从泡沫叙事到效率叙事今天可以做的事回头看整篇文章的起点——付鹏关于 AI 泡沫的讨论本质上是在提醒大家关注“预期与现实的差距”。但差距存在不代表方向错了。AI 的发展路径从来不是一条直线它会有资本狂热也会有一地鸡毛但技术应用层面的进化从来没有停止。对普通开发者来说眼前最重要的事不是预测泡沫什么时候破不是纠结哪只股票值得买而是把 AI 当成一项可以掌握的基本技能并且用它解决一个具体的、真实的问题。我建议你今天就做三件事打开你的本地环境用 Ollama 跑通一个小模型。写一个调用云端 API 的 Python 脚本学会查看 Token 消耗。把你手上最繁琐的一个事务性工作列出来想想能不能用 AI 自动完成它。这三件事做完你就已经比大多数围观 AI 泡沫的人走得更远了一步。AI 的时代不会因为泡沫破裂而结束。它会从“讲故事的阶段”切换到“算账的阶段”。而会算账的人永远稀缺也永远不会被浪费。