10 月 11 号凌晨，我把一个开源的 AI 语音项目 fork 了下来。10 月 15 号晚上，我用真实信用卡在这个站上付了 $3 ，又发起退款，看着数据库里的权益先加上、再扣掉。
前后 5 天，https://voicewove.com （ AI 文字转语音 + 声音克隆，40+ 语言）正式开始收钱。
这篇聊聊这 5 天都干了什么。先说结论：写代码大概只占了三成工作量——剩下七成，一半在修上游没人踩过的坑，另一半在支付、合规、品牌这些「跟代码无关」的事上。
为什么 fork ，不从零写
先交代决策。AI 语音站的核心链路是：文字输入 → TTS 引擎 → 音频播放/下载，外加注册、配额、支付。这个开源上游（ MIT 协议，3 万多个文件）把最难啃的部分都做好了：Next.js 15 + shadcn/ui 的完整前端、TTS 引擎对接、声音克隆流程。
自己从零写，这些至少两三周。fork 过来，换品牌、接支付、修坑、上线——5 天。MIT 协议允许商用和闭源衍生，法律上干净，唯一的义务是保留原作者版权声明。
这个账很好算：副业项目的时间是最贵的资源，能站在巨人肩膀上就不自己造肩膀。 但 fork 也不是白捡的，接下来是代价。
上游的坑：每一个都「看起来能跑」 上线过程中修的坑，一半来自上游代码。它们有个共同点：本地开发环境里跑得好好的，一上生产就炸。
坑一：NextAuth 配置有两份。lib/auth.ts 一份，app/api/auth/[...nextauth]/route.ts 又一份——后者才是真正生效的。Google 登录在生产环境一直跳回首页，我改了前者排障半天毫无效果。最后发现实际处理请求的是那份我根本没看过的 catch-all 路由。配置文件存在两份定义，你改的那份不一定是生效的那份——这个教训值一小时。
坑二：数据库驱动错配。 上游用 Neon 的 serverless HTTP 驱动连 Postgres ，但初始化方式按本地长连接写死。部署到 Vercel 后数据库连接直接失败。这类问题本地永远复现不出来，因为本地就是「标准环境」。
坑三：默认音色已被 AI 厂商下架。 上游配置里的预置音色 ID ，在 TTS 供应商那边早就不存在了。本地测试听不出来（报错被吞了），真实合成直接 500 。全量替换成一轮真实 API 验证过的音色才解决。
坑四：Stripe 残留。 上游支付走 Stripe ，我换成了 Creem 。但 pricing 页留着一段 Stripe 时代的检查代码：发现 publishable key 没配，就弹「支付系统错误」。于是每次进定价页，右下角必弹一个错误 toast——用户看到的每个「报错」背后，可能都有一段你以为已经删干净的旧世界。
换皮：23 个文件的色相替换 光换 logo 不够，上游的紫粉渐变是最强的视觉指纹。方案选了深青绿（ teal-emerald ），做法是全局色相替换：purple→teal 、pink→cyan 、fuchsia/violet→emerald ，23 个文件一次脚本跑完，渐变关系原样保留。标题字体从 Inter 换成 Sora ，暗色背景也调进了品牌色调。
这里有个差点翻车的细节：macOS 的 BSD grep 不支持 | 交替语法，grep -rl "a|b" 会静默返回空。我的替换脚本第一次跑完，验证也「通过」了——因为验证用的还是同样的错误语法。直到提交时发现只有 2 个文件被改过才察觉。最后用 Python 重写替换逻辑，逐文件计数确认。
支付：Stripe 换 Creem ，一半时间花在「无关」的事上
个人开发者做海外收款，我选了 Creem （ Merchant of Record 模式）——它作为名义卖家替你处理全球税务合规，代价是每单抽成。换来的是我不用碰任何税务问题。集成本身一天搞定：8 个产品、checkout 跳转、webhook 签名验证、权益自动发放。
真正耗时间的是三件「代码之外」的事：
店铺隔离。 最早的测试产品挂在了我另一个项目的 Creem 账号下，结账页显示「由 vinciai 提供」。Creem 一个账号就是一个店铺，要品牌隔离就得新开账号重新过 KYC 。做了。
Google 品牌验证。OAuth 应用要在 Google 那边过品牌审核：站点所有权验证（ Search Console TXT 记录）、隐私政策必须包含 Google API 「 Limited Use 」披露、第三方数据处理明细、AI NCII 禁令声明、应用名与首页完全一致。审核是真人看的——第一版隐私政策被指出「数据收集描述不充分」，改了三处才过。
Creem KYC 也被真人打回过一次。 理由：网站上的用户评价使用了「不可核实的通用身份」。那是上游模板自带的假评价。整改方式很干脆——整个评价区块隐藏，等有真实用户反馈再说。这让我对平台的信任反而上升了：连假评价都抓的审核，通过后的合规基线才可信。
退款回收：一个差点漏掉的白嫖漏洞 上线前我坚持用真实信用卡走一遍「支付 → 退款」全流程（$3 自己付自己退，Creem 手续费自己担）。这一验验出一个洞：
webhook 只处理了发放，没有处理退款。 用户买了克隆额度 → 用掉 → 申请退款 → 额度已经花了但钱退回来——完美白嫖循环。
补上的逻辑：发放时把 Creem 订单号写进支付流水（之前存的是产品 ID ，退款事件来了根本无法回查）；退款事件按订单号回查原始发放记录，事务内扣回权益——克隆包扣剩余额度、字符包扣永久配额、订阅退款直接失效。全部验证通过：真实支付 $3 → 额度 +1 → 后台退款 → 额度归零、流水标记 refunded 。我自己的净成本是 $0 （手续费 Creem 承担）。
5 天全景账单 事项 耗时占比 写新代码（支付集成、退款回收、SEO 落地页） ~30% 修上游坑（上面那四个 + 若干小坑） ~35% 合规与审核（ Google 品牌验证 × 3 次提交、Creem KYC × 2 次） ~20% 品牌（换装、店铺隔离、域名） ~15% 成本：域名已有、Creem 按单抽成、TTS 引擎按量付费、Vercel/Neon 免费档。固定成本接近零，全部变动成本跟收入挂钩。
现在的状态 站已上线，支付-退款全链路生产级验证完毕，分析双引擎（ Cloudflare Web Analytics + Clarity ）就位，4 个 SEO 落地页已提交收录。收入：$3 ，已退款（是我自己的测试单）。
30 天目标：100 个注册用户，第一笔陌生人的真实付款。成了继续写，败了也写。
Select Language