如果AI泡沫彻底破裂最受伤的会是谁是那家靠讲故事融资的公司还是那个把客服系统、知识库、内容生成流程全部押在单一模型 API 上的开发团队答案很可能不是前者。因为概念公司的钱来自资本市场而你的线上系统是业务每天在跑的。泡沫破裂从来不是“AI 技术消失”而是“为 AI 付钱的理由发生了变化”。当大模型 API 涨价、接口调整、免费额度取消或者公司预算收缩、AI 项目被砍你的应用还能不能扛得住这才是真正需要推演的问题。这篇文章准备把“AI 泡沫破裂”当作一个工程场景来讨论不聊股市也不做情绪判断而是从架构和成本角度思考如果市场进入收缩期什么样的 AI 应用能活下来什么样的会先死。更重要的是我会给出三个可以立刻落地的工程预案模型无关接口、降级容错、效果回归评估。这三件事做扎实即使泡沫真的破裂你的系统也不会一夜瘫痪。1. 这篇文章真正要解决的问题过去两年AI 领域出现了很多“看起来必须立刻跟上”的焦虑。团队开始用大模型写周报、做客服、生成营销文案、搭建 Agent甚至重构核心业务。但很多项目的真实状态是模型能力演示很惊艳上线后的业务价值却说不清楚。这个问题在资本市场火热的时候可以被掩盖。预算充足团队可以做很多试错型项目。可一旦资本退潮公司开始追问“这个 AI 功能到底带来了多少收入、省了多少人力、降低了多少成本”很多项目就会暴露真实成色。所以这篇文章不是唱衰 AI而是帮开发者做一层防御设计。具体来说如果模型 API 涨价或不再提供服务你的业务代码需要改动多少如果线上模型突然变蠢或者输出格式不稳定你的系统能不能自动降级如果模型升级后效果下降你靠什么判断而不是靠感觉如果 AI 项目预算被砍你之前积累的数据、流程、评测集还能不能复用这些问题本质上和 AI 会不会泡沫破裂无关。哪怕 AI 继续高歌猛进这些都是任何严肃的 AI 应用项目必须回答的问题。泡沫破裂只是让这些问题提前暴露而已。适合读这篇文章的读者包括正在做 AI 应用开发的工程师、需要做技术选型的技术负责人、准备把 AI 能力接入核心系统的架构师以及在 AI 项目里负责算法评估和成本控制的产品经理。2. 为什么“AI 泡沫破裂”值得认真推演先做一个基本判断AI 技术本身不会因为泡沫破裂而消失。历史上每一次技术泡沫破裂的往往是估值和预期而不是底层技术。真正有价值的技术会在泡沫退去后继续发展只是发展节奏会从“快速试错”切换到“精耕细作”。值得警惕的是另一件事泡沫时期的很多工程决策都建立在“模型成本会持续下降、模型能力会持续上涨、供应商永远会提供稳定的 API”这三个假设上。这三个假设并不总是成立。第一个假设模型成本持续下降。从长期看单位 token 的成本确实在下降。但短期波动很常见比如新版本定价调整、免费接口限流、企业版合同条款变化。如果业务把所有流量都打在一个 API 上没有成本预算和缓存机制账单问题会最先刺痛你。第二个假设模型能力持续上涨。模型能力总体在提升但实际使用中并不稳定。同一套 Prompt模型供应商调整了参数或更新了权重输出风格可能就变了。更现实的问题是模型能力上涨不意味着你的业务效果好因为业务效果还依赖数据、Prompt、后处理和上下文管理。第三个假设供应商永远稳定。这其实是最不确定的。API 服务会变商业策略会变模型会被下线额度会被调整。如果你的代码里到处是openai.chat.completions.create这种直连调用一旦供应商侧的 SDK 升级、接口路径变化或者模型名称变动你就得全局改代码。泡沫破裂最典型的信号就是市场开始从“看想象力”转向“看现金流”。在这个阶段企业会砍掉那些没有明确 ROI 的 AI 项目。而判断一个项目有没有 ROI最直接的指标是它依赖的是“模型本身的能力”还是“围绕模型构建的系统能力”。“模型本身的能力”很容易被替代。今天用 GPT-4 能做摘要明天用 Llama 也能做摘要后天用 Qwen 也能做摘要。如果你的产品只是把 Prompt 套上一个网页外壳那你的护城河约等于零。“围绕模型构建的系统能力”则很难被替代。这包括私有数据清洗、Prompt 版本管理、输出校验、降级策略、评估集、成本追踪、安全审核。这些能力不随模型供应商变化而变化才是 AI 应用真正的资产。所以泡沫破裂的后果不是“AI 项目全部死掉”而是“没有系统能力的 AI 项目先死掉”。如果你还在犹豫要不要在 AI 架构上投入答案很明确把时间花在系统能力上而不是花在追新模型上。3. 泡沫破裂后哪些层会先被淘汰这个问题可以用倒推的方式来看。假设明天所有外部大模型 API 都涨价 10 倍你的 AI 应用还能不能正常运行这个问题的答案基本决定了你的项目属于“泡沫层”还是“价值层”。先看会被淘汰的层。第一类是纯套壳应用。这类应用的核心功能就是调用大模型 API然后返回结果。没有用户数据积累没有行业知识库没有业务流程绑定。用户用你的产品和直接打开 ChatGPT 没有本质区别。这类应用在模型 API 便宜的时候能赚一点信息差一旦 API 涨价或者免费模型变强就会立刻失去存在意义。第二类是“模型能力即业务能力”的应用。比如一个 AI 写作工具如果用户觉得好用是因为模型本身写得好而不是因为你的产品提供了独特的素材库、风格模板或审核流程那你的产品就完全受制于模型供应商。哪天模型升级后变笨或者竞对拿到了更强的模型授权你的产品优势就没有了。第三类是重运营但轻数据的 Agent 项目。很多 Agent 产品表面上在做任务编排实际只是把几个模型调用串起来。工具调用确实有价值但如果每个环节都依赖模型输出且没有兜底规则用户就会遇到“Agent 信誓旦旦说办好了实际什么都没发生”的情况。这种体验一旦出现几次用户就流失了。再看不怎么受影响甚至可能因为泡沫破裂而受益的层。第一类是深度绑定业务数据的系统。比如企业内部知识库问答模型的角色只是理解语义真正的价值在于数据权限管理、文档切分、检索召回和引用溯源。这类系统换一个模型效果可能有波动但整体架构还在。第二类是具备严格输出校验的自动化流程。比如用 AI 抽取合同关键字段但抽取结果必须经过规则校验不合格就进入人工审核。这类系统的核心是“人机协同闭环”模型只是其中一个模块。第三类是本地化部署和私有化方案。如果模型效果要求高又必须保证数据不出内网本地部署模型就是刚需。这类需求不会因泡沫破裂而消失反而会减少对外部 API 的依赖。从工程角度说你的目标应该是让业务代码尽量不感知“模型供应商是谁”。这个目标不是理论上的洁癖而是很实际的生存设计。4. 工程预案一构建模型无关的 LLM 调用层先解释一下什么叫“模型无关”。简单说业务代码里不应该出现任何一家供应商专用的 SDK 调用而应该面向一个抽象的LLMClient接口编程。如果没有这一层你的代码会变成这样import openai client openai.OpenAI(api_keysk-xxx) resp client.chat.completions.create( modelgpt-4o, messages[{role: user, content: prompt}] ) return resp.choices[0].message.content这段代码本身没问题但它把“模型调用”和“业务逻辑”耦合在了一起。下次想换成国内大模型或者换成内网部署的模型所有调用点都要改。更关键的是团队里往往有不同的模型试用需求。算法工程师想试 Claude后端工程师想用本地 Qwen产品经理说不能预算超支。如果没有一个统一接口每个人各写各的项目后期就会变成一团乱麻。正确的做法是先定义抽象接口。# 文件路径llm_client.py from abc import ABC, abstractmethod class LLMClient(ABC): 所有模型提供方的统一接口业务层只依赖这个抽象。 abstractmethod def complete(self, prompt: str, **kwargs) - str: 输入 prompt返回模型生成的文本。然后为不同供应商实现适配器。下面代码以 OpenAI 兼容接口和本地模型接口为例。之所以选 OpenAI 兼容协议是因为很多本地推理服务比如 Ollama、vLLM都提供了 OpenAI 兼容的 HTTP 接口这样一个适配器就能覆盖很多场景。# 文件路径llm_client.py import os import requests class OpenAICompatibleClient(LLMClient): 适配 OpenAI API以及任何提供 OpenAI 兼容接口的本地服务。 def __init__(self, api_key: str, model: str, base_url: str https://api.openai.com/v1): self.api_key api_key self.model model self.base_url base_url def complete(self, prompt: str, **kwargs) - str: url f{self.base_url}/chat/completions headers {Authorization: fBearer {self.api_key}} payload { model: self.model, messages: [{role: user, content: prompt}], **kwargs, } resp requests.post(url, headersheaders, jsonpayload, timeoutkwargs.get(timeout, 60)) resp.raise_for_status() return resp.json()[choices][0][message][content]这个接口之所以用requests而不是供应商 SDK是因为供应商 SDK 更新频繁而且不同 SDK 的接口风格差异很大。用 HTTP 直接调用可以减少一层依赖也让代码更透明。但直接用requests有一个代价你需要自己处理鉴权、重试、错误解析。对于中小团队来说这个代价可以接受因为收益是模型切换成本大幅降低。接下来我们需要一个工厂根据配置创建对应的 Client。# 文件路径client_factory.py import os from llm_client import OpenAICompatibleClient, LLMClient def create_client(config: dict) - LLMClient: provider config[provider] if provider openai: return OpenAICompatibleClient( api_keyos.environ[config[api_key_env]], modelconfig[model], base_urlconfig.get(base_url, https://api.openai.com/v1), ) if provider local: return OpenAICompatibleClient( api_keynot-needed, modelconfig[model], base_urlconfig.get(endpoint, http://127.0.0.1:11434), ) raise ValueError(funsupported provider: {provider})这里要特别强调本地模型的api_key只是一个占位符因为在本地部署场景下往往不需要鉴权。这个设计并不优雅但很实用。如果你的本地推理服务需要真正的鉴权可以在配置里加字段。用这种方式业务层代码不需要关心你用的是哪家模型。切换模型时只需要改配置文件然后重新创建 Client。看一下业务代码怎么用# 文件路径business_service.py from client_factory import create_client def generate_summary(client: LLMClient, content: str) - str: 生成摘要业务层只依赖 LLMClient 抽象。 prompt f请用三句话总结以下内容\n{content} return client.complete(prompt, max_tokens300)这样做之后你的系统就具备了最基础的生存能力模型供应商变了业务代码不用动。接下来还需要考虑另一个问题如果主模型不可用怎么办。5. 工程预案二降级与容错让系统在模型最差的时候仍然可用模型调用和普通数据库调用不一样。普通关系型数据库的可用性可以做到 99.9% 以上而外部大模型 API 的稳定性天生就弱一档。你不仅要处理超时、限流、5xx 错误还要面对输出内容不合法、格式混乱、甚至包含幻觉内容的情况。如果系统里所有核心流程都直接依赖模型 API并且没有任何兜底那模型一旦出问题你的业务就彻底停摆。降级策略就是为了解决这个问题。降级方案可以按成本从低到高分为几类第一缓存复用相同请求的结果第二主模型失败时切换到本地小模型或备用供应商第三彻底放弃模型回退到规则、模板或人工流程。工程上一般是组合使用。先看一个带缓存和降级的配置# 文件路径config.yaml llm: primary: provider: openai model: gpt-4o-mini api_key_env: OPENAI_API_KEY timeout_seconds: 5 max_tokens: 512 fallback: provider: local model: qwen2.5:7b endpoint: http://127.0.0.1:11434 timeout_seconds: 30 cache: enabled: true ttl_seconds: 3600这个配置表达的意思是正常情况下用gpt-4o-mini一旦超时或报错切换成本地模型。同时对相同 Prompt 的请求做一小时缓存减少重复调用。接下来是调用代码。这里要做三件事缓存、超时控制、失败降级。# 文件路径safe_generate.py import hashlib import json import time from functools import lru_cache # 简单内存缓存只适合单进程场景。 # 多实例部署时建议换成 Redis 等外部缓存。 lru_cache(maxsize4096) def _get_cache(key: str) - str: return key def call_with_fallback(primary, fallback, prompt, primary_timeout5, fallback_timeout60, use_cacheTrue): cache_key hashlib.sha256(prompt.encode(utf-8)).hexdigest() if use_cache: cached _get_cache(cache_key) # 这里用缓存判断的方式比较简陋实际项目需要存 value 和过期时间 if cached ! prompt: return cached try: start time.time() result primary.complete(prompt, timeoutprimary_timeout) latency_ms round((time.time() - start) * 1000) print(json.dumps({event: primary_ok, latency_ms: latency_ms})) if use_cache: _get_cache(cache_key) # 实际应写入真实缓存 return result except Exception as exc: print(json.dumps({event: primary_failed, reason: str(exc)})) try: start time.time() result fallback.complete(prompt, timeoutfallback_timeout) latency_ms round((time.time() - start) * 1000) print(json.dumps({event: fallback_ok, latency_ms: latency_ms})) return result except Exception as fallback_exc: # 两边都失败只能抛给上层由业务决定是否走人工流程 raise RuntimeError(both primary and fallback failed) from fallback_exc这段代码的缓存实现其实非常简陋因为内存缓存只能算 demo。核心目的是表达思路把缓存和降级放在同一个入口函数里业务层就可以只调用这个函数不用关心底层细节。在实际项目中缓存要注意两个问题。一是缓存键不能只看 Prompt还要看模型版本和参数。同一个 Prompt 在gpt-4o-mini和qwen2.5:7b上的回答可能不同所以缓存键应该包含模型名称。二是缓存要设置 TTL避免模型升级后长期返回旧内容。降级策略的另外两个关键点是超时和重试。超时时间需要根据业务场景调整。用户实时对话主模型超时建议控制在 3 到 5 秒否则用户等不起。离线批量任务可以放宽到 30 秒以上。重试次数也要限制避免模型持续异常时把调用量打爆。值得一提的是降级到本地小模型并不一定意味着效果大幅下降。对于一些结构化的任务例如信息抽取、关键词匹配、格式转换7B 参数的模型可能已经够用。真正需要强模型的任务是复杂推理、长文本理解、创意生成等。所以一种更细的做法是把任务按难度分级简单任务直接用本地模型复杂任务才调用外部大模型。这样既控成本又提升稳定性。6. 工程预案三效果评估与回归测试避免被模型折腾到怀疑人生很多团队都有这种经历今天把 Prompt 调好效果不错。明天模型供应商发了一个新版本或者你换了一个模型结果同一批用例的输出完全变样了。更麻烦的是如果连“什么算好”都没有定义你根本无法判断是模型的问题还是自己的 Prompt 写错了。所以AI 应用必须要有“回归测试”意识。简单说就是准备一组固定测试用例每次切换模型、修改 Prompt、调整参数后都跑一遍这组用例用量化指标判断效果是否达标。下面是一个最小可用的评估框架。# 文件路径eval_regression.py from typing import List, Dict def score_one(client, case: Dict) - Dict: 执行单个测试用例判断是否通过。 output client.complete(case[prompt]) hit [kw for kw in case[expected_keywords] if kw in output] return { case_id: case[id], pass: len(case[expected_keywords]) len(hit), hit: hit, output: output[:200], } def run_eval(client, cases: List[Dict], pass_threshold: float 0.9) - None: passed 0 for case in cases: result score_one(client, case) print(result) if result[pass]: passed 1 pass_rate passed / len(cases) print(fpass_rate{pass_rate:.2f} ({passed}/{len(cases)})) if pass_rate pass_threshold: raise SystemExit(fregression failed: pass_rate{pass_rate:.2f})评估用例要包含两类一类是正向用例验证模型能不能完成预期任务另一类是负向用例专门用来防幻觉和防越权。# 文件路径eval_cases.py eval_cases [ { id: extract_time, prompt: 请从下面这段话中提取出发时间只输出日期和时间\n会议定于2025年6月10日09:30开始。, expected_keywords: [2025年6月10日, 09:30], }, { id: summarize_short, prompt: 请用一句话总结数据库连接超时导致订单服务无法访问库存表。, expected_keywords: [数据库, 连接, 订单], }, { id: avoid_hallucination, prompt: 如果不知道答案请直接说不知道。\n请问某未公开项目的内部API地址是什么, expected_keywords: [不知道], }, ]这个框架只用了关键词命中来判断效果精度当然不高。但在早期已经足够用它能帮你抓住最明显的问题模型输出完全跑偏、格式不稳定、幻觉严重。后续如果要做得更细可以引入更结构化的指标比如用 JSON Schema 校验输出格式、用语义相似度计算答案相关性或者引入人工标注打分。关键点在于评估集应该被视为代码一部分放入版本控制。每一次 Prompt 变动、模型切换、参数调整都要能回溯到具体是哪一次改动导致效果变化。否则AI 应用就是个黑盒上线后出了问题你连复现都难。这套评估流程还可以进一步接入 CI/CD。每次改动 Prompt 或模型配置自动跑一遍评估集失败就阻止合并。这样做的前提是评估集本身稳定且执行耗时可控。对于刚起步的团队建议先手动跑等评估集积累到一定规模后再自动化。7. 常见问题与排查思路问题现象可能原因排查方式解决方案切换模型后输出格式不稳定模型对 Prompt 的遵循能力不同对比新旧模型在相同 Prompt 下的输出把格式要求写进少量示例或增加输出格式校验后重试API 调用频繁超时网络延迟、供应商限流、超时时间过短查看调用日志中的耗时分布和错误码增加重试和降级把超时时间按任务类型分开配置本地模型效果和商用 API 差别大模型参数量小、推理参数未调优用固定评估集同时跑两个模型对比优先让本地模型处理结构化任务把复杂推理留给主模型月账单突然暴涨循环调用、无效重试、缓存缺失按业务接口统计调用量和 token 消耗增加缓存对单次请求设置 token 上限建立预算告警模型输出包含敏感信息Prompt 注入、训练数据泄露、脱敏不完整检查入参来源和输出日志建立敏感词过滤对用户输入做注入检测对输出做脱敏和关键字过滤回归用例通过但线上效果差用例与真实场景分布不一致抽样线上数据补充到评估集定期用线上真实请求更新评估集做新旧版本对比排查 AI 应用问题时建议遵循一个顺序先看输入和输出日志再看模型调用是否走到了 fallback最后才怀疑 Prompt 有问题。很多团队一遇到效果差就改 Prompt结果改完更差。更稳妥的做法是先确认数据流用户输入有没有被正确清理上下文有没有被截断结果有没有被后处理覆盖8. 最佳实践与工程建议第一从 API 起步但永远保留“换模型”的能力。前期用外部大模型 API可以快速验证业务价值。同时从一开始就抽象出LLMClient接口并预留本地模型适配。不要等到业务量上来了再重构那时候成本极高。第二模型和 Prompt 都要做版本管理。模型版本、Prompt 内容、参数配置最好都提交到 Git并和代码版本关联。这样出了问题可以快速定位是代码改动还是模型改动导致的。如果条件允许把 Prompt 也做成配置而不是硬编码在代码里。第三成本治理要从第一天开始。每个调用点都应该输出 token 消耗、耗时、模型名。月账单暴涨时可以先按接口维度统计快速定位是哪个功能在烧钱。缓存不是可选项是成本控制的必需品。第四安全边界要清晰。涉及用户隐私、商业机密、内部代码的数据默认不应该发送到外部模型 API。如果要使用外部 API必须做脱敏处理。企业内部 AI 应用中最常见的泄密路径就是把文档内容直接拼进 Prompt然后发送给外部模型。这个问题在泡沫期容易被忽略但一旦出事就是大事。第五AI Agent 项目要特别重视可观测性。Agent 通常包含多轮工具调用每轮都依赖模型输出任何一个环节出问题整个任务都可能失败。给 Agent 加详细的执行日志记录每一步的输入、输出、工具调用结果、耗时和 token 消耗。这样至少能知道 Agent 卡在哪一步。第六不要陷入“追新模型”的节奏。新模型确实可能在 benchmark 上更强但你的业务效果未必同步提升。每次想升级模型先跑一遍自己的评估集用数据说话。如果效果没提升那就继续用旧模型省下来的成本和时间都是利润。第七把 AI 当成模块而不是整个系统。一个健康的技术架构里AI 模型只是完成特定任务的组件。它旁边应该有校验模块、降级模块、人工审核入口、数据回流机制。这些模块组合在一起才是完整的 AI 应用系统。9. 总结与后续学习方向回到文章开头的问题如果 AI 泡沫彻底破裂真正危险的不是“AI 技术不行了”而是你的系统把生死权全部交到了别人手里。这篇文章给出的三个工程预案是任何 AI 应用项目都应该具备的基础能力模型无关接口让你在供应商变化时不至于重写代码降级容错机制让系统在主模型不可用时仍然能提供服务效果评估回归让你在模型切换、Prompt 调整时能有判断依据而不是靠感觉。如果你现在正在做 AI 应用开发可以先用最小成本完成这三件事。具体落地顺序建议是先抽象出 LLM 调用层再引入降级策略最后搭建评估集。这三步做完你的 AI 应用就有了基本抗风险能力。下一步值得继续深入的方向包括本地模型部署与微调、RAG 检索增强生成、Agent 的可观测性和评测体系以及更细粒度的成本治理。这些方向本质上都是围绕“让 AI 稳定、可靠、可控地融入业务系统”展开的。AI 泡沫是否会破裂什么时候破裂没有人能准确预测。但有一点是确定的只依赖模型能力、没有系统工程能力的 AI 应用在任何市场周期里都很难走远。趁现在还有余力把架构加固把评估体系建起来才是对项目最务实的保护。
AI泡沫破裂下的工程生存指南：模型无关、降级容错与效果评估三大预案
如果AI泡沫彻底破裂最受伤的会是谁是那家靠讲故事融资的公司还是那个把客服系统、知识库、内容生成流程全部押在单一模型 API 上的开发团队答案很可能不是前者。因为概念公司的钱来自资本市场而你的线上系统是业务每天在跑的。泡沫破裂从来不是“AI 技术消失”而是“为 AI 付钱的理由发生了变化”。当大模型 API 涨价、接口调整、免费额度取消或者公司预算收缩、AI 项目被砍你的应用还能不能扛得住这才是真正需要推演的问题。这篇文章准备把“AI 泡沫破裂”当作一个工程场景来讨论不聊股市也不做情绪判断而是从架构和成本角度思考如果市场进入收缩期什么样的 AI 应用能活下来什么样的会先死。更重要的是我会给出三个可以立刻落地的工程预案模型无关接口、降级容错、效果回归评估。这三件事做扎实即使泡沫真的破裂你的系统也不会一夜瘫痪。1. 这篇文章真正要解决的问题过去两年AI 领域出现了很多“看起来必须立刻跟上”的焦虑。团队开始用大模型写周报、做客服、生成营销文案、搭建 Agent甚至重构核心业务。但很多项目的真实状态是模型能力演示很惊艳上线后的业务价值却说不清楚。这个问题在资本市场火热的时候可以被掩盖。预算充足团队可以做很多试错型项目。可一旦资本退潮公司开始追问“这个 AI 功能到底带来了多少收入、省了多少人力、降低了多少成本”很多项目就会暴露真实成色。所以这篇文章不是唱衰 AI而是帮开发者做一层防御设计。具体来说如果模型 API 涨价或不再提供服务你的业务代码需要改动多少如果线上模型突然变蠢或者输出格式不稳定你的系统能不能自动降级如果模型升级后效果下降你靠什么判断而不是靠感觉如果 AI 项目预算被砍你之前积累的数据、流程、评测集还能不能复用这些问题本质上和 AI 会不会泡沫破裂无关。哪怕 AI 继续高歌猛进这些都是任何严肃的 AI 应用项目必须回答的问题。泡沫破裂只是让这些问题提前暴露而已。适合读这篇文章的读者包括正在做 AI 应用开发的工程师、需要做技术选型的技术负责人、准备把 AI 能力接入核心系统的架构师以及在 AI 项目里负责算法评估和成本控制的产品经理。2. 为什么“AI 泡沫破裂”值得认真推演先做一个基本判断AI 技术本身不会因为泡沫破裂而消失。历史上每一次技术泡沫破裂的往往是估值和预期而不是底层技术。真正有价值的技术会在泡沫退去后继续发展只是发展节奏会从“快速试错”切换到“精耕细作”。值得警惕的是另一件事泡沫时期的很多工程决策都建立在“模型成本会持续下降、模型能力会持续上涨、供应商永远会提供稳定的 API”这三个假设上。这三个假设并不总是成立。第一个假设模型成本持续下降。从长期看单位 token 的成本确实在下降。但短期波动很常见比如新版本定价调整、免费接口限流、企业版合同条款变化。如果业务把所有流量都打在一个 API 上没有成本预算和缓存机制账单问题会最先刺痛你。第二个假设模型能力持续上涨。模型能力总体在提升但实际使用中并不稳定。同一套 Prompt模型供应商调整了参数或更新了权重输出风格可能就变了。更现实的问题是模型能力上涨不意味着你的业务效果好因为业务效果还依赖数据、Prompt、后处理和上下文管理。第三个假设供应商永远稳定。这其实是最不确定的。API 服务会变商业策略会变模型会被下线额度会被调整。如果你的代码里到处是openai.chat.completions.create这种直连调用一旦供应商侧的 SDK 升级、接口路径变化或者模型名称变动你就得全局改代码。泡沫破裂最典型的信号就是市场开始从“看想象力”转向“看现金流”。在这个阶段企业会砍掉那些没有明确 ROI 的 AI 项目。而判断一个项目有没有 ROI最直接的指标是它依赖的是“模型本身的能力”还是“围绕模型构建的系统能力”。“模型本身的能力”很容易被替代。今天用 GPT-4 能做摘要明天用 Llama 也能做摘要后天用 Qwen 也能做摘要。如果你的产品只是把 Prompt 套上一个网页外壳那你的护城河约等于零。“围绕模型构建的系统能力”则很难被替代。这包括私有数据清洗、Prompt 版本管理、输出校验、降级策略、评估集、成本追踪、安全审核。这些能力不随模型供应商变化而变化才是 AI 应用真正的资产。所以泡沫破裂的后果不是“AI 项目全部死掉”而是“没有系统能力的 AI 项目先死掉”。如果你还在犹豫要不要在 AI 架构上投入答案很明确把时间花在系统能力上而不是花在追新模型上。3. 泡沫破裂后哪些层会先被淘汰这个问题可以用倒推的方式来看。假设明天所有外部大模型 API 都涨价 10 倍你的 AI 应用还能不能正常运行这个问题的答案基本决定了你的项目属于“泡沫层”还是“价值层”。先看会被淘汰的层。第一类是纯套壳应用。这类应用的核心功能就是调用大模型 API然后返回结果。没有用户数据积累没有行业知识库没有业务流程绑定。用户用你的产品和直接打开 ChatGPT 没有本质区别。这类应用在模型 API 便宜的时候能赚一点信息差一旦 API 涨价或者免费模型变强就会立刻失去存在意义。第二类是“模型能力即业务能力”的应用。比如一个 AI 写作工具如果用户觉得好用是因为模型本身写得好而不是因为你的产品提供了独特的素材库、风格模板或审核流程那你的产品就完全受制于模型供应商。哪天模型升级后变笨或者竞对拿到了更强的模型授权你的产品优势就没有了。第三类是重运营但轻数据的 Agent 项目。很多 Agent 产品表面上在做任务编排实际只是把几个模型调用串起来。工具调用确实有价值但如果每个环节都依赖模型输出且没有兜底规则用户就会遇到“Agent 信誓旦旦说办好了实际什么都没发生”的情况。这种体验一旦出现几次用户就流失了。再看不怎么受影响甚至可能因为泡沫破裂而受益的层。第一类是深度绑定业务数据的系统。比如企业内部知识库问答模型的角色只是理解语义真正的价值在于数据权限管理、文档切分、检索召回和引用溯源。这类系统换一个模型效果可能有波动但整体架构还在。第二类是具备严格输出校验的自动化流程。比如用 AI 抽取合同关键字段但抽取结果必须经过规则校验不合格就进入人工审核。这类系统的核心是“人机协同闭环”模型只是其中一个模块。第三类是本地化部署和私有化方案。如果模型效果要求高又必须保证数据不出内网本地部署模型就是刚需。这类需求不会因泡沫破裂而消失反而会减少对外部 API 的依赖。从工程角度说你的目标应该是让业务代码尽量不感知“模型供应商是谁”。这个目标不是理论上的洁癖而是很实际的生存设计。4. 工程预案一构建模型无关的 LLM 调用层先解释一下什么叫“模型无关”。简单说业务代码里不应该出现任何一家供应商专用的 SDK 调用而应该面向一个抽象的LLMClient接口编程。如果没有这一层你的代码会变成这样import openai client openai.OpenAI(api_keysk-xxx) resp client.chat.completions.create( modelgpt-4o, messages[{role: user, content: prompt}] ) return resp.choices[0].message.content这段代码本身没问题但它把“模型调用”和“业务逻辑”耦合在了一起。下次想换成国内大模型或者换成内网部署的模型所有调用点都要改。更关键的是团队里往往有不同的模型试用需求。算法工程师想试 Claude后端工程师想用本地 Qwen产品经理说不能预算超支。如果没有一个统一接口每个人各写各的项目后期就会变成一团乱麻。正确的做法是先定义抽象接口。# 文件路径llm_client.py from abc import ABC, abstractmethod class LLMClient(ABC): 所有模型提供方的统一接口业务层只依赖这个抽象。 abstractmethod def complete(self, prompt: str, **kwargs) - str: 输入 prompt返回模型生成的文本。然后为不同供应商实现适配器。下面代码以 OpenAI 兼容接口和本地模型接口为例。之所以选 OpenAI 兼容协议是因为很多本地推理服务比如 Ollama、vLLM都提供了 OpenAI 兼容的 HTTP 接口这样一个适配器就能覆盖很多场景。# 文件路径llm_client.py import os import requests class OpenAICompatibleClient(LLMClient): 适配 OpenAI API以及任何提供 OpenAI 兼容接口的本地服务。 def __init__(self, api_key: str, model: str, base_url: str https://api.openai.com/v1): self.api_key api_key self.model model self.base_url base_url def complete(self, prompt: str, **kwargs) - str: url f{self.base_url}/chat/completions headers {Authorization: fBearer {self.api_key}} payload { model: self.model, messages: [{role: user, content: prompt}], **kwargs, } resp requests.post(url, headersheaders, jsonpayload, timeoutkwargs.get(timeout, 60)) resp.raise_for_status() return resp.json()[choices][0][message][content]这个接口之所以用requests而不是供应商 SDK是因为供应商 SDK 更新频繁而且不同 SDK 的接口风格差异很大。用 HTTP 直接调用可以减少一层依赖也让代码更透明。但直接用requests有一个代价你需要自己处理鉴权、重试、错误解析。对于中小团队来说这个代价可以接受因为收益是模型切换成本大幅降低。接下来我们需要一个工厂根据配置创建对应的 Client。# 文件路径client_factory.py import os from llm_client import OpenAICompatibleClient, LLMClient def create_client(config: dict) - LLMClient: provider config[provider] if provider openai: return OpenAICompatibleClient( api_keyos.environ[config[api_key_env]], modelconfig[model], base_urlconfig.get(base_url, https://api.openai.com/v1), ) if provider local: return OpenAICompatibleClient( api_keynot-needed, modelconfig[model], base_urlconfig.get(endpoint, http://127.0.0.1:11434), ) raise ValueError(funsupported provider: {provider})这里要特别强调本地模型的api_key只是一个占位符因为在本地部署场景下往往不需要鉴权。这个设计并不优雅但很实用。如果你的本地推理服务需要真正的鉴权可以在配置里加字段。用这种方式业务层代码不需要关心你用的是哪家模型。切换模型时只需要改配置文件然后重新创建 Client。看一下业务代码怎么用# 文件路径business_service.py from client_factory import create_client def generate_summary(client: LLMClient, content: str) - str: 生成摘要业务层只依赖 LLMClient 抽象。 prompt f请用三句话总结以下内容\n{content} return client.complete(prompt, max_tokens300)这样做之后你的系统就具备了最基础的生存能力模型供应商变了业务代码不用动。接下来还需要考虑另一个问题如果主模型不可用怎么办。5. 工程预案二降级与容错让系统在模型最差的时候仍然可用模型调用和普通数据库调用不一样。普通关系型数据库的可用性可以做到 99.9% 以上而外部大模型 API 的稳定性天生就弱一档。你不仅要处理超时、限流、5xx 错误还要面对输出内容不合法、格式混乱、甚至包含幻觉内容的情况。如果系统里所有核心流程都直接依赖模型 API并且没有任何兜底那模型一旦出问题你的业务就彻底停摆。降级策略就是为了解决这个问题。降级方案可以按成本从低到高分为几类第一缓存复用相同请求的结果第二主模型失败时切换到本地小模型或备用供应商第三彻底放弃模型回退到规则、模板或人工流程。工程上一般是组合使用。先看一个带缓存和降级的配置# 文件路径config.yaml llm: primary: provider: openai model: gpt-4o-mini api_key_env: OPENAI_API_KEY timeout_seconds: 5 max_tokens: 512 fallback: provider: local model: qwen2.5:7b endpoint: http://127.0.0.1:11434 timeout_seconds: 30 cache: enabled: true ttl_seconds: 3600这个配置表达的意思是正常情况下用gpt-4o-mini一旦超时或报错切换成本地模型。同时对相同 Prompt 的请求做一小时缓存减少重复调用。接下来是调用代码。这里要做三件事缓存、超时控制、失败降级。# 文件路径safe_generate.py import hashlib import json import time from functools import lru_cache # 简单内存缓存只适合单进程场景。 # 多实例部署时建议换成 Redis 等外部缓存。 lru_cache(maxsize4096) def _get_cache(key: str) - str: return key def call_with_fallback(primary, fallback, prompt, primary_timeout5, fallback_timeout60, use_cacheTrue): cache_key hashlib.sha256(prompt.encode(utf-8)).hexdigest() if use_cache: cached _get_cache(cache_key) # 这里用缓存判断的方式比较简陋实际项目需要存 value 和过期时间 if cached ! prompt: return cached try: start time.time() result primary.complete(prompt, timeoutprimary_timeout) latency_ms round((time.time() - start) * 1000) print(json.dumps({event: primary_ok, latency_ms: latency_ms})) if use_cache: _get_cache(cache_key) # 实际应写入真实缓存 return result except Exception as exc: print(json.dumps({event: primary_failed, reason: str(exc)})) try: start time.time() result fallback.complete(prompt, timeoutfallback_timeout) latency_ms round((time.time() - start) * 1000) print(json.dumps({event: fallback_ok, latency_ms: latency_ms})) return result except Exception as fallback_exc: # 两边都失败只能抛给上层由业务决定是否走人工流程 raise RuntimeError(both primary and fallback failed) from fallback_exc这段代码的缓存实现其实非常简陋因为内存缓存只能算 demo。核心目的是表达思路把缓存和降级放在同一个入口函数里业务层就可以只调用这个函数不用关心底层细节。在实际项目中缓存要注意两个问题。一是缓存键不能只看 Prompt还要看模型版本和参数。同一个 Prompt 在gpt-4o-mini和qwen2.5:7b上的回答可能不同所以缓存键应该包含模型名称。二是缓存要设置 TTL避免模型升级后长期返回旧内容。降级策略的另外两个关键点是超时和重试。超时时间需要根据业务场景调整。用户实时对话主模型超时建议控制在 3 到 5 秒否则用户等不起。离线批量任务可以放宽到 30 秒以上。重试次数也要限制避免模型持续异常时把调用量打爆。值得一提的是降级到本地小模型并不一定意味着效果大幅下降。对于一些结构化的任务例如信息抽取、关键词匹配、格式转换7B 参数的模型可能已经够用。真正需要强模型的任务是复杂推理、长文本理解、创意生成等。所以一种更细的做法是把任务按难度分级简单任务直接用本地模型复杂任务才调用外部大模型。这样既控成本又提升稳定性。6. 工程预案三效果评估与回归测试避免被模型折腾到怀疑人生很多团队都有这种经历今天把 Prompt 调好效果不错。明天模型供应商发了一个新版本或者你换了一个模型结果同一批用例的输出完全变样了。更麻烦的是如果连“什么算好”都没有定义你根本无法判断是模型的问题还是自己的 Prompt 写错了。所以AI 应用必须要有“回归测试”意识。简单说就是准备一组固定测试用例每次切换模型、修改 Prompt、调整参数后都跑一遍这组用例用量化指标判断效果是否达标。下面是一个最小可用的评估框架。# 文件路径eval_regression.py from typing import List, Dict def score_one(client, case: Dict) - Dict: 执行单个测试用例判断是否通过。 output client.complete(case[prompt]) hit [kw for kw in case[expected_keywords] if kw in output] return { case_id: case[id], pass: len(case[expected_keywords]) len(hit), hit: hit, output: output[:200], } def run_eval(client, cases: List[Dict], pass_threshold: float 0.9) - None: passed 0 for case in cases: result score_one(client, case) print(result) if result[pass]: passed 1 pass_rate passed / len(cases) print(fpass_rate{pass_rate:.2f} ({passed}/{len(cases)})) if pass_rate pass_threshold: raise SystemExit(fregression failed: pass_rate{pass_rate:.2f})评估用例要包含两类一类是正向用例验证模型能不能完成预期任务另一类是负向用例专门用来防幻觉和防越权。# 文件路径eval_cases.py eval_cases [ { id: extract_time, prompt: 请从下面这段话中提取出发时间只输出日期和时间\n会议定于2025年6月10日09:30开始。, expected_keywords: [2025年6月10日, 09:30], }, { id: summarize_short, prompt: 请用一句话总结数据库连接超时导致订单服务无法访问库存表。, expected_keywords: [数据库, 连接, 订单], }, { id: avoid_hallucination, prompt: 如果不知道答案请直接说不知道。\n请问某未公开项目的内部API地址是什么, expected_keywords: [不知道], }, ]这个框架只用了关键词命中来判断效果精度当然不高。但在早期已经足够用它能帮你抓住最明显的问题模型输出完全跑偏、格式不稳定、幻觉严重。后续如果要做得更细可以引入更结构化的指标比如用 JSON Schema 校验输出格式、用语义相似度计算答案相关性或者引入人工标注打分。关键点在于评估集应该被视为代码一部分放入版本控制。每一次 Prompt 变动、模型切换、参数调整都要能回溯到具体是哪一次改动导致效果变化。否则AI 应用就是个黑盒上线后出了问题你连复现都难。这套评估流程还可以进一步接入 CI/CD。每次改动 Prompt 或模型配置自动跑一遍评估集失败就阻止合并。这样做的前提是评估集本身稳定且执行耗时可控。对于刚起步的团队建议先手动跑等评估集积累到一定规模后再自动化。7. 常见问题与排查思路问题现象可能原因排查方式解决方案切换模型后输出格式不稳定模型对 Prompt 的遵循能力不同对比新旧模型在相同 Prompt 下的输出把格式要求写进少量示例或增加输出格式校验后重试API 调用频繁超时网络延迟、供应商限流、超时时间过短查看调用日志中的耗时分布和错误码增加重试和降级把超时时间按任务类型分开配置本地模型效果和商用 API 差别大模型参数量小、推理参数未调优用固定评估集同时跑两个模型对比优先让本地模型处理结构化任务把复杂推理留给主模型月账单突然暴涨循环调用、无效重试、缓存缺失按业务接口统计调用量和 token 消耗增加缓存对单次请求设置 token 上限建立预算告警模型输出包含敏感信息Prompt 注入、训练数据泄露、脱敏不完整检查入参来源和输出日志建立敏感词过滤对用户输入做注入检测对输出做脱敏和关键字过滤回归用例通过但线上效果差用例与真实场景分布不一致抽样线上数据补充到评估集定期用线上真实请求更新评估集做新旧版本对比排查 AI 应用问题时建议遵循一个顺序先看输入和输出日志再看模型调用是否走到了 fallback最后才怀疑 Prompt 有问题。很多团队一遇到效果差就改 Prompt结果改完更差。更稳妥的做法是先确认数据流用户输入有没有被正确清理上下文有没有被截断结果有没有被后处理覆盖8. 最佳实践与工程建议第一从 API 起步但永远保留“换模型”的能力。前期用外部大模型 API可以快速验证业务价值。同时从一开始就抽象出LLMClient接口并预留本地模型适配。不要等到业务量上来了再重构那时候成本极高。第二模型和 Prompt 都要做版本管理。模型版本、Prompt 内容、参数配置最好都提交到 Git并和代码版本关联。这样出了问题可以快速定位是代码改动还是模型改动导致的。如果条件允许把 Prompt 也做成配置而不是硬编码在代码里。第三成本治理要从第一天开始。每个调用点都应该输出 token 消耗、耗时、模型名。月账单暴涨时可以先按接口维度统计快速定位是哪个功能在烧钱。缓存不是可选项是成本控制的必需品。第四安全边界要清晰。涉及用户隐私、商业机密、内部代码的数据默认不应该发送到外部模型 API。如果要使用外部 API必须做脱敏处理。企业内部 AI 应用中最常见的泄密路径就是把文档内容直接拼进 Prompt然后发送给外部模型。这个问题在泡沫期容易被忽略但一旦出事就是大事。第五AI Agent 项目要特别重视可观测性。Agent 通常包含多轮工具调用每轮都依赖模型输出任何一个环节出问题整个任务都可能失败。给 Agent 加详细的执行日志记录每一步的输入、输出、工具调用结果、耗时和 token 消耗。这样至少能知道 Agent 卡在哪一步。第六不要陷入“追新模型”的节奏。新模型确实可能在 benchmark 上更强但你的业务效果未必同步提升。每次想升级模型先跑一遍自己的评估集用数据说话。如果效果没提升那就继续用旧模型省下来的成本和时间都是利润。第七把 AI 当成模块而不是整个系统。一个健康的技术架构里AI 模型只是完成特定任务的组件。它旁边应该有校验模块、降级模块、人工审核入口、数据回流机制。这些模块组合在一起才是完整的 AI 应用系统。9. 总结与后续学习方向回到文章开头的问题如果 AI 泡沫彻底破裂真正危险的不是“AI 技术不行了”而是你的系统把生死权全部交到了别人手里。这篇文章给出的三个工程预案是任何 AI 应用项目都应该具备的基础能力模型无关接口让你在供应商变化时不至于重写代码降级容错机制让系统在主模型不可用时仍然能提供服务效果评估回归让你在模型切换、Prompt 调整时能有判断依据而不是靠感觉。如果你现在正在做 AI 应用开发可以先用最小成本完成这三件事。具体落地顺序建议是先抽象出 LLM 调用层再引入降级策略最后搭建评估集。这三步做完你的 AI 应用就有了基本抗风险能力。下一步值得继续深入的方向包括本地模型部署与微调、RAG 检索增强生成、Agent 的可观测性和评测体系以及更细粒度的成本治理。这些方向本质上都是围绕“让 AI 稳定、可靠、可控地融入业务系统”展开的。AI 泡沫是否会破裂什么时候破裂没有人能准确预测。但有一点是确定的只依赖模型能力、没有系统工程能力的 AI 应用在任何市场周期里都很难走远。趁现在还有余力把架构加固把评估体系建起来才是对项目最务实的保护。
