基于Cursor本地化AI的会议纪要自动生成工具设计与实践

1. 项目概述：一个为 Cursor 设计的本地化会议纪要生成工具

如果你和我一样，日常开发工作重度依赖 Cursor，并且每周都要参加各种技术评审、需求对齐和团队站会，那你肯定也头疼过会议纪要这件事。把一小时的录音转成文字稿已经够麻烦了，还要从几万字的对话里提炼出“决策”、“待办”和“风险点”，简直是体力活。之前我尝试过用 n8n 搭一个自动化工作流，把转录文本喂给大模型，再按固定格式输出结构化摘要，效果不错，但每次都要触发那个远程流程，总觉得不够“顺手”。

于是就有了这个项目：Meeting Summarizer for Cursor。它的核心目标很简单——把之前 n8n 工作流里那套成熟的会议摘要逻辑，完整地“搬进” Cursor 的本地环境里。你不再需要依赖外部服务，所有操作都在你的 Cursor 工作空间内完成，利用 Cursor 内置的 AI 能力，生成格式统一、信息清晰的会议纪要。它包含两个部分：一个是直接嵌入 Cursor 的规则文件（.mdc），确保 AI 在总结时遵循固定的模板和修正规则；另一个是可选的、独立的 Web 应用，作为一个“提示词构建器”，帮你把杂乱的会议转录文本快速整理成一条规整的指令，直接粘贴到 Cursor Chat 里使用。

这个工具特别适合需要高频产出标准化会议记录的开发者、项目经理或团队负责人。它不改变你的工作流，只是让你在 Cursor 里做这件事的效率提升一个量级。接下来，我会详细拆解它的设计思路、各个模块是如何工作的，以及如何从零开始把它用起来，并分享一些我在实际使用中踩过的坑和总结的技巧。

2. 核心设计思路与架构解析

这个项目的设计哲学是“本地优先”和“无缝集成”。它没有尝试去再造一个复杂的 AI 应用，而是巧妙地利用了 Cursor 的两个特性：规则（Rules）和聊天（Chat）。整个架构可以看作是对原有 n8n 工作流的一次“本地化移植”和“体验优化”。

2.1 为什么选择基于 Cursor Rules 实现？

最初考虑过几种方案：写一个独立的 CLI 工具、开发一个 VSCode 插件，或者继续优化 n8n。但最终选择 Cursor Rules，主要基于以下几点考量：

1. 零环境依赖：Rules 是 Cursor 的原生功能，一个.mdc文件放到.cursor/rules/目录下即可生效。团队成员无需安装任何额外的 Python 环境、Node 包或配置 API 密钥，只要使用 Cursor，就能享受一致的摘要体验。
2. 上下文感知：Cursor 的 AI 模型在应用规则时，能充分理解当前项目的代码上下文。这对于技术会议尤其重要，AI 在总结时能更好地理解提到的类名、函数或技术栈，减少术语误解。
3. 交互式修正：与 n8n 的“一次输入，静态输出”不同，在 Cursor Chat 中生成摘要后，你可以立即就任何不准确的地方与 AI 进行对话式修正。比如：“把第三个待办项的负责人从张三改为李四”，这比重新跑一遍工作流要灵活得多。
4. 成本与隐私：所有处理都在本地通过 Cursor 完成，无需将可能敏感的会议录音或文字稿发送到第三方服务，对于内部会议的信息安全是一个重要保障。

2.2 双模块设计：规则引擎与提示词工厂

项目清晰地分成了两个松耦合的模块，这种设计让工具既“开箱即用”，又“灵活可配”。

核心模块一：Cursor 规则文件（.cursor/rules/meeting-summarizer.mdc）这是项目的大脑。它定义了当用户在聊天中请求总结会议时，AI 应该遵循的“宪法”。这个规则文件做了以下几件关键事：

• 强制结构化输出：它要求 AI 必须按照“摘要（Summary）”、“决策（Decisions）”、“行动项（Action Items）”、“关键点（Key Points）”、“风险与阻碍（Risks/Blockers）”这五个固定部分来组织内容。这种一致性对于后续的信息检索和团队同步至关重要。
• 实施人名校正：语音转文字（STT）服务经常搞错人名，比如把“Forrest”听成“Boris”。规则里内置了一个校正表（如"Boris": "Forrest"），AI 会在输出前自动替换，确保纪要中称呼正确。
• 格式化与空值处理：它规定了每个部分标题的格式（如## Decisions），并特别强调，如果会议中确实没有提及某项内容（如无任何决策），则输出“None stated”或“None noted”，而不是留空或胡编乱造。这保证了文档的完整性。

核心模块二：Web 提示词构建器（静态 HTML/JS 应用）这是项目的双手，主要解决“输入体验”问题。原始的会议转录文本（尤其是.vtt字幕文件）往往包含时间戳、说话人标记等冗余信息，直接丢给 AI 会干扰判断，也浪费 Token。 这个静态 Web 应用提供了一个干净的 UI，让你可以：

• 上传.vtt文件：它会自动解析文件，剥离时间戳，将多行对话合并成连贯的段落，只保留纯净的对话文本。
• 补充元数据：通过下拉菜单选择会议类型（如“需求评审”、“技术设计”）、填写日期时间，这些信息会作为上下文提供给 AI，帮助它更好地理解会议性质。
• 整合 Copilot 摘要：如果你在会议中使用了类似 Microsoft Copilot 的辅助工具生成了初步摘要，可以将其粘贴进来，AI 会将其作为参考，生成更精炼的最终版。
• 一键生成提示词：点击按钮，它会将所有信息（元数据、转录文本）打包成一条格式工整、指令清晰的提示词，你只需复制并粘贴到 Cursor Chat 即可。

这两个模块可以独立使用。你可以只用规则文件，在聊天中手动粘贴文本并口述指令；也可以使用 Web 应用来提升准备工作的效率。它们通过一份共享的配置（如人名校正表）保持同步。

3. 详细实操指南：从零部署到日常使用

下面，我将一步步带你完成整个工具的设置和使用过程。请确保你已安装并熟悉 Cursor 的基本操作。

3.1 环境准备与项目初始化

首先，你需要将项目代码获取到本地。假设你使用 Git：

git clone <项目仓库地址> cd Cursor-Tool--Meeting-Summarizer

观察项目结构，核心文件如下：

. ├── .cursor/ │ └── rules/ │ └── meeting-summarizer.mdc # Cursor 规则文件 ├── meeting-summarizer-prompt-builder.html # Web 应用主界面 ├── assets/ │ └── meeting-summarizer-prompt-builder.css └── JS/ ├── meeting-summarizer-prompt-builder.js ├── meeting-summarizer-config.js # 默认配置（人名校正、下拉选项） └── meeting-summarizer-rule.js # 规则文本（用于 Web 应用展示）

第一步：激活 Cursor 规则这是最关键的一步，让 Cursor 学会你的纪要格式。

1. 将meeting-summarizer.mdc文件复制到你当前 Cursor 工作空间的.cursor/rules/目录下。如果该目录不存在，请手动创建。
2. 重启 Cursor（或重新加载当前窗口）。规则生效后，当你在这个工作空间内打开 Chat，AI 的行为就已经被约束了。你可以通过 Cursor 的设置界面查看已加载的规则来确认。

注意：规则是工作空间（Workspace）级别的。如果你希望在多个项目中使用，需要将.mdc文件分别放置到每个项目的.cursor/rules/目录下，或者考虑配置全局规则。

3.2 Web 提示词构建器的使用详解

这个 HTML 文件是纯静态的，无需任何服务器。你可以直接双击它在浏览器中打开，或者用file://协议访问。

界面功能区域解析：

1. 会议元数据区：填写会议主题（About）、选择类型（Type）、日期和时间。这些信息会作为系统提示的一部分，帮助 AI 把握会议基调。
2. Copilot 摘要区（可选）：如果你有会中生成的初步摘要，贴在这里。AI 会将其视为高质量参考，而非原始杂音。
3. 转录文本输入区：核心区域。提供两种方式：
   • 上传 VTT 文件：点击上传按钮，选择你的.vtt字幕文件。系统会自动处理，并在下方文本框中展示净化后的纯文本。这是最推荐的方式，能最大程度去除噪音。
   • 直接粘贴文本：如果你只有纯文本转录稿，直接粘贴进这个大文本框。
4. 操作按钮区：
   • Build prompt for Cursor：点击后，会将所有输入内容组装成一条完整的提示词，显示在下方。
   • Copy to clipboard：一键复制组装好的提示词。
   • Manage options：点击会弹出模态框，允许你自定义“会议类型”下拉框的选项，这些设置会保存在你浏览器的本地存储（localStorage）中。
   • Getting Started：点击查看完整的 Cursor 规则文本，方便你随时查阅格式要求。

一个完整的操作示例：假设你刚开完一个“API 设计评审会”，并有一个meeting.vtt文件。

1. 在 Web 页面中，About填写 “User Profile Service API Design Review”，Type选择 “Technical Design”。
2. 上传meeting.vtt文件。
3. 点击Build prompt for Cursor。你会看到生成了一段类似以下的文本：

   Please summarize the following meeting transcript using our standard meeting summary format. **About:** User Profile Service API Design Review **Type:** Technical Design **Date:** 2023-10-27 **Time:** 14:00-15:00 **Transcript:** [这里是净化后的会议对话全文...]

4. 点击Copy to clipboard。
5. 切换到 Cursor，在 Chat 中粘贴刚才复制的内容，按回车发送。

AI 会根据规则，生成一个包含五个部分的、格式工整的纪要。人名（如果配置了校正）也会被自动修正。

3.3 核心配置文件的同步与修改

为了保证 Web 应用展示的规则文本、默认的人名校正表与实际的 Cursor 规则文件一致，项目采用了“同步契约”模式。当你需要修改规则时，必须同步更新三个文件：

1. JS/meeting-summarizer-config.js：这里定义了nameCorrections的默认值（如"Boris": "Forrest"）和会议类型的默认下拉选项。
2. JS/meeting-summarizer-rule.js：这里存储了规则的纯文本字符串，用于在 Web 应用的 “Getting Started” 模态框中显示。
3. .cursor/rules/meeting-summarizer.mdc：这是真正生效的 Cursor 规则文件。

修改人名校正表的步骤：假设团队新来了一位同事“周毅”，但 STT 系统总是识别为“周一”。

1. 打开meeting-summarizer-config.js，在nameCorrections对象中添加一行："周一": "周毅"。
2. 打开meeting-summarizer-rule.js，在规则文本中对应的nameCorrections部分，同样添加"周一": "周毅"。
3. 打开meeting-summarizer.mdc文件，在规则定义中找到nameCorrections部分，添加相同的映射。
4. 验证：修改后，在 Web 应用中点击 “Getting Started”，确认显示的规则文本已更新。在 Cursor 中，用包含“周一”的转录文本测试，确认输出中已纠正为“周毅”。

重要提示：务必保持这三处修改的完全一致。如果发生不同步，用户从 Web 应用看到的规则说明可能和 Cursor 实际执行的规则不符，导致混淆。

4. 高级技巧与避坑指南

在实际使用几个月后，我积累了一些超出基础文档的经验，能帮你更好地驾驭这个工具。

4.1 转录文本的预处理与质量提升

AI 总结的质量，八成取决于输入文本的质量。原始的.vtt或.srt文件直接使用效果往往不佳。

• 必做：使用 Web 应用的文件上传功能：它内置的 VTT 解析器会做两件关键事：一是移除所有的时间戳行（如00:01:02.340 --> 00:01:05.678），二是将同一说话人的多行短句合并成段落。这能显著提升文本可读性并减少 Token 消耗。
• 可选：人工清理：对于非常重要的会议，在将净化后的文本粘贴进 Web 应用前，可以快速扫一遍，手动修正一些明显的、严重的语音识别错误，特别是产品名、技术术语和数字。例如，把“死磕”改为“Sketch”，把“一二三”改为“123”。这步投入几分钟，能极大提升最终纪要的准确性。
• 处理多人会议：如果转录文件包含了说话人标识（如Speaker 1:），保留它们通常有益，因为 AI 能借此区分不同角色的发言。Web 应用的解析器会保留这些标识。

4.2 与 Cursor Chat 的高效交互策略

仅仅粘贴提示词然后等待，可能不是最高效的方式。

• 分步总结：对于超长会议（超过1小时），可以尝试分步指令。先让 AI 总结前半部分，再总结后半部分，最后再让它整合成一份完整的纪要。指令可以是：“请先总结前30分钟的讨论，聚焦于需求争议部分。” 然后再提供后续文本。
• 追问与修正：AI 生成初版后，充分利用 Chat 的交互性。如果觉得某个行动项描述模糊，可以直接问：“请将第三条行动项‘优化性能’具体化，会上提到了哪些可执行的步骤？” AI 会根据上下文的原始转录文本进行细化。
• 利用规则alwaysApply: true：项目中的规则设置了alwaysApply: true，这意味着在该工作空间内，任何聊天对话都会尝试应用此规则。当你单纯想和 AI 讨论代码而不需要会议总结格式时，可能会感到干扰。此时，你可以在提问时稍作说明，例如：“（忽略会议总结格式）请帮我 review 这段 Python 代码的逻辑。” 或者，临时将规则文件的alwaysApply改为false。

4.3 数据持久化与团队共享方案

Web 应用的管理选项（Manage Options）默认保存在浏览器的 localStorage 里，换台电脑或浏览器就没了。对于团队共享，有几种方案：

1. 配置文件版本化：最推荐的方式是直接修改JS/meeting-summarizer-config.js文件中的默认配置。然后通过 Git 将整个项目仓库共享给团队成员。大家拉取代码后，Web 应用就会加载统一的默认选项。个人仍然可以在浏览器端进行自定义，但团队基准是一致的。
2. 轻量级后端（可选）：项目提到了可选的/api/config端点。如果你团队有内部服务器，可以部署一个简单的服务，让 Web 应用从此处读写共享配置。但这引入了运维成本，对于小团队来说，方案1通常足够。
3. 规则文件分发：确保团队每个成员都在其项目工作空间的.cursor/rules/目录下放置了最新的.mdc规则文件。这是保证摘要格式统一的基础，可以通过 Git 模板钩子或共享文档说明来规范化。

4.4 常见问题排查与解决

即使准备充分，使用时也可能遇到一些小问题。下面是一个快速排查指南：

5. 与原有 n8n 工作流的对比与选型建议

这个项目起源于对 n8n 工作流的模仿，但它在本地化、轻量化方面做出了取舍。理解这些差异能帮助你做出正确的技术选型。

优势（选择 Cursor 方案的理由）：

• 部署与使用成本极低：无需维护 n8n 服务器、MongoDB 数据库，以及连接它们的 API 密钥和网络配置。所有东西都在本地。
• 交互性与即时修正：最大的优势。在 Chat 中与 AI 就纪要内容进行多轮对话、修正、细化的体验，是单向的 n8n 工作流无法比拟的。
• 隐私与安全：所有数据（会议转录稿）不出本地，满足更高安全合规要求。
• 与开发环境深度集成：在讨论技术方案时，AI 能直接引用当前项目中的代码文件，做出的总结更具技术上下文。

局限（需要继续使用或补充 n8n 的场景）：

• 缺乏自动化归档：n8n 工作流可以在生成摘要后，自动将其存入 MongoDB 或 Notion、Confluence 等知识库。Cursor 方案生成的纪要目前只存在于聊天历史中。你需要手动复制保存。如果需要自动化，可以额外编写一个简单的脚本，监听 Cursor 的某个输出目录或通过其 API（如果未来提供）来抓取摘要并存储。
• 处理流程非链式：n8n 可以设计复杂的链式流程，例如先让模型 A 总结，再让模型 B 润色或提取特定实体。Cursor 中目前是一次性完成。虽然可以通过连续对话模拟多步，但不如工作流可视化、可固化。
• 批处理能力弱：如果需要一次性总结大量历史会议录音，n8n 的流水线作业更高效。Cursor 方案更适合实时或临时的单次会议处理。

我的实践建议：对于日常、高频、实时的会议纪要需求，尤其是技术团队内部的会议，强烈推荐使用这个 Cursor 本地方案。它的便捷性和交互性提升是巨大的。而对于需要自动化归档、生成报表或处理大批量历史数据的场景，则应该保留或优化原有的 n8n 工作流，两者可以并存，服务于不同的用例。

这个工具的本质，是将一个好的、经过验证的会议摘要“逻辑”和“格式”，从云端工作流下沉到了你每天使用的 IDE 环境中。它可能没有解决所有问题，但它确实把一个繁琐、重复的任务，变得简单、顺手了许多。