工作经历

公司做企业级数据分析 SaaS，400 多家企业客户在用。我在 5 人前端组，负责看板、报表和权限三个模块。

• Vue 2 迁移 Vue 3：项目 600 多个组件，不能停下业务需求整体重写。先接入 @vue/compat 让项目在 Vue 3 下跑起来，再按模块逐个消除兼容层警告，Vuex 逐步换成 Pinia；两个月迁完，期间正常发版。构建换成 Vite 后本地冷启动从 40 多秒降到 5 秒，热更新基本即时
• 业务组件沉淀：把表格（列配置、分页、批量操作）、筛选栏、弹窗表单等反复写的模式封装成组件，配 Storybook 文档和示例；新做一个标准列表页从两三天缩短到 一天以内
• 错误监控：接入 Sentry，按接口报错、白屏、JS 异常三类配置企业微信告警，并把用户 ID 和租户写进上下文；之前靠客户反馈才知道的问题，现在基本当天就能发现
• 权限改造：原来按钮级权限散落在各个页面的 v-if 里，抽成 v-permission 指令和路由守卫统一处理，权限配置改为后端下发，新增角色不再需要发版

公司给连锁门店提供收银和巡店系统，我在 3 人前端组，负责门店后台和巡店小程序。

• 用 Vue 3 + Element Plus 开发门店后台的商品、库存和报表页面，独立负责了 20 多个页面的交付
• 报表导出原来是前端一次拉全量数据再拼 Excel，数据超过 5 万行浏览器直接卡死。和后端改成异步导出任务 + 下载链接，前端只负责发起和轮询进度
• 用 uni-app 开发巡店小程序（门店检查表、拍照上传、整改跟踪），门店地下室信号差，检查结果先存本地，联网后自动补交

项目经历

Vue 3 / TypeScript / ECharts / Pinia / Web Worker

客户在页面上自由组合图表、筛选维度来搭建自己的分析看板，一个看板通常有 10 到 20 个图表，单个图表的原始数据可能上万行。

• 主线程卡顿：维度切换时前端要对原始数据重新聚合（分组、求和、同比），放在主线程里一次要算 1 秒多，页面会卡住。把聚合计算移到 Web Worker，用 Transferable 传 ArrayBuffer 避免拷贝，主线程只负责渲染，切换维度时页面不再卡顿
• 图表配置化：设计看板的 JSON 配置（数据源、指标、维度、图表类型、样式），运营在界面上配置后保存，渲染端按配置生成 ECharts option；常规的看板需求不再需要前端排期
• 自适应：大屏模式和嵌入第三方页面时容器尺寸会变，统一用 ResizeObserver 监听容器并节流调用 resize，修复了全屏切换后图表尺寸错乱的问题
• 按需加载：20 个图表同时请求会把接口打满，改为视口内的图表先加载，其余进入视口时再请求，首屏接口数从 20 个降到 6 个左右

Vue 3 / JSON Schema / Monaco Editor / AJV

公司内部 OA 的审批表单原来每个都手写页面，引擎上线后用配置生成，目前承载 60 多个审批表单。

• 基于 JSON Schema 扩展表单协议，加入 x-component、x-reactions 字段描述组件类型和联动规则，联动按依赖图计算，避免循环触发
• 提供拖拽配置和源码编辑两种模式，源码模式用 Monaco Editor，接入 Schema 校验和字段名自动补全
• 校验规则前后端共用一份 Schema（前端 AJV、后端同样的 Schema 校验），避免前后端校验不一致
• 表单字段超过 100 个时输入明显卡顿，排查发现每次输入都触发整张表单的联动计算。改成只重算依赖当前字段的节点，输入恢复流畅

uni-app / Vue 3 / IndexedDB 兼容层

覆盖 300 多家门店的店长和督导，每天提交检查表 2000 份左右。

• 离线提交：检查结果和照片先写本地队列，联网后按顺序补交，重复提交用检查单 ID 做幂等；上线后「提交失败」相关的反馈基本消失
• 图片处理：一份检查表最多 30 张照片，拍照后本地压缩并加水印（门店、时间、定位），单张从 4MB 左右降到 300KB，上传耗时缩短到原来的五分之一左右
• 分包：报表和历史记录页移出主包，主包控制在 1.2MB 以内，首次打开时间明显缩短

个人优势

• 5 年前端经验，近 2 年负责企业知识问答与文档助手，关注流式交互、引用可追溯、失败恢复和用户信任
• 能和模型、检索、后端团队一起定义事件协议，文本、引用、工具调用、错误分事件处理，而不是只拼接文字
• 流式交互细节处理完整：可取消、迟到片段丢弃、超时与断网分开提示、原问题可重试
• 长对话性能做过治理：消息虚拟化、Markdown 增量渲染、代码块延迟高亮，上千条消息下滚动依然流畅
• 重视引用的可信度：引用卡带文档名、更新时间和段落定位，打开前重新校验权限，无权限不泄露摘要
• 做过文档上传与解析链路：分片上传、失败单文件重试、加密 PDF 和扫描件给出明确原因
• 会用数据迭代 AI 功能：记录「上传 → 可检索 → 首次提问」漏斗，改进等待说明后首次提问转化提升约 8 个百分点
• 熟悉 AI 功能的测试方法，维护流式测试样例（空回答、乱序事件、重复结束、工具失败、超长代码块）
• 有前端安全意识，修复过搜索高亮拼接 HTML 带来的 XSS，模型输出一律按不可信内容渲染
• 会写 Node.js 服务，能自己搭 SSE 网关和简单的检索接口，和后端讨论方案时能看到全链路
• 技术栈：React、Next.js、TypeScript、SSE 流式输出、状态机、Vitest、Playwright

工作经历

负责企业知识助手，产品连接文档库、工单和会议纪要，面向约 300 家企业客户。前端 5 人，与检索和模型团队共用一套问题反馈看板。

• 流式交互：早期回答断流后只显示“失败”，用户需要重新提问。和后端约定消息 ID、序号与终止原因，前端缓存已收到的段落并支持续传；网络抖动下的回答丢失反馈从每周十余件降到 2 件以内
• 引用定位：用户反馈“答案像是编的”，无法核对来源。设计答案中的段落引用卡，点击跳转文档对应位置，权限不足时明确提示；抽样评估中，可追溯回答占比从约 55% 提升到 90%
• 长对话性能：大型工单会话包含大量表格与代码块，重新渲染整个列表导致输入卡顿。按消息分片维护状态，长列表做虚拟化，Markdown 解析结果缓存；100 条消息的会话中输入响应保持在 100ms 左右
• 上传体验：文档导入可能需要数分钟，原页面只显示旋转图标。按上传、解析、索引三个阶段显示状态和失败原因，允许取消与重试；由于重复上传造成的客服工单下降约一半
• 质量闭环：差评时收集问题类型、引用是否正确和匿名 traceId，避免上传原文到埋点。每周和检索团队复盘高频问题，先修权限与检索噪声，再讨论提示词调整

负责文档编辑器和搜索页，产品日活约 6 万，前端小组 7 人。

• 将搜索结果按文档、评论和附件分组，关键词高亮仅对可信文本节点处理，修复直接拼接 HTML 带来的 XSS 风险
• 为编辑器引入操作日志与断网暂存；弱网环境下保存失败时明确展示“仅在本机”，避免用户误以为已同步
• 对大型文档的目录和评论侧栏做按需渲染，浏览器内存占用下降约三成，长文档滚动明显更顺畅

项目经历

React / TypeScript / SSE / TanStack Query / Playwright

用户可在同一对话里提问企业知识库、引用文档并发起后续操作。实际难点是权限、慢任务与不确定的模型结果。

• 前端按事件类型处理文本、引用、工具开始、工具完成和错误；显示正在做什么，但不把内部模型推理过程当成可验证事实展示
• 请求支持 AbortController 取消；取消后不再拼接迟到的流片段。超时与网络断开分开提示，用户可在原问题上重试
• 引用卡带文档名称、更新时间与段落定位，链接在打开前重新检查权限；无权限时不泄露摘要
• 和测试制定可重复的流式测试样例：空回答、乱序事件、重复结束、工具失败和超长代码块；上线前灰度 10% 客户观察断流与负反馈比例

Next.js / React / TypeScript / Web Worker

客户一次上传几十份资料，解析、切块、索引在服务端异步执行；前端需说明每份文档的可用状态。

• 上传前做大小、扩展名和文件头检查；超大文件分片传输，单文件失败可重试而不影响其他文件
• 大量文件的状态更新按帧合并，列表只渲染可视区；上传 100 份文档时界面仍能响应取消与筛选
• 解析失败给出具体原因，如加密 PDF、扫描件无法识别、权限不足；上传完成后引导用户用引用预览确认索引内容
• 记录“开始上传→可检索→首次提问”的转化漏斗，发现多数流失发生在索引等待阶段，改进进度说明后首次提问转化率提升约 8 个百分点

React / Markdown AST / Shiki / Web Worker

长对话里模型会输出表格、公式和长代码块，原来每收到一个流片段就整段重新解析 Markdown，几十轮之后输入框都开始卡。

• 改为增量解析：只重新解析最后一个未闭合的块，已完成的块缓存渲染结果
• 代码高亮放到 Worker 里异步完成，流式输出时先显示纯文本，结束后再替换为高亮版本
• 消息列表虚拟化，只渲染可视区附近的消息；一千条消息的会话里滚动和输入都保持流畅
• 模型输出统一经过白名单清洗再渲染，链接打开前提示外部地址

教育经历

工作经历

智能服务组负责客服和运维两条线的 Agent，团队 6 人（算法 2、工程 3、产品 1），服务约 1200 家企业客户。

• 工单 Agent：客服要在 5 个系统之间来回查订单、配额和告警记录。把查询拆成 9 个只读工具，Agent 负责规划调用顺序并汇总结论，写操作只生成待确认草稿。上线半年，一线客服平均处理时长从 14 分钟降到 6 分钟
• 检索质量：早期按固定 512 字切块，表格和步骤说明经常被切断。改为按文档结构切分，标题路径写进块的元数据，再加一层重排；评测集上答案引用正确率从 62% 提到 87%
• 评测体系：从线上差评和人工抽检里整理 600 条问题，按场景、难度和期望工具链路标注。搭建自动评分脚本，模型裁判与人工打分的一致率约 85%，每次发布前回归一遍，两次拦下了换模型后的效果回退
• 成本与延迟：简单问答走小模型，多步排查才走大模型；检索结果按文档版本缓存。首字时间 P50 从 3.1 秒降到 1.4 秒，月度模型费用下降约 40%
• 安全：工具调用按当前登录用户的权限执行，跨租户查询在网关层拦截；对文档里夹带的“忽略以上指令”类内容做过专项测试，相关用例纳入评测集

负责消息通知和开放平台，日均推送约 3000 万条，后端 8 人。

• 把通知服务从同步调用改为消息队列 + 重试 + 死信，渠道故障时消息不丢，高峰期接口 P99 从 1.2 秒降到 180ms
• 开放平台接口统一签名、限流和审计日志，第三方调用异常的定位时间从半天缩短到 20 分钟以内
• 2023 年起参与内部知识库问答的原型，负责文档同步和权限过滤，这段经历让我转到大模型应用方向

项目经历

Python / LangGraph / FastAPI / Prometheus API / OpenTelemetry

值班工程师收到告警后要查指标、日志、最近发布记录，平均 25 分钟才能给出初步判断。

• 用状态图描述排障流程：先确认影响面，再按服务依赖查指标和日志，最后对照最近变更给出怀疑点，每一步都可以人工跳过或改写
• 每个工具调用记录输入、输出和耗时，整条链路接入 OpenTelemetry，值班同学能看到 Agent 查了什么、依据是什么
• 结论必须附上指标截图链接和日志片段，没有证据的推断标注为“待确认”；内部试用三个月，初步定位时间中位数降到 8 分钟

PostgreSQL / pgvector / Elasticsearch / Rerank

• 向量召回和关键词召回各取前 30 条，合并去重后重排取前 6 条，型号、错误码这类精确词靠关键词召回兜底
• 文档更新后只重建变化的块，全量 4 万篇文档的增量同步从每晚 3 小时缩短到 10 分钟级
• 对“查不到”的问题单独统计，每周把高频缺失内容反馈给文档团队，三个月内无答案比例从 18% 降到 7%