我AI工具站的复盘:技术易做,商业难跑

为什么要做海外 AI 工具站，主要是2个考虑：

第一，我做了多年技术，前端、后端、任务系统、模型调用、部署这些环节拆开看，没有真正的盲区。做一个基于 AI 的工具站，技术上是可行的。

第二，海外工具站确实存在结构性机会。海外用户付费意愿更高，工具型产品只要解决明确问题，就有机会获得持续收入。

所以当时的逻辑很直接：一边把 AI 能力产品化，一边验证这个站能不能产生收入。

但跑完这一轮，我最大的感受不是"技术有多难"。从技术角度看，大部分问题都有解。真正难的是取舍——个人做海外 AI 工具站，第一阶段的重点不是技术深度，而是用 MVP 跑通真实需求，以最低成本上线，验证支付、获客和商业闭环。

下面我就以 hillboss.com 为样本，复盘这个过程中的关键决策。

先从自己的真实需求开始

我没有从风口关键词切入，而是先看自己有哪些高频需求。

视频去水印下载、视频字幕提取、字幕总结——这些场景我自己经常遇到。需求很具体：用户给一个公开视频链接，系统解析视频、提取字幕，甚至进一步做摘要。

选这个方向有两个好处：第一，我自己是用户，知道输出应该长什么样；第二，避免了工具站最常见的陷阱——做了一个功能，但不清楚用户到底要什么结果。

第一版就从视频工具起步。思路很明确：先把一条用户任务跑通——输入、处理、输出。链路跑通之后，再扩展到图片、语音、视频生成。

如何架构

从第一天起，我就没有把它当单体小网页来做，而是拆成三层。

前端负责页面、上传、交互、结果展示。后端负责账号、积分、任务、支付、数据库，以及各种 provider 的编排。计算服务独立处理真正吃资源的任务——图片去背景、图片修复、视频字幕处理、模型推理。

frontend/web   # Next.js 前端backend/api    # FastAPI 主后端compute/*      # 独立计算服务db/            # 数据库迁移

这里有一个关键判断：主后端不背重活。它的职责是业务编排，而不是把所有模型、依赖、视频图片处理都塞进去。一旦重型任务混在主后端里跑，排错会非常痛苦——接口慢了，你分不清是数据库慢、模型慢、下载慢还是内存被打爆。计算服务独立部署，有自己的虚拟环境、启动脚本、端口和配置，看起来麻烦，但后续的运维和排错清晰很多。

用AI进行开发

这个项目的前端和后端，主要靠 AI 辅助完成。但我不认同"一句话生成一个工具站"这种叙事。

AI 写代码很快，快不等于稳。没有需求边界、技术约束、UI 约束和验证流程，AI 很容易产出一堆看起来完整、实际难以维护的代码。所以我在开发中沉淀了一套 spec 驱动的工程流程：

spec-prd     # 需求沟通，沉淀 prd.mdspec-tec     # 技术约束，沉淀 tec.mdspec-ui      # UI 约束，沉淀 ui.mdspec-dev     # 按 PRD 和约束开发，并做验证spec-test    # 代码测试spec-deploy  # 部署上线

这套流程的核心逻辑是：PRD 锁定目标，技术约束划定边界，UI 约束控制一致性，开发阶段不只写代码还要做真实验证，部署阶段不能只听 AI 说"改好了"——要确认远程服务确实重新加载了。过程中我不断把踩坑经验反向优化 skill，因为 AI 开发最大的价值不是一次性生成代码，而是形成一套稳定、可复用的工程流程。

第一个教训：技术能做，不代表商业能跑

第一阶段，视频去水印、视频下载、字幕相关功能跑通之后，一个现实问题很快暴露出来。

视频去水印下载这类功能，风控门槛很高。网站包含这类能力，接入正规支付系统会非常困难。这不是技术问题，是合规问题，也是支付风控问题。

同时，视频文件对存储和带宽的要求远超预期。你以为是帮用户下载一个视频，实际上要处理视频代理、Range 请求、临时文件、下载速度、带宽成本。有真实流量之后，这些成本会迅速显现。

这就是第一个大坑：我一开始只判断了"能不能做"，但商业化的前提是另外几个问题——能不能上线、能不能接支付、成本能不能扛住、出了问题能不能解释。

后来我做了调整：视频能力保留为内部技术储备，但商业化入口不能押在这类高风险功能上。

第二阶段：转向更合规的图片工具

调整方向后，我转向了图片去水印、Logo 去水印、文字去水印、图片去背景等需求。场景同样明确：用户上传图片，系统返回处理结果。

技术上，开源模型和第三方 API 两条路都可以走。我一开始选了自建——这是技术人很容易踩的坑：明明可以买现成的锤子，偏要自己造一把。

我研究了 IOPaint、rembg，也结合了 OpenCV 的处理经验。自建的好处是可控，单次调用成本看起来低。坏处也很实在：服务器采购、环境部署、模型调参、接口稳定性，每一样都要自己扛。大量时间花在技术上，而不是产品体验上。

这件事适合技术学习，但不一定适合 MVP。MVP 阶段要证明的不是"我能自己搭模型"，而是用户愿不愿意用、愿不愿意付费。

第三方 API：MVP 阶段更明智的选择

后来我开始用第三方 API 做 AI 图片生成、视频生成、语音生成，这一步让我更确定一个判断：MVP 阶段，第三方 API 是更好的选择。

以fal.ai为例，不用处理模型部署、GPU、显存、队列、推理服务稳定性。你只需要把产品链路打通——用户输入什么、后端怎么创建任务、积分怎么扣、结果怎么返回、失败怎么处理。这些才是工具站第一阶段真正要验证的东西。

自建当然有价值，但它更适合在需求、用户、收入都验证通过之后再做。先用第三方 API 跑通链路，再决定哪些能力值得自建，比一上来就钻进模型部署现实得多。MVP 阶段最贵的往往不是 API 调用成本，而是迟迟上不了线。

接入支付和积分：工具站开始像一个生意

接支付这一步，工具站就不再是 demo 了，它开始像一个生意。小生意也要有账：谁买了、买了多少、积分有没有到账、失败怎么查。

支付方案上，主流选择是 Stripe 和 Creem。

Stripe 生态成熟、文档完善，但对中国大陆个人开发者不太友好——注册门槛高，合规审核严，风控触发后处理周期长。

Creem 相对轻量，注册简单，对中国大陆开发者接纳度更高，适合个人 MVP 阶段快速接入。

权衡之后我选了 Creem。但接入后遇到的第一个坎不是技术问题，而是 KYC 认证。Creem 的 KYC 审核并不只是"提交材料等通过"——我的实际经历是第一次提交后被拒了，后来通过邮件和 support@creem.io 反复沟通，解释清楚业务模式和用途，最终才通过审核。对大陆个人开发者来说，这里要有心理准备：不是材料齐全就一定能过，沟通和耐心是绕不开的一步。

第三阶段：真正部署上线

部署阶段，前端、后端和计算服务分开部署，和架构设计保持一致。实际服务栈：

前端：Next.js后端：FastAPIIOPaint：计算服务rembg：计算服务数据库：Supabase PostgreSQL邮箱：Resend支付：CreemCDN：Cloudflare

部署不是项目写完才补的一章，它会反向约束你怎么设计目录、怎么拆服务、怎么写脚本。

个人项目没有运维团队兜底，服务名、端口、启动脚本一开始就要规范，否则后面排错代价很高。

第四阶段：上线了，但没有流量

网站部署成功以后，我很快遇到另一个现实问题：网站是活了，但没有自然流量。

这一步其实很正常。一个海外工具站不是上线就有人来，你要么靠搜索，要么靠内容，要么靠投放。

所以后面我开始补增长相关的东西。先接 Google Analytics，看访问量、来源、页面停留和转化路径。再接 Google Search Console，看 Google 是否收录，哪些页面有展现，有没有索引问题。

然后做技术 SEO——title、description、canonical、sitemap、robots、多语言路径。

我也考虑过广告投流。但这里又有一个现实判断：当前站点功能还不够多，一站式处理能力还不完整。如果这个时候大量投流，用户进来了，也不一定能转化。

所以接下来还要继续打磨产品。

写在最后

跑完这一轮，我对海外 AI 工具站的理解更清晰了。它不是单纯的技术实验，而是一套从产品、技术、合规、成本、支付到获客的小系统。

个人项目和大公司项目的本质区别在于资源约束。大公司里你可能不关心一台服务器多少钱、视频带宽多少钱、一个模型服务吃多少内存，但个人项目里，每一个技术选择最终都会变成成本。

所以 MVP 阶段，技术不要陷得太深。先低成本上线，先验证真实需求，先验证用户愿不愿意使用、愿不愿意付费。有真实用户和收入之后，再决定哪些能力值得自建。

技术人员很容易高估"能做出来"的价值，低估"能上线、能收费、能获客"的难度。技术是底盘，这点毋庸置疑。但在海外 AI 工具站的第一阶段，最重要的是把技术放在正确的位置——先服务 MVP，先服务上线，先服务商业验证。

如果你也想做一个 AI 工具站，建议先别急着做平台。从一个真实需求开始，做一个工具，跑通一条链路，把部署、支付、统计、SEO 都接起来。这时候再回头看，你会更清楚下一步该深挖技术，还是继续打磨产品。

欢迎打开 HillBoss看看我目前做到哪一步。它还不完美，但正好是一份正在迭代的真实样本。