1. 项目概述:AI-ViewNote 的诞生背景与核心价值
作为一名长期浸泡在技术学习中的开发者,我发现自己每年要消耗数百小时的网课和会议视频。最让我头疼的不是内容理解,而是如何高效整理这些视频中的知识精华。传统的手动暂停-截图-记录方式,不仅效率低下,还会严重打断学习心流。市面上的语音转文字工具要么价格昂贵,要么输出结果像未经整理的"文字乱麻",完全不符合技术从业者的笔记需求。
这就是AI-ViewNote诞生的契机——一个用Go+React构建的开源桌面应用,它能将任意视频/会议录音自动转化为结构化笔记。与SaaS类工具最大的不同在于:它完全运行在本地,支持自定义接入各类ASR和LLM API,你的数据永远不会离开本地机器(除非你主动上传到云端API)。这种设计特别适合处理企业内部会议录音或付费课程内容等敏感场景。
技术提示:ASR(Automatic Speech Recognition)指自动语音识别技术,LLM(Large Language Model)即大语言模型。AI-ViewNote的创新点在于将两者串联成完整工作流。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心架构与技术栈解析
2.1 为什么选择Wails v3 + Go?
在桌面端开发领域,Electron一直是主流选择,但它的内存占用和打包体积对资源敏感型应用很不友好。经过技术选型评估,我们最终锁定Wails框架,原因有三:
-
性能优势:相比Electron的Chromium内核,Wails v3使用系统原生Webview,内存占用减少60%以上。实测AI-ViewNote空载内存仅85MB,而功能相似的Electron应用普遍在200MB+
-
开发效率:Go的后端处理能力+React的前端生态,完美匹配音视频处理场景。例如用Go调用FFmpeg处理4小时视频仅需:
go复制cmd := exec.Command("ffmpeg", "-i", inputPath, "-vn", "-acodec", "libmp3lame", outputPath) if err := cmd.Run(); err != nil { log.Fatal("FFmpeg error:", err) } -
跨平台支持:Wails编译出的单一二进制文件可直出Windows/macOS/Linux版本,省去Electron复杂的打包配置
2.2 前端技术栈选型考量
前端采用React+TypeScript+Vite+TailwindCSS组合,主要基于以下实践考量:
- 类型安全:视频处理涉及复杂的状态流转(如转写进度、AI处理阶段),TypeScript能有效预防运行时类型错误
- 热更新效率:Vite的HMR速度比Webpack快3-5倍,这对需要频繁调整UI的笔记排版功能至关重要
- 样式隔离:Tailwind的Utility-First特性避免了传统CSS在复杂笔记模板中的样式污染问题
3. 核心工作流实现细节
3.1 本地音视频处理模块
底层依赖FFmpeg进行媒体处理,关键实现包括:
-
格式兼容性处理:
- 自动检测输入视频编码(H.264/HEVC/VP9)
- 统一转码为AAC音频(兼容所有主流ASR API)
- 采样率强制降为16kHz(平衡文件大小与识别精度)
-
分段处理优化:
go复制// 将长视频按10分钟分段处理,避免单次ASR请求超时 segments := math.Ceil(duration / 600) for i := 0; i < segments; i++ { start := i * 600 end := start + 600 cmd := exec.Command("ffmpeg", "-ss", start, "-to", end, ...) // 并发处理各分段 }
3.2 语音识别(ASR)接入层
设计上采用插件化架构,支持快速接入不同厂商API。以火山引擎为例的配置示例:
json复制{
"asr_provider": "volcengine",
"access_key": "YOUR_KEY",
"secret_key": "YOUR_SECRET",
"language": "zh-CN",
"profanity_filter": true
}
性能对比实测数据(中文普通话):
| 服务商 | 准确率 | 价格(元/小时) | 延迟 |
|---|---|---|---|
| 火山引擎 | 96.2% | 0.45 | 1.2x |
| 讯飞听见 | 97.1% | 0.68 | 1.0x |
| Google Cloud | 95.7% | 1.20 | 1.5x |
3.3 LLM智能排版引擎
这是项目的灵魂所在,核心创新点是预设场景化Prompt模板。例如技术笔记生成的Prompt结构:
markdown复制你是一个资深技术讲师,请将以下转录文本整理为Markdown格式的技术笔记:
1. 提取核心术语,用**加粗**显示
2. 将操作步骤转换为有序列表
3. 代码示例用```包裹
4. 每章节添加二级标题
5. 移除"嗯"、"啊"等语气词
转录内容:{{content}}
实测不同模型效果对比(GPT-4 vs Claude 3 vs 国产模型):
| 模型 | 结构合理性 | 术语准确性 | 排版美观度 |
|---|---|---|---|
| GPT-4 | ★★★★★ | ★★★★★ | ★★★★☆ |
| Claude 3 | ★★★★☆ | ★★★★☆ | ★★★★★ |
| 通义千问 | ★★★☆☆ | ★★★☆☆ | ★★★☆☆ |
4. 开发中的典型问题与解决方案
4.1 跨进程通信(IPC)优化
Wails v3虽然改进了IPC机制,但在传输长文本时仍需注意:
-
分块传输:将ASR结果按500KB分块,通过事件流推送
go复制// Go端代码示例 for _, chunk := range splitText(content, 500*1024) { runtime.EventsEmit(ctx, "transcript_chunk", chunk) } -
前端节流处理:
typescript复制let buffer = ""; window.runtime.EventsOn("transcript_chunk", (chunk) => { buffer += chunk; // 防抖渲染 debounceRender(buffer); });
4.2 FFmpeg进程管理
在长时间视频处理时发现两个关键问题:
-
僵尸进程:Go的exec.Command需要显式释放资源
go复制cmd := exec.Command(...) // 必须添加以下代码 defer func() { _ = cmd.Process.Kill() _ = cmd.Wait() }() -
进度反馈:通过解析FFmpeg的stderr获取实时进度
go复制cmd.Stderr = &stderrBuf go func() { scanner := bufio.NewScanner(&stderrBuf) for scanner.Scan() { if strings.Contains(line, "time=") { // 提取时间码并计算百分比 emitProgress(...) } } }()
5. 使用场景与个性化配置建议
5.1 技术学习场景优化
对于编程类视频,推荐配置组合:
- ASR:讯飞听见(技术术语识别强)
- LLM:GPT-4(代码理解能力最佳)
- Prompt:启用"技术笔记+代码高亮"模板
- 输出:Markdown+PNG截图(保留演示代码)
5.2 会议纪要场景方案
企业会议录音处理建议:
- 提前录入参会人员姓名列表(提升ASR人名识别率)
- 使用"议题-结论"分段模板
- 开启说话人分离功能(需ASR服务支持)
- 导出为Word格式便于批注
6. 性能优化实测数据
在16GB M1 MacBook Pro上的基准测试:
| 视频时长 | 处理阶段 | 耗时 | 内存峰值 |
|---|---|---|---|
| 30分钟 | 音频提取 | 28s | 120MB |
| ASR转写 | 1m42s | 180MB | |
| LLM处理 | 2m15s | 350MB | |
| 2小时 | 音频提取 | 1m56s | 130MB |
| ASR转写 | 6m33s | 210MB | |
| LLM处理 | 8m12s | 410MB |
关键发现:LLM处理时间与token数量呈指数关系,建议超过1小时的视频先做ASR分段再并行处理。
