去年秋天我开始做 AI Writer 的时候，面临的第一道选择题就是：技术栈怎么选？

没有团队，没有 Ops，预算有限——这是大多数独立开发者的真实处境。这篇文章不讲大道理，只记录我在做实际产品时的技术取舍和思考过程，希望能给你一些参考。

一、选型原则：从后往前推

我的选型逻辑很简单：从最终用户感受到的体验，往前倒推需要什么基础设施。

AI Writer 的核心场景是：用户上传一篇英文论文 → 系统分析 AI 率 → 提供降 AI 改写建议。这意味着我需要：

  • 一个能处理长文本的 LLM 推理层
  • 足够快的响应速度（用户等不了 30 秒）
  • 可靠的存储（用户数据不能丢）
  • 简单的部署方式（一个人运维）

下面是我的最终选择，以及为什么选它们。

二、LLM 推理：Claude API + 多 Provider 兜底

AI 产品的核心是模型推理。我选 Claude API 作为主力有三层考虑：

质量优先：AI Writer 的核心价值是"保留学术原意的前提下降 AI 率"，对语义理解能力要求很高。Claude 在长文本、学术语境下的表现是目前最好的。

但只依赖一个 provider 有风险——API 故障、限流、价格波动。所以我在架构上预留了多 Provider 切换能力：

// LLM Provider 抽象层
interface LLMProvider {
  name: string;
  chat(messages: Message[], opts?: Options): Promise<Response>;
}

const providers = {
  claude: new ClaudeProvider(process.env.CLAUDE_API_KEY),
  openai: new OpenAIProvider(process.env.OPENAI_API_KEY),
  // 未来可扩展
};

// 自动降级：主 provider 失败 → 备选重试
async function withFallback(messages, main = 'claude') {
  for (const name of [main, ...Object.keys(providers).filter(p => p !== main)]) {
    try {
      return await providers[name].chat(messages);
    } catch (e) {
      console.warn(`${name} 失败，尝试下一个`, e.message);
    }
  }
  throw new Error('所有 provider 均不可用');
}

实际的体验是：Claude API 的可用性很好，上线以来没触发过降级。但有了这套兜底，睡觉也踏实些。

三、存储：SQLite 是独立开发者的最佳朋友

在做技术选型时，我一度认真考虑过 PostgreSQL，甚至看了 Supabase。但最后选择了 SQLite——准确地说，是 Turso（基于 libSQL 的边缘分布式 SQLite）。

理由很简单：

  • 零运维：不需要连接池，不需要配置主从，不需要处理备份——Turso 自动处理
  • 足够快：对独立开发者来说，SQLite 的性能天花板非常高。单表百万条数据量级的查询，毫秒级返回
  • 开发体验好：本地开发就是文件读写，不用装数据库

如果将来业务量真的大到 SQLite 扛不住，那时候再切 PostgreSQL 也不迟。大多数项目根本活不到那一天——这听起来有点残酷，但做独立开发先活下来比什么都重要。

四、部署：最简方案

部署我选了 Vercel + Cloudflare Workers 的混合方案：

前端 Vercel（Next.js）
API 层 Vercel Edge Functions
AI 推理 Cloudflare Workers（长任务）
数据库 Turso（边缘 SQLite）
域名 Cloudflare DNS

这套组合的好处是：所有服务都有 generous 的免费额度。在用户量到几百之前，月度基础设施成本基本为 0。

五、一些经验教训

最后分享几个踩过的坑：

① 不要在早期做微服务。我一开始试图把前端、API、AI 推理拆成三个独立服务，结果花了大量时间在部署配置和服务间通信上。后来全部合并到一个 Next.js 应用里，用路径区分职责，开发效率提升了一倍。

② 流式响应是刚需。AI 产品的用户体验很大程度取决于响应速度。即使用户需要等 10 秒才能拿到完整结果，只要用流式（SSE）让用户看到文字逐行出现，感知延迟就基本消失了。

③ 数据库 schema 不要一开始就上 ORM。我早期用 Drizzle ORM，但频繁的需求变更导致 migration 文件膨胀。后来直接写 raw SQL，反而更清晰——当然这只是个人偏好，小团队的优势就是可以随时改主意。

以上是在构建 AI Writer 过程中的真实技术决策。没有哪个选择是完美的，技术选型本质上是在有限资源下做 trade-off。

如果你也在做类似的事，欢迎 发邮件 一起交流——独立开发者的路，一个人走有时候挺孤独的。