1. 从零到一为什么产品经理需要一套自己的原型与PRD工作流做产品经理这些年我最大的感受是写PRD和画原型这两件事表面上看是“文档工作”实际上是一个产品从模糊想法到可落地执行的关键翻译过程。翻译得好研发、设计、测试各角色拿到手就能干活翻译得差后面就是无休止的返工、扯皮、需求评审会上被怼到怀疑人生。传统做法无非是Axure画原型、Word写PRD、Visio画流程图工具之间来回切换改一个字段名要同步改三四个地方。后来Figma、即时设计这类在线工具普及了协作效率上来了但PRD的文字部分依然靠手写一个中等复杂度的功能模块光PRD正文就能写上万字还不算各种状态说明和异常分支。WorkBuddy这类工具的出现本质上是把“原型设计”和“PRD撰写”这两个动作合并到一个工作台里用结构化的方式管理需求。你可以把它理解成一个专门为产品经理设计的IDE——原型是可视化界面PRD是底层逻辑描述两者通过数据模型关联起来。改一个字段原型和文档同步更新这是它最核心的价值。这篇文章适合三类人看第一类是刚入行的产品经理想知道一套完整的原型加PRD工作流长什么样第二类是有一定经验但还在用传统工具的产品经理想看看有没有更高效的方案第三类是对提示词工程感兴趣的技术同学想了解怎么用大模型辅助产品文档生成。不管你基础如何我会把每一步的操作逻辑和背后的原因都讲清楚你照着做就能复现。2. 整体设计思路把PRD拆成“可执行的结构化数据”2.1 为什么传统PRD写法效率低先说说传统PRD的问题。一份典型的PRD包含这些内容需求背景、目标用户、功能列表、页面流程、字段说明、状态机、异常处理、埋点需求、接口约定。这些内容分散在文档的不同章节但它们之间是有强关联的。比如“字段说明”里的某个字段在“页面流程”里对应哪个交互步骤在“状态机”里对应哪个状态流转在“接口约定”里对应哪个参数——这些关联关系在纯文本PRD里是隐式的靠人脑去维护。结果就是改了一个字段类型忘了同步改接口文档加了一个状态忘了更新流程图删了一个页面埋点需求里还留着对应的埋点。这种不一致性在需求评审时被研发发现轻则当场改重则整个方案被打回重来。WorkBuddy的思路是把这些内容结构化。每个功能模块是一个“实体”实体下面挂“字段”、“状态”、“动作”、“规则”。原型页面和PRD文档都是这些结构化数据的“视图”。你改的是数据本身视图自动更新。这个思路和现代前端框架的数据驱动UI是一个道理——数据变了界面自动重新渲染。2.2 核心工作流的四个阶段我把整个工作流拆成四个阶段每个阶段有明确的输入和输出第一阶段需求结构化。把脑子里的想法或者老板给的一句话需求拆解成功能模块、用户角色、核心流程。这个阶段不需要画图用文字和列表就行。关键是穷举所有分支包括正常流程和异常流程。第二阶段原型搭建。基于结构化的需求在WorkBuddy里拖拽组件生成页面原型。每个页面元素绑定到对应的数据字段。这个阶段要关注的是交互逻辑不是视觉设计——原型是给研发和设计看的不是给用户看的。第三阶段PRD生成。WorkBuddy根据原型和结构化数据自动生成PRD初稿包括字段说明表、状态流转图、接口参数表。你只需要补充业务规则和边界条件。第四阶段评审与迭代。把原型和PRD分享给团队收集反馈在WorkBuddy里直接修改。修改记录自动同步到PRD版本历史。这四个阶段不是严格线性的实际工作中经常来回跳。但整体框架是这样下面我逐个展开。2.3 工具选型为什么是WorkBuddy而不是其他市面上做原型和PRD的工具不少Figma、Axure、墨刀、即时设计都能画原型Notion、飞书文档能写PRD。WorkBuddy的差异点在于它把两者打通了而且内置了提示词工程的能力。提示词工程在这里的作用是当你输入一段自然语言描述的需求WorkBuddy能自动帮你拆解成结构化的功能模块和字段列表。比如你输入“用户可以用手机号加验证码登录登录后能看到自己的订单列表订单可以按状态筛选”它会自动生成“登录页”和“订单列表页”两个原型页面以及“手机号”、“验证码”、“订单状态”等字段。这个能力背后是大模型在支撑。你写的提示词质量直接决定了生成结果的质量。所以后面我会专门讲提示词工程的实操技巧。至于Gitee它在整个工作流里的角色是版本管理和协作。WorkBuddy生成的原型和PRD可以导出成Markdown或JSON格式提交到Gitee仓库里做版本控制。团队其他成员可以通过Gitee Pages直接查看最新的PRD文档不需要每个人都装WorkBuddy。这个组合方案我实测下来很稳尤其适合中小团队。3. 核心细节解析提示词工程与结构化拆解3.1 提示词工程在PRD生成中的实际应用提示词工程这个词听起来很玄但落到产品经理的日常工作中它就是“怎么把需求描述清楚让大模型能准确理解并生成你想要的结果”。我总结了一个三段式提示词模板实测下来生成质量比随便写一句话高很多。第一段角色设定。告诉模型它现在是什么角色。比如“你是一个有五年经验的B端产品经理擅长将模糊的业务需求拆解成结构化的功能模块和字段列表。”这个设定会影响模型输出的专业度和颗粒度。第二段任务描述。明确告诉模型要做什么。比如“请将以下需求拆解成功能模块每个模块包含模块名称、核心字段字段名、类型、是否必填、说明、主要操作操作名称、触发条件、结果、异常分支。”第三段输出格式。指定输出的结构。比如“用Markdown表格输出字段列表用有序列表输出操作流程用无序列表输出异常分支。”这三段缺一不可。我试过只写任务描述不写角色设定生成的内容偏技术实现缺少产品视角只写角色设定不写输出格式生成的内容结构混乱还得手动整理。三段都写清楚基本一次就能生成可用的初稿。3.2 结构化拆解的颗粒度控制拆解颗粒度是产品经理的基本功。拆得太粗研发看不懂拆得太细自己维护不过来。我的经验是一个功能模块的字段数量控制在5到15个之间操作数量控制在3到8个之间。超过这个范围说明模块还可以继续拆分。举个例子“用户管理”这个模块如果字段有用户名、密码、手机号、邮箱、头像、昵称、性别、生日、注册时间、最后登录时间、账号状态、角色、部门、职位、上级领导——15个字段刚好在边界上。如果再加入“紧急联系人”、“身份证号”、“银行卡号”那就应该拆成“用户基础信息”和“用户扩展信息”两个模块。操作数量也是同理。“用户管理”的操作有创建用户、编辑用户、禁用用户、启用用户、重置密码、分配角色、导出用户列表——7个操作合理。如果再加上“批量导入”、“批量导出”、“批量禁用”、“批量分配角色”那就应该把批量操作单独拆成一个“批量操作”模块。这个颗粒度控制的逻辑是一个模块对应一个原型页面一个页面上的操作按钮不超过8个。超过8个按钮的页面用户认知负担太重研发实现也容易出遗漏。3.3 字段类型与校验规则的标准化字段类型和校验规则是PRD里最容易出问题的部分。研发经常问“这个字段是字符串还是数字长度限制多少允许为空吗有没有格式要求”如果PRD里没写清楚研发就按自己的理解实现最后测试发现不符合预期又要改。我的做法是在WorkBuddy里建一个“字段类型字典”把所有可能用到的字段类型和对应的校验规则预定义好。比如字段类型存储格式默认校验规则常见异常短文本字符串长度1-50不允许特殊字符超长、含特殊字符长文本字符串长度1-500允许换行超长整数数字范围根据业务定默认0-999999非数字、超范围金额数字保留两位小数范围0-99999999.99负数、超范围、精度错误手机号字符串11位数字1开头位数不对、非数字邮箱字符串符合邮箱格式格式错误枚举字符串必须在预定义选项内非法选项日期字符串YYYY-MM-DD格式格式错误、非法日期布尔布尔值true/false非布尔值这个字典建好之后每次新建字段直接从字典里选类型校验规则自动带出来。研发拿到PRD后直接照着字典实现校验逻辑不需要再问。这个做法至少减少了30%的需求澄清会议。3.4 状态机与流程图的自动化生成状态机是PRD里最容易被忽略但最重要的部分。一个订单有“待支付、已支付、待发货、已发货、已完成、已取消、已退款”七个状态每个状态之间的流转条件是什么哪些操作触发流转流转后哪些字段会变化——这些如果不用状态机描述清楚研发实现时必然出bug。WorkBuddy的做法是你在结构化数据里定义好状态和流转规则它自动生成状态流转图。这个图不是静态图片是可以用鼠标悬停查看详情的交互式图表。研发在评审时可以直接在图上点来点去确认每个流转条件。我一般会把状态机分成三层来描述第一层是状态列表列出所有可能的状态第二层是流转规则定义从哪个状态可以流转到哪个状态触发条件是什么第三层是副作用定义流转发生后哪些字段会变化哪些通知会触发。这三层写清楚研发基本不会在状态逻辑上出问题。4. 实操过程从需求到PRD的完整落地4.1 环境准备与WorkBuddy初始化WorkBuddy支持Web端和桌面端我建议用桌面端因为原型编辑对性能要求比较高Web端在拖拽复杂页面时偶尔会卡顿。安装过程不复杂官网下载安装包一路下一步就行。安装完成后需要登录账号新用户有免费额度够用一阵子。登录后第一件事是创建一个“工作空间”。工作空间相当于一个项目容器里面包含这个项目的所有原型页面、PRD文档、字段字典、状态机定义。我一般按产品线来建工作空间比如“电商后台”、“用户中心”、“数据报表”各一个空间。创建完工作空间后进入“设置”页面配置团队协作。WorkBuddy支持邀请成员加入工作空间成员分三种角色管理员、编辑者、查看者。管理员可以改所有设置编辑者可以改原型和PRD查看者只能看不能改。一般给研发和设计开编辑者权限给测试和运营开查看者权限。接下来配置Gitee集成。在WorkBuddy的设置里找到“版本控制”选项选择Gitee作为远程仓库。你需要先在Gitee上创建一个空仓库然后把仓库地址和访问令牌填到WorkBuddy里。访问令牌在Gitee的“设置-私人令牌”里生成勾选“仓库读写”权限就行。注意Gitee的私人令牌只显示一次生成后立刻复制保存。如果忘了只能重新生成一个。配置完成后WorkBuddy会自动把当前工作空间的内容推送到Gitee仓库。之后每次修改你可以在WorkBuddy里点“提交”填写提交信息然后“推送”到Gitee。团队其他成员在Gitee上能看到完整的版本历史。4.2 需求结构化拆解实操假设我们要做一个“支付网关设计文档PRD”这是热搜词里提到的场景。支付网关的核心功能是接收业务系统的支付请求路由到不同的支付渠道处理支付结果回调对账和退款。第一步在WorkBuddy里新建一个“功能模块”叫“支付网关”。然后在这个模块下建子模块支付请求、支付路由、支付回调、对账、退款。第二步给每个子模块定义字段。以“支付请求”为例字段包括请求ID、业务系统标识、订单号、支付金额、币种、支付渠道、回调地址、请求时间、请求状态。每个字段选好类型填好说明。第三步定义操作。支付请求的操作有创建支付请求、查询支付请求、关闭支付请求。每个操作定义触发条件、输入参数、输出结果、异常分支。第四步定义状态机。支付请求的状态有待路由、路由中、路由成功、路由失败、支付中、支付成功、支付失败、已关闭。定义每个状态之间的流转规则。这四步做完WorkBuddy会自动生成一份结构化的PRD初稿。你只需要补充业务规则比如“单笔支付金额上限为50000元”、“同一订单号重复请求时返回已有请求ID”、“路由失败时自动重试三次间隔分别为1秒、5秒、30秒”。4.3 原型页面搭建与字段绑定结构化数据准备好之后切换到“原型”视图。WorkBuddy提供了常用的组件库表格、表单、按钮、弹窗、标签页、步骤条、卡片。拖拽组件到画布上然后双击组件绑定数据字段。以“支付请求列表页”为例拖一个表格组件绑定“支付请求”模块的字段列表表格自动生成列头。拖一个搜索栏组件绑定“订单号”和“请求状态”两个字段作为搜索条件。拖一个“新建请求”按钮绑定“创建支付请求”操作。绑定完成后原型页面上的每个元素都和底层数据关联起来了。你改字段名原型上的列头自动更新你加一个字段原型上自动多一列。这个联动机制是WorkBuddy最省心的地方。原型搭建的注意事项不要追求视觉精美原型是沟通工具不是设计稿。我见过一些产品经理花大量时间调原型样式字体、颜色、间距反复调结果研发根本不看样式只看交互逻辑。把时间花在交互流程和异常分支上比花在样式上价值大得多。4.4 PRD自动生成与人工补充原型搭建完成后点“生成PRD”按钮WorkBuddy会根据结构化数据和原型页面生成一份完整的PRD文档。文档结构包括需求概述、功能模块列表、字段说明表、操作流程说明、状态流转图、接口参数表、异常处理说明。自动生成的PRD大概能覆盖70%的内容剩下的30%需要人工补充。需要补充的主要是业务背景说明、用户故事、非功能性需求性能、安全、兼容性、埋点需求、上线计划。我一般会在自动生成的PRD基础上用WorkBuddy的“富文本编辑”功能补充这些内容。补充的内容也会被结构化存储下次生成PRD时自动带出来。4.5 Gitee版本管理与团队协作PRD定稿后在WorkBuddy里点“提交到Gitee”填写提交信息比如“支付网关PRD v1.0 初稿”。WorkBuddy会把PRD导出成Markdown格式原型导出成JSON格式一起提交到Gitee仓库。团队其他成员在Gitee上可以看到完整的版本历史。研发可以在Gitee的Issue里提问题比如“支付回调的超时时间是多少”你在WorkBuddy里修改后重新提交Gitee上会自动关联这次提交和对应的Issue。如果团队用Gitee Pages还可以把PRD文档发布成静态网站。在Gitee仓库的“服务”里开启Gitee Pages选择部署分支和目录Gitee会生成一个访问链接。团队成员打开链接就能看到最新的PRD不需要登录Gitee账号。提示Gitee Pages的静态网站更新有延迟提交后大概等1到2分钟再刷新。4.6 提示词模板与自定义指令配置WorkBuddy支持自定义指令你可以把常用的提示词模板保存下来下次直接调用。我配置了几个常用指令指令一需求拆解。“请将以下需求拆解成功能模块每个模块包含字段列表、操作列表、状态机。字段列表用表格输出包含字段名、类型、是否必填、说明。操作列表用有序列表输出包含操作名、触发条件、结果。状态机用文字描述状态和流转规则。”指令二异常分支穷举。“请针对以下功能模块穷举所有可能的异常分支包括输入异常、网络异常、并发异常、权限异常、数据异常。每个异常分支说明触发条件、系统表现、用户提示。”指令三接口参数生成。“请根据以下字段列表和操作列表生成RESTful接口定义包括URL、Method、请求参数、响应参数、错误码。”这三个指令覆盖了PRD撰写中最耗时的三个环节。配置好之后每次新建模块直接调用指令生成初稿后再人工调整效率提升非常明显。5. 常见问题与排查技巧实录5.1 WorkBuddy使用中的典型问题问题一生成的原型页面布局错乱。这种情况通常是因为字段太多表格组件放不下。解决办法是分页显示或者把不重要的字段隐藏起来放到“详情页”里展示。WorkBuddy的表格组件支持“列配置”可以设置每列的显示优先级。问题二PRD生成时提示“数据不完整”。检查一下是不是有字段没填类型或者有操作没定义异常分支。WorkBuddy在生成PRD前会做一次数据校验不完整的部分会标红提示。按提示补全就行。问题三Gitee推送失败提示“权限不足”。检查访问令牌是否过期或者是否勾选了“仓库读写”权限。另外确认一下Gitee仓库是不是私有仓库私有仓库需要令牌有更高的权限。问题四WorkBuddy 502错误。这是服务端网关错误通常是网络波动或者服务端临时故障。等几分钟重试如果持续出现检查一下本地网络是否正常。我在使用过程中遇到过两次都是等了几分钟自己恢复了。问题五自定义指令不生效。检查指令的触发关键词是否和WorkBuddy的保留词冲突。另外确认指令是否保存到了当前工作空间跨工作空间的指令不通用。5.2 提示词工程的避坑指南坑一提示词太笼统。“帮我写一个支付功能的PRD”——这种提示词生成的内容泛泛而谈没有实操价值。要具体到业务场景、用户角色、核心流程。坑二一次让模型做太多事。“帮我拆解需求、生成原型、写PRD、生成接口文档”——模型一次处理太多任务每个任务的质量都会下降。拆开做一个指令只做一件事。坑三不指定输出格式。不指定格式的话模型每次输出的结构都不一样后续处理很麻烦。一定要在提示词里明确输出格式表格、列表、JSON都可以。坑四忽略上下文。大模型的上下文窗口有限如果对话历史太长早期的信息会被遗忘。重要的约束条件要在每次指令里重复强调。坑五不做人工校验。模型生成的内容一定会有错误尤其是业务规则和边界条件。生成后必须逐条校验不能直接拿去用。5.3 Gitee协作中的常见故障故障一本地Git同时配置了Gitee和另一个代码托管平台推送时冲突。解决办法是在Git配置里为不同的远程仓库设置不同的用户名和邮箱。用git config --local user.name和git config --local user.email在仓库级别配置不要用--global。故障二用TortoiseGit拉取Gitee代码失败。检查SSH密钥是否配置正确。在Gitee的“设置-SSH公钥”里添加本地生成的公钥。如果用的是HTTPS方式检查用户名密码是否正确。故障三Gitee创建Issue时验证码错误。这是浏览器缓存问题清除缓存或者换一个浏览器试试。如果还不行检查系统时间是否准确时间偏差太大会导致验证码校验失败。故障四Gitee Pages部署后页面空白。检查部署目录里是否有index.html文件。Gitee Pages默认找index.html作为入口如果没有这个文件需要手动指定入口文件。故障五分支结构混乱。建议采用简单的分支模型master分支存放稳定版本dev分支存放开发中的版本每个功能模块从dev拉feature分支开发完成后合并回dev。合并到master前必须经过评审。5.4 常见问题速查表问题现象可能原因排查步骤解决方案原型布局错乱字段过多超出容器检查表格列数和页面宽度分页显示或隐藏次要字段PRD生成失败数据不完整查看标红提示补全字段类型和异常分支Gitee推送失败令牌过期或权限不足检查令牌有效期和权限范围重新生成令牌并勾选读写权限502错误服务端临时故障等待几分钟后重试如持续出现联系技术支持自定义指令不生效关键词冲突或空间不匹配检查指令配置修改关键词或重新保存指令提示词生成质量差提示词太笼统检查提示词是否包含角色、任务、格式使用三段式模板重写Git推送冲突多平台配置冲突检查git config使用仓库级配置替代全局配置Pages页面空白缺少入口文件检查部署目录添加index.html或指定入口6. 进阶技巧让WorkBuddy真正融入日常工作流6.1 建立个人提示词库提示词工程的核心资产是提示词库。我建议每个产品经理都建一个自己的提示词库按场景分类需求拆解类、原型生成类、PRD撰写类、接口定义类、测试用例类。每个类别下积累3到5个经过验证的提示词模板。提示词库的维护方法是每次用某个提示词生成了高质量的结果就把这个提示词保存下来标注适用场景和注意事项。下次遇到类似场景直接调用不用重新想。积累三个月你就有了一套属于自己的“提示词工具箱”。WorkBuddy的自定义指令功能就是为这个场景设计的。你可以把提示词库导入WorkBuddy用快捷键快速调用。我目前积累了二十多个指令覆盖了日常工作中80%的文档撰写场景。6.2 与研发协作的接口约定PRD里的接口约定部分我建议用OpenAPI规范来描述。WorkBuddy支持导出OpenAPI格式的接口定义研发可以直接导入到Swagger或Postman里做接口调试。这个做法比在PRD里写文字描述接口参数要准确得多也省去了研发手动录入接口的时间。具体操作是在WorkBuddy的“接口定义”模块里按OpenAPI的格式填写接口信息包括路径、方法、请求体、响应体、错误码。填写完成后导出成YAML文件提交到Gitee仓库。研发拉取代码后直接导入Swagger接口文档自动生成。这个流程跑通之后前后端联调的时间至少缩短一半。以前联调时研发经常问“这个字段是什么类型”、“这个错误码是什么意思”现在Swagger里都有自己看就行。6.3 版本迭代与变更管理产品迭代过程中PRD的变更是常态。WorkBuddy的版本管理功能可以记录每次变更的内容、时间、操作人。变更记录会同步到Gitee的提交历史里形成完整的审计轨迹。我一般会在每个迭代周期开始时从Gitee的master分支拉一个feature分支在这个分支上做本迭代的PRD修改。迭代结束后把feature分支合并回master打一个版本标签比如“v1.2.0”。这样每个版本的PRD都有据可查。变更管理的关键是每次变更都要写清楚变更原因和影响范围。比如“将支付超时时间从30分钟改为15分钟原因是渠道方调整了超时策略影响范围是所有使用该渠道的支付请求。”这样的变更记录半年后回头看也能快速理解当时的决策背景。6.4 团队协作中的权限与流程设计团队协作最怕的是权限混乱。我的建议是按角色分配权限按流程控制变更。产品经理有编辑权限研发和设计有评论权限测试和运营有查看权限。PRD的每次修改都需要至少一个研发和一個测试确认确认后才能合并到master分支。这个流程在Gitee里通过“合并请求”实现。产品经理在feature分支上修改PRD提交合并请求指定研发和测试作为审核人。审核人在Gitee上查看变更内容确认无误后点“合并”。如果有问题在合并请求里评论产品经理修改后重新提交。这个流程看起来多了一步但实际上减少了大量口头沟通和事后扯皮。所有变更都有记录所有确认都有痕迹出了问题能快速定位是哪个环节出的错。6.5 从PRD到测试用例的自动化PRD里的字段说明和操作流程可以直接用来生成测试用例。WorkBuddy支持导出测试用例模板包含正常流程用例和异常流程用例。测试同学拿到模板后补充具体的测试数据和预期结果就行。我试过用提示词工程来生成测试用例初稿。提示词是“请根据以下字段列表和操作流程生成测试用例包括用例编号、用例名称、前置条件、操作步骤、预期结果。正常流程和异常流程分开输出。”生成的结果覆盖了大部分场景测试同学只需要补充边界值测试和性能测试。这个做法把测试用例编写的时间从两天缩短到半天。测试同学有更多时间去做探索性测试而不是花在写文档上。6.6 持续集成与自动化部署如果团队有持续集成环境可以把WorkBuddy的导出流程集成到CI流水线里。每次PRD更新提交到Gitee后CI自动触发构建把PRD导出成HTML和PDF部署到Gitee Pages或者内部文档服务器。这个自动化的价值在于团队成员永远看到的是最新版本的PRD不需要手动同步。产品经理改完PRD提交后几分钟内所有人都能看到更新。这个实时性在快速迭代的团队里非常重要。配置方法是在Gitee仓库里添加一个Webhook指向CI服务的触发地址。CI服务收到Webhook后拉取最新代码执行WorkBuddy的命令行导出工具把生成的文件部署到目标服务器。WorkBuddy提供了命令行工具支持在CI环境里无头运行。7. 个人实操体会与建议这套工作流我用了大半年最大的感受是工具的价值不在于功能多强大而在于能不能融入你的日常工作习惯。WorkBuddy的功能确实多但如果你只是偶尔用一下效果有限。真正产生价值的是把它变成每天工作的默认工具——写需求用它、画原型用它、生成PRD用它、提交版本用它。提示词工程也是一样。刚开始你可能觉得写提示词很麻烦不如直接手写PRD快。但坚持用一个月积累了一套自己的提示词库之后效率提升是肉眼可见的。我现在写一个中等复杂度的功能模块PRD从需求拆解到PRD定稿大概两个小时就能完成以前至少要一天。Gitee的版本管理是另一个让我省心的地方。以前PRD改来改去最后自己都记不清哪个版本是最新的。现在每次修改都有提交记录随时可以回滚到任意版本。团队协作也清晰了谁改了什么、什么时候改的、为什么改的一目了然。最后分享一个小技巧把常用的提示词模板和字段字典导出成JSON文件提交到Gitee仓库里。这样换电脑或者换工作空间时直接导入就能用不用重新配置。这个习惯帮我省了不少重复劳动的时间。