抑滓冉疤0. 项目一句话介绍：word-cards 是什么？
word-cards 本质是一个"单词卡片"应用：给儿童/学习者展示单词、短句（phrase），并配合发音（TTS）提升记忆效率。
项目数据有非常直观的结构（例如 content.json）：
Key：卡片 id（如 dog、lion_face）
Value：word + phrase
这种结构非常适合：
快速迭代内容（只改 JSON 就能新增卡片）
用 AI 辅助批量生成/润色 phrase
与 TTS 天然对接：word 或 phrase 都可以直接读出来
- 我怎么用 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）
- 为什么我要"自部署 TTS"？（而不是全放在 Vercel）
2.1 纯浏览器 TTS（Web Speech）的问题
优点：零后端、最快上线。
缺点也很明显：
不同浏览器/系统音色差异巨大
有的环境不可用或权限麻烦
不能稳定复现"同一句话"的音频（不利于缓存、分享、离线）
2.2 让 Vercel 来跑 TTS？通常不划算
即便你用 Serverless Function 调第三方 TTS，仍可能遇到：
冷启动 + 生成耗时 → 体验抖动
生成音频属于"重任务"，并发上来容易被限
成本不可控（按量计费的 TTS + 频繁请求）
2.3 自部署 TTS：把"重活"从前端平台拆出去
我更倾向的落地方式：
Vercel：只负责前端与轻量 API（业务编排）
自建 TTS 服务：负责生成音频（CPU/GPU 都可）
缓存层：存储音频文件，尽量走 CDN
这样做的收益是：
延迟更稳定（尤其是命中缓存时）
费用结构清晰（算力/带宽自己掌控）
可定制音色、采样率、语速、发音规则
- 一个可落地的整体架构（适配 word-cards 这类应用）
3.1 核心路径：从卡片到声音
前端展示 content.json 的 word/phrase
用户点击"播放"
前端请求：/api/tts?text=...（或直接请求你的 TTS 服务）
后端逻辑：
计算文本 hash（例如 sha1(text + voice + speed)）
查缓存（对象存储/本地磁盘/Redis）
未命中则调用 TTS 引擎生成音频
存储并返回音频 URL（或直接返回音频流）
3.2 缓存策略建议（决定体验上限）
强烈建议做"可重复命中"的缓存：同一句 phrase 每次生成应该得到同一份缓存文件
文件命名使用 hash，避免中文路径和特殊字符问题
返回时尽量给可缓存响应头（Cache-Control），让浏览器/CDN 吃满缓存
- 自部署 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 或仅允许你的前端域名访问）
- 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 留在服务端。
- "AI + 内容"在 word-cards 的增益点
像 content.json 这种结构非常适合 AI 参与：
批量生成 phrase（控制难度、长度、词汇覆盖）
统一风格（例如都用现在时、句子长度 6~10 个词）
纠错与去重（避免 phrase 重复、语法问题）
生成多语言版本（后续做中英双语卡片也很自然）
人工底线建议保留两条：
可读性与年龄段适配（AI 容易写得太"成人化"）
TTS 可读性（缩写、数字、特殊符号要规范化）
- 结语：vibe coding 的正确打开方式
vibe coding 最强的地方是把"从 0 到 1 的阻力"打穿
真正上线、可维护、可扩展，还是要回到工程常识：分层、缓存、限流、部署边界