meeting-minutes-taker

会议纪要整理器

通过迭代审阅，将原始会议转录整理为全面、基于证据的会议纪要。

快速开始

预处理（可选，但建议执行）：

• 文档转换：先使用 doc-to-markdown 技能将 .docx/.pdf 转换为 Markdown（保留表格/图片）
• 转录清理：如果转录质量较差，使用 transcript-fixer 技能修正 ASR/STT 错误
• 上下文文件：准备包含团队名录的 context.md，以便准确识别发言者

核心工作流：

1. 阅读用户提供的转录
2. 如果用户提供了项目专属上下文文件，则加载该文件（可选）
3. 智能命名文件：根据内容自动生成文件名（见下文）
4. 识别发言者：如果转录中有“Speaker 1/2/3”，首先请用户在源平台为发言者添加标签并重新导出（见步骤 1.5 阶段 0）；只有作为后备方案时才根据文本推断
5. 多轮生成：通过多轮处理或使用上下文隔离的子 Agent，合并时采用并集
6. 使用完整性审查清单进行自我审查
7. 向用户展示草稿，以便人工逐行审阅
8. 跨 AI 比较（可选）：用户可能会提供其他 AI 工具（如 Gemini、ChatGPT）的输出——合并这些内容以减少偏见
9. 根据反馈反复修改，直到用户批准最终版本

智能命名文件

根据转录内容自动生成输出文件名：

格式：YYYY-MM-DD-<topic>-<type>.md

组成部分	来源	示例
日期	转录元数据或首次提及的日期	2026-01-25
主题	主要讨论主题（2–4 个词，使用 kebab-case）	api-design、product-roadmap
类型	会议类别	review、sync、planning、retro、kickoff

示例：

• 2026-01-25-order-api-design-review.md
• 2026-01-20-q1-sprint-planning.md
• 2026-01-18-onboarding-flow-sync.md

请用户确认建议的文件名，再进行写入。

核心工作流

复制此清单并跟踪进度：

Meeting Minutes Progress:
- [ ] Step 0 (Optional): Pre-process transcript with transcript-fixer
- [ ] Step 1: Read and analyze transcript
- [ ] Step 1.5: Speaker identification (if transcript has "Speaker 1/2/3")
  - [ ] Phase 0 FIRST: ask user to label speakers on the source platform (Feishu Minutes / Tencent Meeting), re-export, use labeled transcript
  - [ ] Fallback only (source labeling unavailable or declined by user):
    - [ ] Analyze speaker features (word count, style, topic focus)
    - [ ] Match against context.md team directory (if provided)
    - [ ] Present speaker mapping with per-speaker evidence to user for confirmation
- [ ] Step 1.6: Generate intelligent filename, confirm with user
- [ ] Step 1.7: Quality assessment (optional, affects processing depth)
- [ ] Step 2: Multi-turn generation (PARALLEL subagents with Task tool)
  - [ ] Create transcript-specific dir: <output_dir>/intermediate/<transcript-name>/
  - [ ] Launch 3 Task subagents IN PARALLEL (single message, 3 Task tool calls)
    - [ ] Subagent 1 → <output_dir>/intermediate/<transcript-name>/version1.md
    - [ ] Subagent 2 → <output_dir>/intermediate/<transcript-name>/version2.md
    - [ ] Subagent 3 → <output_dir>/intermediate/<transcript-name>/version3.md
  - [ ] Merge: UNION all versions, AGGRESSIVELY include ALL diagrams → draft_minutes.md
  - [ ] Final: Compare draft against transcript, add omissions
- [ ] Step 3: Self-review for completeness
- [ ] Step 3.5: Retrieval Self-Test (consumption-side verification)
  - [ ] Fresh-context subagent extracts future-query claims list from transcript ONLY (never sees draft) → intermediate/<transcript-name>/retrieval-claims.md
  - [ ] Hit-test each claim against retrievable layer (Key Decisions / Action Items / Parking Lot / Open Questions), by component, with lexical anchors
  - [ ] Revocation scan before ANY promotion; promote with [self-test promoted] tag + greppable verbatim quote; uncertain → Open Questions
  - [ ] Report "enumerated N / hits M / promoted K / uncertain list" (never a binary pass); fail-open with visible NOT-RUN note if extraction fails
- [ ] Step 4: Present draft to user for human review
- [ ] Step 5: Cross-AI comparison (if human provides external AI output)
- [ ] Step 6: Iterate on human feedback (expect multiple rounds)
- [ ] Step 7: Human approves final version

Note: <output_dir> = directory where final meeting minutes will be saved (e.g., project-docs/meeting-minutes/)
Note: <transcript-name> = name derived from transcript file (e.g., 2026-01-15-product-api-design)

步骤 1：阅读并分析转录

分析转录，识别：

• 会议主题和与会者
• 有佐证引文的关键决策
• 负责人明确的行动项
• 延后处理的事项/待解决问题

步骤 1.5：识别发言者（必要时）

触发条件：转录中只有“Speaker 1”“Speaker 2”“发言人1”等通用标签。

阶段 0：在源端添加标签（务必优先尝试）

如果转录来自支持手动标记发言者的平台（飞书妙记、腾讯会议，或任何带有说话人分离编辑页面的工具），请先暂停并让用户在源平台为发言者添加标签，然后重新导出/导入已标记的转录，再生成会议纪要。向用户发送源页面链接——通常位于转录的 frontmatter 中（minute_url、会议 URL）。

这比推断更可靠，原因如下：

• 平台标记由人工聆听实际语音完成，是权威来源。基于文本的推断只能识别那些在会议中被点名的发言者；其他人都只能靠猜测。
• 多人被合并为同一标签的说话人分离片段，单靠文本无法还原——再多的推断也无法解决，但在源端重新标记可以。
• 推断结果会迫使你在各处添加 [inferred] 标记，并对每位发言者进行一轮人工审核；源端标记只需进行一次，就能获得准确的真实信息。

仅在以下情况使用下方的阶段 A–C 作为后备方案：(a) 用户明确要求继续推断，或 (b) 源内容无法标记（原始音频文件没有平台页面，或没有编辑权限）。使用后备方案时，每个对应关系都必须附有证据和置信度；未解决的标签保持原样（绝不强行指定）；如果用户之后在源端完成标记，则返回并修正会议纪要。

后备方案（受 Anker Skill 启发）：

阶段 A：特征分析（模式识别）

分析每位发言者：

特征	观察内容
词数	发言总词数（高 = 高级成员／负责人，低 = 旁听者）
发言段数	发言次数（频繁 = 积极参与者）
平均发言长度	每轮发言的平均词数（长 = 演讲者，短 = 回应者）
填充词比例	填充词（对／嗯／啊／就是／然后）的比例（低 = 准备充分的发言者）
发言风格	正式／非正式、技术深度、决策权限
话题重点	主要讨论的领域（后端、前端、产品等）
互动模式	他人是否向其提问？他们是否分配任务？

分析输出示例：

Speaker Analysis:
┌──────────┬────────┬──────────┬─────────────┬─────────────┬────────────────────────┐
│ Speaker  │ Words  │ Segments │ Avg Length  │ Filler %    │ Role Guess             │
├──────────┼────────┼──────────┼─────────────┼─────────────┼────────────────────────┤
│ 发言人1  │ 41,736 │ 93       │ 449 chars   │ 3.6%        │ 主讲人 (99% of content)│
│ 发言人2  │ 101    │ 8        │ 13 chars    │ 4.0%        │ 对话者 (short responses)│
└──────────┴────────┴──────────┴─────────────┴─────────────┴────────────────────────┘

Inference rules:
- 占比 > 70% + 平均长度 > 100字 → 主讲人
- 平均长度 < 50字 → 对话者/响应者
- 语气词占比 < 5% → 正式/准备充分
- 语气词占比 > 10% → 非正式/即兴发言

阶段 B：上下文映射（提供上下文文件时）

当用户提供项目上下文文件（例如 context.md）时：

1. 加载团队目录部分
2. 将特征模式与已知团队成员匹配
3. 将角色与发言模式交叉比对

上下文文件应包含：

## Team Directory
| Name | Role | Communication Style |
|------|------|---------------------|
| Alice | Backend Lead | Technical, decisive, assigns backend tasks |
| Bob | PM | Product-focused, asks requirements questions |
| Carol | TPM | Process-focused, tracks timeline/resources |

阶段 C：继续前确认

重要：切勿默默假定发言者身份。

向用户展示分析摘要：

Speaker Analysis:
- Speaker 1 → Alice (Backend Lead) - 80% confidence based on: technical focus, task assignment pattern
- Speaker 2 → Bob (PM) - 75% confidence based on: product questions, requirements discussion
- Speaker 3 → Carol (TPM) - 70% confidence based on: timeline concerns, resource tracking

Please confirm or correct these mappings before I proceed.

用户确认后，在整个文档中一致地应用映射关系。

步骤 1.7：转录质量评估（可选）

评估转录质量，以确定处理深度：

评分标准（1–10 分）：

因素	分数影响
内容量	>10k 个字符：+2，5-10k：+1，<2k：最高 3 分
填充词比例	<5%：+2，5-10%：+1，>10%：-1
发言者清晰度	主要发言者占比 >80%：+1（演讲者明确）
技术深度	技术内容较多：+1

质量等级：

分数	等级	处理方式
≥8	高	生成包含所有章节、图表和引述的完整结构化会议纪要
5-7	中	生成标准会议纪要，重点关注关键决策和行动项
<5	低	仅生成摘要——简要概述重点，跳过详细转录

评估示例：

📊 Transcript Quality Assessment:
- Content: 41,837 chars (+2)
- Filler ratio: 3.6% (+2)
- Main speaker: 99% (+1)
- Technical depth: High (+1)
→ Quality Score: 10/10 (High)
→ Recommended: Full structured minutes with diagrams

用户决策点：如果质量为低（<5），询问用户：

“转录质量较低（碎片对话／噪音较多）。生成完整会议纪要，还是仅生成摘要？”

步骤 2：多轮初始生成（关键）

单次处理绝对会丢失内容。 使用多轮生成和冗余的完整处理轮次：

核心原则：多次完整处理 + 合并并集

每轮都从完整转录中生成完整会议纪要（所有章节）。通过上下文隔离的多轮处理捕捉不同细节。合并并集，汇总所有发现。

❌ 错误：聚焦范围狭窄的处理轮次（浪费令牌，造成偏差）

Pass 1: Only extract decisions
Pass 2: Only extract action items
Pass 3: Only extract discussion

✅ 正确：上下文隔离的完整处理轮次

Pass 1: Generate COMPLETE minutes (all sections) → version1.md
Pass 2: Generate COMPLETE minutes (all sections) with fresh context → version2.md
Pass 3: Generate COMPLETE minutes (all sections) with fresh context → version3.md
Merge: UNION all versions, consolidate duplicates → draft_minutes.md

策略 A：顺序多轮处理（每轮生成完整会议纪要）

Pass 1: Read transcript → Generate complete minutes → Write to: <output_dir>/intermediate/version1.md
Pass 2: Fresh context → Read transcript → Generate complete minutes → Write to: <output_dir>/intermediate/version2.md
Pass 3: Fresh context → Read transcript → Generate complete minutes → Write to: <output_dir>/intermediate/version3.md
Merge: Read all versions → UNION merge (consolidate duplicates) → Write to: draft_minutes.md
Final: Compare draft against transcript → Add any remaining omissions → final_minutes.md

策略 B：并行多 Agent（每个 Agent 均生成完整会议纪要）—首选

必须使用 Task 工具，以隔离的上下文启动多个子 Agent，每个子 Agent 都要生成完整的会议纪要：

使用 Task 工具的实现方式：

// Launch ALL 3 subagents in PARALLEL (single message, multiple Task tool calls)
Task(subagent_type="general-purpose", prompt="Generate complete meeting minutes from transcript...", run_in_background=false) → version1.md
Task(subagent_type="general-purpose", prompt="Generate complete meeting minutes from transcript...", run_in_background=false) → version2.md
Task(subagent_type="general-purpose", prompt="Generate complete meeting minutes from transcript...", run_in_background=false) → version3.md

// After all complete:
Main Agent: Read all versions → UNION merge, consolidate duplicates → draft_minutes.md

重要：子 Agent 提示词必须包含：

1. 转录稿文件的完整路径
2. 输出文件的完整路径（转录稿专属子目录中的 version1.md、version2.md、version3.md）
3. 要加载的上下文文件（如果提供了项目专属上下文，则包括这些文件和 meeting_minutes_template.md）
4. 用户提供的参考图片／文档
5. 输出语言要求（与用户的语言偏好一致，保留英文技术术语）
6. 引文格式要求（见下文的“引文格式要求”章节）
7. 决策识别规则：按要素而非措辞识别决策——叙述性发言或案例审查发言中包含的指示，只要具备责任方（由谁负责）、行动（做什么），以及可选的条件（截至何时），仍应视为决策。准确性保障：不确定某项内容是否为真实决策时，将其归入待解决问题，而非关键决策（切勿夸大决策表的内容）。

为什么多轮完整分析有效：

• 每一轮都会独立分析相同内容
• 不同的上下文状态能发现不同细节（没有任何一轮能发现所有内容）
• 第 1 轮可能发现决策 X，却漏掉行动项 Y
• 第 2 轮可能发现行动项 Y，却漏掉决策 X
• 合并后即可同时纳入 X 和 Y

为什么隔离上下文很重要：

• 每一轮／每个 Agent 都从全新状态开始，不受先前假设影响
• 各轮之间不会相互干扰
• 隔离上下文会自然形成不同的“视角”

逐步将上下文转移到文件系统

重要：将每轮的输出写入文件，而不是对话上下文。

路径约定： 所有中间文件都应创建在 <output_dir>/intermediate/ 下的转录稿专属子目录中，以避免处理不同转录稿时发生冲突。

重要：使用转录稿专属子目录结构：

<output_dir>/intermediate/<transcript-name>/version1.md
<output_dir>/intermediate/<transcript-name>/version2.md
<output_dir>/intermediate/<transcript-name>/version3.md

示例：如果最终会议纪要路径为 project-docs/meeting-minutes/2026-01-14-api-design.md，则：

• 中间文件：project-docs/meeting-minutes/intermediate/2026-01-14-api-design/version1.md
• 这样可以避免同一会话中处理多个转录稿时发生冲突
• 应将 intermediate/ 文件夹添加到 .gitignore（临时工作文件）

// Create transcript-specific subdirectory first
mkdir: <output_dir>/intermediate/<transcript-name>/

// Launch all 3 subagents IN PARALLEL (must be single message with 3 Task tool calls)
Task 1 → Write to: <output_dir>/intermediate/<transcript-name>/version1.md (complete minutes)
Task 2 → Write to: <output_dir>/intermediate/<transcript-name>/version2.md (complete minutes)
Task 3 → Write to: <output_dir>/intermediate/<transcript-name>/version3.md (complete minutes)

Merge Phase:
  Read: <output_dir>/intermediate/<transcript-name>/version1.md
  Read: <output_dir>/intermediate/<transcript-name>/version2.md
  Read: <output_dir>/intermediate/<transcript-name>/version3.md
  → UNION merge, consolidate duplicates, INCLUDE ALL DIAGRAMS → Write to: draft_minutes.md

Final Review:
  Read: draft_minutes.md
  Read: original_transcript.md
  → Compare & add omissions → Write to: final_minutes.md

基于文件转移上下文的好处：

• 保持对话上下文整洁（避免令牌溢出）
• 中间结果会保留下来（需要时可重新读取）
• 每一轮都从全新的上下文窗口开始
• 合并阶段只读取所需内容
• 人工可以检查中间文件并进行审核——这对于了解每一轮提取了哪些内容至关重要
• 支持处理超出上下文限制的超长转录稿
• 便于事后调试——如果最终输出遗漏了内容，人工可以追溯是哪一轮漏掉的

重要：始终在转录稿专属子目录中保留中间版本：

• <output_dir>/intermediate/<transcript-name>/version1.md、version2.md、version3.md——每个子 Agent 的输出
• 这些文件有助于人工审核者了解合并过程
• 合并后不要删除中间文件
• 人工可能需要比较中间版本，以了解覆盖范围的差异
• 将 intermediate/ 添加到 .gitignore——这些是临时工作文件，不是最终交付物
• 转录稿专属子目录可避免处理多个转录稿时发生冲突

输出要求

• 中文输出，保留英文技术术语
• 基于证据做出决策——每项重要决策都需要引用原文作为依据
• 结构化章节——Executive Summary、Key Decisions、Discussion、Action Items、Parking Lot
• 规范的引用格式——参见下方的 Quote Formatting Requirements 部分
• Mermaid 图表（强烈推荐）——可视化图表能让会议纪要不再局限于纯文本：
  • ER 图用于数据库／架构讨论
  • 时序图用于数据流和 API 交互
  • 流程图用于流程／工作流决策
  • 状态图用于状态机讨论
  • 图表能显著提升会议纪要的可读性，方便人们审阅和理解
• 上下文优先的文档结构——将所有审阅过的材料（UI 模型图、API 文档、设计图片）放在文档顶部（元数据之后、Executive Summary 之前），以便在决策前先交代背景；将图片复制到 meeting-media/<meeting-name>/ 文件夹，并使用 ![description](meeting-media/...) 语法内嵌；为视觉材料附上简短描述——这样能让会议纪要更易于阅读，使读者在阅读讨论内容前就了解所讨论的内容
• 发言者归属——准确标明由谁做出决策

关键规则

• 切勿臆测——如有不清楚之处，请向用户确认
• 对有争议的决策逐字引用
• 将行动项分配给具体个人，而非团队
• 保留数值（范围、数量、优先级）
• 始终进行多轮处理——单轮处理必然会遗漏内容
• 统一等价术语——将细微差异（例如“backend architecture”与“backend”、“API endpoint”与“endpoint”）视为等价；不要指出或强调不同发言者之间的这些差异
• 唯一事实来源——每条信息只放在一个位置；避免在不同章节重复表格、列表或摘要（例如，API 列表应放在 Discussion 或 Reference 中，而不是两者都放）
• 根据内容而非措辞识别决策——不必出现“We decided X”这样的说法；以叙述口吻给出的指示，只要包含谁、做什么（以及条件），就应归入 Key Decisions，而不是埋在 Discussion 的正文中

第 3 步：完整性自查

初稿生成后，立即对照记录稿进行检查：

Completeness Checklist:
- [ ] All discussion topics covered?
- [ ] All decisions have supporting quotes?
- [ ] All speakers attributed correctly?
- [ ] All action items have specific owners?
- [ ] Numerical values preserved (ranges, counts)?
- [ ] Entity relationships captured?
- [ ] State machines complete (all states listed)?

如发现遗漏，请直接补充缺失内容，无需提及遗漏了什么。

第 3.5 步：检索自测（消费端验证）

为何设置此步骤。 三个生成子 Agent 使用相同的提示词，并共享对“决策”的隐含认知——因此，它们的错误具有相关性。合并结果可以避免内容丢失，却无法避免共同盲点。第 3 步的检查清单只能验证已识别出的决策；如果所有处理轮次都没有将某项内容归类为决策，它就无法发现该内容。与此同时，会议纪要的用途是供人们检索：几周后，有人会问“X 是否说过我们必须做 Y？”，然后查阅 Key Decisions／Action Items 表格。如果某条指令只出现在 Discussion 的正文中，即使没有内容“丢失”，也无法通过这种查询找到它。本步骤会直接检验这一最终特性。（坦诚说明其适用范围：这是第二层、部分去相关的回忆机制，而非万能工具。它无法涵盖的已知盲点包括：言语的实际语用含义与字面措辞相反的断言（“好吧，不做负载测试就做吧，只是到时候别说我没提醒过你”＝明确表达的异议），以及没有任何发言的默认同意场景。）

流程（合并后、提交草稿前）：

1. 反向提取面向未来查询的主张列表。 启动一个全新的上下文子 Agent，它只能读取转录内容，绝不能看到会议纪要草稿（可以提供发言人姓名对照表；锚定风险来自草稿的结构，而非人员名单）。其任务是：

   假设项目成员在 1–8 周后回来核实：“[某人] 是否曾就 X 发出指示 / 作出承诺 / 作出决定 / 否决 / 承诺一个数字？”列举所有此类主张。每项主张 = 谁 + 类型（指示 / 承诺 / 决定 / 否决 / 数字承诺 / 有条件共识）+ 内容 + 范围（如有，到期条件）+ 时间戳。只纳入责任人明确的主张；跳过观点和背景叙述。

   对于较长的转录内容（大约超过 60k 个字符或 90 分钟），应分成有重叠的片段提取并合并——单次通读会受到“中间遗忘”注意力衰减的影响，而长会议恰恰常把指示埋在其中。将列表写入 <output_dir>/intermediate/<transcript-name>/retrieval-claims.md（作为检查已运行的可审计证据，供人工之后审阅）。

2. 逐项核验主张是否能从可检索层中找到（主 Agent）：可检索层 = Key Decisions 标题 + Decision 行、Action Items 表、Parking Lot、Open Questions——命中意味着读者只扫描这些内容，无需阅读正文就能找到该主张。按组成部分判断是否命中：谁 / 行动 / 截止时间 / 到期条件都必须出现（表格行若列出了任务却漏掉到期条件，则属于部分未命中）。要求有词汇锚点——行中必须包含主张的关键行动者 / 行动词；不要接受纯粹语义上的“LLM 可能会认为二者对应”这种等价关系，因为未来的读者是匆忙的人，而不是宽容的模型。

3. 处理未命中项。 在提升任何内容之前，先执行撤销扫描：在转录内容中搜索同一主题后续的反转 / 修改 / 附加条件（“我们之前说要空运——先等海关确认后再说”）。会议中已被取代的主张不得原样提升；应记录最终状态。此扫描是强制要求——提升已撤销的决定，是这一步可能让会议纪要比不运行检查更糟糕的唯一情况。然后：

   • 未命中 + 确实属于指示 / 承诺 / 决定 → 提升到 Key Decisions 或 Action Items，并标记 [self-test promoted]，附上逐字引文 + 时间戳，以便通过搜索在转录中找到（没有可搜索引文的提升将被拒绝——这能限制虚构主张的风险）。
   • 未命中 + 不确定 → 转至 Open Questions / Parking Lot。绝不要让不确定的提升项充斥决策表；其精确性决定了它是否可检索。
   • 未命中 + 确实只是细节 → 保留在 Discussion 中，但应能说明为什么不会有人查询它。

4. 报告结果，不要只说“通过”。 输出：enumerated N / hits M / promoted K / uncertain list，并与草稿一同展示。提升的行正是人工应最仔细审阅的内容——与 Step 3 的静默补漏不同，提升绝不能悄无声息。

5. 失败时放行。 如果提取子 Agent 卡住或失败，仍然交付会议纪要，并附上醒目的说明“Retrieval Self-Test: NOT RUN”。此关卡绝不能阻碍交付——错误阻拦正常运行的关卡会让操作人员逐渐养成永久跳过它的习惯。

6. 在迭代轮次中（Step 6 反馈周期、跨 AI 合并）：交付前至少要针对最终版本重新运行命中测试——否则后续轮次新增的内容会完全绕过检查。

步骤 4：提交用户进行人工审核

将完整会议纪要作为供人工审核的草稿提交。强调：

• 会议纪要需要人工逐行仔细审核
• 领域专家能发现 AI 可能忽略的术语冲突
• 最终版本通过迭代完善形成

用户可以：

• 直接接受（复杂会议中很少见）
• 要求深入审核，检查是否有内容遗漏
• 指出术语问题（例如与现有系统的命名冲突）
• 提供另一个 AI 的输出以供交叉比较

步骤 5：跨 AI 比较（减少偏差）

当用户提供另一个 AI 工具（例如 Gemini、ChatGPT 等）的输出时：

此步骤很有价值，因为：

• 不同 AI 模型有不同的偏差——每个 AI 都能发现不同的细节
• 交叉验证——两个输出中都出现的内容可能是准确的
• 差异检测——一方有而另一方没有的内容可能表明存在遗漏
• 错误纠正——一个 AI 可能发现另一个 AI 忽略的事实错误（例如日期错误、与会者姓名错误）

比较流程：

1. 仔细阅读外部 AI 的输出
2. 找出外部输出中有但我们的草稿中没有的内容
3. 添加前对照原始转录稿核实每项内容（不要盲目照搬）
4. 找出外部 AI 出错的内容（事实错误）——记录下来，但不要照搬错误
5. 将有效的新内容合并到我们的草稿中
6. 记录根据交叉比较所做的任何修正

跨 AI 比较中的发现示例：

• 缺少关于 API 身份验证方式的决定 ✓（添加到我们的草稿中）
• 缺少命名约定规范 ✓（添加到我们的草稿中）
• 日期错误（2026-01-13，而实际日期为 2026-01-14）✗（不要照搬错误）
• 与会者姓名错误 ✗（不要照搬错误）
• 缺少数据库性能方面的顾虑 ✓（添加到待议事项中）

步骤 6：根据人工反馈迭代（关键）

当用户要求深入审核（“深入审核”“再检查一次”“还有遗漏吗”）时：

1. 逐节重读转录稿
2. 将每一节与当前会议纪要进行比较
3. 检查：实体、字段名称、数值范围、状态转换、权衡取舍、延后处理事项
4. 补充任何遗漏的内容
5. 未经过彻底的逐节审核，绝不要声称“没有遗漏”

当用户提供另一个版本要求合并时：

合并原则：取并集，绝不删除

1. 保留现有版本中的所有内容
2. 添加传入版本中的所有新内容
3. 合并重复内容（不要重复相同信息）
4. 详细程度不同时，保留更详细的版本
5. 保持章节编号的逻辑顺序

积极纳入图表（关键）

在合并阶段，必须积极纳入所有版本中的所有图表。

图表是价值很高的内容，生成它们需要投入精力。不同的子 Agent 可能会根据各自关注的内容生成不同的图表。合并时漏掉图表会造成重大损失。

图表合并策略：

1. 清点每个版本（v1、v2、v3）中的所有图表
2. 纳入所有独有图表——不要认为图表是多余的
3. 如果存在相似图表，保留更详细、更完整的图表
4. 检查所有可能包含图表的章节：执行摘要、讨论、API 设计、状态机、数据流等

需要查找的常见图表类型：

• 时序图（数据流、API 交互）
• ER 图（数据库架构、表关系）
• 状态图（状态机、状态转换）
• 流程图（决策流程、流程工作流）
• 组件图（系统架构）

示例：遗漏 v3 中的图表 如果 v3 中有一张“状态查询机制”的流程图，而 v1 和 v2 中没有，那么合并后的输出中必须包含这张流程图。不要认为其他图表已经涵盖了相关内容。

输出语言

• **主要语言：**与转录稿的语言一致（或遵循用户指定的语言）
• **保留英文：**技术术语、实体名称、缩写（符合标准惯例）
• **引文：**保留转录稿中的原始语言

参考文件

文件	加载时机
meeting_minutes_template.md	首次生成时——包含模板结构
completeness_review_checklist.md	审查步骤中——包含完整性检查
context_file_template.md	帮助用户创建 context.md 时——包含团队目录模板
项目上下文文件（由用户提供）	用户提供项目专属上下文（团队目录、术语、约定）时

推荐的预处理流程

适用于 .docx 转录文本的完整流程：

Step 0: doc-to-markdown      # Convert .docx → Markdown (preserves tables/images)
        ↓
Step 0.5: transcript-fixer  # Fix ASR errors (optional, if quality is poor)
        ↓
Step 1+: meeting-minutes-taker  # Generate structured minutes

命令：

# 1. Install markitdown (one-time)
uv tool install "markitdown[pdf]"

# 2. Convert .docx to markdown
markitdown "录音转写.docx" -o transcript.md

# 3. Then use meeting-minutes-taker on transcript.md

组合工作流的优势：

• 保留表格：markitdown 会将 Word 表格转换为 Markdown 表格
• 提取图像：可将图像嵌入最终会议纪要
• 引用更整洁：transcript-fixer 会在提取引用前修正 ASR 错字
• 准确识别发言者：在干净的文本上进行风格分析效果更好
• 正交设计：每项技能各司其职，可组合成流水线

常见模式

架构讨论 → Mermaid 图表（进阶版会议纪要）

**图表能让会议纪要超越纯文本的局限。**它们能让人工审阅者立即理解复杂讨论。始终留意添加可视化图表的机会。

何时使用图表：

• 数据流讨论 → 时序图
• 数据库架构讨论 → ER 图
• 流程／工作流决策 → 流程图
• 状态机讨论 → 状态图
• 系统架构 → 组件图

示例：数据流（时序图）

sequenceDiagram
    participant FE as Frontend
    participant BE as Backend
    participant SVC as External Service
    participant DB as Database
    FE->>BE: Click "Submit Order"
    BE->>SVC: POST /process (send data)
    SVC-->>BE: Return {status}
    BE->>DB: Save result
    BE-->>FE: Return success

示例：数据库架构（ER 图）

erDiagram
    ORDER ||--o{ ORDER_ITEM : "1:N"
    ORDER {
        uuid id PK
        string customer_name
        decimal total_amount
    }
    ORDER_ITEM {
        uuid id PK
        uuid order_id FK
        int quantity
    }

示例：版本切换（工作流图）

sequenceDiagram
    participant User
    participant System
    Note over System: Current: V2 Active
    User->>System: Create V3 (inactive)
    User->>System: Set V2 inactive
    User->>System: Set V3 active
    Note over System: New: V3 Active

引用格式要求（重要）

引用必须使用正确的 Markdown 块引用格式，并单独成行：

❌ 错误：行内引用格式

* **Quote:** > "This is wrong" - **Speaker**

✅ 正确：单独成行的块引用

* **Quote:**
  > "This is the correct format" - **Speaker**

✅ 正确：多个引用

* **Quote:**
  > "First quote from the discussion" - **Speaker1**
  > "Second quote supporting the same decision" - **Speaker2**

关键格式规则：

• * **Quote:** 单独成行（此行不包含引用内容）
• * **Quote:** 后无需空行
• 引用内容缩进 2 个空格，然后添加 > 前缀
• 在引用行末尾标注发言者：- **SpeakerName**
• 多个引用使用相同缩进，每个单独成行

技术决策 → 决策块

### 2.X [Category] Decision Title

* **Decision:** Specific decision made
* **Logic:**
  * Reasoning point 1
  * Reasoning point 2
* **Quote:**
  > "Exact quote from transcript" - **Speaker Name**

延后事项 → 待处理事项

包含“以后再处理”、“Phase 2”、“不属于 MVP”等关键词的事项，应结合上下文放入待处理事项。

人机协作迭代（必不可少）

会议纪要不是一次性生成的结果。高质量的会议纪要需要经过多轮审查：

人工审查为何至关重要

1. 术语冲突：人们了解现有系统的命名方式（例如，“Note”在现有系统中已表示评论）
2. 领域上下文：人们能发现某个术语是否可能与其他概念混淆（例如，“UserProfile”与“Account”）
3. 组织知识：人们了解团队约定和以往决策
4. 完整性缺漏：当人们觉得内容有所缺失时，可以要求进行“深度审查”

迭代模式示例

Round 1: Initial generation
  └─ Human review: "Check original transcript for missing items"
Round 2: Deep transcript review, add omitted content
  └─ Human review: "UserProfile conflicts with existing Account entity naming"
Round 3: Update terminology to use "CustomerProfile" instead
  └─ Human review: "Note field conflicts with existing Comment system"
Round 4: Update to use "Annotation" instead of "Note"
  └─ Human approval: Final version ready

核心原则

**AI 生成初稿；人类将其完善为最终版本。**切勿认为第一版内容完整或术语正确。务必鼓励人工审查，并做好多轮迭代的准备。

反模式

• ❌ 当来源平台支持标注时，根据文本推断发言人身份 - 应先让用户在飞书妙记 / 腾讯会议中标注发言人并重新导出（步骤 1.5 阶段 0）；文本推断只能识别被点名的发言人，无法还原被说话人分离合并的片段
• ❌ 用生成草稿时的同一套思维模型自我审查 - 步骤 3 的检查清单只能核验各轮处理已分类的内容；共同的盲点（例如以叙述口吻表达的指令）仍会被遗漏。执行步骤 3.5 的全新上下文检索自测；提取器绝不能看到草稿
• ❌ 未执行撤销扫描就将自测漏项纳入内容 - 如果将会议后续已撤销的决定原样纳入，就会在表格中写入错误决定；这是自测让会议纪要比跳过自测更糟的唯一方式
• ❌ 将自测结果报告为简单的「通过」或「未通过」 - 始终报告「枚举 N 项 / 命中 M 项 / 纳入 K 项 / 不确定项清单」；没有数字的绿灯会让人逐渐停止审阅
• ❌ 单轮生成 - 仅通读一遍转录稿肯定会遗漏内容
• ❌ 分段处理但不重叠 - 每轮都必须覆盖完整转录稿，而不是按章节拆分
• ❌ 只聚焦狭窄范围的处理轮次 - 每轮都必须生成完整会议纪要（包含所有章节），而不是只生成一种章节类型（浪费令牌并导致偏差）
• ❌ 不提供引文佐证的泛泛总结
• ❌ 将行动项分配给「团队」而非具体人员
• ❌ 遗漏数值（优先级、范围、状态数量）
• ❌ 状态不完整的状态机
• ❌ 逐字转录循环辩论，而不是加以总结
• ❌ 在合并多个版本时删除内容
• ❌ 未逐章审阅就声称「没有遗漏」
• ❌ 未经人工审阅就将初稿当作最终版本
• ❌ 未检查是否与现有系统存在冲突就使用术语
• ❌ 子 Agent 之间共享上下文（会造成交叉污染并遗漏内容）
• ❌ 在对话上下文中保留所有中间输出（会导致令牌溢出，应使用文件系统）
• ❌ 会议纪要纯文本化，不含图示 - 架构 / 架构模式讨论值得用图示呈现
• ❌ 合并后删除中间文件 - 保留文件供人工审阅和调试
• ❌ 盲目复制外部 AI 的输出 - 合并前始终根据转录稿核验
• ❌ 忽略跨 AI 对比的机会 - 不同 AI 模型会发现不同细节
• ❌ 顺序执行子 Agent - 必须在一条消息中使用多次 Task 工具调用，并行启动 v1、v2、v3 子 Agent
• ❌ 使用扁平的中间文件目录 - 必须使用转录稿专属子目录 intermediate/<transcript-name>/，避免冲突
• ❌ 使用行内引文格式 - 引文必须另起一行并使用引用块格式，不能写成行内的 > "quote"
• ❌ 合并时遗漏图示 - 必须积极纳入所有版本中的所有图示，即使它们看起来相似
• ❌ 强调无关紧要的术语差异 - 不要指出发言人使用的「后端架构」与「后端」或「API」与「端点」等差异；这些术语含义相同，强调此类差异有失尊重
• ❌ 不同章节间内容重复 - 不要在多个章节重复相同信息（例如同时在「讨论」和「参考」中放置 API 端点表）；将内容放在一个权威位置，并在需要时引用
• ❌ 创建不存在的链接 - 不要创建指向仓库中不存在文件的 Markdown 链接（例如 [doc.md](reviewed-document)）；对于仓库之外的外部 / 本地文档，请使用纯文本
• ❌ 整合时丢失内容 - 移动或整合章节时，核实所有项目符号和细节均得到保留；绝不要概括掉「支持批量操作」或「按钮会触发自动保存」等具体细节
• ❌ 在角色头衔后追加领域细节 - 发言人归属信息只能使用团队目录中的角色列（例如「后端」「前端」「TPM」）；不要追加「后端，基础设施」或「后端，业务逻辑」等专业方向；所有角色相同的团队成员，归属标注应完全一致

下一步：导出为交付格式

整理好会议纪要后，建议导出为：

Meeting minutes complete: [N] decisions, [M] action items captured.

Options:
A) Export as PDF — run /daymade-docs:pdf-creator (Recommended for sharing)
B) Export as slides — run /daymade-docs:ppt-creator (for presentation)
C) No thanks — the markdown is sufficient