让 AI 先写技术方案：RFC 草稿生成的模板与约束
在许多敏捷开发团队中，工程师往往面临一个两难选择：
- 要么在动工前花整整两天时间手写几十页的前端技术方案（RFC / Technical Design Document），把路由设计、Store 状态树、接口契约、组件拆分事无巨细列出来，结果导致业务交付排期被严重拉长；
- 要么干脆省略技术方案，产品一给 PRD 就直接开撸代码，结果中途发现接口字段不兼容、组件无法复用、状态流转混乱，导致反复推倒重构。
最优雅的工程化解法是：让大模型充当前端技术方案的“第一作者”。
通过向 AI 喂入当前代码库的架构目录结构、公共组件清单以及结构化需求，让其在 1 分钟内自动生成一份高质量的前端 RFC 草稿。工程师只需花 15 分钟在此基础上进行二次审阅与边界微调，即可快速完成方案对齐与动工。
为什么让 AI 写 RFC 比直接让 AI 写代码更稳健？
在前端研发流中，技术方案（RFC）处于架构决策的最高层。将 AI 的插桩点从“直接生成业务代码”前置到“生成技术方案草稿”，有三大确定性优势：
- 全局拓扑把控：技术方案强迫大模型先在抽象层面思考“模块之间的调用关系、状态流转路径和异常兜底”，而不是一上来就陷入具体的 CSS 样式细节中。
- 极低的审查与纠错成本：Review 一份包含 6 个小节的技术方案，比 Review 上千行充满语法噪音的代码要快得多。如果方案方向跑偏（例如选用了错误的状态管理模式），在 RFC 阶段就能一秒纠正。
- 驱动下游自动化生成：一旦这份 RFC 经过人工审核确认，它就成为了唯一的“黄金架构约束”，后续可以拿着这份 RFC 直接生成符合规范的单测用例与组件脚手架。
前端标准化 RFC 模板约束定义
为了防止 AI 自由发挥写出空洞的假大空套话，必须在 System Prompt 中强制注入标准化的前端 RFC Markdown 结构模板：
# [RFC] {功能名称} 前端架构设计方案 ## 1. 业务背景与变更范围（Scope） - 涉及页面路由（新增/改造）: - 影响的公共底层模块: ## 2. 状态机与数据流设计（State Architecture） - Store 选型（Pinia / Zustand / 局部 State）: - 核心 State 数据模型定义（TypeScript Interface）: - 派生 Getters / Computed 清单: - 异步 Actions 时序与防重入机制: ## 3. 组件树层级与职责拆分（Component Breakdown） - 容器组件（Smart Container）: - 展示型纯组件（Dumb UI）: - 依赖的公共基础组件（如 ProTable, AmountInput）: ## 4. 后端 API 契约与 Mock 数据（API Contracts） - 依赖接口列表（Method, URL, 关键入参，响应体结构）: - 接口异常处理与状态码拦截策略: ## 5. 性能与风险防线（Performance & Risk Budget） - 首屏渲染预算（是否需要虚拟列表、动态导入、懒加载）: - 内存与副作用管理（监听器、定时器销毁声明）: - 回滚与降级预案:实战约束：如何向 Prompt 注入工程上下文
给模型喂 Prompt 时，最关键的是提供受限的代码库先验知识。
// scripts/generate-rfc.ts import { generateLlmCompletion } from './llm-client'; export async function generateFrontEndRfc(prdText: string): Promise<string> { const systemPrompt = ` 你是一位严谨的前端架构师（技术洁癖型）。 请根据输入的 PRD 文档，为本仓库生成一份前端技术方案草稿。 【当前工程技术栈约束】 1. 框架: Vue 3.4+ (SFC <script setup lang="ts">) + Vite 5 + Pinia 2. 2. 基础组件库: packages/components (严禁手写原生 table/input，优先使用 ProTable/ProForm). 3. 工具库: 统一使用 dayjs (严禁 moment), lodash-es (严禁全量 lodash). 4. 路由规范: views/ 下按业务域分目录，每个域独立 index.ts 导出路由配置. 【生成纪律】 - 必须严格填充【前端标准化 RFC 模板】中的全部 5 个小节。 - 每一个 State 和 API 契约必须给出严格的 TypeScript 类型定义代码块。 - 严禁空洞的形容词，所有设计必须具体到文件路径与函数名。 `; return generateLlmCompletion({ system: systemPrompt, user: `PRD 需求内容如下：\n${prdText}`, }); }落地效果对比：从手写到 AI 预研
我们在一个 20 人的前端业务大组中推广了该机制，跟踪了 40 个真实需求的交付数据：
| 评估维度 | 传统纯手写 RFC 模式 | AI 生成草稿 + 人工确认模式 | 提升幅度 |
|---|---|---|---|
| 方案编写平均耗时 | 6.5 小时 | 0.8 小时（48 分钟） | 效率提升 87% |
| 方案规范完整度 | 68%（常漏写异常兜底与单测） | 96%（模板硬性约束） | 质量大幅提升 |
| 代码返工率 | 18.2% | 4.5% | 返工减少 75% |
生产避坑守则
- 严禁 AI 擅自引入未在仓库 package.json 中的第三方库：在 Prompt 中明确声明“白名单依赖机制”，如果 AI 建议引入新的 npm 包，必须单独在方案中开辟一个“三方库引入审批申请”小节并说明体积增量。
- 状态模型先行：技术方案中最核心的是 TypeScript 接口定义。只要 TS 类型把控精准，下游无论谁来写业务代码，都不会出现低级的字段取值错误。
