产品经理面试题：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 发现：
Link: </.well-known/deprecations>; rel="deprecation"; type="application/deprecations+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，记录格式版本，允许关闭清单或回退到文档与资源级头部，并在兼容性说明中标注草案状态。
什么时候支持请求字段？
当响应字段试点证明选择器、日期和迁移流程稳定，并且请求字段有清晰的验证与回滚语义后再支持；否则会把误报直接变成写入失败。
你会怎样证明产品价值？
比较试点组与对照组的迁移完成时间、已弃用字段调用占比、支持工单和回滚率，同时检查清单解析覆盖率与误报率，避免把文档浏览量当成迁移成功。