用 AI "Vibe Coding" 把 word-cards 做到可上线：自部署 TTS + Vercel 部署实践
这篇文章以我在
word-cards项目中的真实开发节奏为主线：先把"体验"做出来，再把"工程化"补齐。重点讲三件事：
- 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 核心路径：从卡片到声音
- 前端展示
content.json的word/phrase - 用户点击"播放"
- 前端请求：
/api/tts?text=...（或直接请求你的 TTS 服务） - 后端逻辑：
- 计算文本 hash（例如
sha1(text + voice + speed)） - 查缓存（对象存储/本地磁盘/Redis）
- 未命中则调用 TTS 引擎生成音频
- 存储并返回音频 URL（或直接返回音频流）
- 计算文本 hash（例如
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 本地开发常用命令（示意）：
bash
# 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 环境变量与跨域
你通常需要这些变量（示意）：
txt
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 前端加速，快速做出"像产品"的效果。