Cursor x PM：产品经理的 AI 原型设计工作流

Cursor x PM：产品经理的 AI 原型设计工作流 Cursor x PM：产品经理的 AI 原型设计工作流 Modified August 10, 2025 😶 上下文取舍 1. 选择一直在一个对话框对话，AI 了解你的设计理念，之前的开发代码，会做出更好的选择。但随着上下文增长，token 和成本都在燃烧，且到最后会很卡，反应也很慢，甚至 AI 会神志不清。 2. 选择新的对话，AI 立刻就不知道你的所有上下文了，都是从头开始。你能相信一个新招来的员工上手老项目吗？ 如何解决上下文问题呢？ 1. 通过 设计统一性 来解决上下文丢失的问题。本身，产品在探索原型时，所需要的技术和代码上下文就不多，因此除了产品、UI 设计、技术架构等文档以外，应该都不需要额外的上下文了。就算重新做也是能应付过来的。 2. 在和 Cursor 对话时，不给定任何的代码文件上下文，每次制定让 AI 修改“xxx”页面“xxx 模块”的什么内容，这些内容 AI 可以通过文本搜索直接定位到原型位置进行修改。 3. 每次设计完一整个模块，直接另起新对话。这样既能保持一定的脑力，也能保障性、速度、成本。 实战指南：四步启动你的 AI 原型项目 第零步：环境与规则设定 (Setup) 1. 配置 Project Rules：将前文提到的 MVP 开发提示词 和 UI与技术方案规范规则 添加到 Cursor 的项目规则中。这是整个工作流的基石。 2. 简化模式：建议产品经理使用无脑 Agent 模式，将技术细节交给 AI。遇到开发问题，优先让 AI 自行解决或更换模型，而不是手动调试。 3. 模型选择策略： ◦ 常规开发：使用 Claude 3 Sonnet 或 GPT 4o，性价比高。 ◦ 复杂任务/首次生成：当首次根据 PRD 生成复杂模块时，可使用 Claude 3 Opus 或 GPT 4，并开启“思考模式”让 AI 规划更周全。 ◦ Bug 修复：当一个模型卡住时，切换到另一个模型（如 Claude 换 Gemini）往往有奇效。 第一步：技术架构设计 项目的架构设计，作为产品经理，很难完美的了解什么样的技术栈，是最适合快速做前端原型的技术。 因此，技术原型的架构可以完全交给 AI 去设计。假如说，咱们的产品原型主要是为了做一个 Web 端使用的数据产品，就可以直接去问 AI 这个结果。当然，我已经问过的结果为： Code block Markdown 🔧 技术栈 前端框架 : Next.js 14/15 (React 18/19) 开发语言 : TypeScript 样式方案 : Tailwind CSS 图标库 : Lucide React 构建工具 : Next.js内置 (支持 Turbopack) 代码规范 : ESLint 除了技术栈的设计，最好也把文件夹的框架也提前告知。 Code block Python event tracking mvp/ ├── src/ 主应用源码 │ ├── app/ Next.js App Router 页面 │ ├── components/ React 组件 │ ├── types/ TypeScript 类型定义 │ ├── data/ 模拟数据 │ └── utils/ 工具函数 ├── event tracker/ 演示应用（独立的埋点收集演示） ├── prd/ 产品需求文档 ├── package.json 主应用依赖配置 └── README.md 项目说明 第二步：UI 设计 UI 设计作为单独的一个部分，需要单独尝试。尝试后，建设统一的 UI 文档，后续所有的内容如果有不符合的直接看文档解决。 由于我本人对 UI、UX，没有特别大的建树。唯一有的是一点审美。因此我会按照下述方案让 cursor 把 UI 方案生成好。 1. demo 页面：让 Cursor 先生成一个 demo 页面，包含 cursor 常用的数据产品元素（筛选、导航、按钮、表、分页等等），以及我想要的所有元素。 2. 场景原则：告诉 Cursor 场景和原则（专业性、大厂内部） 3. 网站模拟：给 Cursor 一些可以模拟的网站，如 youtube、snowflake 等风格；有特定的喜欢的风格也可以让 cursor 去看网站截图去识别。有一些专门的设计网站，会有风格设计，截图给到 Cursor 会更有效。 4. 文档存储：最终让 cursor 生成你满意的 UI 后，存到 UI 设计方案中，以供后续参考和使用。 这部分属于一次性探索过程，其提示词不追求固定的复用性。 第三步：核心 PRD 编写 (Obsidian 协同) 在项目中建立 prd/ 文件夹，用于存放所有核心功能的 Markdown 文档。 😶 为什么不用 Cursor 直接写 PRD？ Cursor 内置的编辑器对于长文本和富文本格式的编辑体验不佳。因此，我们推荐使用专业的 Markdown 笔记工具来管理需求文档。 最佳实践：Obsidian + Cursor 使用 Obsidian 打开项目文件夹，可以实现完美的“左手 PRD，右手 Code”工作流。 • 左边 Obsidian：实时编辑和迭代 PRD，利用其强大的 Markdown 编辑和组织能力。 • 右边 Cursor：AI 读取 prd/ 文件夹中的文档进行开发。 这种方式保证了需求文档的规范性和可维护性，也方便 AI 精准定位需求。 第四步：疯狂迭代 当 cursor 在阅读你的 prd 后，形成了第一版原型后，别担心，一定不是你想要的。 之后进入疯狂迭代模式，考验的是你的打字速度的时刻了。 1. review 原型 2. 发现问题 3. cursor 窗口直接把截图 + 问题描述 + 修改建议 + 限制，发上去 我们的方案是：看到一个问题发一个，看到一个发一个。cursor 会把未解决的需求，放到 pending 区域，之后会一直自己解决问题。 有一个功能叫 Queued Messages，这简直是产品的福音，无限需求模式开启……😅 总结与展望 重新定义原型：从静态草图到动态的“活文档” 这个工作流的真正价值，是它重新定义了“原型”在产品开发中的角色。我们不再需要经历线框图、高保真设计稿等多个静态阶段，而是跳过草图，直接生成一个无限逼近 Alpha Prototype 的、可交互的动态产物。 这个“活文档”有两个核心价值： 1. 向下游（研发）赋能：它为研发团队提供了最直观、无歧义的需求说明。工程师可以通过直接操作来理解功能逻辑和交互细节，极大降低了沟通成本，让后续的正式开发更顺畅。 2. 向上游（PRD）反哺：静态的 PRD 文档总有考虑不周之处。通过与原型互动，产品经理能发现那些在文档中难以察觉的逻辑断点和体验缺陷。这个发现过程会反过来驱动 PRD 的迭代和完善，最终产出一份经过了实际检验、质量更高的需求文档。 最终，我们交付给研发的，不仅仅是一份 PRD，而是一个 “PRD + 可交互原型”的组合，这才是对需求最精准的描述。 适用场景与局限性 非常适合： • 产品探索阶段：需要快速验证大量想法的 0 到 1 过程。 • 内部 Demo：向团队或老板展示项目愿景和核心功能。 • 无开发资源：产品经理需要独立完成原型设计。 • 数据可视化产品：前端交互相对固定，适合 AI 生成。 可能不适合： • 生产级项目：对代码质量、性能、安全性有严格要求的项目。 • 复杂交互/动画：需要精细调试的复杂前端交互。 • 需要深度优化的项目：AI 生成的代码通常不是最优解。 对团队的价值 • 加速创新：将产品团队的创意快速转化为可感知的原型，极大缩短了从想法到验证的周期。 • 降低沟通成本：一个可交互的原型，胜过千言万语的 PRD。它能让研发、设计、业务方对需求的理解更直观、更一致。 • 解放研发资源：让研发团队能更专注于生产环境的架构和开发，而不是被频繁变更的原型需求所困扰。 最终工作流 这套工作流将原型开发分为了三个核心阶段：准备、初始设计、核心迭代。它整合了从宏观创意到微观代码执行的全过程。 😶 上下文取舍 1. 选择一直在一个对话框对话，AI 了解你的设计理念，之前的开发代码，会做出更好的选择。但随着上下文增长，token 和成本都在燃烧，且到最后会很卡，反应也很慢，甚至 AI 会神志不清。 2. 选择新的对话，AI 立刻就不知道你的所有上下文了，都是从头开始。你能相信一个新招来的员工上手老项目吗？ 上下文取舍 1. 选择一直在一个对话框对话，AI 了解你的设计理念，之前的开发代码，会做出更好的选择。但随着上下文增长，token 和成本都在燃烧，且到最后会很卡，反应也很慢，甚至 AI 会神志不清。 2. 选择新的对话，AI 立刻就不知道你的所有上下文了，都是从头开始。你能相信一个新招来的员工上手老项目吗？ 如何解决上下文问题呢？ 1. 通过 设计统一性 来解决上下文丢失的问题。本身，产品在探索原型时，所需要的技术和代码上下文就不多，因此除了产品、UI 设计、技术架构等文档以外，应该都不需要额外的上下文了。就算重新做也是能应付过来的。 2. 在和 Cursor 对话时，不给定任何的代码文件上下文，每次制定让 AI 修改“xxx”页面“xxx 模块”的什么内容，这些内容 AI 可以通过文本搜索直接定位到原型位置进行修改。 3. 每次设计完一整个模块，直接另起新对话。这样既能保持一定的脑力，也能保障性、速度、成本。 实战指南：四步启动你的 AI 原型项目 第零步：环境与规则设定 (Setup) 第零步：环境与规则设定 (Setup) 1. 配置 Project Rules：将前文提到的 MVP 开发提示词 和 UI与技术方案规范规则 添加到 Cursor 的项目规则中。这是整个工作流的基石。 2. 简化模式：建议产品经理使用无脑 Agent 模式，将技术细节交给 AI。遇到开发问题，优先让 AI 自行解决或更换模型，而不是手动调试。 3. 模型选择策略： ◦ 常规开发：使用 Claude 3 Sonnet 或 GPT 4o，性价比高。 ◦ 复杂任务/首次生成：当首次根据 PRD 生成复杂模块时，可使用 Claude 3 Opus 或 GPT 4，并开启“思考模式”让 AI 规划更周全。 ◦ Bug 修复：当一个模型卡住时，切换到另一个模型（如 Claude 换 Gemini）往往有奇效。 ◦ 常规开发：使用 Claude 3 Sonnet 或 GPT 4o，性价比高。 ◦ 复杂任务/首次生成：当首次根据 PRD 生成复杂模块时，可使用 Claude 3 Opus 或 GPT 4，并开启“思考模式”让 AI 规划更周全。 ◦ Bug 修复：当一个模型卡住时，切换到另一个模型（如 Claude 换 Gemini）往往有奇效。 第一步：技术架构设计 第一步：技术架构设计 项目的架构设计，作为产品经理，很难完美的了解什么样的技术栈，是最适合快速做前端原型的技术。 因此，技术原型的架构可以完全交给 AI 去设计。假如说，咱们的产品原型主要是为了做一个 Web 端使用的数据产品，就可以直接去问 AI 这个结果。当然，我已经问过的结果为： 除了技术栈的设计，最好也把文件夹的框架也提前告知。 第二步：UI 设计 第二步：UI 设计 UI 设计作为单独的一个部分，需要单独尝试。尝试后，建设统一的 UI 文档，后续所有的内容如果有不符合的直接看文档解决。 由于我本人对 UI、UX，没有特别大的建树。唯一有的是一点审美。因此我会按照下述方案让 cursor 把 UI 方案生成好。 1. demo 页面：让 Cursor 先生成一个 demo 页面，包含 cursor 常用的数据产品元素（筛选、导航、按钮、表、分页等等），以及我想要的所有元素。 2. 场景原则：告诉 Cursor 场景和原则（专业性、大厂内部） 3. 网站模拟：给 Cursor 一些可以模拟的网站，如 youtube、snowflake 等风格；有特定的喜欢的风格也可以让 cursor 去看网站截图去识别。有一些专门的设计网站，会有风格设计，截图给到 Cursor 会更有效。 4. 文档存储：最终让 cursor 生成你满意的 UI 后，存到 UI 设计方案中，以供后续参考和使用。 这部分属于一次性探索过程，其提示词不追求固定的复用性。 第三步：核心 PRD 编写 (Obsidian 协同) 第三步：核心 PRD 编写 (Obsidian 协同) 在项目中建立 prd/ 文件夹，用于存放所有核心功能的 Markdown 文档。 😶 为什么不用 Cursor 直接写 PRD？ Cursor 内置的编辑器对于长文本和富文本格式的编辑体验不佳。因此，我们推荐使用专业的 Markdown 笔记工具来管理需求文档。 为什么不用 Cursor 直接写 PRD？ Cursor 内置的编辑器对于长文本和富文本格式的编辑体验不佳。因此，我们推荐使用专业的 Markdown 笔记工具来管理需求文档。 最佳实践：Obsidian + Cursor 使用 Obsidian 打开项目文件夹，可以实现完美的“左手 PRD，右手 Code”工作流。 • 左边 Obsidian：实时编辑和迭代 PRD，利用其强大的 Markdown 编辑和组织能力。 • 右边 Cursor：AI 读取 prd/ 文件夹中的文档进行开发。 这种方式保证了需求文档的规范性和可维护性，也方便 AI 精准定位需求。 第四步：疯狂迭代 第四步：疯狂迭代 当 cursor 在阅读你的 prd 后，形成了第一版原型后，别担心，一定不是你想要的。 之后进入疯狂迭代模式，考验的是你的打字速度的时刻了。 1. review 原型 2. 发现问题 3. cursor 窗口直接把截图 + 问题描述 + 修改建议 + 限制，发上去 我们的方案是：看到一个问题发一个，看到一个发一个。cursor 会把未解决的需求，放到 pending 区域，之后会一直自己解决问题。 有一个功能叫 Queued Messages，这简直是产品的福音，无限需求模式开启……😅 总结与展望 重新定义原型：从静态草图到动态的“活文档” 重新定义原型：从静态草图到动态的“活文档” 这个工作流的真正价值，是它重新定义了“原型”在产品开发中的角色。我们不再需要经历线框图、高保真设计稿等多个静态阶段，而是跳过草图，直接生成一个无限逼近 Alpha Prototype 的、可交互的动态产物。 这个“活文档”有两个核心价值： 1. 向下游（研发）赋能：它为研发团队提供了最直观、无歧义的需求说明。工程师可以通过直接操作来理解功能逻辑和交互细节，极大降低了沟通成本，让后续的正式开发更顺畅。 2. 向上游（PRD）反哺：静态的 PRD 文档总有考虑不周之处。通过与原型互动，产品经理能发现那些在文档中难以察觉的逻辑断点和体验缺陷。这个发现过程会反过来驱动 PRD 的迭代和完善，最终产出一份经过了实际检验、质量更高的需求文档。 最终，我们交付给研发的，不仅仅是一份 PRD，而是一个 “PRD + 可交互原型”的组合，这才是对需求最精准的描述。 适用场景与局限性 适用场景与局限性 非常适合： • 产品探索阶段：需要快速验证大量想法的 0 到 1 过程。 • 内部 Demo：向团队或老板展示项目愿景和核心功能。 • 无开发资源：产品经理需要独立完成原型设计。 • 数据可视化产品：前端交互相对固定，适合 AI 生成。 可能不适合： • 生产级项目：对代码质量、性能、安全性有严格要求的项目。 • 复杂交互/动画：需要精细调试的复杂前端交互。 • 需要深度优化的项目：AI 生成的代码通常不是最优解。 对团队的价值 对团队的价值 • 加速创新：将产品团队的创意快速转化为可感知的原型，极大缩短了从想法到验证的周期。 • 降低沟通成本：一个可交互的原型，胜过千言万语的 PRD。它能让研发、设计、业务方对需求的理解更直观、更一致。 • 解放研发资源：让研发团队能更专注于生产环境的架构和开发，而不是被频繁变更的原型需求所困扰。 最终工作流 最终工作流 这套工作流将原型开发分为了三个核心阶段：准备、初始设计、核心迭代。它整合了从宏观创意到微观代码执行的全过程。 🔗 原文链接： https://mp.weixin.qq.com/s/80lW2tva... https://mp.weixin.qq.com/s/80lW2tva... 原创 燕子石 子时说2025年08月08日 22:13 北京 写在前面：本文旨在分享一套利用 AI Copilot (Cursor) 赋能产品经理、加速原型产出的工作流。它旨在优化传统的原型设计流程，实现从想法 (Idea) 到可交互原型 (Prototype) 的极速转化，从而让团队能更早地验证想法、对齐目标。 写在前面：本文旨在分享一套利用 AI Copilot (Cursor) 赋能产品经理、加速原型产出的工作流。它旨在优化传统的原型设计流程，实现从想法 (Idea) 到可交互原型 (Prototype) 的极速转化，从而让团队能更早地验证想法、对齐目标。 文章摘要 • 核心理念：拥抱“Vibe Coding”，将 AI 作为黑盒，通过高频反馈和明确的规则约束，实现敏捷、低成本的原型开发。 • 解决什么问题：解决产品经理在原型阶段需求多变、探索性强，但又缺乏开发资源和技术深度的痛点。 • 核心方法： a. 设定规则 (Project Rules)：通过为 Cursor 设定 MVP 开发原则、UI/技术规范，强制 AI 聚焦核心需求，避免过度设计。 b. 管理上下文：通过模块化开发、开启新对话、文档化（PRD、UI 规范）等方式，解决 LLM 上下文过长导致的性能下降和“失忆”问题。 c. 工具协同：使用 Obsidian 管理 PRD 文档，与 Cursor 开发环境无缝衔接，实现需求与开发同步。 a. 设定规则 (Project Rules)：通过为 Cursor 设定 MVP 开发原则、UI/技术规范，强制 AI 聚焦核心需求，避免过度设计。 b. 管理上下文：通过模块化开发、开启新对话、文档化（PRD、UI 规范）等方式，解决 LLM 上下文过长导致的性能下降和“失忆”问题。 c. 工具协同：使用 Obsidian 管理 PRD 文档，与 Cursor 开发环境无缝衔接，实现需求与开发同步。 • 最终产出：一个可以快速迭代、用于验证核心功能和收集反馈的 Alpha Prototype。 背景：让产品经理回归核心价值 在日常工作中，产品经理常常需要兼顾界面、UI 设计等任务。然而，这些并非我们的核心价值所在。 本工作流的核心思路，正是将这部分执行工作“外包”给 AI，让我们能更专注于产品定位、核心功能、用户体验和商业价值的把控。 为此，我们需要快速构建一个可交互的原型来验证想法、对齐需求。本次分享将介绍我是如何使用 Cursor 来完成这一目标的。 产品原型样式： 首先，我们需要明确我们制作的是哪一类原型 (([1]))。在多种原型中，我们聚焦于无限接近于 Alpha Prototype 的原型设计，其核心目标是验证最初设计的关键功能，而非追求完美。 • Preproduction prototype：最终产品，工作原型 • Beta prototype：量产前全功能原型 • Alpha prototype：用于验证最初设计的关键功能 • Visual prototyping：视觉原型，预期设计的外观，而不是功能 • Experience prototyping：使用者体验原型，在功能与外观上相当完整的原型，可用用于使用者研究 • Functional prototyping：功能原型，外观可能不一样。主要是硬件 • Paper prototyping：纸上原型，框架图，UI 在纸上。非常草稿 • Rapid prototyping：快速原型 3D 打印 核心理念：为原型而生的 “Vibe Coding” 要理解这套工作流，我们首先要引入一个概念：“Vibe Coding”。这是一种非常规的编码思路：我们不深入检查 AI 生成的代码细节，不做 Code Review，而是将 AI 的编码工作视为一个“黑盒”，通过“与 AI 高效沟通”和“频繁检查交付物（原型界面）”来驱动开发。 当然，这种模式也带来了几个显而易见的挑战： 1. LLM 开发的正确率与鲁棒性难以保证。 2. LLM 在长对话中，可能会“忘记”之前设定的原则，导致设计不统一。 3. 随着上下文增长，LLM 的开发精度可能下降，而成本却在上升。 4. 遇到复杂问题时，AI 可能会陷入无效的循环。 然而，产品原型阶段的工作特点，恰好可以扬长避短。 为何这种模式特别适合产品原型阶段？ 产品经理在原型阶段的工作特点，恰好能规避 Vibe Coding 的主要缺点： 1. 【探索性极强】：需求在不断探索中迭代，而非固定。这正好匹配 AI 灵活调整的能力。 2. 【鲁棒性要求低】：原型、Demo 的目标是“看起来可用”，而非“绝对可靠”。这大大降低了对 AI 代码完美性的要求。 3. 【技术栈单一】：原型通常不涉及复杂的前后端交互和多技术栈整合，降低了 AI “翻车”的概率。 基于上述特点，我们可以设计一个工作流，扬长避短，充分利用 Vibe Coding 快、准、狠的优势。 工作流核心：如何扬长避短，管理 AI 的开发过程 1. 明确目标：为 AI 设定“MVP 开发”心智模式 1. 明确目标：为 AI 设定“MVP 开发”心智模式 原型阶段对鲁棒性要求不高，这为我们降低了对大模型的要求。那么，我们如何引导 AI 聚焦于 MVP 的核心目标，而不是进行过度设计呢？ 通过 Project Rule，我们可以加入一个 自定义 Prompt，让 AI 以下述方式进行开发： 2. 统一标准：为 AI 提供“设计与技术规范”的标尺 2. 统一标准：为 AI 提供“设计与技术规范”的标尺 当你进行 Vibe Coding 时，另一个主要挑战是“设计统一性问题”。这包括： 1. UI、UX 设计原则 2. 技术栈的差异 3. 产品方案和需求的偏离 因此，我们在 project rule 下设计另一个规则： 3. 管理上下文：避免 AI“失忆”与成本失控 3. 管理上下文：避免 AI“失忆”与成本失控 在原型设计中，产品经理与 AI 的交互频率和探索广度，可能远超常规开发。原因如下： 1. 高频探索：产品经理会不断提出新 idea，需求变更频繁，这会快速消耗 AI 的上下文窗口。 2. 黑盒操作：由于不关心代码细节，产品经理倾向于用自然语言“咣咣”提需求，导致对话历史冗长。 3. Agent 模式依赖：倾向于使用 Agent 模式，让 AI 自主完成，这会产生大量中间过程的 Token 消耗。 因此，管理上下文对产品经理来说至关重要。我们面临一个取舍：