这次我们来看一个名为“Let Them Write RFCs”的项目。这个项目不是AI模型，也不是图像或语音工具，而是一个关于软件开发流程和文档协作的方法论实践。它的核心主张很简单：在技术团队中，鼓励并授权所有成员（而不仅仅是架构师或资深工程师）来撰写RFC（Request for Comments，征求意见稿），以此驱动技术决策、设计讨论和知识沉淀。

对于开发者、技术负责人和项目经理来说，如果团队正面临设计文档质量参差不齐、技术决策过程不透明、新人难以融入核心讨论等问题，那么理解并实践“Let Them Write RFCs”的理念，可能会带来显著的流程改进。本文将深入拆解这一方法：它是什么、解决了什么问题、具体如何落地实施，以及如何避免常见的陷阱。我们不会讨论具体的代码实现，而是聚焦于流程设计、模板工具和团队协作的最佳实践。

1. 核心能力速览

“Let Them Write RFCs”并非一个可执行的软件包，而是一套工作流程和规范。因此，它的“能力”体现在对团队协作模式的改变上。

2. 适用场景与使用边界

2.1 谁应该使用这套方法？

• 一线开发工程师：当你发现现有架构存在缺陷，或有一个更好的解决方案时，你可以通过RFC正式提出，获得讨论和采纳的机会。
• 技术负责人/架构师：通过RFC流程，可以将决策依据书面化，让团队理解背后的思考，而不仅仅是接受一个结果。这也有助于分散设计压力。
• 项目经理/产品经理：可以更早、更结构化地介入技术方案讨论，理解不同方案对产品目标、排期和资源的影响。
• 新加入团队的成员：RFC仓库是绝佳的学习资料，能快速了解系统设计的历史和团队的思考方式。

2.2 它能解决什么问题？

1. 设计过程黑盒化：避免“架构师在会议室里画个图，出来就直接开发”的情况。RFC要求将设计思路公开，接受评议。
2. 知识孤岛：关键的设计决策仅存在于少数人的头脑或临时聊天记录中。RFC形成了可搜索、可追溯的组织记忆。
3. 会议低效：在没有预先阅读材料的情况下，设计评审会议容易变成冗长的即时讨论。RFC要求与会者提前阅读，会议聚焦于关键争议点。
4. 决策反复：书面化的RFC记录了当时的环境、约束和决策理由，当未来有人质疑“为什么当初这么选”时，有据可查。

2.3 使用边界与注意事项

• 不是银弹：RFC流程会引入额外的文档工作。对于琐碎、明确或紧急的修改，应走简化的流程（如直接在代码注释中说明，或事后补录）。
• 需要文化支持：必须营造“对事不对人”的安全环境。批评应针对提案内容，而非提案人。管理者需要明确鼓励这种行为。
• 避免形式主义：重点在于沟通和决策的质量，而非文档格式的完美。模板是工具，不是枷锁。
• 版权与合规：RFC内容通常是团队内部知识产权。如需对外公开（如开源项目），需注意脱敏处理。

3. 环境准备与前置条件

实施“Let Them Write RFCs”不需要安装Python或配置CUDA，但需要准备好“协作环境”和“团队共识”。

3.1 工具链准备（通用推荐）

1. 版本控制系统：Git是标配。所有RFC文档应像代码一样被管理。
2. 文档格式：Markdown是首选。它版本友好、易于阅读和编写，且能被大多数工具渲染。
3. 协作平台：
   • GitHub/GitLab/Gitee：利用其Issues发起讨论，Pull Requests进行RFC内容的评审和合并，Projects管理RFC状态。
   • Confluence/Notion：适合更侧重内部知识库管理的团队，但需注意与代码变更的关联性可能减弱。
4. 沟通工具：Slack、Teams或钉钉等，用于通知RFC的新建、更新和评审请求。

3.2 团队共识与规则定义

这是比工具更重要的“软环境”。

1. 明确触发条件：团队需要共识，什么样的变更需要RFC？例如：新服务设计、重大架构重构、引入新技术栈、可能影响多团队的API变更等。
2. 定义角色与流程：
   • 作者：任何团队成员。
   • 评审者：相关领域的技术负责人、受影响系统的维护者、产品经理等。
   • 决策者：通常是一个小型的技术委员会或直接负责人，负责在讨论后做出最终决策（通过、拒绝或要求修改）。
3. 制定RFC模板：这是保证文档质量的关键。下一节会详细展开。
4. 设立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 流程启动方式

流程不是自动化的，但可以通过工具规范化。

1. 发起阶段：

   • 作者在rfcs/目录下复制模板，命名为rfcs/xxxx-[简短描述].md（如rfcs/0021-migration-to-grpc.md）。
   • 作者完成草案撰写，将状态置为草案（Draft）。
   • 作者创建一个GitHub Issue，简要说明背景，并附上RFC文档链接，邀请初步讨论。

2. 评审阶段：

   • 作者根据初步反馈修改RFC，认为准备充分后，创建一个Pull Request，将RFC文件合并到主分支（或一个专门的rfcs分支）。
   • 在PR描述中，将RFC状态更新为评审中（Review），并@相关评审者。
   • 评审者在PR中进行行评（Line Comments），讨论细节。
   • 作者根据评审意见迭代修改RFC。

3. 决策与归档阶段：

   • 经过多轮评审后，决策者（或团队投票）在PR中给出最终结论。
   • 如果采纳，合并PR，将RFC状态更新为已采纳（Accepted），并创建相关开发任务。
   • 如果拒绝，关闭PR，将RFC状态更新为已拒绝（Rejected），并记录主要原因。文档仍应保留，作为历史记录。
   • 实施完成后，更新RFC状态为已实施（Implemented）。

5. 功能测试与效果验证：如何评估RFC流程的健康度

对于流程和方法论，我们的“测试”就是评估其执行效果。可以从以下几个维度进行验证：

5.1 验证维度一：文档质量与完整性

• 测试目的：检查RFC文档是否包含了做出明智决策所需的全部信息。
• 操作步骤：随机抽取3-5份状态为已采纳的RFC文档。
• 检查清单：
  1. 摘要是否清晰表达了核心提案？
  2. 动机部分是否明确了待解决的业务或技术问题？
  3. 详细设计是否足够详细，能让另一位工程师在不询问作者的情况下实现大致框架？
  4. 权衡分析是否讨论了至少一个替代方案？
  5. 未决问题是否被列出并在评审中得到了解决？
• 成功标准：80%以上的受检RFC满足所有检查项。

5.2 验证维度二：流程效率与参与度

• 测试目的：确保流程不成为瓶颈，且团队广泛参与。
• 操作步骤：回顾过去一个季度所有的RFC。
• 度量指标：
  1. 平均评审周期：从PR创建到合并/关闭的平均时长。理想应在一周内，复杂提案可延长。
  2. 作者分布：RFC作者是否集中在少数资深成员？健康的比例应有超过30%的团队成员至少发起过1次RFC。
  3. 评审参与度：平均每个RFC有多少位不同的评审者留下实质性评论（非“LGTM”）？
• 成功标准：评审周期可控，作者和评审者来源多样化。

5.3 验证维度三：决策影响与知识传承

• 测试目的：验证RFC是否真正指导了实施，并成为有效的知识载体。
• 操作步骤：
  1. 找一个半年前已采纳的RFC，找到其对应的实施代码或系统。
  2. 询问一位当时未参与该RFC的新同事，让他/她阅读该RFC。
• 检查清单：
  1. RFC的设计与当前系统实现是否一致？
  2. 新同事在阅读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-filter=ACM | grep -E '^rfcs/.*\.md$'); do # 检查是否包含必要的章节标题 if ! grep -qE '^## (摘要|动机|详细设计|权衡分析)' "$file"; then echo "错误：RFC文件 $file 缺少必要的章节（摘要、动机、详细设计、权衡分析）。" exit 1 fi # 检查状态表是否被修改（可选，防止状态被随意更改） if grep -q '^|.*状态.*|' "$file"; then echo "提示：请确认RFC状态变更符合流程。" fi done

6.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-action@v1.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', encoding='utf-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', encoding='utf-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流程会带来额外的“协作成本”，需要像观察系统资源一样进行管理。

1. 时间成本：

   • 作者：撰写一份高质量的RFC可能需要数小时到数天。这是最大的投入。
   • 评审者：深度评审一份RFC可能需要1-2小时。团队需要为评审预留固定时间（如每周固定的“设计评审时间盒”）。
   • 关键指标：关注“平均每行代码的RFC讨论时长”，避免过度设计。

2. 注意力成本：

   • 过多的RFC同时处于评审状态会分散团队注意力。建议使用看板（如GitHub Projects）管理RFC状态，并设置在审RFC的数量限制（例如，团队同时深度评审的RFC不超过3个）。

3. 工具成本：

   • Git仓库容量几乎可忽略不计。
   • 主要的工具成本是团队学习和适应新流程的初期投入。可以通过内部分享、编写引导文档和设置流程教练来降低。

降低成本的建议：

• 区分RFC粒度：对于小型改进，可以使用轻量级的“设计笔记”（Design Note）格式，只需几段文字描述变更和理由。
• 推行异步优先：鼓励在PR评论中充分进行异步讨论，减少同步会议时间。
• 设立流程守护者：在初期，可以指定一位同事负责引导流程、解答疑问、定期回顾流程效果并提议改进。

8. 常见问题与排查方法

在推行“Let Them Write RFCs”过程中，可能会遇到以下典型问题。

9. 最佳实践与使用建议

1. 从小处开始，逐步推广：不要在全公司强制推行。先在一个有积极性的小团队（如一个5-10人的产品线）试点，打磨流程和模板，再逐步推广。
2. 工具服务于流程，而非相反：先明确团队协作的痛点和你希望RFC流程达成的目标，再选择或配置工具。避免陷入工具选型的纠结。
3. 定期回顾与改进：每季度或每半年，召开一次简短的“流程回顾会”，讨论：什么做得好？什么很痛苦？模板需要调整吗？流程需要优化吗？
4. 奖励与认可：公开表扬那些撰写了高质量RFC、提供了深度评审意见的成员。这可以是口头表扬、团队分享，甚至是小的物质奖励。将撰写RFC纳入工程师的成长模型。
5. 保持文档活性：RFC不是一成不变的。当系统发生重大演进时，可以创建新的RFC来补充或取代旧文档。确保索引总是最新的。
6. 与现有流程整合：将RFC状态与项目管理系统（如Jira）联动。例如，“已采纳”的RFC自动创建对应的开发史诗（Epic）和任务（Task）。

10. 总结

“Let Them Write RFCs”的本质，是将技术决策从一个黑盒的、依赖个人的过程，转变为一个透明的、可追溯的、集体智慧驱动的过程。它最大的价值不在于产生了一份完美的文档，而在于强制进行了深度的、结构化的思考与沟通。

对于想要尝试的团队，第一步不是制定复杂的规则，而是挑选一个正在面临的中等复杂度技术问题，鼓励相关同事按照一个简单模板，把想法写下来并进行讨论。从这个微小的实践开始，感受书面化沟通带来的清晰度提升和共识加速。

最容易踩的坑是“过度流程化”，让写RFC变成令人畏惧的负担。始终记住，流程的终极目标是提升效率和质量，而不是创造工作。保持灵活，持续调整，让流程为团队服务，而不是团队为流程服务。

当RFC文化建立起来后，你会发现它不仅是设计文档，更是团队的技术路线图、新人的入职指南和决策的历史档案。它让“为什么这么做”变得和“怎么做”一样重要。