AI平台腐化下的技术选型：构建可迁移、可替换、可降级的AI栈

前几天我在重构一个内部 AI 知识库问答服务顺手核对了一遍所用大模型 API 的更新记录。接口签名没变模型版本也没有标红但线上返回内容的质量明显走上了另一条曲线原本能直接回答的问题开始频繁给出“正确但无用”的套话原本很简洁的输出开始莫名多出一大段免责表述。与此同时服务商悄悄调整了限流策略计费粒度也从按次变成了按更细的 token 单元文档里关于数据留存的一句话也改得更加模糊。那一刻我脑子里跳出来的词是 Cory Doctorow 在讨论互联网平台时反复使用的 enshittification。这个词在国内技术圈通常被译作“平台腐化”或“平台衰败”。它描述的不是一个功能坏掉而是一个系统性的过程平台为了不断获取更多价值最初的慷慨会逐渐消失用户和第三方开发者的体验被一点点换取利润直到整个生态被榨干。过去很多人用它解释搜索结果页广告越来越多、社交平台时间线越来越吵。但现在我要提醒AI 生态进入这个阶段的速度比我们想象的快得多。这不是在否定 AI 工具的价值。相反正因为大模型已经能承担大量真实工作我们才更需要看清楚当开发者习惯性地把所有能力挂到同一个外部平台上之后真正构成危险的并不是模型不够聪明而是你如何被逐渐绑在一套由别人定义规则的系统里。这篇文章想说的只有一件事AI 时代真正值得长期修炼的不是“如何更熟练地调用某个平台”而是“如何让自己手里的技术栈永远保有离开某个平台的能力”。1. 为什么 AI 生态现在需要重新提起“平台腐化”1.1 从社交平台到智能平台同一个剧本反复上演Cory Doctorow 对 enshittification 的总结有一个非常犀利的地方它不是一个偶然事故而是一个有规律的商业演化。第一阶段平台为了让生态长大会用低价、免费额度、开放接口、宽松政策吸引用户和开发者第二阶段平台开始把早期积累的用户作为议价工具转卖给广告商、投资者和平台自身的“优先功能”第三阶段当用户和第三方开发者已经很难迁移时平台开始直接从他们身上抽取最大价值。这套剧本在传统的社交和搜索平台上已经被验证过很多次。而 AI 平台尤其是提供大模型 API、在线推理和模型托管服务的平台本质上也是同样的生态结构提供接口的是平台被吸引来的第三方开发者是引水者最终用户是消费者。三者之间出现了新的信息不对称——平台比开发者更清楚模型能力的变化也比开发者更容易调整规则来改变收益结构。所以不要觉得 AI 平台天然就比上一代互联网平台更“纯洁”。它只是一套新的基础设施而基础设施一旦形成中心化就会立刻面临“谁来定义规则”的问题。1.2 AI 时代的腐化比传统 SaaS 更隐蔽传统软件即服务SaaS的腐化有一个非常清晰的信号功能越来越多、价格越来越贵、外部数据导入导出越来越受限。但 AI 平台的腐化点隐蔽得多因为它动的往往不是“功能列表”而是模型行为。API 没有变计费没有涨但模型底层的权重版本已经悄悄换掉了。原本在特定场景下表现良好的输出可能因为一次“安全策略调整”或“训练数据更新”而变得完全不同。这在传统软件里很难想象你升级功能版本前至少还能看 changelog而大模型 API 的“存在行为漂移”是常态平台不一定会在公告里写清楚。更麻烦的是很多 AI 平台的基础模型并不可替换。你用某个平台提供的向量检索、函数调用、知识库托管表面上是在调 API实际是把整个应用的记忆、行为和上下文一起托管到了对方那里。一旦规则变化你连“替换一个模型”的机会都没有只能重写应用。1.3 为什么这项讨论现在做比以后做更从容一个现实是今天绝大多数 AI 应用还很小。它们可能是团队内部的小工具、一个自动生成摘要的脚本、一个带检索增强的聊天机器人。它们还没有承受真正的商业压力也没有在被平台收割后陷入绝境。但这恰恰是重构技术栈成本最低的时候。等到应用规模变大、用户量上升、数据积累到一定程度时你再想从某个模型 API 迁移到另一个就不只是改一个调用接口的问题而是要把历史对话、知识库上下文、向量索引、评估集全部重做。越早把“可迁移性”当作一等公民来设计后面就越灵活。从工程经验看这个阶段最该做的不是追求接满所有平台而是先选一个最典型的场景把“换下游模型”这件事完整演练一遍。如果你能够在一天内从一个模型切到另一个模型而不影响业务那么无论平台如何变化你都有底气。2. AI 技术栈里的腐化点比表面看起来更靠近底层2.1 不只是价格问题而是控制权问题很多团队在选择大模型 API 时最关心的是单次调用价格。这当然重要但它只是最表层的成本。真正要算的是切换成本如果你现在把聊天、改写、分类、思维链都放到同一家平台的生态里未来它上调价格、缩小上下文、改变输出偏好你手上的牌其实很少。价格是明面上的控制权是隐性的。你调用的模型版本是否可指定平台是否允许你把模型权重下载到本地自行部署输出结果是否允许用于后续训练和研究这些问题直接决定你是在消费一个服务还是在慢慢欠下技术债。很多平台早期会用“超低单价、超高额度、免费试用”制造低风险假象。一旦业务跑起来你又不可能立刻换因为提示词、下游字段、输出格式都按它的约定写了。等到价格回归理性你才发现自己已经被嵌入得比预想更深。2.2 数据腐化你的知识库正在成为别人平台的养料另一个容易被忽略的腐化点是数据。很多 AI 应用会把内部文档、用户对话、检索内容发送到远程模型 API 处理。平台在隐私协议里可能会写“数据仅用于处理请求”但数据一旦过境你就失去了完整的控制力。更重要的是如果你长期依赖某平台的向量数据库和检索接口你积累的知识库索引会被私有格式锁定。这就像过去博客时代“所有文章都存在某个博客平台的数据库里平台改版后导出格式不兼容”的翻版。只不过现在不止是文章还包括对话历史、改写偏好、知识图谱、工具定义。数据层的腐化往往是无声的因为直到你想离开的那一刻才会发现导出数据困难重重。所以在数据架构上我更建议把“原始数据存储”和“模型生成数据”分开。原始数据必须始终握在自己手里向量化只是派生的检索形式。定期把原始文档和对话日志导出到自有的对象存储或关系型数据库里即使未来换向量库也能重建索引。2.3 行为漂移你很难保证“昨天能用的功能今天还能用”我在实际维护 AI 应用时最头疼的不是模型答错而是模型行为漂移。上周测试集上 90% 通过率的提示词这周可能因为平台端调整了系统默认温度temperature或安全策略直接掉到 70%。平台没有提供明确的版本锚点也没有让用户锁定某一次确定的部署快照你的应用只能被动跟随。这类问题需要靠长期的评测集和监控来解决。但在许多团队里评估往往只在接入新模型时做一次后续再也没有运行。于是平台的每一次“隐性更新”都在替你修改应用的真实行为而你甚至无法区分它是模型能力变化还是自身业务逻辑 bug。要应对行为漂移首先要建立“质量基线”。从核心场景里抽出 20 到 50 个典型问题写好标准答案或判断规则。每次平台有变动或者每逢固定周期就重新跑一遍。这样至少能帮你定位问题出在输入、提示词还是模型本身。3. 用“退出成本”重新制定 AI 技术选型标准3.1 一个更容易记住的判断框架我给团队做选型时会用一个非常简单的框架看“退出成本”而不是只看“接入成本”。接入成本是第一次调用时省了多少分钟退出成本是如果明天不想用这个平台换到替代方案需要投入多少人力。好方案不一定接入最快但一定能让你在离开时付出可承受的代价。具体到 AI 技术栈退出成本可以分为三个维度数据可迁移、模型可替换、客户端可降级。数据可迁移你的数据是否可以导出为标准格式如 JSON、CSV、Parquet向量索引能否重建。模型可替换你选择的 API 是否兼容多个厂商或可以用本地模型替代。客户端可降级如果远程模型不可用你的应用是否有离线简单模式而不是完全瘫痪。这三个维度不需要一开始全部满足。但最好在技术方案文档里写清楚当前的选择在哪个维度有风险未来如何补救。3.2 评估 AI 工具时最该问的 7 个问题在实际落地中我会把上面的框架拆成几个更具体的问题用于评估一个 AI API 或平台是否值得长期依赖是否支持显式指定模型版本还是只能跟随平台默认版本是否提供标准的 OpenAI 兼容接口还是只能用平台专属 SDK核心数据对话、文档、知识库能否方便导出向量检索和内存缓存是否本地可跑是否有开源的替代实现平台是否有历史行为基准和变更日志能让你及时发现模型漂移如果平台停止服务你的应用是否还能降级到规则模式或本地模型这些问题不一定每个都能得到满意答案但至少能帮你在签约前发现潜在的锁定点。尤其是第 6 条很多人会忽略。一个平台如果连“模型行为变更说明”这种基础服务都不提供那它对开发者就是黑盒风险完全由你来承担。3.3 一个最小可用的模型抽象层示例为了降低退出成本我建议所有 AI 项目在业务代码与具体模型 API 之间加一层薄薄的抽象。不需要过早引入重型框架一个简单的策略类Strategy就够用。下面是常见的抽象写法适合小团队快速落地# completion_gate.py class CompletionGate: def __init__(self, provider): self.provider provider def complete(self, messages, **kwargs): return self.provider.complete(messages, **kwargs) class OpenAICompatibleProvider: def complete(self, messages, **kwargs): # 调用某个兼容 OpenAI 接口的服务 endpoint kwargs.get(endpoint, https://your-endpoint.example/api/completions) # 具体 HTTP 请求省略 pass class LocalModelProvider: def complete(self, messages, **kwargs): # 调用本地部署的模型推理服务 pass这个示例的核心不是代码本身而是它的设计意图业务层只依赖 CompletionGate不直接依赖某个具体供应商的 SDK。将来要换模型只需要新增一个 Provider而不是改动所有业务代码。在实际项目里这种抽象往往是一个高成本收益比的第一步。4. 一个可以落地的抗腐化检查清单4.1 模型层做替换而不是做绑定在工程实现上第一步仍然是把模型调用抽象出来。如果项目已经深耦合到某个 SDK也不要慌张可以先按“接口抽取—逐步替换—回归测试”的顺序改造。具体操作是先定义一个当前业务真正需要的能力接口例如产品文案生成、摘要、分类然后写一个适配器将现有模型 API 适配到该接口接着把业务代码中的直接调用替换成适配器调用最后再实现第二个适配器用另一个模型或本地模型验证替换路径是否通畅。这个过程中最重要的不是代码写得多么优雅而是“第二适配器”必须真的跑通。如果只是写了一个接口但没有第二个实现那这个抽象仅仅增加了一层间接层并不能降低退出成本。我见过不少团队做了接口封装却从不真的切换最后反被那种虚假的安全感耽误。4.2 数据层做分离而不是做同构知识库、对话日志、用户行为数据应在应用层保留一份结构化副本。许多 AI 应用喜欢把所有东西都塞进平台提供的向量数据库虽然方便但一旦平台索引格式变化重建成本和数据泄露风险都会倍增。更稳妥的做法是在数据产生时先把原始数据存到自有的对象存储或关系型数据库里向量化只是为了检索而生成的派生数据可以随时根据原始数据重新生成。同时定期导出向量索引的元数据确保未来可以在另一个向量库中重建。从常见实践看这个原则也适用在 Agent 工具定义上。工具函数、外部 API 的请求格式尽量使用通用标准例如用 JSON Schema 描述参数用 OpenAPI 定义接口调用不要让某个平台的 Agent 协议把你的工具定义锁死。4.3 可观测性不只是监控请求量还要监控模型行为抗腐化不能只靠“相信平台不会变”。我通常会在 AI 网关层记录三类指标请求层面延迟、状态码、token 数、成本层面每次请求费用、月度趋势、质量层面是否通过测试集、关键输出是否稳定。其中质量层面最容易忽略。建立一个小样本评测集覆盖 20 到 50 个典型问题每天或每次平台变更后跑一遍看输出是否发生明显漂移。一旦发现质量指标明显下降就可以按下面的链路排查先看评测集是不是最近改过提示词或标准答案再看平台侧是否有模型版本、安全策略或 API 行为变更公告再看输入侧文档、上下文、检索结果是否发生变化最后看基础设施限流、超时、网络、缓存是否异常注意不要一上来就把所有评测集都放进自动化流程。先手工跑 5 个核心场景确认评测集本身稳定后再逐步扩大覆盖面。4.4 设计降级路径断网、限流、平台停服时应用还能做什么我在给团队做 AI 应用设计时会强制要求回答一个问题“如果所有外部模型 API 突然不可用你的应用还能不能给出价值”答案不一定是“能”但必须有一个明确的降级策略。对于内部知识库问答可以降级为关键词搜索加段落摘录对于内容生成可以降级为模板生成对于对话机器人可以降级为 FAQ 匹配。很多时候一个粗糙的降级方案反而能避免整个系统在意外来临时彻底失效。设计降级路径时不需要做到与完整模型能力相当只要保住核心业务的最小闭环。然后通过开关控制检测到请求失败率超过阈值、或平台返回特定错误码自动进入降级模式并向运维告警。5. 个人、团队、社区能做的三个长期动作5.1 把评估集和提示词当作“自己的资产”很多团队把提示词直接写在代码里改起来很随性也没有版本管理。但提示词本质上是一种需要在多次模型变化中反复评估的系统资产。把它抽取到配置中心纳入 Git 版本管理配合评测集一起维护才能在模型漂移时快速定位问题。个人项目也不必过度工程化。一个目录包含 prompts/ 和 eval/用脚本一次性跑完所有样例输出对比报告这已经比大多数团队做得更好了。提示词里的每个变量、每个指令都应该能追溯改动时间与影响范围。长期来看评估集和提示词会变成团队内部对模型行为最重要的理解载体。它比任何文档都更能说明“好结果”长什么样也是你在更换模型时衡量损失的直接依据。5.2 优先使用开放权重模型和标准接口如果场景允许我更建议把开放权重模型纳入技术栈。开放权重模型意味着你可以在推理平台之间迁移甚至本地部署。配合开源推理框架业务不会因为某一家平台的策略变化而被迫重写。但也要承认本地部署有门槛。硬件资源、推理延迟、运维成本都需要计算。务实做法是小模型和离线降级场景用本地推理高难度复杂生成调用远程 API两类模型都接在统一的抽象层后面用到哪种切换哪种。即使本地模型效果稍弱它仍然是一道重要的安全边际至少你不会在平台涨价或停服时束手无策。标准接口的意义同样重要。使用 OpenAI 兼容接口或社区标准接口能让你在多个平台之间切换时不需要重新适配。即使某些高级参数不是每个平台都支持但基础的聊天补全、向量嵌入和工具调用保持兼容已经能覆盖大多数业务场景。5.3 维护“可离开”比追求“最强大”更重要社区层面人们对开源模型的投入、对互操作接口的讨论、对数据集许可的重视本质上都在做同一件事给 AI 生态留下退出通道。作为普通开发者我们未必能改变整个行业的趋势但至少可以在自己的项目里维护“可离开”这个原则。技术选型时把“这个项目将来能不能换掉底层模型”作为一个显式需求写进架构评审清单。遇到平台提供“独家能力”时先问一句这个能力是开放标准吗换一个平台还能用吗如果答案是否定的可以把它隔离在一个小模块里确保它不会渗入整个业务层。真正让一项技术对你产生价值的不是某次调用跑出了多惊艳的结果而是它在变化来临时还能继续被你掌控。这个判断标准会随着你手上项目越来越多而越发重要。6. 当风向变化时你的选择决定了技术的边界6.1 把“可离开”变成架构评审的一条默认规则以前做架构评审重点通常放在性能、安全、成本、可维护性上。现在应该加一条可退出性。每次引入新的 AI 依赖时评审单上多三个问题数据是否可迁移模型是否可替换客户端是否可降级这三个问题的答案不一定要一开始就全部通过但要写明风险等级和后续补偿计划。比如如果引入一个非开放格式的向量数据库那就必须同时准备一份索引导出脚本如果某模型只提供在线 API那就必须准备一个本地小模型作为降级选项。把“可离开”作为默认规则不是为了让流程复杂而是让风险在早期暴露。这个规则对个人项目同样适用。下次你在脚本里直接写好某家平台的 API Key 时停下来想一想如果这个平台明天关停我需要多久才能把功能迁移到另一个方案如果答案是一周甚至更久说明这个项目的确定性还不够。6.2 对抗腐化的责任不在某个平台手里而在整个生态的约束里Cory Doctorow 在讨论 enshittification 时说过这个过程的可怕之处在于它看起来像一种物理定律几乎所有平台最终都会走向腐化。但他也不是完全悲观——平台之所以腐败是因为用户和第三方缺乏离开的能力一旦用户拥有真正的退出权平台就必须持续提供价值否则就会被抛弃。AI 生态同样如此。今天的大模型 API、模型托管、向量数据库、Agent 框架都还处于早期很多规则还没有定型。如果所有开发者都把“接入快”当作唯一标准那么平台自然没有动力维护开放格式和公平条款如果越来越多团队开始关注退出成本、数据可迁移性、模型可替换性那么整个生态就会在竞争中保留更多可互操作的空间。所以我更愿意把“AI 与平台腐化”这个话题理解为它不是一句悲观的口号而是一份工程实践清单。在你接入下一个 AI 工具、设计下一个智能功能、选择下一个模型供应商时先给自己的工作流留出后路。单次跑通只说明流程没有断真正的长期价值不在于你能跑多快而在于当风向变化时你还能有自己的选择。