⚡

RFC流程技能Skill rfc-process

RFC流程技能用于管理和指导技术提案和设计决策的请求评论（RFC）过程。它提供模板、生命周期、最佳实践和工作流，以促进团队协作、文档化和共识建立。关键词：RFC、技术提案、设计决策、团队协作、文档化、软件开发、项目管理。

架构设计 0 次安装 0 次浏览 更新于 3/11/2026

name: rfc-process description: 技术提案的请求评论（RFC）过程 allowed-tools: Read, Glob, Grep, Write, Edit

RFC流程技能

何时使用此技能

在以下情况下使用此技能：

  • RFC过程任务 - 处理技术提案的请求评论（RFC）过程
  • 规划或设计 - 需要RFC过程方法的指导
  • 最佳实践 - 希望遵循既定模式和标准

概述

促进技术提案和设计决策的请求评论（RFC）过程。

强制要求：文档优先方法

创建RFC之前：

  1. 调用docs-management技能获取RFC模式
  2. 通过MCP服务器验证RFC最佳实践（如perplexity）
  3. 基于IETF RFC风格为软件团队调整指导

RFC vs ADR

RFC vs ADR 比较：

RFC（请求评论）：
• 用于决策前的提案
• 邀请讨论和反馈
• 可能被接受、拒绝或修订
• 通常比ADR范围更大
• 用于需要共识的重大变更

ADR（架构决策记录）：
• 在决策后记录决定
• 记录决策和理由
• 一旦接受即不可变
• 专注于单个决策
• 用于所有重要的架构决策

关系：
RFC（提案） → 讨论 → 决策 → ADR（记录）

RFC模板

# RFC-[编号]: [标题]

| 属性 | 值 |
|----------|-------|
| **RFC编号** | RFC-[编号] |
| **标题** | [简短、描述性标题] |
| **作者** | [姓名] |
| **状态** | [草案 | 开放评论 | 最终评论 | 接受 | 拒绝 | 撤回] |
| **创建日期** | [YYYY-MM-DD] |
| **更新日期** | [YYYY-MM-DD] |
| **目标决策日期** | [YYYY-MM-DD] |
| **利益相关者** | [团队/个人] |

---

## 摘要

[一段执行摘要。提案内容及原因？]

---

## 动机

### 问题陈述

[此RFC解决什么问题？当前情况为何不足？]

### 目标

- [目标1]
- [目标2]
- [目标3]

### 非目标

- [非目标1：此RFC明确不解决的内容]
- [非目标2]

---

## 提案

### 概述

[提案解决方案的高层描述]

### 详细设计

[深入技术描述。包括：
- 架构变更
- API变更
- 数据模型变更
- 算法描述
- 集成点]

### 示例用法

```csharp
// 代码示例展示提案用法
public class ExampleUsage
{
    public async Task Example()
    {
        // 演示提议的API或模式
    }
}

迁移计划

[现有系统/数据如何迁移？]

  1. 阶段1：[描述]
  2. 阶段2：[描述]
  3. 阶段3：[描述]

考虑的替代方案

替代方案1：[名称]

描述：[此替代方案内容]

优点：

  • [优点1]
  • [优点2]

缺点：

  • [缺点1]
  • [缺点2]

未选择原因：[拒绝此替代方案的理由]

替代方案2：[名称]

[相同结构…]

现状（不采取行动）

**描述：**继续当前方法

优点：

  • 无迁移成本
  • 无学习曲线

缺点：

  • [激励此RFC的问题仍存在]

权衡

权衡 选择路径 替代路径
[权衡1] [我们接受什么] [我们放弃什么]
[权衡2] [我们接受什么] [我们放弃什么]

风险与缓解措施

风险 可能性 影响 缓解策略
[风险1] 低/中/高 低/中/高 [缓解策略]
[风险2] 低/中/高 低/中/高 [缓解策略]

实施计划

时间线

阶段 描述 持续时间 依赖项
阶段1 [描述] [持续时间] [依赖项]
阶段2 [描述] [持续时间] [依赖项]

资源需求

  • [资源1：例如，“2名高级工程师4周”]
  • [资源2：例如，“基础设施团队支持”]

成功标准

  • [ ] [标准1：可测量的成功指标]
  • [ ] [标准2：可测量的成功指标]

回滚计划

[如果实施失败如何回滚]

安全考虑

[此提案的安全影响]

  • [考虑1]
  • [考虑2]

隐私考虑

[此提案的隐私影响]

  • [考虑1]
  • [考虑2]

测试策略

[如何测试？]

  • 单元测试：[方法]
  • 集成测试：[方法]
  • 性能测试：[方法]
  • 发布计划：[金丝雀发布、百分比发布等]

文档更新

[需要创建或更新的文档？]

  • [ ] [文档1：例如，“API参考”]
  • [ ] [文档2：例如，“开发者指南”]
  • [ ] [文档3：例如，“运维手册”]

开放问题

[在评论期间需要解决的问题]

  1. [问题1]
  2. [问题2]

反馈

评论

[讨论空间 - 可链接到外部讨论线程]

日期 作者 评论 解决方案
[日期] [姓名] [评论] [解决方案]

修订历史

版本 日期 作者 变更
0.1 [日期] [姓名] 初始草案
0.2 [日期] [姓名] [所做变更]

参考资料

  • [参考1]
  • [参考2]
  • [相关RFC/ADR]

## RFC生命周期

```text
RFC状态流：

┌─────────────────────────────────────────────────────────────────────────────┐
│                                                                              │
│    ┌──────────┐     ┌─────────────────┐     ┌──────────────────┐            │
│    │  草案    │────▶│  开放评论       │────▶│  最终评论        │           │
│    └──────────┘     └─────────────────┘     └──────────────────┘            │
│         │                    │                       │                       │
│         │                    │                       │                       │
│         ▼                    ▼                       ▼                       │
│    ┌──────────┐         ┌──────────┐           ┌──────────┐                 │
│    │  撤回    │         │  撤回    │           │  接受    │                 │
│    └──────────┘         └──────────┘           └──────────┘                 │
│                                                      │                       │
│                              ┌──────────┐            │                       │
│                              │  拒绝    │◀───────────┤                       │
│                              └──────────┘            │                       │
│                                                      ▼                       │
│                                              ┌──────────────┐                │
│                                              │  已实施      │                │
│                                              └──────────────┘                │
│                                                                              │
└─────────────────────────────────────────────────────────────────────────────┘

时间线：
• 草案：作者准备，尚未准备好审核
• 开放评论：至少2周反馈时间
• 最终评论：1周最终异议
• 接受/拒绝：决策做出
• 已实施：工作完成

何时编写RFC

情况 需要RFC？
新微服务 是
数据模型变更 是
新公共API 是
内部重构 可能
错误修复 否
次要增强 否
破坏性变更 是
新技术采用 是
废弃 是

RFC角色

角色 职责
作者 编写RFC，处理反馈，推动决策
审核者 提供技术反馈
利益相关者 代表受影响团队或系统
批准者 做出最终接受/拒绝决策
编辑 确保RFC符合标准（可选）

轻量级RFC（设计文档）

对于较小提案，使用此简化格式：

# 设计文档：[标题]

**作者：** [姓名]
**日期：** [日期]
**状态：** [草案/审核/批准]

## 背景

[我们解决什么问题？]

## 提案

[我们计划做什么？]

## 替代方案

[我们考虑过什么其他方案？]

## 决策

[我们决定什么及原因？]

RFC注册表

# RFC注册表

## 活动RFC

| RFC | 标题 | 作者 | 状态 | 目标日期 |
|-----|-------|--------|--------|-------------|
| RFC-012 | [标题] | [作者] | 开放评论 | 2025-02-15 |
| RFC-013 | [标题] | [作者] | 草案 | - |

## 已接受RFC

| RFC | 标题 | 接受日期 | ADR |
|-----|-------|----------|-----|
| RFC-010 | [标题] | 2025-01-10 | ADR-025 |
| RFC-011 | [标题] | 2025-01-15 | ADR-026 |

## 已拒绝/撤回RFC

| RFC | 标题 | 状态 | 原因 |
|-----|-------|--------|--------|
| RFC-008 | [标题] | 拒绝 | [简短原因] |
| RFC-009 | [标题] | 撤回 | [简短原因] |

最佳实践

对作者

  1. 尽早开始讨论：在正式RFC前分享草案
  2. 详尽准备：预先处理明显问题
  3. 保持客观：公平呈现替代方案
  4. 及时回应：快速处理反馈
  5. 知道何时调整：愿意改变或撤回

对审核者

  1. 建设性：建议改进，而非仅指出问题
  2. 及时：尊重截止日期
  3. 关注实质：避免琐碎争论
  4. 提出问题：澄清而非批评
  5. 提议替代方案：如有异议，提供替代

工作流

创建RFC时：

  1. 识别需求：识别需要共识的重大变更
  2. 草案RFC：使用模板，注重清晰性
  3. 预审核：非正式分享以获取早期反馈
  4. 发布：移至“开放评论”
  5. 讨论：处理反馈，根据需要修订
  6. 最终化：移至“最终评论”
  7. 决策：接受、拒绝或撤回
  8. 记录：如接受，创建ADR

扩展阅读

详细指导：

最后更新： 2025-12-26