Skip to main content
PRD 转代码我用过 V0、Cursor、Copilot,真正要盯的是哪一步最容易出错,以及生成之后怎么验收。

Q1: PRD 到代码生成的演进历史

1

手动开发时代 (2010-2017)

前端工程师拿到 PRD 后,手动编写每一行代码。从需求理解、架构设计、UI 实现到测试,全部依赖人工。一个中等复杂度的页面需要数天开发周期,沟通成本占项目时间的相当大一部分。
2

低代码与可视化搭建 (2018-2020)

低代码平台(如宜搭、微搭)通过拖拽组件和配置属性生成代码。解决了简单表单和中后台页面的快速搭建,但灵活性不足——复杂交互和定制需求仍然需要手写代码。
3

AI 代码补全 (2021-2023)

GitHub Copilot 的出现改变了开发模式。AI 从”工具”变成了”副驾驶”——根据上下文自动补全代码行和函数。开发效率明显提升,但仍然需要开发者主导架构和流程。
4

对话式代码生成 (2024)

Cursor、Claude Code、Windsurf 等 AI-native IDE 兴起。开发者通过自然语言描述需求,AI 生成完整的文件和模块。从”补全”进化到”生成”,但仍然需要人工串联各个步骤。
5

端到端 PRD→Code (2025+)

V0、Bolt.new、Lovable、GitHub Copilot Workspace 等工具实现了从 PRD 到可部署代码的自动化管线。AI Agent 解析 PRD、生成架构、编写代码、生成测试、部署上线,开发者从”写代码”转变为”审代码”。
PRD→Code 解决的核心问题:
PRD→Code 的核心不是”让 AI 替代程序员”,而是”把开发流程从手工作坊升级为自动化管线”——开发者从写代码转变为审代码和定义规范。

没有 PRD→Code 工作流

产品经理写 PRD → 设计师出设计稿 → 前端看 PRD 理解需求 → 手写代码 → 手写测试 → 部署。每个环节都有信息损耗,PRD 理解偏差容易导致返工。一个中等页面从 PRD 到上线需要 1-2 周。

引入 PRD→Code 工作流

产品经理写 PRD → AI 解析 PRD 生成技术方案 → AI 生成代码和测试 → 开发者审查和调整 → 自动部署。信息在管线中无损流转,开发者聚焦在架构决策和质量把控上。同样的页面从 PRD 到上线缩短到 1-2 天。
传统开发就像手工作坊——师傅(开发者)拿到图纸(PRD),一锤一锤地敲出产品。PRD→Code 就像自动化工厂——图纸(PRD)送进流水线(AI 管线),机器自动切割(代码生成)、打磨(测试生成)、组装(部署),师傅只需要在最后检查质量(人工审查)。师傅不需要消失,但角色从”体力劳动者”变成了”质量管理者”。

Q2: PRD 到代码生成的完整流程

PRD→Code 的本质是一条自动化管线,核心逻辑只有 5 步:
AI 生成的代码质量已经很高,但仍然存在三个风险:
  • 幻觉风险:AI 可能编造不存在的 API 或使用已废弃的方法
  • 架构偏差:AI 对复杂业务逻辑的理解可能与实际需求有偏差
  • 安全漏洞:AI 可能生成存在 XSS、CSRF 等安全隐患的代码
人工审查不是”走形式”,而是管线中的质量关口。审查重点:架构合理性、业务逻辑正确性、安全合规性。
PRD→Code 的自动化程度就像自动驾驶的分级。L2(Copilot):AI 做辅助(补全代码),人主导。L3(Cursor):AI 做大部分工作(生成模块),人监督。L4(V0/Bolt):AI 做全流程(PRD→代码→测试),人在关键节点审查。L5(完全自主):AI 做全流程且不需要人——目前还不存在。大多数团队处在 L3-L4 阶段,核心瓶颈不是 AI 能力不够,而是信任不够——开发者还没有建立”审查 AI 代码”的工作习惯。

各阶段的工具链

管线中的数据流


Q3: PRD 解析与需求提取

PRD 解析的核心挑战是把非结构化的自然语言转化为结构化的需求描述。PRD 文档通常用自然语言写成,包含功能需求、非功能需求、业务规则、边界条件等信息,AI 需要从中提取出可执行的技术规格。
PRD 解析就像同声传译——把产品经理的”方言”(非结构化 PRD)翻译成开发者的”标准语”(结构化需求 JSON)。好的翻译不是逐字翻译,而是理解语义后用目标语言重新表达。AI 解析 PRD 也是一样——不是提取原文中的关键词,而是理解业务意图后生成结构化描述。如果 PRD 写”用户体验要好”,AI 需要翻译成”首屏加载 < 2s、交互响应 < 100ms”。

PRD 质量对输出的影响

PRD 的质量直接决定 AI 生成代码的质量——这就是”Garbage In, Garbage Out”原则。

Q4: 设计稿到代码

设计稿到代码(Design-to-Code)是 PRD→Code 管线中最直观的环节。核心原理是AI 读取设计稿的结构化数据(图层、样式、布局),映射为对应的前端代码。本文只把它当作管线中的一环;设计稿解析、Figma MCP、设计令牌与工具对比的完整内容见 Design to Code。
MCP(Model Context Protocol)是 Anthropic 提出的标准化协议;Figma MCP Server 基于该协议,让 AI Agent 能直接读取 Figma 文件的结构化数据——图层树、样式、布局约束、设计 Token。传统方式是截图让 AI 识别(信息损耗大),MCP 方式是直接读取设计数据(信息无损)。
  • 截图方式:AI 只能看到像素,无法精确获取间距、字号、颜色值
  • MCP 方式:AI 读取完整的图层树和样式数据,生成的代码与设计稿像素级一致
Figma 设计稿就像建筑蓝图——好看但不能直接用来施工。传统方式是施工队(开发者)看着蓝图手动砌墙(写代码),容易出现偏差。Figma MCP 就像把蓝图数字化——AI 读取每个房间的尺寸、门窗位置、材料规格(图层树和样式数据),自动生成施工图纸(前端代码)。从”看着蓝图猜尺寸”变成”读取精确数据自动生成”。

V0 的设计稿转代码原理

V0 是 Vercel 推出的 AI UI 生成工具,支持从文本描述或截图生成 React + Tailwind CSS 代码。它的核心能力是理解 UI 语义并映射为组件。

Locofy 与 Anima 的对比


Q5: 代码到测试

AI 生成测试的核心原理是分析代码的结构和行为,自动生成覆盖正常路径、边界条件和异常场景的测试用例。
AI 生成测试就像请了一个考试出题专家。你把课本(源代码)给他,他能自动出一套覆盖所有知识点的试卷。正常路径是”基础题”(大部分学生都能做对),边界条件是”陷阱题”(考验细心程度),异常场景是”超纲题”(考验应变能力)。好的出题专家不会只出基础题——他会覆盖所有知识点,包括容易被忽略的边界和异常。

AI 生成 E2E 测试

E2E(End-to-End)测试模拟真实用户的操作流程。AI 生成 E2E 测试的原理是分析页面的交互流程,自动生成 Playwright 测试脚本。

测试覆盖率分析

AI 不仅能生成测试,还能分析测试覆盖率并补充缺失的测试用例。

Q6: 端到端工作流实现

端到端 PRD→Code 工作流的实现需要选择合适的工具链并建立标准化的流程。
工具链选择的核心原则:每个环节用最擅长的工具。
  • PRD 解析:Claude(长上下文理解能力强,200K tokens 窗口)
  • 设计稿生成:V0(React + Tailwind 生态最成熟)
  • 代码生成:Cursor(IDE 集成度最高,支持 @codebase 上下文)
  • 测试生成:Qodo / GitHub Copilot(测试生成专用优化)
  • 部署:Vercel(与 V0 生态无缝集成)
不要试图用一个工具完成所有环节——每个工具都有自己的优势领域。

工具链选择矩阵


Q7: 底层源码——AI Agent 如何编排 PRD→Code 管线

AI Agent 使用 LangGraph 的图结构来编排多步骤管线。每个节点是一个独立的任务(PRD 解析、代码生成、测试生成),边定义了数据流转关系(详见 LangGraph 文档):
这段代码做了 3 件事:1) 用 StateGraph 定义管线的状态和节点;2) 每个节点调用 LLM 完成特定任务;3) human_review 节点暂停管线等待人工反馈,实现 Human-in-the-Loop。

满分回答 vs 及格回答

问题:“说说 PRD 到代码生成的完整流程和你的实践经验”

及格回答(60-70分):
“PRD 到代码就是用 AI 工具把需求文档变成代码。可以用 V0 生成 UI,用 Cursor 写逻辑,用 Copilot 写测试。”
问题出在:知道工具但不理解流程设计。 满分回答(90-100分):
“PRD 到代码的核心不是’用哪个工具’,而是设计一条可靠的自动化管线。管线有 5 个阶段:PRD 解析、架构设计、代码生成、测试生成、部署。每个阶段用最擅长的工具——Claude 解析 PRD(长上下文理解能力强),V0 生成 UI(React + Tailwind 生态成熟),Cursor 生成业务逻辑(IDE 集成度最高),Qodo 生成测试(测试生成专用优化)。[1]”
“管线中最关键的设计决策是在哪里加入人工审查。我的实践经验是:PRD 解析后必须人工确认需求理解是否正确(否则后续全部白费),代码生成后必须人工审查架构合理性(AI 对复杂业务逻辑的理解可能有偏差),测试生成后可以自动化运行(覆盖率 > 80% 即可)。人工审查不是’走形式’,而是管线中的质量关口。[2]”
“实际项目中最大的挑战不是 AI 能力不够,而是PRD 质量太低。Garbage In, Garbage Out——如果 PRD 写’做一个购物车’,AI 只能生成一个最基本的骨架。如果 PRD 写清楚了功能清单、验收条件、边界情况、性能要求,AI 生成的代码质量能直接达到生产级。所以我的做法是在 PRD 模板中加入结构化字段(功能列表、验收条件、非功能需求),确保输入质量。[3]“

常见追问

题目来源于真实面经(字节/腾讯/阿里前端面试、牛客网、haizlin/fe-interview),按难度递进。每个模块 8 个 Accordion,覆盖 4 个难度层级。
答题要点: 说出 5 个阶段和每个阶段的工具选择。高分回答: “PRD 到代码的核心流程有 5 个阶段:
  1. PRD 解析:用 Claude 或 GPT-4 从 PRD 文档中提取结构化需求(功能列表、验收条件、API 契约)。关键是用 JSON Schema 约束输出格式,确保下游能消费。
  2. 架构设计:AI 根据结构化需求生成技术方案(组件树、状态管理、路由设计)。这一步需要人工审查——AI 对复杂业务逻辑的理解可能有偏差。
  3. 代码生成:用 V0 生成 UI 组件(React + Tailwind),用 Cursor 生成业务逻辑。V0 擅长视觉还原,Cursor 擅长代码逻辑。
  4. 测试生成:用 Qodo 或 Copilot 生成 Jest 单元测试和 Playwright E2E 测试。AI 分析代码结构后自动生成覆盖正常路径、边界条件、异常场景的测试用例。
  5. 部署:通过 GitHub Actions 或 Vercel 自动化 CI/CD。
每个阶段之间有人工审查节点——PRD 解析后确认需求理解,代码生成后审查架构,测试生成后验证覆盖率。”
答题要点: 解释 MCP 协议的原理和 Figma MCP 的数据流。高分回答: “MCP(Model Context Protocol)是 Anthropic 提出的标准化协议,Figma MCP Server 基于它让 AI Agent 直接读取 Figma 文件的结构化数据。工作原理:
  1. Figma MCP Server 作为中间层,连接 Figma API 和 AI Agent
  2. AI Agent 通过 MCP 协议调用 Figma Server 的工具(如 getFile、getNode)
  3. Figma Server 返回结构化数据(图层树、样式、布局约束、设计 Token)
  4. AI 根据结构化数据生成代码
与传统截图方式的区别:截图只能让 AI 看到像素(信息损耗大),MCP 让 AI 读取完整的图层树和样式数据(信息无损)。生成的代码与设计稿能实现像素级一致。MCP 的价值不只是 Figma——它是通用协议。同样的 MCP 架构可以接入 GitHub(读取 issue 生成代码)、Jira(读取任务生成需求)、Linear(读取 ticket 生成测试)。”
答题要点: 从输入质量、审查机制、测试覆盖三个维度回答。高分回答: “保证 AI 生成代码质量有三个维度:
  1. 输入质量(Garbage In, Garbage Out):PRD 的质量直接决定代码质量。在 PRD 模板中加入结构化字段——功能列表、验收条件、边界情况、非功能需求。模糊的’做一个购物车’和详细的’购物车需求:数量修改不能超过库存,空车展示引导页’,AI 生成的代码质量天差地别。
  2. 审查机制:在管线中加入人工审查节点。PRD 解析后确认需求理解是否正确,代码生成后审查架构合理性和安全合规性。审查清单包括:是否有 XSS 风险、是否处理了空状态、是否有无障碍支持。
  3. 测试覆盖:AI 生成测试后,检查覆盖率报告。行覆盖率 > 80%,分支覆盖率 > 70%,关键边界 100% 覆盖。覆盖率不达标时让 AI 补充缺失的测试用例。
三者缺一不可——好的输入 + 严格的审查 + 充分的测试 = 高质量的 AI 代码。”
答题要点: 对比效率、覆盖率、维护成本三个维度。高分回答: “AI 生成测试和手写测试的核心区别:效率:AI 生成测试的速度远高于手写。一个中等规模的组件,手写测试需要数小时,AI 生成往往只需几分钟。覆盖率:AI 擅长覆盖边界条件和异常场景——开发者手写测试时容易忽略的’数量为 0’、‘API 超时’、‘空数组’等边界,AI 都能自动识别并生成测试。维护成本:AI 生成的测试需要人工审查。常见问题:Mock 过度(测试通过但没测到真实逻辑)、断言太弱(只检查元素存在不检查内容)、测试命名不清晰。审查后调整的成本通常 < 原始生成成本的 20%。最佳实践:AI 生成 + 人工审查。让 AI 做’体力活’(生成大量测试用例),人做’脑力活’(审查测试质量、补充业务逻辑测试)。”
答题要点: 从实际踩坑经验出发,说出 3 个典型问题和解决方案。高分回答: “实际项目中的三个典型问题:
  1. PRD 理解偏差:AI 对’用户友好’这种模糊描述的理解和产品经理不一致。解决方案:在 PRD 模板中用结构化字段替代模糊描述——‘用户友好’改为’首屏加载 < 2s、交互响应 < 100ms、空状态有引导’。
  2. 架构决策不合理:AI 生成的代码可能用了过时的模式(如 class 组件)或不适合项目的技术选型。解决方案:在 System Prompt 中明确技术约束——‘使用 React 18 函数组件 + Hooks,状态管理用 Zustand,样式用 Tailwind CSS’。
  3. 生成的代码不一致:多次生成的代码风格不统一(命名规范、文件结构、错误处理方式)。解决方案:建立项目级的 CLAUDE.md 文件,定义代码规范、文件结构、命名约定,让 AI 在生成时遵循统一标准。”
答题要点: 根据项目类型和团队规模给出选择建议。高分回答: “工具链选择取决于三个因素:项目类型、团队规模、质量要求。快速原型验证(个人/小团队):V0 + Vercel。从描述到部署最快(分钟级),适合验证想法、做 Demo。缺点是代码质量中等,不适合生产环境。企业级项目(中大团队):Cursor + Claude Code + Playwright。代码质量和测试覆盖率最高,支持 @codebase 上下文理解整个项目。缺点是学习成本高,需要建立 CLAUDE.md 规范。设计驱动开发(设计团队主导):Figma MCP + Claude Code。设计稿到代码精度最高,像素级还原。缺点是依赖 Figma,设计师需要学习 MCP 配置。全栈项目(前后端一体):Bolt.new / Lovable。前后端一体化生成,适合全栈开发者。缺点是灵活性不足,复杂定制需要手动调整。核心原则:每个环节用最擅长的工具,不要试图用一个工具完成所有环节。”
答题要点: 从灵活性、代码质量、可维护性三个维度对比。高分回答: “表面上看,PRD→Code 和低代码都是’自动生成代码’,但本质区别很大:灵活性:低代码平台只能生成平台支持的组件和逻辑,超出平台能力的需求无法实现。PRD→Code 生成的是标准代码(React/Vue/TypeScript),没有平台锁定,任何需求都能实现。代码质量:低代码生成的代码通常是平台私有格式(JSON Schema),不可读、不可维护。PRD→Code 生成的是标准开源代码,可读、可维护、可版本控制。可维护性:低代码平台的代码和平台绑定——平台升级可能导致不兼容,平台停服则代码报废。PRD→Code 生成的代码完全独立,不依赖任何平台。适用场景:低代码适合简单的表单和中后台页面(80% 的标准场景)。PRD→Code 适合所有场景,特别是复杂交互和定制需求。反面证据:低代码平台的’低代码’是相对的——复杂需求仍然需要写大量配置代码,配置代码的学习成本不比写代码低。PRD→Code 的优势是’生成标准代码’,开发者不需要学习任何新工具。”
答题要点: 从多 Agent 协作、自主调试、持续学习三个方向回答。高分回答: “PRD→Code 的未来趋势有三个方向:
  1. 多 Agent 协作:不再是单个 AI 完成所有工作,而是多个专业 Agent 分工协作——架构 Agent 设计方案、前端 Agent 写 UI 代码、测试 Agent 生成测试、DevOps Agent 配置部署。每个 Agent 专注自己的领域,通过 LangGraph 编排协作。
  2. 自主调试:当前的 PRD→Code 管线是’生成 → 人审查 → 修复’的循环。未来的趋势是 AI 自主运行测试、分析失败原因、自动修复代码、重新测试——直到所有测试通过。Devin 和 Claude Code 已经在探索这个方向。
  3. 持续学习:AI 从项目的代码审查反馈中学习——哪些模式被接受、哪些被拒绝、团队的编码风格偏好。随着项目积累,AI 生成的代码越来越符合团队标准。CLAUDE.md 和 AGENT.md 就是这个方向的早期形态。
终极愿景:PRD→Code 从’L4(AI 做全流程,人审查)‘进化到’L5(AI 做全流程,不需要人)‘。但这需要 AI 在架构决策、安全审查、业务理解上达到人类专家水平——短期内不太可能。“

延伸阅读与引用参考

  • Vercel V0 官方文档:V0 是 Vercel 推出的 AI UI 生成工具,从文本描述生成 React + Tailwind CSS 生产级代码。[1]
  • Figma 帮助中心:Figma 官方文档入口,可查阅 Dev Mode MCP Server 的配置说明。[2]
  • LangGraph 文档:LangChain 的图结构多 Agent 编排框架,PRD→Code 管线的底层编排引擎。[3]
  • Anthropic Claude Code 文档:Claude Code 的完整文档,覆盖 MCP、Skills、Hooks 等企业级特性。[4]
  • GitHub Copilot Workspace 文档:GitHub 的 PRD→Code 工具,从 issue/spec 自动生成代码实现。[5]
  • Andrej Karpathy - Vibe Coding:Andrej Karpathy 提出的 Vibe Coding 概念——用自然语言描述需求,AI 生成代码。[6]
  • Cursor 官方文档:Cursor AI 代码编辑器的使用指南,@codebase 上下文和 Agent 模式。[7]
  • Anthropic MCP 规范:Model Context Protocol 的官方规范,标准化 AI 与外部工具的连接协议。[8]
  • Qodo (原 CodiumAI) 文档:AI 驱动的测试生成工具,自动生成 Jest/Playwright 测试用例。
  • Bolt.new 文档:StackBlitz 推出的全栈 AI 代码生成工具,从描述到可运行应用。
  • Lovable 文档:原 GPT Engineer,PRD 到全栈应用的自动化管线。