最近有个视频讨论很值得开发者关注：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 不是某种平台的宿命，而是一种可以识别、可以应对、可以通过工程手段缓释的市场行为。接下来可以沿着数据便携性、模型互操作、开放权重许可三个方向继续深入研究。
