政企产品经理 AI 工作流分享：需求 ->产品的敏捷实现（深度长文）
我是 Ben，一名政企行业的解决方案架构师，目前正在往 AI 产品经理角色转型。
目录
这个工作流适合谁
为什么会有这个工作流
工作流详解（需求阶段 / 设计阶段 / 工程化实现阶段 / 交付部署阶段）
总结
一、这个工作流适合谁
我将其命名为：基于AI的「需求直达产品」敏捷工作流
如名所示，此工作流并不适合所有人，更适合与我本职工作类似的角色，比如售前、解决方案、产品经理这些角色。因为这些角色需要频繁触碰用户需求、理解需求并及时转化为「看得见摸得着」的产品。
二、为什么会有这个工作流
我所在的公司承接了一些政府定制化项目，这类项目如果无法及时收口需求，往往陷入以下困境：
需求不断变化-->方案频繁修改-->产品原型反复调整-->开发延期难验收-->项目烂尾-->客户投诉
以我在某 G 端客户的数据分析+大屏项目为例。由于是定制化项目，用户对【最终交付成品】缺乏清晰认知，导致：
需求沟通阶段：用户提不出系统化的需求，多为以下两类：
模糊泛需求：你们好好做，要能让一线人员用起来……
领导的意志：领导说了要做 XXXXX，你们去设计一下……
产品设计阶段：用户看到原型图后依然模糊不清，仅说："好，你们抓紧开发，领导要看效果"
开发交付阶段：第一个模块上线后，用户才有了直观体验，各种修改意见和新增需求随之涌现：
修改速度慢则被催促质疑
领导不满意则全盘否定，需彻底重构产品
从上述案例可见：在定制化项目中，直到 V1 版本部署上线前，用户很难对产品形成具体概念，更难以在项目初期提出明确需求。
因此，我开始思考：
如果在需求沟通后立即交付 MVP 版本，让用户实际体验，是否能够提前收集反馈并及时调整？
但传统流程（需求整理→产品设计→UI 设计→开发）周期过长！
有没有可能通过高效方式由我直接完成这一过程？
于是乎，自己便尝试与 AI 工具搭档试验，在多个项目的摸索与验证后，我形成了这套工作流。
三、工作流详解
本工作流共有 4 个阶段：需求阶段-->设计阶段-->工程化实现阶段-->交付部署阶段，每个阶段都有给力的 AI 工具加持进行提质提效！
1. 需求阶段
利用通义的实时记录完整转录用户需求。会议结束后，查看自动生成的【导读】和【脑图】以充分理解需求，并在【笔记】中记录会议关键点。
2. 设计阶段
2.1 方案设计
有了需求汇总后，可能还难以立即构思清晰的产品设计方案。
此时，可借助 AI 大模型辅助构建，目前尝试下来以ChatGPT和DeepSeek效果最佳。
提示词模板示例如下供参考，自己可以尽情测试，这也是个有趣的过程。欢迎把你觉得好用的提示词评论告诉我~
你是一名专业的政企行业产品经理，请你基于下方的项目信息，为我设计并输出产品方案，以便我可以将此方案交给前端工程师进行原型开发。 ————项目信息———— 1.项目背景：…… 2.业务需求：…… 3.使用对象：……
2.2 原型构建
接下来就是激动人心的【text to app】环节。
将上一步 AI 输出的产品设计方案交给原型构建工具：Lovable/ v0.dev / bolt.new / Tempo Labs，等待几分钟即可预览产品原型。建议同时使用多种工具生成不同版本的原型，然后从中选择最佳方案。
注意：
查看原型后，可基于不满意的地方在左侧对话区域修改指令，并重新生成。
推荐仅构建前端原型，不做后端数据对接。这些工具通常会自动生成模拟数据以增强原型的真实感。
下面是简单的示例，我同时对 4 个工具下达同样的指令（构建一个文旅智导官），大约 3-5 分钟就会生成产品原型。
从上至下依次为 Lovable，v0.dev，Bolt.new 和 Tempo Labs。
3. 工程化实现阶段
3.1 将原型源文件下载到本地
获得基本满意的产品原型后，需将源文件下载到本地进行更细致的修改。这 4 个 AI 工具的源文件下载方式分为两类：
第一类是直接在右上角可以点击下载，将整个项目的源文件下载到本地。（v0.dev / bolt.new）、
第二类是先将项目发布到自己的 github 上，然后再从 github 上将项目下载到本地。(Lovable / Tempo Labs)
3.2 对产品进行修改直至满意
打开Cursor/Windsurf/Trae这 3 个工具之一（个人强推 Cursor），将上一步下载的文件夹导入。
这三款工具本质上是 AI 增强型 IDE（集成开发环境），可将项目相关文件一并导入作为知识库，帮助它们根据你的需求创建、引用和修改文件。
首先要克服对"程序员专属界面"的心理障碍——许多非程序员同事反馈看到这类界面就产生排斥感。
实际使用后你会发现它们并不复杂！
以 Cursor 为例，界面主要分为四个区域：
文件列表区域：展示项目内所有文件；
文件内容区域：显示当前选中文件的内容；
终端运行区域：运行项目或执行命令的交互区域；
AI 对话区域：与 AI 交流以修改产品的核心区域；
关于 Cursor 的基本操作，网上教程丰富，此处不再赘述。仅阐述 2 个观点：
只要指令清晰 + 小模块迭代 + 保持耐心 → 100%可完成产品原型
虽然我们不懂代码，但随着与 AI 交互深入，掌握一些基础前端/后端技术概念有助于提出更精准的指令。
下面是一个浅显易懂的举例，当你发现 AI 设计的按钮太大不符合预期时，
->非精准指令：
"帮我把按钮调小一点，现在太大了"
->结果：
AI 将此按钮调得过小，又需反复调整
->问题：
我们无法准确描述心中预期的按钮大小
->解决方法：
观察 AI 修改的文件和参数，学习相关概念后直接修改。
如下图所示，AI 在回复中说明了它修改了 button.tsx 文件中的 size 属性（红色表示原值，绿色表示修改后的值），并总结了高度从 h-10 减为 h-9。下次不满意时，你可以直接修改这些参数直至符合预期。
因此，当你提出修改指令时，建议在指令最后添加：
"请在修改后为我总结修改了什么文件的什么参数，并说明这些修改的作用"
通过学习 AI 的回答，你会逐渐掌握"内边距"、"外边距"、"边框"等前端术语，使指令更加精准，而不仅限于"大一点"和"小一点"的模糊表述。不要排斥学习新知识，它们往往没有想象中那么困难（实践是最好的祛魅方式）！
上述这一小节主要介绍方法论，实操中还有很多细节和技巧，我将在未来持续分享，但最重要的是亲自动手实践！
4. 交付部署阶段
4.1 版本控制
在工程化实现阶段会多次修改，进而产生不同版本，需要及时保存并具备回退能力。
此时可借助GitHub进行版本控制。对开发人员而言，这是基础技能，但对非技术人员可能较为陌生。
简言之，GitHub 允许你将项目文件的特定版本上传至云端，在本地继续修改后再次上传，同时可随时回退到云端的任何历史版本。
Cursor 等工具已内置此功能：左侧边栏的分支图标提供版本控制选项，选择【初始化仓库】即可开始。
填写版本信息（如"V1 版本"），点击【提交】→【发布 Branch】将项目发布到 GitHub。
如需保密，选择【Publish to GitHub private repository】。发布成功后，会出现云朵小图标，表示此版本已提交。
后续修改先在本地完成，不会影响云端文件。决定提交新版本时，重复上述步骤即可。
非技术出身的小伙伴可能会疑惑：为何不直接用不同文件夹管理版本，而非要上传至 GitHub？
主要原因是 GitHub 除了能管理版本，还能极大简化后续部署过程，下一节将细细道来。
4.2 部署上线（公网部署+公网访问）
本小节适用于可上传至公网部署的项目。如涉密不宜上传公网，请跳至下一节查看本地部署方案。
推荐使用Netlify（无需科学上网）或Vercel（需科学上网）进行在线部署。
这些平台可无缝对接 GitHub，首次部署完成后，后续能自动检测并部署 GitHub 上的新版本，实现丝滑上线体验。
以 Netlify 为例：
登录后，点击左侧【Sites】→右侧【Add new site】→选择【Import an existing project】
点击【GitHub】完成授权，选择要部署的项目（即刚刚发布到 GitHub 的项目）。
进入部署页面：填写自定义 Site name，点击底部【Deploy XXXX】按钮，等待部署完成即可。
部署完成后，就可以获得一个公网可以访问的链接。按需将此链接发给团队/客户进行评审沟通。
4.3 部署上线（本地部署+公网访问）
若只需在本地运行项目，同时临时获取外网链接供客户访问，可使用ngrok（注意：有时访问较慢，需耐心等待）。
访问 ngrok 官网，点击"免费开始"按钮，完成注册登录后进入 Dashboard 页面。
在 Dashboard 页面，关注左侧导航栏【Getting Started】中的两个页面：安装 ngrok 工具和获取个人 token 秘钥。
完成必要配置后，在 Cursor 中运行项目，终端区域会显示项目的局域网地址。新建终端，输入：
ngrok http 192.168.20.146:8080（替换为你的实际地址）。
回车等待片刻，箭头指示处的网址即为可供外网访问的地址，通过它可以访问本地运行的项目。
注意：为避免安全风险，此方案仅用于必要演示，用完立即关闭。
当 MVP 版本上线后，客户可直观体验产品形态并提出更具体的需求。
如果产品框架获得认可，后续小需求可直接从【工程化实现阶段】开始，在 Cursor 中修改并一键部署。
4.4 PRD 文档输出
经过几轮迭代，产品基本定型后，可交付给开发团队进行生产级开发。当然，这取决于你的意愿和技术基础：
如你有意愿且具备技术基础，可自己完成生产级开发（与 AI 工具配合边学边做），但可能周期较长且需自行维护；
如你仅担任售前/解决方案/产品经理角色，则需向开发团队提供【完整产品 DEMO】+【PRD 文档】；
在 Cursor 中打开项目，通过以下提示让 AI 为你生成 PRD 文档：
请你分析这个项目的代码，基于代码中体现的已实现功能、用户界面结构和与后端交互的 API 调用，生成一份详细的产品需求文档，保存在根目录下，命名为**PRD.md** 这份 PRD 应包含以下章节： 1. **项目概述 (Project Overview):** 简要描述项目的类型和主要用途。 2. **已实现的功能列表 (Implemented Features):** 列出代码中实现的主要功能模块和子功能。例如：用户认证（登录/注册）、数据展示（列表、详情）、数据输入（表单）、搜索/过滤等。 3. **用户流程/页面结构 (User Flows / Page Structure):** 描述用户在应用中的主要路径或页面之间的导航关系，基于路由配置和组件交互推断。 4. **数据接口清单 (Data Interface Specification):** **这是核心部分，请详细分析。** 列出前端代码中发现的所有与后端交互的 API 接口。对于每个接口，请包含（如果能从代码中推断出）： * 接口名称/用途 (Purpose - 简要说明功能) * HTTP 方法 (GET, POST, PUT, DELETE 等) * 请求 URL 路径 (Request URL Path) * 请求参数/请求体结构 (Inferred Request Parameters/Body Structure) - 列出主要字段名和推断的数据类型。 * 响应数据结构 (Inferred Response Data Structure) - 列出主要响应字段名、推断的数据类型，以及常见的数据示例结构（如对象、数组）。 5. **技术实现细节 (Technical Notes - Based on Code):** 简要提及代码中可以看出的一些技术实现方式，例如使用了哪些主要框架/库（React/Vue/Angular）、状态管理库、数据获取方式等。 **重要** * 请务必专注于从代码中可以直接分析出的内容，不要推断，臆测或虚构。 * 以清晰、结构化的格式输出，使用标题和列表。 * 输出语言为中文。
注：此提示词不是固定模板，可根据需要调整。
也可以直接要求 AI 理解项目代码并生成 PRD 文档，然后基于输出内容进行迭代调整。
既然产品原型已经有了，Cursor 能够深入理解产品，输出相关的文档就会更真实可用，举一反三：
可以让其生成用户交互流程图（输出 mermai 代码，然后在线转成流程图）
可以让其为你书写投标所用的建设方案（最好喂一些模版文件）
……
当然，最终文档仍需你亲自审阅把关！
四、总结
恭喜！读到这里的你已经超越了 90%的传统型售前工程师/解决方案架构师/产品经理。
总结一下：我把【需求→最小可行性产品】的链路拆分为四个阶段：
需求阶段：利用通义的实时记录记录用户需求，通过 Google / 秘塔搜索补充相关信息，最终归档到钉钉文档或飞书文档中。
设计阶段：借助 GPT4o / DeepSeek 梳理需求并产出产品方案，再通过 Lovable / v0.dev / Bolt.new / Tempo Labs 快速生成产品原型。
工程化实现阶段：将原型代码下载到本地或同步至 GitHub，导入 Cursor / Windsurf / Trae 中进行优化调整。
交付部署阶段：根据需要，将项目部署到 Netlify / Vercel 实现公网部署与访问，或利用 ngrok 实现本地部署+公网访问。最后通过 Cursor 分析项目代码，生成 PRD 及相关文档。
在这个过程中，我深刻体会到：
AI 是一位全天候在线、情绪稳定、执行力超强的合作伙伴，我们需要做的是清晰地表达指令。
当 AI 输出不符预期时，保持耐心，重新审视提示词，逐步调整完善。
希望这套工作流能够对你有所启发，助你提升工作效率，留出更多时间享受生活！
最后，以陆游《冬夜读书示子聿》的名句作结：
纸上得来终觉浅，绝知此事要躬行。
如果对上述 AI 工作流感兴趣想了解细节，或者你有更好的提示词内容~
欢迎关注公众号【Ben 的 AI 实验室】或添加个人微信（jiangben1105），分享交流，互通有无！
版权声明: 本文为 InfoQ 作者【Ben的AI实验室】的原创文章。
原文链接:【http://xie.infoq.cn/article/ffd1baa9f187eabfb8aed053f】。文章转载请联系作者。
实践是祛魅的最好方式！ 2023-06-13 加入
AI转型中
评论