如何用AI Vibe Coding自部署TTS在Vercel上实现部署？

用 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（或直接返回音频流） 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 前端加速，快速做出“像产品”的效果。