产品经理面试：API 版本生命周期支持是否应该收费？

题干与适用场景

你的 B2B SaaS 有三个仍在使用的 API 版本。工程团队希望只免费维护最新版本，销售却承诺大客户长期兼容。你需要决定哪些版本继续服务、弃用如何通知、迁移工具由谁承担，以及长期支持是否应该作为付费能力。

RFC 8594 定义了表示资源可能在未来失效的 Sunset 响应头，RFC 9745 定义了表示资源已弃用的 Deprecation 响应头。它们提供机器可读的沟通信号，却不会替产品团队决定支持期限、客户分层或迁移责任。

这道题讨论 API 生命周期产品治理和商业边界，不等同于“如何实现 API 下线”或“如何制定 API 采用策略”。

面试官考察点

• 能否把兼容性承诺连接到客户价值、续约和工程成本。
• 能否定义版本、支持级别、弃用通知和迁移成功的可验证契约。
• 能否区分所有客户应得的安全修复与可收费的长期维护服务。
• 能否处理销售例外、合同承诺、生态公平和自助迁移体验。
• 能否用指标、试点和停止条件管理生命周期，而不是无限承诺。

回答前需要澄清的问题

1. 旧版本的调用量、收入、客户集中度和主要失败场景是什么？
2. 哪些变更属于安全修复、错误修复、功能增强或破坏性变更？
3. 客户合同是否已有支持年限、通知期、服务等级和赔偿条款？
4. 客户能否在不改业务逻辑的情况下切换版本，是否有 SDK、迁移报告和测试环境？
5. 销售承诺是个别例外，还是已经形成所有大客户都会要求的市场预期？

30 秒回答框架

先按使用量、收入、风险和迁移难度分群，再把安全修复和弃用通知设为基础承诺。最新版本和有限窗口的旧版本免费维护；超过窗口的长期支持可收费，但必须包含明确的版本范围、响应级别、迁移工具和退出日期。用兼容性指标、迁移完成率和支持成本试点，验证客户愿意为风险降低付费，再决定是否扩大。

分步骤深入解答

1. 先验证问题是否值得商业化

建立版本地图：每个版本的请求量、活跃客户、收入、错误率、敏感数据风险、SDK 覆盖和预计迁移工时。把客户分成可自助迁移、需要协助迁移和合同约定长期兼容三组。

访谈开发者、采购、安全和客户成功团队，确认客户购买的是旧版本本身，还是迁移风险、停机风险和内部审批成本。若大多数客户只是缺少迁移文档，收费长期支持可能会惩罚可通过产品改进解决的问题。

2. 设计分层生命周期

可采用“当前版本、维护版本、弃用版本”三态。当前版本获得新功能和常规修复；维护版本只接收安全与高影响错误修复；弃用版本继续返回清晰的迁移指引和机器可读通知，并在承诺日期后停止服务。

每个版本公开发布日期、弃用日期、停止日期、支持范围和替代版本。Deprecation 用来表达弃用状态，Sunset 用来表达预计失效时间；文档、控制台、SDK 警告和客户联系人应使用同一时间线。

3. 划定免费与付费边界

免费层应包含安全修复、公开迁移文档、变更日志、稳定的弃用通知和合理的迁移窗口。付费长期支持可以包含更长维护期、专属响应、迁移评估、批量兼容测试和定制连接器，但不能把修复产品自身安全缺陷作为加价项目。

定价可以按版本数量、支持期限、调用量或服务等级分层。合同必须写明覆盖的端点、修复类别、响应时间、客户配合义务、例外审批和最终停止日期，避免销售口头承诺形成无限责任。

4. 设计迁移工具和证据

先提供差异报告、弃用端点清单、请求样例、SDK 版本建议、沙盒和回放测试。对可自动改写的参数提供 codemod 或 lint 规则，对语义变化则提供人工检查清单和灰度流量。

用迁移成功率、失败原因、回滚次数、测试覆盖和从通知到切换的天数判断工具是否有效。不要把“客户点击了迁移指南”当成迁移完成，完成必须以新版本真实请求和关键业务结果为准。

5. 处理销售例外与公平性

建立例外登记：客户、承诺人、合同条款、版本范围、到期日、成本和替代方案都可审计。短期例外应有价格和退出日期，不能只靠工程团队私下维护分支。

对所有客户公开相同的基础时间线；付费客户获得额外服务能力和更长窗口，但不应获得隐瞒弃用或绕过安全修复的特权。若历史合同冲突，先让法务和销售确认义务，再由产品发布统一公告。

6. 评估成本、风险与指标

成本包括构建矩阵、测试环境、值班、文档、SDK 和旧依赖的安全修复。风险包括旧版本漏洞、迁移失败导致停机、客户锁定感和生态碎片化。

核心指标包括旧版本调用占比、弃用通知触达率、迁移完成率、迁移失败率、支持工时、长期支持毛利、重大安全修复时效和续约影响。按客户分层观察，避免大客户少量调用掩盖大量小客户的迁移负担。

7. 路线图与停止条件

第一阶段清理版本地图、合同承诺和通知机制，选两个客户试点迁移工具。第二阶段上线控制台提醒、差异报告、沙盒和付费长期支持合同。第三阶段根据调用下降、迁移成功和毛利决定是否停止旧版本或增加自动化。

停止条件包括安全修复无法按期完成、例外数量持续增加、迁移失败造成高风险事故、客户不愿付费且调用价值下降，或维护成本超过保留收入。达到条件时冻结新客户接入旧版本，提前公告并执行最终停止计划。

高质量示范回答

我会先画出版本使用、收入、合同和迁移难度，再把安全修复与弃用通知设为所有客户的基础承诺。当前版本提供新功能，维护版本只修安全和高影响错误，弃用版本在公开窗口内继续服务并通过 Deprecation 与 Sunset 头、控制台和文档发出一致通知。

长期支持可以收费，但收费内容应是更长窗口、专属响应、迁移评估和兼容测试，不能把产品安全缺陷收费化。先用差异报告、沙盒和回放测试帮助两个客户迁移，观察调用下降、完成率、失败率、支持工时和续约影响，再决定扩大付费支持或按停止条件关闭旧版本。

常见错误

• 只按工程方便立即关闭旧版本，没有查看收入、合同和迁移风险。
• 把安全修复放进高价套餐，破坏基本信任和安全责任边界。
• 只发布博客通知，没有机器可读的弃用时间、控制台提醒和客户触达记录。
• 承诺“长期兼容”却没有端点范围、响应级别和最终停止日期。
• 把迁移文档浏览量当成迁移成功，不验证真实新版本请求。
• 为单个大客户维护私有分支，导致版本矩阵不可审计。
• 没有冻结新客户接入旧版本和最终停止的退出条件。

追问及应对

为什么不全部免费维护？

有限窗口的基础维护降低生态风险；无限期限会持续增加测试和安全成本。付费长期支持把额外期限与服务责任显式化，同时保留公平的基础安全承诺。

客户说合同承诺了永久兼容怎么办？

先保存合同证据并让法务、销售确认义务。产品上登记例外范围和到期日，提供迁移方案；在义务未厘清前不单方面停止服务。

RFC 头部能解决弃用沟通吗？

不能。Deprecation 和 Sunset 提供机器可读信号，但还需要文档、控制台、SDK、客户联系人和支持流程共同执行时间线。

如何防止付费支持变成锁定客户？

公开版本规则、导出迁移工具和停止日期；付费价值放在响应、评估和测试服务上，让客户能够在没有供应商协助时完成基本迁移。

什么时候值得提供 codemod？

当参数变化可静态识别、客户数量大且失败模式稳定时值得提供。语义变化或数据迁移仍需沙盒、回放和人工校验，不能承诺全自动安全转换。

哪个指标决定停止旧版本？

综合调用占比、关键客户覆盖、迁移完成率、失败风险、支持成本和合同义务。单一调用量阈值无法反映少数高风险客户的影响。