# 盯紧会议邮件仓库 (/zh/use-cases/team-ops/personal-assistant)



<Callout type="info">
  这位队友不只是做摘要,它还要判断每条信息该去哪,而路由规则和摘要本身一样重要。会议纪要私信给负责人,绝不发群。研发相关的 Bug 或功能请求,建一个真实的 Helio Task;GTM 或运营事项,只在纪要里标一条待办,不建 Task。工具断连或权限报错,在当天日报里上报、等人工处理,不会自己反复重试。系统通知和噪音邮件直接忽略,不会为这些打扰你。规则说一次,它会一直照着执行,不用你重复交代。
</Callout>

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

<Prompt>
  你是我的个人助理,帮我盯着邮箱、会议纪要、日历和代码仓库,把我必须回复、必须决策、必须 review 和容易遗漏的事情找出来。每天固定时间给我发一份简报,按“必须今天处理 / 可以委托 / 等别人回复 / 仅供参考”分类,给每个必须处理的事项写一句建议动作。研发相关的 Bug 或功能请求帮我建一个 Helio Task;GTM 或运营类的事项,在简报里标一条待办就行,不用建 Task。哪个工具连接断了,不要自己反复重试,直接在当天的简报里告诉我,等我来处理。
</Prompt>

<LivePreview component="NewThread" scenario="{ draft: &#x22;你是我的个人助理,帮我盯着邮箱、会议纪要、日历和代码仓库,把我必须回复、必须决策、必须 review 和容易遗漏的事情找出来。每天固定时间给我发一份简报,按“必须今天处理 / 可以委托 / 等别人回复 / 仅供参考”分类,给每个必须处理的事项写一句建议动作。研发相关的 Bug 或功能请求帮我建一个 Helio Task;GTM 或运营类的事项,在简报里标一条待办就行,不用建 Task。哪个工具连接断了,不要自己反复重试,直接在当天的简报里告诉我,等我来处理。&#x22; }" />

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

这位 AI 队友会主动盯着 Lark/飞书会议、Gmail 和 GitHub,不用等你开口要一份纪要或邮件汇总。每次会议后,它会把结构化纪要——决策事项、待办、背景、争议点——私信发给负责跟进的人,绝不发到群里。它还会分类你的收件箱,把回复草稿留给你确认后才发送,同时挑出需要处理的付款事项和值得关注的 SEO 通知,忽略掉噪音。到了日终,一份日报会汇报还没闭环的事——一封没回的邮件、一个快过期的 Token、一处断掉的连接——并持续提醒,直到真正解决,而不是提一次就算完。

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

<Steps>
  <Step>
    ### 雇用一位 GTM 队友,把 bio 改成这份工作本身,而不是通用模板 [#雇用一位-gtm-队友把-bio-改成这份工作本身而不是通用模板]

    打开左侧边栏的 **AI Teammates**,点击 **Hire AI Teammate**,选择 **GTM Lead** 模板。它默认的 bio 讲的是协调营销内容产出,在 Profile 步骤把它换掉,让队友一开始就知道这是一份信息运营的活,不是内容生产:

    <Prompt>
      你是我们负责信息运营的 GTM 队友,主动监听会议录制、邮件往来和代码仓库动态,不用等我开口。每次会议后,把结构化纪要(决策事项/待办/背景/争议点)私信给负责人,绝不发到群里。研发相关的 Bug 或功能请求要建 Helio Task;GTM/运营事项只在纪要里标待办,不建 Task。工具断连或权限出错时,在当晚日报里上报,不要自己反复重试。记住谁负责什么,跨会议、跨周期不用重新解释。
    </Prompt>

    确认名字后点击**创建队友**,它会落到自己的频道里,之后下面的内容都在那里发给它。[雇用详情 →](/ai-teammates/hire-an-ai-teammate)

    <LivePreview component="CreateAssistantPage" scenario="{ focus: &#x22;profile&#x22;, initialState: { start: &#x22;template&#x22;, templateRef: &#x22;@helio/gtm-lead&#x22;, name: &#x22;GTM Lead&#x22;, bio: &#x22;你是我们负责信息运营的 GTM 队友,主动监听会议录制、邮件往来和代码仓库动态,不用等我开口。每次会议后,把结构化纪要(决策事项/待办/背景/争议点)私信给负责人,绝不发到群里。研发相关的 Bug 或功能请求要建 Helio Task;GTM/运营事项只在纪要里标待办,不建 Task。工具断连或权限出错时,在当晚日报里上报,不要自己反复重试。记住谁负责什么,跨会议、跨周期不用重新解释。&#x22; } }" />
  </Step>

  <Step>
    ### 按信息源真正的主次顺序连接 [#按信息源真正的主次顺序连接]

    会议是信息主源头,所以先把 Lark/飞书接好,再接 Gmail,最后接 GitHub。三者的接入方式不同。Lark/飞书不是 Tools 里的标准 OAuth 卡片:它通过飞书开放平台的自建应用接入,是一次性的管理员级配置,不是"登录、确认授权"那种流程。Gmail 是最简单的一种——这位队友自己 Tools 里的 per-teammate OAuth 授权:打开连接、登录、确认授权即可。GitHub 是两层设置:先由工作区管理员在 Settings → Integrations 里给整个组织装一次 Helio GitHub App,装完之后才能在这位队友自己的 Tools 里,把它该盯的具体仓库(比如存放用户访谈记录的那个)授权给它。[连接你的工具 →](/connect/connect-tools-to-ai-teammates)

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

  <Step>
    ### 给它一场真实的会议,而不是测试用的转写稿 [#给它一场真实的会议而不是测试用的转写稿]

    拿一场真实录制试一下,确认它按 SOP 的格式回来(决策事项、待办、背景、争议点),而且是私信发给你,不是发到群里:

    <Prompt>
      总结一下昨天下午三点的合作方通话。按决策事项、带负责人的待办、背景信息、还没解决的争议点这个结构整理,私信发给我,不要发到团队频道。
    </Prompt>

    <LivePreview
      component="AssistantChat"
      scenario="{ assistantName: &#x22;GTM Lead&#x22;, messages: [
    { author: &#x22;user&#x22;, text: &#x22;总结一下昨天下午三点的合作方通话。按决策事项、带负责人的待办、背景信息、还没解决的争议点这个结构整理,私信发给我,不要发到团队频道。&#x22; },
    { author: &#x22;assistant&#x22;, text: &#x22;已经拉取了录制和转写。决策事项:联合营销试点推进,范围定在 Q3。待办:Sam 负责周五前出合作方简报,他交了我就开始起草外联序列。背景:这是两周前首次沟通的后续,这次对方特意问了我们 API 的限流。争议点:分成比例还没谈拢,对方要 15%,我们回价 10%,仍未解决。以私信发给你,没有发到群里。&#x22; },
  ] }"
    />
  </Step>

  <Step>
    ### 把路由规则说一次到位:这才是让它可信,而不只是快的关键 [#把路由规则说一次到位这才是让它可信而不只是快的关键]

    纪要只是一半的工作;每条信息该去哪,和内容本身同样重要。把规则表交给它一次,之后它每次都照做,不用重复交代:

    | 信息类型          | 路由去向              |
    | ------------- | ----------------- |
    | 会议纪要          | 私信负责人,绝不发群        |
    | 研发 Bug / 功能请求 | 建一个真实的 Helio Task |
    | GTM / 运营事项    | 纪要内标一条待办,不建 Task  |
    | 工具断连 / 权限报错   | 在日报里上报,等人工处理      |
    | 系统通知 / 噪音邮件   | 直接忽略,不为此打扰你       |

    <Prompt>
      以后这样路由你发现的信息:会议纪要一律私信给我,不发群。明显是研发 Bug 或功能请求的,给它建一个 Helio Task。GTM 或运营相关的,只在纪要里标一条待办就行,不用建 Task。工具连接断了或者遇到权限报错,不要自己反复重试,在当晚日报里上报,等我来处理。系统通知和噪音邮件直接忽略。
    </Prompt>

    <LivePreview
      component="AssistantChat"
      scenario="{ assistantName: &#x22;GTM Lead&#x22;, messages: [
    { author: &#x22;user&#x22;, text: &#x22;以后这样路由你发现的信息:会议纪要一律私信给我,不发群。明显是研发 Bug 或功能请求的,给它建一个 Helio Task。GTM 或运营相关的,只在纪要里标一条待办就行,不用建 Task。工具连接断了或者遇到权限报错,不要自己反复重试,在当晚日报里上报,等我来处理。系统通知和噪音邮件直接忽略。&#x22; },
    { author: &#x22;assistant&#x22;, text: &#x22;明白了,会议纪要只走私信,研发相关的建 Task,GTM 事项留在纪要里当待办,连接断了就在日报里等你处理而不是自己重试,纯噪音的邮件我会直接过滤掉。这套规则我会一直照做,不会再问你一遍。&#x22; },
  ] }"
    />
  </Step>

  <Step>
    ### 把每晚的日报做成自动化 [#把每晚的日报做成自动化]

    与其每天都记得去要一次状态汇报,打开左侧边栏的 **Automations**,点击 **Create via Chat**,在打开的 New Thread 输入框上方选这位队友:

    <Prompt>
      每天晚上 10 点,扫描过去 12 小时内新出现的会议录制,检查 GitHub 和 Gmail 的连接状态是否正常,统计还有多少重要邮件没回复。汇总今天的亮点和之前还没闭环的事项,然后把日报私信发给我。
    </Prompt>

    <LivePreview component="NewThread" scenario="{ populated: false }" />
  </Step>
</Steps>

**只有发送邮件回复需要你批准:** 读取会议、邮件和仓库动态、创建 Task、把纪要或日报私信发给你,这些都会自主完成——起草并发送一封真正的回复,是唯一会离开 Helio 的动作,所以会先暂停等你确认。完整的批准边界见[控制](/ai-teammates/control)。

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

| 提示                | 说明                                                                                                                                      |
| ----------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| 按优先级顺序连接信息源       | Lark/飞书需要先在飞书开放平台做一次性的管理员配置,其他才能跑起来;先接好它,再接 Gmail 简单的 per-teammate OAuth,最后接 GitHub 的两层设置——工作区管理员先给整个组织装一次 GitHub App,你再单独把具体仓库授权给这位队友。 |
| 先用一场真实录制试一遍,别用占位稿 | 拿一场真实的通话验证纪要的结构(决策事项、待办、背景、争议点)和"私信不发群"的路由规则,再放心用。                                                                                      |
| 把路由表一次性完整交给它      | 会议纪要、研发 Bug、GTM 事项、断连、噪音,各自的去向都不一样;把完整表格交给它,不用它逐条猜。                                                                                     |
| 把每晚的检查做成自动化       | 别指望自己每晚都记得去问;在 Automations 里设置一次,让它固定时间自己跑。                                                                                             |

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

<Accordions type="single">
  <Accordion title="它会不会没经过我同意就把邮件发出去?">
    不会。它会自己起草回复,但每次真正发送前都会先等你批准。
  </Accordion>

  <Accordion title="会议纪要会发到哪里?">
    一律私信给负责跟进的人,绝不会发到群里。
  </Accordion>

  <Accordion title="它发现的 GTM 或运营事项会怎么处理?">
    只会在纪要里标一条待办,不会建 Helio Task。会建 Task 的是研发相关的 Bug 或功能请求。
  </Accordion>

  <Accordion title="如果某个工具连接断了怎么办?">
    它不会自己反复重试,而是把这件事上报到当晚的日报里,一直等到你处理为止。
  </Accordion>

  <Accordion title="Lark、Gmail、GitHub 是不是要一起接好?">
    不用,按优先级顺序接就行。会议是主信息源,所以先接 Lark/飞书(飞书开放平台的一次性管理员配置),再接 Gmail(简单的 per-teammate OAuth),最后接 GitHub(工作区管理员先装一次组织级 App,再单独给这位队友授权具体仓库)。
  </Accordion>
</Accordions>

<Cards>
  <Card title="团队与个人效率" href="/use-cases/team-ops" description="返回团队与个人效率场景总览。" />

  <Card title="筛选候选人" href="/use-cases/industry-specialized/recruiting-sourcing" description="把一份职位描述变成打分排序的候选人名单。" />

  <Card title="一人公司配AI团队" href="/use-cases/industry-specialized/solo-founder-team" description="覆盖一家小公司需要的每个职能。" />
</Cards>