【自学AI】13 实现一个生产级 AI 简历押题系统的完整复盘

决策 1：为什么用 SSE 而不是轮询？#

AI 生成至少需要 5 分钟，用户盯着白屏等 5 分钟是什么体验？

一开始想用轮询——前端每秒发一个请求问”好了没？” 但算了一下：5 分钟 = 300 秒 = 300 个请求。

服务器要处理 300 个重复请求，用户要等 2-3 秒才看到更新—— 这不是好的解法。

SSE 的优势：

• 后端主动推送，前端被动接收
• 一个连接，持续推送
• 实时性好（100 毫秒内看到更新），资源消耗少

核心代码很简单：

1
const subject = new Subject<ProgressEvent>();
2

3
subject.subscribe({
4
  next: (event) => {
5
    res.write(`data: ${JSON.stringify(event)}\n\n`); // 推送给前端
6
  },
7
});

后端每次有进度更新，就往 subject 里扔一个事件，前端自动收到。

这个决策的本质： 对于长时间运行的异步任务，主动推送比被动轮询更高效。

决策 2：为什么分两步而不是一步？#

这是整个系统最重要的架构决策。

一开始想一步到位——让 AI 一次性生成”题目 + 分析”。 但实际测试发现，一步法有几个问题：

改成两步之后：

1
// 第一步：生成题目（7 分钟）
2
const questionsResult = await aiService.generateResumeQuizQuestionsOnly({...});
3

4
// 第二步：生成分析（2 分钟）
5
const analysisResult = await aiService.generateResumeQuizAnalysisOnly({...});

数据对比：

两步法看起来多了一次 API 调用，但总时间反而更短—— 因为两个中等请求比一个超长请求更快。

而且用户体验更好：第一步完成后，用户已经看到”题目已生成”，心里有数。

《易经·履卦》：“履道坦坦，幽人贞吉。” 一步一步踩实，比一次性跳过去更稳。

决策 3：为什么简历有三种方式而不是只有一种？#

最简单的做法是：只支持”粘贴文本”，用户自己复制粘贴简历。

但这样用户体验很差——大部分人的简历是 PDF 或 DOCX 文件， 让他们先打开文件、复制内容、再粘贴，多了两步。

所以我们支持了三种方式：

这是优雅的降级设计——让用户选择最方便的方式，而不是强制一种。

文件解析的技术栈：

1
// 依赖三个包
2
pnpm add axios@1.13.2 pdf-parse@1.1.1 mammoth@1.11.0
3

4
// 根据文件类型选择解析方式
5
switch (fileType) {
6
  case 'PDF':
7
    text = await this.parsePdf(buffer);
8
    break;
9
  case 'DOCX':
10
    text = await this.parseDocx(buffer);
11
    break;
12
}

这个决策的本质： 支持多种输入方式是产品体验的基础，不要偷懒只做一种。

决策 4：为什么扣费要提前，失败后再退费？#

扣费时机有三种选择：

完整的扣费生命周期：

1
原子扣费（resumeRemainingCount - 1）
2
         ↓
3
创建消费记录（status: PENDING）
4
         ↓
5
AI 生成（可能失败）
6
         ↓
7
保存结果
8
         ↓
9
消费记录 → SUCCESS
10

11
         ↕（任何一步失败）
12

13
退款（resumeRemainingCount + 1）
14
消费记录 → FAILED + isRefunded: true

原子操作的关键代码：

1
// ✅ 正确方式（原子操作）
2
const user = await this.userModel.findOneAndUpdate(
3
  {
4
    _id: userId,
5
    resumeRemainingCount: { $gt: 0 }, // 条件检查
6
  },
7
  {
8
    $inc: { resumeRemainingCount: -1 }, // 原子递减
9
  },
10
  { new: false }, // 返回更新前的文档
11
);
12

13
if (!user) {
14
  throw new BadRequestException('次数不足');
15
}

为什么要原子操作？

假设两个请求同时进来，用户只剩 1 次：

• 请求 A 读到余额 = 1，扣费，余额变成 0
• 请求 B 也读到余额 = 1（因为 A 还没写回去），也扣费，余额变成 -1

这就是并发问题。

原子操作把”检查余额”和”扣费”合并成一个不可分割的动作， 数据库保证同一时间只有一个请求能成功。

这个决策的本质： 先扣费、后生成、失败退款，是最清晰、最可靠的方式。

决策 5：为什么要进度条？#

AI 生成至少需要 5 分钟，用户盯着白屏等 5 分钟是什么体验？

进度条的核心问题是：AI 生成是异步的，我们不知道它什么时候完成，没办法给出真实的进度百分比。

解决方案：模拟进度。

1
private getStagePrompt(progressSubject: Subject<ProgressEvent>): void {
2
  const progressMessages = [
3
    { progress: 0.05, message: '🤖 AI 正在深度理解您的简历内容...' },
4
    { progress: 0.1,  message: '📊 AI 正在分析您的技术栈和项目经验...' },
5
    { progress: 0.15, message: '🔍 AI 正在识别您的核心竞争力...' },
6
    // ... 共 18 条消息，覆盖 0-90%
7
  ];
8

9
  let progress = 0;
10
  const interval = setInterval(() => {
11
    progress += 1;
12
    this.emitProgress(progressSubject, progress, progressMessages[progress].message);
13

14
    if (progress === progressMessages.length - 1) {
15
      clearInterval(interval);
16
    }
17
  }, Math.floor(Math.random() * (2000 - 800 + 1)) + 800); // 每 0.8-2 秒随机更新
18
}

关键设计：

• 随机间隔（0.8-2 秒）：比固定 1 秒更自然
• 消息内容有变化：从”理解简历”到”设计问题”到”质量检查”
• 进度只到 90%：最后 10% 留给真实完成事件

这样用户看到的是：进度条在动，消息在变，AI 真的在干活—— 虽然我们不知道真实进度，但用户感受到的是”有进展”。

这个决策的本质： 不确定性的进度条，用模拟 + 随机间隔 + 有意义的消息，让用户感到”AI 真的在干活”。

思维 1：先设计，后编码#

我们没有上来就写代码，而是先花了大量时间做设计。

为什么？

• 代码是容易改的，但如果架构错了，代价很高
• 需求理解不清楚，代码写出来也是错的
• 数据结构设计不好，后续会很痛苦

正确的顺序：

1
需求分析 → 架构设计 → 数据库设计 → 代码实现

《易经·系辞》：“形而上者谓之道，形而下者谓之器。” 道是架构，器是代码。道不清楚，器再精致也没用。

思维 2：每一步都能独立测试#

我们没有说”全部写完再测试”，而是：

• 框架搭好后，能调用接口吗？能收到 SSE 响应吗？
• 简历能解析吗？能验证格式吗？
• 扣费能成功吗？退费能成功吗？
• 复杂的文件解析对吗？边界情况处理了吗？
• AI 能生成内容吗？JSON 格式正确吗？

这就是增量开发——每一步都是完整的、可测试的、有价值的。

不是等到全部写完才发现”哦，这里有个 Bug”， 而是每写完一个模块，立刻测试，立刻发现问题。

思维 3：用户体验很重要#

为什么要有进度条？为什么要分两步？为什么要支持三种方式？

都是为了用户体验。

站在用户的角度想：

• “我点了生成,然后什么都没发生，5 分钟都没动静，我以为系统死了”（没有进度条）
• “我只支持上传文件，但我想直接粘贴简历”（方式太少）
• “生成成功了，但配额没了，也没有提示”（体验差）

好的产品，永远是从用户的角度出发。

思维 4：失败处理和回滚#

我们在扣费那一节讲了很多关于”失败怎么办”的问题。

本质思想是：在分布式系统中，失败是常见的，关键是怎样恢复。

这不是说”万一出错，用户就认了”， 而是说”有任何错误，我们都有备选方案”。

嵌套 try-catch 的价值：

1
try {
2
  // 扣费 + 生成
3
} catch (error) {
4
  try {
5
    await refundCount(userId, 'resume'); // 退款
6
  } catch (refundError) {
7
    // ⚠️ 退款失败是严重问题，必须告警
8
    this.logger.error(`🚨 退款流程失败！需要人工介入！`);
9
    // TODO: 发送告警通知
10
  }
11
}

这就是健壮的系统设计。

1. 优化质量#

• 收集用户反馈，迭代 Prompt
• 做 A/B 测试，对比不同 Prompt 的效果
• 加入人工审核，确保质量

2. 优化成本#

• 分析 Token 消耗，找到优化空间
• 考虑用更便宜的模型（但要测试质量）
• 加入缓存，避免重复计算

3. 优化体验#

• 加入实时反馈（用户可以标记”这道题不好”）
• 支持导出（用户可以下载为 PDF）
• 支持分享（用户可以分享给朋友）

4. 扩展功能#

• “专项面试”模块（针对某个特定技术深度）
• “模拟面试”模块（AI 作为面试官）
• “薪资谈判”模块（怎样谈出高薪）

这些都是基于现有基础，可以逐步建立。

架构设计比代码实现更重要#

代码是容易改的，但架构错了，代价很高。

这次做系统，最花时间的不是写代码，是想清楚：

• 扣费时机怎么设计？
• 两步法还是一步法？
• 失败了怎么回滚？

想清楚之后，代码反而写得很快。

用户体验是产品的灵魂#

技术再好，用户体验差，也没人用。

进度条、三种输入方式、友好的错误提示—— 这些看起来是”细节”，但恰恰是用户感受最深的地方。

失败处理和成功处理一样重要#

很多教程只讲”成功的路径”，不讲”失败了怎么办”。

但真实系统里，失败是常见的——网络超时、数据库连接失败、AI 返回格式错误……

怎样优雅地处理失败、怎样自动恢复、怎样保护用户数据—— 这些才是系统是否靠谱的关键。

工程思维是可以迁移的#

这次学到的思维方式——先设计后编码、增量开发、原子操作、失败回滚—— 不只适用于 AI 应用，适用于任何复杂系统。

技术会变，但工程思维不会变。