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