最近有个视频讨论很值得开发者关注Cory Doctorow 谈 AI 与 Enshittification 时代。这期内容不教你调参也不推荐新框架而是把过去两年 AI 行业里“平台怎么一步步变差”的现象拆开讲清楚。Enshittification中文可以译作“平台腐化”或“劣质化”是 Doctorow 长期观察互联网平台生存周期的核心概念如今用在 AI 领域依然锋利。这次我们不谈部署、不跑基准测试先把话说清楚这个视频回答的是“为什么很多 AI 服务一开始很好用越往后越别扭”。如果你正在做 AI 产品选型、调第三方模型 API或者在公司内部推动 AI 工具落地这期视频对你有实际参考价值。文章里我会把概念、观察信号、工程应对方案和评估清单一并整理出来你可以直接拿来做技术决策时的检查工具。1. 核心知识速览项目说明演讲者Cory Doctorow记者、科幻作家、数字权利活动家电子前沿基金会EFF特别顾问核心概念Enshittification平台/服务在生命周期中逐渐从“对用户好”转向“对股东好”的过程讨论对象AI 产品、模型 API、数据平台、开源生态主要论点AI 行业正在出现与社交平台类似的“平台腐化”路径但开发者仍有应对空间适合读者AI 产品经理、算法工程师、技术负责人、关注数据合规与开源的开发者视频性质访谈/演讲视频基于公开背景梳理细节需以视频原始内容为准关联话题平台互操作性、数据便携性、开源模型、版权与合理使用、模型监管2. 什么是 Enshittification从一个互联网新词说起Enshittification 最早被系统化表述是在 Doctorow 关于平台经济与数字市场运行的写作中。它描述的是一个平台为了吸引用户初期会提供非常好用的功能、更低的费用、更开放的数据等用户和第三方商家形成依赖后平台开始挤压各方利益先牺牲商家和开发者的体验再逐步降低用户服务质量最终把平台的大部分价值转移给股东或平台自身。Doctorow 认为这个周期不是偶然而是平台权力结构带来的必然。只要平台掌握着“用户访问的入口”和“商家触达用户的通道”它就有一层层收割的动机。简单说第一阶段平台用补贴和高质量体验拉新。第二阶段平台让商家/开发者投入资源形成依赖。第三阶段平台提高抽成、限制数据访问、插入广告、降低服务质量因为这些用户已经“无处可去”。这个框架搬到 AI 行业能解释很多现象。比如某个 AI API 刚上线时速度快、价格低、限制少开发者纷纷接入等开发者把业务逻辑都挂在上面之后服务方开始调整限流策略、提高单价、修改数据条款甚至要求额外付费才能使用更高质量模型。开发者想迁移却发现提示词、微调结果、上下文缓存都和该平台深度绑定。从工程角度看这与“供应商锁定”是同一个问题但表现形式更隐蔽因为它叠加了数据资产和模型效果的锁定。3. 从视频主题看 AI 领域的 Enshittification 信号3.1 平台从“开发者友好”转向“股东友好”AI 服务和社交平台一样也会经历先补贴、后收割的过程。早期为了吸引开发者和内容创作者平台会给更慷慨的免费额度、更灵活的数据访问政策。当生态形成后产品开始更多考虑盈利和股东回报常见的表现包括免费配额大幅缩减并且不提前告知。同一模型被拆成多个版本售卖低版本被刻意限制。输出结果开始强制携带平台品牌或水印逻辑。取消对第三方工具链的官方支持引导用户使用平台自研生态。这些现象不意味着“坏公司”而是商业模式进入新阶段的信号。作为技术决策者我们需要在接入一个 AI API 之前就评估它未来可能发生的策略变化而不是等功能被砍后再找替代方案。3.2 数据与版权的“灰色地带”变成风险敞口视频讨论的另一个重点是数据来源和版权问题。大量模型在线训练时使用了未经授权的数据当监管和诉讼压力增加平台会调整数据使用条款部分功能可能因此下线。对开发者来说这带来的不是道德争议而是实际风险你依赖的模型服务可能因为数据授权问题突然变更能力范围。所以更稳妥的做法是在选型时关注模型的训练数据来源、授权协议、公司所在法域并对核心业务做备份方案。如果一项能力只能依赖单一在线 API且对方的数据条款不透明就应该把它视为高风险依赖。3.3 封闭生态与互操作性的缺失Cory Doctorow 一直强调互操作性的价值。在 AI 领域互操作性意味着你能否把你在一个平台上的数据、配置、工作流迁移到另一个平台你的工具链是否依赖特定 API 的特殊字段你的提示词和评估集是否可以随时导出目前很多 AI 产品并不提供完整的数据导出能力。比如对话历史、用户反馈数据、模型调用记录这些数据在平台内查询很容易但要批量导出到本地或者迁移到另一个供应商往往缺少标准接口。这与社交媒体时代的“数据便携性”问题如出一辙。4. 开发者如何识别 AI 平台腐化早期信号如果你不想等平台变差后才被动应对可以定期用下面这套检查清单评估你正在使用的 AI 服务。4.1 条款与定价检查信号关注点风险等级价格调整频率一年内多次涨价且无梯度说明高免费配额变动从稳定变为按周/按日变动高数据条款是否能导出自己的数据是否默认授权训练高服务级别协议有没有明确的可用性承诺和补偿机制中模型版本控制平台是否允许锁定 API 的模型版本中4.2 技术可迁移性检查在架构设计阶段最好假设“当前使用的 AI API 会在三个月后变更”。为了减少迁移成本把 AI 调用封装成独立模块不要散落在业务代码中。统一请求和响应结构用适配器对接不同供应商。记录每次调用的输入输出到日志系统形成自己的评估数据集。对关键业务设置“候选供应商”并进行周期性验证。这样即使某个平台进入“腐化加速期”迁移成本也可控。5. 从工程视角看应对方案开放模型、本地部署与数据主权Cory Doctorow 在讨论中多次提到“离开的能力”才是用户和开发者真正的筹码。对于 AI 技术栈这个“离开的能力”可以通过以下工程手段实现。5.1 优先选择开放模型与可自部署方案当业务允许时优先考虑权重开放的模型。开放模型可以本地部署也可以使用自托管推理服务避免把核心数据全部托管在单一厂商。以下是两种路线的对比维度在线商用 API开放模型本地部署获取成本按调用量付费初期低后期不稳定需要 GPU 和运维成本数据控制数据经过第三方服务数据完全自控模型更新服务商控制可能强制变更自行选择更新节奏可迁移性依赖服务商 SDK 和 API导出模型文件即可迁移适用场景快速验证、低延迟、无 GPU 团队数据敏感、长期依赖、批量任务实际项目中比较合理的策略是“双轨制”快速原型、小流量实验走在线 API稳定业务、敏感数据处理走自部署模型。两条路线并存可以增强议价能力和抗风险能力。5.2 把提示词和评估数据当成一等资产管理在 AI 应用中提示词、few-shot 样例、评估集、微调数据都是重要的工程资产。如果这些资产只存在于某个 AI 产品的 Web 界面里迁移就是空谈。建议在项目目录中严格管理这些资产用 Git 跟踪版本ai_assets/ ├── prompts/ │ ├── system_prompts.md │ └── task_prompts/ ├── few_shot_examples/ ├── evaluation/ │ ├── test_cases.json │ └── golden_answers.json ├── fine_tuning/ │ └── datasets/ └── configs/ └── model_endpoints.yaml这样做的好处是更换模型供应商时只需要调整适配层和配置不需要重新积累测试数据。5.3 建立互操作性的技术基线互操作性不能只停留在口号层面。对 AI 应用来说可以参照以下基线模型接口使用 OpenAI 兼容格式便于切换兼容层。存储层使用通用格式比如 JSONL 保存对话日志和推理结果。特征和向量化表示不绑定特定数据库的品牌。缓存层设计成可替换接口。当你实现这些基线后平台变动带来的冲击会小很多。6. AI 生态健康度评估清单将 Doctorow 的框架应用到 AI 工具评估中可以建立一个“生态健康度”快速打分表。每个维度 0-5 分分数越低代表腐化风险越高。维度高分特征低分特征得分数据便携性提供完整导出 API支持标准化格式只能手动复制无批量导出模型开放度开放权重可自部署仅在线接口封闭权重条款稳定性定价和条款有明确变更公告期随时变更且影响已上线业务互操作性OpenAI 兼容接口SDK 不绑定业务专用协议只能使用官方 SDK版权透明度公布训练数据来源和授权方式数据来源不明侵权诉讼多社区与开源有活跃开源社区、第三方工具链只能使用厂商提供的工具退出成本可以低成本迁移到开源替代方案迁移需要重写全部业务逻辑建议每季度对所有关键 AI 依赖项做一次评估。当某项分数持续下降就应当启动替代方案预研。7. 常见认知误区误区一“大厂不会突然砍掉服务”实际上AI 产品迭代速度极快特别是依托大模型的能力层经常因监管、成本、版权原因调整服务范围。不要因为供应商体量大就降低风险意识这也正是“大而不能倒”逻辑在技术层面的误用。误区二“开源模型一定更安全”开放权重只是起点还需要关注模型许可证、训练数据合法性、下游使用限制。有些模型允许下载但商用条款、衍生品发布条件都有限制。选择开放模型同样要做合规审查。误区三“本地部署就能避开所有问题”本地部署解决了数据跨境和平台依赖问题但带来了运维、算力、安全更新的新问题。你需要自己负责依赖库的安全补丁、模型更新评估、推理服务的稳定性。它是一种风险转移不是风险消除。误区四“现在趋势好未来不会变差”Enshittification 最有效的防御不是预测未来而是建立弹性。就像做服务熔断一样你无法保证上游永远可用但你可以通过降级和重试策略保持系统稳定。8. 最佳实践与行动建议8.1 产品与研发侧建立 AI 依赖供应商清单标注关键性等级。对核心业务实现“AI 能力抽象层”至少覆盖两家兼容供应商。定期验证模型输出质量维护自己的评测集不依赖供应商提供的演示指标。为高价值业务设计降级策略在线 API 不可用时自动切换本地小模型或规则引擎。8.2 数据合规侧在接入任何 AI 服务前审查其数据使用条款尤其关注“是否用你的数据训练模型”。对包含用户隐私的请求做脱敏处理或者直接使用本地部署方案。保留完整的调用记录和数据流转日志方便事后审计。8.3 组织与流程侧不要把所有鸡蛋放在一个 AI 平台上至少在业务架构层面保留“替换供应商”的流程文档。每次大模型 API 条款更新时触发一次评审而不是让工程师私下调整代码。在技术选型评审中引入“退出成本”和“互操作性”指标而不只看效果和价格。9. 总结与下一步Cory Doctorow 的这期视频值得看不只是因为它提出了一个好记的概念而是把平台经济中反复出现的“先好后坏”循环讲清楚了。AI 时代这个循环正在加速重演。对开发者而言最实际的收获是不要把自己的技术判断建立在“平台永远保持不变”的假设上。你最先应该做的一件事是盘点当前项目里所有对 AI 供应商的单点依赖。找一个最不复杂的依赖项尝试把它替换成兼容实现或者补充一个备选方案。这个过程会暴露很多架构问题也会让你真正理解“互操作性”在 AI 工程中的分量。最容易踩的坑是把概念当成攻击平台的口号而不是把它当作风险分析工具。Enshittification 不是某种平台的宿命而是一种可以识别、可以应对、可以通过工程手段缓释的市场行为。接下来可以沿着数据便携性、模型互操作、开放权重许可三个方向继续深入研究。