修订时保留已接受的要求

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

设计审查 R1 已接受键盘操作和可见焦点要求，工程审查 R2 要调整加载方式。你需要更新当前计划，又不能让新版本只剩最新审查者的建议。教学记录把每项接受的要求与其来源版本相连。

具体做法

把可更新的实施计划与审查历史分开。建立已接受义务清单，记录来源、条件和验证；新修订保留仍有效义务，只把新增或替代决定放在 R2。真实冲突明确列出，用户后续改变要求时记录取代关系，不修改历史让它看起来从未存在。

反例

为工程审查重写计划，删除 R1 的键盘和焦点要求。只保留 R2 的加载建议，再把 R1 历史改成“没有接受要求”。

改进写法

修订上述当前计划，继续保留 R1 已接受的键盘操作与可见焦点及其验证条件。R2 仅记录新的加载改动和依据，不改写 R1 的来源或决定。若加载方案影响键盘要求，单列冲突和处理建议，确认有效变更后记录其取代关系；不能因重写或压缩把义务悄悄删掉。

为什么这样改

仅保留最新建议会丢失此前明确接受的承诺，也混淆是谁决定了什么。当前计划引用义务来源，历史记录保持原貌，后续接手者能核对仍须履行的条件和真正发生的变更。

如何验证

示意 R2 计划仍列键盘、焦点与新的加载方式，R1/R2 历史分别保留各自决定。若用户后来明确调整某项要求，新记录指出被替代内容和来源。

检查没有凭空把 R1 改成 None、没有丢验证条件，也没有把历史批准扩大成新的外部操作许可。

适用边界

义务可能被明确后续决定替代，历史不是永远有效的授权。不要把来源的自动决定、阶段标签或固定记录工具当本方法前提；重要的是保留真实来源、有效条件与修订关系。