用 AI Vibe Coding - word-cards 自部署 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 前端加速，快速做出“像产品”的效果。
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！ 这个好，看起来很实用 鼓励转贴优秀软件安全工具和文档！ 新版吗？好像是停更了吧。 分享、互助 让互联网精神温暖你我 yyds。多谢分享 喜欢鼓捣这些软件，现在用得少，谢谢分享！ 感谢发布原创作品，程序园因你更精彩 很好很强大我过来先占个楼 待编辑 东西不错很实用谢谢分享 东西不错很实用谢谢分享 yyds。多谢分享 用心讨论，共获提升！ 谢谢分享，辛苦了 谢谢分享，辛苦了 喜欢鼓捣这些软件，现在用得少，谢谢分享！ 谢谢楼主提供！ 新版吗？好像是停更了吧。 感谢分享 谢谢分享，试用一下
页:
[1]
2