Teardown
Gaiya LabEN

拆解中文

TranscribeAudio：一套后端，多个马甲

从公开的 openapi.json 逆向一个中国团队的出海站群

结论不是独立产品，是站群里的一个流量入口，处在纯免费引流期。

对象
TranscribeAudio
实测项
18
实时数据
持续监控中 →

站群逆向FastAPI阿里云出海

transcribeaudio.ai · 调研 2026-08-21 · 数字后面的 A/B/C/D 是可信度等级,见文末说明

一句话定位

不是一个独立产品,是一个中国团队 AI 工具站群里刚开张不到六周的新入口站。

它和姊妹站 videototranscript.com 共用同一套 FastAPI 后端(各 186 个端点,交集 113,全中文注释),后端里有完整且明显在运行的订阅、积分、退款、逾期催收系统,但这个站的前端一个付费入口都没有。

判断:处在纯免费引流期,变现开关随时可以打开。

一、身份:证据是硬的

1.1 API 文档对外全开,全中文注释

api.transcribeaudio.ai/api/openapi.json 公开可读,186 个端点(A,本地快照可复算):

POST /api/at/audio-to-text/create-transcription    声音转录创建接口
POST /api/at/audio-to-text/manager-role            角色管理层
POST /api/aliyun_translate/create-job              阿里云翻译接口
POST /api/at/youtube-extraction/create-job         YouTube无字幕视频提取创建接口
POST /api/pai/v1/webhook/common                    通用Replicate回调

1.2 错误信息带双语

给 API 发空请求(无副作用的参数校验):

{"code":400301,"result":null,"message":{"en":"Params error","zh":"参数异常"}}

1.3 基础设施在阿里云

响应头含 x-oss-request-id、x-oss-ec,排错链接指向 api.alibabacloud.com,源站是阿里云 OSS,前面挂 Cloudflare。

前端埋点直传阿里云 SLS,配置硬编码在 JS 里:

{host:"us-west-1.log.aliyuncs.com", project:"pai-us", logstore:"web-transcribeaudio"}

project: pai-us 加上 API 里的 /api/pai/v1/webhook/,指向阿里云 PAI 机器学习平台体系。

二、技术栈(A,除注明外均为实测)

层 证据 结论
前端 /_nuxt/*.js、_payload.json Nuxt (Vue) SSG,预渲染静态文件
托管 x-oss-request-id + server: cloudflare 阿里云 OSS + Cloudflare CDN
后端 {"detail":"Method Not Allowed"}、openapi title: FastAPI Python FastAPI,独立 API 子域
部署 /zfhealth/liveness k8s 健康探针
模型 通用Replicate回调、/bridge/newapi/chat Replicate 跑模型 + New API 网关聚合 LLM
翻译 /api/aliyun_translate/* 阿里云机器翻译做多语言
埋点 阿里云 SLS + GA4 + Microsoft Clarity 三套并行
登录 /api/login/login-google、邮箱验证码 Google OAuth + 自建邮箱登录
资产 assets.transcribeaudio.ai 独立资产域

没有用任何海外 PaaS,没有 Vercel、Supabase、Clerk、Stripe。完整的阿里云技术栈加 Cloudflare 做前置,是中国团队出海的标准配置。

这套栈的含义是固定成本比 AdsCreator 那种 Vercel 单体高得多:k8s 集群、OSS 存储、SLS 日志、独立 API 域名,都要有人维护。反过来说,这些成本一旦分摊到 N 个马甲站,单站就变得很便宜——这正是它的打法。

三、站群结构:一套后端,多个域名

首页 JS 里漏出了一个不属于它的域名 assets.videototranscript.com。顺着查(A,两站 openapi 与 sitemap 均已本地存档):

transcribeaudio.ai videototranscript.com
架构 阿里云 OSS + Cloudflare 完全相同
SLS logstore web-transcribeaudio web-videototranscript
SLS project pai-us 同一个
API 前缀 /api/at/(audio transcribe) /api/vt/(video transcript)
GA4 ID G-M22EDVNYL4 G-T7064ZTSF4(分开统计)
openapi 端点 186 186,交集 113
自家业务端点 /at/ 48 /vt/ 86
上传上限 250MB 5GB
sitemap 21 条 21 条

同一套代码库不同部署,各站只暴露自己那条业务线的完整路由,两站还共享同名同 hash 的 JS chunk(DlAUqK2U.js),出自同一个 monorepo。

复核时改掉的一处判断

原报告说 videototranscript 是主力站,理由里包含“站点规模更大”。实测两站 sitemap 都是 21 条,规模一样小。主力的证据只剩三条,但这三条足够:

  • 自家业务端点 86 对 48
  • 上传上限 5GB 对 250MB,差 20 倍
  • 页面构成不同(见下)

21 条 sitemap 的实际构成

两站都是 3 个路径 × 7 种语言(默认 en,加 de / es / fr / pt / jp / kr。语言码是 jp 和 kr,不是 ja/ko)。但 3 个路径完全不同:

三个路径
transcribeaudio 首页、/privacy-policy/、/terms-of-use/
videototranscript 首页、/history/、/youtube-transcript-generator/

transcribeaudio 只有一个真实内容页,另外两个是法务页。 它连一个 SEO 落地页都还没做。videototranscript 那边则已经有 /youtube-transcript-generator/ 这种冲关键词的落地页。这个差别比端点数更能说明谁是主力。

另外 videototranscript 首页链了两次 /blog/,但 sitemap 里没有 blog 的任何条目。要么博客还没内容,要么忘了提交。对一个靠 SEO 吃饭的站群,这是疏漏。

后端业务线远不止转录

按前缀统计 186 个端点(A,实测):

asset            49   文件/文件夹/回收站/收藏,完整资产管理
at               48   音频转录(本站)
text-to-speech   15   语音合成,带音色包管理
vt               13   视频转录(姊妹站主力,那边是 86)
favorite         13
login            10
management        9   内部管理后台
payment           7   支付
youtube-plugins   5   YouTube 插件,可能有浏览器扩展
aliyun_translate  4
share             3
doc-recognition   2   文档识别
article-crawling  1   URL 内容抓取

值得注意的是 videototranscript 的 186 个端点里完全没有 login 和 favorite,一个都没有。两种解释:那边是纯匿名工具不做账号,或者它的文档裁剪更狠。从 transcribeaudio 前端有 AuthModal 组件、videototranscript 没有来看,第一种更可能。

transcribeaudio.ai 只是这个平台的一个入口。平台本体是谁,公开信息里没能锁定。

四、时间线:刚开张不到六周

  • 域名当前注册记录 2026-07-17(videototranscript 是 07-01),注册商 Cloudflare
  • Wayback 现版本首次存档 2026-08-14
  • sitemap lastmod:transcribeaudio 08-14,videototranscript 08-19

两个域名此前都存在过(transcribeaudio.ai 2024 年有快照,videototranscript.com 2021 年就有),是捡的过期老域名,和 adscreator 一样图域名年龄权重。

对比 adscreator 的 534 页,这边 21 页,还在最早期。

五、怎么赚钱:现在不赚,枪已上膛

5.1 前端零变现入口

  • 页面标题:“Free Online Audio to Text Converter – No Sign-Up”
  • 全站无定价、无 credits、无升级按钮,首页 HTML 里 pricing 出现 0 次(A,实测)
  • JS 里搜不到 Stripe / Paddle / Creem / LemonSqueezy

5.2 后端支付系统完整且在运行

POST /api/payment/subscription/pay-url             订阅支付
POST /api/payment/credits-addon/pay-url            积分包加购
POST /api/payment/subscription/unsubscribe         退订
POST /api/payment/subscription/stop-past-due-bill  逾期账单处理
POST /api/management/payment/update-balance        人工调整余额
POST /api/management/payment/subscription/upgrade  升级(1-立即生效 0-次月生效)

余额分四种记账:free_quotas 免费额度、subscription_quotas 订阅额度、permanent_credits 永久积分、subscription_credits 订阅积分。还有退款开关 is_refund、立即取消开关 is_immediately、支付渠道字段 payment_channel。

这套东西不是新写的,是从已在运营的平台继承来的。没有真实付费用户的产品,不会去建逾期催收和人工调余额这两样功能——它们只在有人真的欠费、真的来客服吵架之后才会被写出来。

5.3 成本结构:它能免费养多久(C,我的估算)

原报告没算这笔账,补上。这是判断“免费期还剩多长”最直接的指标。

转录的边际成本随使用量线性增长,不是软件生意:

项 估算 说明
ASR 推理 $0.003–0.006 / 分钟音频 按 2026 年主流 API 价,自托管更低
存储 可忽略 OSS 便宜,且可设过期
翻译 按字符,量小可忽略 阿里云机器翻译

一个 10 分钟音频约 $0.03–0.06。假设日活 1,000 次转录,一天 $30–60,一个月 $900–1,800。这个量级对一个有主业的团队完全撑得住,所以免费期可以拖很久,不构成压力。

但两件事会立刻改变这个结论:一是上传上限 250MB(姊妹站 5GB),长音频拉高单次成本;二是 text-to-speech 那 15 个端点,语音合成的成本比 ASR 高一个量级。如果站群里有站在免费送 TTS,烧钱速度完全不同。

5.4 判断

transcribeaudio.ai 处在纯免费引流期。这也是本监控最重要的观察点:前端一旦出现定价字样,说明免费期结束。 次要观察点是 sitemap 从 3 个路径涨到十几个,那说明它开始认真做 SEO 了。

六、有客户吗、有收入吗

这个站本身几乎肯定没有:

  • 上线不到六周,21 个页面,无付费入口
  • 首页只有 3 条无出处的五星评价,无具名、无 logo 墙(D)
  • 全网零讨论,Reddit、X、评价站均无

但这个问法对它不太成立。它不是一门独立生意,是站群里的一个流量入口。真正的收入在平台本体那边,而平台本体的身份从公开信息无法确认。

能确定的是:那套后端有完整的订阅、积分、退款、逾期催收,这些功能不会为零收入产品去建。

七、两个值得说的问题

7.1 管理后台接口暴露在公网 API 文档里

/api/management/* 与用户 API 挂在同一份公开的 openapi.json 下,包括:

POST /api/management/login/delete-account
POST /api/management/login/get-userinfo-by-email
POST /api/management/login/pag-query-user-info
POST /api/management/payment/update-balance
POST /api/management/payment/subscription/unsubscribe

这些接口大概率有鉴权(本次分析只读取公开文档,未调用任何管理端点),但把管理路由和用户路由放进同一份对外全开的文档,本身就是不必要的暴露面。/redoc 和 /api/docs 也对外开放,等于把整个后端能力清单公之于众。

这条同时说明团队的工程规范偏松,对判断这个对手的执行质量有参考价值。

7.2 产品同质化,靠数量不靠差异

转录赛道已挤满 Transkriptor、TranscribeToText、VideoTranscriber。它的打法不是做出差异,是同一套后端批量开马甲站,用不同关键词域名各抢一份 SEO 流量。单站不需要赢,站群总量覆盖成本即可。

壁垒判定

  • 假壁垒:转录功能本身,串个 ASR API 就有
  • 弱壁垒:老域名年龄、多语言 SEO 覆盖
  • 真壁垒:那套共享后端的工程化程度。49 个 asset 端点、四种余额记账、逾期催收,这些是被真实运营磨出来的,新团队开第一个站的时候不会有
  • 模型厂商顺手做了会怎样:已经做了。ChatGPT 能直接转录音频。这个站群的生存空间靠的是“不用登录、免费、SEO 能搜到”,不是技术

工程量(C,我的估算)

单开一个马甲站:前端 Nuxt 套模板加多语言,1–2 周。这是它的核心优势,复制成本极低。

但从零建这套共享后端:资产管理、四种记账、支付与退款、k8s 部署、多模型网关,至少 3–6 个月加一个小团队。一个人做不了。

八、和 AdsCreator 对照

两种完全不同的出海模型:

AdsCreator TranscribeAudio
团队 美国,有 8 位数代理业务的连续创业者 中国团队,站群化运营
技术 Next.js + Vercel + Stripe Nuxt + 阿里云 OSS + FastAPI + Replicate
固定成本 极低,无自建基础设施 高,但摊到 N 个站就低
边际成本 每条图 $0.03–0.09 每分钟音频 $0.003–0.006
打法 单站做深,534 页 SEO 矩阵 + GEO 多站做广,一套后端开 N 个马甲
差异化 领域 know-how 固化成枚举 几乎没有,靠流量覆盖
变现 上线即收费 先免费养流量,支付随时可开
共同点 都买老域名、都靠 SEO、都不投广告

可复制性: adscreator 那套一个人两三个月能做出七成;这套的单站一周就能仿,但共享后端仿不了,那是三到六个月加一个团队的活。

九、结论

一句话判断: 这是一门规模生意,不是产品生意。单站看毫无价值,整体看是一台把 SEO 流量批量转成订阅的机器。它的风险不在竞争,在两点:一是搜索引擎对站群的判罚,二是通用 AI 助手直接吃掉“我要转录一段音频”这个需求。

如果我来做: 不要学它开站群,那需要先有一套被真实运营磨过的后端。可学的是它的顺序——先把计费、记账、退款建好,前端再决定什么时候打开。也可以学它的多语言 SSG:一套 Nuxt 预渲染出 7 个语言版本,成本几乎为零,而多数独立开发者只做英文。

我可能错在哪:

  • 假设一:免费是策略,不是能力不足。 我的依据是后端有完整支付系统。但也可能这套后端是买来的或外包的模板,团队还没能力接通。验证方法:盯 home.pricing.plans 这个 i18n key,如果几个月后前端仍不渲染,而其他功能在更新,说明是接不上而不是不想接。
  • 假设二:两站同属一个团队。 依据是同一个 SLS project、同 hash 的 JS chunk、同构的 186 端点。这个证据链很硬,但理论上也可能是同一个白标供应商卖给了两家客户。验证方法:看两站的支付主体和服务条款里的公司名。
  • 假设三:平台本体收入可观。 完全是从“建了逾期催收”推的,没有任何直接证据。如果那套后端其实是从开源项目或某个 SaaS 模板改的,这条推理就塌了。验证方法:搜 /api/at/ /api/vt/ 这类前缀加中文注释的特征,看是否存在公开的同源代码库。

附:可信度分级与信息来源

  • A 实测:我直接抓取验证的,本地快照可复算
  • B 核查级:多来源交叉验证
  • C 估算级:我的推算,已标注计算过程
  • D 自述级:站点自述,无口径

实测:transcribeaudio.ai 首页 / sitemap.xml / robots.txt / _nuxt JS bundle;api.transcribeaudio.ai/api/openapi.json(186 端点,公开);videototranscript.com 全套同上,做交叉比对;HTTP 响应头;Wayback 快照记录、whois 注册日期。快照存于 本地快照目录。

没查实的地方:平台本体身份、两站的实际流量、home.pricing.plans 这个 i18n key(在未存档的 _nuxt chunk 里,本次快照没保存到,下次抓取建议一并存下)、ASR 用的具体模型、是否真有浏览器扩展(youtube-plugins 那 5 个端点暗示有,但没找到扩展商店页面)。

说明:本次分析仅做只读抓取与公开文档读取,未调用任何写操作或管理端点。