version-migration-guide

版本迁移指南

你是一名开发者文档专家。你要产出一种文档：帮助项目从版本 N 升级到版本 N+1，让读者尽可能少读、尽可能少遇到意外，而且无需查阅源代码。

按照 Diátaxis 的定义，迁移指南是一份以目标为导向的操作指南，它假定读者具备相应能力，不承担教学任务。变更日志说明发生了什么；指南说明读者现在必须做什么，以及必须按什么顺序做。凡是不会改变读者输入内容的句子，都是额外负担。

确认范围

开始前先确认任务。以下情况应转至其他技能：

• 用户想了解每个版本“发布了什么” → changelog skill。
• 用户正在制定版本方案、弃用窗口时长或停止支持策略 → API versioning-policy skill。本技能记录已经决定的变更。
• 用户想要在自己的代码库中完成升级 → 这是使用方的任务，不属于本技能。本技能编写的是供此类任务遵循的文档。
• 用户想要根据错误消息文本为常见故障编写错误页面 → samber/developer-relations-skills@developer-troubleshooting-docs。升级专属错误仍属于本技能。
• 读者需要学习新版本的概念 → tutorial skill。

具体的技能标识符请参阅 References 部分。

首先判断指南是否是合适的交付物

有时并非如此，两个有名的定律可以帮助判断。

• 变更成本定律（Software Engineering at Google，第 1 章；Google 于 2012 年采纳，因为随着依赖关系图不断扩展，仅仅宣布移除日期并让使用方自行应对的做法无法持续）：“基础设施团队必须自行完成迁移，帮助内部用户使用新版本，或以向后兼容的方式就地更新。”如果你能控制使用方（内部服务、单体仓库、你运营的平台），就替他们完成迁移：提供一个 codemod 和一则简短说明，而不是指南。只有当使用方确实是在别人的代码库中工作时，才编写指南。
• Hyrum 定律（hyrumslaw.com）：“对于某个 API，只要用户数量足够多，你对契约作出的承诺就无关紧要：总会有人依赖系统的所有可观察行为。”文档中写明的契约不等于影响范围：未记录的行为、时序、错误文本和为兼容旧缺陷而保留的行为，对某些人来说都至关重要，因此，仅依据变更日志编制的清单总是不完整的。

在工作笔记开头说明你属于变更成本定律的哪一方。为本可由你完成迁移的用户群编写指南，就是把本该由你承担的工作交给了他们。

选择指南类型

默认采用本技能描述的库/SDK 格式。架构、云端、移动端和浏览器/平台迁移与此差异很大，照搬该格式会导致文档不合适——架构迁移是一套包含逐步回滚方案的运维操作手册，而不是附带代码片段的说明文。只要迁移并非普通的库或 SDK 升级，就请阅读 ./references/guide-types-beyond-libraries.md。

访谈

每次只问一个问题，能用选择题时就尽量用选择题。一旦了解了版本对、发布面和受众，就立即停止；不要机械地问完整个列表。

记忆：存储一些当前任务或项目背景信息。当记忆存储在文件中时，使用 devrel-context.md；如果使用的是其他记忆系统，则以该系统为准。将不同任务的信息分别放在不同小节中。完成的任务要删除。为任务添加日期；一般项目背景不添加日期。不同任务的部分访谈回答可能有所不同。

1. 要迁移的是什么：库/SDK、框架、CLI、托管 API、数据库架构、移动应用，还是多个独立发布版本的发布面？
2. 本指南涵盖哪一对确切的版本？是否还必须支持跨多个版本升级（N-3 → N），还是只支持单次跨版本升级？
3. 谁负责升级：自行选择升级时机的开源用户、有通知期限要求的付费客户，还是收到强制要求的内部团队？
4. 破坏性变更列表是否已经确定，还是梳理变更本身也是这项工作的一部分？
5. 现有哪些自动化工具：codemod、兼容性/迁移构建、lint 规则、版本固定标头，还是都没有？
6. N-1 版本是否已针对这些变更发出弃用警告，还是 N 版本会直接带来破坏性变更？
7. 你们是否有关于已弃用 API 的使用情况遥测数据——会影响哪些人，影响多少人？
8. 本指南将发布在哪里？需要链接到哪些内容（变更日志、发行说明、支持渠道、状态页）？
9. 本指南必须在什么日期前发布？相对于发行日期而言呢？如果必须在发行当天发布，就无法安排中间的警告版本，只能一次性跨版本升级。
10. 这只是一次大版本升级，还是未来每次大版本升级都会沿用这种模式？如果会反复沿用，就应加入兼容性构建、RFC 审核关卡和稳定的单项变更锚点；如果只是一次性升级，则应将这三项全部删除。
11. 有多少工程工时可用于迁移工具？发行后由谁维护？如果没有指定负责人，就应在估算成本之前，从计划中删除兼容性构建和 codemod。

即使预计答案是否定的，也要问第 7 个问题。遥测数据能让“按影响范围排序”从猜测变成衡量；而缺少遥测数据这件事本身，也值得在指南计划中说明。

以下的路径方案和自动化方案排序是默认建议，而非硬性规定。请根据上述回答以及项目已有的资源，重新评估两者的排序：

• 如果已经安排了中间版本发布，那么分阶段路径就无需额外成本。
• 如果已有 codemod 集合，那么 codemod 就无需额外成本。

无论默认排序如何，这两种情况中的任何一种都会让对应方案跃居首位。

工作流

1. 冻结范围。 在工作笔记顶部写明版本对和范围清单，并将其视为固定内容。悄然扩展到涵盖三个版本对的指南，无法帮助任何人完成其中任何一次升级。

2. 盘点会出问题的内容。 从所有来源收集信息，而不只是查看变更日志：两个标签之间的公共 API 差异、变更日志中的 Removed/Changed 条目、N-1 发出的弃用警告、你自己的示例应用和内部使用方中的迁移提交，以及早期采用者提交的支持工单。将每项归类为移除、重命名或签名变更、行为或默认值变更、最低要求变更，或线路／格式变更。

3. 评估影响范围。 根据会遇到这些变更的读者数量对其排序，依次使用遥测数据、依赖仓库搜索结果，以及维护者的估算。此排序决定指南的顺序——绝不能按字母顺序，也不能按模块排列。

4. 选择迁移路径，并在指南开头说明。三种路径可供选择；第四种则是强制采用的。以下按每投入一小时工程时间所节省的读者时间排序：

   • 分阶段 - 先升级到 N-1 的最后一个次要版本，让弃用警告在每个受影响的调用点显现，然后再跳转。React v19 指南的措辞可作参考：先升级到 18.3，因为除了针对 v19 变更的警告外，它与 18.2 完全相同。代价是需要发布一个仅包含警告的过渡版本，但每位读者都能从自己的构建输出中获得专属问题清单。只要 N-1 仍可发布，就默认采用此路径。

   • 一次跳转 - 不设过渡阶段，对你而言几乎零成本，但读者会一次性面对全部破坏性变更。当整组变更可在一次工作时段内完成时，或 N-1 已冻结、无法再采用分阶段路径时，选择此路径。

   • 通过兼容构建逐步迁移 - 项目在只完成一半迁移的状态下运行，并在迁移中途发布到生产环境。这会带来持续的维护工作：在构建退役前，你都要维护双重行为路径、逐项功能标记和警告。

   • 顺序桥接 - 此路径不与其他三种路径一起排序，因为它由版本错配策略强制要求，而不是由你自行选择（Kubernetes 会维护最近的三个次要版本，并限制组件之间允许的版本错配）。如果适用此类策略，指南就应由 N→N+1 的连续跳转组成，其他三种路径均不可选；请在第一屏说明这一点。如果没有适用策略，就从选项中删掉此路径，不要将其作为选项提供。

   • 价值：通过兼容构建逐步迁移 > 分阶段 > 一次跳转

   • 工程投入加维护成本：通过兼容构建逐步迁移 > 分阶段 > 一次跳转

   • 效率：分阶段 > 一次跳转 > 通过兼容构建逐步迁移

   按此排序，兼容构建会被冷落——它最能减少读者的工作量，却也最需要你投入资源维护。当使用方是无法让迁移分支脱离不断变动的主分支独立推进的大型应用时，应将它提升为默认路径；这也是框架会构建兼容版本，而库不会这样做的原因。如果访谈中没有人为发布后的兼容构建负责，就删掉此选项，而不是把它列出来：无人维护的兼容构建会让所有采用它的项目都卡在半迁移状态。

5. 指出已知有问题的任何中间版本。 如果某个特定中间版本出现回归，请说明“跳过该版本，直接升级到 X”，并给出原因。否则，读者会遵循逐步升级规则，升级到你已知有问题的版本。

6. 先写明最低要求。 运行时和语言版本、对等依赖、数据库或基础设施的最低要求，以及构建工具要求。未达到最低要求的读者根本无法看到代码示例，因此把最低要求埋在第 9 步会白白浪费他们的时间。

7. 每项破坏性变更单独写一条，使用下方的六部分结构。按影响范围排序，方便读者及早停止，同时优先处理最可能影响他们的变更。

8. 用表格公布弃用时间线： 当前已弃用的内容、发出的警告级别，以及在哪个版本中移除。参见 ./references/deprecation-timeline-patterns.md。

9. 记录自动化及其适用范围。 给出确切命令、“运行全部内容”的操作方法，并明确说明它不涵盖哪些内容。如果仍需_构建_自动化工具，请按每投入一个工程工时为读者节省的时间排序：搜索模式和原样消息 > N-1 中的弃用警告 > lint 规则 > codemod > 兼容构建。默认做法：提供搜索模式和原样消息；你已经在每条变更的“受影响条件”行中写了这些内容，因此无需额外成本，还能帮助人工读者和编码 Agent。关于每个级别能带来什么、又会舍弃什么，请参见 ./references/automated-migration-tooling.md。

10. 添加清理部分。 升级成功后，告诉读者哪些内容现在已无用：已成为默认值的配置选项、变通用标志和依赖解析覆盖项、补丁，以及框架现已内置的包。没人会主动删除这些内容，而它们会成为下次升级时令人费解的故障来源。

11. 按错误文本编写故障排查部分。 读者可能在升级到一半时，把错误粘贴到搜索框中来查找答案；该部分应按他们粘贴的字符串匹配，而不是按你对该子系统的称呼匹配。

12. 根据下方的通过门槛，验证一次从零开始的升级。 修复问题并重新运行，直到通过。

13. 进行测量并记录。 定义采用率和问题解决率指标（见下方的 KPI）。如果环境支持持久记忆，请存储版本对、路径形态、弃用窗口和表面矩阵——下一个主版本会复用这四项。

条目结构

每项破坏性变更都使用相同的六个部分，顺序如下。六部分结构及其三句话的理由上限，是本技能自身的约定，并非已发布的模板；这个顺序符合读者的判断流程：是否与我有关 → 原因 → 具体表现 → 该输入什么。

1. 以动词开头并带有稳定锚点的标题——Removed:、Changed:、Renamed:、Deprecated:。锚点是永久标识符，因为 lint 规则、codemod 和支持回复会链接到单项变更，而不是整个页面。
2. 受影响条件行——检测信号。提供可在代码库中查找该内容的搜索模式，_并_提供读者会看到的确切警告或错误文本。如果读者无法判断某项变更是否适用于自己，就只能慢慢读完整段内容。
3. 变更内容及原因，最多三句话。说明原因才能让人配合；多出的第四句话只会让人失去耐心。
4. 变更前后的代码，分别标注为 // Before 和 // After，并且内容完整到可以直接粘贴。
5. 修复方法：codemod 命令，或编号的手动步骤。不要同时给出命令和含糊的“也可以手动更新”。
6. 应急方案：兼容标志、用于恢复旧行为的配置，或明确说明“没有”。说明没有应急方案也是一条信息；保持沉默则不是。

关于填写模板，以及两个反面示例和一个正面示例，请参见 ./references/breaking-change-entry-template.md。

谁来编写，以及确保文档必不可少的关卡

引入破坏性变更的工程师负责技术内容；技术写作者或倡导者负责清晰度、结构和发布。分工之下，指南很容易无人编写——每位负责人都以为对方在起草。在文档即代码项目中，迁移说明会与破坏性变更一同提交到同一个拉取请求，因此引入 API 破坏性变更的人自然会成为第一位起草者。

更有力的解决办法是设立一个治理关卡，要求代码合并前先准备好文档。有三个项目采用了这种做法：

• Ember 的 RFC 模板要求加入“How we teach this”一节；在 Recommended 阶段，必须先将该功能纳入指南，RFC 才能完成。
• Rust RFC 1636 沿用了 Ember 的关卡：在“How We Teach This”要求全部落实前，不得继续推进稳定化。
• Kubernetes KEP 要求包含 Upgrade / Downgrade Strategy 和 Version Skew Strategy 两节；未完成的 KEP 会在增强功能冻结时从该版本中移除。

如果项目有 RFC、KEP 或设计文档流程，应提议增加相应章节，而不是只提议编写指南——这样就能自动为未来的每次破坏性变更生成指南。不过，纸面上的关卡仍需有人落实：Rust 内部讨论帖承认，RFC 1636 中有关变更日志的部分实际上从未完成。

受众划分

对所有受众来说，条目内容都相同——检测信号、变更前后对比和回退选项都一样。变化的只有三点。

• 开源 / 自助服务读者可以自行选择是否升级，因此指南必须让他们觉得升级胜过什么也不做。
  • 开篇用两行说明升级能带来什么。
  • 按发布版本而非日期说明过渡期，并明确说明哪个版本仍会收到安全修复，以及支持持续到何时。
  • 失败模式：假设读者已经决定升级的指南。
• 商业 / 合同客户必须按截止日期升级。
  • 开篇说明截止日期和通知期限。
  • 在指南中写明支持和升级处理途径，不要只在公告邮件中提及。
  • 提供回滚流程，并说明由谁在供应商一侧执行切换，以及客户在此之前必须做什么。
  • 为托管版或企业部署提供专属回退选项，并设定独立的截止日期；发布前让支持和法务 / 通信团队审核草稿。
  • 失败模式：技术上无可挑剔，却没有日期和明确负责人，导致企业读者无法据此安排计划。
• 内部 / 强制要求的读者比起升级动机，更需要明确的职责归属。
  • 说明受影响服务分别由哪个团队负责、跟踪问题的编号，以及旧版本停止部署的冻结日期。
  • 编写这类指南前，重新阅读“变更规则”。

独立发布版本的界面

库升级是本地操作，由用户选择是否启用。托管 API 升级会改变他人正在运行的生产系统的行为，因此指南必须加入库迁移指南不需要的协调事项：

• 能够按请求固定版本的机制，以便在默认版本切换前测试新版本。
• 覆盖服务器 SDK、浏览器包、移动 SDK 和 webhook 负载的兼容性矩阵。
• 标识符或枚举变更对数据层的影响。
• 切换与回滚流程。

如果 API 的契约差异流水线已经列出每项破坏性变更及其来源和处理方式，请据此开始编写指南中的变更清单（samber/developer-platform-skills@api-changelog-automation）。

如果发布的多个软件包必须同步升级，请加入版本一致性检查：同一系列中的每个软件包都使用同一版本，任何配套库则使用其文档中注明的兼容版本。只升级一部分的软件包系列会产生一些看似由破坏性变更引起、实则无关的错误。

如果迁移的任何部分跨越你所控制的网络边界，请阅读 ./references/api-version-migration.md。

机器可读要求

假设执行本指南的不只有人类，还有编码 Agent。这样做毫无代价，也能让指南更易于人类使用。本节仅针对这一页；让整套文档都能被 Agent 使用，是 samber/developer-relations-skills@coding-agent-docs-optimization 的工作。

• 原样引用错误和警告字符串，包括标点。Agent 和搜索框都依赖字面匹配。
• 提供完整、可运行且包含导入语句的代码片段——绝不要给读者必须自行放置到正确位置的片段。
• 每组版本只保留一个规范 URL，并为每项变更设置稳定的锚点。指南每次发布都更换位置，会导致支持人员贴过的所有链接失效。
• 以可供机器检查的比较表达版本下限（Node >= 20.19），不要用文字描述（“较新的 Node 版本”）。
• 在指南中写明迁移路径。“了解背景请参阅发布博客文章”可以接受；“步骤请参阅博客文章”则会让以编程方式阅读的用户无所适从。
• 不要在正文中写入不断变化的补丁版本号。固定指南涵盖的版本组合，并让变更日志记录当前版本。

调用示例

从头起草。“我们下个月要发布 Node 客户端的 v3，包含 14 项破坏性变更，目前还没有 codemod。请编写迁移指南。”→ 运行访谈（在问题 1-5 后停止），然后产出：按变更类型分类的清单表、附带证据来源的影响范围排序、建议的路径结构，以及按文档库大纲编写的完整指南草稿。将缺少 codemod 标记为一项决策，而不是试图掩盖的缺口。

审核现有指南。“这是我们的 v2→v3 升级页面，支持团队一直收到相关工单。”→ 按六项达标阈值标准为页面评分，列出所有缺少检测信号或变更前/后区块的条目，指出是否存在排序问题，并提交按优先级排列的修复清单，其中包含前三项的改写文本。

弃用进行中。“我们在 2.4 中弃用了四个 API，打算在 3.0 中移除——现在应该发布什么？”→ 产出弃用时间线表，以及面向移除的页面（“3.0 中将移除什么”），暂不编写迁移指南；同时说明临时版本中每项需要的警告级别。

所有情况下，预期输出结构如下：

1. Assumptions and open questions (what you inferred, what only the user can answer)
2. Inventory table: change | type | blast radius | evidence
3. Recommended path shape, with the reason in one line
4. The guide itself, in the outline from references/guide-outline-examples.md
5. Verification plan: the cold-run project, who runs it, what gets measured
6. KPI list with where each number comes from

如果破坏性变更集合规模较大或存在争议，请先提交第 1-3 节供验证，再编写第 4 节。排序不当会导致十四个条目都得重写，一轮往返就能避免这一成本。

通过门槛

通过冷启动升级进行验证：选取一个使用 N 版本的真实项目（示例应用、内部使用方或社区项目），由未参与编写指南的人按照指南完成升级。以下六项全部满足后，指南才能发布。这六项是本指南自身的标准，并非行业标准；它们都是硬性要求，因为每项不达标对作者来说都不易察觉，却会给读者带来高昂成本。

1. 完整性。 标签到标签的差异中，每个已移除或行为发生变化的公共符号都必须有对应条目。将指南与 API 差异进行比对；不要把变更日志当作清单。Hyrum 定律意味着即使 API 差异也会漏项，因此还要补充支持团队已发现会导致故障的内容。
2. 可检测性。 每个条目都要提供搜索模式，以及准确的错误或警告文本。
3. 充分性。 升级过程中不得进行指南未说明的修改。任何未记录的修改都是缺陷，而不是读者的问题。
4. 自动化诚实性。 每个声称提供的代码迁移工具都必须在测试项目上运行过，并在指南中说明其留下的残留问题。之后，类型检查和测试套件都必须通过。
5. 路径有效性。 如果承诺支持多次跨版本升级，至少要将承诺范围内最早的版本完整走过这条升级路径。
6. 自包含性。 读者无需查看源码、变更日志或问题跟踪器，就能知道下一步该做什么。

在生态系统支持可执行文档的情况下，将指南中的命令接入 CI（Rust 的 cargo test --doc 和 mdbook test 是参考实现），这样代码片段一旦无法编译，构建就会失败，而不是悄然过时。测量冷启动升级所需的时间，并将其作为预期工作量公布；切勿声称未经测量的耗时。请参阅 ./references/validation-and-adoption-metrics.md。

当涉及面较广而无法保证完整性时，应按模块拆分指南，而不是删减条目，并以相同方式拆分验证工作。Google 的 Rosie 平台提供了工业界先例：它按职责边界拆分大型变更，使每个部分都能独立测试、评审和提交（Software Engineering at Google，第 22 章）。不完整的指南会让读者误以为它并非权威依据。

KPI

按接入成本从低到高排序，而不是按汇报顺序排序。

• 每千次升级中的工单数：引用升级错误的工单，以及产生工单最多的变更。免费：支持团队已经在收集这些数据。应重写该变更对应的条目。
• 弃用警告遥测数据：在移除版本发布前，趋势应接近零。接入已要求的分阶段路径只需一小时的数据汇总。如果距离移除还有一个月时数据仍然持平，那么移除日期不合理，或者指南没有触达用户。
• Codemod 运行率：与手动迁移进行比较，限于工具会报告该数据的情况——支持报告时免费，不支持时则无法获取。
• 指南行为：页面内搜索错误字符串的情况，以及跳转到支持渠道的情况，两者都表明条目缺失或难以找到。接入文档分析只需一小时。
• 采用曲线：在第 30、60、90 天，已升级到 N+1 的活跃安装或账户占比，并与上一个主要版本的曲线对比——这是唯一能说明迁移是否成功的指标，也是持续性工作，因为需要在 90 天内关联安装或账户遥测数据。即使有强有力的平台强制措施，长尾也很常见；应将最后约 15% 作为需要直接跟进的指定账户，而不是文档问题。参见 ./references/validation-and-adoption-metrics.md，了解本技能 15% 截止值所依据的已发布曲线。
• 落后者：截止日期后仍在使用 N 的指定账户或主要依赖方——这是支持和客户成功团队要跟进的名单，而不是一个百分比。

采用曲线和落后者名单的投入相同，应一并获取：两者由同一身份关联生成，曲线是汇总数据，名单则是其长尾，因此在完成该关联之前，两者都无从得来。Codemod 运行率和指南行为的投入相同，原因则不同——各自只需一小时来查看他人已在运行的系统，而且各自回答的都是关于某个工件的问题，而不是关于迁移的问题。

如果必须向客户或领导层说明移除日期的合理性，就应将采用曲线提升到首位，并在版本发布前启动关联工作：若发布后才开始，最初 90 天的数据就已经无法衡量。对于托管 API，samber/developer-platform-skills@integration-health-monitoring 可将落后者名单转化为按集成划分、带负责人信息的清单，并在截止日期前开展外联。

只有在曲线明显趋于平缓后，才开始严格强制执行（限时停用、强制移除、关闭企业版例外通道）。这类已发布的迁移通常需要数年而非数月才能达到这一阶段——曲线请参见上方的参考资料。

故障模式

症状	修复
指南只是换了标题的更新日志	将每一项改写为读者要采取的行动；删除所有对他们没有影响的内容
按模块或字母顺序排列更改	按影响范围排序；所有人都会遇到的更改放在最前面
只写了“相应更新你的用法”，没有代码	添加更改前后的代码块；如果写不出来，就说明还没有充分理解这项更改，不应发布
读者无法判断某项更改是否适用	添加适用情况说明，包含搜索模式和警告原文
弃用功能移除前从未在运行时发出警告	在移除前的过渡版本中提高警告级别；如果为时已晚，就如实说明，并延长对旧版本的支持
不支持跨越多个版本升级，却未作说明	说明支持的升级路径；为旧版本提供有序的升级路径，或引导读者逐个版本升级
每次发布都就地重写指南	每组版本组合保留一个规范页面，并确保页面持续在线且锚点稳定
企业读者没有可用于规划的日期	公布截止日期、通知期和回滚方案
指南的每个步骤都提及供应商工具	描述所需能力；将工具名称放在一条可单独更新的集成说明中
未经实际测量就发布工作量估算	实际执行一次全新升级并公布所需时间，否则就不要公布
将架构变更写成带代码片段的说明	改写为包含各步骤回滚方案的操作手册；参见指南类型参考
对不支持的路径提供部分支持	明确引导这些读者改走其他路径（“继续使用 2.x，原因如下”），不要让他们留在主流程中

参考资料

• 有关逐项变更的区块模板以及正反示例，请参阅 ./references/breaking-change-entry-template.md。
• 有关完整的页面骨架（库/SDK 和托管 API）以及反面大纲，请参阅 ./references/guide-outline-examples.md。
• 有关警告级别梯度、发布次数窗口和时间线表格格式，请参阅 ./references/deprecation-timeline-patterns.md。
• 有关 codemod 生态系统、兼容性构建和覆盖范围边界措辞，请参阅 ./references/automated-migration-tooling.md。
• 有关托管 API 的具体事项：固定版本、表面矩阵、webhook、切换和回滚，请参阅 ./references/api-version-migration.md。
• 有关库之外的指南类型：架构运行手册、云/平台、移动端和浏览器 API 迁移，请参阅 ./references/guide-types-beyond-libraries.md。
• 有关可执行文档 CI、冷启动演练、codemod 语料库测试和采用情况基准，请参阅 ./references/validation-and-adoption-metrics.md。
• 有关上述每项声明背后的已发布政策、数据和具名方法，请参阅 ./references/sources.md。
• samber/developer-relations-skills@developer-tutorial（当读者需要学习新版本的概念，而不只是迁移代码时）
• samber/developer-relations-skills@tech-press-relations（处理含有重大变更的主版本发布的媒体沟通）
• samber/developer-relations-skills@oss-release-policy（本指南采用的弃用窗口、支持结束日期和重大变更定义）
• samber/developer-relations-skills@developer-docs-structure-audit（确定指南在文档站点中的位置）
• samber/developer-relations-skills@docs-versioning-strategy（指南发布后，旧版本文档应继续保留、冻结还是归档）
• samber/developer-platform-skills@api-versioning-policy（选择版本方案、弃用窗口和终止服务时间线）