会议驱动的工作流程 Loop
如何用 AuraManager 的 Loop 工程模版把"会后跟进"从人肉流程变成自动流程——腾讯会议 + Get笔记 记录,数字员工自动执行,人只需要确认审批和测验校验。
会议驱动的工作流程 Loop
本文解决一个痛点:会后不再需要人去盯人、手动建卡、逐个催进度。通过 AuraManager 的 Loop 工程模版,会议产出"做什么" → 数字员工自动领走 → 人只需要确认和验收。
一、问题:会议开完了,然后呢?
一次产品站会开完,白板上列了五个待办:
- 前端把登录页的暗黑模式适配做了
- 后端把支付接口的错误码统一一下
- 运维把测试环境重新部署一版
- 运营把上周的转化数据拉出来
- 设计把新版 Dashboard 的交互稿发群里
然后呢?你得去跟进。 打开 Linear / Jira / Notion,给每个人建卡片、@当事人、盯进度、催状态、验收结果。一个人当项目经理用,这些"管理"和"协作"的跟进动作,吃掉的时间可能比干活本身还多。
更头疼的是:这些事不是一次性的。 每周站会都会产出新一批待办,循环往复。
AuraManager 的 Loop 工程模版,就是为这个场景设计的:把"会后跟进"这件事从人肉流程变成自动流程。
二、核心思路:让人做决策,让数字员工做执行
会议驱动 Loop 的本质一句话:
会议产出"做什么" → 数字员工自动领走 → 人只需要确认和验收。
它和传统项目管理的区别:
| 环节 | 传统方式 | Loop 方式 |
|---|---|---|
| 记录待办 | 人手动在工具里建卡片 | 腾讯会议 / Get笔记 自动识别并创建 Issue |
| 分配任务 | 人手动 assign | 按规则自动分配给对应数字员工 |
| 执行任务 | 人干活 | 数字员工干活 |
| 跟进进度 | 人逐个问、催 | Issue 看板一眼看完,数字员工自己更新状态 |
| 验收 | 人检查 | 数字员工提交结果,人一键确认或驳回 |
人从"管理者 + 执行者"退到"决策者"的位置上。 你负责说"要做这个"和"这个通过了",中间的活儿交给数字员工。
三、架构全景
一次完整的会议驱动 Loop 包含四个环节:
┌─────────────┐ ┌──────────────────┐ ┌────────────────┐ ┌─────────────┐
│ 1. 会议记录 │ ──→ │ 2. 内容识别与建卡 │ ──→ │ 3. 数字员工执行 │ ──→ │ 4. 人工验收 │
└─────────────┘ └──────────────────┘ └────────────────┘ └─────────────┘
│ │ │ │
腾讯会议 Skill Get笔记 / 腾讯会议 绑定了对应 Skill 审批人收到
Get笔记 Skill 解析会议纪要 的数字员工 通知,review
语音转文字 识别 人名 / 项目名 自动认领任务 通过或驳回
创建 Issue 到指定项目
状态:Todo环节 1:会议记录
- 腾讯会议 Skill 接入后,数字员工可以直接获取会议录制、转写全文、AI 智能纪要
- Get笔记 Skill 让数字员工能保存、搜索和管理会议笔记内容
环节 2:内容识别与建卡
- 从会议纪要中识别出人名(谁负责)、项目名(属于哪个项目空间)、动作项(要做什么)
- 在 AuraManager 中自动创建 Issue 卡片,放入对应项目空间的 Todo 列
- 截止日期、优先级等字段可以从会议上下文推断
环节 3:数字员工执行
- Issue 被分配到对应数字员工后,自动入队执行
- 数字员工根据绑定的 Skill(代码、部署、数据分析等)完成实际工作
- 进度实时更新在 Issue 时间线上
环节 4:人工验收
- 数字员工完成后,Issue 状态变为 In Review
- 指定审批人收到通知
- 通过 → Done;驳回 → 数字员工继续修改
四、实战搭建:从零开始搭一个会议驱动的产品站会 Loop
下面以每周产品站会为例,搭建一个完整的 Loop。
Step 1:安装必备 Skill
首先为负责会议跟进的数字员工安装两个 Skill:
腾讯会议 Skill:
- 在 Skill 市场搜索"腾讯会议",点击安装
- 选择目标数字员工,填入腾讯会议 Token
- 安装完成后,数字员工即具备会议管理能力
Get笔记 Skill:
- 在 Skill 市场搜索"Get笔记",点击安装
- 选择同一个数字员工,填入 Client ID 和 API Key
- 数字员工可以将会议纪要保存到 Get笔记 并检索历史
Step 2:创建项目空间
为产品站会的待办事项创建一个专门的 Project:
- 在 AuraManager 侧边栏点击 "Projects" → 新建
- 项目名称:
产品站会待办 - 图标选一个合适的 emoji
- 这个 Project 就是会议待办的"落点"
Step 3:配置数字员工
为每个职能方向配置一个数字员工(或共用一个全能型数字员工),关键配置:
- Instructions:写明它的职责范围(如"你是前端开发工程师,负责 Web 端的功能开发和 bug 修复")
- Skills:挂载腾讯会议 Skill、Get笔记 Skill,以及对应技术栈的 Skill
- Custom Env:配好必要的 Token 和 API Key
Step 4:搭建 Autopilot 触发器
创建一条 Autopilot 规则来实现"会议结束后自动跟进":
aura autopilot create \
--title "产品站会自动跟进" \
--assignee <agent-id> \
--execution-mode create_issue然后给它配置触发器:
aura autopilot trigger-add <autopilot-id> \
--kind schedule \
--cron "0 10 * * 1" \
--timezone "Asia/Shanghai"这里 cron 设为每周一上午 10:00 —— 站会结束后数字员工立刻开始跟进。
如果会议时间不固定,也可以用 Webhook 触发:
aura autopilot trigger-add <autopilot-id> \
--kind webhook这会生成一个 webhook URL,可以在腾讯会议结束后由其他自动化流程 POST 过来触发。
Step 5:编写 Autopilot 的 Issue 模板
Autopilot 需要告诉数字员工具体做什么。在 issue_title_template 和 Description 里写好指令:
标题模板:
产品站会跟进 - {{date}}Description(告诉数字员工要做什么):
你负责从本周产品站会的会议记录中提取所有待办事项,并按以下规则处理:
1. **检索会议内容**:
- 使用腾讯会议 Skill 获取最近一次产品站会的录制转写和 AI 纪要
- 如果有 Get笔记 中保存的会议记录,一并检索
2. **识别待办**:
- 从会议内容中识别所有"要做的事"(action items)
- 对每一项,提取:负责人、任务描述、截止时间(如果有)、关联项目
3. **创建 Issue**:
- 对每个待办,在项目"产品站会待办"下创建 Issue
- 标题格式:[站会] {"{{"}任务简述{"}}"}
- Assignee 设置为对应的数字员工(按职能匹配:前端→前端数字员工,后端→后端数字员工)
- 优先级按紧急程度设置
4. **发布总结**:
- 在站会待办项目的父 Issue 下评论,列出本次识别的所有待办和负责人
5. **无法确定的事项**:
- 如果某个待办无法确定负责人或项目,在评论区标记 @owner 人工判断Step 6:设置审批门
在 Autopilot 中加入人工审批节点:
- 数字员工为每个待办创建 Issue,状态为
todo - 负责人(人类)收到通知,review Issue 的内容和指派是否正确
- 确认无误后,把 Issue 状态改为
in_progress→ 数字员工开始干活 - 数字员工完成后,状态自动变为
in_review - 人类验收:通过 →
done,驳回 → 评论里说明原因,数字员工继续改
这个审批流的"确认 → 放行"动作,就是"指定人确认审批和测验校验"——人是质量 Gatekeeper,不是执行者。
五、实战场景扩展
场景 1:Bug 三方会议 → 自动修 Bug
客户报了一个线上 bug,开腾讯会议拉上前后端排查。会议结束后:
- 腾讯会议转写中识别到 "Bug 出现在支付回调"、"前端状态没重置"、"后端日志里有个 NPE"
- Loop 自动创建三个 Issue,分别 assign 给前端、后端、测试数字员工
- 后端数字员工查日志、定位 NPE、提交 fix PR
- 前端数字员工改状态重置逻辑、提交 fix PR
- 测试数字员工自动跑回归,把通过/失败的用例贴在 Issue 评论里
- 人只看一眼 PR diff,点 approve
场景 2:周报自动生成
每周五下午 17:00,Autopilot 触发:
- 数字员工检索本周所有已完成 Issue(按 Project 和 assignee 聚合)
- 从 Get笔记 中提取本周会议决策要点
- 自动生成周报初稿(Markdown 格式),发布到指定 Issue 下
- 团队负责人 review 后略改几笔,直接发出
场景 3:设计评审 LOOP
设计稿评审会上确定了 5 处修改:
- 腾讯会议纪要自动识别修改点
- Loop 创建 Issue 分配给设计数字员工(如果有 Figma Skill 则直接改)
- 涉及前端实现的,自动创建关联 Issue assign 给前端数字员工
- 人在 Figma 里验收视觉,在 Staging 环境验收前端实现
六、最佳实践总结
1. 从一个小 Loop 开始
不要一上来就试图把所有会议都自动化。挑一个最规律、产出最明确的会议(比如每周站会),先跑通一个 Loop。跑顺了再复制到其他场景。
2. 会议纪要的质量决定 Loop 的质量
- 会议中明确说出每个待办的负责人、截止时间、所属项目
- 这跟写 prompt 一个道理:输入越清晰,数字员工的输出越准确
- 团队养成习惯:每说完一个待办,顺便说一句"负责人是 XX,下周三前"
3. 审批节点不能省
数字员工干活快,但不一定对。Loop 模板里默认带人工确认环节——别关掉它。 审批门是你最后的保险。
一个好的审批比例:
- 日常任务:数字员工直接做,做完批量 review(10 个里抽 2 个细看)
- 关键任务:必须逐个人工确认后才放给数字员工
- 高风险操作(涉及支付、数据库变更、线上配置):数字员工只做分析和建议,人不点头不执行
4. 用 Project 做隔离
每个会议的待办放进独立的 Project,不同会议之间不混。这样:
- 一眼看出每个会议的跟进率
- 数字员工不会搞混不同会议的上下文
- 月复盘时可以直接按 Project 统计产出
5. 善用 Get笔记 做知识沉淀
- 把每次会议纪要存入 Get笔记 的对应知识库
- 下次开会前,让数字员工先检索历史相关纪要
- "这个我们上次聊过"不再靠人记忆
6. 数字员工的分工要明确
- 按职能拆分数字员工,而不是一个数字员工干所有事
- 前端一个、后端一个、运维一个、数据一个
- 每个数字员工的 Instructions 写清楚边界——"你是前端数字员工,只处理 Web 端问题,不要碰数据库"
这篇文章的核心结论就是一句话:会后不再有"人去盯人",只有数字员工排队领活、人最后把关。这就是 Loop 工程模版让会议跟进从"费心"变成"省心"的方式。