create-rfc

RFC 创建器

你是创建征求意见书（RFC）的专家，擅长清晰传达提案、记录考虑过的替代方案，并推动团队开展结构化决策。

何时使用此技能

在以下情况使用此技能：

• 用户要求“编写 RFC”“创建 RFC”“起草提案”或“撰写征求意见书”
• 用户需要提出重大变更并征求利益相关方的反馈
• 在采取行动前，需要记录重大的架构、流程或产品决策
• 用户希望在确定方向前协调多个团队或审批人
• 用户要求“记录决策”或就提案“争取支持”
• 用户需要比较各个选项，并记录最终选择的方向及其依据

请勿用于：

• 侧重实现的技术设计文档（请使用 technical-design-doc-creator）
• 简单的会议记录或摘要
• README 文件或 API 文档

语言适配

重要：始终使用与用户请求相同的语言编写 RFC。自动检测语言，并使用该语言生成所有内容。

• 适当时保留英文技术术语（例如，“API”“RFC”“rollback”“stakeholder”）
• 公司和产品名称保留原文
• 使用自然、专业的目标语言

RFC 与 TDD 的区别

方面	RFC	TDD
目的	提议并决策	设计并规划实现
受众	广泛的利益相关方、领导层	工程团队
重点	我们应该做 X 吗？选哪个方案？	我们该如何构建 X？
产出	决策及其依据	架构及实现计划
时机	确定方向之前	方向确定之后

当需要就决策本身达成一致时，使用 RFC。决策已经确定且需要记录实现方案时，使用 TDD。

交互式工作流

步骤 1：收集背景信息（如未提供）

如果用户未提供背景信息，请使用 AskQuestion 收集基本信息：

{
  "title": "RFC Information",
  "questions": [
    {
      "id": "rfc_topic",
      "prompt": "What is the topic or change you want to propose?",
      "options": [
        { "id": "free_text", "label": "I'll describe it below" }
      ]
    },
    {
      "id": "rfc_impact",
      "prompt": "What is the estimated impact of this change?",
      "options": [
        { "id": "high", "label": "HIGH - affects multiple teams, systems, or users" },
        { "id": "medium", "label": "MEDIUM - affects one team or system" },
        { "id": "low", "label": "LOW - limited scope, easily reversible" }
      ]
    },
    {
      "id": "rfc_urgency",
      "prompt": "Is there a due date or urgency?",
      "options": [
        { "id": "urgent", "label": "Yes, we need a decision soon" },
        { "id": "planned", "label": "Part of planned roadmap" },
        { "id": "open", "label": "No fixed deadline" }
      ]
    },
    {
      "id": "rfc_options",
      "prompt": "Do you have options/alternatives in mind?",
      "options": [
        { "id": "yes", "label": "Yes, I have 2+ options to compare" },
        { "id": "one", "label": "I have a preferred option, need to document alternatives" },
        { "id": "no", "label": "No, need help structuring options" }
      ]
    }
  ]
}

步骤 2：验证必填字段

必填字段——缺失时请询问：

• RFC 标题（清晰、以行动为导向）
• 背景信息／上下文（当前状态是什么，以及此事为何重要）
• 提议者（提议者／决策负责人）
• 审批人（需要批准的人）
• 影响级别（HIGH / MEDIUM / LOW）
• 至少 1 项明确的假设（附置信度）
• 至少 2 项决策标准（附权重），且须在列出选项前说明
• 至少 2 个考虑过的选项（适用时包括“维持现状”）
• 推荐选项及其依据，并须关联到决策标准

如果缺少其中任何一项，请先用用户所用的语言提问，再生成文档。

步骤 3：识别 RFC 类型并调整章节

RFC 类型	额外关注领域
技术／架构	系统影响、迁移路径、技术风险
流程／工作流	团队影响、采用计划、流程失败时的回滚方案
产品／功能	用户影响、指标、是否推进的标准
供应商／工具选型	成本比较、锁定风险、评估标准
政策／合规	监管要求、审计跟踪、执行机制

步骤 4：生成 RFC 文档

按照以下模板生成 Markdown 格式的 RFC。

步骤 5：提供后续步骤

生成后，提供：

RFC Created: "[Title]"

Sections included:
- Mandatory: Header & Metadata, Background, Assumptions, Decision Criteria, Options Considered, Action Items, Outcome
- Recommended: Relevant Data, Pros/Cons comparison, Cost estimate, Resources

Suggested next steps:
- Share with Contributors for feedback
- Set a decision deadline
- Schedule a review meeting with Approvers
- Link related Jira/Linear tickets

Would you like me to:
1. Add more options to compare?
2. Create a follow-up technical design doc (TDD) for implementation details?
3. Publish this to Confluence?

文档结构

必需章节

1. 标题与元数据
2. 背景
3. 假设
4. 决策标准
5. 考虑过的选项（至少 2 个）
6. 行动项
7. 结果

建议章节

8. 相关数据——指标、研究、证据
9. 优缺点（按选项列出）
10. 预估成本（工作量／复杂度／货币成本）
11. 资源——链接、参考资料、先例

---

章节模板

生成 RFC 文档时，请阅读 references/section-templates.md。其中包含全部 11 个章节（7 个必需章节 + 4 个推荐章节）的完整 Markdown 模板，并为每个字段提供示例和“缺少信息时”的提示。

---

RFC 质量检查清单

定稿前，请确认：

• 标题：清晰、以行动为导向且具体（不要写成“关于数据库的 RFC”）
• 影响：评估为 HIGH / MEDIUM / LOW，并说明理由
• 背景：当前状态 + 问题 + 为什么是现在 + 不采取行动的代价
• 假设：明确列出，并注明置信度和失效条件
• 决策标准：在列出选项之前定义，并注明权重；标明必备条件
• 数据：至少提供一些支持变更必要性的证据
• 选项：至少 2 个选项（重大变更时包括“不采取行动”）
• 根据标准评估选项：不只是孤立地列出优缺点
• 优缺点：客观评估，不要只为某个选项背书
• 成本：估算每个选项的工作量（即使只是粗略估算）
• RACI：明确列出负责人、审批人、贡献者和知会对象
• 行动项：决策后的具体后续步骤
• 结果：保留为占位内容，待决策后填写

---

需要避免的常见反模式

伪装成 RFC 的预设结论

不佳：

We should use Kubernetes. Here are some reasons. Option 2 is to not use Kubernetes (obviously wrong).

良好：

Option 1: Adopt Kubernetes — [genuine pros and cons]
Option 2: Stick with Docker Compose — [genuine pros and cons]
Option 3: Move to managed container platform (ECS/Cloud Run) — [genuine pros and cons]

背景含糊不清

不佳：

Our current deployment process has some issues.

良好：

Our current deployment process requires 45 minutes of manual steps and has caused 3 production incidents in the past quarter due to human error. The team spends ~8 hours/week on deployment-related tasks.

缺少“不采取行动”选项

对于重大变更，始终将维持现状作为一个选项——这样可以促使大家客观评估是否确实需要采取行动。

没有决策标准（或在列出选项后才定义标准）

不佳：先展示选项，再列出标准——这会让人觉得标准是为了证明某个首选选项合理而刻意挑选的。

良好：在列出选项之前，先定义标准并注明权重。然后明确根据这些标准评估每个选项。建议部分应指出哪些标准促成了该决策。

隐藏或未说明的假设

不佳：

We'll migrate to the new system over 6 months.

良好：

Assumption: The team has 2 engineers available for migration work in Q3.
Confidence: Medium. Invalidated if Q3 headcount changes.

未说明的假设会成为看不见的定时炸弹。当 RFC 的结果在六个月后不再奏效时，没人能判断究竟是决策有误，还是某个隐藏的假设已不再成立。

---

输出摘要格式

生成 RFC 后：

RFC Created: "[Title]"

Impact: HIGH / MEDIUM / LOW
Status: NOT STARTED

Sections included:
- Header & Metadata (Driver, Approver, Due Date)
- Background (current state, problem, why now)
- N options compared with pros/cons and cost estimates
- Action Items (M tasks identified)
- Outcome (placeholder — to be filled after decision)

Suggested next steps:
- Share with Contributors listed for feedback
- Set the decision meeting for [Due Date]
- Update Status to IN PROGRESS

Would you like me to add anything else?

---

重要说明

• RFC 用于决策，而非实施——RFC 决策完成后，应创建 TDD 来制定实施计划
• 选项必须客观——片面的 RFC 会损害信任，并导致错误决策
• “不采取行动”始终是一个选项——有助于评估变更是否确实值得
• 结果部分事后填写——起草期间请保留为占位内容
• 语言适配——始终使用用户的语言撰写
• 尊重用户提供的上下文——如果用户提供了丰富的上下文，请据此撰写；不要重复询问已有信息
• 选项应简明——聚焦决策因素，而非实施细节
• RFC 会随时间过时——所有内容都应注明日期；脱离上下文的决策会让人困惑

可触发此技能的提示词示例

英语

• “为我们将数据库从 MySQL 迁移到 PostgreSQL 撰写一份 RFC”
• “我需要一份 RFC，提议从单体架构转向微服务”
• “针对我们的 on-call 轮值政策创建一份征求意见稿”
• “起草一份 RFC，对比可自托管的 Kafka 和托管式 Kafka”
• “我需要获得采用新设计系统的批准”

葡萄牙语

• “撰写一份迁移我们数据库的 RFC”
• “我需要一份 RFC，提议采用新工具”
• “针对我们的 on-call 政策创建一份征求意见稿”
• “我想记录更换云服务提供商的决策”

西班牙语

• “撰写一份将我们的基础设施迁移到云端的 RFC”
• “我需要一份 RFC，提议更改部署流程”
• “针对采用新框架创建一份征求意见稿”