返回笔记首页
最后更新: 2026-06-05v-green

面试官追问的问题

主题配置

第一部分：AI 智能运营平台

一、大模型基础知识

Q1：你说对接了 DeepSeek 接口，能说说大模型的 API 调用基本流程吗？

考察意图：验证你是真的对接过，还是只是把接口封装抄过来用的。

答案要点：

大模型 API 调用本质是一个 HTTP POST 请求，核心结构是：

plain 
请求体：
{
  model: "deepseek-chat",       // 指定模型
  messages: [                    // 对话历史
    { role: "system", content: "你是客服助手..." },
    { role: "user", content: "用户提问" },
    { role: "assistant", content: "上一轮回复" },
    { role: "user", content: "当前提问" }
  ],
  stream: true,                  // 是否流式输出
  max_tokens: 2000               // 最大生成长度
}

messages 数组是关键，它维护了整个对话上下文。大模型本身是无状态的，每次调用都需要把历史对话带上去，模型才知道上下文。

避坑提示：不要说"就是调一个接口，传 prompt 进去"，这说明你没理解 messages 结构，面试官会继续追。

Q2：什么是 Token？项目里你是怎么理解和使用 Token 的？

考察意图：看你对 AI 成本概念的理解深度，这是运营平台的核心业务价值。

答案要点：

Token 是大模型处理文本的基本单位，不是字符也不是单词，是介于两者之间的文本片段。

计量规律：

  • 英文大约 4 个字符 = 1 个 token
  • 中文大约 1-2 个汉字 = 1 个 token
  • 标点符号通常是 1 个 token

实际费用计算：每次请求消耗 = prompt_tokens（输入）+ completion_tokens（输出），按百万 token 计费。

在项目里的应用：接口返回的 usage 字段包含本次消耗，我在调试界面展示了每次对话的 token 构成。通过分析历史 usage 数据，发现了约 30% 的冗余上下文，因为对话历史没有做裁剪，把几十轮早期对话全部带上去了，推动后端做了滑动窗口裁剪，月度成本降了约 25%。

避坑提示：不要把 token 和"字"等同，中文一个字不等于一个 token，面试官如果精通这块会追问。

Q3：你提到了 RAG，能解释一下 RAG 的完整流程吗？前端参与了哪些环节？

考察意图：RAG 是现在 AI 应用最核心的技术之一，看你理解有多深。

答案要点：

RAG（Retrieval-Augmented Generation，检索增强生成）解决的核心问题是：大模型的训练数据有截止日期，也不了解企业私有知识，直接问会产生幻觉或说"不知道"。

完整流程分两个阶段：

离线阶段（建库）
plain 
文档 → 分块（Chunking）→ 向量化（Embedding）→ 存入向量数据库
在线阶段（检索）
plain 
用户提问 → 问题向量化 → 向量相似度检索 → 取 Top-K 相关分块
          → 拼入 Prompt → 调用 LLM → 返回答案

前端在 RAG 流程中参与的环节：

  1. 文档上传界面：支持 PDF、Word、TXT 上传，展示解析和向量化进度
  2. 分块可视化：让运营看到文档被切成了哪些片段，字数多少，是否合理
  3. 分块编辑：允许手动修正分块内容，触发增量向量化而非全量重算
  4. 命中率展示：统计每个分块被检索命中的频率，用热力图展示，帮助运营判断知识库质量
  5. 检索来源追溯：在 AI 回答旁边展示引用了哪些文档片段（这个项目里用监控模块做了对话回放）

避坑提示：很多人只知道 RAG 是"先搜索再生成"，但说不清楚分块策略、向量相似度计算、Top-K 这些细节。面试官如果深问"为什么要分块"，答案是：整篇文档向量化后是一个向量，精度很低；分块后每段有独立的向量，检索更精准，而且可以只返回最相关的几段，不超出上下文窗口。

Q4：向量和向量数据库是什么，前端需要直接操作吗？

考察意图：验证你对 AI 工程链路的理解，而不只是会调接口。

答案要点：

向量（Embedding）：把文本转换成一组数字（比如 1536 维的浮点数组），语义相近的文本，它们的向量在数学空间里距离也近。这个转换由 Embedding 模型完成（比如 OpenAI 的 text-embedding-ada-002，或 DeepSeek 的 embedding 接口）。

向量数据库：专门存储和检索向量的数据库，支持"相似度搜索"——给一个查询向量，返回最接近的 Top-K 个结果。常见方案：Pinecone、Weaviate、Chroma、Milvus，或者 PGVector（PostgreSQL 插件）。

前端需要直接操作向量数据库吗：通常不需要。向量化（调 Embedding 接口）和向量存储（写入向量数据库）都在后端完成，前端只负责展示结果和触发操作。

但有一个特殊场景值得了解：离线/隐私场景下，可以用 transformers.js 在浏览器端跑轻量 Embedding 模型，完全本地化。这个在面试中说出来是加分项。

Q5：流式输出（SSE）和普通接口请求有什么区别？你是怎么实现的？

考察意图：流式输出是 AI 前端的最核心技术点，必问。

答案要点：

普通请求：等 AI 生成完整回复后，一次性返回全部内容。用户等待时间 = 模型生成全部内容的时间，通常需要几秒到几十秒，体验很差。

流式输出：AI 生成一个 token 就立刻返回，前端实时显示，用户感知到的等待只有第一个字出现的时间（TTFF，通常不到 1 秒）。

实现方式是 Fetch + ReadableStream：

javascript 
const response = await fetch('/v1/chat/completions', {
  method: 'POST',
  body: JSON.stringify({ stream: true, ...payload })
})

const reader = response.body.getReader()
const decoder = new TextDecoder('utf-8', { stream: true })

while (true) {
  const { done, value } = await reader.read()
  if (done) break
  const text = decoder.decode(value, { stream: true })
  // 按行解析 SSE 格式：data: {...}
  for (const line of text.split('\n')) {
    if (!line.startsWith('data: ')) continue
    const json = JSON.parse(line.slice(6))
    const content = json.choices[0]?.delta?.content ?? ''
    if (content) appendToUI(content)
  }
}

关键细节：

  • TextDecoder 的 { stream: true } 处理跨 chunk 的多字节字符（中文）
  • 用 AbortController 实现"停止生成"
  • TTFF 指标：记录发请求到收到第一个 token 的时间，是衡量 AI 接口性能的核心指标

避坑提示：不要说"用 EventSource 实现的"，EventSource 只能发 GET 请求，无法自定义 Authorization Header，对接 AI 接口必须用 Fetch。

Q6：Prompt Engineering 是什么？你在项目里怎么体现的？

考察意图：看你对 Prompt 工程的理解是否停留在"写提示词"层面。

答案要点：

Prompt Engineering 是通过设计和优化输入给大模型的提示词，来控制模型输出质量和方向的工程实践。

核心技巧：

角色定义：告诉模型它是谁，限定行为范围

plain 
你是一个专业的客服助手，只回答产品相关问题

结构化约束：用明确的格式告诉模型怎么回答

plain 
【回答结构】问题确认 → 原因分析 → 解决方案 → 满意度确认

边界约束：告诉模型不能做什么

plain 
【禁止行为】不得承诺无法兑现的服务，不得评价竞品

Few-shot 示例：给模型几个例子，让它理解期望的格式

在项目里的体现：

  • Prompt 版本管理让运营可以迭代和对比不同 Prompt 的效果
  • A/B 测试让运营用数据而不是感觉来判断哪个 Prompt 更好
  • 在线调试让运营在上线前验证 Prompt 效果

避坑提示：不要说 Prompt Engineering 就是"写提示词"，面试官会认为你理解浅。要强调"用结构化方式设计"和"用数据验证效果"。

Q7：上下文窗口是什么？你们项目是怎么处理上下文超限问题的？

考察意图：考察你对大模型实际工程限制的理解。

答案要点：

上下文窗口（Context Window）：大模型每次能处理的最大 token 数量。比如 DeepSeek-V2 的上下文窗口是 128K tokens，GPT-4o 是 128K，早期 GPT-3.5 只有 4K。

超出上下文窗口的内容，模型会直接看不到，导致"忘记"前面的对话。

处理策略：

策略一：滑动窗口（最常用） 只保留最近 N 轮对话，丢弃更早的历史。实现简单，但会丢失早期上下文。

策略二：摘要压缩 当历史消息超过阈值时，先让 AI 对早期对话生成摘要，用摘要替换原始消息。保留语义但减少 token 占用。

策略三：前端 Token 预算 UI 在输入框旁边实时展示已用 / 剩余 token 数，让用户感知。项目的调试界面展示了每次请求的 token 构成，就是这个方向的实践。

策略四：RAG 替代长上下文 不把大文档塞进上下文，而是向量检索后只注入最相关的几段。这是更根本的解法。

Q8：A/B 测试里你提到满意度、完成率这些指标，这些数据从哪里来？怎么统计的？

考察意图：看你是否理解 AI 产品的效果评估体系，而不只是做了个界面。

答案要点：

这些指标数据来源和统计方式：

满意度（Satisfaction Rate）：用户主动对 AI 回复点"👍"或"👎"的比率，也可以来自对话结束后的满意度问卷。前端负责埋点收集用户反馈，上报给后端统计。

完成率（Completion Rate）：用户提问后，对话正常结束（区别于中途退出、触发敏感词中断）的比率。后端根据对话状态统计。

平均回复长度：completion_tokens 的平均值，或者解码后的字符数。回复太短说明模型在敷衍，太长说明废话多。

平均 Token 消耗：每次请求的 prompt_tokens + completion_tokens 均值，用于成本分析。

A/B 测试中，两个 Prompt 版本分别对不同用户生效，后端按版本分组统计这些指标，前端拿到两组数据做对比展示。

避坑提示：如果被问"你们怎么保证 A/B 分组的统计准确性"，答案是：分流在服务端做，同一个用户在测试期间始终命中同一个版本（用 userId 哈希），不能每次请求随机分，否则同一用户的数据会分到两组导致污染。

二、监控与性能相关

Q9：你说监控了 TTFF，这个指标怎么计算的，正常范围是多少？

考察意图：看你是否真的理解这个指标，还是只是背了个名词。

答案要点：

TTFF（Time to First Token，首 Token 响应时长）= 发出请求的时间戳 - 收到第一个 token 的时间戳。

javascript 
const startTime = Date.now()
let firstTokenTime = null

// 在 onChunk 回调里记录
if (!firstTokenTime && content) {
  firstTokenTime = Date.now()
  const ttff = firstTokenTime - startTime
  reportMetric('TTFF', ttff)
}

正常范围参考：

  • 优秀：< 500ms
  • 良好：500ms - 1000ms
  • 可接受：1000ms - 2000ms
  • 需要优化：> 2000ms

影响 TTFF 的因素：

  • 网络延迟（用户到服务器的距离）
  • 服务端排队时间（并发高时需要等待 GPU 资源）
  • Prompt 长度（输入越长，模型开始生成前需要处理的时间越长）
  • 模型规模（大模型推理更慢）
Q10：SSE 连接断了怎么处理？你们有没有做断线检测？

考察意图：考察你对 SSE 可靠性设计的理解，是否想到了生产环境的边界情况。

答案要点：

SSE 断线分两种情况，处理方式不同：

情况一：网络抖动（临时断线） 浏览器原生支持自动重连，SSE 断线后会自动尝试重新连接。服务端通过在每条消息里带 id 字段，客户端重连时在 Last-Event-ID 请求头里带上最后收到的 id，服务端从这个 id 之后的消息开始续传，不重复发送历史数据。

情况二：服务端主动关闭（比如后端重启）EventSource.onerror 触发，此时 readyState === CLOSED，浏览器不会自动重连。前端需要检测到这种情况，提示用户刷新页面。

项目里的做法：做了数据新鲜度检测。维护了一个 lastUpdateTime 时间戳，每次收到推送时更新。另起一个定时器每 5 秒检查一次，如果超过 30 秒没收到推送，说明连接可能已经静默断开，在页面上显示"数据可能已过期"的提示。这样即使 SSE 静默断开，用户也不会一直盯着过期数据不知情。

第二部分：AI 训练数据标注平台

三、AI 训练数据相关

Q11：你说做了 RLHF 标注，RLHF 是什么？你理解它训练的目标是什么？

考察意图：RLHF 是训练 ChatGPT 类模型的核心技术，看你是真懂还是只是用了这个词。

答案要点：

RLHF（Reinforcement Learning from Human Feedback，基于人类反馈的强化学习）是让大模型学会"什么样的回答是好的"的训练方法。

为什么需要 RLHF： 单纯用文本预训练的大模型，输出可能很流畅但不符合人类期望，比如给出有害内容、答非所问、过于冗长。监督学习需要大量人工写"标准答案"，成本极高。RLHF 让人类只做"比较判断"（A 比 B 好），比写答案容易得多，数据收集效率高很多。

三阶段训练流程：

plain 
阶段一：监督微调（SFT）
人工写一些高质量的问答对 → 微调基础模型

阶段二：奖励模型训练（RM）
给同一个问题的多个回复让人排序 → 训练奖励模型（就是我这个项目在做的）

阶段三：强化学习优化（PPO）
用奖励模型给大模型打分 → 用 PPO 算法优化大模型，让它生成奖励分高的回复

标注员在平台里做的"选 A 还是 B"，产出的就是阶段二的训练数据。

避坑提示：不需要解释 PPO 算法细节，面试前端的人说不清楚很正常。但要说清楚"标注数据用于训练奖励模型，奖励模型再用于优化 LLM"这个链条。

Q12：NER 是什么，标注出来的数据有什么用？

考察意图：看你对标注类型的业务理解，不只是"做了个功能"。

答案要点：

NER（Named Entity Recognition，命名实体识别）是从文本中识别出有特定意义的实体，比如人名、地名、机构、疾病、药品、日期等。

标注产出的数据格式：

json 
{
  "text": "张伟于2024年11月在北京协和医院确诊为2型糖尿病",
  "entities": [
    { "start": 0, "end": 2, "text": "张伟", "type": "person" },
    { "start": 3, "end": 11, "text": "2024年11月", "type": "time" },
    { "start": 12, "end": 18, "text": "北京协和医院", "type": "org" },
    { "start": 21, "end": 27, "text": "2型糖尿病", "type": "disease" }
  ]
}

标注数据的用途：

  • 训练 NER 模型，让模型自动识别新文本中的实体
  • 用于知识图谱构建（提取实体和实体之间的关系）
  • 用于信息抽取（从大量非结构化文本里提取结构化数据）
  • 也可以用于大模型的指令微调（SFT），让模型学会做实体识别任务
Q13：图片目标检测的标注数据格式是什么？对接训练框架时有什么注意点？

考察意图：看你是否理解标注数据和训练框架的对接关系。

答案要点：

项目里导出的标注格式：

json 
{
  "image": "商品图片_001.jpg",
  "annotations": [
    { "label": "product", "bbox": [120, 85, 340, 280] }
  ]
}

bbox 格式是 [x, y, width, height]，这是 COCO 数据集格式，被 YOLO、Detectron2 等主流目标检测框架广泛支持。

对接训练框架的注意点：

  1. 坐标归一化：Canvas 里的坐标是像素坐标，训练时通常需要归一化到 0-1 之间。YOLO 格式就是归一化坐标：x_center / img_width, y_center / img_height, w / img_width, h / img_height。
  2. Canvas 缩放问题：展示时图片做了缩放适配 Canvas 尺寸，导出坐标时要还原到原图尺寸，否则训练数据会有偏差。
  3. 数据格式转换：不同框架格式不同，YOLO 是 txt 文件，COCO 是 JSON，Pascal VOC 是 XML，根据训练框架做对应的格式转换。
Q14：标注数据的质量怎么保证？Cohen's Kappa 是什么？

考察意图：看你是否理解数据质量对模型训练的影响，以及质检指标的业务含义。

答案要点：

为什么数据质量重要：模型的能力上限由训练数据决定。标注一致性差（不同标注员对同一条数据判断不同），模型学到的是"噪声"而不是规律，效果会很差。

Cohen's Kappa 系数：衡量两个标注员对同一批数据标注结果的一致程度，排除随机一致性的影响，比简单的"准确率"更可靠。

计算思路：

plain 
Kappa = (实际一致率 - 期望随机一致率) / (1 - 期望随机一致率)

数值解读：

  • 0.8 以上：一致性很强，数据质量好
  • 0.6-0.8：一致性较好，可以接受
  • 0.4-0.6：一致性一般，需要加强培训
  • 0.4 以下：一致性差，数据基本不可用

项目里从 0.71 提升到 0.85 的背后，是做了这几件事：

  • 制定更细致的标注规范（边界案例如何处理）
  • 标注前先做培训和黄金标准测试
  • 质检模块对一致性低的标注员重点抽查
  • 多人标注同一批数据取多数投票结果
Q15：任务被质检打回之后，标注员怎么知道哪些条目需要修改？

考察意图：考察你对完整业务流程的理解，不只是"做了质检功能"。

答案要点：

这是任务流转的闭环设计，涉及前端的几个环节：

  1. 质检员标记不通过时必须填写批注：代码里强制要求，否则无法标记不通过。批注内容说明具体哪里有问题（比如"选 A 但明显 B 回答更准确，因为..."）。
  2. 打回操作触发通知：真实项目里，打回后通过 WebSocket 推送消息给标注员，立即收到通知，不需要手动刷新任务列表。
  3. 标注员重新进入任务时：只需要处理被标记不通过的条目，通过的条目已锁定不可修改，避免改了对的内容。
  4. 修改完提交：再次进入质检队列，质检员只需要复核被打回的条目，不需要重新审核所有内容。

项目里用 Pinia 的 rejectTask 方法更新任务状态，配合路由跳转让标注员回到标注页面，定位到需要修改的条目。

四、Canvas 与性能相关

Q16：Fabric.js 和原生 Canvas 相比，你选 Fabric.js 的理由是什么？有什么缺点？

考察意图：考察你的技术选型能力，能不能说清楚权衡取舍。

答案要点：

选 Fabric.js 的原因：

原生 Canvas 是命令式的，你画了什么，Canvas 不记得——它只有像素，没有"对象"的概念。要实现"点击选中某个矩形"，需要自己遍历所有矩形，用数学判断鼠标坐标是否在矩形内，再记录选中状态。要实现拖拽缩放，还要处理各方向的锚点、坐标变换、边界检查……这些基础能力，Fabric.js 全都内置了。

做标注工具选 Fabric.js，核心是省去了实现对象选择、拖拽、缩放、事件系统这套基础设施的工作量，让我能专注在标注业务逻辑本身。

Fabric.js 的缺点：

  1. 体积大：打包后约 300KB，对首屏加载有影响
  2. 渲染性能有上限：对象超过几百个时，默认渲染会变慢（需要手动优化，比如关闭 renderOnAddRemove、离屏缓存）
  3. 版本兼容问题：v5 和 v6 API 变化较大，社区资料多是老版本
  4. 不适合像素级操作：语义分割（像素涂抹）这类需求，Fabric.js 不适合，要用原生 Canvas 或 Konva.js
Q17：你提到帧率从 30fps 优化到 60fps，具体做了哪几步？每步效果怎么样？

考察意图：性能优化必须能说清楚"做了什么、为什么有效、效果是多少"，这是区分真做过和假做过的核心问题。

答案要点：

分三步，每步都有明显效果：

第一步：关闭**renderOnAddRemove**

问题：Fabric 默认每次 add()/remove() 对象都触发重绘。初始化时如果有 100 个标注框要从 JSON 恢复，就触发 100 次重绘，页面直接卡住。

修复：初始化时设置 renderOnAddRemove: false，批量操作完后手动调一次 requestRenderAll()。

效果：初始化阶段渲染时间从约 800ms 降到约 50ms。

第二步：分离 mousemove 和 mouseup 的渲染

问题：鼠标移动时绘制预览框，每次 mousemove 都触发 Fabric 全量重绘（包括底图、所有标注框）。500 个标注框的情况下，帧率掉到约 30fps。

修复：mousemove 时只更新高亮层（用一个单独的轻量 Canvas），不触发 Fabric 的重绘。mouseup 后才调 canvas.requestRenderAll() 做一次完整渲染。

效果：帧率从约 30fps 提升到约 45fps。

第三步：静止对象离屏缓存

问题：每帧渲染时，Fabric 对所有对象都执行绘制指令，即使它们没有变化。

修复：把静止的标注框（未被选中、未在编辑）预先渲染到一个离屏 Canvas，主 Canvas 直接 drawImage(offscreenCanvas) 贴图。只有被选中或正在修改的对象走 Fabric 完整渲染。

效果：帧率从约 45fps 提升到稳定 60fps。

避坑提示：面试官可能追问"你怎么测量帧率的"。答：用 requestAnimationFrame 计算相邻两帧的时间差，或者用 Chrome DevTools 的 Performance 面板录制，看 FPS 曲线。

Q18：Canvas 里的撤销用了 JSON 快照，有没有更好的方案？为什么当时选快照？

考察意图：看你是否有技术深度，能不能主动说出方案的局限和改进方向。

答案要点：

JSON 快照方案的优缺点：

优点：实现简单，Fabric 内置 canvas.toJSON() 和 canvas.loadFromJSON()，5 行代码搞定；不需要为每种操作单独定义反向操作；出 bug 的概率低。

缺点：每个快照包含所有对象的完整数据，标注框多时体积大（比如 200 个标注框，每个快照可能 50KB，30 帧就是 1.5MB）；每次撤销需要重新解析 JSON 并重建所有对象，性能开销比较大。

更好的方案：Command 模式（增量撤销）

把每个操作封装成一个 Command 对象，包含 execute() 和 undo() 两个方法：

javascript 
class AddRectCommand {
  constructor(canvas, rect) {
    this.canvas = canvas
    this.rect = rect
  }
  execute() { this.canvas.add(this.rect) }
  undo() { this.canvas.remove(this.rect) }
}

优点：内存占用小（只存操作记录，不存全量状态）；撤销执行的是反向操作，速度快；可以支持 redo（重做）。

缺点：需要为每种操作（新增、移动、缩放、删除、批量操作）分别实现 execute 和 undo 逻辑，开发工作量大，边界情况多。

当时选快照的原因：标注工具的交互类型固定（就那几种操作），操作频率也不高（不是游戏类的高频操作），快照的内存和性能问题在可接受范围内。如果单张图片的标注框经常超过 100 个，或者需要支持多步 redo，再考虑换 Command 模式。

第三部分：通用大模型知识

Q19：你在项目里用了 DeepSeek，它和 GPT-4 有什么区别？为什么选 DeepSeek？

考察意图：看你对国内外主流大模型生态的了解程度。

答案要点：

为什么选 DeepSeek：

  • 接口和 OpenAI 完全兼容（同样的 /v1/chat/completions 路径、同样的请求格式），迁移成本为零
  • 国内访问速度快，延迟低，不需要代理
  • 价格比 OpenAI 低很多（约为 GPT-4 的 1/10 到 1/20）
  • 中文能力强，客服场景下效果不输 GPT-4

和 GPT-4 的差异：

  • GPT-4 综合能力（特别是复杂推理、代码生成）仍领先
  • DeepSeek 在中文任务、数学推理上有独特优势
  • GPT-4 生态更成熟，插件、Fine-tuning 支持更完善
  • DeepSeek 数据合规性在国内更有保障（数据不出境）

项目实践意义：接口兼容 OpenAI 格式，意味着换模型只需要改两行配置（base_url 和 model name），不需要改任何业务代码，这个架构设计值得强调。

Q20：大模型会产生幻觉，前端怎么从产品层面缓解这个问题？

考察意图：考察你对 AI 产品设计的理解，而不只是工程实现。

答案要点：

什么是幻觉：大模型生成了听起来合理但实际上错误的内容，比如编造不存在的引用、错误的事实、不准确的数据。

前端 / 产品层面的缓解策略：

  1. RAG 引用来源透明化：把 AI 引用的原文文档片段展示在回答旁边，用户可以点击核实。类似 Perplexity 的角标引用设计，让用户看到"这句话的依据是哪个文档的哪一段"。
  2. 不确定性提示：在 Prompt 里要求模型"如果不确定请说不确定"，前端识别"可能"、"大约"、"建议核实"等词汇，用不同样式提示用户该答案置信度较低。
  3. 高风险领域免责声明：医疗、法律、金融领域，在 AI 回答上方固定展示"以下内容由 AI 生成，仅供参考，请咨询专业人士"。
  4. 关键操作二次确认：AI 生成的 SQL、代码、配置文件在执行前展示预览并需要用户确认，防止幻觉导致不可逆操作。
  5. 反馈机制：提供"这个回答有误"的反馈按钮，收集错误案例。这些数据可以用于 RLHF 训练的负样本。
  6. 限定 AI 能力边界：在 UI 上明确告诉用户"该助手专注于 xx 领域"，通过预期管理减少幻觉的危害。

在项目里的体现：监控看板的"话题偏移"异常对话类型，就是在追踪 AI 没有按设定边界回答的情况；运营看到这类异常后，可以针对性地优化 Prompt 约束。

附：面试时项目介绍的推荐顺序

介绍项目时，建议按这个逻辑组织语言

plain 
1. 背景（为什么做这个）     ← 30秒，让面试官理解业务价值
2. 我负责什么              ← 10秒，明确你的角色
3. 技术上最难的一个点       ← 60秒，重点展开，说清楚问题→方案→效果
4. 结果数据                ← 20秒，用数字说话
5. 留一个钩子              ← 5秒，让面试官有想追问的点

示例（AI标注平台Canvas部分）

"图片标注这个模块，技术上最难的是 Canvas 标注引擎的性能问题。

初版上线后，当一张图片有几百个标注框的时候，帧率掉到 30fps，标注员用起来很卡顿。

我排查下来发现是 Fabric.js 默认每次添加对象都触发全量重绘，鼠标移动时也是全量重绘。

我分三步优化：第一步关掉自动渲染改为手动控制；第二步分离鼠标移动和抬起的渲染时机；第三步对静止对象做离屏缓存。

最终帧率稳定在 60fps，标注员反馈流畅很多。

这个优化上线后，日均标注量从 5500 条提升到 8000 条，效率提升了约 45%。"

这个顺序让面试官听完就有想追问"第二步分离渲染时机是怎么做的"的冲动，比你平铺直叙讲功能有效得多。