用 AI Vibe Coding - word-cards 自部署 TTS + Vercel 部署实践

用 AI “Vibe Coding” 把 word-cards 做到可上线：自部署 TTS + Vercel 部署实践

这篇文章以我在 word-cards 项目中的真实开发节奏为主线：先把“体验”做出来，再把“工程化”补齐。重点讲三件事：

1. AI vibe coding 的工作流怎么落地；2) 为什么要把 TTS 自己部署；3) 前端如何用 Vercel 稳定上线。

Demo: https://word-cards.blazorserver.com/

GitHub: https://github.com/neozhu/word-cards

---

0. 项目一句话介绍：word-cards 是什么？

word-cards 本质是一个“单词卡片”应用：给儿童/学习者展示单词、短句（phrase），并配合发音（TTS）提升记忆效率。

项目数据有非常直观的结构（例如 content.json）：

• Key：卡片 id（如 dog、lion_face）
• Value：word + phrase

这种结构非常适合：

• 快速迭代内容（只改 JSON 就能新增卡片）
• 用 AI 辅助批量生成/润色 phrase
• 与 TTS 天然对接：word 或 phrase 都可以直接读出来

---

1. 我怎么用 AI “Vibe Coding” 推进开发？

所谓 vibe coding，不是“全交给 AI”，而是把 AI 当成高频的结对搭档：
用最短路径把“可运行的体验”堆出来，再迭代到可维护、可部署。

我常用的节奏是 4 步循环：

1.1 先问“我想要什么感觉？”

不要一上来写架构文档，先定义体验目标，比如：

• 打开页面：立刻看到卡片
• 点击：立刻切下一张
• 点喇叭：立即播报（最好有缓存，不要每次生成）
• 手机上也顺畅（延迟、带宽都要考虑）

1.2 让 AI 给出“最小可行路径”（MVP）

典型产物是：

• 页面组件怎么组织
• 数据怎么读（content.json）
• TTS 是走浏览器 Web Speech 还是后端生成音频

这一步的关键是：先能跑。哪怕方案不完美，但能验证“用户体验”是不是对的。

1.3 我负责约束：边界、成本、风险

AI 很容易“建议上全家桶”。我会明确约束：

• Vercel Serverless 不适合重推理/长时任务
• TTS 音频要缓存，否则成本和延迟爆炸
• 接口必须加限流/鉴权（至少防刷）

1.4 最后再让 AI 帮我补工程化

当体验跑通后，再补：

• 目录结构整理
• 环境变量与部署文档
• API 错误处理
• 缓存策略（本地/对象存储/CDN）

---

2. 为什么我要“自部署 TTS”？（而不是全放在 Vercel）

2.1 纯浏览器 TTS（Web Speech）的问题

优点：零后端、最快上线。
缺点也很明显：

• 不同浏览器/系统音色差异巨大
• 有的环境不可用或权限麻烦
• 不能稳定复现“同一句话”的音频（不利于缓存、分享、离线）

2.2 让 Vercel 来跑 TTS？通常不划算

即便你用 Serverless Function 调第三方 TTS，仍可能遇到：

• 冷启动 + 生成耗时 → 体验抖动
• 生成音频属于“重任务”，并发上来容易被限
• 成本不可控（按量计费的 TTS + 频繁请求）

2.3 自部署 TTS：把“重活”从前端平台拆出去

我更倾向的落地方式：

• Vercel：只负责前端与轻量 API（业务编排）
• 自建 TTS 服务：负责生成音频（CPU/GPU 都可）
• 缓存层：存储音频文件，尽量走 CDN

这样做的收益是：

• 延迟更稳定（尤其是命中缓存时）
• 费用结构清晰（算力/带宽自己掌控）
• 可定制音色、采样率、语速、发音规则

---

3. 一个可落地的整体架构（适配 word-cards 这类应用）

3.1 核心路径：从卡片到声音

1. 前端展示 content.json 的 word/phrase
2. 用户点击“播放”
3. 前端请求：/api/tts?text=...（或直接请求你的 TTS 服务）
4. 后端逻辑：
   • 计算文本 hash（例如 sha1(text + voice + speed)）
   • 查缓存（对象存储/本地磁盘/Redis）
   • 未命中则调用 TTS 引擎生成音频
   • 存储并返回音频 URL（或直接返回音频流）

3.2 缓存策略建议（决定体验上限）

• 强烈建议做“可重复命中”的缓存：同一句 phrase 每次生成应该得到同一份缓存文件
• 文件命名使用 hash，避免中文路径和特殊字符问题
• 返回时尽量给可缓存响应头（Cache-Control），让浏览器/CDN 吃满缓存

---

4. 自部署 TTS：我会怎么做（Docker + 独立服务）

这里不绑定某一种引擎，你可以选：

• Piper：轻量、CPU 友好、部署简单
• Coqui TTS：可玩性高，但资源占用更大
• 系统/云厂商 TTS：省维护，但成本与依赖更强

一个实用的“工程形态”是：

• 用 Docker 跑一个 HTTP 服务（/synthesize）
• 输入：text, voice, speed, format
• 输出：音频文件或音频流（wav/mp3）

Windows 本地开发常用命令（示意）：

# 1) 本地启动前端（示意）
npm run dev

# 2) 启动自部署 TTS（示意，按你的实现调整）
docker compose up -d

生产部署建议：

• 把 TTS 放到 VPS（Linux）或家用小主机（注意上行带宽）
• 用 Nginx/Caddy 做反代 + HTTPS
• 给 TTS 接口做最小保护（token 或仅允许你的前端域名访问）

---

5. Vercel 部署：我踩过的“现实问题”

5.1 Vercel 擅长什么？

• 静态资源/CDN 分发
• Next.js 前端与轻量 API
• 快速预览环境（PR Preview）

5.2 Vercel 不擅长什么？

• 长时间运行任务（TTS/转码/大文件处理）
• 高 CPU 推理（成本和限制都不友好）
• 需要本地磁盘持久化的缓存（Serverless 天生不稳定）

所以我的原则是：
Vercel 用来“接住用户与页面”，TTS 用独立服务“把重活做完”。

5.3 环境变量与跨域

你通常需要这些变量（示意）：

TTS_BASE_URL=https://tts.example.com
TTS_TOKEN=********

前端调用方式两种：

• 前端直接请求 TTS（要处理 CORS、token 暴露风险）
• 前端请求 Vercel API，再由 API 转发到 TTS（更安全、可加限流与缓存策略）

一般更建议第二种：把 token 留在服务端。

---

6. “AI + 内容”在 word-cards 的增益点

像 content.json 这种结构非常适合 AI 参与：

• 批量生成 phrase（控制难度、长度、词汇覆盖）
• 统一风格（例如都用现在时、句子长度 6~10 个词）
• 纠错与去重（避免 phrase 重复、语法问题）
• 生成多语言版本（后续做中英双语卡片也很自然）

人工底线建议保留两条：

• 可读性与年龄段适配（AI 容易写得太“成人化”）
• TTS 可读性（缩写、数字、特殊符号要规范化）

---

7. 结语：vibe coding 的正确打开方式

• vibe coding 最强的地方是把“从 0 到 1 的阻力”打穿
• 真正上线、可维护、可扩展，还是要回到工程常识：分层、缓存、限流、部署边界

word-cards 这类项目尤其适合：
内容驱动 + 体验优先 + TTS 拆分部署 + Vercel 前端加速，快速做出“像产品”的效果。