零基础 Vibe Coding 手搓本地会议助手

为什么我要自己手搓一个本地会议助手

会议一长，注意力就散。你明明努力在跟节奏，手里的笔却只能潦草记下几个关键词；散会之后再回忆，细节早已模糊成一片。更尴尬的是，真正需要落地的待办事项，往往就藏在那几句没记下来的话里。

市面上其实不缺会议录音转写工具，我几乎都试过一轮。问题倒不是它们不能用，而是总有一处不合身：要么免费时长卡得很死，稍微长一点的会就转不完整；要么长录音处理慢得让人失去耐心，一杯咖啡喝完进度条还在爬。最麻烦的是，辛辛苦苦拿到逐字稿之后，我还要自己再花一遍时间去梳理重点、提炼待办——转写只是完成了一半，另一半的活儿一点没少。

于是这个周末，脆自己动手，用 Vibe Coding 的方式撸了一个完全跑在本地的会议助手。

整套方案只依赖本地环境与两个外部 API

折腾完之后，我拿一段多人对谈的播客录音做了测试。结果比我预期的要好：它不仅吐出了一份清晰的逐字稿，还用大模型把会议内容分析了一遍，分别梳理出四位发言人的核心观点和下一步行动建议，整个过程不到一分钟就结束了。

后来我发现，这东西的用处远不止会议记录。听讲座、刷播客、分析长视频，它都能派上用场，效果让我相当满意。而整个开发过程其实异常简单，回头看大致可以拆成四个阶段：

1. 想清楚自己到底要什么
2. 挑一套顺手的 Vibe Coding 工具
3. 把想法写成提示词，驱动 AI 生成代码
4. 带着 AI 一起修 bug，把功能补齐

这篇文章我会把搭建思路、工具配置和当时用的完整提示词毫无保留地分享出来。哪怕你一行代码都没写过，照着这个流程走一遍，也能摆脱昂贵的订阅制软件，做出一个真正属于自己的应用。

先把话说在前面：这不是一篇教你写代码的教程，通篇不会出现需要你理解的技术细节。它更像一份操作记录——我做了什么、说了什么、AI 回了什么、卡在哪里、又是怎么绕过去的。你完全可以照抄我的每一步，甚至连提示词都不用改。

我的需求其实只有两件事

动手之前，我把功能需求想得很清楚，一共就两条，没有第三条。

1. 语音转文字：我上传一段会议录音，ASR 模型把它转成文本，并且尽可能区分出不同的发言人。做不到完美区分没关系，能大致分清谁在说话就行。
2. 内容再分析：拿到转写文本之后，交给大模型做一次深度分析，把核心要点提炼出来，而不是让我再读一遍几千字的逐字稿。

需求定得越窄，AI 生成的代码反而越靠谱。这是我后来最大的体会——如果你一上来就想要一个”全能工作台”，提示词会迅速膨胀，AI 也会在无数细节里迷路。

反过来说，需求定得清楚还有一个隐藏好处：它天然成了验收标准。AI 交付的东西好不好，你不需要懂代码也能判断——录音能不能传、文字出没出来、发言人分没分开、要点提炼得对不对，四条一对照就清楚了。

工具甄选：Claude Code 配阶跃星辰 Step Plan

在 Vibe Coding 这件事上，选对工具基本等于成功了一半。我的组合是 Claude Code + 阶跃星辰 Step Plan。

两者的分工很明确：Claude Code 负责写代码、改错误、调接口；Step Plan 提供背后的模型能力。让我决定用 Step Plan 的原因是它的模型库足够全——既有适合做内容分析的 step-3.5-flash 和 step-3.5-flash-2603，也有专门为语音识别准备的 stepaudio-2.5-asr。一个平台把分析和转写两件事都覆盖了，我不用再去接第二家。

这里有个容易被低估的好处：同一个平台意味着同一套鉴权、同一份账单、同一种错误码风格。调试的时候不用在两个控制台之间来回切换查日志，排查效率其实高了很多。

计费方式也是打动我的一个点。Step Plan 按 Prompt 次数收费，每周 400 次 Prompt 的额度对应一个相当低的费用，性价比很能打。我花了一个下午做密集调试，把整个应用从零搭建完成，期间消耗的 Prompt 次数甚至没到每周额度的 25%。

实际跑起来之后我还算了一笔账：一段大约 40 分钟的音频，API 调用成本只有 0.135 元。这意味着后续日常使用的成本几乎可以忽略不计，跟动辄上百元的月度订阅完全不是一个量级。

顺带说一句，之所以选择本地运行而不是部署到线上，是因为会议内容往往涉及公司内部信息。音频、会议记录、转写结果和分析结果都优先存在本机，只有转写和分析两个动作需要调用外部 API，这个折中对我来说是可以接受的。

把想法写成提示词，让 AI 直接生成代码

工具就位之后，真正决定成败的就是这一步。很多人以为 Vibe Coding 的关键是会写代码，其实恰恰相反，关键是你能不能把需求说得足够具体。下面的提示词我写得相当啰嗦——技术栈、目录结构、环境变量名、返回字段、页面分区，全都点名了。事后看，正是这种啰嗦省掉了后面大量返工。

工具就位，接下来就是把脑子里的东西翻译成提示词，交给 Claude Code。这是我当时敲进去的完整提示词，一字未改地贴在这里，你可以直接拿去用：

提示词：请为我从零开始搭建一个本地运行的会议录音转文本及会议分析 MVP 应用，并直接生成所有代码。此应用需安装或运行在用户本地电脑上，所有数据，包括音频文件、会议记录、转写结果及分析结果，均优先保存在本地。语音识别和会议分析功能将通过调用外部 API 实现。

应用的核心目标是：用户上传一段会议录音后，系统调用 ASR API 将语音转为文字，并尽量区分发言人。转写完成后，再调用 LLM API 对会议内容进行总结分析，生成会议主题、核心结论、待办事项、风险点、争议点、各位发言人的主要观点以及下一步建议。

技术栈采用 Next.js、TypeScript 和 Tailwind CSS。首个版本将构建成本地 Web App，运行在 localhost。数据存储使用 SQLite。音频文件保存在本地的 uploads 目录。后续可考虑封装成 Electron 或 Tauri 桌面应用。

核心功能实现包括：用户访问首页可查看历史会议列表，并能创建新会议及上传音频文件。支持 mp3、wav、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 接收完整 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。我当时只问了一句：

“为什么创建会议会失败呢？”

它自己就去排查并修复了。再试一次，会议创建成功，但音频处理环节又卡住了。更尴尬的是，我发现每次测试上传的录音记录都被保留了下来，首页堆了一排”运行中”的会议任务。

于是我临时提了个新需求：

“添加删除会议的功能。”

不到五分钟，再次点开会议详情，页面右上角就多了一个显眼的删除按钮。这种”想到什么就说什么，几秒钟后功能就长出来”的体验，是传统开发流程里很难有的。

长音频的坑：改成异步任务加分片处理

前面那些小问题都还算顺利，真正的硬骨头在这里。如果你打算处理的会议普遍在半小时以上，这一段建议重点看，因为几乎所有人都会栽在同一个地方。

清掉冗余数据后继续攻主战场。这一次录音转写成功了，但智能分析环节报错：”转写成功，但分析失败: Error: LLM 返回内容为空。”

我一开始以为是接口又抽风，仔细排查才发现，问题很可能出在音频太长——转写加分析耗时过久，单个请求很容易超时。

于是我让 Claude Code 去查关于导入音频时长、文件大小和转写字数的限制要求，卡点果然就落在 API 请求的时长上。它给出的反馈是：单次处理的音频最好控制在 10 到 30 分钟之间，转写文本量对应在 5000 到 10000 字符；超过这个长度，就需要提前做分片处理。

既然不是模型能力的问题，那就继续优化。毕竟日常会议普遍超过 30 分钟，如果每次都要我先手动切分，这个工具就失去意义了。我给它的下一轮指令是这样的：

“将超过 10 分钟的长音频处理改为异步任务结合分片处理。上传接口仅返回 jobId，不再让前端长时间等待请求完成。后端根据 jobId 异步进行分片、转写、总结和结果合并。前端通过轮询 jobId 来展示上传中、分片中、转写中、总结中、完成或失败等状态。保留 maxDuration 配置，但避免过度依赖单个 API 请求的长时间运行。”

这一轮改动比较大，我们依然是一路”Yes”确认下去。

改完之后，我直接上传了一段长达 78 分钟的录音素材，会议助手一次性完成了转写和分析，结果清晰明了。

那一刻的成就感很实在：从想法到可运行的成品，中间没有找人帮忙，没有翻文档，也没有为某个报错熬到深夜。

如果你也想试试，我的建议是别从大项目开始，先找一个小到有点蠢的需求——比如这个会议助手——把它跑通，你会对整个流程建立完全不同的信心。这一步的价值远大于看完十篇教程。

整个项目由 AI 生成与修复，我只负责描述需求和确认改动

这个本地会议助手的使用场景

工具做出来是要用的。跑通之后我把它丢进日常工作里试了一段时间，慢慢摸索出了几个真正高频的用法。

用了一段时间之后，我发现它的适用范围比预想的宽很多，顺手列几个我实际在用或者能想到的：

1. 日常会议记录：最长 78 分钟的录音实测可以一次跑完，转写全文加智能分析直接出，会后不用再补纪要。
2. 讲座与课程复盘：长音频自动分片，不用自己切文件，听完就能拿到结构化的要点。
3. 播客与访谈消化：多人对谈的场景下，发言人观点会被分开梳理，比通读逐字稿高效得多。
4. 长视频内容分析：把音轨抽出来丢进去，同样能得到摘要和行动项。
5. 数据不出本地：音频、会议记录、转写结果和分析结果都优先存在本机，对内容敏感的场景更踏实。

当然，转写和分析两个环节仍会调用外部 API，介意的话需要自行评估。

当然，如果你只是想要一个开箱即用的现成方案，也可以看看怪兽会议、腾讯会议·AI小助手这类成熟产品；需要英文会议场景的话，Otter AI会议和Fireflies-AI会议助手都是常见选择。但自己搭一个的好处在于，需求变了可以随时改，不用等别人排期。

而且自己搭的工具有一个现成产品永远给不了的好处：它完全贴合你的工作流。你想让它输出什么格式、分成几个区块、待办事项要不要带负责人，全都是一句话的事。用久了之后，它甚至会慢慢长成你习惯的样子。

常见问题解答

把当时反复卡住的几个点和结论整理一下，方便你少走弯路。

完全不会写代码，真的能复现吗？

可以。整个过程中我没有手写任何逻辑代码，只做了三件事：描述需求、把报错信息发回去、对 AI 提出的改动点确认。剩下的文件创建、接口调试、类型检查都由 Claude Code 完成。

成本大概是多少？

按我的实测，一段约 40 分钟的音频，API 调用成本是 0.135 元。开发阶段的密集调试花了一个下午，消耗的 Prompt 次数不到每周 400 次额度的 25%。

长音频为什么会失败，怎么解决？

单次请求处理过长的音频容易超时，导致分析返回空内容。建议把超过 10 分钟的音频改成异步任务加分片的模式：上传只返回 jobId，后端异步分片转写再合并，前端轮询状态即可。

官方给出的经验区间是单次 10 到 30 分钟、转写文本 5000 到 10000 字符，我的 78 分钟素材在分片之后顺利通过。

一些心得分享

做完之后回看整个过程，有些体会值得单独拎出来讲。

从音频上传、调用 ASR 生成逐字稿，到大模型总结会议、提炼待办、分析发言人观点——这套功能放在过去，至少是一个完整 SaaS 产品的核心卖点。而现在，借助 Claude Code 和 Step Plan，一个普通用户在自己电脑上花半天时间就搭出来了。

更重要的是，这不是一个演示用的 Demo。我可以根据自己的使用习惯不断往上加功能，度没有上限。想加删除按钮就加删除按钮，想改异步就改异步，没有任何需求要提给谁审批。

想加删除按钮就加删除按钮，想改异步就改异步，没有任何需求要提给谁审批、要排到哪个迭代。这种掌控感是订阅制产品给不了的——你买的不是某个功能，而是随时改造它的权利。

回头看，Step Plan 真正的价值在于把 Vibe Coding 的试错成本压到了极低。做这类应用最耗精力的从来不是”第一次生成”，而是反复调试：接口报错要修，ASR 返回格式要适配，LLM 分析失败要排查，长音频还要重新设计架构。如果每一次调试都按常规 API 计费，人很容易在心疼成本的心态下不敢多试，最后半途而废。

而按 Prompt 次数计费的月度套餐让模型调用成本变得可预测，我才能放心地让 Claude Code 多跑几轮、多修几次、多试几种方案。对普通用户来说，摆脱成本顾虑、敢于尝试，可能才是最关键的那一步。

还有一点容易被忽略：敢于试错并不只是心态问题，它需要计费方式配合。当每一次尝试都有明确且低廉的价格时，人才会真的放手去试；反之，再怎么鼓励”大胆尝试”，用户心里那本账也会把他拉回保守。

我还想补一句关于心态的话。整个过程里我没有一次试图去读懂 AI 写的代码，也没有因为看不懂而停下来。报错了就贴回去，功能缺了就直接说，改动太大就一路确认。这种”不懂也能推进”的感觉，是过去任何一个时代都不曾有过的。

OpenI AI时代点评

把这次实践放到更大的背景里看，它其实回答了一个很实际的问题：普通人到底需不需要为每一个细分需求付费订阅一个 SaaS？

这篇实战最有意思的地方，不在于做出了一个会议助手，而在于它演示了一种新的软件获取方式：当需求足够具体、又不想为通用功能付费时，自己 Vibe 一个可能比找现成工具更划算。40 分钟音频 0.135 元的成本，和动辄上百元的月度订阅之间，差的是整整一个数量级。

另一个值得注意的细节是”报错即反馈”的工作流。过去调试是专业技能，现在变成了把红色错误信息复制粘贴回去。这道门槛的消失，意味着非技术背景的人第一次真正具备了把想法落地成工具的能力。哪怕你对代码一窍不通，也可以试试用Trae智能体这类工具走一遍同样的流程。

当然也要清醒：本地 MVP 和成熟产品在稳定性、协作、多端同步上还有明显差距，敏感数据虽然留在本地，但音频仍需调用外部 API 处理。它更适合作为个人工作流的补充，而不是团队级方案的替代品。