这次我们来看一个名为“Let Them Write RFCs”的项目。这个项目不是AI模型也不是图像或语音工具而是一个关于软件开发流程和文档协作的方法论实践。它的核心主张很简单在技术团队中鼓励并授权所有成员而不仅仅是架构师或资深工程师来撰写RFCRequest for Comments征求意见稿以此驱动技术决策、设计讨论和知识沉淀。对于开发者、技术负责人和项目经理来说如果团队正面临设计文档质量参差不齐、技术决策过程不透明、新人难以融入核心讨论等问题那么理解并实践“Let Them Write RFCs”的理念可能会带来显著的流程改进。本文将深入拆解这一方法它是什么、解决了什么问题、具体如何落地实施以及如何避免常见的陷阱。我们不会讨论具体的代码实现而是聚焦于流程设计、模板工具和团队协作的最佳实践。1. 核心能力速览“Let Them Write RFCs”并非一个可执行的软件包而是一套工作流程和规范。因此它的“能力”体现在对团队协作模式的改变上。能力项说明核心理念民主化技术设计过程鼓励任何对问题有见解的成员发起和撰写设计文档。主要产出结构化的RFC文档用于描述问题背景、提案方案、权衡分析、未决问题等。启动门槛无硬件要求。核心是团队共识、文档模板和协作工具如Git、Markdown、讨论区。核心价值提升设计透明度、积累团队知识库、规范决策流程、降低沟通成本。适合场景中型及以上技术团队、开源项目、需要进行复杂技术选型或系统重构的场景。不适合场景微型团队3人以下、紧急线上故障处理、非常明确且微小的改动。2. 适用场景与使用边界2.1 谁应该使用这套方法一线开发工程师当你发现现有架构存在缺陷或有一个更好的解决方案时你可以通过RFC正式提出获得讨论和采纳的机会。技术负责人/架构师通过RFC流程可以将决策依据书面化让团队理解背后的思考而不仅仅是接受一个结果。这也有助于分散设计压力。项目经理/产品经理可以更早、更结构化地介入技术方案讨论理解不同方案对产品目标、排期和资源的影响。新加入团队的成员RFC仓库是绝佳的学习资料能快速了解系统设计的历史和团队的思考方式。2.2 它能解决什么问题设计过程黑盒化避免“架构师在会议室里画个图出来就直接开发”的情况。RFC要求将设计思路公开接受评议。知识孤岛关键的设计决策仅存在于少数人的头脑或临时聊天记录中。RFC形成了可搜索、可追溯的组织记忆。会议低效在没有预先阅读材料的情况下设计评审会议容易变成冗长的即时讨论。RFC要求与会者提前阅读会议聚焦于关键争议点。决策反复书面化的RFC记录了当时的环境、约束和决策理由当未来有人质疑“为什么当初这么选”时有据可查。2.3 使用边界与注意事项不是银弹RFC流程会引入额外的文档工作。对于琐碎、明确或紧急的修改应走简化的流程如直接在代码注释中说明或事后补录。需要文化支持必须营造“对事不对人”的安全环境。批评应针对提案内容而非提案人。管理者需要明确鼓励这种行为。避免形式主义重点在于沟通和决策的质量而非文档格式的完美。模板是工具不是枷锁。版权与合规RFC内容通常是团队内部知识产权。如需对外公开如开源项目需注意脱敏处理。3. 环境准备与前置条件实施“Let Them Write RFCs”不需要安装Python或配置CUDA但需要准备好“协作环境”和“团队共识”。3.1 工具链准备通用推荐版本控制系统Git是标配。所有RFC文档应像代码一样被管理。文档格式Markdown是首选。它版本友好、易于阅读和编写且能被大多数工具渲染。协作平台GitHub/GitLab/Gitee利用其Issues发起讨论Pull Requests进行RFC内容的评审和合并Projects管理RFC状态。Confluence/Notion适合更侧重内部知识库管理的团队但需注意与代码变更的关联性可能减弱。沟通工具Slack、Teams或钉钉等用于通知RFC的新建、更新和评审请求。3.2 团队共识与规则定义这是比工具更重要的“软环境”。明确触发条件团队需要共识什么样的变更需要RFC例如新服务设计、重大架构重构、引入新技术栈、可能影响多团队的API变更等。定义角色与流程作者任何团队成员。评审者相关领域的技术负责人、受影响系统的维护者、产品经理等。决策者通常是一个小型的技术委员会或直接负责人负责在讨论后做出最终决策通过、拒绝或要求修改。制定RFC模板这是保证文档质量的关键。下一节会详细展开。设立RFC仓库在Git中创建一个专门的rfcs/目录或仓库用于存放所有RFC文档。4. RFC文档模板设计与启动方式一个结构良好的模板能引导作者思考全面也方便评审者快速抓住重点。下面是一个融合了业界实践如Rust、Python社区的通用RFC模板。4.1 基础RFC模板Markdown格式在项目根目录或rfcs/目录下创建模板文件如rfcs/0000-template.md。# RFC N: [提案标题] | 项目 | 内容 | | :--- | :--- | | **状态** | 草案Draft / 评审中Review / 已采纳Accepted / 已拒绝Rejected / 已实施Implemented | | **作者** | [姓名/邮箱] | | **创建日期** | YYYY-MM-DD | | **相关Issue** | #[Issue编号] (可选) | ## 摘要 用一两段话简要概括整个提案。这是给忙碌的决策者看的“电梯演讲”。 ## 动机 为什么要做这个改变需要解决什么问题不解决会有什么后果这里要描述现状的痛点可以包含数据、用户反馈或系统指标。 ## 详细设计 这是RFC的核心。详细描述你的提案。 * **架构图**如果涉及组件变更请提供架构图。 * **接口定义**新的API、配置项、数据模型等最好给出示例。 * **数据流/流程图**说明关键的业务或数据流程如何变化。 * **与其他系统的交互**说明变更如何影响上下游。 * **伪代码/示例**对于复杂的逻辑用伪代码或简化的代码示例说明。 尽量做到详细让评审者无需追问就能理解方案全貌。 ## 权衡分析 每个设计都有取舍。诚实地分析 * **替代方案**你考虑过的其他方案是什么为什么最终否定了它们 * **优缺点**本方案的优点和缺点分别是什么 * **成本估算**开发工作量、运维复杂度、迁移成本等。 ## 未决问题 列出你在撰写时尚未确定答案的问题。这可以引导评审讨论。 例如 * 方案A和方案B在性能上的具体差异还需要压测验证。 * 新引入的第三方库的长期维护性如何 ## 后续计划 如果提案被采纳下一步做什么 1. 任务拆解可以链接到具体的Task或Issue。 2. 实施阶段划分。 3. 回滚方案如果适用。 ## 参考资料 1. 相关的技术文档、论文、博客文章链接。 2. 其他公司或开源项目的类似实践。4.2 流程启动方式流程不是自动化的但可以通过工具规范化。发起阶段作者在rfcs/目录下复制模板命名为rfcs/xxxx-[简短描述].md如rfcs/0021-migration-to-grpc.md。作者完成草案撰写将状态置为草案Draft。作者创建一个GitHub Issue简要说明背景并附上RFC文档链接邀请初步讨论。评审阶段作者根据初步反馈修改RFC认为准备充分后创建一个Pull Request将RFC文件合并到主分支或一个专门的rfcs分支。在PR描述中将RFC状态更新为评审中Review并相关评审者。评审者在PR中进行行评Line Comments讨论细节。作者根据评审意见迭代修改RFC。决策与归档阶段经过多轮评审后决策者或团队投票在PR中给出最终结论。如果采纳合并PR将RFC状态更新为已采纳Accepted并创建相关开发任务。如果拒绝关闭PR将RFC状态更新为已拒绝Rejected并记录主要原因。文档仍应保留作为历史记录。实施完成后更新RFC状态为已实施Implemented。5. 功能测试与效果验证如何评估RFC流程的健康度对于流程和方法论我们的“测试”就是评估其执行效果。可以从以下几个维度进行验证5.1 验证维度一文档质量与完整性测试目的检查RFC文档是否包含了做出明智决策所需的全部信息。操作步骤随机抽取3-5份状态为已采纳的RFC文档。检查清单摘要是否清晰表达了核心提案动机部分是否明确了待解决的业务或技术问题详细设计是否足够详细能让另一位工程师在不询问作者的情况下实现大致框架权衡分析是否讨论了至少一个替代方案未决问题是否被列出并在评审中得到了解决成功标准80%以上的受检RFC满足所有检查项。5.2 验证维度二流程效率与参与度测试目的确保流程不成为瓶颈且团队广泛参与。操作步骤回顾过去一个季度所有的RFC。度量指标平均评审周期从PR创建到合并/关闭的平均时长。理想应在一周内复杂提案可延长。作者分布RFC作者是否集中在少数资深成员健康的比例应有超过30%的团队成员至少发起过1次RFC。评审参与度平均每个RFC有多少位不同的评审者留下实质性评论非“LGTM”成功标准评审周期可控作者和评审者来源多样化。5.3 验证维度三决策影响与知识传承测试目的验证RFC是否真正指导了实施并成为有效的知识载体。操作步骤找一个半年前已采纳的RFC找到其对应的实施代码或系统。询问一位当时未参与该RFC的新同事让他/她阅读该RFC。检查清单RFC的设计与当前系统实现是否一致新同事在阅读RFC后能否准确回答关于该系统设计初衷和关键决策的问题成功标准设计与实现一致新同事能通过文档快速理解系统。6. 接口与自动化将RFC流程集成到工具链虽然核心是人工流程但可以通过一些“接口”和自动化提升体验。6.1 利用Git Hooks进行基础校验可以在项目Git仓库中配置pre-commit钩子对rfcs/目录下的Markdown文件进行基础检查。#!/bin/bash # .git/hooks/pre-commit (示例片段) for file in $(git diff --cached --name-only --diff-filterACM | grep -E ^rfcs/.*\.md$); do # 检查是否包含必要的章节标题 if ! grep -qE ^## (摘要|动机|详细设计|权衡分析) $file; then echo 错误RFC文件 $file 缺少必要的章节摘要、动机、详细设计、权衡分析。 exit 1 fi # 检查状态表是否被修改可选防止状态被随意更改 if grep -q ^|.*状态.*| $file; then echo 提示请确认RFC状态变更符合流程。 fi done6.2 使用GitHub Actions/GitLab CI进行自动化管理可以配置CI/CD流水线自动化一些任务。# .github/workflows/rfc-notify.yml 示例 name: Notify on New RFC on: pull_request: paths: - rfcs/** types: [opened, ready_for_review] jobs: notify: runs-on: ubuntu-latest steps: - name: Notify Team Channel uses: slackapi/slack-github-actionv1.24.0 with: channel-id: C1234567890 # 团队频道ID slack-message: | :memo: 新的RFC等待评审 标题${{ github.event.pull_request.title }} 作者${{ github.event.pull_request.user.login }} 链接${{ github.event.pull_request.html_url }} 请相关同学及时查看。 env: SLACK_BOT_TOKEN: ${{ secrets.SLACK_BOT_TOKEN }}6.3 生成RFC索引页面可以编写一个简单的脚本自动生成一个包含所有RFC列表和状态的索引页面README.md。#!/usr/bin/env python3 # scripts/generate_rfc_index.py import os import re from pathlib import Path RFC_DIR Path(./rfcs) INDEX_FILE RFC_DIR / README.md def extract_rfc_info(file_path): with open(file_path, r, encodingutf-8) as f: content f.read() title_match re.search(r^# RFC \d: (.)$, content, re.MULTILINE) status_match re.search(r^\|.*状态.*\|\s*(.?)\s*\|$, content, re.MULTILINE) author_match re.search(r^\|.*作者.*\|\s*(.?)\s*\|$, content, re.MULTILINE) date_match re.search(r^\|.*创建日期.*\|\s*(.?)\s*\|$, content, re.MULTILINE) return { file: file_path.name, title: title_match.group(1) if title_match else N/A, status: status_match.group(1) if status_match else N/A, author: author_match.group(1) if author_match else N/A, date: date_match.group(1) if date_match else N/A, } def main(): rfc_files list(RFC_DIR.glob(*.md)) rfc_files [f for f in rfc_files if f.name ! README.md and f.name ! 0000-template.md] rfc_files.sort() rfcs [] for f in rfc_files: rfcs.append(extract_rfc_info(f)) with open(INDEX_FILE, w, encodingutf-8) as f: f.write(# RFC 索引\n\n) f.write(| RFC编号 | 标题 | 状态 | 作者 | 创建日期 |\n) f.write(|---------|------|------|------|----------|\n) for rfc in rfcs: # 从文件名提取编号例如 0021-migration-to-grpc.md - 0021 rfc_num rfc[file].split(-)[0] f.write(f| {rfc_num} | [{rfc[title]}]({rfc[file]}) | {rfc[status]} | {rfc[author]} | {rfc[date]} |\n) if __name__ __main__: main()将此脚本加入CI或Makefile在RFC合并后自动更新索引。7. 资源占用与协作成本观察引入RFC流程会带来额外的“协作成本”需要像观察系统资源一样进行管理。时间成本作者撰写一份高质量的RFC可能需要数小时到数天。这是最大的投入。评审者深度评审一份RFC可能需要1-2小时。团队需要为评审预留固定时间如每周固定的“设计评审时间盒”。关键指标关注“平均每行代码的RFC讨论时长”避免过度设计。注意力成本过多的RFC同时处于评审状态会分散团队注意力。建议使用看板如GitHub Projects管理RFC状态并设置在审RFC的数量限制例如团队同时深度评审的RFC不超过3个。工具成本Git仓库容量几乎可忽略不计。主要的工具成本是团队学习和适应新流程的初期投入。可以通过内部分享、编写引导文档和设置流程教练来降低。降低成本的建议区分RFC粒度对于小型改进可以使用轻量级的“设计笔记”Design Note格式只需几段文字描述变更和理由。推行异步优先鼓励在PR评论中充分进行异步讨论减少同步会议时间。设立流程守护者在初期可以指定一位同事负责引导流程、解答疑问、定期回顾流程效果并提议改进。8. 常见问题与排查方法在推行“Let Them Write RFCs”过程中可能会遇到以下典型问题。问题现象可能原因排查方式解决方案RFC无人评审1. 评审责任不明确。2. 团队工作饱和无暇评审。3. RFC内容过于庞大晦涩。1. 检查PR是否了明确的评审者。2. 调研团队时间分配。3. 评估RFC的可读性。1. 明确评审矩阵谁必须审谁可以审。2. 设立团队“办公时间”或固定评审时段。3. 要求作者先寻求非正式反馈迭代后再发起正式评审。评审陷入细节争论无法推进讨论偏离核心设计陷入技术细节或风格偏好之争。回顾讨论串看争议点是否属于“实现细节”。1.决策者介入明确当前讨论的边界将实现细节问题记录为“未决问题”留待实施阶段解决。2. 强调RFC的目标是达成设计共识而非代码审查。RFC流程变得官僚化大家不愿写1. 模板过于复杂。2. 流程耗时过长。3. 写了也没用决策早已内定。1. 匿名收集团队反馈。2. 分析从发起到决策的平均周期。1.简化模板提供“精简版”和“完整版”两种选择。2.为流程设定期限例如“评审期最长7天”。3.领导层以身作则公开依据RFC做决策并奖励提出优秀RFC的成员。RFC与最终实现差异大1. 实施过程中发现了新问题。2. 开发人员未严格遵循设计。对比RFC文档和代码提交。1.要求更新RFC如果实施有重大偏离应补充修订附录或创建新的RFC来说明变化。2. 将RFC作为代码审查的参考依据之一。新成员不知道何时该写RFC触发条件模糊或缺乏示例。询问新成员的困惑点。1.提供清晰的决策树如流程图。2.建立RFC示例库标注哪些是优秀范例。3. 安排导师在初期提供指导。9. 最佳实践与使用建议从小处开始逐步推广不要在全公司强制推行。先在一个有积极性的小团队如一个5-10人的产品线试点打磨流程和模板再逐步推广。工具服务于流程而非相反先明确团队协作的痛点和你希望RFC流程达成的目标再选择或配置工具。避免陷入工具选型的纠结。定期回顾与改进每季度或每半年召开一次简短的“流程回顾会”讨论什么做得好什么很痛苦模板需要调整吗流程需要优化吗奖励与认可公开表扬那些撰写了高质量RFC、提供了深度评审意见的成员。这可以是口头表扬、团队分享甚至是小的物质奖励。将撰写RFC纳入工程师的成长模型。保持文档活性RFC不是一成不变的。当系统发生重大演进时可以创建新的RFC来补充或取代旧文档。确保索引总是最新的。与现有流程整合将RFC状态与项目管理系统如Jira联动。例如“已采纳”的RFC自动创建对应的开发史诗Epic和任务Task。10. 总结“Let Them Write RFCs”的本质是将技术决策从一个黑盒的、依赖个人的过程转变为一个透明的、可追溯的、集体智慧驱动的过程。它最大的价值不在于产生了一份完美的文档而在于强制进行了深度的、结构化的思考与沟通。对于想要尝试的团队第一步不是制定复杂的规则而是挑选一个正在面临的中等复杂度技术问题鼓励相关同事按照一个简单模板把想法写下来并进行讨论。从这个微小的实践开始感受书面化沟通带来的清晰度提升和共识加速。最容易踩的坑是“过度流程化”让写RFC变成令人畏惧的负担。始终记住流程的终极目标是提升效率和质量而不是创造工作。保持灵活持续调整让流程为团队服务而不是团队为流程服务。当RFC文化建立起来后你会发现它不仅是设计文档更是团队的技术路线图、新人的入职指南和决策的历史档案。它让“为什么这么做”变得和“怎么做”一样重要。