meeting-transcription

会议转录

此技能可让 AI Agent 将会议录音处理为结构化、可执行的文档。Agent 会处理从原始音频输入到说话人分离、转录和智能摘要的完整流程。输出包括带时间戳和说话人标签的转录稿、关键讨论要点的简明摘要、已作出的决定列表，以及明确标注负责人和截止日期的行动项。

工作流

1. 导入并验证音频输入。 接收会议音频文件，并验证其格式是否受支持：MP3、WAV、M4A、FLAC、OGG 或 WebM。检查文件大小、时长和声道数（单声道还是立体声）。如果音频格式不常见，请使用 FFmpeg 或类似的预处理工具将其转换为 WAV 16kHz 单声道。记录文件元数据（时长、采样率、编解码器），供后续参考。

2. 预处理音频以提升质量。 应用降噪处理，抑制背景嗡声、键盘敲击声和房间回声。对录音中的音频电平进行归一化处理，以提高音量较小的说话者的音量，并降低音量较大的片段。如果录音包含多个声道（例如，立体声播客），则在每个声道对应已知说话者时拆分声道。将信噪比极低的片段标记为可能不可靠。

3. 执行说话人分离。 识别并标记录音中的不同说话者。使用声纹聚类来区分说话者，即使他们互相打断或接连快速发言。默认分配临时标签（Speaker 1、Speaker 2 等），并允许用户在处理前或处理后提供姓名映射。对于重叠语音，将片段归于主要说话者，并注明存在重叠。

4. 将音频转录为文本。 将预处理并完成说话人分离的音频输入语音转文本引擎（例如，Whisper、Deepgram、Google Speech-to-Text）。生成带时间戳的逐字或分段转录稿。恢复标点并更正大小写。对于多语言会议，检测语言切换，并以各片段的原始语言进行转录，也可选择提供行内翻译。

5. 生成结构化摘要。 分析完整转录稿，提取关键讨论主题、已作出的决定、待解决问题和行动项。将相关讨论片段归入主题部分。对于每项行动，确定负责人（使用说话人标签或姓名）、任务描述和提及的截止日期。生成包含明确分节的摘要文档：概览、关键讨论要点、决定、行动项和后续事项。

6. 格式化并交付输出。 按照所需格式生成最终输出：Markdown、JSON 或纯文本。将完整的带时间戳转录稿和结构化摘要作为单独的章节或文件一并提供。如果启用了日历集成，则与日历事件数据交叉核对会议，并在输出标题中自动填入会议标题、参会者列表和议程。

用法

向 Agent 提供音频文件的路径，并可选提供说话人姓名映射、输出格式偏好和语言提示。Agent 将返回完整转录稿和结构化摘要。

提示词格式：

Transcribe and summarize the meeting recording.
Audio file: [path or URL to audio file]
Speakers: [optional name mapping, e.g., "Speaker 1 = Priya, Speaker 2 = James"]
Language: [primary language, e.g., English]
Output format: [markdown / json / text]

示例

示例 1：带说话人标签的带时间戳转录稿

输入：

Transcribe the meeting at /recordings/sprint-planning-2026-02-10.m4a
Speakers: Speaker 1 = Priya, Speaker 2 = James, Speaker 3 = Dana
Output format: markdown

输出（转录稿节选）：

# Sprint Planning — February 10, 2026

Attendees: Priya (Engineering Lead), James (Product Manager), Dana (Designer)
Duration: 34 minutes

---

[00:00:12] Priya: Alright, let's kick off sprint planning. James, can you
walk us through the priorities for this sprint?

[00:00:18] James: Sure. The top item is the checkout flow redesign. We got
feedback from the beta group that the three-step process is causing drop-off
at step two. Dana, you had some mockups ready?

[00:00:31] Dana: Yes, I've simplified it to a single-page layout. The address
and payment fields are on the same screen now with a collapsible order summary
on the right. I'll share the Figma link after this call.

[00:00:48] Priya: That sounds good. How much engineering effort are we looking
at? I'm thinking this is a two-sprint task if we include the backend changes
for the new validation logic.

[00:01:02] James: Can we scope it so the frontend ships this sprint and the
backend validation follows in the next one?

[00:01:10] Priya: That works. We can use client-side validation as a stopgap.
I'll create the tickets after this meeting.

[00:01:22] James: Great. Second priority is the analytics event tracking.
We're missing conversion events on the pricing page.

[00:01:35] Dana: No design implications there. It's purely instrumentation.
No UI changes needed.

示例 2：包含行动项的结构化摘要

输出（同一会议的摘要）：

## Meeting Summary

### Overview
The sprint planning session covered three topics: the checkout flow redesign,
analytics event tracking for the pricing page, and an update on the mobile
onboarding experiment. The team agreed to split the checkout work across two
sprints and prioritize the analytics instrumentation for immediate deployment.

### Key Discussion Points
- **Checkout flow redesign:** Beta feedback indicates 35% drop-off at step 2.
  Dana presented a single-page layout. The team agreed on a phased rollout:
  frontend this sprint, backend validation next sprint.
- **Analytics event tracking:** Conversion events are missing on the pricing
  page. No design changes required. Estimated at 3 story points.
- **Mobile onboarding experiment:** A/B test results not yet significant.
  The team will extend the experiment by one week.

### Decisions
1. Checkout redesign split: frontend in Sprint 14, backend in Sprint 15.
2. Client-side validation will serve as a temporary stopgap.
3. Analytics instrumentation ships this sprint with no design dependency.
4. Mobile onboarding experiment extended by one week.

### Action Items
| Owner | Task                                              | Deadline  |
|-------|---------------------------------------------------|-----------|
| Priya | Create Jira tickets for checkout frontend work    | Feb 10    |
| Dana  | Share Figma link for single-page checkout mockup  | Feb 10    |
| Priya | Estimate backend validation effort for Sprint 15  | Feb 12    |
| James | Write analytics event spec for pricing page       | Feb 11    |
| James | Schedule decision review for mobile onboarding    | Feb 17    |

### Follow-ups
- Priya to sync with the backend team on API contract changes.
- Dana to run a usability test on the single-page layout with 3 users.
- James to share the A/B test dashboard link in Slack for monitoring.

最佳实践

• 尽可能使用立体声或多声道录音。 为每位发言者分配独立音频声道可大幅提高说话人分离的准确性。鼓励团队使用支持按参与者分轨录音的会议平台。
• 提前提供说话人姓名映射。 预先映射说话人身份可以避免转录后手动重新标注，并支持生成更丰富的摘要，其中可注明行动项负责人。
• 检查低置信度片段。 将语音转文字置信度低于 0.7 的转录片段标记出来，供人工检查。这些片段通常对应多人同时说话、含糊不清或口音较重的情况。
• 将摘要控制在一页以内。 好的摘要应比转录内容更短，而不是简单复述。重点关注决策和行动项；完整细节可由有需要的人查阅转录内容。
• 在输出中将转录内容与摘要分开。 用户的需求各不相同：有人需要完整记录，有人只需要行动项。将两者作为独立章节或文件提供。
• 整合日历元数据。 当 Agent 可以访问日历事件时，自动填入会议标题、参会者名单和议程，以减少手动输入，并丰富输出的标题信息。

边缘情况

• 多人重叠发言和串话。 多人同时说话时，将片段归于声音最大的人，并添加 [crosstalk] 之类的注释。避免悄然遗漏内容。
• 非英语或多语言混合会议。 使用语言识别模型检测对话中的语言切换。以源语言转录每个片段，并可选择在方括号中附上英文译文。
• 音频质量差。 如果信噪比很低（例如，在嘈杂环境中录制的电话音频），应提醒用户转录准确性可能会降低，并用 [inaudible] 标记突出显示不确定的段落。
• 时间很长的会议（2 小时以上）。 对于长时间录音，分块处理以避免内存问题。除了整体摘要，还应生成分段摘要，帮助用户浏览内容。
• 机密或敏感内容。 如果转录内容包含个人身份信息、财务数据或法律讨论，应将输出标记为限制访问，并在已配置的情况下应用脱敏规则。