产品经理面试题：SaaS 是否应该提供字段级 API 弃用清单？

题目与适用场景

你的 SaaS 有大量 B2B API 客户。团队希望采用 2026 年 6 月发布的 IETF Internet-Draft《A Deprecation Manifest for Field-Level Lifecycle Signalling in HTTP APIs》，通过 application/deprecations+json 告知单个请求或响应字段的弃用、日落时间和替代项。请判断是否应把它做成产品能力，并说明范围、客户价值、兼容策略、发布顺序和成功指标。该草案仍是 work in progress，不是最终 RFC。

面试官考察点

能否把协议能力翻译为客户问题、迁移工作流和商业价值。
能否区分资源级响应头（RFC 9745、RFC 8594）与字段级清单的边界。
能否在标准未定稿时控制承诺、兼容性和治理风险。
能否用可观测指标验证采用率、迁移完成度和误报率。

回答前需要澄清的问题

客户主要使用 SDK、OpenAPI 生成器，还是直接解析 JSON？
当前是否已有弃用公告、版本策略和联系人通知机制？
字段弃用是否集中在响应字段，还是也包括请求字段、嵌套数组和多态结构？
目标是帮助人工迁移，还是让 CI/CD 和 SDK 自动阻断风险？
哪些客户、地区或合规场景要求保留旧字段多久？

30 秒回答框架

先确认问题：客户难以及时发现字段级变更，资源级 Deprecation/Sunset 头部无法表达每个成员的生命周期。我的结论是做“可选的字段级生命周期信号”试点，不把草案包装成稳定标准。第一阶段只覆盖响应字段，提供清单、文档链接和替代字段；同时保留 OpenAPI、公告和资源级响应头。用试点客户的发现率、迁移完成时间、误报率和回滚率决定是否扩大范围。

分步骤深入解答

1. 定义客户痛点与边界

字段被弃用通常仍会在一段时间内返回。客户需要知道“哪个字段、何时弃用、何时移除、替代什么”，而不是只看到整个资源有一个生命周期信号。清单解决发现和编排问题，不改变字段当前行为，也不能替代版本政策、契约测试或人工沟通。

2. 解释协议与现有能力的关系

资源级头部仍是默认通道。字段级清单可通过 Link 发现：

http

Link: </.well-known/deprecations>; rel="deprecation"; type="application/deprecations+json"

示例清单：

json

{
  "deprecations": [
    {
      "target": "response",
      "selector": "$.customer.legacy_name",
      "selectorType": "jsonpath",
      "deprecation": "2026-09-01",
      "sunset": "2027-03-01",
      "replacement": "$.customer.display_name",
      "info": "https://docs.example.com/migrations/customer-name"
    }
  ]
}

在产品设计上应把格式、发现方式和业务治理分开：草案变化时，客户仍能通过文档和 OpenAPI 获取稳定说明。

3. 选择最小可行产品

先支持响应中的 JSON 字段、单一 API 版本和明确日期。暂不承诺所有 JSONPath 方言、请求体变体、GraphQL、二进制协议或自动改写客户端。清单只读、可缓存，并提供原始文档链接和人工确认入口。

4. 设计发布与迁移流程

变更登记后，平台生成清单并校验日期顺序；文档、SDK changelog 和客户通知同步发布。先对内部 API 和设计合作客户灰度，再扩大到自助客户。遇到误报或日期变更，必须保留版本记录和回滚开关。

5. 设置治理、风险和指标

治理规则包括字段所有者、最短通知期、替代项必须可用、日落前的例外审批。核心指标包括：清单发现率、受影响调用识别率、从通知到迁移完成的中位天数、仍调用已弃用字段的请求占比、误报率、客户支持工单量和回滚次数。若客户没有解析清单，产品应投资 SDK、CLI 或 CI 检查，而不是继续堆格式。

6. 做出阶段性决策

若试点显著缩短迁移时间且误报可控，扩大到请求字段和嵌套结构；若收益主要来自文档而非机器解析，则把清单保持为高级能力，优先完善 OpenAPI、通知和版本政策。任何对外承诺都应标注草案依据和兼容保证。

高质量示范回答

我会做，但先把它定位为“字段级生命周期信号”试点，而不是宣传一个已经定稿的标准。客户现在能收到资源级 Deprecation 和 Sunset，却难以知道响应中的具体成员；字段级清单可以把发现、替代项和日期交给自动化工具。

第一阶段只支持一个 JSON 响应模型和明确的弃用、日落日期，保留 OpenAPI、文档和资源级头部作为兼容通道。平台在变更登记时校验字段所有者、替代项和最短通知期，先让内部及设计合作客户接入，记录发现率、迁移中位时间、已弃用字段调用占比、误报率和回滚次数。清单格式来自 2026 年 6 月的 IETF 草案，因此我会在文档中明确它仍可能变化，并保留关闭或降级开关。

若试点证明客户能更早发现变更且支持成本下降，再扩大到请求字段和更复杂结构；若客户主要依赖文档而不解析清单，就把资源投入转向 SDK、CI 检查和通知编排。产品成功标准是减少意外破坏和迁移时间，而不是增加一个协议名词。

常见错误

把 Internet-Draft 说成已批准的 RFC，或承诺所有客户端立即支持。
只讨论 JSON 格式，不说明字段所有者、日期政策、通知和回滚。
认为响应头可以自动定位任意嵌套字段。
只给“做/不做”结论，没有试点、指标和停止条件。
忽略请求字段、数组索引、多态结构造成的选择器歧义。

追问及应对

如果客户不解析清单怎么办？

把清单作为机器可读补充，继续提供 OpenAPI、迁移文档、SDK changelog、Webhook 或邮件通知；用发现率验证真实使用，而不是强迫客户采用。

如何处理草案发生变化？

隔离 manifest 生成器和客户 API，记录格式版本，允许关闭清单或回退到文档与资源级头部，并在兼容性说明中标注草案状态。

什么时候支持请求字段？

当响应字段试点证明选择器、日期和迁移流程稳定，并且请求字段有清晰的验证与回滚语义后再支持；否则会把误报直接变成写入失败。

你会怎样证明产品价值？

比较试点组与对照组的迁移完成时间、已弃用字段调用占比、支持工单和回滚率，同时检查清单解析覆盖率与误报率，避免把文档浏览量当成迁移成功。