1. 项目概述：用AI自动生成会议纪要，解放你的双手

如果你和我一样，每周都要参加好几个小时的线上会议，会后还得花时间整理纪要、提炼要点、分发邮件，那你一定会对这个项目感兴趣。 AutohostAI/meeting-notes 是一个开源项目，它巧妙地串联了 Google Meet、Google Drive、OpenAI 的 GPT 模型以及 AWS 云服务，实现了一个全自动的会议纪要生成与分发系统。简单来说，就是会议一结束，所有参会者就能立刻收到一封结构清晰、重点突出的 AI 总结邮件。

这个项目的核心价值在于，它把我们从繁琐的会后工作中彻底解放出来。你不再需要一边听录音回放，一边手忙脚乱地敲键盘。它自动抓取会议转录稿，利用大语言模型提炼出摘要、关键决策和后续行动项，然后一键发送给所有人。这对于需要频繁开会、追求效率的团队，尤其是远程协作团队来说，简直是生产力神器。无论你是团队管理者、项目经理，还是任何希望优化会议流程的工程师，这个方案都值得你深入了解甚至亲手部署一套。

2. 系统架构与核心工作流拆解

在动手部署之前，我们必须先吃透整个系统是如何运转的。这不仅能帮助我们在部署时胸有成竹，更能在出现问题时快速定位。整个系统的架构可以看作一个由事件驱动的自动化流水线。

2.1 核心工作流详解

整个流程始于一次开启了转录功能的 Google Meet 会议，终于一封发送到所有参会者邮箱的总结邮件。我们可以将其分解为五个关键步骤：

  1. 触发与采集 ：用户在 Google Meet 会议中手动启用“转录”功能。会议结束后，Google Meet 会自动将生成的文字转录稿（一个 Google Docs 文档）保存到会议发起者的 Google Drive 的特定文件夹中。这是整个流程的数据源头。

  2. 事件通知 ：当新的转录文件被创建到 Drive 时，Google Drive 的变更推送通知功能会向一个预先配置好的 Webhook 端点发送一个 HTTP POST 请求。这个请求就像一个“警报”，告诉我们的系统：“嘿，有新的会议记录来了！”

  3. 消息中转与缓冲 ：系统暴露的 API 端点（一个 AWS Lambda 函数）接收到这个 Webhook 请求。API 并不会立即处理文件内容，而是将文件的关键信息（如文件ID、标题、所有者邮箱）封装成一个消息，投递到一个 AWS SQS 队列中。这里引入队列是系统设计的一个精妙之处，它实现了 解耦 和 削峰填谷 。即使短时间内有多场会议结束，产生大量 Webhook 请求，API 也能快速响应（只负责投递消息），而繁重的处理任务则由下游的“工人”按自己的节奏从队列中取出处理，避免了因处理超时而导致的 Webhook 失败或丢失。

  4. 智能处理核心 ：另一个独立的 Lambda 函数（我们称之为 Worker）作为消费者，从 SQS 队列中取出消息。它根据消息中的文件ID，使用服务账号凭证通过 Google Drive API 下载转录文档的纯文本内容。然后，它将这份可能冗长的文本发送给 OpenAI 的 gpt-3.5-turbo-16k 模型，并附上一段精心设计的提示词，要求模型提取参会者名单、生成会议摘要、列出关键决策和后续行动项。

  5. 结果交付 ：Worker 获得 AI 生成的格式化总结后，利用 Mailgun 的邮件发送 API，将这份总结通过电子邮件发送给所有参会者（通常可以从转录稿的元数据或会议邀请中解析出邮箱列表）。邮件中还会附上原始转录稿的链接，供需要查阅细节的参会者使用。

注意 ：这个架构是典型的“事件驱动+队列缓冲”的 Serverless 应用模式。它的优势在于高弹性、低成本（只有实际运行时才计费）和良好的可维护性。每个环节（API、Worker）都是无状态的，可以独立扩展。

2.2 技术栈选型背后的考量

为什么选择这些技术？每个选择都有其实际意义：

  • AWS Lambda & API Gateway ：处理 Webhook 和异步任务执行的理想选择。无需管理服务器，自动扩缩容，按调用次数和运行时间付费，非常适合这种间歇性、突发性的工作负载。
  • Amazon SQS ：作为可靠的中间件，确保 Webhook 事件不丢失。即使 Worker 暂时不可用，消息也会在队列中保留，直至被成功处理。它提供了“至少一次”的投递保证，是构建可靠异步系统的基石。
  • OpenAI GPT-3.5-Turbo-16k ：相比标准的 4k 上下文版本，16k 版本能处理更长的文本。一场一小时的会议转录稿很容易超过 4k Token，选用 16k 模型可以确保完整内容被一次性分析，避免因截断而丢失重要信息。GPT-3.5 在成本、速度和总结能力上取得了很好的平衡。
  • Mailgun ：专注于邮件发送的第三方服务，提供可靠的 API、邮件模板、投递状态跟踪和反垃圾邮件管理。比自己搭建 SMTP 服务器省心得多。
  • Google Cloud 服务账号 ：这是安全访问 Google Drive 数据的关键。使用服务账号并进行“全域授权”，可以让我们的应用代表域内任何用户访问其 Drive 文件（前提是文件已共享给该服务账号或位于其可访问的共享驱动器），而无需获取每个用户的 OAuth 令牌。

3. 前期准备与环境配置实操

在开始构建和部署之前，我们需要在多个云服务平台完成账号注册和关键资源的创建。请准备好你的邮箱，我们依次来搞定。

3.1 账号与密钥准备清单

你需要注册并获取以下所有服务的访问凭证，请像保管密码一样保管它们：

  1. OpenAI 账号 ：访问 OpenAI Platform，在 API Keys 页面生成一个新的 API Key。同时，记下你的 Organization ID（在组织设置里）。项目将使用 gpt-3.5-turbo-16k 模型。
  2. AWS 账号 ：确保你有一个 AWS 账号，并配置好 AWS CLI，且拥有在目标区域（如 us-east-1 ）创建 IAM 角色、Lambda、SQS、API Gateway 等资源的权限。
  3. Google Workspace 账号 ：你需要一个 Google Workspace（原 G Suite）的管理员账号。因为后续需要配置全域授权，这通常需要管理员权限。同时，确保你的 Google Meet 和 Drive 服务正常。
  4. Google Cloud 项目 ：在 Google Cloud Console 创建一个新项目（或使用现有项目）。我们需要在这个项目下启用 API 并创建服务账号。
  5. Mailgun 账号 ：注册 Mailgun，你需要验证一个发信域名（Mailgun 会提供沙箱域名，但用于生产建议使用自己的域名）。获取你的 API Key 和配置好的发信域名。

3.2 创建 Google Cloud 服务账号并配置全域授权

这是整个流程中权限配置最核心也最容易出错的一步。我们的目标是创建一个有权限访问用户 Google Drive 中会议转录文件的服务账号。

步骤一：在 Google Cloud Console 中操作

  1. 进入你的 GCP 项目，导航到 “IAM 和管理” -> “服务账号” 。
  2. 点击“创建服务账号”，给它起一个易于识别的名字，例如 meeting-notes-drive-accessor 。服务账号 ID 会自动生成，描述可以填写“用于访问 Google Meet 转录文件”。
  3. 点击“创建并继续”。在“授予此服务账号对项目的访问权限”这一步，暂时不需要添加任何角色，直接点击“完成”。（因为我们将通过域范围授权来赋予其 Drive 权限，而非在 GCP 项目内授权）。
  4. 在服务账号列表中，找到刚创建的服务账号，点击其邮箱进入详情页。
  5. 切换到 “密钥” 标签页，点击“添加密钥” -> “创建新密钥”，密钥类型选择 JSON 。点击创建后，一个包含私钥的 JSON 文件会自动下载到你的电脑上。请安全地保存这个文件，我们稍后会用到它，并将其重命名为 credentials.json 。

步骤二：在 Google Workspace 管理员控制台中配置全域授权

  1. 使用你的 Google Workspace 超级管理员账号登录 Admin Console 。
  2. 依次进入 “安全” -> “访问权限和数据控制” -> “API 控制” 。
  3. 点击 “管理全域授权” 。
  4. 点击 “添加新的” 。
  5. 在“客户端 ID”字段中，粘贴你刚刚下载的 credentials.json 文件中的 client_id 字段值（一串长的数字和字母组合，以 .apps.googleusercontent.com 结尾）。
  6. 在“API 范围”字段中，输入以下范围。这定义了服务账号可以访问的 API 和数据： 
    https://www.googleapis.com/auth/drive.readonly, https://www.googleapis.com/auth/drive.metadata.readonly
    drive.readonly 允许读取文件内容， drive.metadata.readonly 允许读取文件属性（如标题、所有者）。对于只读操作，这两个范围通常足够。
  7. 点击“授权”。

关键提示 ：全域授权生效可能需要几分钟时间。完成此步骤后，该服务账号就获得了代表你 Workspace 域内 任何用户 访问其 Drive 文件的权限（仅限只读）。这意味着，只要会议转录文件对域内用户可见（通常是会议创建者自己的文件），服务账号就能访问它。这是实现自动化无需用户交互登录的关键。

3.3 配置 Google Drive 的推送通知

为了让我们的系统能感知到新文件的创建，需要为服务账号的 Drive 设置一个“监听器”。

  1. 启用 Google Drive API ：回到 Google Cloud Console，进入 “API 和服务” -> “库” ，搜索并启用 Google Drive API 。
  2. 获取访问令牌（临时） ：我们需要用服务账号凭证获取一个访问令牌，用于调用 Drive API 来创建“看管”。你可以使用 gcloud CLI 或编写一个小脚本。这里用 curl 演示原理： 
    # 使用服务账号的 JSON 密钥文件获取 OAuth 2.0 访问令牌
curl -X POST \
  -H "Content-Type: application/json" \
  --data @credentials.json \
  "https://oauth2.googleapis.com/token" \
  --arg client_id "$(jq -r .client_id credentials.json)" \
  --arg client_secret "$(jq -r .client_secret credentials.json)" \
  --arg refresh_token "$(jq -r .refresh_token credentials.json)" \
  -d 'grant_type=refresh_token'
    实际上，更简单的方法是使用 Google 的客户端库。但项目本身的 Lambda 代码会处理与 Drive 的通信，我们部署后，API 需要被配置为 Webhook 的接收端。 你真正需要做的是，在部署完成后，获取到 API Gateway 生成的 HTTPS 端点 URL 。
  3. 创建“看管” ：理论上，你需要编写代码或使用 API 测试工具，以服务账号身份向 https://www.googleapis.com/drive/v3/changes/watch 端点发送一个 POST 请求，指定监听某个 Drive 文件夹（通常是 Meet 转录的默认保存位置）的变化，并将 address 参数设置为你的 AWS API Gateway 端点 URL。然而，在项目的实际部署中， 这一步通常被自动化了 。CloudFormation 模板可能不包含这部分，你需要根据你的 Workspace 设置，考虑是监听特定文件夹，还是依赖文件命名规则。一个更通用的做法是，在用户首次使用前，引导他们运行一个一次性脚本，为其个人 Drive 的根目录或特定文件夹创建“看管”。

实操心得 ：在实际测试中，我建议先专注于让 Worker 处理已有文件（通过指定文件ID）来验证 AI 总结和邮件发送流程。Webhook 的配置可以放在整个流程跑通之后再进行，这样可以分阶段排查问题。

4. 项目构建与云端部署全流程

环境准备就绪后，我们开始构建 Docker 镜像并将其部署到 AWS。项目使用 CloudFormation 进行基础设施即代码的部署，确保环境可重现。

4.1 本地构建 Docker 镜像

首先，将项目代码克隆到本地，并确保 credentials.json 文件已放置在项目根目录。

git clone <repository-url>
cd meeting-notes
# 将你的 credentials.json 文件放到这里

构建 Docker 镜像。项目 Dockerfile 会安装 Python 依赖，并将 credentials.json 复制到镜像内。

docker build --provenance=false -t meeting-notes .

--provenance=false 参数在某些 Docker 版本中用于禁用 SBOM 生成，以加快构建速度或避免兼容性问题。

4.2 推送镜像到容器仓库

你需要一个地方存放构建好的镜像。这里以 AWS ECR 为例，你也可以使用 Docker Hub 或其他私有仓库。

  1. 登录 ECR （以 us-east-1 区域为例）：

    aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin your-aws-account-id.dkr.ecr.us-east-1.amazonaws.com

    将 your-aws-account-id 替换为你自己的 12 位 AWS 账号 ID。

  2. 在 ECR 创建仓库 （如果尚未创建）：

    aws ecr create-repository --repository-name autohost-meeting-notes --region us-east-1

  3. 标记并推送镜像 ：

    docker tag meeting-notes:latest your-aws-account-id.dkr.ecr.us-east-1.amazonaws.com/autohost-meeting-notes:latest
docker push your-aws-account-id.dkr.ecr.us-east-1.amazonaws.com/autohost-meeting-notes:latest

    推送成功后，记下完整的镜像 URI，稍后部署时会用到。

4.3 配置与部署 CloudFormation 栈

CloudFormation 模板 ( cloudformation.yaml ) 定义了所有需要的 AWS 资源：Lambda 函数、SQS 队列、API Gateway、IAM 角色等。我们需要通过参数文件来定制化部署。

  1. 准备参数文件 ：

    cp stack-params.json stack-params-prod.json

    编辑 stack-params-prod.json 文件，填入你的实际值。以下是一个示例：

    [
  {
    "ParameterKey": "Architecture",
    "ParameterValue": "arm64"
  },
  {
    "ParameterKey": "ApiContainerImageUri",
    "ParameterValue": "your-aws-account-id.dkr.ecr.us-east-1.amazonaws.com/autohost-meeting-notes"
  },
  {
    "ParameterKey": "ApiContainerImageTag",
    "ParameterValue": "latest"
  },
  {
    "ParameterKey": "OpenaiApiKey",
    "ParameterValue": "sk-你的OpenAI密钥"
  },
  {
    "ParameterKey": "OpenaiOrgId",
    "ParameterValue": "org-你的组织ID"
  },
  {
    "ParameterKey": "StageName",
    "ParameterValue": "prod"
  },
  {
    "ParameterKey": "MailgunApiKey",
    "ParameterValue": "key-你的Mailgun密钥"
  },
  {
    "ParameterKey": "MailgunDomain",
    "ParameterValue": "your-domain.com"
  },
  {
    "ParameterKey": "S3Bucket",
    "ParameterValue": "your-meeting-notes-bucket"
  },
  {
    "ParameterKey": "WorkspaceEmails",
    "ParameterValue": "user1@your-company.com,user2@your-company.com"
  }
]
    • WorkspaceEmails ：这个参数很重要。它应该包含你 Google Workspace 域内 所有可能发起会议的用户邮箱 ，用逗号分隔。系统可能会用它来验证或过滤通知。如果你不确定，可以先填入管理员和几个测试用户的邮箱。

  2. 创建 S3 存储桶 ：CloudFormation 模板中可能引用了 S3 存储桶来存储 Lambda 代码或临时文件。你需要提前创建它：

    aws s3 mb s3://your-meeting-notes-bucket --region us-east-1

  3. 执行部署 ：

    aws cloudformation create-stack \
    --stack-name meeting-notes-prod \
    --capabilities CAPABILITY_NAMED_IAM \
    --tags Key=service,Value=meeting-notes Key=Environment,Value=prod \
    --parameters file://$(pwd)/stack-params-prod.json \
    --template-body file://$(pwd)/cloudformation.yaml \
    --region us-east-1 \
    --profile default

    这个命令会启动一个 CloudFormation 栈的创建过程。你可以通过 AWS 控制台或 aws cloudformation describe-stacks 命令查看创建进度。

  4. 获取 API 端点 ：部署成功后，在 CloudFormation 栈的“输出”选项卡中，找到 ApiGatewayInvokeURL 的值。这就是你的 Webhook 端点 URL，格式类似于 https://xxxxx.execute-api.us-east-1.amazonaws.com/prod/ 。你需要将这个 URL 配置到 Google Drive 的“看管”中。

4.4 本地测试与调试技巧

在部署到云端前，强烈建议在本地进行测试。项目支持使用 Lambda 容器镜像的运行时接口模拟器进行本地调用。

  1. 创建环境变量文件 .env ：在项目根目录创建 .env 文件，填入所有必要的环境变量，格式参考项目正文中的示例。确保 AWS_ACCESS_KEY_ID 和 AWS_SECRET_ACCESS_KEY 具有访问 SQS 和 S3 的权限。

  2. 构建并运行本地容器 ：

    docker build -t meeting-notes-local . && docker run -p 9000:8080 --env-file=.env --rm meeting-notes-local

    容器启动后，会在本地 9000 端口模拟 Lambda 运行时。

  3. 测试 Webhook 处理器 ：使用 curl 模拟 Google Drive 发送的 Webhook 事件。你需要从一次真实的 Google Drive 变更通知中获取 x-goog-resource-uri 和 x-goog-channel-token 的模拟值，或者根据代码逻辑构造一个。这个测试主要是验证 API 能否正确接收请求并将消息放入 SQS。

    curl -XPOST "http://localhost:9000/2015-03-31/functions/function/invocations" \
  -d '{"headers":{"x-goog-resource-uri":"https://www.googleapis.com/drive/v3/changes?alt=json&pageToken=dummy_token",
    "x-goog-channel-token":"test@your-domain.com"}}'

  4. 测试 Worker 处理器 ：这是更重要的测试，直接验证 AI 总结和邮件发送的核心逻辑。你需要准备一个真实的 Google Docs 转录文件的 ID 和链接。

    curl -XPOST "http://localhost:9000/2015-03-31/functions/function/invocations" \
  -d '{"Records":[{"messageId":"test-id","body":"{\"title\":\"Test Meeting Transcript\",\"id\":\"YOUR_REAL_GOOGLE_DOC_ID_HERE\",\"link\":\"https://docs.google.com/document/d/YOUR_REAL_GOOGLE_DOC_ID_HERE/edit\",\"owner_email\":\"owner@your-domain.com\"}"}]}'

    替换 YOUR_REAL_GOOGLE_DOC_ID_HERE 为一个你拥有访问权限的、包含会议转录内容的 Google Docs 的 ID。观察控制台日志，看是否能成功下载文档、调用 OpenAI API 并发送邮件。

踩坑记录 ：在本地测试时，最常见的错误是权限问题。确保你的 .env 文件中的 AWS_ACCESS_KEY_ID 和 AWS_SECRET_ACCESS_KEY 有足够的权限访问 SQS 和 S3（如果用到）。另外，Google 服务账号的 credentials.json 文件必须正确放置在镜像内，且对应的全域授权已生效。如果遇到 403 错误，优先检查这两点。

5. 核心功能实现与定制化开发

部署好基础框架后，我们深入看看核心的 AI 处理逻辑和如何根据自身需求进行定制。

5.1 AI 提示词工程与总结优化

项目的核心智能在于发送给 GPT 模型的提示词。原始的提示词可能隐藏在代码中。一个有效的会议总结提示词通常包含以下要素：

  • 角色设定 ：让 AI 扮演一个专业的会议记录员或助理。
  • 输入格式说明 ：明确告知 AI 输入是 Google Meet 的转录文本，可能包含说话人标签和时间戳。
  • 输出格式要求 ：指定需要提取的结构化信息，例如：
    1. 参会者列表 ：从转录内容中识别并列出所有发言人。
    2. 会议摘要 ：用一段话概括会议的核心内容和讨论过程。
    3. 关键决策 ：以 bullet points 形式列出会议中做出的所有决定。
    4. 后续行动项 ：列出所有明确的待办事项，最好能包含负责人（如果能从对话中推断）和模糊的时间要求。
  • 风格与长度要求 ：要求总结简洁、专业、使用中文（如果会议是中文），并控制字数。

你可以在项目代码中找到处理 Transcript 和调用 OpenAI 的 Lambda 函数（通常是 worker 函数），修改其中的 system 和 user 提示词来优化总结效果。例如，你可以要求 AI 特别关注“截止日期”、“谁来做”、“是否达成共识”等关键信息。

5.2 邮件模板设计与品牌化

发送给参会者的邮件是最终交付物，其美观度和清晰度直接影响用户体验。项目使用 Mailgun 发送邮件，很可能支持 HTML 模板。

  1. 定位邮件模板 ：在代码中搜索 send_email 或 Mailgun 相关的函数，找到构造邮件内容的逻辑。它可能是一个简单的字符串模板，也可能是从文件读取的 HTML 模板。
  2. 自定义 HTML 模板 ：你可以创建一个更精美的 HTML 文件，包含公司的 Logo、品牌色、更清晰的章节排版。将行动项用表格呈现，关键决策高亮显示。
  3. 动态数据注入 ：确保模板能接收并渲染 AI 生成的总结数据，如 {{summary}} , {{decisions}} , {{next_steps}} , {{transcript_link}} 等变量。
  4. 在 Mailgun 中配置 ：如果你使用 Mailgun 的模板功能，可以将设计好的 HTML 上传到 Mailgun，并在代码中指定模板名称。这样可以利用 Mailgun 的模板变量替换功能。

5.3 扩展功能思路

基础功能跑通后，可以考虑以下增强功能，这需要你修改 Lambda 函数代码并重新构建部署：

  • 多语言支持 ：检测转录文本的主要语言，并让 AI 用同一种语言生成总结。或者，固定输出中英文双语总结。
  • 情感分析与发言统计 ：让 AI 分析会议的整体氛围（积极、消极、中性），并统计每位发言人的讲话时长或次数，生成一个简单的“参与度”报告。
  • 集成到团队协作工具 ：除了发送邮件，还可以将总结自动发送到 Slack、Microsoft Teams 或钉钉的特定频道，甚至创建对应的 Jira Issue 或 Asana 任务。
  • 敏感信息过滤 ：在发送总结前，可以添加一个过滤层，对 AI 生成的内容进行扫描，屏蔽或标记可能包含的敏感信息（如内部代码、未公开数据等）。
  • 手动复核与编辑 ：在最终发送前，将总结先发送给会议主持人或指定人员，提供一个简单的 Web 界面供其编辑确认后再发送给全体参会者。

6. 运维监控与常见问题排查

系统上线后，稳定的运行和及时的故障排查至关重要。AWS 提供了一系列工具来帮助我们。

6.1 关键监控指标与告警设置

你应在 AWS CloudWatch 中为以下指标设置告警：

  1. Lambda 错误率 （ Errors 指标）：对于 API 和 Worker Lambda，设置当最近5分钟错误率超过1%时告警。错误可能源于权限问题、API 调用超限或代码异常。
  2. Lambda 执行时长 （ Duration 指标）：监控函数运行时间。如果接近超时时间（默认15分钟），需要优化代码或增加超时设置。特别是 Worker 函数，处理长转录和调用 OpenAI 可能耗时。
  3. SQS 队列深度 （ ApproximateNumberOfMessagesVisible ）：监控队列中积压的消息数量。如果消息数持续增长，说明 Worker 处理速度跟不上消息产生速度，可能需要增加 Lambda 并发限制或检查 Worker 函数性能。
  4. SQS 死信队列消息数 ：如果配置了死信队列，监控其中的消息数。这些是经过多次重试仍失败的消息，需要人工介入排查。
  5. Mailgun 发送失败 ：在代码中捕获 Mailgun API 的发送异常，并记录到 CloudWatch Logs 中。可以基于特定的错误日志模式创建指标过滤器并触发告警。

6.2 常见问题排查清单

当系统不工作时，按照以下步骤进行排查：

问题现象 可能原因 排查步骤
收不到 Webhook 1. Google Drive “看管”未创建或已过期。
2. API Gateway 端点 URL 不正确或未公开。
3. API Gateway 或 Lambda 权限错误。		 1. 检查 Google Cloud 项目中的“看管”列表。
2. 用 curl 或 Postman 手动调用 API Gateway 端点，看是否有响应。
3. 查看 API Gateway 和 Lambda 的 CloudWatch 日志。
Webhook 收到但无后续邮件 1. SQS 队列配置错误，消息未成功入队。
2. Worker Lambda 没有触发或执行失败。
3. 服务账号无法访问 Drive 文件。
4. OpenAI API 调用失败（密钥无效、超限）。
5. Mailgun 发送失败（密钥、域名无效）。		 1. 检查 SQS 控制台，查看队列中是否有消息。
2. 查看 Worker Lambda 的 CloudWatch 日志，这是最重要的信息源。
3. 在日志中检查下载 Drive 文件时的错误。
4. 检查 OpenAI API 密钥和环境变量 OPENAI_ORG_ID 是否正确。
5. 检查 Mailgun API 密钥和发信域名状态。
AI 总结内容质量差 1. 提示词设计不佳。
2. 转录文本质量低（多人同时说话、口音重、背景噪音）。
3. 模型 Token 超限，文本被截断。		 1. 修改并优化发送给 GPT 的提示词。
2. 确保会议环境安静，发言人清晰。Google Meet 的转录质量直接影响结果。
3. 确认使用的是 gpt-3.5-turbo-16k 模型，并检查输入文本长度。
邮件发送到垃圾箱 1. Mailgun 发信域名未正确配置 SPF/DKIM/DMARC 记录。
2. 邮件内容被识别为垃圾邮件。		 1. 在 Mailgun 控制台完成发信域名的验证，并按要求在 DNS 添加记录。
2. 优化邮件模板，避免使用过于营销化的词汇，确保发件人地址可信。

6.3 日志分析与调试技巧

CloudWatch Logs 是你的最佳朋友。为两个 Lambda 函数（API 和 Worker）开启详细的日志输出。

  • 在代码中增加结构化日志 ：不要只打印 “Processing started” ，要打印关键变量，如接收到的文件ID、调用的模型、邮件发送状态等。使用 JSON 格式的日志便于后续查询。 
    # 示例：在Python Lambda中
import json
import logging
logger = logging.getLogger()
logger.setLevel(logging.INFO)

def handler(event, context):
    file_id = event.get('id')
    logger.info(json.dumps({
        "event": "process_started",
        "file_id": file_id,
        "timestamp": context.get_aws_request_id()
    }))
    # ... 处理逻辑
  • 使用 CloudWatch Logs Insights ：这是一个强大的查询工具。你可以编写查询语句来快速过滤错误、统计处理时长、追踪特定文件ID的处理流程。 
    # 查询 Worker Lambda 中所有 ERROR 级别的日志
filter @message like /ERROR/
| fields @timestamp, @message
| sort @timestamp desc
| limit 20
  • 模拟生产事件进行测试 ：在 AWS 控制台，你可以直接配置一个测试事件来触发 Lambda，模拟 SQS 消息或 API Gateway 事件，这比本地测试更接近真实环境。

部署和运行这样一个自动化系统，最大的成就感来自于看到它稳定运行，并真正为团队节省时间。从最初的权限配置踩坑，到后来优化提示词让总结更精准，整个过程就像在打磨一件工具。我建议你在自己的小团队里先试用起来，收集反馈，再逐步推广。毕竟，最好的工具永远是那个能切实解决痛点的工具。

Logo
亚马逊云科技技术品牌专区

更多推荐

open-code-review Codex 插件教程：对话式调用评审技能指南

本文是一份面向新手的 **open-code-review Codex 插件教程**，教你在 Codex 中通过对话式方式调用 open-code-review 的 AI 代码评审技能。open-code-review 是阿里巴巴开源的 AI 代码评审工具，采用"确定性流水线 + LLM Agent"混合架构，内置多语言评审规则（NPE、线程安全、XSS、SQL 注入等），可在 Codex 里用一

avatar 亚马逊云科技技术品牌专区

OBS Studio 完整指南：免费开源录屏与直播软件从零上手

想做一场像模像样的直播，或者把屏幕内容录成教程视频，但一想到商用软件的订阅费就有些犹豫？其实你不需要花一分钱。OBS Studio 是一款免费开源的直播与录屏软件，支持 Windows、macOS 和 Linux，采集、混音、编码、推流、录制，一条流水线全包了。## 先搞清楚 OBS Studio 是什么OBS Studio 是一个"场景化"的采集合成工具：你把摄像头、窗口、浏览器、图片、

avatar 亚马逊云科技技术品牌专区

如何用MediaCrawler爬取小红书抖音数据？7大平台爬虫从安装到实战完整指南

MediaCrawler 是一个支持小红书、抖音、快手、B站、微博、百度贴吧、知乎的开源自媒体数据采集工具。它能按关键词、按帖子、按创作者主页三种方式抓取笔记/视频内容、评论甚至二级评论，并把结果存成 JSON、CSV、Excel 或数据库。适合做市场调研、竞品监控、内容选题的运营人员，以及想要现成爬虫框架而不想从零写 JS 逆向的开发者。## 从一次"手动抄数据"说起想象这个场景：你负责

avatar 亚马逊云科技技术品牌专区