梧桐小区新搬来的业主小柯发现，小区里没有宠物活动区。他兴冲冲在业主群提议“3号楼旁空地建个宠物乐园”，以为大家点个赞就能动工，结果业委会刘主任微微一笑：“想法很好，但不能说建就建。你得先写一份《建设方案书》，说明为什么建、怎么建、预算多少、会不会扰民，贴到公示栏让全小区业主都来提意见，最后业主大会表决通过，才能施工。”小柯觉得这流程太麻烦，可当他真正走完一遍后才发现——正是这看似繁琐的“方案书”机制，让他的冲动想法变成了一座人人都满意的乐园。 这套机制在开源世界里，就叫 RFC（Request for Comments，请求评论）。PyTorch 这样的顶级开源项目，任何重大功能改动都不能直接改代码，而是要先写一份 RFC 提案，放进专门的仓库里，邀请全球开发者一起评议、修订、表决，通过后才进入开发。这份“建设方案书”背后，藏着一整套关于社区协作、技术决策和工程智慧的学问。

岗位关联

理解 RFC 机制，是 AI 从业者参与开源项目贡献的必修课：它决定了你的技术想法能否被社区采纳，也决定了你能否从“改代码的人”成长为“定义技术方向的人”。

目录
  1. 可视化演示
  2. RFC基本概念：项目里的“建设方案书”
  3. 提案生命周期：从想法到落地的六步循环
  4. RFC文档结构：好方案的黄金骨架
  5. 评审与决策：社区共识的达成之道
  6. PyTorch实践：真实世界里的RFC成败录
  7. 参与贡献指南：从读者到提案者
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示RFC提案撰写、社区评审与实施落地三阶段流程，对比RFC与普通PR的适用场景，理解PyTorch重大变更的标准化决策机制。

本节配有交互动效（进入视口后自动加载，约 3KB）。

提案流程 撰写/评审/实施三阶段 标准化决策 起源于IETF标准，被PyTorch等大型项目采用。

RFC基本概念：项目里的“建设方案书”

小柯觉得写方案书多此一举，刘主任反问他：“如果不用公示，你直接建个水泥地游乐场，养宠物的邻居很高兴，但带孩子的妈妈们会怎么想？没有方案书，你的‘好心’就可能变成别人的‘添堵’。”小柯恍然大悟：方案书不是审批的绊脚石，而是让一个想法接受整个社区检验的桥梁。

在 PyTorch 社区，RFC 就是这样的桥梁。RFC 全称 Request for Comments（请求评论），它最早诞生于 1969 年，当时 ARPA 网络（互联网前身）的研究者为了制定网络协议，把想法写成编号备忘录，寄给同行请求评论——第一份文档就直接命名为“Request for Comments“。从那时起，RFC 就成了”重大技术决策先讨论、后实施”的开源文化基因。

如今 PyTorch 专门设立了 pytorch/rfcs 仓库，任何设计影响面较大的功能——新 API、新编译流程、内存格式调整——都要求先提交 RFC 提案，而不是直接提代码 PR。RFC 和普通 issue 的本质区别在于：issue 是零散的想法或 bug 报告，RFC 是一份经过严谨组织的完整设计蓝图。

小柯终于明白，方案书贴在公示栏上的那一刻，他的个人想法就变成了社区公共财富。RFC 的核心价值，正是让所有潜在受影响者都有机会发声，让方案在碰撞摩擦中越变越扎实——这比一个完美却孤独的创意有价值得多。

V=n(n−1)2\displaystyle V = \frac{n(n-1)}{2}
这是网络价值公式，意思是社区讨论的价值与参与人数的平方成正比——就像业主群里 5 个人讨论只有 10 种对话组合，50 个人参与就有 1225 种观点碰撞的可能。RFC 之所以要求公开评议，正是因为它能放大集体智慧。
  1. 人数取值$n$ 表示参与讨论的总人数，人数越多，观点组合越丰富
    n∈{1,2,3,… }n \in \{1, 2, 3, \dots\}
  2. 两两配对$n(n-1)$ 表示任选两人构成一次对话的所有可能数量，这代表观点互相碰撞的机会
    n(n−1)n(n-1)
  3. 去除重复除以 $2$ 是因为 A 与 B 的讨论和 B 与 A 的讨论是同一件事，要去重
    n(n−1)2\frac{n(n-1)}{2}

提案生命周期：从想法到落地的六步循环

小柯开始走流程。他先在业主群发了“宠物乐园草案”请大家聊聊需求；随后把草稿完善成正式的《建设方案书》；刘主任帮他把方案书扫描贴到公告栏；一周后他在业主大会上汇报并接受质询；会后他根据意见修改方案，又公示了一轮；最后业委会表决通过，工程队进场。这六步像一条流水线，把冲动变成了工程。

PyTorch 的 RFC 生命周期几乎一模一样：先在 issue 或讨论区抛出设想、收集初步反馈；再按官方模板用 Markdown 撰写 RFC，通过 Pull Request（PR，拉取请求）提交到 pytorch/rfcs 仓库；社区成员在 PR 页面留下评论，作者逐条回应并更新文档；当讨论逐渐收敛，维护者认可设计后，RFC 被 approve（批准）并合并；最后才进入实施阶段，按方案拆分任务逐步写代码。整个过程多轮循环，少有提案一次性通过。

为什么不能省掉中间几步？因为每个阶段都在消除一种不确定性：孵化阶段消除“需求不真实”，撰写阶段消除“思路不清晰”，公示阶段消除“视野太狭窄”，评审阶段消除“设计有漏洞”，修订阶段消除“反馈没吸收”。五层过滤之后，留下的设计自然可靠。

小柯后来感慨，宠物乐园看似绕了远路，却让他避开了“雨天泥泞”“夜间狗叫扰民”这些完全没想过的问题。RFC 的生命周期不是官僚程序，而是一场让粗糙想法提纯成可靠设计的精炼之旅——每一轮循环，都在为未来的用户排掉一个雷。

Mt=1−UtTt\displaystyle M_t = 1 - \frac{U_t}{T_t}
这是提案成熟度公式：$U_t$ 是第 $t$ 轮评审后仍未解决的问题数，$T_t$ 是本届被提出的问题总数。未解决问题占比越低，成熟度越接近 1——就像方案书修改到没人再提新问题，就可以进入表决了。
  1. 问题统计$U_t$ 指经过第 $t$ 轮修订后还没找到答案的问题，$T_t$ 指本论题的总问题数
    Ut≤TtU_t \leq T_t
  2. 未解决占比$\frac{U_t}{T_t}$ 衡量当前“遗留问题”的密度，比值越接近 0 说明越接近收尾
    UtTt∈[0,1]\frac{U_t}{T_t} \in [0, 1]
  3. 成熟度镜像用 $1$ 减去这个比值，让“遗留越少”对应“成熟越高”，方便直观判断
    Mt=1−UtTtM_t = 1 - \frac{U_t}{T_t}

RFC文档结构：好方案的黄金骨架

刘主任递给小柯一份《梧桐小区建设提案模板》：封面、背景说明、建设方案、备选方案、风险与预算。小柯嫌模板死板，刘主任只说了一句：“模板是让读者不迷路——每个人拿到方案书，都知道去哪一页找什么信息。”

PyTorch 的 RFC 模板同样严格，一份标准提案通常包含：Summary（摘要）、Motivation（动机）、Detailed Design（详细设计）、Alternatives（备选方案）、Backward Compatibility（向后兼容性）、Testing Plan（测试计划）和 Documentation（文档计划）。其中“动机”回答为什么做，“设计”回答怎么做，“备选”证明你认真比较过其他路径，“兼容性”说明如何不砸老用户的饭碗。每一块都在降低读者的认知负担。

尤其“备选方案”一节，最能体现一个作者的功力。小柯写方案时，刘主任要求他必须写“室内宠物角”和“移动围栏”两个备选，并说明为什么不如“空地建造”。小柯被迫做了详细调研，最后有理有据地捍卫了自己的选择——好的模板不是限制创意，而是逼你把模糊的直觉变成可辩护的判断。

小柯按模板填完方案书，意外发现自己对项目的理解深了一层。模板的魔力就在于此：它把“我有个想法”这种混沌状态，强制转化成“背景—方案—备选—风险”的清晰脉络，让评审者把精力花在刀刃上，而不是费劲地猜你想干什么。

H=−∑i=1npilog⁡2pi\displaystyle H = -\sum_{i=1}^{n} p_i \log_2 p_i
信息熵公式。一份杂乱无章的提案就像一团乱麻，读者要花大量精力猜测重点；而套用模板的提案结构清晰，读者能直接把注意力放在真正需要判断的设计选择上——这就是结构化在降低认知上的“熵”。
  1. 状态概率$p_i$ 表示信息中第 $i$ 种状态出现的概率，可能状态越分散，不确定性越大
    ∑i=1npi=1\sum_{i=1}^{n} p_i = 1
  2. 信息度量$\log_2 p_i$ 衡量一个状态携带的信息量，概率越低的状态，信息量越大
    log⁡2pi\log_2 p_i
  3. 平均熵值对所有状态加权求和并取负号，得到整个信息的平均不确定度
    H=−∑i=1npilog⁡2piH = -\sum_{i=1}^{n} p_i \log_2 p_i

评审与决策：社区共识的达成之道

业主大会上，养宠物的年轻人强烈支持，带婴儿的妈妈担心安全，跳广场舞的阿姨怕场地被占。小柯没有辩解，而是一一记录，会后在方案里加了“分时段开放、加装安全围栏、保留晨练区域”三条设计。他第一次理解：评审不是要消灭反对意见，而是让方案吸收不同立场的养分。

GitHub 上的 RFC 评审也有类似的机制。社区成员可以在 PR 页面表达 Approve（批准）、Request Changes（请求修改） 或 Comment（一般评论）；作者需要逐条回应——同意的直接修改，不同意的给出技术理由。整个评审往往持续多轮，第一轮收集大方向异议，第二轮聚焦细节，第三轮只剩下措辞微调。当讨论从“热闹”走向“收敛”，负责该模块的核心维护者（maintainer）会综合各方意见，做出最终裁决。

值得强调的是，共识不等于人人满意。一个健康通过的 RFC，通常不是所有人都说“好”，而是所有实质性质疑都得到了认真回应。如果你能证明每个反对理由要么被解决、要么被合理解释，讨论就会自然收敛——这正是评审的终极目标。

业主大会最后投票时，当初反对的妈妈和阿姨都投了赞成票——因为她们的意见被认真吸收进了方案。小柯终于领悟：RFC 的评审不是一道“过或不过”的判断题，而是一场让利益相关者共同参与设计的共创过程。当反对者的合理诉求都被安放，共识便悄然形成。

D=S−ON\displaystyle D = \frac{S - O}{N}
决策支持度公式：$S$ 是支持评论数，$O$ 是反对评论数，$N$ 是有效评论总数。当 $D$ 趋近正值且没有遗留重大异议时，方案就具备了通过条件——就像业主大会上反对声越来越小，方案自然水到渠成。
  1. 正负抵消用支持数 $S$ 减去反对数 $O$，得到净支持量，反映方向上的倾斜
    S−OS - O
  2. 总量归一除以有效评论总数 $N$，消除“参与人数多寡”的干扰，只看力量对比
    S−ON\frac{S - O}{N}
  3. 判读范围$D$ 落在 $[-1, 1]$ 区间，越接近 $1$ 支持度越高，越接近 $-1$ 反对越强烈
    D∈[−1,1]D \in [-1, 1]

PyTorch实践：真实世界里的RFC成败录

春晖公园去年也走过一次 RFC 流程：树池选型被植物爱好者拦下，换成了透水树池，现在雨季从不积水。而邻区的滨江公园，方案书只写了“种树”，没有生态和排水分析，施工到一半被叫停改造，白白浪费了预算。小柯把这两个案例都抄进了笔记本。

PyTorch 历史上同样积累了大量经典案例。TorchScript 的 RFC 详细论证了类型系统的取舍，成为后来静态图方案的重要参考；Distributed RPC 的提案经过多轮评审，大幅完善了容错和超时机制；FX（函数式变换） 的 RFC 在“渐进式迁移”上做到极致，成为社区广为采纳的典范。反过来看那些被拒绝或大幅返工的提案，高频原因惊人地一致：范围过大（想一口气改上百个 API）、缺少迁移路径（老用户怎么办？）、维护成本过高（未来每个版本都要为它买单）、动机不充分（到底解决了谁的真实痛点？）。

写一份好的 RFC，就像给小区写方案：要多问“谁会受影响”“最坏情况是什么”“凭什么选这个方案”。PyTorch 官方同时提供了完整的 RFC 模板仓库和大量历史提案供参考——模仿经典是最快的入门路径。

小柯发现一个规律：凡是顺利落地的设施，方案书一定经历了充分的社区评议；凡是半途而废的工程，十有八九在提案阶段就在“拍脑袋”。PyTorch 社区也一样——一份 RFC 能否通过，表面看是运气，实际上看的是作者对社区规则的尊重程度。

P=c+1n+2\displaystyle P = \frac{c + 1}{n + 2}
拉普拉斯平滑估计公式。$c$ 是通过的 RFC 数量，$n$ 是提案总数。它估计“一份新提案被通过的经验概率”——如果你观察到 5 个提案里通过 3 个，估计值约 0.57，比直接算 0.6 更保守，避免在样本不足时过度乐观。
  1. 通过计数$c$ 是过去通过评审的 RFC 数，代表社区认可度
    c∈{0,1,2,… }c \in \{0, 1, 2, \dots\}
  2. 总量计数$n$ 是提交的提案总数，包含通过和未被采纳的
    n≥cn \geq c
  3. 平滑修正分子分母各加一个较小常数（$1$ 和 $2$），防止样本太少时概率估算为 $0$ 或 $1$
    P=c+1n+2P = \frac{c + 1}{n + 2}

参与贡献指南：从读者到提案者

三个月后，小柯已经成了业委会的义务顾问：他知道何时发起投票，如何浓缩冗长的讨论，怎样邀请合适的人参与评审。当刘主任问他愿不愿意写垃圾分类站的方案时，小柯笑着回答：“我试试。”

从一个 AI 从业者的视角，参与 PyTorch RFC 贡献有一条清晰的进阶路径：第一，阅读历史 RFC，观察优秀提案如何组织论证；第二，选择你真正熟悉的痛点，在 issue 中先确认这不是重复提案；第三，保持小而美，尽量把改动范围压缩到可管理的大小——一个 300 行的提案比 3000 行的提案更容易被认真读完；第四，把评论当免费咨询，及时友善地回应每一条反馈；第五，RFC 获批后，先提交拆分的实施任务，让每个 PR 都小而可审查。

沟通也有讲究：对建设性意见说“你说得对，我已修改”；对不采纳的意见说“感谢建议，考虑到 XX，我选择保留原方案”——后者同样重要。维护者和贡献者一样都是人，真诚、透明、有依据的沟通，比任何技术本身都更能赢得信任。

小柯的垃圾分类站方案出乎意料地一次性通过，因为他已经懂得在“充分打磨”和“及时收敛”之间找到平衡。第一份提案最难的不是写文档，而是克服“怕被批评”的心理。记住：RFC 就是一场免费的集体头脑风暴，每个评论者都是你的方案质检员。

Q=Qmax⁡(1−e−kr)\displaystyle Q = Q_{\max}(1 - e^{-k r})
收益递减公式：$Q$ 是提案质量，$Q_{\max}$ 是理论上限，$r$ 是修订轮次，$k$ 是每轮改进的效率。它说明修改带来的质量提升是“先快后慢”的——前几轮改动能大幅提升质量，十轮以后基本趋于平稳，这时就该收敛而不是无限打磨。
  1. 质量上限$Q_{\max}$ 是方案能达到的最高质量水平，由问题本身的复杂度决定
    0<Q≤Qmax⁡0 < Q \leq Q_{\max}
  2. 指数衰减$e^{-k r}$ 表示“未实现的质量空间”，修订轮次越多，剩余空间越小
    e−kr→0 (r→∞)e^{-k r} \to 0 \ (r \to \infty)
  3. 逼近上限$1 - e^{-k r}$ 让质量从初始值逐渐逼近上限，一轮修改的效率递减
    Q=Qmax⁡(1−e−kr)Q = Q_{\max}(1 - e^{-k r})

AI 应用场景

企业内部重大架构变更评审

阶段：需求分析与技术设计

解决的问题：AI平台的底层架构改动风险极高，直接实施可能影响所有业务线。传统做法是技术负责人拍板，但容易忽略一线使用者的真实痛点；引入 RFC 机制后，任何重大变更（比如更换特征存储、修改模型服务框架）都先输出设计文档，在全团队范围评审，用集体智慧提前暴露风险。

具体案例：某公司 ML 平台组计划引入新的特征存储层。团队负责人写了一份两页的 RFC，涵盖动机、新旧对比、迁移步骤和数据校验方案，发到内部协作群公示三天。算法工程师们提出了 11 条意见，其中“特征时效性不满足实时链路”一条直接避免了上线事故。

开源项目公共 API 设计

阶段：技术方案设计

解决的问题：向 PyTorch 等开源项目贡献新算子或新 API 时，直接提代码 PR 往往被要求先进行设计讨论。传统的“先写代码再被 review”容易造成大量返工；先提 RFC 则能在写任何代码之前，让全社区帮你校准 API 签名、语义边界和兼容性。

具体案例：一位贡献者想为 PyTorch 增加“稀疏注意力 API”。他先在 issue 里预热，再按模板提交 RFC，社区围绕“是否支持自定义掩码”“梯度如何传播”展开了四轮讨论。维护者要求补充与现有 scaled_dot_product_attention 的对比后批准了提案，后续实现几乎一次通过。

Python 演示

python48 行
"""RFC 提案评审模拟器: 计算支持度、成熟度并给出评审结论"""  class RfcProposal:    def __init__(self, title, author):        self.title = title        self.author = author        self.comments = []  # (kind, text)     def add_comment(self, kind, text):        self.comments.append((kind, text))     def support_score(self):        pro = sum(1 for k, _ in self.comments if k == "pro")        con = sum(1 for k, _ in self.comments if k == "con")        total = len(self.comments)        if total == 0:            return 0.0        return (pro - con) / total     def maturity(self, unresolved, total):        if total == 0:            return 1.0        return 1.0 - unresolved / total     def is_passed(self, threshold=0.3):        return self.support_score() >= threshold and self.maturity(1, 4) > 0.75  def main():    rfc = RfcProposal("新增长序列并行API", "小柯")    rfc.add_comment("pro", "解决超长序列训练显存瓶颈")    rfc.add_comment("question", "是否需要异步调度支持")    rfc.add_comment("con", "与现有分布式接口重复")    rfc.add_comment("pro", "设计与其他框架对齐")     print("提案标题: " + rfc.title)    print("提案作者: " + rfc.author)    print("支持度: {:.2f}".format(rfc.support_score()))    print("成熟度: {:.2f}".format(rfc.maturity(1, 4)))    if rfc.is_passed():        print("评审结论: 通过")    else:        print("评审结论: 建议继续修订")  if __name__ == "__main__":    main()
目的：模拟一份 RFC 提案从提交到评审的过程，用支持度公式 D=(S-O)/N 和成熟度公式 M=1-U/T 综合判断提案是否通过。
  1. rfc.add_comment("pro", "解决超长序列训练显存瓶颈")为提案添加一条支持评论，kind 可以是 pro（支持）或 con（反对）
  2. pro = sum(1 for k, _ in self.comments if k == "pro")用生成器统计所有支持评论的数量
  3. return (pro - con) / total套用支持度公式 D=(S-O)/N，得到 [-1, 1] 的分数
  4. return 1.0 - unresolved / total计算成熟度：未解决问题占比越低，成熟度越接近 1
  5. rfc.is_passed()综合判断：支持度达标且成熟度够高，才返回通过

常见误区

误区“RFC 不就是写一篇 Markdown 文档，开个 PR 等别人点赞吗？写完提交就行，剩下的交给维护者。”很多初学者把 RFC 当成一次性的作业提交。

正解RFC 的完整名称是 Request for Comments，核心在“请求评论”而非“提交文档”。文档只是起点，真正的工作是从提交后开始的：逐条回应评论、反复修订设计、推动讨论收敛。就像小柯的方案书，贴出来才刚开始——业主大会上的质询才是重头戏。没有充分互动的 RFC，只是一篇没人看的博客。

为何常见：初学者习惯把开源贡献等同于“写代码提 PR”，自然用“交作业”的思维理解 RFC，忽略了它本质是一个协作过程。

误区“RFC 被 approve 了，说明我的功能马上就能合并发布，下一步就是庆祝。”有人把设计批准误解为实现完成。

正解RFC 获批只代表“方案可行”，距离功能落地还有漫长的实施阶段。PyTorch 的实践是：RFC 合并后，作者要按方案拆分成多个小 PR，逐个走代码评审、测试、文档流程。就像小柯的方案书表决通过后，工程队还要画施工图、采购材料、分阶段施工。设计通过是“图纸盖章”，不是“入住新居”。

为何常见：人们容易把“决策完成”等同于“事情完成”，因为设计阶段的高强度讨论制造了一种“已经做完了”的错觉。

误区“评论区吵成一锅粥，这条 RFC 肯定没戏了，干脆撤回吧。”反对声让很多新手打退堂鼓。

正解激烈的讨论恰恰说明提案触动了真实问题，是好事。业主大会上妈妈和阿姨们吵得越凶，小柯越是认真记录，最终方案反而更完善。评审最怕的不是反对，而是无人问津。只要反对意见被逐一解答、讨论走向收敛，反对声大也能通过；反之，只有点赞没有质疑的提案，反而可能藏着没人发现的隐患。

为何常见：人们习惯把批评等同于否定，但开源评审的批评是设计养料——社区愿意花时间喷你，说明它在乎你做的功能。

误区“我得把设计做到天衣无缝才能发出去，否则会被社区笑话。”部分新人反复修改草稿迟迟不敢提交。

正解RFC 刻意设计成“先发初稿、持续迭代”的机制，一开始提交的往往是 60 分版本，靠社区反馈逐步修到 90 分。收益递减公式说明前几轮改动的提升最大，拖着不发等于放弃了最有效的改进路径。小柯的第一版方案连排水问题都没提，但不妨碍它最终通过。在开源世界，“快速发出、持续打磨”远胜“憋大招”。

为何常见：应试教育留下的“准备好了再交卷”心态被带入开源协作，而 RFC 恰恰是反过来的——它是协作草稿，不是期末答卷。

面试题

Q1. RFC 的全称是什么？

单选题 · easy

  • A.Request for Comments← 正确答案
  • B.Request for Code Review
  • C.Review for Contribution
  • D.Request for Community

答案：A。RFC 全称 Request for Comments，直译是“请求评论”。它强调先征求社区意见再动手实现，而不是请求代码评审（B）、请求贡献（C）或请求社区（D）。就像小柯先贴方案书征求业主意见，而不是直接找施工队开工。

Q2. RFC 机制最早起源于哪个领域？

单选题 · easy

  • A.互联网协议制定← 正确答案
  • B.操作系统内核设计
  • C.数据库事务处理规范
  • D.编程语言编译器优化

答案：A。RFC 起源于 1969 年 ARPA 网络（互联网前身）的协议制定过程，研究者用编号备忘录的形式分发技术方案并请求同行评议。操作系统（B）、数据库（C）、编译器（D）当时还未形成这种公开评议机制，互联网协议是 RFC 的诞生地。

Q3. PyTorch 的 RFC 提案文档主要存放在哪里？

单选题 · easy

  • A.独立的 rfcs 仓库← 正确答案
  • B.主仓库 issues 列表
  • C.官方文档的子目录
  • D.开发者个人博客里

答案：A。PyTorch 专门设立了独立的 pytorch/rfcs 仓库存放提案文档，方便集中检索和长期回溯。主仓库 issues 用于 bug 和普通讨论，官方文档面向用户而非设计评审，个人博客更不是官方渠道。这样集中管理就像把方案书统一贴在公告栏，而不是散落在各个业主的聊天记录里。

Q4. RFC 与直接提代码 PR 的核心区别是什么？

单选题 · mid

  • A.先定方案再写实现← 正确答案
  • B.不需要写任何代码
  • C.只面向核心成员开放
  • D.无需社区参与讨论

答案：A。RFC 是“先设计后编码”：先用文档把方案讲清楚，社区认可后再进入实现。虽然 RFC 本身不写功能代码，但后续实施仍需要 PR 写代码（B 错）；RFC 面向所有贡献者而非仅核心成员（C 错）；社区讨论恰恰是 RFC 最核心的环节（D 错）。就像先审批图纸再盖楼，而不是边盖边改。

Q5. 以下哪一项不属于 PyTorch RFC 模板的常见模块？

单选题 · mid

  • A.摘要与动机说明
  • B.详细设计与实现
  • C.资金预算与排期← 正确答案
  • D.备选方案与兼容性

答案：C。RFC 模板关注技术设计：摘要动机（A）、详细设计（B）、备选方案、向后兼容性（D）都是标配，但不包含资金预算和排期——开源社区靠志愿者贡献，不涉及项目经费审批。把商业项目的“预算”概念套到开源 RFC 上，就像给小区方案书加一页“利润预测”一样格格不入。

Q6. 在 RFC 评审中，核心维护者的职责包括哪些？

多选题 · mid

  • A.裁决设计是否可合并← 正确答案
  • B.综合社区反馈意见← 正确答案
  • C.替作者重写全部文档
  • D.推进讨论收敛并做结论← 正确答案

答案：ABD。维护者的角色是“主持人+裁决者”：综合各方反馈（B）、推动讨论收敛（D）、最终决定是否合并（A）。但他们不会替作者重写文档（C），作者对提案负责是基本原则。就像业委会组织业主大会、汇总意见、宣布表决结果，但不会替小柯重新写方案书。

Q7. 一份 RFC 被拒绝的常见原因有哪些？

多选题 · mid

  • A.方案范围过于庞大← 正确答案
  • B.缺少迁移兼容方案← 正确答案
  • C.未考虑后续维护成本← 正确答案
  • D.文档结构完整规范

答案：ABC。范围过大（A）、缺少迁移路径（B）、维护成本过高（C）是 PyTorch RFC 被拒的高频原因，因为它们直接威胁社区的可持续发展。而文档结构完整规范（D）是加分项，不可能导致拒绝。就像一张方案书如果资金预算和排水设计都是空白，业主大会一定会否决——哪怕封面做得再漂亮。

Q8. 成熟度指标 M = 1 - U/T 反映的是什么？

单选题 · hard

  • A.未解决议题占比低则成熟← 正确答案
  • B.评论数量越多则越成熟
  • C.文档内容越长则越成熟
  • D.支持人数越多则越成熟

答案：A。M = 1 - U/T 中 U 是未解决议题数，T 是议题总数，M 越高表示遗留问题越少、讨论越收敛。评论数量（B）、文档长度（C）、支持人数（D）都不是这个公式的变量。就像方案书不是签名越多越成熟，而是没有解决的问题越少越成熟——问题清零才能进入表决。

Q9. 作为 RFC 提交者，恰当回应社区评论的方式有哪些？

多选题 · hard

  • A.逐条回复并说明取舍← 正确答案
  • B.及时更新文档版本← 正确答案
  • C.忽略那些重复提出的意见
  • D.保留异议的合理理由← 正确答案

答案：ABD。对每条评论给出回应并说明取舍（A）、按反馈及时更新文档（B）、对不采纳的意见给出合理解释（D），都是专业做法。即使是重复意见（C），也应合并回复表达“此前已讨论过”，而不是无视——因为每个提问者都值得被尊重。就像小柯在业主大会上认真回应每一条质疑，哪怕同一问题被问了三遍。

Q10. RFC 被批准合并之后意味着什么？

单选题 · extreme

  • A.方案获准但实施仍需代码评审← 正确答案
  • B.代码已完成可直接发布版本
  • C.核心成员将立即着手实现
  • D.备选方案将自动失效作废

答案：A。RFC 批准是设计里程碑，后续实施仍需按规范拆分成多个 PR，逐个经历代码评审和测试（A 正确）。批准不代表代码完成（B），也不代表维护者替你实现（C）。备选方案仍作为设计记录保留，而非“作废”（D）。这就像方案书表决通过后，只有施工图、材料、监理各环节都合格，工程才算真正落地。