RFC Mode
使用 RFC Mode 先完成设计、拆分子任务，再进入实现。
RFC Mode 是 North Coder 的内建 Agent profile，适合在写代码前先澄清需求、调研代码、记录设计决策，并把工作拆成可执行子任务。
它和普通会话最大的区别是：RFC Mode 会产出正式 RFC 文档，并把子任务状态写入结构化元数据，后续可以在 RFC View 中审阅和执行。
为什么用 RFC 而不是直接写代码
小需求可以让 Agent 直接实现。但面对"重构整个认证模块，支持 SSO 和 RBAC"这类任务，直接动手写代码往往导致设计遗漏、上下文丢失和结果不可预期。
RFC 机制借鉴了 Rust 等开源社区的长期实践——在实现大功能前先提出设计方案，经过审阅后再动工。这套流程同样适合人与 Agent 的协作：
📋 需求澄清 → 📐 设计文档 → 🔀 子任务拆解 → 🔨 逐个实现 → ✅ 质量验证相比直接让 Agent 写代码，RFC Mode 有四个关键优势：
- 多轮问答澄清需求：自然语言描述常常模糊或遗漏。RFC Mode 会先提问、确认边界，帮你把需求想清楚，再动手写设计文档。
- 合理的细节程度：RFC 只记录架构、接口设计、权衡取舍和验收标准，不写实现细节。既足够指导实现，又不会过度膨胀导致维护困难。
- 可审阅的设计界面：代码越来越难 Review，但 RFC 文档是人能读懂的设计方案。团队可以在实现前一起审阅 RFC，达成共识后再动工。
- 持续的项目记忆：RFC 文档沉淀在代码仓库里，Agent 可以快速获取高质量的设计上下文。代码中也会通过注释标记关联的 RFC 编号，形成双向索引。
什么时候使用
适合使用 RFC Mode：
- 新功能或跨模块改动。
- API、数据模型、权限、安全或部署相关变化。
- 需求还不清楚，需要先讨论设计选择。
- 需要拆成多个子任务并跟踪状态。
- 希望把“为什么这么做”留成可回看的设计记录。
不建议使用 RFC Mode：
- 单文件文案调整。
- 明确的小 bug 修复。
- 不需要设计取舍的机械改动。
- 只是想让 Agent 直接实现一个很小的任务。
基本流程
- 进入目标工作区。
- 在会话里选择
RFC ModeAgent profile。 - 描述问题、目标、约束和已知背景。
- RFC Mode 会先阅读代码并提出必要的澄清问题。
- 你确认关键设计选择后，RFC Mode 会生成 RFC。
- 聊天流中会出现 RFC 提案面板。
- 打开完整 RFC View，审阅元信息、子任务和正文。
- 对已就绪子任务点击执行，进入实现会话。
如果 RFC 还不满意，可以继续在同一个 RFC Mode 会话中给反馈，让 Agent 修改设计。
RFC 产物
RFC Mode 会生成两类文件：
| 文件 | 用途 |
|---|---|
docs/rfcs/NNNN-title.md | RFC 正文，记录背景、设计、权衡、验证计划和未决问题。 |
docs/rfcs/meta/NNNN-title.json | RFC 元信息和子任务状态，供 RFC View 和任务执行使用。 |
正文适合人阅读；JSON 元数据适合界面和 Agent 读写。日常使用时不需要手动编辑 JSON 状态。
RFC View
打开 RFC 文件时，North Coder 会优先显示 RFC View。它把 RFC 正文和元数据合并成一个可操作界面：
- 元信息卡片：状态、优先级、标签、日期等。
- 子任务表：任务 ID、标题、依赖、状态、Ref 和执行按钮。
- RFC 正文：完整设计内容。
- 搜索：可以搜索元信息、子任务和正文。
子任务状态包括：
| 状态 | 含义 |
|---|---|
pending | 等待执行。 |
in-progress | 正在执行或可继续执行。 |
implemented | 已完成。 |
blocked | 有未完成依赖，界面根据依赖自动推算。 |
执行子任务
在 RFC View 或聊天流里的 RFC 提案面板中，可以执行单个子任务，也可以执行所有已就绪任务。
执行前可以选择要使用的 Agent profile。启动后，North Coder 会创建或打开对应实现会话，并注入该子任务的范围、验收标准和状态更新要求。
实现完成后，Agent 应通过 update_rfc_task_status 工具更新任务状态。不要让 Agent 直接手改 docs/rfcs/meta/*.json 里的状态字段，因为工具会检查状态流转和依赖关系。
和 Plan Mode 的区别
| 模式 | 适合场景 | 产物 | 执行方式 |
|---|---|---|---|
| RFC Mode | 需要正式设计记录和任务拆分的功能 | docs/rfcs/*.md + docs/rfcs/meta/*.json | 从 RFC View 执行子任务 |
| Plan Mode | 需求基本明确，只想先探索并生成实现计划 | .north-coder/plans/*.md | Hand Off 或在当前会话继续 |
| General | 小任务或直接实现 | 代码改动和会话记录 | 当前会话直接执行 |
如果一个任务会影响长期架构或团队协作，优先使用 RFC Mode。如果只是想让 Agent 先看代码再列步骤，使用 Plan Mode 会更轻量。
写好 RFC Mode 任务
给 RFC Mode 的第一条消息建议包含：
- 背景：为什么要做这件事。
- 目标：希望用户或系统获得什么能力。
- 范围：哪些模块需要考虑，哪些不需要。
- 约束：兼容性、安全、性能、部署、UI 或时间限制。
- 验证：希望实现阶段如何证明完成。
示例：
我希望为文档站增加搜索分析能力。请先用 RFC Mode 调研现有 docs-site 搜索实现，
设计一个不引入后端服务的方案，明确数据采集边界、隐私约束和子任务拆分。审阅建议
批准 RFC 前，重点看：
- 背景和目标是否准确。
- 非目标是否排除了不该做的事。
- 设计决策是否说明了理由。
- 子任务是否能独立执行。
- 依赖关系是否合理。
- 验证计划是否能证明实现完成。
如果这些内容还不清楚，先让 RFC Mode 修改 RFC，再开始实现。