# 组织你的一支技术Team (/zh/use-cases/rd-product/ai-team)



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

<Prompt>
  你是一位技术团队搭建 AI。请为这个项目建立一支 AI 技术团队，并跑通每日进展汇总：项目是[项目目标、当前阶段、仓库/文档/频道位置、已有的人或 AI 队友]。先判断这个项目需要哪些角色，比如 PM、工程、代码审查、测试/QA、发布运维，为每个角色安排好第一个任务和交接对象，需要连接 GitHub、Notion 等工具时主动提醒我。之后每天自动汇总进展、阻塞、谁需要接手，以及哪些结果需要我审批。
</Prompt>

<LivePreview component="NewThread" scenario="{ draft: &#x22;你是一位技术团队搭建 AI。请为这个项目建立一支 AI 技术团队，并跑通每日进展汇总：项目是{项目目标、当前阶段、仓库/文档/频道位置、已有的人或 AI 队友}。先判断这个项目需要哪些角色，比如 PM、工程、代码审查、测试/QA、发布运维，为每个角色安排好第一个任务和交接对象，需要连接 GitHub、Notion 等工具时主动提醒我。之后每天自动汇总进展、阻塞、谁需要接手，以及哪些结果需要我审批。&#x22; }" />

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

组织你自己的技术团队，是把每个角色各请一位 AI 队友进同一个频道，而不是让一个通才队友什么都做。PM 在动工之前先把目标拆成里程碑，每个角色交付自己的产出，代码审查员和 QA 这样的第二双眼睛补上第一遍漏掉的问题。当两个角色真的有分歧时，这会被摆成一个待你处理的冲突，而不是被谁先动手的那个悄悄定了。

<Callout type="warn">
  队友之间的互审代替不了你的审查。代码审查员在你看到 PR 之前先抓出一个 bug 是件好事，但合并 PR、推送到 main、对外发送这些事，哪怕频道里所有 AI 角色都觉得没问题，依然要等你。如果两个角色是真的有分歧（工程师说某个需求按现在的写法做不出来，PM 说这条不能改），这应该被标成一个待你处理的冲突，而不是靠哪个角色还在继续往下做来"解决"。
</Callout>

## 推荐配置 [#推荐配置]

| 队友      | 模板      | 建议添加的技能     |
| ------- | ------- | ----------- |
| 产品      | 产品管理专家  | 网络搜索        |
| 研究      | 深度研究写手  | 网络搜索        |
| 设计      | UI 设计师  | 网络搜索        |
| 软件开发    | 代码开发专家  | GitHub、网络搜索 |
| 代码审查与质量 | 全栈代码审查官 | GitHub      |

**合并、推送、对外发送仍需你批准：** 除此之外——起草、互审、角色间交接——全程自动运行。完整边界见[控制](/ai-teammates/control)。

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

<Steps>
  <Step>
    ### 每个角色雇一位队友 [#每个角色雇一位队友]

    打开左侧边栏的 **AI Teammates**，点击 **Hire AI Teammate**，为项目需要的每个角色重复这个过程。给每一位起一个你会真的打出来的名字（比如 PM 叫"Priya"，工程叫"Sam"），因为下面你会用名字 @ 他们。给 PM 换一个 bio，让拆解发生在动工之前：

    <Prompt>
      你是这个项目频道的 PM。给你一个目标，动工之前先拆成里程碑和第一版范围。当其他角色标出某个需求不可行或有冲突时，不要悄悄替它们选边，要把这个冲突交给频道里的人来定。
    </Prompt>

    <LivePreview component="CreateAssistantPage" scenario="{ focus: &#x22;profile&#x22;, initialState: { start: &#x22;template&#x22;, templateRef: &#x22;@helio/product-manager&#x22;, name: &#x22;Priya&#x22;, bio: &#x22;你是这个项目频道的 PM。给你一个目标，动工之前先拆成里程碑和第一版范围。当其他角色标出某个需求不可行或有冲突时，不要悄悄替它们选边，要把这个冲突交给频道里的人来定。&#x22; } }" />
  </Step>

  <Step>
    ### 把他们都放进同一个频道 [#把他们都放进同一个频道]

    为这个项目建一个频道，把刚雇的每一位队友都邀请进来，加上你自己。这是团队协调的共享空间，不是五个分开的私信。

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

  <Step>
    ### 给全队简报，让 PM 先拆解 [#给全队简报让-pm-先拆解]

    <Prompt>
      你是一位技术团队搭建 AI，擅长根据项目目标设计 AI 队友角色、分工、协作频道、任务流和每日推进节奏。请为我建立一个“AI 技术团队组建与每日推进”的自动化任务，项目是：[项目目标、当前阶段、仓库/文档/频道位置、我已有的人或 AI 队友]。第一天请先判断这个项目需要哪些 AI 队友，至少给出 PM、工程、代码审查、测试/QA、发布/运维这些角色是否需要；为每个角色写清楚职责、首个任务、输入资料、交付结果和交接对象。然后帮我规划应该创建哪些频道、任务和每日同步机制，让这支 AI 技术 Team 能开始跑第一轮工作。之后每天自动汇总这支技术 Team 的进展、阻塞、谁需要接手、哪些任务该拆小、哪些结果需要我审批。优先使用 Helio 内的频道、任务、文档和公开资料先跑；如果需要 GitHub、Notion、Slack 等官方直连工具，请主动引导我在 Integrations 连接；如果必须访问网页后台，请用 browser 引导我登录。
    </Prompt>

    Priya 发出拆解结果之后，按名字分工：

    <Prompt>
      @Priya 先拆需求。@Sam，等文档定了之后做第一版 MVP。每个角色都把自己的产出发在这个频道里，不用等我来转达。
    </Prompt>
  </Step>

  <Step>
    ### 让角色并行推进，而不只是排队 [#让角色并行推进而不只是排队]

    互不依赖的部分不用排队等：

    <Prompt>
      @Sam 在做的时候，你们俩能不能并行开始：一个查竞品格局，一个找三个参考设计。都做好了发在这里，如果发现该改文档的地方就标出来。
    </Prompt>
  </Step>

  <Step>
    ### 两个角色意见不一致时，这是个信号，不是个 bug [#两个角色意见不一致时这是个信号不是个-bug]

    一支真实团队不会永远意见一致，这支也不该。重要的是真实的分歧要被摆出来，而不是被悄悄消化掉：

    <LivePreview
      component="AssistantChat"
      scenario="{ assistantName: &#x22;Priya&#x22;, messages: [
    { author: &#x22;user&#x22;, text: &#x22;Sam，MVP 做得怎么样了？&#x22; },
    { author: &#x22;assistant&#x22;, text: &#x22;卡在一件事上，不是代码问题：需求写的是实时库存同步，但我们对接的供应商 API 只支持 15 分钟轮询，没有 webhook。我可以照轮询来做，但那和『实时』承诺的体验不一样。Priya 的文档没说清楚哪个才是真正要的，我觉得这不该我自己定，赶在做错之前先标给你们俩。&#x22; },
  ] }"
    />

    <LivePreview
      component="AssistantChat"
      scenario="{ assistantName: &#x22;Priya&#x22;, messages: [
    { author: &#x22;user&#x22;, text: &#x22;Sam 说得对，你怎么看？&#x22; },
    { author: &#x22;assistant&#x22;, text: &#x22;文档写实时，是因为最初的需求听着是这个意思，不是因为我们真的确认过这是硬性要求。既然供应商有这个限制，我倾向于第一版先放宽成 15 分钟同步，把真正的实时标成第二版换供应商的依赖项，但这是个产品取舍，不该由我和 Sam 两个人之间定，你来拍板。&#x22; },
  ] }"
    />
  </Step>

  <Step>
    ### 用一个真实任务验证协作，不是演示 [#用一个真实任务验证协作不是演示]

    派一个小目标，观察不同队友是否各自认领、产出、相互交接，而不是一个人全干、其他人沉默。
  </Step>
</Steps>

<Callout type="info">
  这是一个频道里有好几位 AI 队友加上你自己，不是拆成多个 workspace。任何时候任何人都能 @ 任意一位队友，不用等轮到那个角色发言。
</Callout>

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

| 提示                 | 说明                             |
| ------------------ | ------------------------------ |
| 给每个队友起一个你会真的打出来的名字 | 你会一直用 @ 来指挥角色，真名字比通用角色标签好用得多。  |
| 先让 PM 过一遍目标        | 直接把原始需求丢给工程师会跳过拆解这一步，后面容易范围漂移。 |
| 让互不依赖的部分并行         | 研究、设计、开发如果彼此不依赖，不用排队等。         |
| 把分歧当信号，不是噪音        | 两个角色冲突时，那是真实信息提前浮现——该解决，不该压下去。 |

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

<Accordions type="single">
  <Accordion title="队友之间互审能代替我的审查吗？">
    不能。代码审查员在你看到 PR 之前先抓出一个 bug 是好事，但合并、推送到 main、对外发送依然要等你批准。
  </Accordion>

  <Accordion title="两个角色意见不一致会怎么样？">
    会被标成一个待你处理的公开冲突，而不是被谁先动手的那个悄悄定了。
  </Accordion>

  <Accordion title="这是拆成多个独立空间吗？">
    不是。这是一个频道里有好几位 AI 队友加上你自己。任何时候都能 @ 任意一位队友。
  </Accordion>

  <Accordion title="角色之间必须按顺序来吗？">
    不用。研究和设计这类互不依赖的部分可以并行，不用排队。
  </Accordion>
</Accordions>

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

  <Card title="写一份 PRD" href="/use-cases/rd-product/prd-writer" description="团队动工之前，PM 角色要先产出的东西。" />

  <Card title="审批操作" href="/ai-teammates/control#where-approvals-appear" description="让关键操作在执行前经你审查。" />
</Cards>