给「提案改提案」装一本台账：EIP-2458 的 updates 与 updated-by 头字段

标准文档有个冷启动难题：一份规范被后来的规范修订、扩充或纠正时，读者怎么从旧文档找到新文档？EIP 仓库早期的答案不完整。对已定稿（Final）的提案，流程规定修订必须另立新号，用 replaces 与 superseded-by 两个头字段互相指认，旧号封存、新号接班，族谱清晰；可对仍处在评审流程中的活跃提案（Draft 到 Final 之间），更新直接改原文、记一个 updated 日期就完事，修订关系不留双向线索。2020 年 1 月 6 日提交的 EIP-2458 就是来补这段的：信息类（Informational）提案，作者 Edson Ayllon，建议为活跃提案增设 updates 与 updated-by 一对字段，让「我在改谁」与「谁在改我」像定稿提案那样可机读、可追溯。它的最终状态是 Withdrawn，但问题本身是文档治理的永恒母题，值得把它的方案拆开看。

字段的精确语义

提案规范部分的措辞相当克制。updated-by 挂在被修订的活跃提案上：一个活跃提案要更新时，正确姿势不是直接改原文了事，而是另开一份新 EIP 走标准评审流程；等那份新 EIP 定稿后，旧提案的 updated 日期栏添新条目时，须在 updated-by 里列出对应提案号。updates 挂在新提案上：凡声明 updates 某活跃提案的提案，隐含它也 requires 那份提案；多个引用用逗号分隔，示例写法就是 updates: 1 与 updated-by: 9999, 9998, 9997 两行 YAML。两个字段都只服务活跃状态的提案，定稿提案的修订继续走 replaces 与 superseded-by，语义不重叠。提案还论证了对齐性：既然是给已有头部语法加选项，格式沿用旧例即可，不引入新解析成本；作为信息标准，它没有向后兼容风险，也没有技术安全议题——原文甚至直说「不引入任何技术问题」，风险全在流程采纳上。

给「提案改提案」装一本台账：EIP-2458 的 updates 与 updated-by 头字段图 2 — 给「提案改提案」装一本台账：EIP-2458 的 updates 与 updated-by 头字段 · 图 2

它想换来的三样东西

把提案的动机段翻译成白话，它想买到三样东西。第一是曝光：一份修订活跃标准的提案，如果不挂 updates，外界很难发现它动的其实是一个正在评审的特性；挂上之后，新提案天然继承了被改提案的关注度。第二是通知：利益相关方看到「某份公开讨论中的提案正被另一份提案更新」，有义务在旧提案被改动前先在新提案里完成辩论——这相当于把「先发帖再改帖」写进规范。第三是模块化审计：修订不直接覆写原文，而是一段一段以独立提案存在，每段都有自己可追的评审记录；旧文本不会被悄悄改写，改动本身成为公开评审的对象。这套设计在代码世界叫 pull request 文化，在 RFC 世界叫 obsoletes 头，EIP-2458 想把它移植进提案仓库。

结局与现实做法

提案没有走完：状态 Withdrawn，两个字段最终未成仓库强制规范。现实演化走向了另一头：编辑流程把「改动留痕」外包给了 Git——评审期提案直接改原文、历史提交即台账，头部字段仅保留 replaces 与 superseded-by 用于定稿后的正式取代关系，requires 与 references 用于依赖与引用。回头看，EIP-2458 的方案没输在想法，输在它想给已有机制再加一层，而仓库选择了「版本控制系统承担历史、头部字段只记终态关系」的分工。今天的提案族谱依旧存在，只是承载介质从字段挪进了提交历史——这是文档治理里非常典型的一幕：理想的元数据方案常常败给已经顺手的基础设施。