研发与产品
写一份 PRD
给它问题和目标，它会先问清楚缺失的信息，再产出一份团队可以实时协作评审、修订的文档。
复制成 Markdown 发给 AI，AI 能更快理解你的诉求
复制粘贴下面这句话，快速开始你的第一个任务：
帮我为这个想法建立一个持续推进的 PRD 自动化任务：[粘贴产品想法/用户问题]。先判断现有信息是否足够，不够就追问目标用户、真实问题和使用场景，足够就产出一份包含目标用户、核心目标、非目标、用户故事、功能范围、核心流程、边界情况、验收标准和风险的完整 PRD 初稿，存进 Notion。之后每天帮我跟进新反馈、未关闭的问题和需要决策的事项，等大家都确认后再把定稿的 P0 需求拆成任务，同步给团队。
Live preview
这个工作流是什么
写一份 PRD，是给队友一个问题和目标，而不是解决方案，让它在动笔之前先问清楚一份需求文档需要的信息——成功指标、边缘情况、明确排除在外的范围。它起草结构完整的文档，定稿前先送去做可行性评审，评审意见逐条收敛，等大家都对齐之后再把定稿的 P0 需求拆成任务。
这位队友不会自己决定范围或可行性。它负责问清楚一份 PRD 需要的问题、起草结构、根据反馈修订，但一个需求算 P0 还是 P1、一个截止日期是不是现实、某个东西在这个时间线里技术上做不做得出来，这些判断是你和团队的，不是它自己拍板的。它会标出"要的东西"和"现实能做到的东西"之间的冲突，不会悄悄替你选边。
PRD 结构参考
队友起草的 PRD 通常包含这几块：
- 背景与问题（为什么做、现状痛点、数据/反馈支撑）
- 目标与非目标（这版做什么、明确不做什么）
- 目标用户与场景（画像 + 关键用户故事）
- 成功指标（可量化的验收/北极星指标）
- 需求详述（功能点、优先级 P0/P1/P2、交互要点）
- 流程与边界情况（关键流程、异常处理）
- 依赖与风险（技术依赖、合规、已知风险与对策）
- 里程碑与范围（分期计划、MVP 边界）
- 待定问题（还没定的，列出来推动决策）
怎么用这个工作流
雇用一位产品经理，把 bio 写成"先问后写"
打开左侧边栏的 AI Teammates，点击 Hire AI Teammate，选择产品经理模板。默认 bio 是通用的产品策略，在 Profile 步骤把它换掉，让它知道这份工作是从提问开始，不是从草稿开始：
你负责写 PRD。给你一个问题和目标，动笔之前先把一份真正的需求文档需要的问题问清楚：成功指标、边缘情况、明确排除在外的范围。不要用听起来合理的默认值填空，要么问、要么标成待定问题。草稿出来之后，把评审意见和技术可行性反馈当成必须处理的修订，而不是可选的建议。范围和优先级的判断（P0 还是 P1、时间线上是否现实）由我来定，不是你自己拍板。
Live preview
给它问题，而不是解决方案
一个好的问题描述要说清楚现在的痛点、受影响的是谁、成功的样子是什么——而不是一个提前定好的方案：
我们需要在 [产品] 里支持 [功能]。现在 [目前难受的变通做法]。目标用户是 [用户群]。成功的样子是 [结果]。动笔之前先问我缺什么信息。
举个例子：
Live preview
定稿前先送去做可行性评审
一份没被真正会开发的人看过的 PRD，只是一份格式工整的愿望清单。草稿出来之后先送技术评审，再开放给更大范围的团队。交接会发进研发频道，而队友只能在自己加入过的频道里发言——先把产品经理加进那个频道：
草稿好了，先发给研发做可行性评审，评审完再开放给更大范围的团队。
Live preview
这个流程不需要你批准任何操作： 文档在你的工作区内协作，不涉及对外发送。哪些操作需要你签字批准，看控制。
用得更好的几个提示
| 提示 | 说明 |
|---|---|
| 给问题，不给提前定好的方案 | 一个提前定好的方案会跳过本该问出来的问题，也可能错过一个更好的方案或一个被忽略的约束。 |
| 定稿前先送去做可行性评审 | 一份没被真正会开发的人看过的 PRD，只是一份格式工整的愿望清单。 |
| P0/P1 和时间线的判断留给团队 | 队友会标出"要的东西"和"现实能做到的东西"之间的冲突，不会自己拍板解决。 |
| 在同一条评论下回复来修订 | 逐条修订只改被评论到的那一节，不是整篇重写。 |
常见问题
想用自己的 AI 队友试试看？
免费开始，赠 1,000 积分——无需信用卡。