前端大型项目 RFC 实践：从评审流转到版本归档，如何避免文档与代码脱节？

前端项目一旦做大，最让人头疼的不是写 RFC（Request for Comments），而是半年后新人入职，发现「方案里写了一套，代码里跑的是另一套」。

文档脱节的本质，是方案评审脱离了代码的生命周期。写文档出身的我，目前在团队里推行了这样 3 步流转：

1. 载体下沉：RFC 不存飞书或语雀，直接用 Markdown 放在项目根目录的 /rfcs 文件夹下。
2. 流程绑定：RFC 评审直接提 Pull Request，大家在 Diff 上评论。方案通过才合入 main 分支；如果开发中架构有变动，PR 必须同时包含「代码修改」和「RFC 补丁」，否则不予合并。
3. 状态标记：文档头部标明生命周期，比如 [Draft] -> [Accepted] -> [Implemented] -> [Deprecated]。上线后归档为静态记录，日常维护则转交给代码注释和 TS 类型。

但实际执行中还是有痛点：业务排期一紧，大家往往「先上线，文档下周补」，最后下周复下周，RFC 依然有失效的风险。

想请教各位前端负责人和架构师： 大家团队目前是用什么机制防脱节的？是有成熟的 CI 检查或工具链约束，还是索性「RFC 只管立项，事后脱节就随它去，靠自动生成的代码文档活着」？欢迎分享你们的实践。