零基础手搓本地会议助手：完整实战教程

你是否在冗长的会议中感到思维难以集中？一边努力跟上发言节奏，一边匆忙记录要点，会议结束后却发现关键细节早已模糊。

虽然市场上有多种会议录音转文字工具，但它们普遍存在一些痛点：免费额度有限，长音频处理缓慢，最麻烦的是，获得逐字稿后仍需手动整理重点和待办事项。

这个周末，一个想法诞生了：何不尝试用 Vibe Coding 的方式，在本地电脑上亲手搭建一个专属的会议助手呢？

本地会议助手的效果与价值

以一段多人对话的播客录音为例进行测试。这个助手不仅快速生成了逐字稿，还利用 AI 分析了会议要点，分别提炼出四位发言人的核心观点与后续建议，整个过程耗时不到一分钟。

无论是用于复盘会议内容，还是分析讲座、长视频，其效果都令人满意。整个开发过程可以清晰地拆解为四个步骤：

• 梳理核心需求
• 选择合适的 Vibe Coding 工具
• 将想法转化为提示词，交由 AI 生成代码
• 引导 AI 修复问题，逐步完善功能

接下来，本文将完整分享该应用的搭建思路、工具配置以及关键提示词。即使你毫无编程基础，也能依照此流程，开发出属于自己的本地应用，从而摆脱对昂贵订阅制软件的依赖。

零基础开发本地会议助手

首先，需要明确这个会议助手应具备的核心能力：

• 支持直接上传会议录音，通过 ASR（自动语音识别）模型转换为文本，并尽可能区分不同发言人。
• 获取文稿后，利用大语言模型（LLM）分析内容，整理出核心信息。

工具选择：成功的关键

在 Vibe Coding 中，选对工具至关重要。本次项目选用 Claude Code 搭配阶跃星辰的 Step Plan。

Claude Code 负责具体的代码编写、错误修复和接口调试；Step Plan 则提供所需的模型能力。Step Plan 的优势在于模型能力全面，既包含适合内容分析的 step-3.5-flash 系列模型，也拥有专攻语音识别的 stepaudio-2.5-asr 模型，完美覆盖开发需求。

Step Plan 按 Prompt 调用次数计费，提供了非常友好的额度：5小时限额100次，每周400次，性价比很高。

实际花费如何？经过半天的密集调试完成整个应用开发后，连每周额度的四分之一都未用完。

经过多段语音测试，一段约40分钟的音频，API消耗仅需0.135元左右，后续使用成本极低。

Vibe Coding 实战过程

工具准备就绪后，下一步是将清晰的需求转化为提示词，交给 Claude Code 开始生成代码。

提示词示例：
我要开发一个本地运行的会议录音转文本和会议分析 MVP 应用，请你直接帮我从零搭建项目并写代码。
这个应用安装或运行在用户本地电脑上，用户可以在本地打开使用。音频文件、会议记录、转写结果、分析结果都优先保存在本机。语音识别和会议分析能力通过外部 API 调用完成。
应用目标是：用户上传一段会议录音，系统调用 ASR API 把录音转成文字，并尽量区分不同发言人。转写完成后，系统再调用 LLM API，对会议内容进行总结和分析，生成会议主题、核心结论、待办事项、风险点、争议点、每位发言人的主要观点和下一步建议。
技术栈使用 Next.js、TypeScript、Tailwind CSS。第一版先做成本地 Web App，运行在 localhost。数据存储使用 SQLite。音频文件保存在本地 uploads 目录。后续可以再封装成 Electron 或 Tauri 桌面应用。
请实现这些核心功能：用户进入首页后可以看到历史会议列表，可以创建新会议并上传音频文件。上传文件支持 mp3、wa v、m4a、mp4。上传后后端保存音频文件到本地 uploads 目录，并创建一条会议记录，状态显示为处理中。
后端需要封装 ASR 调用模块，文件名可以叫 lib/asr.ts。ASR API 的供应商、API Key、Base URL、模型名都从 .env.local 读取，方便后续切换不同 ASR 服务。环境变量包括 ASR_PROVIDER、ASR_API_KEY、ASR_BASE_URL、ASR_MODEL。ASR 返回结果要统一转换成项目内部格式，每一段包含 speaker、startTime、endTime、text。如果 API 暂时无法返回 speaker，也要保留转写文本，并默认标记为 Speaker 1。
后端还需要封装 LLM 调用模块，文件名可以叫 lib/llm.ts。LLM API 的供应商、API Key、Base URL、模型名都从 .env.local 读取，方便后续切换不同大模型。环境变量包括 LLM_PROVIDER、LLM_API_KEY、LLM_BASE_URL、LLM_MODEL。LLM 接收完整 transcript 后，需要输出稳定 JSON，包含 meetingTitle、summary、keyDecisions、actionItems、risks、disagreements、speakerInsights、nextSteps。actionItems 里需要包含任务内容、负责人、截止时间、优先级。speakerInsights 需要按发言人总结他的主要观点、关注点和态度。
前端需要三个主要页面：首页会议列表、上传会议页面、会议详情页面。会议详情页要分成转写全文和智能分析两个区域。转写全文按时间顺序展示，显示发言人、时间戳和文本内容。发言人名称要支持手动编辑，比如把 Speaker 1 改成张三，把 Speaker 2 改成李四。智能分析区域展示会议总结、核心结论、待办事项、风险点、争议点、发言人观点和下一步建议。
请注意本地应用体验。上传后要显示处理中状态，ASR 失败要显示明确错误，LLM 分析失败也要保留已经完成的转写结果。不要因为分析失败导致整条会议记录丢失。页面风格要简洁清爽，适合工作工具，重点信息一眼能看懂。
请生成完整项目结构，包括 package.json、SQLite 初始化逻辑、环境变量示例文件、API 路由、ASR 封装、LLM 封装、本地文件保存模块、数据库读写模块、类型定义、README 启动说明。
直接创建一个能本地运行的完整 MVP 项目。完成后请检查 TypeScript 类型错误、路由错误、环境变量读取错误、文件上传逻辑和 SQLite 存储逻辑。最后告诉我如何安装依赖、如何配置 .env.local、如何本地启动。

对于不熟悉代码的用户，后续操作非常简单：在终端中，基本只需一路敲回车或选择“Yes”，让 Claude Code 自动创建文件和编写逻辑。

不到十分钟，一个极简风格的应用雏形即可运行，界面清爽直观。

然而，首次上传录音测试时遇到了报错。

遇到报错无需慌张。只需将前端页面显示的红色报错信息复制下来，发送给 Claude Code。

怎么创建会议会失败呢。

Claude Code 会自动排查并修复问题。

再次尝试，会议创建成功，但处理音频时再次卡住。同时发现一个新问题：每次上传测试的失败记录都会堆积在首页，显示为大量“运行中”的会议任务。

于是，临时向 Claude Code 提出了一个新需求：

添加删除会议的功能。

五分钟后，会议详情页的右上角便出现了删除按钮。

清理完测试数据后，继续解决核心卡点。这次录音转写文本成功了，但智能分析却提示：“转写成功，但分析失败: Error: LLM 返回内容为空。”

起初怀疑是某个接口出错，但排查后发现，问题很可能源于音频过长。转写和分析耗时太久，单个请求容易超时。

于是让 Claude Code 查询对导入音频文件的时长、大小及转写字数是否有限制。果然，症结在于 API 请求时长。

Claude Code 的回复显示，单次处理的音频最好控制在10-30分钟，对应转写文本在5000-10000字符。若超过此范围，则需提前进行切片处理。

既然不是模型能力问题，便继续优化。考虑到日常会议常超过30分钟，若每次都需要手动预处理将非常麻烦。

把超过10分钟的长音频处理改成异步任务 + 切片处理。上传接口只返回 jobId，不要让前端一直等请求完成。后端按 jobId 异步切片、转写、总结、合并结果。前端轮询 jobId 状态，展示上传、切片中、转写中、总结中、完成、失败。保留 maxDuration 配置，但不要依赖单个 API 请求长时间运行。

这次改动耗时稍长，但操作依旧简单：一路选择“Yes”。

优化完成后，直接上传了一段78分钟的录音素材。这一次，会议助手一气呵成，顺利完成了转写和智能分析，结果清晰明了。

此外，它也非常适合用于处理和分析各类音频内容，如视频访谈、播客等，用途广泛。

经验分享与总结

回顾整个流程：从上传音频、调用 ASR 生成逐字稿，到再调用大模型进行会议总结、提炼待办事项、分析发言人观点——这套流程在过去至少是一个完整 SaaS 工具的核心功能。但现在，借助 Claude Code 和 Step Plan，普通用户也能在本地电脑上快速搭建属于自己的自动化工作流。

更重要的是，这不仅仅是一个可运行的 Demo。你可以根据自己的使用习惯，随时添加新功能，自由度极高。

Step Plan 的真正价值在于显著降低了 Vibe Coding 的试错成本。

开发这类本地应用，最耗费心力的是中间的反复调试：接口报错需要修改，ASR 返回格式需要适配，LLM 分析失败需要排查，长音频还需要进一步优化。如果全部按调用次数实时计费，用户很容易一边调试一边心疼成本，最终不敢大胆尝试。

Step Plan 这种为 Coding 场景设计的月卡模式，使得模型调用成本变得可预期。这让开发者可以放心地让 Claude Code 多跑几轮、多修复几次 Bug、多尝试几个方案。

对大多数人而言，消除了成本焦虑，敢于尝试和持续使用，才是迈出第一步的关键。