不知道大家有沒有這樣的感覺，開會時間一長，腦子就容易不受控制的放空了。
一邊想努力跟上發言人的思路，一邊匆匆記筆記，會上的我頻頻點頭，會後一回想細節全忘了…
雖說現在也有不少會議錄音轉文本工具，要麼免費時長比較有限，要麼長錄音處理慢，最麻煩的是拿到逐字稿之後，我還要花時間自己整理會議重點、提煉待辦事項。
這週末，我乾脆自己 Vibe Coding 了一個本地運行的會議助手。
這是我下載的一段多人對談的博客錄音，會議助手不僅幫我梳理出逐字稿，還用 AI 分析出了會議要點，分別提煉出了 4 位發言人的觀點以及下一步的建議，全程不到一分鐘！
我自己用來梳理會議內容，聽講座、博客、分析長視頻，效果還是挺滿意的，整個開發過程也非常簡單，大概可以分爲 4 步：
- 梳理需求
- 選擇 Vibe Coding 工具
- 把想法轉成提示詞，交給 AI 寫代碼
- 讓 AI 修 bug，完善功能
這篇文章，我會把整個應用的搭建思路、工具配置，給 AI 的 prompt，毫無保留地分享給大家。如果你也想徹底告別那些昂貴的訂閱制軟件，哪怕完全沒寫過代碼，也可以按照這個流程自己開發應用。
01. 0 基礎開發本地會議助手
我對會議助手的能力需求是這樣的：
- 我直接上傳會議錄音，ASR 模型會將語音轉爲文本，並且要區分發言人。
- 拿到文稿後，用 LLM 大模型分析重點，整理核心內容。
選擇工具
Vibe Coding 開發應用，選對工具就成功了 80%。我用的是 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 次數計，5 小時限額 100 次 prompt，每週 400 次，性價比非常不錯的~
看看整體的花費，我花了半天時間瘋狂調試，把整個應用開發完，連每週額度的 25% 都沒用到。
我測試了幾段語音，40 分鐘左右的音頻，API 消耗才 0.135 元，相當於後續的使用成本幾乎爲 0~
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_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 分鐘的錄音素材，會議助手一次就搞定了轉寫和分析，結果非常清晰。
而且我發現它不僅適合做會議記錄，還能用來了解和學習各種音頻內容，比如視頻訪談、播客等等。
02. 一些分享
從上傳音頻、調用 ASR、生成逐字稿，到再調用大模型做會議總結、提煉待辦、分析發言人觀點，放在以前，這至少是一個完整 SaaS 工具的核心功能。但現在，藉助 Claude Code 和 Step Plan，一個普通用戶在本地電腦上也能很快搭出自己的工作流。
更關鍵的是，它不是隻能跑一個 Demo。我可以根據自己的使用習慣繼續加功能，自由度無限高。
Step Plan 真正有價值的地方，在於降低了 Vibe Coding 的試錯成本。
做這種本地會議助手，最費的其實是中間反覆調試。接口報錯要改，ASR 返回格式要適配，LLM 分析失敗要排查，長音頻還要繼續優化。如果全部按普通 API 計費，用戶很容易一邊調試一邊心疼成本，最後就不敢多試。
Step Plan 就是專門爲 Coding 設計的月卡，讓模型調用成本可預期，讓我可以放心讓 Claude Code 多跑幾輪、多修幾次、多試幾個方案。
對普通人來說，沒了成本焦慮，敢試、敢用纔是最關鍵的。
原文鏈接：Vibe Coding 實戰，我用半天時間做了個會議助手
