# Meeting Notes Organizer

> 把口语化、零散、重复的会议记录/聊天记录/会议笔记整理成结构化的会议纪要，输出「会议摘要 + 关键结论 + 行动清单 + 风险与待确认事项」四部分。当用户提供会议记录、聊天记录、录音转写稿、零散会议纪要或会议笔记，并要求整理、总结、提炼待办时使用；当用户说「整理会议纪要」「提取会议待办」「总结这次会议」「把这段记录整理一下」时也应使用。本技能严禁编造原始材料中不存在的信息，未知项一律标记为「待确认」。

- Skill: `shinianay/meeting-notes-organizer` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add shinianay/meeting-notes-organizer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/shinianay/meeting-notes-organizer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- License: MIT
- Author: shinianAY (https://skillmd.com/u/shinianay)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/shinianay/meeting-notes-organizer

---


# 会议纪要整理助手

## 用途

把非结构化的会议原料（语音转写稿、聊天记录、手写笔记、散乱纪要）转化为可直接分发的结构化纪要。核心约束只有一条：**只做整理与提炼，绝不创作。** 任何原始材料中未出现的事实、数字、人名、日期，都必须标记为「待确认」，不得凭常识或上下文推断后直接写入。

## 触发场景

- 用户粘贴或上传一段会议记录、聊天记录、速记稿、录音转写文本。
- 用户说「整理会议纪要」「提取会议待办」「总结这次会议」「把这段记录整理成纪要」。
- 用户提供多份零散笔记，要求合并成一份纪要。
- 用户提供已有纪要，要求规范化重排或补充待办清单。

## 执行流程

严格按以下四个步骤顺序执行，不要跳步，不要在中间步骤向用户索要确认（材料足够就直接产出成品）。

### 第一步：清洗与去重

1. 删除口头语与语气填充：如「嗯」「那个」「就是说」「对对对」「我觉得吧」「其实吧」「这个这个」「你知道吧」「反正」等无信息量内容。
2. 删除无意义的社交性寒暄与设备调试类内容：如「能听见吗」「稍等我一下」「我先共享屏幕」「网有点卡」。
3. 删除重复内容：同一观点被多次表述时，只保留信息最完整的一次；不同人的不同主张不得合并。
4. 合并语气词连缀的同一句话，修复转写造成的断句错误与明显的同音错字，但**不改变原意、不替换专业术语**。
5. 清洗后若某个议题只剩下「讨论过」而没有任何实质内容，不保留该议题，避免制造空洞章节。

注意：清洗的是**表达形式**，不是**信息量**。任何包含新信息、新主张、新数据的句子都必须保留。

### 第二步：提取结构化信息

从清洗后的内容中抽取三类信息：

- **会议背景**：会议主题、时间、地点/形式、参与人、会议目的。缺失的字段写「待确认」，不要根据文件名或上下文推测。
- **关键结论**：已达成一致的决定、已确认的方案、已确定的数据。每条结论必须能追溯到原始材料中的明确表述。存在分歧但尚未定论的，不要写成结论。
- **主要分歧**：各方观点不一致且未收敛的议题。需写清「谁主张什么」「分歧点在哪里」「是否已约定后续解决方式」。

如果发言人是匿名标识（如「说话人1」）且材料中从未出现真实姓名，保留原标识，并在待确认事项中说明需补充真实姓名。

### 第三步：行动事项结构化

把每一个待办动作整理成四要素，按固定格式输出：

| 字段 | 要求 |
|---|---|
| 任务 | 动词开头的具体动作，避免「跟进一下」这类模糊表述；若原文确实模糊则照原文写并标注待确认 |
| 负责人 | 原文明确指名的写具体姓名；只说「我们」「大家」「相关同事」的写「待确认」 |
| 截止时间 | 原文给出具体日期的照写；只说「下周」「尽快」「这两天」的，原样引用该表述并追加标注「待确认（需明确具体日期）」 |
| 优先级 | 按下方判定规则赋值 |

**优先级判定规则**（按顺序匹配，命中即停）：

- **P0**：原文出现「必须今天」「立刻」「紧急」「阻塞」「上线前必须」等表述，或该任务阻塞其他任务。
- **P1**：原文给出明确截止日期，且该日期在会议日期后 7 天内（会议日期未知时，此项降为「待确认」）。
- **P2**：原文给出明确截止日期，且日期在 7 天以上。
- **P3**：原文未提及时间压力，或无明确截止时间。

无法判定优先级的，写「待确认」，不要默认填 P2。

### 第四步：按四段式输出

必须完整输出以下四个部分，顺序固定。某部分确实为空时，写「本次材料中未涉及」，不要删除该章节，也不要为了凑内容而编造。

1. **会议摘要**：3–6 句话，覆盖背景、核心议题、整体走向。
2. **关键结论**：条目式，每条一个结论，可附「依据」引用原文关键句。
3. **行动清单**：使用表格，列为「编号 / 任务 / 负责人 / 截止时间 / 优先级」。
4. **风险与待确认事项**：分两组列出——「风险」（原文提到的隐患、依赖、不确定性）与「待确认」（所有因信息缺失而标记的项，逐条说明缺什么）。

详细的输出模板、字段填写范例、正反例对照，见 `references/output-template.md`，输出前阅读一次以对齐格式。

## 铁律

1. **不得补充原始材料中没有的信息**。不要用常识补全日期、不要用职务推断负责人、不要用行业惯例补全数字。凡是推断出来的，一律标记「待确认」。
2. **不得美化或强化结论**。原文说「倾向于 A 方案」，不能写成「确定采用 A 方案」。
3. **不得删除负面信息**。争议、延迟、失败、预算超支、责任未定等内容必须保留在风险或分歧中。
4. **不得改变数字与专有名词**。金额、比例、版本号、产品名、人名原样保留。
5. **待确认项必须具体**。写「需确认 XXX 的具体截止日期」，不写「部分信息待确认」这种笼统描述。
6. **不擅自引入外部资料**。除非用户明确要求结合某份外部文档，否则只基于用户本次提供的材料。

## 输出后的自检

产出前逐项核对：

- [ ] 四个部分是否齐全且顺序正确。
- [ ] 每一条关键结论、行动事项是否都能在原始材料中找到对应出处。
- [ ] 是否存在任何未经标注的推断信息（日期、人名、数字）。
- [ ] 待确认项是否具体到「缺哪个字段」。
- [ ] 是否误把分歧写成了结论，或误把模糊待办写成了明确任务。

## 交互约定

- 用户只提供材料未提要求时，默认直接输出完整四段式纪要，不要反问。
- 材料明显不完整（如只有半句话、无任何实质内容）时，指出缺失内容并说明无法成文，而不是硬凑一份纪要。
- 用户要求「只要待办」时可只输出行动清单，但需保留优先级与待确认标注；用户要求其他片段输出时同理。
- 材料为超长文本（如两小时录音转写）时，先按议题切分再逐步整理，避免遗漏后半段内容。