最近在社区里看到不少关于 Cory Doctorow 提出的“Enshittification平台腐化”概念的讨论尤其是把那场和 AI 相关的视频内容反复看了几遍之后我发现这个话题表面上是科技评论实际上和做 AI 工程的人关系非常深。它不只是吐槽平台越来越难用而是在讲一个平台从“对用户好”到“对平台好、对用户坏”的衰退周期以及 AI 时代这轮周期会如何加速、如何影响我们正在构建的应用。这篇文章会围绕“AI 与平台腐化时代”这个主题从概念拆解讲到 AI 工程中的具体风险再给出我自己的应对思路和一个可运行的多模型适配层示例。如果你正在做 AI 应用开发、模型接入、Agent 平台选型或者在纠结“要不要把核心业务押在某个大模型 API 上”这篇内容会比较对胃口。1. 什么是“平台腐化”先把这个概念讲清楚1.1 从 Cory Doctorow 的核心观点说起Cory Doctorow 是知名的科技作家和数字权利倡导者他发明了一个词叫Enshittification中文社区一般翻译成“平台腐化”或“平台劣化”。这个词描述的是互联网平台常见的生命周期早期为了吸引用户平台对用户特别好甚至不惜补贴。用户规模上来了平台开始对第三方开发者、商家、创作者展示价值把生态圈做大。等到用户和生态都被锁定平台为了讨好股东开始把“对用户好”和“对商家好”的资源一点点抽走转向“对平台自己最好”。平台变得难用、广告变多、搜索体验变差、API 涨价、审核规则混乱用户被困在里面却因为迁移成本太高而走不掉。这个周期听起来像是商业评论但它背后是平台权力结构失衡的问题当平台掌握了基础设施、分发渠道和数据用户与开发者在议价上就处于绝对劣势。1.2 为什么 AI 时代要把这个问题重新拿出来看如果你只把“平台腐化”当成社交媒体的吐槽那就低估了它对 AI 行业的适用性。AI 时代的平台化进程比传统互联网快得多主要因为几个原因API 依赖集中大量应用直接调用 OpenAI、Anthropic、Google 等头部大模型 API几乎没有迁移能力。数据反馈闭环用户的每一次调用、反馈、微调数据都可能沉淀在平台侧成为模型持续优化的养料。生态锁定明显插件、Agent、知识库、提示词资产越来越多地绑定在某一家的生态里。定价权集中模型 API 的定价由头部平台决定开发者很难议价。换句话说传统平台腐化还需要十几年积累AI 平台可能在短短几年内就走完整条曲线。很多开发者已经在深夜收到过“模型价格调整”“服务接口变更”“新的安全审查规则”之类的邮件。这种“平台今天变一个规则你就要通宵改代码”的体验正是腐化现象在工程侧的具象化。2. AI 场景下的平台腐化几个典型表现2.1 模型 API 的定价与限流变化最先被感知到的腐化发生在 API 定价与限流策略上。早期阶段模型厂商为了抢占市场会以较低的价格和宽松的限流策略吸引开发者。当依赖者多了平台就开始调整提高 token 单价压缩免费额度。增加限流策略比如 RPS每秒请求数收紧。把成本高昂的进阶能力单独拆分收费。封禁或限制某些“异常用途”的调用。对业务方来说这些调整不是一次性的而是持续发生。如果你只在代码里写死了固定的模型地址、固定配额临时改起来非常痛苦。2.2 数据反馈与训练数据的闭环问题第二个容易被忽视的问题是数据闭环。Cory Doctorow 在访谈类内容中反复强调过平台如何“收割”用户生成的内容。AI 时代这个收割变得更深了用户输入给 Chatbot 的问题可能被用作模型训练数据。开发者通过 API 上传的文档、知识库可能参与平台的数据飞轮。用户对模型输出的反馈点赞、点踩、修改痕迹被平台收集并用于强化对齐。对企业来说如果你的核心知识库、客户对话记录都送到外部 API 去处理这些数据就会成为平台资产的一部分。哪怕平台承诺“不训练”数据在链路中留存本身就是风险。2.3 内容生态中的 AI 垃圾与推荐机制另一个表现是内容生态的恶化。当 AI 可以低成本生成文章、图片、视频之后平台内的内容量暴增但内容质量在快速下滑。搜索引擎和社交平台不得不投入更多算力做“AI 内容识别”和“垃圾过滤”可这些举措会误伤普通用户也会让真实创作者触达用户的难度变大。这种现象对 AI 应用开发者同样有影响你依赖的搜索 API 结果质量在下降你用来做 RAG检索增强生成的网页内容越来越不可信你训练模型时从互联网获取的数据集中充斥着 AI 生成内容的变体。数据质量变低导致上层应用效果变差这就是一种系统性腐化。3. AI 工程中的平台依赖从 API 到基础设施要对抗腐化第一步是识别自己在哪些层面存在平台依赖。在 AI 工程里依赖通常分成三层。3.1 API 层依赖API 层依赖是指你的应用直接调用了某家大模型提供商的接口比如通过 OpenAI 的 Chat Completions 接口做文本生成通过 Claude API 做长文档理解或者通过某个云平台的对象存储服务保存数据。这种依赖的优点是非常方便开发成本低效果也默认就是最好的。但缺点是接口协议被厂商控制升级后可能不兼容。价格模型不透明成本估算困难。隐私数据存在第三方平台上合规压力变大。3.2 模型与数据依赖模型依赖指你的核心能力建立在某一个模型的特性之上。比如说你针对 GPT-4o 的特定输出格式做了大量提示词工程和解析逻辑或者你用的 Embedding 模型是某个平台的专有模型换一个模型后向量相似度分布完全不一样检索质量会剧烈波动。数据依赖则是说你的应用长期依靠平台提供的知识库、检索能力或网页索引。一旦平台调整数据的抓取策略或收费方式应用就断粮。3.3 算力与部署依赖算力层依赖通常被忽视。很多人以为用了开源模型就万事大吉但自建模型依然需要 GPU、推理框架、运维能力。如果你把所有推理任务放在一家云厂商的 GPU 实例上实际上还是被云平台锁定只是从“API 锁定”变成了“基础设施锁定”。因此对抗平台腐化并不是简单地“不用某一家 API”而是要建立一种可替换性思维每一层都要有备选方案并且每一层的抽象边界都要清晰。4. 工程化应对方案如何降低平台锁定风险理解了风险之后我们再来看具体的工程应对策略。这些策略不是要求你立刻放弃大模型 API而是让你在享受平台便利的同时保留随时离开的能力。4.1 多供应商适配器模式这是最直接的方案。在应用代码里不要把某个 API 的 SDK 直接用满整个项目而是抽象一个模型供应商接口然后把不同厂商的实现做成适配器。这样做有几个好处某家服务不稳定时可以切换到备选供应商。某家涨价后可以快速评估替代成本。新模型出来后可以小范围灰度对比效果。代价是需要额外写一层胶水代码但相比被平台锁死后被迫重构这点成本非常划算。4.2 开源模型与私有化部署对于数据敏感型业务开源模型的重要性会越来越高。像 Llama、Qwen、DeepSeek 等开源模型在通用任务上的表现已经接近中高端闭源模型。你可以通过本地部署或私有云部署来完全掌控推理过程和数据流向。但要注意私有化部署不等于不腐化它只是把依赖从“外部平台”转移到“内部运维团队”。你仍然需要关注模型许可证更新、推理框架升级、硬件更换等问题只是自主权变大了。4.3 数据所有权与可迁移设计这一条经常被忽略。很多 AI 应用真正值钱的是业务数据、用户反馈、微调数据集而不是模型本身。如果这些数据只能存在某个平台的 JSON 字段里不能批量导出那平台就牢牢卡住了你的脖子。你在设计系统时应该约定所有业务数据必须有标准化的导出接口。向量数据库的索引、元数据、分片策略尽量通用。用户上传的资料和对话记录要落本地备份。微调语料的格式要兼容开源训练框架而不是绑定在某个平台的私有格式上。5. 实战示例构建一个简单的多模型 AI 网关说了这么多抽象的“可替换性”下面我们用一个实际的 Python 示例演示如何设计一个非常轻量的多模型网关。这个示例不依赖太重的外部框架重点展示适配器思路。5.1 项目结构先创建一个简单的项目目录ai-gateway-demo/ ├── main.py ├── providers/ │ ├── __init__.py │ ├── base.py │ ├── openai_provider.py │ └── local_provider.py ├── requirements.txt └── config.yaml5.2 抽象 Provider 接口项目入口是providers/base.py它定义所有模型供应商都要实现的方法# 文件路径providers/base.py from abc import ABC, abstractmethod from typing import Optional, Dict, Any class BaseProvider(ABC): 所有模型供应商的抽象基类 abstractmethod def chat(self, messages, **kwargs) - Dict[str, Any]: 接收一段对话消息列表返回模型生成结果。 messages 示例 [ {role: system, content: 你是 AI 助手}, {role: user, content: 讲个笑话} ] pass abstractmethod def embed(self, texts: list[str]) - list[list[float]]: 把文本转换为向量供检索使用 pass这个接口的精髓是把“对话”和“向量化”这两个高频操作抽象出来。业务代码只依赖BaseProvider不关心底层是哪家模型。5.3 OpenAI Provider 实现假设我们要接入 OpenAI 兼容接口那么实现如下。为了方便演示我们使用openaiSDK但只把它封装在 Provider 内部。# 文件路径providers/openai_provider.py import os from typing import Dict, Any, Optional from openai import OpenAI from .base import BaseProvider class OpenAIProvider(BaseProvider): def __init__(self, model: str gpt-4o-mini): # 从环境变量读取 key避免写在代码里 api_key os.environ.get(OPENAI_API_KEY) # 也可以通过配置文件覆盖 base_url base_url os.environ.get(OPENAI_BASE_URL) self.client OpenAI(api_keyapi_key, base_urlbase_url) self.model model def chat(self, messages, **kwargs) - Dict[str, Any]: response self.client.chat.completions.create( modelself.model, messagesmessages, **kwargs ) return { content: response.choices[0].message.content, provider: openai, model: self.model } def embed(self, texts: list[str]) - list[list[float]]: response self.client.embeddings.create( modeltext-embedding-3-small, inputtexts ) return [item.embedding for item in response.data]这里base_url是可选的这样你既可以直接连 OpenAI也可以把该 Provider 指向任何兼容 OpenAI 接口的第三方网关或私有部署网关。5.4 本地模型 Provider 实现如果我们部署了一个本地模型比如基于 Ollama 或 vLLM 拉起一个 OpenAI 兼容服务那LocalProvider和OpenAIProvider的代码结构几乎一样只是 base_url 指向本地。# 文件路径providers/local_provider.py import os from typing import Dict, Any from openai import OpenAI from .base import BaseProvider class LocalProvider(BaseProvider): 本地模型 Provider。假设你已经通过 vLLM 或 Ollama 启动了一个 OpenAI 兼容服务。 例如 vllm serve Qwen/Qwen2.5-7B-Instruct --port 8000 或者 ollama serve ollama run qwen2.5 def __init__(self, model: str qwen2.5): # 本地服务的 base_url默认指向 vLLM 默认端口 base_url os.environ.get(LOCAL_BASE_URL, http://localhost:8000/v1) self.client OpenAI(api_keylocal, base_urlbase_url) self.model model def chat(self, messages, **kwargs) - Dict[str, Any]: response self.client.chat.completions.create( modelself.model, messagesmessages, **kwargs ) return { content: response.choices[0].message.content, provider: local, model: self.model } def embed(self, texts: list[str]) - list[list[float]]: # 本地 Embedding 模型如果未部署可抛异常提示 raise NotImplementedError(本地 Embedding 需要额外部署请根据实际环境扩展)这里展示了“可替换”的核心因为本地服务也可能兼容 OpenAI 协议所以LocalProvider同样用OpenAI客户端只改一个 base_url。这大大降低了切换成本。5.5 故障切换与降级有了多个 Provider 之后我们在main.py里实现一个简单的路由和故障切换逻辑# 文件路径main.py import random from typing import List from providers.base import BaseProvider from providers.openai_provider import OpenAIProvider from providers.local_provider import LocalProvider class AIGateway: def __init__(self, providers: List[BaseProvider]): self.providers providers def chat_with_fallback(self, messages, max_retries: int 3): 顺序尝试所有 provider遇到异常就切换到下一个。 last_error None for i in range(max_retries): provider self.providers[i % len(self.providers)] try: result provider.chat(messages) print(f[使用供应商] {result.get(provider)}) return result except Exception as e: last_error e print(f[供应商失败] {provider.__class__.__name__}: {e}) # 简单休眠后继续尝试下一个 continue raise RuntimeError(f所有模型供应商均不可用: {last_error}) def main(): # 方式 1优先本地其次云端 local_provider LocalProvider(modelqwen2.5) cloud_provider OpenAIProvider(modelgpt-4o-mini) gateway AIGateway([local_provider, cloud_provider]) result gateway.chat_with_fallback([ {role: user, content: 用一句话解释什么是平台腐化} ]) print(最终输出, result[content]) if __name__ __main__: main()在这个示例中业务代码完全不关心最终是哪个模型在提供服务。本地模型挂了就切到云端云端服务涨价了在配置里把顺序调一下就行。5.6 运行和验证假设你本机已经通过 Ollama 拉起了qwen2.5模型那么可以直接运行export OPENAI_API_KEYsk-xxx python main.py预期输出类似[使用供应商] LocalProvider 最终输出 平台腐化是指平台在吸引用户后逐渐改变规则 开始损害用户和第三方利益并服务于自身利益的过程。如果你没有本地模型可以把main()里的 provider 列表改成gateway AIGateway([cloud_provider])这样程序依然能运行只是缺少了降级能力。这个示例足够轻量你可以把它扩展成一个带配置文件和健康检查的正式服务。6. 常见问题与排查思路在搭建多模型网关时有一些高频问题。我整理成表格方便你排查。问题现象常见原因解决思路切换到本地模型后返回内容为空本地模型未正常加载或 context 窗口太小先单独调用本地模型的 chat 接口确认模型能正常生成本地 vLLM 服务响应慢GPU 显存不足或未开启连续批处理减小模型规模或使用--max-num-seqs调优API Key 暴露在代码仓库中开发者直接把 key 写死在.env或配置文件里使用环境变量注入并将敏感文件加入.gitignore某一供应商限流后整体超时没有做超时控制和熔断给每个 provider 请求设置timeout并增加熔断状态换供应商后输出格式不稳定提示词中未明确输出格式要求在 System Prompt 中加入 JSON Schema 或结构化约束向量维度不一致不同 Embedding 模型输出的向量维度不同在向量数据库中按模型名称隔离 collection或做维度映射数据安全合规检查不通过业务数据发送到了未经审批的外部 API在网关层增加“数据出域”日志和审批开关敏感数据强制走本地 provider7. 最佳实践与工程建议7.1 把“可替换性”写进架构评审标准在做 AI 应用架构设计时我建议把“可替换性”作为一项明确指标。每次引入一个新 AI 服务都问自己一个问题如果明年它涨价 5 倍我们需要改多少代码如果答案是“重构一个模块”说明抽象做得不错如果答案是“推翻重来”说明依赖过于直接。7.2 统一日志与可观测性多模型网关不仅要在调用链路上做抽象还要在可观测性上做归一化。建议为每次调用记录以下字段供应商名称。模型名称。输入 token 数。输出 token 数。延迟。返回状态。错误类型。这些数据可以用来做成本分析、性能对比和“哪家模型更适合哪类任务”的决策。没有日志支撑多模型切换就是凭感觉拍板。7.3 数据出境与合规边界企业级 AI 应用必须把合规放在技术之前。使用外部大模型 API 时要明确哪些数据可以出域、哪些不能。对于客户隐私、合同文本、财务信息等尽量走本地模型或私有化部署。网关层应该提供基于数据分类的自动路由能力而不是让业务开发人员自己判断。7.4 定期做“模型替换演练”很多系统号称支持多模型但从来没有真正切换过。等到线上出问题时才发现新模型请求根本走不通。建议每季度做一次模型替换演练在一个测试环境里把主供应商替换成备选供应商跑一遍核心链路确认效果和成本。7.5 关注许可证与开源合规使用开源模型时要注意模型许可证的更新和商用限制。不同模型的 License 不一样有的允许商用有的要求衍生模型也必须开源有的对月活用户规模有限制。这些规则不归技术团队管但技术团队要主动识别风险并上报。8. 总结与进一步学习方向Cory Doctorow 提出的“平台腐化”概念提醒我们数字平台的价值主张是会变化的。AI 时代的模型平台、云平台、数据平台都遵循类似的逻辑早期用便利换依赖中期用生态换锁定后期用垄断换利润。作为开发者我们无法阻止平台制定商业策略但可以通过架构设计让自己在平台变化时拥有选择权。本文的核心思路可以归纳为四点对上游 API 做抽象用多供应商适配器保留替换路径。对敏感数据和核心资产做本地化兜底避免数据被平台沉淀。对成本、性能、稳定性做持续观测用数据驱动选型决策。定期做切换演练让“可替换性”不是纸面能力。接下来你可以继续探索的方向包括基于 Kubernetes 的模型推理服务部署、vLLM 的推理性能调优、Agent 生态中的模型路由设计、向量数据库的跨平台迁移方案。如果对本文的多模型网关感兴趣你也可以把它扩展成一个带 Web 界面的成本监控系统这会非常实用。