可交互 PRD：用 TraeWork 修炼产品内功

02写一份 PRD，机械劳动可能吃掉一半时间#

我在直播里把一份 PRD 的机械劳动粗略拆成了四块。这个比例是我对日常工作的经验估算，不是行业统计，但它很能说明问题：

TraeWork 本身就有 Code、Work、Design 三种模式，还有桌面、网页和移动端。面对这样的复杂产品，我写新需求时必须回看各端、各模式的历史规则。即使是我自己写，也不可能一次把所有边界想清楚；很多遗漏只有在原型跑起来、研发开始追问时才会暴露。

这也是为什么，我不满足于让 AI 只生成一篇更快、更规整的文字文档。纯文字仍然要求评审者在脑中想象流程，作者也很难知道自己究竟漏掉了什么。

03把原型和需求放进同一张画布#

我理解的可交互 PRD 很直接：左边是真实可点击的 Demo，右边是结构化的需求说明。两边不是各讲各的，而是互相映射。

直播中我用“复刻一个抖音”来演示。左侧生成首页、朋友、创作、消息和个人中心等可操作页面；我点到哪一个入口，右侧就定位到相应的功能描述、页面结构、交互逻辑和数据要求。换成二手交易平台也是一样：点进商品详情，右侧就跳到商品详情对应的需求。

如果只想阅读传统文档，也可以切回纯文本模式。可交互不是强迫每个人都盯着 Demo，而是让评审者可以在“实际走流程”和“仔细读规则”之间自由切换。

我想强调，它不是“更漂亮的文档”。HTML 能同时承载文字、数据和交互，我们就进一步把 Demo 和需求放进同一个 HTML 文件。这样不只是产品经理，任何对一个产品负责、正在验证 AI 创业想法的人，都可以一边体验，一边查看体验背后的需求依据。

原型越接近真实，误解越早暴露；误解越早暴露，修改成本就越低。

04如果需求没想清楚，我会先跟 AI 聊#

很多人知道 AI 能生成原型，却卡在“我自己还不知道要做什么”。这时我不建议硬凑一段看起来完整的 Prompt。我会先打开 TraeWork 的语音讨论，把还很粗糙的想法直接说出来。

1我有一个想法：既然 AI 能把 PRD 生成原型，能不能直接把可点击的 Demo 放在左边，把对应的需求说明放在右边？
2你先不要开始生成。请判断这个需求还有哪些地方没有想清楚，并持续向我提问。
3等背景、用户、约束和验收标准都澄清以后，再帮我整理成文档。

讨论结束后，AI 会把已经聊清楚的内容整理成文档。我再让它“根据这份文档生成可交互 PRD”，比一开始就要求它猜完整个产品可靠得多。

我会要求需求至少交代四件事

1. 页面和功能清单

   产品由哪些页面、入口和核心模块组成，每个部分承担什么。

2. 角色与权限

   谁会使用，不同角色能看见什么、能执行什么，越界时怎样处理。

3. 交互与状态

   默认态、空态、加载态、报错态和恢复路径分别是什么。

4. 验收标准

   怎样才算可以上线，是否需要灰度或 A/B Test，页面、行为和指标分别如何检查。

如果我担心自己漏项，就把这四件事直接写进任务里，让右侧的需求说明逐项回答。AI 可以帮我扩展边界，但最终哪些规则成立，还是由我判断。

05让 AI 负责执行，我负责判断#

AI 读过的知识和案例远远多于一个人的个人经验，所以它很适合枚举状态、整理格式、查找遗漏和快速实现。但它不会自动理解我这个业务里最重要的取舍，也可能沿着最常见、最省事的方式完成任务。

因此我的分工是：先把目标和事实告诉 AI，让它执行；再把自己的时间放在判断上——这个功能到底为什么做、真实用户会不会这样使用、交互是否符合业务、生成的结果能不能通过。

生成得不好，我不会把整件事推倒重来，也不会直接接受。我会指出问题，让它继续改，直到结果能被真实评审。

06从 0 到 1：一句触发词可以起步，但不能代替需求#

在直播演示里，我输入的是：“帮我复刻一个抖音，用可交互式 PRD。”TraeWork 随后生成了包含多个页面的 Demo，以及概览、产品设计、需求详情、规则与异常等文档区域。

触发方式本身很简单：在任务里明确写出“生成可交互式 PRD”。这是产品内置能力，不需要另外安装一个 Skill。

你当然可以先用一句话看到第一版，再逐步补充；但需求越清楚，第一版就越接近你真正想要的结果。就像老板只给同事一句模糊任务，同事也只能花大量时间猜目标。

07从 1 到 100：我会用两种方式继续修改#

0 到 1 只是起点。真正考验产品能力的，是我能不能看出哪里不对，再把第一版一点点修到可以评审。直播里我演示了两种修改方式。

大范围问题：圈选后让 AI 修改

如果个人主页整体风格不对，我会直接框选那一块，写“背景太丑，换成可爱小猫”；如果作品图标不合适，我可以再加一条标注，要求它换成更现代、不要正方形的图标。多个问题可以像批注论文一样先全部标出来，再一次发送给 AI。

这种方式适合页面结构、视觉方向或一整块内容需要调整的情况。它让我明确告诉 AI“改哪里”，也能减少它误改其他区域。

小范围问题：像改 Word 一样直接编辑

如果只是改一句文案、调整字号、加粗文字，或者拖动一个元素的位置，我不一定要再发一次对话。进入点击修改后，可以直接在 HTML 文档上编辑，体验更像 Word：删除、输入、放大缩小、加粗和拖拽都可以直接完成。

所以我的选择很简单：局部且确定的改动自己改；范围较大、需要重新生成的改动交给 AI。两种方式一起用，才是完整的 1 到 100。

08用同一个链接完成评审，而不是继续搬版本#

可交互 PRD 做好以后，我可以复制分享链接。研发、设计或其他评审者打开后，看到的就是我当前最新的版本；后续继续修改，同一链接也会更新。这样不需要在群里反复发送“PRD 1.0”“PRD 2.0”“PRD 最终版”。

评审前，我会再沿着四类问题走一遍，也可以先让 AI 帮我检查，再由自己确认：

• 正常流程能不能从入口走到结果，完整循环有没有断点？
• 空态、加载态、报错态和异常恢复是否真的被设计过？
• 不同角色的可见范围与操作权限是否清楚？
• 上线怎样验收，页面、行为、指标与灰度方式分别是什么？

从调研、需求、PRD、原型、评审到汇报，我希望每一份产出都成为下一步的输入。省下来的不只是排版工时，而是我用来思考产品的带宽。

09直播里，大家还问了这些问题#

产品、设计和前端的边界会不会变化

我的回答是：边界确实正在变模糊。产品经理可以生成高保真 Demo，设计师和前端也能借助 AI 覆盖原来不属于自己的部分。但这不等于专业能力消失，而是每个人都要多一点产品判断、设计审美和开发常识。

真正形成差异的，是你对业务和用户有没有自己的思考。文档、设计稿和前端代码都可以让 AI 加速，为什么做、怎样给用户用、上线后怎样迭代，仍然需要人承担。

可不可以把右侧需求改成 Spec 格式

可以。可交互 PRD 是一种呈现方式，不限制右侧必须使用哪套文档结构。如果团队习惯 Spec，可以让右侧包含 specification、tasks 和 checklist；左侧仍然保留可操作原型。关键不是名词，而是任务、规格和验收有没有写清楚。

已经能 Vibe Coding，为什么还需要 PRD

个人验证想法时，Demo 可以很快说明方向；但企业级产品不能靠猜，也不能只凭“能跑”就上线。产品、设计、研发和测试需要共同评审规则、稳定性、灰度和各种边界，一份能沉淀事实依据的文档仍然必要。

Demo 负责让体验变得直观，文字负责把规则变成可以追溯的依据。两者放在一起，才是我理解的可交互 PRD。

已有原型能不能反向生成，需不需要指定模型

如果已经有原型，可以把对应项目交给 TraeWork，让它根据现有页面整理成可交互 PRD。模型方面，我在演示里使用 Auto，让产品根据任务和当时可用情况自动选择；比起先纠结模型，更重要的是给足项目上下文并检查产出。

如果第一版效果不理想，我会先检查需求有没有说清楚，再使用直接编辑或圈选修改继续推进，而不是期待任何模型“一把梭哈”就得到最终版本。