很多时候，会议真正麻烦的地方并不在开会，而是在会后：要整理会议纪要、确认谁负责什么、写跟进邮件，还要同步到任务系统里。对于经常开项目会、客户会、销售沟通会、产品评审会的团队来说，这类重复工作其实很适合交给 AI 来辅助完成。
在这里插入图片描述

这篇文章会以 ClaudeAPI 为例，讲一套比较完整的流程：从会议逐字稿出发，自动生成会议总结、提取行动项，并草拟会后跟进邮件。先说明一下，这里说的 ClaudeAPI 是第三方 Claude API 兼容接入服务平台，并不是 Anthropic 官方服务。至于模型、价格、额度、线路可用性这些信息，还是要以 ClaudeAPI 官网或控制台的最新说明为准。

这篇教程能帮你自动化什么？

这个流程的输入一般会包括几类内容。

比如，最基础的是会议逐字稿，可能来自 Zoom、Teams、Google Meet、飞书、腾讯会议，也可能是录音转写工具生成的文本。除此之外，最好再补充一些会议背景信息，比如会议标题、日期、参会人、会议类型等。你还可以指定输出偏好，比如用中文、英文还是双语，风格是正式一点、简洁一点，还是更适合客户沟通。

最终生成的内容通常包括：

  • 结构化的会议总结；
  • 关键结论和已经确认的决策；
  • 行动项，也就是 Action Items；
  • 风险、阻塞点和待确认问题；
  • 会后跟进邮件草稿；
  • 如果需要，还可以同步到 Notion、Jira、Trello、飞书多维表格或 Google Sheets。

这个流程适用于很多场景，比如项目例会、客户会议、销售跟进、产品评审、招聘面试、复盘会等。不过要注意，不同类型的会议关注点不一样，不能简单套用同一个会议纪要模板。销售会更关心客户痛点和下一步推进，项目会更重视负责人、截止时间和风险项。

整体工作流：从会议逐字稿到跟进邮件

一个比较通用、也方便复用的会议纪要自动化流程，可以按下面的思路来做。

先拿到会议录音或逐字稿，然后对逐字稿做简单清洗，保留发言人、时间戳和关键背景。接下来调用 ClaudeAPI 生成结构化会议总结，再从总结和原始逐字稿中提取行动项。等这些内容整理好之后，就可以根据收件人身份和邮件语气生成跟进邮件草稿。最后一定要有人做审核，确认事实、日期、金额和承诺没有问题。如果团队有需要，再同步到项目管理、CRM 或邮件系统里。

这里有一个关键点：AI 适合用来整理和草拟，但不建议默认自动发送邮件。尤其是涉及客户承诺、报价、合同、交付日期这类敏感内容时，人工确认这一步不能省。

准备工作：ClaudeAPI、逐字稿和运行环境

在使用 ClaudeAPI 之前，通常需要先准备好这些东西：

  • ClaudeAPI 平台账号和 API Key；
  • 当前控制台里可用的模型名称；
  • Python 或 Node.js 运行环境；
  • 一份已经初步清洗过的会议逐字稿；
  • 明确的输出格式，比如 Markdown 或 JSON。

常见的请求结构一般会包含几个字段。system 用来定义模型的角色、规则和边界；user 放会议背景、逐字稿和输出要求；max_tokens 用来限制输出长度；temperature 建议设置低一些，比如 0.2 到 0.4，这样结果会更稳定；model 则填写控制台当前支持的模型名称。

一个简化版的 Node.js 伪代码大概是这样：

const response = await client.messages.create({
  model: "以控制台可用模型为准",
  max_tokens: 3000,
  temperature: 0.2,
  system: "你是严谨的会议纪要助手，只能依据原文总结，不得编造。",
  messages: [
    {
      role: "user",
      content: `请根据以下会议逐字稿生成会议总结、行动项和邮件草稿：\n${transcript}`
    }
  ]
});

真正接入时，还需要按照 ClaudeAPI 的兼容接口文档配置 base URL、鉴权方式和 SDK。不同平台的实现细节可能会调整，所以最好始终以官方接入文档为准。

第一步：整理会议逐字稿，让 AI 更容易抓住重点

会议总结生成得好不好，很大程度上取决于输入质量。原始转写里经常会有口头禅、重复句子、识别错误和一些无关寒暄。如果直接把这些内容全部丢给模型，不仅会增加 token 成本，也容易影响行动项提取的准确性。

比较理想的输入可以保留这些信息：

会议标题：Q3 官网改版项目例会
日期：2025-xx-xx
参会人：张三、李四、王五
会议类型：项目例会
目标：确认首页设计稿、开发排期和上线风险

[00:03:12] 张三：首页设计稿今天定稿，李四周五前给到最终版本。
[00:05:40] 李四：可以，但移动端还有两个交互需要产品确认。
[00:08:20] 王五：开发下周一开始，预计两周完成，接口文档需要后端周三前补齐。

清洗时，可以删掉一些明显没有价值的内容，比如：

  • “嗯”“然后”“对对对”这类口头禅；
  • 跟会议主题无关的闲聊；
  • 明显重复的转写片段；
  • 已经确定是识别错误、但又无法还原的内容。

不过，决策、日期、负责人、金额、交付范围这些关键信息千万不要随手删掉。如果有些内容听起来不确定，可以保留，并标注为“疑似”或“待确认”。这样后面人工审核时也更方便。

第二步：用 ClaudeAPI 生成结构化会议总结

写会议总结的 Prompt 时，最好明确告诉模型要区分事实、决策和待确认事项。不要只写一句“帮我总结会议”，因为这样生成出来的内容往往比较泛，很容易漏掉真正重要的信息。

下面是一段可以复用的 Prompt：

你是严谨的会议纪要助手。请只根据会议逐字稿生成总结，不得编造原文没有的信息。

请输出 Markdown，包含：
1. 会议概览
2. 关键结论
3. 已确认决策
4. 讨论重点
5. 风险与阻塞
6. 待确认问题
7. 下一步计划

规则：
- 如果负责人、日期或结论没有明确出现，写“未明确”
- 涉及金额、交付时间、合同条款时标记“需人工确认”
- 不要新增会议中没有出现的承诺
- 输出语言：中文

推荐的输出格式可以这样设计：

## 会议概览
- 会议主题：
- 会议目标：
- 参会人：
- 总体结论：

## 已确认决策
- 决策 1：
- 决策 2：

## 风险与阻塞
- 风险：
- 影响：
- 建议处理人：

如果是销售会议，就要重点提取客户痛点、预算、决策链和下一步跟进安排；如果是项目例会，负责人、截止日期和阻塞项会更重要；如果是招聘面试，则要关注候选人的能力表现、潜在风险和后续安排。换句话说，Prompt 最好跟会议类型匹配，而不是所有会议都用同一套模板。

第三步：自动提取行动项 Action Items

行动项不应该只是一串简单的待办列表。为了后续能导入任务系统，最好把每个行动项都结构化，比如用 JSON 表示：

{
  "action_items": [
    {
      "task": "补齐接口文档",
      "owner": "后端团队",
      "due_date": "周三前",
      "priority": "高",
      "context": "开发下周一开始，需要接口文档支撑排期",
      "status": "待处理",
      "evidence": "接口文档需要后端周三前补齐"
    }
  ]
}

行动项提取 Prompt 可以这样写：

请从会议逐字稿中提取行动项，并输出合法 JSON。

字段要求：
- task：具体任务
- owner：负责人；未明确则写“未明确”
- due_date：截止时间；未明确则写“未明确”
- priority：高/中/低；无法判断则写“未明确”
- context：任务背景
- status：待处理/待确认/已完成
- evidence：原文依据

规则：
- 不得编造负责人和截止日期
- 重复任务需要合并
- “下周看一下”这类模糊表达标记为“待确认”
- 输出必须是 JSON，不要附加解释

如果后面要导入 Notion、Jira 或 Google Sheets，就可以把 JSON 字段直接映射成表格字段。不过建议先做人工审核，再批量创建任务。否则 AI 有可能把会议里的讨论假设，误判成已经确认的正式任务。

第四步：用 AI 生成会后跟进邮件

AI 写跟进邮件的价值，主要是帮你节省整理表达的时间。但邮件内容必须受会议事实限制，不能让模型自由发挥。Prompt 里要说清楚：不得新增承诺，也不能替参会人做会议里没有确认过的决定。

邮件 Prompt 示例：

请根据会议总结和行动项生成一封会后跟进邮件。

变量：
- 收件人类型：客户
- 语气：正式、简洁、友好
- 语言：中文
- 长度：300 字以内

邮件必须包含：
1. 简短感谢
2. 核心结论
3. 行动项列表
4. 待确认问题
5. 下一次跟进时间，如未明确则写“待确认”

限制：
- 不得新增会议中没有出现的承诺
- 涉及报价、合同、上线日期必须标记需人工确认
- 不要使用夸张营销语

如果是发给内部团队，表达可以更直接一些：

主题：Q3 官网改版项目例会纪要与行动项

各位好，以下是本次会议同步：

1. 核心结论
- 首页设计稿本周进入最终确认阶段。
- 开发计划下周一启动，接口文档是当前前置依赖。

2. 行动项
- 李四：周五前提交首页最终设计稿。
- 后端团队：周三前补齐接口文档。
- 产品团队：确认移动端两个交互问题。

3. 待确认
- 移动端交互方案仍需产品确认。
- 具体上线日期需结合开发进度再评估。

如有遗漏，请在邮件中补充。

如果是客户邮件，就要更谨慎一些。尤其不要在语气上显得已经承诺了交付时间、价格或范围，除非这些内容在会议中已经明确确认。

一次请求生成 vs 分步骤生成：哪种更适合你？

方式 优点 缺点 适合场景
一次性生成总结、行动项、邮件 简单、速度快 不太方便单独校验 短会议、内部例会
分步骤生成 更稳定，也更便于调试 请求次数会更多 客户会议、项目会议
分块处理后合并 适合长会议 实现起来更复杂 研讨会、访谈、培训

如果只是做一个最小可用版本，可以先用一次请求跑通流程。等会议变长，或者结果要进入 CRM、任务系统，再改成分步骤会更稳：先生成总结，再提取行动项，最后写邮件草稿。这样每一步都能单独检查，出错时也更容易定位。

长会议怎么处理：分段摘要与行动项合并

长会议逐字稿很容易超过单次请求的理想处理范围。即使模型支持较长上下文，也不代表应该把所有内容一次性塞进去。更稳妥的做法是使用类似 Map-Reduce 的流程。

可以先按时间或议题把逐字稿切成几段，每一段分别生成局部摘要、局部决策和局部行动项。然后把这些局部结果汇总起来，再让模型生成全局总结。接着合并重复行动项，并保留原始片段编号，方便后续人工核查。

合并阶段的 Prompt 可以强调这些规则：

请合并以下分段行动项：
- 相同任务只保留一条
- 负责人冲突时标记“需人工确认”
- 截止日期冲突时保留所有候选日期并标记“需人工确认”
- 不得新增原文没有的信息

这样做的好处很明显：一方面能减少长文本中的遗漏，另一方面也方便回查原文，降低错误定位成本。

如何降低成本并提升稳定性？

成本通常跟输入 token、输出 token、模型单价和请求次数有关。具体价格还是要看服务平台的最新说明。工程上可以从几个方向优化。

比如，先清洗逐字稿，把没意义的口头禅和重复片段删掉；控制输出格式，避免模型生成一大段散文式内容；短会议可以一次请求，长会议则分块处理。对于 JSON 输出，最好加 schema 校验。如果 JSON 解析失败，可以自动重试一次，并在重试 Prompt 里强调“只输出合法 JSON”。

另外，日志也要谨慎处理。可以记录请求 ID、输入摘要和错误信息，但不要把完整敏感逐字稿写进日志里。

模型选择也不用一刀切。高风险客户会议、复杂谈判、长访谈，可以考虑使用能力更强的模型；普通内部例会、固定模板纪要，则可以选择更轻量的模型来控制成本。具体能用哪些模型，还是以 ClaudeAPI 控制台为准。

常见错误与解决方法

1. Claude 输出不是合法 JSON
解决方法：在 Prompt 里明确写“只输出 JSON，不要 Markdown”，同时在程序里做 JSON parse 校验。如果失败，就带上错误信息重试一次。

2. 行动项缺少负责人
解决方法：不要让模型猜负责人。没明确出现就写“未明确”，并在邮件里列为待确认问题。

3. 邮件语气太生硬
解决方法：把语气作为变量传进去，比如“正式但友好”“面向客户”“面向内部研发团队”。这样输出会更贴近实际场景。

4. 会议总结漏掉关键决策
解决方法：在 Prompt 里单独要求输出“已确认决策”，最好再要求给出原文依据，方便人工核对。

5. 长文本超出上下文或质量下降
解决方法：按议题或时间切块，先生成局部摘要，再合并成全局总结。

6. API 超时或限流
解决方法：加入超时控制、指数退避重试和队列处理。失败后不要无限重试，否则可能造成额外成本和系统压力。

安全与合规：哪些会议不应该直接自动化？

会议内容里可能包含客户信息、商业机密、员工资料、财务数据和法律事项。使用 ClaudeAPI 或任何第三方兼容接入服务之前，都应该先确认公司内部的数据处理要求。

建议至少遵守这些原则：

  • 不上传未经授权的敏感录音或逐字稿；
  • 涉及人事、法务、财务、合同的会议，必须由人工复核；
  • 不把完整敏感逐字稿写入日志；
  • 邮件发送前确认收件人、抄送人和附件；
  • 不让 AI 自动承诺价格、合同条款、上线日期或交付范围；
  • 企业场景下，应设置访问权限、审批流程和数据留存策略。

说到底，AI 可以提高整理效率，但不应该替人承担最终责任。尤其是涉及外部客户和正式承诺时，人工审核非常必要。

完整示例：输入一段会议逐字稿，输出总结、行动项和跟进邮件

输入逐字稿：

会议标题：客户官网改版需求沟通
参会人：客户方赵经理、我方张三、设计李四

赵经理：我们希望新版官网下月底前能上线，重点是突出案例和咨询入口。
张三：下月底上线需要确认内容素材，如果本周能收到案例资料，我们可以评估排期。
李四：设计这边周五前可以给首页初稿。
赵经理：案例资料我安排同事整理，但具体时间我再确认。

会议总结：

## 会议概览
本次会议围绕客户官网改版需求展开，重点包括上线期望、案例展示、咨询入口和首页设计排期。

## 关键结论
- 客户希望新版官网突出案例和咨询入口。
- 客户期望下月底前上线，但该时间仍需结合素材和排期评估。
- 我方设计可在周五前提供首页初稿。

## 待确认问题
- 客户案例资料提供时间未明确。
- 下月底上线是否可行需进一步评估。

行动项 JSON：

{
  "action_items": [
    {
      "task": "提供首页设计初稿",
      "owner": "李四",
      "due_date": "周五前",
      "priority": "高",
      "context": "客户官网改版需要先确认首页方向",
      "status": "待处理",
      "evidence": "设计这边周五前可以给首页初稿"
    },
    {
      "task": "整理并提供案例资料",
      "owner": "客户方",
      "due_date": "未明确",
      "priority": "高",
      "context": "上线排期依赖案例资料",
      "status": "待确认",
      "evidence": "案例资料我安排同事整理，但具体时间我再确认"
    }
  ]
}

跟进邮件草稿：

主题：官网改版需求沟通纪要与下一步事项

赵经理您好，

感谢今天沟通。根据会议内容，本次官网改版将重点突出客户案例和咨询入口。关于下月底上线的目标，我方需要在收到案例资料后进一步评估排期，因此该时间点建议先标记为待确认。

下一步事项如下：
1. 我方李四将在周五前提供首页设计初稿。
2. 客户方将安排整理案例资料，具体提供时间待确认。
3. 我方将在收到素材后评估整体上线排期。

如以上内容有遗漏或需要调整，欢迎直接回复补充。

这封邮件虽然已经比较完整，但仍然建议人工确认后再发送。尤其是上线时间、素材提供时间这些内容，最好不要让 AI 直接替双方定下来。

ClaudeAPI、自建脚本和无代码工具怎么选？

方案 适合人群 优点 局限
ClaudeAPI + 脚本 开发者、产品团队 灵活、可控，方便集成 需要一定开发能力
Make / Zapier / 飞书自动化 运营、非技术用户 上手快，配置成本低 复杂逻辑会受限制
企业 Agent / MCP / Graph API 中大型企业 权限管理和系统集成更强 部署和维护更复杂
手动使用 Claude 网页版 个人用户 最简单，几乎没有开发成本 不适合规模化

如果只是个人使用，可以从最简单的方式开始：手动复制逐字稿，让 Claude 生成会议纪要。等团队每周会议量比较大之后，再考虑用 ClaudeAPI 接入脚本，把会议总结、行动项提取和邮件草稿生成做成固定流程。这样投入产出比通常会更好。

总结：最小可用版本怎么做？

最小可用版本不需要一开始就接入所有系统。更现实的做法是分三步走。

第一步，先实现“逐字稿 → 会议总结自动生成”，把最耗时间的纪要整理先省下来。第二步，再加入行动项 JSON，方便后续导入任务系统。第三步，生成跟进邮件草稿，但保留人工审核，不要直接自动发送。

等流程稳定之后，再考虑接入邮件草稿箱、项目管理工具和企业权限系统。这样既能明显减少会后整理时间，也能避免 AI 编造内容、误发邮件、泄露敏感信息等风险。

Logo
https://edu.csdn.net/learn/39067/627173?utm_source=2019755004

汇聚全球AI编程工具，助力开发者即刻编程。

更多推荐

cover

【Claude】Could not resolve authentication method 报错已解决

avatar AI编程社区
cover

【Claude】Prompt is too long 上下文超长报错已解决

avatar AI编程社区
cover

【Claude】Credit balance is too low 余额不足报错已解决

avatar AI编程社区