最近和几个做 AI 应用的朋友聊天几乎每个人都会问同一个问题AI 到底是不是泡沫答案还没聊出来又有人开始追下一个热点仿佛只要踩中某个风口前面的问题就自动消失了。这种事让我很不安。泡沫论和风口论其实是同一枚硬币它们都在猜一个宏大的答案却忽略了一个更具体的问题——在 AI 热度波动的时候你正在做的流程、产品和用例到底是会死掉还是会活下来。我更愿意把这个问题当成工程问题来拆AI 会不会有泡沫不是你能决定的你能不能在一个可能降温的技术周期里持续产生价值才是你能决定的。这篇文章不预测行情只聊一个更实用的判断框架怎么知道自己的 AI 项目是“真需求”还是“伪需求”以及怎么在大环境不明朗的时候把工程做扎实。1. 讨论 AI 泡沫之前先把它拆成四层当人们争论 AI 是不是泡沫时往往不是在争论同一个事物。有人在说算力是不是过剩有人在做大模型价格战有人在抱怨应用不好用还有人只是觉得“AI 编程工具还挺好使”。这些话题全都挂在 AI 名下但经济逻辑完全不同。1.1 四层结构基础设施、模型、应用、工具为了不被一句话带偏我通常把 AI 拆成四层来看基础设施层包括计算芯片、数据中心、网络等。它的成本大头是资本开支和能源关注的是利用率、折旧和扩容速度。模型层包括大模型的训练、开源源码、API 服务等。它的成本大头是训练和推理关注的是参数规模、推理成本、价格变化和版本迭代。应用层基于模型能力构建的业务产品。它的成本大头是获客、留存、内容或服务交付关注的是用户愿不愿意持续使用。工具层嵌入日常研发、办公、设计等流程的辅助产品。它的成本大头是产品体验和行业适配关注的是能不能变成天天打开的习惯。四层关系可以用下面这张表简单概括层级典型角色主要成本来源泡沫风险的主要来源对普通开发者的意义基础设施算力提供方资本开支、能源、维护产能和需求错配少数人的生意成本会传导到上层模型层模型研发与 API 服务训练、推理、人才价格战和同质化尽量把它当作可替换能力应用层业务产品获客、留存、交付需求是否真实、留存是否稳固最有可能创造长期价值工具层流程助手产品体验、行业适配能否持续被使用要和具体工作流绑定这张表不一定严谨但它能很快解释一个现象为什么有人觉得 AI 发展火热有人觉得 AI 落地很虚。因为两个人站在不同楼层看到的东西完全不同。1.2 分层之后很多争论就能对上了分层之后再听“AI 是不是泡沫”的讨论你会发现很多矛盾观点其实不矛盾。基础设施层的景气不直接等于应用层的繁荣。算力需求持续上涨可能是因为模型还在训练和推理并不代表用户愿意为某个应用付费。反过来应用层增长缓慢也不代表 AI 没有用可能只是说明“能跑通的场景”还没多到足以撑起独立商业模式。模型层同样有自己的节奏。模型能力在迭代API 的定价策略也在调整。从长期看能力会从稀缺走向普及价格会变得更可负担但短期内不同服务商差异很大不能一概而论。价格下降对模型服务商是压力但对外层开发者往往是利好。当一次推理的成本降到一个临界点很多过去不值得做的场景就会重新变得值得。所以泡沫论和机会论不一定非要分出胜负更可能的情况是某一层正在降温另一层正在开启。我比较认同的一个判断是普通开发者和中小团队不容易在基础设施层和模型层建立壁垒因为这两层拼的是资本、数据和顶级人才反倒是应用层和工具层离用户最近可以用较少的资源做出差异。与其把时间花在预测哪一层先崩不如先想清楚自己站在哪一层以及这一层的价值来源是什么。2. 泡沫对工程界的真正意义不是警告而是价格正常化泡沫这个词很容易让人联想到“完了”。但从技术扩散的常见路径来看泡沫破裂往往不等于技术失败更多时候是价格从虚高回归到正常让新的商业模式有机会出现。2.1 从“稀缺性溢价”到“低成本普及”可以这样类比一条收费公路在刚修好时通行费高得离谱很少有人愿意走运营方亏损严重直到通行费降到某个临界点物流网络才能长起来。基础设施的价值不在修建那一刻而在价格低到足以支撑下游应用的时刻。AI 的算力、模型调用也正在经历类似过程只不过速度更快。模型能力曾经稀缺调用一次要花不少钱于是很多人默认 AI 是“昂贵的、需要省着用”的资源。但从技术扩散的常见路径看一项能力往往会从稀缺走向普及成本趋于下降。具体到当下某个时间段降价是否已经发生、幅度有多大要以实际服务商的报价为准。真正重要的不是预测哪一天降价而是不要把方案建立在“AI 永远稀缺、永远高价”的假设上。当然这并不意味着所有投资都合理。过度建设、重复造轮子、没有真实需求的现象依然存在。这些部分确实可能被修正。但对做工程的人来说关键是别让自己的业务模型依赖某一个版本的模型有多强也别依赖某一家的 API 价格永远不变。泡沫破裂不等于技术死亡。更多时候它只是把虚高的价格打回原形让真正能算清账的人继续做下去。2.2 对开发者的三层启示如果接受“能力会变便宜、模型会变普及”这个前提那工程策略就会跟着调整第一不要赌稀缺性。如果你的产品价值来自“我有模型权限而你碰不到”那不是长期护城河。等更便宜的模型或开源方案出现这个优势会迅速消失。第二把架构设计成“模型可替换”。不要让业务逻辑和某一个模型服务强绑定。调用入口统一抽象提示词版本化输出结构稳定这样未来换模型或降成本时你不需要重写业务。第三把应用设计成“低成本优先”。经常有人一看模型效果好就把所有输入都塞进去等到账单出来才傻眼。更务实的做法是用缓存、用小模型先做初筛、用大模型处理复杂分支把单位成本控制在能跑通的范围内。这三条单独看都不难难的是大部分团队一开始没往这个方向想。等到模型涨价或服务出问题再回头改改造成本会高很多。3. 怎么判断一个 AI 用例是不是真需求三张表风口判断不了但具体用例值不值得做是可以算出来的。我这里说的“算”不是用 Excel 编一个看起来很美的模型而是用三张表把现状、实验和单位成本摆在一起。3.1 表一现状成本表做任何 AI 改造之前先回答一个问题这个场景现在到底要花多少人力、多少钱和时间很多团队直接跳过这一步凭感觉说“这个场景工作量很大”。但“很大”不是一个可比较的数字。你要记录的是周发生次数、单次耗时、单次人工成本、错误率以及因为错误造成的返工或客诉。下面是一个示例结构场景周发生次数单次人工耗时分钟单次成本元错误率周总成本客服初筛50030.85%400文案初稿50301510%750这个表不要求很精确但要有真实数据支撑。没有这一步后面谈 AI 节省多少成本都是空话。3.2 表二AI 方案实验表现状清楚之后用最小实验验证 AI 到底能做到什么程度。建议不要拿几条精心挑选的样例说“效果很好”而要准备 20 条真实输入包含常规情况、边界情况和明显异常的输入。对每一条记录AI 输出是什么人工判断是否可接受需要人工修正多少分钟调用耗时和费用样例编号输入类型AI 输出摘要可接受修正耗时分钟调用费用元备注20 条数据做完你会得到一个比“效果不错”靠谱得多的体感到底有多少输出可以直接用有多少需要改又有多少完全不能用。3.3 表三综合单位成本表第三张表把实验数据折算到单位成本综合单位成本 ≈ AI 调用成本 人工修正成本 监控成本纯人工单位成本 ≈ 原来的场景单位成本只有当综合单位成本明显低于纯人工成本并且质量波动在可控范围里这个用例才值得继续做。这里要注意“明显低于”不是指低 5%而是要至少覆盖你开发、维护、监控和上线后纠错的隐性成本。当然也有例外。有些场景即使综合成本不比人工低也值得做比如人工招不到、处理速度要求远超人力极限、或者工作本身有安全风险。这些属于“非经济理由”要单独说明不能混进成本表里。这三张表看起来简单但能筛掉很多伪需求。很多项目一算完第一张表就放弃了因为原来的流程根本没有高频到值得改造另一些项目在第二张表阶段发现AI 输出的人工修正成本比纯人工还高那硬上线只是给自己添乱。4. 把 AI 用出生产力最小工程闭环很多 AI 项目死在同一个地方Demo 惊艳上线崩溃。原因很简单单次调用跑通只能证明模型有这项能力不能证明你的程序能稳定地把能力变成服务。4.1 单次调用跑通不等于能用能用意味着至少包含四件事请求能稳定发出超时和失败有重试每次输入输出都有日志可以回溯输出质量有评估而不是靠感觉出问题时有回退方案不至于让用户直接面对白屏或错误提示我一般把这个闭环叫“最小 AI 工程闭环”请求、返回、记录、评估、人工修正、回归。缺少任何一环长期维护都会变得很痛苦。4.2 一个最小闭环的代码结构下面是一个很朴素的代码示例重点不在模型有多强而在结构里有没有把日志、重试和异常处理放进去。具体接口名称请按你正在使用的 SDK 调整这里只展示通用写法。# 通用结构示例请根据实际 SDK 调整 import json import logging import time logging.basicConfig(levellogging.INFO) def call_ai(prompt, llm_func, temperature0.2, max_retries2): for attempt in range(max_retries 1): try: start time.time() result llm_func(prompt, temperaturetemperature) logging.info(json.dumps({ event: ai_call, attempt: attempt, prompt: prompt, output: result, duration_ms: round((time.time() - start) * 1000), }, ensure_asciiFalse)) return result except Exception as e: logging.warning(fai_call_failed attempt{attempt} error{e}) time.sleep(1 * (attempt 1)) raise RuntimeError(ai_call_failed_after_retries)这个结构解决的是“出了问题你至少知道问题在哪”。很多团队没有日志线上出问题只能靠猜。猜的次数多了AI 项目就会变成一个黑盒最后没人敢改。4.3 参数和接口的常见理解调用大模型时有几个参数几乎每次都会碰到。下面是我的常用理解参数作用常见建议temperature控制随机性或确定性提取、结构化输出调低创意文案可以调高max_tokens限制生成最大长度按输出需要设置避免无限长timeout单次请求超时时间网络不稳定时设置合理超时并重试concurrency同时发起的请求数不要拉满先小并发测稳定不同模型对这些参数的取值范围和评价标准不完全一样所以要养成看文档的习惯。实际使用中我建议先固定一组保守参数跑评估集再逐步调整不要一边调参一边判断效果好坏。上线前先抽 20 条真实输入跑一遍人工评分之后每换一次模型或提示词都拿同一批样例再跑一遍。没有这个习惯你永远不知道是不是在瞎调。4.4 先建评估集再谈优化很多人调 prompt 靠感觉感觉不对就换措辞换来换去最后也不知道哪个版本好。更有效的做法是先建一个评估集。评估集不用很大20 到 50 条真实输入就够起步。把这些样本作为固定基准每次调整提示词、参数或模型后都跑一遍并记录评分。评分可以是“可用 / 需修改 / 不可用”三档也可以按业务需要加一个 1 到 5 分。有了评估集“优化”就不是玄学而是一个可回归的过程。你今天改了 prompt拿评估集跑一遍分数变高了就接受变低了就回滚。这样做还有一个额外好处以后团队换人接手也不会丢掉这套评估基准。5. 当 AI 做得不好从现象到原因的排查链路AI 项目的另一个常见坑是模型输出不符合预期时第一反应是“这模型不行”。但实际上很多问题根本不是模型的问题而是输入、参数或工作流的问题。5.1 先确定问题发生在哪一层遇到问题时我习惯先按下面这个顺序排查输入层输入格式是否规范、编码是否统一、上下文是否完整、长度是否超限。环境与依赖层SDK 版本、网络、超时、权限、API Key 是否有效。参数层temperature 是否过高、max_tokens 是否太小、并发是否过高。模型与供应商层模型能力是否匹配场景、服务状态是否正常、版本是否有差异。工作流层输出有没有顺利进入下游人工修正、回退流程是否存在。很多“生成得不对”的问题最后查出来是输入里带了一堆非预期字段或者上下文截断了。你换再强的模型也没用因为模型拿到的信息本来就缺。5.2 常见现象的排查顺序下面这张表可以当作快速对照现象优先排查顺序常见原因输出重复、空洞参数 → 缓存 → 提示词 → 模型temperature 太低、提示词有明显引导、模型本身输出和上下文对不上输入 → 参数 → 模型上下文被截断、关键字段没传进去、窗口超限响应很慢网络 → 并发 → 模型服务单次请求本身慢、并发排队、服务端负载高频繁报错权限 → 版本 → 参数API Key 失效、SDK 版本不一致、参数超出范围成本快速上涨Prompt 长度 → 缓存 → 调用次数每次把全量历史拼接、没有缓存、调用量失控排查时要先看日志。如果连日志都没有那就先补日志再谈排查。这不是绕弯子而是工程的基本顺序。5.3 不要第一反应就换模型换模型是一个成本很高、收益很不可控的动作。新模型可能在某些样例上表现更好但在你的评估集上可能反而更差。所以换模型之前至少要做三件事把当前模型的输出样本和日志拉出来看用同一套评估集跑新旧模型对比确认差异是真实能力差距还是参数、提示词没有对齐排查 AI 问题时先问自己这条输入有没有完整到达模型如果输入都不完整换模型没有意义。我见过不少团队花很多时间换了一个模型结果发现原来的问题是因为提示词里有一个字段拼错了。换模型是最容易想到的方案但往往不是最先应该做的方案。6. 长期主义模型会换流程才是资产如果把时间拉长到三年五年你会发现当前最强的模型不一定是长期最强的当前 API 的价格也不一定是长期价格。真正能留下来的是你对业务问题的定义、评估集、反馈闭环和工程流程。6.1 为什么 prompt 技巧不是护城河提示词是很重要的工程手段但它不是护城河。模型一更新同一个提示词的效果可能就会变别人抄走你的提示词也未必能复现同样的结果。能长期复用的是你对场景的理解以及围绕场景建立的数据和评估体系。比如你知道这个行业里用户常问的问题有哪些、什么情况下需要转人工、什么输出会被判定为不合格。这些知识来自业务沉淀不是一次 prompt 调试就能获得的。6.2 模型中立架构为了让 AI 能力可以被替换我一般会建议做“模型中立”设计统一接口所有 AI 调用走同一个函数或服务不散落在业务代码里。提示词版本化每次修改都有记录能追溯是哪一版产生了什么效果。输出留档和评分把线上输出和人工反馈沉淀下来作为持续评估的数据。人工反馈闭环用户或审核人员对输出进行打标这些标注意见回流到评估集。这套方法听起来不复杂但它决定了你到底是在做一个依赖模型的工具还是在做一家能持续利用模型能力的业务。6.3 什么场景不适合硬上 AI不是所有场景都应该急着上 AI。以下几种情况建议先把前置条件补齐否则大概率会变成成本和口舌之争要求零错误且错误代价极高。AI 输出具有概率性必须有足够强的人工审核或规则兜底。输入质量本身很差也没有标注样本。模型只能从它收到的数据里学习业务数据一团糟AI 也不可能变好。合规限制严格数据不能出域而你又没有私有化部署的条件。这时候先解决数据合规问题再谈效率。业务量太小连 20 条评估样本都凑不齐。先攒数据不要为了 AI 而 AI。这些不适合不代表永远不能做。它说的是在资源有限的情况下把 AI 用在最容易形成闭环、最能算清账的场景比全面铺开要有价值得多。6.4 最后一个判断你到底在做什么回到开头的问题AI 是不是泡沫这个问题确实重要但对你个人的下一步选择来说它不一定是最重要的。如果你做的是靠模型稀缺性套利的生意那么泡沫破不破都很难持续。如果你做的是把 AI 变成可控流程里的一个零件这件事的价值就独立于 AI 的热度。模型可以换、价格可以涨跌、平台可以迭代但“你能不能准确判断输入、评估输出、持续改进流程”这个能力不会过时。这也是我写这篇文章想留下的唯一框架不预测顶部不猜底部只把自己的评估集、日志、回退方案和反馈闭环做扎实。等外界热闹或冷淡的时候手里有这些的人反而最不慌。