AI 应用前端工程师 · 上海 · 5 年经验
shenmubai@example.com · 138 0000 0000 · github.com/shenmubai
个人优势
- 5 年前端经验，近 2 年负责企业知识问答与文档助手，关注流式交互、引用可追溯、失败恢复和用户信任
- 能和模型、检索、后端团队一起定义事件协议，文本、引用、工具调用、错误分事件处理，而不是只拼接文字
- 流式交互细节处理完整：可取消、迟到片段丢弃、超时与断网分开提示、原问题可重试
- 长对话性能做过治理：消息虚拟化、Markdown 增量渲染、代码块延迟高亮，上千条消息下滚动依然流畅
- 重视引用的可信度：引用卡带文档名、更新时间和段落定位，打开前重新校验权限，无权限不泄露摘要
- 做过文档上传与解析链路：分片上传、失败单文件重试、加密 PDF 和扫描件给出明确原因
- 会用数据迭代 AI 功能：记录「上传 → 可检索 → 首次提问」漏斗，改进等待说明后首次提问转化提升约 8 个百分点
- 熟悉 AI 功能的测试方法，维护流式测试样例（空回答、乱序事件、重复结束、工具失败、超长代码块）
- 有前端安全意识，修复过搜索高亮拼接 HTML 带来的 XSS，模型输出一律按不可信内容渲染
- 会写 Node.js 服务，能自己搭 SSE 网关和简单的检索接口，和后端讨论方案时能看到全链路
- 技术栈：React、Next.js、TypeScript、SSE 流式输出、状态机、Vitest、Playwright
工作经历
某企业协作公司 · AI 应用前端工程师
负责企业知识助手，产品连接文档库、工单和会议纪要，面向约 300 家企业客户。前端 5 人，与检索和模型团队共用一套问题反馈看板。
- 流式交互：早期回答断流后只显示“失败”，用户需要重新提问。和后端约定消息 ID、序号与终止原因，前端缓存已收到的段落并支持续传；网络抖动下的回答丢失反馈从每周十余件降到 2 件以内
- 引用定位：用户反馈“答案像是编的”，无法核对来源。设计答案中的段落引用卡，点击跳转文档对应位置，权限不足时明确提示；抽样评估中，可追溯回答占比从约 55% 提升到 90%
- 长对话性能：大型工单会话包含大量表格与代码块，重新渲染整个列表导致输入卡顿。按消息分片维护状态，长列表做虚拟化，Markdown 解析结果缓存；100 条消息的会话中输入响应保持在 100ms 左右
- 上传体验：文档导入可能需要数分钟，原页面只显示旋转图标。按上传、解析、索引三个阶段显示状态和失败原因，允许取消与重试；由于重复上传造成的客服工单下降约一半
- 质量闭环：差评时收集问题类型、引用是否正确和匿名 traceId，避免上传原文到埋点。每周和检索团队复盘高频问题，先修权限与检索噪声，再讨论提示词调整
某在线办公公司 · 前端开发工程师
负责文档编辑器和搜索页，产品日活约 6 万，前端小组 7 人。
- 将搜索结果按文档、评论和附件分组，关键词高亮仅对可信文本节点处理，修复直接拼接 HTML 带来的 XSS 风险
- 为编辑器引入操作日志与断网暂存；弱网环境下保存失败时明确展示“仅在本机”，避免用户误以为已同步
- 对大型文档的目录和评论侧栏做按需渲染，浏览器内存占用下降约三成，长文档滚动明显更顺畅
项目经历
企业知识问答工作台
React / TypeScript / SSE / TanStack Query / Playwright
用户可在同一对话里提问企业知识库、引用文档并发起后续操作。实际难点是权限、慢任务与不确定的模型结果。
- 前端按事件类型处理文本、引用、工具开始、工具完成和错误；显示正在做什么，但不把内部模型推理过程当成可验证事实展示
- 请求支持 AbortController 取消；取消后不再拼接迟到的流片段。超时与网络断开分开提示，用户可在原问题上重试
- 引用卡带文档名称、更新时间与段落定位，链接在打开前重新检查权限；无权限时不泄露摘要
- 和测试制定可重复的流式测试样例：空回答、乱序事件、重复结束、工具失败和超长代码块；上线前灰度 10% 客户观察断流与负反馈比例
AI 文档导入与审阅
Next.js / React / TypeScript / Web Worker
客户一次上传几十份资料，解析、切块、索引在服务端异步执行；前端需说明每份文档的可用状态。
- 上传前做大小、扩展名和文件头检查；超大文件分片传输，单文件失败可重试而不影响其他文件
- 大量文件的状态更新按帧合并，列表只渲染可视区；上传 100 份文档时界面仍能响应取消与筛选
- 解析失败给出具体原因，如加密 PDF、扫描件无法识别、权限不足；上传完成后引导用户用引用预览确认索引内容
- 记录“开始上传→可检索→首次提问”的转化漏斗，发现多数流失发生在索引等待阶段，改进进度说明后首次提问转化率提升约 8 个百分点
对话消息渲染引擎
React / Markdown AST / Shiki / Web Worker
长对话里模型会输出表格、公式和长代码块，原来每收到一个流片段就整段重新解析 Markdown，几十轮之后输入框都开始卡。
- 改为增量解析：只重新解析最后一个未闭合的块，已完成的块缓存渲染结果
- 代码高亮放到 Worker 里异步完成，流式输出时先显示纯文本，结束后再替换为高亮版本
- 消息列表虚拟化，只渲染可视区附近的消息；一千条消息的会话里滚动和输入都保持流畅
- 模型输出统一经过白名单清洗再渲染，链接打开前提示外部地址