# 写一份 PRD (/zh/use-cases/rd-product/prd-writer)



复制粘贴下面这句话，快速开始你的第一个任务：

<Prompt>
  帮我为这个想法建立一个持续推进的 PRD 自动化任务：[粘贴产品想法/用户问题]。先判断现有信息是否足够，不够就追问目标用户、真实问题和使用场景，足够就产出一份包含目标用户、核心目标、非目标、用户故事、功能范围、核心流程、边界情况、验收标准和风险的完整 PRD 初稿，存进 Notion。之后每天帮我跟进新反馈、未关闭的问题和需要决策的事项，等大家都确认后再把定稿的 P0 需求拆成任务，同步给团队。
</Prompt>

<LivePreview component="NewThread" scenario="{ draft: &#x22;帮我为这个想法建立一个持续推进的 PRD 自动化任务：[粘贴产品想法/用户问题]。先判断现有信息是否足够，不够就追问目标用户、真实问题和使用场景，足够就产出一份包含目标用户、核心目标、非目标、用户故事、功能范围、核心流程、边界情况、验收标准和风险的完整 PRD 初稿，存进 Notion。之后每天帮我跟进新反馈、未关闭的问题和需要决策的事项，等大家都确认后再把定稿的 P0 需求拆成任务，同步给团队。&#x22; }" />

## 这个工作流是什么 [#这个工作流是什么]

写一份 PRD，是给队友一个问题和目标，而不是解决方案，让它在动笔之前先问清楚一份需求文档需要的信息——成功指标、边缘情况、明确排除在外的范围。它起草结构完整的文档，定稿前先送去做可行性评审，评审意见逐条收敛，等大家都对齐之后再把定稿的 P0 需求拆成任务。

<Callout type="warn">
  这位队友不会自己决定范围或可行性。它负责问清楚一份 PRD 需要的问题、起草结构、根据反馈修订，但一个需求算 P0 还是 P1、一个截止日期是不是现实、某个东西在这个时间线里技术上做不做得出来，这些判断是你和团队的，不是它自己拍板的。它会标出"要的东西"和"现实能做到的东西"之间的冲突，不会悄悄替你选边。
</Callout>

## PRD 结构参考 [#prd-结构参考]

队友起草的 PRD 通常包含这几块：

1. 背景与问题（为什么做、现状痛点、数据/反馈支撑）
2. 目标与非目标（这版做什么、明确不做什么）
3. 目标用户与场景（画像 + 关键用户故事）
4. 成功指标（可量化的验收/北极星指标）
5. 需求详述（功能点、优先级 P0/P1/P2、交互要点）
6. 流程与边界情况（关键流程、异常处理）
7. 依赖与风险（技术依赖、合规、已知风险与对策）
8. 里程碑与范围（分期计划、MVP 边界）
9. 待定问题（还没定的，列出来推动决策）

## 怎么用这个工作流 [#怎么用这个工作流]

<Steps>
  <Step>
    ### 雇用一位产品经理，把 bio 写成"先问后写" [#雇用一位产品经理把-bio-写成先问后写]

    打开左侧边栏的 **AI Teammates**，点击 **Hire AI Teammate**，选择**产品经理**模板。默认 bio 是通用的产品策略，在 Profile 步骤把它换掉，让它知道这份工作是从提问开始，不是从草稿开始：

    <Prompt>
      你负责写 PRD。给你一个问题和目标，动笔之前先把一份真正的需求文档需要的问题问清楚：成功指标、边缘情况、明确排除在外的范围。不要用听起来合理的默认值填空，要么问、要么标成待定问题。草稿出来之后，把评审意见和技术可行性反馈当成必须处理的修订，而不是可选的建议。范围和优先级的判断（P0 还是 P1、时间线上是否现实）由我来定，不是你自己拍板。
    </Prompt>

    <LivePreview component="CreateAssistantPage" scenario="{ focus: &#x22;profile&#x22;, initialState: { start: &#x22;template&#x22;, templateRef: &#x22;@helio/product-manager&#x22;, name: &#x22;产品经理&#x22;, bio: &#x22;你负责写 PRD。给你一个问题和目标，动笔之前先把一份真正的需求文档需要的问题问清楚：成功指标、边缘情况、明确排除在外的范围。不要用听起来合理的默认值填空，要么问、要么标成待定问题。草稿出来之后，把评审意见和技术可行性反馈当成必须处理的修订，而不是可选的建议。范围和优先级的判断（P0 还是 P1、时间线上是否现实）由我来定，不是你自己拍板。&#x22; } }" />

    [雇用详情 →](/ai-teammates/hire-an-ai-teammate)
  </Step>

  <Step>
    ### 连接 Notion [#连接-notion]

    队友会把 PRD 作为一份持续更新的文档存在这里。[连接 Notion →](/connect/connect-tools-to-ai-teammates)

    <LivePreview component="AssistantIntegrations" />
  </Step>

  <Step>
    ### 给它问题，而不是解决方案 [#给它问题而不是解决方案]

    一个好的问题描述要说清楚现在的痛点、受影响的是谁、成功的样子是什么——而不是一个提前定好的方案：

    <Prompt>
      我们需要在 [产品] 里支持 [功能]。现在 [目前难受的变通做法]。目标用户是 [用户群]。成功的样子是 [结果]。动笔之前先问我缺什么信息。
    </Prompt>

    举个例子：

    <LivePreview
      component="AssistantChat"
      scenario="{ assistantName: &#x22;产品经理&#x22;, messages: [
    { author: &#x22;user&#x22;, text: &#x22;我们需要在患者端支持处方撤回。现在患者要撤回已配好的处方得打电话给客服，要等 2 天。目标用户是慢性病用药计划的患者。成功的样子是能自助撤回，同时还能让药房核实资格。动笔之前先问我缺什么信息。&#x22; },
    { author: &#x22;assistant&#x22;, text: &#x22;先问几句：药房核实资格是不是每笔撤回都强制要求，还是超过某个金额或数量才需要？另外 2 天的等待时间是真正的痛点，还是大部分患者根本不知道能自助撤回？这两个答案会决定这主要是个体验问题，还是个流程和权限问题，PRD 会长得完全不一样。&#x22; },
  ] }"
    />
  </Step>

  <Step>
    ### 定稿前先送去做可行性评审 [#定稿前先送去做可行性评审]

    一份没被真正会开发的人看过的 PRD，只是一份格式工整的愿望清单。草稿出来之后先送技术评审，再开放给更大范围的团队。交接会发进研发频道，而队友只能在自己加入过的频道里发言——先把产品经理加进那个频道：

    <Prompt>
      草稿好了，先发给研发做可行性评审，评审完再开放给更大范围的团队。
    </Prompt>

    <LivePreview
      component="AssistantChat"
      scenario="{ assistantName: &#x22;产品经理&#x22;, messages: [
    { author: &#x22;user&#x22;, text: &#x22;草稿好了，先发给研发做可行性评审，评审完再开放给更大范围的团队。&#x22; },
    { author: &#x22;assistant&#x22;, text: &#x22;已经发到研发频道。已经收到一条反馈：每笔撤回都要求药房实时核实资格，现有的资格核查 API 做不到，那是个夜间批处理任务，不是实时调用。我把这个记成了待定问题，没有自己悄悄改需求，因为要不要放宽成当天核实、还是要投入做一个实时 API，这个判断该由你和研发负责人来做，不该我自己定。&#x22; },
  ] }"
    />
  </Step>

  <Step>
    ### 分享出去，逐条修订 [#分享出去逐条修订]

    把文档链接发给评审人。大家在同一份文档里看、评论、改；有分歧的地方留评论，队友跟进修订，只改被评论到的部分，不是整篇重写：

    <LivePreview
      component="AssistantChat"
      scenario="{ assistantName: &#x22;产品经理&#x22;, messages: [
    { author: &#x22;user&#x22;, text: &#x22;在需求详述那一节评论：如果患者在处方已经发货之后才撤回，这里没写会怎么处理。&#x22; },
    { author: &#x22;assistant&#x22;, text: &#x22;确实漏了这个边缘情况。补了一条需求：发货之后的撤回走退货授权流程，而不是直接取消，因为处方已经实际在物流里了。只更新了这一节和下面对应的流程图，其他部分没动。回复了你这条评论，等你确认退货流程是对的做法之后我再标为已解决。&#x22; },
  ] }"
    />
  </Step>

  <Step>
    ### 定稿后拆成任务 [#定稿后拆成任务]

    待定问题都解决、评论都处理完之后，让队友把定稿的 P0 需求拆成任务挂到看板上：

    <Prompt>
      待定问题都解决了，把 PRD 标为定稿，把 P0 需求拆成任务。
    </Prompt>
  </Step>
</Steps>

**这个流程不需要你批准任何操作：** 文档在你的工作区内协作，不涉及对外发送。哪些操作需要你签字批准，看[控制](/ai-teammates/control)。

## 用得更好的几个提示 [#用得更好的几个提示]

| 提示                | 说明                                          |
| ----------------- | ------------------------------------------- |
| 给问题，不给提前定好的方案     | 一个提前定好的方案会跳过本该问出来的问题，也可能错过一个更好的方案或一个被忽略的约束。 |
| 定稿前先送去做可行性评审      | 一份没被真正会开发的人看过的 PRD，只是一份格式工整的愿望清单。           |
| P0/P1 和时间线的判断留给团队 | 队友会标出"要的东西"和"现实能做到的东西"之间的冲突，不会自己拍板解决。       |
| 在同一条评论下回复来修订      | 逐条修订只改被评论到的那一节，不是整篇重写。                      |

## 常见问题 [#常见问题]

<Accordions type="single">
  <Accordion title="队友会自己判断哪个需求是 P0 还是 P1 吗？">
    不会。它负责问清楚一份 PRD 需要的问题、起草结构，但优先级和可行性的判断留给你和团队。
  </Accordion>

  <Accordion title="如果某个需求做不出来会怎样？">
    会被标成一个待定问题，而不是悄悄改掉。队友不会替"要的东西"和"现实能做到的东西"之间的冲突选边。
  </Accordion>

  <Accordion title="评审在哪里进行？">
    在 Notion 里，不在 Helio 聊天里。评审人在同一份文档上评论、编辑，队友跟进未解决的评论，只修订被评论到的部分。
  </Accordion>

  <Accordion title="PRD 定稿之后会发生什么？">
    定稿的 P0 需求会被拆成任务挂到看板上。
  </Accordion>
</Accordions>

<Cards>
  <Card title="R&D & Product" href="/use-cases/rd-product" description="返回研发与产品场景总览。" />

  <Card title="下达指令" href="/ai-teammates/give-instructions" description="告诉队友你们的 PRD 模板和写作规范。" />

  <Card title="记忆" href="/ai-teammates/memory" description="让队友记住你们的文档规范，之后自动套用。" />
</Cards>