状态：本页的文档维护与采用流程于 2026-10-20 UTC 由代理依既有普通、可逆文档迭代授权采用为手册维护规则（见 3.2 节），属于可逆的流程整理，不改变已确认设计语义，适用范围是规范编辑、兼容审阅、采用与证据登记。它不代表已任命维护者、建立发布渠道、批准包版本或授权对外发布；实际角色、资源和发布条件必须在相应变更中落实，未落实则保持未指定／未发布。已确认与未决设计事项以决策与讨论记录为准。 更新：2026-10-20 所属章节：治理、交付与质量
本篇回答三个问题：怎样改变共同规则而不破坏既有使用，怎样明确一个版本实际提供什么，使用方怎样采用并证明迁移完成。先读第 3 节流程、第 5 节兼容判断和第 7 节采用记录；成熟度不是文档审查得分。
1. 何时提出共同能力
出现跨任务重复的交互问题、同一概念的表达分歧、已知可访问性障碍、无法稳定实现的规则或维护成本明显增加时，应提出问题。贡献不必从“新增组件”开始，也可以是修正术语、补齐失败状态、说明不适用范围、增加测试或删除重复规则。
评估候选能力时，先回答：
- 多处问题是否确实具有共同语义，而不仅是视觉相似？
- 现有组件或模式能否通过文档说明、组合或小范围修正解决？
- 领域规则是否误放入通用规范，例如某产品特有的估值公式或审批角色？
- 新能力会增加哪些变体、平台成本和长期承诺？
- 如果只有一个真实场景，是否先作为有边界的试验，而不宣称通用？
不设置“必须两个产品使用”之类未经确认的机械门槛。单一场景可能暴露基础障碍，但需要充分说明通用性与代价。
2. 提案最小内容
| 字段 | 需要写清的内容 |
|---|---|
| 问题与用户任务 | 谁在何种条件下做什么，现在哪里失败或费力 |
| 范围 | 涉及的规范标识、对象、平台、输入、状态、主题与语言 |
| 证据 | 观察、缺陷、支持请求、研究或已有实现，注明来源及限制 |
| 建议 | 行为、数据语义、可访问性、失败和恢复规则 |
| 替代方案 | 继续沿用、修正、组合或新增的取舍 |
| 兼容影响 | 已用行为、API、Token、设计资产、内容和用户习惯的变化 |
| 验收 | 可观察步骤、预期结果、测试环境和所需证据 |
| 维护 | 拟承担维护的角色、实施范围、迁移和复查条件 |
| 未决问题 | 不能由作者替团队决定的选择 |
提案采用实际证据，不把未经测试的效果写成收益事实。“预计减少重复步骤”与“测试中减少了步骤”应明确区分。
3. 审阅、批准与记录
共同语义由规范责任人审阅；平台行为和 API 由实现维护者审阅；业务影响由产品责任人审阅；涉及可访问性、隐私或安全的变更由对应责任人参与。角色可兼任，但审阅范围和最终决定者要明确。
决定记录包括问题、结论、适用范围、状态、理由、放弃的方案、证据、决定日期与后续行动。文案整理不能把“可试验”改写成“默认采用”，也不能把“方向已确认”扩大成所有数值与实现细则均已确认。
紧急修复可按预先授权的维护流程缩短讨论，但必须留下影响评估、实际改动和后续补充证据。尚无此流程时不假定任何贡献者有紧急发布权。
3.1 一次变更怎样从提出走到关闭
采用以下文档级工作流程。可逆编辑可按既有授权处理；跨权限、发布、费用或不可逆操作仍须取得对应授权，流程本身不创造权限。角色是需要承担的责任，不是假定已有团队成员。
| 步骤 | 所需输入 | 退出条件与记录 | 条件不满足时 |
|---|---|---|---|
| 定位 | 问题、稳定规则 ID、现行主节和实际影响 | 分清编辑、修复、新增或破坏性变化；确定唯一修改位置 | 先查清冲突，不在新附件复制另一份规则 |
| 提案 | 第 2 节内容、替代方案和范围 | 正常／失败路径与兼容影响可评审；需要决定的事项单列 | 保持提案，不把拟议默认写成已采用 |
| 审阅 | 相关领域审阅、语义回归与链接检查 | 记录实际参与者／角色、发现及处理；重大分歧有决定依据 | 审阅缺位或必要授权缺失则阻断对应合入或发布 |
| 合入规范 | 明确决定、变更内容及回归证据 | 更新唯一主档、导航和对应登记；保留旧版与差异 | 不因合并文本就升级实现成熟度 |
| 准备采用 | 使用方、目标环境、资源版本和缺口 | 填写第 7.1 节采用记录；明确试验还是实际产品采用 | 无实现时仅可做文档走查，不能声称接入完成 |
| 验证与关闭 | 实际结果、缺陷、例外及迁移证据 | 使用方确认限定任务可用；残余问题和支持边界可定位 | 未执行不关闭验收；只关闭有证据完成的部分 |
编辑澄清也要留可定位 diff，但不要求为每个错字新建产品决策。改变默认行为、词义、数值或支持范围必须进入兼容审阅，不能隐藏在“排版优化”中。紧急问题先明确风险和受影响范围，再依真实授权处理；不存在可用发布流程时，不假定可以跳过它。
3.2 当前采用决定及可撤回边界
统一消费模板、任务优先导航、变更流程和采用记录，由代理依据既有普通、可逆文档迭代授权采用。理由是让使用方找到唯一规则并辨认缺证，而不是新增设计风格或服务能力。撤回这些编辑流程时仍须保留历史证据与已确认语义；不得删除使用方既有记录。若未来真实维护组织与发布策略确定，应补齐责任、渠道与版本规则并说明替代关系，不追溯虚构采用当时已存在的维护者、发布日期或实现支持。
4. 成熟度与进入／退出条件
下表是实现能力成熟度，按能力和支持范围标注；规范成熟度、设计完整度和各实现版本不得混写成一个绿色状态。
| 实现能力成熟度 | 使用含义 | 最低进入条件 | 后续处理 |
|---|---|---|---|
| 草案 draft | 可讨论或在明确范围试验，契约可能变化 | 有用途、边界、负责人或待指定标记、基本状态与验收计划 | 补齐证据后可验证；不再需要则撤回并保留决定 |
| 已验证 validated | 在明确版本、环境和任务范围内具备支持证据 | 规则已获所需确认，相关实现和关键任务门禁有证据，限制已公开，维护责任明确 | 每次相关变更评估回归；新平台另行验证 |
| 已弃用 deprecated | 不建议新增采用，已有使用方按计划迁移 | 弃用理由、替代方案或无替代说明、影响方、迁移与结束条件明确 | 按公告计划结束支持或移除；保留历史索引 |
例如同一规则可分别记录“文档：已审查（附审查范围与证据）；设计：已采用（附决定）；实现能力：draft／未验证”。文档审查不授予实现 validated；设计采用不等于视觉或运行通过。资产发布稳定性另用规范、设计与实现映射的 release_status（Draft／Experimental／Stable），弃用／迁移也独立登记。
“试验发布”是发布渠道或试用范围，不必再与成熟度混成一套重复状态。弃用不等于已经移除；已验证也不意味着未来版本自动继承所有测试。
已验证能力发现严重缺陷时，应立即说明受影响范围、限制或暂停相关能力。可以缩小支持范围或转回草案，但不能删除旧证据以假装从未发布。
5. 版本与兼容性
采用独立版本记录：规范修订、设计资源版本、Token 版本、实现包版本和产品发布版本分别记录，通过映射连接，不强制使用同一个数字。当前未建立正式包版本与发布渠道；不为完成文档而虚构 v1.0。规范修订以真实提交／快照标识与日期定位，不能只写“最新”。若实现包采用 SemVer，必须先明确其公共契约，按主／次／修订号表达不兼容、兼容新增与兼容修复。0.y.z 的开发状态也不免除说明影响与迁移的责任。依据：语义化版本 2.0.0
YUDS 的兼容审阅应超出函数签名。下列情况可能构成破坏性变化：
- 同名状态或按钮改变业务含义，默认操作范围从当前页扩大到全部结果。
- 键盘模型、焦点返回、选中策略或提交时机改变，既有任务和自动化受影响。
- 缺失值、单位、数字精度、日期格式或排序规则改变，用户可能作出不同判断。
- Token 被删除、重命名或语义改变，主题和图表状态不再可区分。
- 支持的平台、辅助技术或关键任务被移除；可访问名称和角色变化破坏使用方式。
- 组件默认布局、尺寸或密度变化导致信息、点击区域或组合约束失效。
- 产品需要修改配置、数据或流程才能保持原来结果。
以下分类为提案时的分析起点，最终由实际影响决定：
| 变更类别 | 典型内容 | 发布说明要求 |
|---|---|---|
| 编辑澄清 | 修正错字、补充不改变规则的示例 | 说明编辑，不暗中改变规范 |
| 兼容修复 | 使实现恢复到已公布契约，且不破坏合理依赖 | 问题、影响范围、回归证据；仍检查用户行为影响 |
| 兼容新增 | 可选能力、未改变默认行为的新变体 | 用途、适用范围和新增测试 |
| 破坏性变更 | 既有可依赖的 API、语义、默认行为或支持范围改变 | 影响清单、迁移、验证和恢复限制；按适用版本策略发布 |
| 紧急安全或严重可用性修复 | 需要迅速限制风险的修正 | 实际限制、受影响版本、必要行动及后续兼容处理 |
“修复缺陷”并不自动等于修订号。如果修复会改变已依赖的行为，应明确兼容风险。截图没有变化也不等于无破坏性变更。
5.1 使用方如何决定是否升级
- 编辑澄清：核对无行为／数值改变后更新文档引用；不强迫无关实现改包。
- 兼容修复：核对实际受影响任务与版本，重跑缺陷路径及相邻正常路径；“修复”不能豁免兼容判断。
- 兼容新增：既有使用不必自动启用；启用前补该可选能力的采用、平台和失败路径证据。
- 破坏性变更：先完成影响清单与迁移方案，再决定升级窗口；无法满足时保留旧版限定支持或登记实际批准的例外，不悄悄扩大默认范围。
- 安全／严重可用性修复：先按真实责任和授权明确限制与必要行动；如必须停用，应明确可用替代与恢复条件，不能用普通升级说明掩盖风险。
任何升级都检查规范、Token、设计资源、实现包是否是相互匹配的版本组合。单独更新设计稿不证明运行行为更新；自动化测试通过也不替代需要的真实辅助技术和任务验收。影响判定有争议时保留较高风险分类直至审阅决定，不用改名降级。
6. 发布包的最低内容
每次发布应包括：
- 本次解决的问题与适用对象。
- 规范、设计、Token、实现的版本与对应关系。
- 新增、修复、变更、弃用和移除的分类说明。
- 实际支持平台及任务，不继承未经验证的组合。
- 测试结果、人工审阅、未执行项和已知缺陷。
- 破坏性变更及迁移入口；无迁移需求时说明依据。
- 负责人、发布日期、升级建议与恢复限制。
预发布、试验和稳定渠道如果存在，应有可辨认名称与适用约束，不把预发布包通过文档推荐成默认生产选择。发布不能修改既有版本的含义；修正历史说明时保留更正记录。
7. 迁移契约
迁移说明不是“更新到新版”一句话。至少应回答：
- 哪些实现版本、产品页面、主题和任务受影响，如何找到调用点。
- 旧行为与新行为分别是什么，为什么改变。
- Token、设计变体、API、事件和用户文案如何替换；需要人工判断的地方明确标出。
- 是否涉及数据结构、业务状态、后台任务或缓存；这些由对应产品及实现责任人负责。
- 升级前需保存什么，升级后怎样验证原有任务及异常路径。
- 哪些步骤可以自动化，工具会修改哪些文件；不能把不确定的业务选择自动批量改写。
- 回退能恢复代码、配置或显示中的哪些部分；是否存在已经写入的数据或外部副作用无法撤回。
有需要时可采用旧新能力并行、适配层或分批迁移，但应说明结束条件，避免永久维护两个含义不同的同名能力。迁移完成需由受影响使用方提供任务级证据，合并迁移脚本不等于迁移完成。
7.1 采用记录：从读到做到
采用记录是使用方的工作单，不是第二份组件契约。字段与资源关系沿用规范、设计与实现映射，本节说明填写时机与关闭条件。
| 项目 | 填写要求 |
|---|---|
| 采用对象与范围 | 任务、页面／组件稳定 ID、目标使用方、平台及明确排除范围；通用测试宿主可不关联产品 |
| 固定输入 | 实际规范修订、Token、设计资产和实现包版本；未提供的资源如实写未提供 |
| 覆盖级别 | 契约／有界子集／分类边界及实际能力清单；不能仅凭族名决定生产采用 |
| 能力前提 | 必须真实存在的权限、版本、任务核查、取消或补偿服务；不存在则明确收窄任务 |
| 差异与风险 | 与唯一主档的差异、已知缺陷、批准状态及例外入口；未批准不能写成已豁免 |
| 责任 | 实际维护、实现、验证与使用方角色；没有人承担时标未指定，阻断实际发布关闭 |
| 验证 | 正常路径、失败／恢复、焦点与辅助操作、内容增长、平台环境和实际结果 |
| 迁移／恢复 | 旧新行为、调用点、数据与外部副作用、回退限制；不适用须说明原因 |
| 完成与后续 | 已完成范围、未执行项、残余缺陷和重验触发条件，不用“全部完成”覆盖未知 |
示例，仅展示填写逻辑，不是已发生的接入
使用方拟在中性测试宿主中编辑记录 R-001 的备注；引用输入、表单校验与异步恢复唯一主档；实现包未提供、运行未执行，所以只能完成文档走查。若远程写入不能核查，示例就明确“结果未知且当前无法核查”，不能为了走通演示增加不存在的查询接口；待实现方补齐真实处置路径后再测试。即使全部文档问题已澄清，也不能把采用状态改成“已验证”。
关闭采用所需证据是任务结果，不是“资源已下载”“PR 已合并”或“设计稿已更新”。测试失败、目标平台变更、权限／提交／焦点契约变化、基础配对或密度变化，以及相关外部依赖升级，都触发受影响范围重验；不重新运行无关范围时应说明影响分析。
8. 弃用与移除
弃用公告明确能力、受影响版本、原因、替代路径、维护范围和预计结束条件。弃用窗口按使用方数量、任务风险和迁移代价决定，不在本稿承诺固定天数。
移除前应检查真实使用方、迁移记录、已知例外和平台影响。无法确认全部使用方时如实说明风险，不能据“搜索到零调用”直接宣称无人使用。历史文档保留版本标识与替代入口，避免旧链接悄然落到语义不同的新规则。
9. 例外机制
例外用于记录限定范围的暂时差异，不是免除责任的永久通行证。完整登记字段统一见规范、设计与实现映射第 9 节；本节规定其批准、期限和关闭原则。
以下原则应保持：
- 未知是否符合不写成例外已批准；审批中与已批准分开。
- 例外须有到期日期或可验证的退出条件，不能只写“后续处理”而无限延续。具体期限由责任方批准，不能凭空填写已同意日期。
- 到期重新评估，不能自动续期；整改完成后验证并关闭。
- 例外不覆盖法律、安全政策、隐私或合同义务；设计维护者不能替这些责任方豁免要求。
- 无可访问基本任务路径、越权或数据丢失等问题，应明确影响发布资格，不以一条普通例外悄悄放行。
登记和实现映射见规范、设计与实现映射。
10. 贡献者交付前检查
- 真实问题和证据清楚，未把产品特有规则误写为通用要求。
- 已区分明确确认、拟议、试验和实现验证。
- 状态、输入、权限、错误和恢复路径已写入契约。
- 兼容性涵盖行为、可访问性和内容，不只看 API 编译。
- 所需审阅人和最终责任人明确，缺位时如实标记。
- 测试证据可定位，未执行项没有被写成通过。
- 迁移、弃用、例外和恢复限制可被使用方理解。
- 规范主档、索引与实现映射同步更新，旧版本仍可追溯。
此清单作为文档贡献与采用检查工具使用，未对任何实际发布勾选通过；发布权与实际发布结论仍须单独记录。
11. 规范变化的评审收据
每一轮实质变化建立独立收据：基线提交、固定评分表版本与哈希、修改规则 ID 及主档、官方事实与读取日期、完整 diff、文档走查的输入／预期／实际发现、独立审阅者、严重度、修复与复验定位。评分按预先固定的检查点逐点提供证据；缺少条文、预期或定位即不得分，不以新增篇幅计分。
文档规范质量与已验证实现成熟度分开。规范达到 95／100 仍不等于产品发布就绪；高／中优先级问题未解决时不宣称该轮规范达标。真实环境或用户决定阻断时记录受影响部分、选项和建议，继续独立可做工作；不能把问题改名为“以后再说”来抬分。更改评分标准须另起版本，保留旧分数与理由，不能追溯降低门槛。
收据放索引证据附件，正文保留规则与稳定入口，避免每轮日志挤入日常阅读。知识库提交与产品发布分别审批和记录；获准推送文档不代表获准发布软件或取得字体许可、形成组件 API 或替代设计决定记录；D01/D02 采用依据另见现行主档。
相关：质量门禁见质量基线、门禁与验收证据。