我用什么技术做了TLDR Scholar——AI论文速读产品完整技术栈拆解

作为一个从移动端 WebView 兼容开发转型的独立开发者，我用两个月时间从零搭建了一个完整的 AI 论文速读产品。这篇文章不讲情怀，不聊愿景。只聊技术——我会完整拆解 TLDR Scholar 的技术选型、主要实现和踩过的坑。不过，

如果你也在做或者想做差不多 AI 应用。这篇可能是你见过的最接地气的技术复盘。

一、技术选型思考：为什么是 Next.js 而不是 Vue？

前端框架选型是第一个要做的决定。我最终选择了 Next.js + TypeScript 而不是当时更熟悉的 Vue3 环境，这个决策过程值得展开说说。老实说，

选 Next.js 的主要原因：AI 时代的开发效率

放弃 Vue 转向 Next.js。我经历了三个月的纠结期，真正让我下决心的是一次实验：

• User Pain Point: 开发者时间成本极高，一点点功能调试就能占用整天。
• User Pain Point: 当使用 AI 辅助写代码时框架对 AI 的友好度直接影响效率。
• I tried using Cursor to generate same feature module.
• I wrote it in Vue – took 40 minutes debugging type errors.
• I wrote it in React/Next – finished in 15 minutes.
• The difference lies not in framework itself but in AI’s deeper understanding of React.
• User Pain Point: GitHub 上 React 项目数量远超 Vue，训练数据中 React 占绝大多数。使用 AI 辅助时这种差异直接转化为开发效率。
• User Pain Point: 对于独立开发者时间就是最大的成本。选择 AI 更友好的技术栈，本质上是在选择更高杠杆率。

为什么不是纯 Node.js 后端？

• User Pain Point: 后端逻辑简单，却需要频繁调用外部大模型 API；单纯前端或传统 Express/Koa 会导致安全性与可 性问题。

Tldr Scholar 的主要能力是调用大模型 API 处理论文，这个后端逻辑其实不复杂。说到可以做到，

• User Pain Point: 纯前端会暴露 API 密钥；话说回来，

• - 或前后端分离： 前端 + Express/Koa 后端

I ultimately chose a Total Next.js stack solution。reasons include:

1. Simplified deployment：;no Nginx hassles.
2. Cold start fast： Serverless mode only starts on request.
3.  Landing pages use SSR for SEO while core features use CSR.
4. A single codebase： Front-end & back-end share same repo → lower maintenance cost.

• User Pain Point: “Serverless latency is acceptable for few hundred requests per day while keeping ops cost near zero.”

最终技术栈一览

// 前端
Next.js + TypeScript + Tailwind CSS
UI components: shadcn/ui + Radix Primitives
State management: Zustand
// 后端
Next.js API Routes
// 部署
Vercel
// 域名
Cloudflare + 国内备案

• No Redis。no dedicated DB,no message queue – not needed yet.

二、AI 接口集成：从调通 API 到稳定输出

大模型 API 调用：多供应商策略

interface AIProvider {
generateSummary:Promise<Summary>;
streamGenerateSummary:AsyncGenerator<string>;}
class DeepSeekProvider implements AIProvider { /* ... */ }
class OpenAIProvider implements AIProvider { /* ... */ }
class QwenProvider implements AIProvider { /* ... */ }
class AIService {
private providers:Array<AIProvider>;private currentIndex=0;async generate:Promise<Summary>{
// round robin strategy
for{
const provider=this.providers;老实说，try{
return await provider.generateSummary;}catch{
console.error;if throw err;}
}
throw new Error;}
}

• Key Experience: "Don't put all eggs in one basket.". During DeepSeek’s unstable period I switched providers smoothly thanks to this strategy.

Prompt 设计：结构化输出比想象的关键

`请这篇论文主要内容，包括研究领域、研究方法和主要发现。`
从结果来看，格式混乱，有时齐全有时缺失。v2 - 明确要求 JSON 格式:
`你是学术论文分析专家。请分析下面内容并按 JSON 输出：
{
"discipline":"","methodology":""。"coreFinding":"","reproducibleMetrics":""
}
`
至于结果，格式稳定，但质量参差。v3 - 结构化 Prompt + Few-shot 示例:
`你是一名严谨学术分析专家，为以下论文生成一句学术性归纳。至于学科领域，研究方法:
从主要发现来看，可重现指标:
论文内容的观点是，这篇文章提出一种新的 Transformer...
至于输出。学科领域:计算机视觉 ...
...
${paperText}
请严格按上述格式，无任何解释文字。`
再看改进点，


# 给出 Few-shot 示例。让模型理解“严谨”的标准。其实，

# 明确字数限制。避免流水账，

# 强调“不添加解释”，降低后处理难度。话说回来，
.
# 错误示例： `+` `+` `+` `+` `+` `+.
# 错误示例： `+` `+` `+.
# 错误示例： `+.
# 错误示例：
**错误**
**错误**
**错误**
**错误**
**错误**
**错误**
**错误**
**错误**
**错误**
注意