前言：代码是最后一步，不是第一步

在正式开始写这篇技术选型文章之前，我想先分享一个可能和大多数技术文章不太一样的观点：

写代码，是这个项目里最不重要的一步。

在过去的一个多月里，我真正花在写代码上的时间，可能不到总时间的 20%。剩下 80% 的时间，我在做一件事：和 AI 聊天，问问题，反复追问，直到把每一个技术决策背后的“为什么”聊透。

这不是偷懒，是我在 B 站项目中学到的最重要的教训。那次我拿到需求就开始写代码，写到一半才发现技术栈选错了，重构成本巨大。这次我换了一个策略：让 AI 当我的技术顾问，帮我穷举选项、对比优劣、预判坑点。我负责做决策，它负责提供信息。

这篇文章，我不只告诉你“选了啥”，更要告诉你 “怎么选”——这套“问 AI 选技术”的方法，比任何技术栈都值钱。

一、我的选型方法论：先聊透，再动手

1.1 核心原则

我把技术选型拆成五个阶段，每个阶段都和 AI 深度聊透：

阶段	做什么	问 AI 什么
1. 穷举选项	列出所有可能的技术方案	“这个场景有哪些主流方案？”
2. 对比优劣	了解每个方案的优缺点	“A 和 B 对比，各自优缺点是什么？”
3. 追问细节	深挖关键差异点	“为什么 A 性能比 B 好？原理是什么？”
4. 验证适配	确认是否匹配我的约束条件	“我的设备只有 1GB 内存，能跑吗？”
5. 决策锁定	做出选择，记录理由	“综合来看，我应该选哪个？为什么？”

1.2 为什么必须“聊透”

很多人拿到需求，直接 Google 搜“XX 框架 教程”，跟着抄一遍就完了。但这样做，你永远不知道：

• 为什么这个框架比另一个好？

• 它有哪些坑是我现在看不到的？

• 如果我的需求变了，它还能撑住吗？

技术选型的本质，不是选“最好”的，而是选“最合适”的。 而“合适”取决于你的约束条件、未来预期、团队能力。这些只有你自己知道，AI 只是帮你挖掘信息。

1.3 我的实操习惯

每次技术选型，我会开两个窗口：

• 一个窗口问 Coding Agent（比如 Cursor/文心快码），让它帮我穷举方案、对比优劣

• 另一个窗口问 通用大模型（比如 DeepSeek/豆包），让它帮我深挖原理、验证适配

两个 AI 互相对照，信息更全面。

二、整体架构选型：从“追风口”到“做自己”

2.1 问题 1：我要做一个什么层级的系统？

问 AI：

我想做一个语音控制电视的系统，应该做成“云端一体化”还是“云端+边缘”架构？

AI 给我的选项：

方案	说明	优点	缺点
纯云端	手机 → 云端 → 电视	开发快	断网废、隐私差、延迟高
纯本地	手机 → 本地设备 → 电视	隐私好、断网可用	本地设备性能不足
云端+边缘	手机 → 边缘端 → 云端（必要时）	平衡隐私、延迟、成本	架构略复杂

我的追问：

我家机顶盒只有 1GB 内存，能跑“边缘端”吗？需要跑什么？

AI 的回答：

可以。边缘端只做三件事：接收音频、调用 ADB、透传云端指令。Go 服务内存 <20MB，SQLite <50MB，1GB 完全够。

我的决策：选 云端+边缘混合架构。理由是：

• 隐私数据（截图、设备信息）留本地

• 复杂决策（意图理解）走云端

• 断网时本地可执行简单指令（如“开灯”）

选型心法：不要因为“架构复杂”就放弃，先问清楚“复杂度在哪、能否承受”。

三、边缘端语言选型：为什么我弃 Java 转 Go

3.1 问题 2：边缘端用什么语言？

问 AI：

边缘端要跑在 1GB 机顶盒上，负责接收音频、执行 ADB、透传指令。Java、Go、Python 怎么选？

AI 给的对比表：

维度	Java	Go	Python
内存占用（空服务）	~200MB	~10MB	~50MB
启动速度	慢（JVM 预热）	毫秒级	秒级
部署	JAR + 依赖	一个二进制文件	解释器 + 依赖
并发模型	线程（重）	goroutine（轻）	asyncio（中）
生态	Spring 强大	云原生标准	AI 生态强

我的追问：

Go 的并发模型具体怎么轻？能举个例子吗？

AI 解释：

Go 的 goroutine 是用户态协程，初始栈 2KB，可以轻松创建上万个；Java 线程映射到操作系统线程，每个栈 1MB。同样内存，Go 能跑更多并发。

我的决策：选 Go。理由：

• 内存占用低（留给视觉模型更多空间）

• 部署简单（一个二进制文件，机顶盒直接跑）

• 并发模型适合边缘设备（同时处理多路指令）

选型心法：对比不能只看“好不好”，要看“在约束条件下哪个更合适”。 我反复追问内存占用、部署方式，因为这些是 1GB 机顶盒的生死线。

四、数据库选型：SQLite 如何单挑 PostgreSQL

4.1 问题 3：本地记忆用什么数据库？

问 AI：

需要存设备配置、用户偏好、操作记忆，可能还要向量检索。SQLite 还是 PostgreSQL？

AI 给的对比：

维度	SQLite	PostgreSQL
部署	一个 .db 文件	需安装服务、配置用户
内存	0（嵌入进程）	50-100MB 常驻
备份	cp 复制文件	pg_dump 命令
向量检索	sqlite-vec 扩展	pgvector 扩展
并发写	单写（你的场景够用）	多写

我的追问：

sqlite-vec 是什么？和 pgvector 比，功能差多少？

AI 回答：

sqlite-vec 是 sqlite-vss 的官方继任者，2025 年发布，支持 HNSW 索引，功能上不输 pgvector。最重要的是，它是纯 C 实现，零依赖，嵌入到 Go 程序里就行。

我的决策：选 SQLite + sqlite-vec。理由：

• 零配置，备份就是复制文件

• 内存占用 0（在 Go 进程内）

• 向量检索功能完整，满足未来 RAG 需求

选型心法：不要因为“以后可能用到大功能”就选重方案。 SQLite 足够覆盖我 99% 的场景，等真不够了再迁也不迟。

五、音频处理选型：手机 AAC + NAS 转码

5.1 问题 4：音频格式怎么选？

问 AI：

手机录音，要传给豆包 API 做语音识别。豆包要求 WAV（16kHz 单声道），但手机录 AAC 文件小。怎么选？

AI 给的方案：

方案	手机端	文件大小	服务端处理
手机录 WAV	复杂（需 AudioRecord）	3秒 ≈ 96KB	无
手机录 AAC	简单（MediaRecorder）	3秒 ≈ 15KB	FFmpeg 转码 ~50ms

我的追问：

FFmpeg 转码 50ms，加上网络传输，总延迟能接受吗？

AI 回答：

转码 50ms，加上 AAC 上传（15KB）和 WAV 上传（96KB）的时间差，AAC 方案可能还更快。你 B 站项目用过 FFmpeg，稳定性和性能已验证。

我的决策：选 手机录 AAC + NAS FFmpeg 转码。理由：

• 手机端代码简单

• 复用 B 站项目的 FFmpeg 经验

• 延迟可控，用户体验无感知

选型心法：不要为了“省一次转码”而在手机端增加复杂度。 边缘端性能足够，把复杂逻辑留在自己能掌控的地方。

六、写在最后：聊透了，代码只是最后一公里

这一篇，我写了边缘端语言、数据库、音频处理的选型过程。但你可能发现，我花了更多篇幅在“怎么问 AI”上。

因为这才是真正的干货。

技术选型不是“搜一下哪个框架最火”，而是一场深度对话：

1. 先让 AI 穷举选项

2. 追问对比细节

3. 挖原理、验适配

4. 最后再做决策

代码，永远是最后一步。

下一篇文章，我将继续拆解云端 Agent 的技术选型——为什么用 TypeScript 而不是 Python？为什么选 Fastify 不选 Express？LangChain.js 和 Vercel AI SDK 怎么分工？

如果你也在做技术选型，欢迎在评论区分享你的“问 AI 技巧”。我们一起把“聊透”这件事，做得更好。