白天开会记需求，晚上画原型，第二天早起赶 PRD——产品人最熟悉的节奏，本质上是同一件事被切成三段，每次切换都得重新捡上下文。最近我把这条链路整体搬进了 WorkBuddy，用下来的感受跟"AI 帮我写文档"完全不同：它不是在旁边提建议，而是真的在你授权的文件夹里翻资料、拆步骤、把 HTML 原型和 PRD 文档一个个生成出来。

这套方法的核心是：先出原型，再写文档。原型定稿后，PRD 里的功能截图就是现成的，一块块往章节里贴；交互说明也简单了，对着页面上的控件一个一个写就行。反过来的代价我尝过——文档里写"点击按钮弹出弹窗"，原型出来发现是侧滑抽屉，光是改这句话就改了十几处。

画原型：材料喂对了，一半的活就省了

很多人的第一次失败是因为给的东西太少。我的固定做法是建一个文件夹，放三样东西：调研记录（md、docx 都行，原始的最好）、原始截图（老系统、竞品截图，一张截图顶三百字描述）、需求说明（一段话就够）。

然后只说一句："先把这个文件夹里的内容全部读完，读完先告诉我你理解的需求是什么。"等它复述一遍，确认没理解偏再让它开工。这一步别省——我第一次跳过这步，它把"核销"理解成了"发货"，原型画到第三屏才发现。

四维描述法：行业 / 受众 / 功能 / 风格

你不说受众，它默认按 C 端消费者来，信息密度低、按钮特别大；你不说风格，它自己挑一套配色，回头你还得让它整个重调。以开发智能问数界面为例：

模式选择代码开发，工作空间选择材料目录，提示词明确需求后，它进入 agent 模式输出原型。在输出之前，对于新增的交互，它会多次弹窗提醒确认：

最终输出修改后的原型：

迭代技巧：把话说死

迭代时最忌讳说"这里感觉不太对"。我的固定句式是：改哪个页面的哪个模块 → 改成什么样 → 有什么特殊规则。最后一定要补一句"其他页面保持不动"，不然它有时候会顺手"优化"你别的页面。

写 PRD：五要素逐章写

把飞书 PRD 模板链接发给它，先读结构、列出章节清单，确认了再往下写。一份能被研发认下来的 PRD 五要素缺一不可：

• 功能简述：背景、目标用户、解决什么问题、本期范围，以及明确不做的事
• 功能截图：让它用浏览器把原型打开，逐屏截图插到对应功能章节里，同时带上访问链接
• 交互说明：正常态、空态、加载态、异常态、权限差异——异常态是重灾区
• 业务流程：主流程 + 分支 + 异常分支
• 列表说明：用表格，字段名、类型、来源、排序规则、筛选条件、权限，一行一个字段

不确定的一律标【待确认】

这句话请一定写进提示词里。不加这句的后果很直接：它会把空缺的地方合理填上，读起来还特别通顺，但那些内容全是猜的。标出来之后，你一眼就知道哪几处需要找业务确认。

四个被低估的实用功能

把跑顺的流程存成技能：当某套流程重复跑了三次以上，直接跟它说"把这套流程存成一个技能，下次调用"。开新需求只需要一句话。

用项目记忆记住规矩：每个项目第一次对话时花一分钟说清楚固定约定，让它记到项目记忆文件里，之后每次开新会话自动生效。

让重复的活定时自己跑：周期性动作交给定时任务，比如每周五汇总需求讨论记录生成周报。

先出线框再出高保真：方向没定时先让出三四个线框草图，选定了再输出正式 HTML 高保真原型。

写在最后

WorkBuddy 帮你把底稿写完，但判断还是你的。异常怎么兜、灰度怎么切、这次要不要做，这些没有标准答案的东西永远得你自己拍板。它帮你省下的是体力活，留下的恰好是最该你花时间的那部分。