94 lines
7.1 KiB
Markdown
94 lines
7.1 KiB
Markdown
---
|
||
name: meeting-minutes
|
||
description: Transform raw audio-transcription documents into clean, structured meeting minutes. Use this skill whenever the user provides a meeting transcript — any file with timestamps and speaker labels (说话人1 / Speaker 1), ASR/speech-to-text output, 转写结果, 录音转写 — and asks to organize, summarize, or 整理 it into 会议记录 / 会议纪要 / meeting minutes / action items. Also trigger when the user uploads a transcription of a meeting, review, training session, interview, or discussion and just says "整理一下" or "帮我总结", even without the word "会议记录". Do NOT use for writing minutes from scratch (no transcript) or for translating transcripts.
|
||
---
|
||
|
||
# 录音转写 → 会议纪要
|
||
|
||
把口语化、带噪声的录音转写文档，整理成一份**详尽但不啰嗦**的正式会议纪要：所有实质信息（决议、数字、责任人、时限、分歧、疑点）一条不丢，所有口语噪声（重复、口头禅、寒暄、跑题碎语）一句不留。
|
||
|
||
成品的衡量标准：一个没参会的人读完纪要，能准确知道**会上定了什么、为什么这么定、还有什么没定、接下来谁在什么时间要做什么**。
|
||
|
||
## 工作流程
|
||
|
||
### 第 1 步：完整读取转写文件
|
||
|
||
**必须读完全文才能动笔。** 会议的决议常常在中途被推翻重定（先定方案 A，结尾改成 A+B 并存），只读开头或抽样阅读会把中间结论当成最终决议，这是此类任务最严重的错误。
|
||
|
||
- 先 `wc -c` / `wc -l` 探明文件大小，再按**行**分块读取（如 `sed -n '1,300p'`），逐块读完全部内容。
|
||
- 中文转写是多字节 UTF-8，**不要用 `head -c` 等按字节截断的方式读取**，会切断字符导致输出乱码报错；始终按行读取。
|
||
- 文件可能是 CRLF 行尾，属正常现象，无需处理。
|
||
|
||
### 第 2 步：边读边积累四类素材
|
||
|
||
读的过程中持续记录，读完即可直接成文：
|
||
|
||
1. **元数据**：源文件名、音频时长、说话人数量、分句数量（转写文件头部通常自带）。
|
||
2. **同音误写词表**：见第 3 步。
|
||
3. **说话人身份线索**：见第 4 步。
|
||
4. **内容骨架**：议题切换点、每个议题下的讨论脉络、当场形成的决议（含被推翻的中间结论）、提到的待办（谁、做什么、什么时限）、被点名的人和精确数字。
|
||
|
||
### 第 3 步：同音误写校正（中文转写的核心难点）
|
||
|
||
方言口音和专业术语会让 ASR 产生大量同音/近音误写，且**同一个词在全文中会被写成多种错法**。典型规律：
|
||
|
||
- 专业缩写被写成日常词：BOM → "报幕/保姆/报模/爆品/泡沫/放牧"；VLOOKUP → "维鲁卡普"
|
||
- 行业术语被写成同音常用词：接头→"截图"、螺纹→"论文"、量程→"量产/量成/量层"、选型→"血型/雪凝/选曲"、模板→"木板"、径向/轴向→"镜像/进项/主项"
|
||
- 人名时对时错："郑工"被写成"正宫/正工"
|
||
|
||
处理规则：
|
||
|
||
- 同一上下文反复出现、读不通的词，按行业语境推断真实词义，**全文统一校正**。判断依据是上下文自洽：如果把"报幕"读成 BOM 后全文每一处都通顺，即可确认。
|
||
- 在纪要开头用一段引述（blockquote）**集中声明校正对照**（"报幕/保姆"实为 BOM 等），让读者知道整理者做过什么，也便于核对。
|
||
- **无法确认的专有名词（人名、系统名、工具名）不要硬猜**：模糊处理或标注"（名称待确认）"，并在交付时提醒用户核对。宁可标注疑点，不可编造确定性。
|
||
|
||
### 第 4 步：说话人身份归属（谨慎原则）
|
||
|
||
- 只依据**转写内部证据**归属身份：A 反复称呼 B 为"郑工"，则 B 是郑工；某人说"刘凯还有 7 个没做"且另一人应答"对，都快了"，则应答者**疑似**刘凯。
|
||
- 证据充分的写实名（如：说话人 1，会中被称"郑工"）；证据单薄的加"疑似"；没有证据的保留"说话人 N"编号。
|
||
- 在基本信息或正文中自然带出主持人、主讲人等**角色**（谁在部署工作、谁在演示、谁在记录待办），角色比名字更重要。
|
||
- 会中被提及但未必在场的人名（被点名负责某事的人）照实写入待办事项。
|
||
|
||
### 第 5 步：按模板组织成文
|
||
|
||
整体结构和逐节写法**严格参照 `references/format-template.md`**（必读），成文前对照 `references/example.md` 中的真实范例校准颗粒度和语感。骨架为：
|
||
|
||
1. 标题：`# 会议纪要：<一句话概括的会议主题>`
|
||
2. 会议基本信息（表格）+ 转写质量校正声明（blockquote）
|
||
3. 正文若干部分：**按会议实际脉络划分议题章节**，不是按时间流水账，也不是套死固定章节数
|
||
4. 会议总结与决议汇总（编号列表，关键决议加粗）
|
||
5. 待办事项（表格：# / 事项 / 责任人 / 时限或备注）
|
||
|
||
### 第 6 步：交付
|
||
|
||
- 输出为 Markdown 文件，命名 `会议纪要_<会议日期>_<一句话概括的会议主题>.md`（日期取自源文件名或转写内容），保存到工作目录或用户指定位置，日期格式：`yyyy-MM-dd`。
|
||
- 聊天回复保持简短：两三句概括会议规模与核心议题，**明确提醒用户核对**同音校正后的人名与专业术语，邀请反馈修订。不要在聊天里复述纪要内容。
|
||
|
||
## 风格红线（"详尽但不啰嗦"的具体含义）
|
||
|
||
**必须保留（详尽）：**
|
||
|
||
- 每一条实质决议、原则、要求，以及它的**理由**（"必须 1:1 配置油品，否则账实不符"——理由让纪要可信、可执行）
|
||
- 精确数字、数量、时限、责任人（"刘凯尚余 7 个""下月初至中旬高勇检查"）
|
||
- **决议的演变过程**：核心争论先呈现各方案的优缺点（适合用对比表格），再写表决与最终决议；会中先定后改的，最终决议为准、但要写明"经讨论改为"
|
||
- 分歧与遗留问题：谁提出了什么顾虑、当场未解决的问题、"会后研究"的事项
|
||
- 提出的疑点、特殊情况、边界条件（"径向件可代用于轴向，反之不可"）
|
||
|
||
**必须删除（不啰嗦）：**
|
||
|
||
- 全部口语噪声：语气词、重复、口吃式赘语（"那个那个""都都都"）、寒暄、应答碎语（"嗯""对头""好"）
|
||
- 操作演示中的现场琐碎（"你打开了没""我看下是哪个文件"），只留演示所传达的**功能逻辑和操作流程**
|
||
- 与议题无关的插话和跑题
|
||
|
||
**叙述纪律：**
|
||
|
||
- 严格区分四种性质并用措辞体现：**已形成决议** / **讨论中的观点** / **个人建议**（"主持人建议……"）/ **遗留待研究**
|
||
- 只写转写中有的内容，不补充转写外的背景知识，不替会议做它没做的结论
|
||
- 加粗只用于关键决议、关键约束、关键数字，宁少勿滥
|
||
- 用转写的原语言写作（中文转写→中文纪要）；正文以陈述句为主，结构化信息（基本信息、方案对比、待办）用表格
|
||
|
||
## 参考文件
|
||
|
||
- `references/format-template.md` — 逐节模板与写法要点，**成文前必读**
|
||
- `references/example.md` — 一份完整真实范例（制造业 BOM 工作会），用于校准详略与语感
|