先看一份完整简历，再动笔

工作经历

智能服务组负责客服和运维两条线的 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%

个人优势

• 5 年前端经验，前 3 年做电商中后台，近 2 年负责公司 AI 助手的前端，从对话界面、工具调用过程展示到人工确认交互都由我设计和实现
• 熟悉 Agent 产品里前端特有的问题：流式渲染的稳定性、断线续传、多步任务的过程可视化、中断与重新生成、模型草稿的编辑与采纳
• 做过生成式界面：模型返回结构化数据，前端按类型渲染成表格、卡片和可操作表单，而不是只显示一段 Markdown
• 用前端性能的方式度量 AI 体验：首字时间、渲染卡顿、回答完整率、等待放弃率都有埋点和看板，每次改版前后对比
• 和后端、算法同学协作时负责定义前后端的流式协议和事件格式，工具编排和模型调用由后端负责
• 前端工程基本功扎实：组件库、性能优化、监控告警、端到端测试都做过
• 技术栈：TypeScript、React、Next.js、Vercel AI SDK（前端部分）、SSE、Zustand、TanStack Query、Tailwind CSS、Playwright、Sentry

工作经历

AI 助手组 7 人（算法 2、后端 2、前端 2、产品 1），助手嵌在公司的 CRM 产品里，服务约 3000 家企业客户。我负责助手前端，是前端方向的负责人。

• 工具调用过程可视化：助手回答前要查客户、订单、合同等多个系统，早期用户只能对着加载动画等 10 多秒。和后端约定步骤事件格式，把每一步以卡片形式流式展示查询对象和中间结果；等待期间的放弃率从 31% 降到 12%
• 流式渲染：长回答里表格和代码块在流式过程中频繁抖动，长对话滚动明显卡顿。改为按块增量解析、未闭合的结构先占位，长列表虚拟化；200 轮以上的对话滚动帧率稳定在 55 帧以上，渲染相关的用户反馈基本消失
• 断线续传：销售常在手机上使用，网络切换时回答会中断。前端记录已收到的事件序号，重连后从断点续传，移动端回答完整率从 88% 提高到 99%
• 人工确认与草稿编辑：改客户阶段、发跟进邮件这类写操作，模型只生成草稿。设计了「草稿卡片 → 编辑 → 确认」的交互，用户可以逐字段修改后再提交；草稿采纳率约 64%，没有出现未经确认就执行的写操作
• 体验度量：搭建 AI 功能的前端埋点和看板，首字时间、完整率、重新生成率、放弃率按版本对比，产品和算法同学据此判断改动效果

商家后台组 9 人，负责商品、订单和营销三个模块的前端。

• 主导商品发布页重构，200 多个字段的单页表单拆成分步表单，配合草稿自动保存，商家发布商品的平均耗时从 12 分钟降到 5 分钟
• 搭建前端监控，接入错误、性能和接口耗时数据，线上问题从商家反馈到定位的时间从半天缩短到 30 分钟以内
• 负责团队组件库的表格和表单组件，被 4 条业务线使用；2023 年参与内部客服问答原型的对话界面，之后转到 AI 助手方向

项目经历

React / Next.js / Vercel AI SDK / SSE / Playwright

销售每天要在 CRM 里翻聊天记录、合同和工单才能写出跟进计划，纯文字回答还要再手动整理进系统。

• 和后端约定结构化输出的 schema：客户风险、跟进建议、邮件草稿分别返回，前端渲染成风险卡片、可勾选的待办和可编辑的邮件表单
• 每条建议都可以展开查看依据，点击跳转到原始聊天记录或合同条款，没有依据的内容标注为「待确认」
• 用 Playwright 录制 30 条典型对话做端到端回归，模型或接口格式变化导致的渲染问题在发布前就能发现；试点团队 40 名销售使用三个月，单个客户的跟进准备时间中位数降到 4 分钟

教育经历

个人优势

• 6 年 Java 后端经验，前 4 年做支付和账户系统，近 2 年负责把公司的业务能力接入大模型，搭建了 Agent 调用的工具平台和知识检索服务
• 把后端的稳定性经验用到 Agent 上：工具接口有幂等、超时、限流和审计，模型调用有熔断和降级，大模型服务故障时业务流程不受影响
• 熟悉 RAG 工程化：文档解析、切块、向量与关键词混合召回、重排和增量更新，知道召回不准时先排查数据和切块
• 做 Agent 先定边界：查询类操作交给模型规划，涉及资金和权限的操作必须走确定的代码分支并人工确认
• 建过评测与观测体系：离线评测集 + 线上链路追踪，每次提示词、模型或检索策略变更都能看到效果和成本的变化
• 技术栈：Java 17、Spring Boot、Spring AI、LangChain4j、MySQL、PostgreSQL / pgvector、Elasticsearch、Redis、RocketMQ、Kubernetes、OpenTelemetry

工作经历

大模型平台组 8 人，为公司内部客服、风控和运营团队提供 Agent 能力，接入业务系统 20 多个。我负责工具平台和知识检索服务。

• 工具平台：各业务团队原来各自写接口给模型调用，权限和日志都不统一。设计统一的工具注册规范，每个工具声明参数结构、权限范围和是否为写操作，平台统一做鉴权、限流、超时和审计；已接入 140 多个工具，模型调用业务接口的异常定位时间从半天缩短到 15 分钟
• 写操作安全：涉及资金和客户信息修改的工具只生成待审批工单，由业务人员确认后经原有业务流程执行；上线以来没有出现模型直接修改业务数据的情况
• 知识检索服务：客服知识库约 6 万篇文档，原来按固定长度切块，条款类内容经常被切断。改为按文档结构切分并保留标题路径，向量召回和关键词召回合并后重排；评测集上引用正确率从 58% 提高到 86%，文档更新后 10 分钟内可被检索到
• 稳定性：模型服务偶发超时会拖垮调用方线程池。在网关层加入按模型分组的熔断、请求排队和小模型降级，高峰期模型调用的整体成功率从 96.5% 提高到 99.7%
• 评测与观测：和客服质检团队一起整理 800 条标注问题，发布前自动回归；整条 Agent 链路接入 OpenTelemetry，每轮对话的工具调用、耗时和 token 消耗可查

账户组 10 人，负责账户余额、冻结和流水服务，日均交易约 800 万笔。

• 账户余额更新从数据库行锁改为分段账户 + 异步汇总，热点商户账户的入账 TPS 从 600 提升到 3000
• 设计对账补偿任务，处理渠道回调丢失和重复通知，每月人工处理的差错单从 300 多笔降到 20 笔以内
• 参与账户系统迁移，负责双写比对和灰度切流，迁移期间无资金差错

项目经历

Spring AI / LangChain4j / pgvector / Elasticsearch / RocketMQ

客服处理一张投诉工单需要查交易、账户、风控三个系统，平均耗时 18 分钟。

• Agent 只调用只读查询工具汇总交易链路和异常点，退款、解冻等操作生成审批单交给人工处理
• 长任务改为异步执行，通过消息队列回传每一步进度，客服可以同时处理其他工单
• 回答中的每条结论都附查询记录编号，质检抽查时可以复核；上线半年，工单平均处理时长降到 7 分钟，质检差错率没有上升

教育经历

个人优势

• 5 年全栈经验，近两年在创业团队独立负责一款 AI 写作产品的前后端，从 0 做到付费用户 1.2 万
• 前端能做好流式交互：打字机效果、中断续写、多版本对比，长文档编辑时不卡顿
• 后端能搭完整的模型服务层：多厂商模型统一接入、超时降级、按用户计量计费、用量告警
• 会做提示词工程但不迷信提示词，结构化输出用 JSON Schema 约束，失败自动修复或重试
• 做过文件解析和长文本处理：PDF、Word、网页导入，超长内容分段摘要再合并，保留原文出处
• 有产品意识，自己看漏斗和留存数据，改过三版新手引导，次日留存从 21% 提到 34%
• 能独立负责部署和运维：Docker、CI/CD、日志和告警都是自己搭的，线上问题能一个人从前端查到数据库
• 技术栈：TypeScript、Next.js、React、Node.js、Python、FastAPI、PostgreSQL、Redis、Docker、Vercel AI SDK

工作经历

团队 7 人，我是两名工程师之一，负责编辑器、模型服务和支付计费，另一位同事负责移动端。

• 长文生成：一次生成五千字以上时经常超时或前后矛盾。改成先出大纲、用户确认后分节生成，每节带上大纲和前文摘要；生成失败只重试单节。长文完成率从 58% 提到 93%
• 多模型接入：封装统一的模型调用层，三家厂商同一套接口，按任务类型和成本选模型，主模型超时 15 秒自动切备用。厂商故障期间用户侧报错率控制在 1% 以内
• 计量计费：按实际消耗的 token 计费，预扣、结算、退还三步写在一个事务里，并发请求不会扣成负数；接入支付后上线首月对账零差错
• 编辑器体验：AI 改写以修订模式呈现，可以逐段接受或拒绝；流式输出时编辑器只更新最后一个段落，万字文档里输入延迟保持在 50ms 以内
• 增长实验：自己埋点、看漏斗，发现多数新用户卡在“不知道写什么”，加了按场景的模板入口，新用户首次生成率提升约 17 个百分点

负责商家后台和数据报表，前后端都写，团队 10 人。

• 用 Next.js 重写商家报表页，大表格虚拟滚动，报表导出改为后台任务，十万行导出不再拖垮接口
• 设计报表的预聚合表和定时任务，核心报表查询从 6 秒降到 400ms
• 2023 年用 GPT 接口做了商品描述生成的内部工具，试用商家 300 多家，是后来转做 AI 产品的起点

项目经历

Next.js / Tiptap / Vercel AI SDK / FastAPI / PostgreSQL

• 编辑器基于 Tiptap 扩展了 AI 改写、续写、扩写三种节点操作，结果以修订标记插入，撤销栈与普通编辑共用
• 流式结果按段落缓冲后再写入文档，避免逐字写入导致的光标跳动和协同冲突
• 文档历史版本按段落存差异，用户可以对比任意两次 AI 改写的结果

Python / Unstructured / pgvector / Celery

• 支持 PDF、Word、网页链接导入，解析在 Celery 队列里异步执行，前端按阶段显示进度
• 用户写作时可以引用导入的资料，生成内容里的引用带原文段落，点击可以跳回原文
• 扫描件、加密文件给出明确提示，解析失败率从 9% 降到 2%

教育经历

个人优势

• 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 里异步完成，流式输出时先显示纯文本，结束后再替换为高亮版本
• 消息列表虚拟化，只渲染可视区附近的消息；一千条消息的会话里滚动和输入都保持流畅
• 模型输出统一经过白名单清洗再渲染，链接打开前提示外部地址

教育经历

个人优势

• 两段前端实习（电商商家中台、在线教育），能独立完成列表、表单和移动端 H5，改动会配单测和性能数据验证
• JavaScript 基础扎实，能讲清事件循环、原型链、闭包和 this 绑定，手写过 Promise、防抖节流、深拷贝等常见实现
• 读过 React 调度器（Scheduler）和 Vue 3 响应式部分的源码，写过一篇 Fiber 可中断渲染的分析文章，掘金阅读 1.4 万
• 维护开源虚拟滚动表格 react-virtual-table，GitHub 1.2k Star，处理过 40 多个 issue，熟悉 npm 包的构建、发布和语义化版本
• 做过性能优化的完整闭环：先用 Performance 面板和 Lighthouse 定位，再改，再用数据对比，实习中把订单列表首屏图片请求从 80 多个降到 30 个左右
• 熟悉移动端兼容问题，整理过 14 条 iOS / 安卓 WebView 的常见坑和解决方案，被实习团队收进新人文档
• 会写简单的 Node.js 服务，用 Koa + MySQL 给课程项目写过接口，能和后端顺畅对接口
• 习惯写测试和文档：实习期间给 20 多个工具函数补了 Vitest 单测，顺带发现了一个日期时区的线上问题
• 英语 CET-6，能直接阅读 React、Vite 的英文文档和 GitHub issue
• 技术栈：JavaScript、TypeScript、React 18、Vue 3、Zustand、Vite、Webpack、Vitest、Node.js（Koa）、MySQL

实习经历

所在团队负责商家后台（订单、商品、售后），日活商家约 8 万，技术栈 React 18 + TypeScript + Ant Design。

• 参与订单中心重构。原来订单列表、退款列表、发货列表 3 个页面各写了一套筛选表单，逻辑有出入，经常改一处漏两处；我把筛选项抽成配置（字段、组件类型、默认值、联动规则），封装 SearchForm 组件统一渲染，后续新增筛选项只改配置
• 订单列表一页 200 行，每行最多 6 张商品图，首屏图片请求 80 多个，弱网下列表要转好几秒。改为 IntersectionObserver 懒加载，并给图片 URL 拼上 OSS 缩放参数按显示尺寸取图，首屏图片请求降到 30 个左右，图片总流量减少约 70%
• 给金额计算、日期格式化等 20 多个工具函数补了 Vitest 单测，过程中发现一个按 UTC 解析日期导致「下单时间少一天」的线上问题，修复后补了时区相关的用例
• 参与每周的 Code Review，整理了一份团队 React Hooks 常见问题清单（闭包拿到旧值、effect 依赖遗漏、列表 key 用 index 等），被组里拿来做新人文档

• 用 Vue 3 + Vite 开发课程报名 H5，负责报名表单、微信支付回跳和分享海报。海报用 html2canvas 生成，处理了跨域图片导致画布被污染、iOS 上生成的图片模糊（按 devicePixelRatio 放大绘制）两个问题
• 处理 iOS 软键盘弹起遮挡输入框、安卓 WebView 下 100vh 包含地址栏导致底部按钮被挡等兼容问题，整理成团队的移动端兼容问题文档，共 14 条，每条附复现机型和解决方案
• 报名页转化埋点原来只有 PV，补上表单每一步的停留和放弃事件后发现「选择上课时间」一步流失最多，配合产品把时间选择改成默认推荐最近一期，报名转化提升约 8%

项目经历

React / TypeScript / Rollup / Vitest

面向后台场景的高性能表格组件，支持 10 万行数据流畅滚动，npm 周下载量 3000 左右，GitHub 1.2k Star，被两家公司的内部项目使用。

• 动态行高：行高不固定时无法直接算出可视区起点。先用预估高度渲染，再用 ResizeObserver 回填真实高度，维护行高前缀和数组，滚动时二分查找起始行，查找复杂度 O(log n)
• 滚动不白屏：在可视区上下各多渲染一屏作为缓冲，快速拖动滚动条时用 requestAnimationFrame 合并滚动事件，避免一帧内多次重排
• 固定列：左右固定列用 position: sticky 实现，不再拆成三张表同步滚动，代码量和滚动抖动都少了很多
• 工程化：Rollup 同时输出 ESM 和 CJS，配置 exports 字段和类型声明，支持 Tree Shaking；GitHub Actions 跑单测和体积检查，PR 体积增长超过 5% 会提示

React / Canvas / WebSocket / Yjs

三人小组的课程设计，支持多人同时画图、移动和删除图形，我负责画布渲染和协同同步部分，课程评分 优秀。

• 用 Yjs 管理白板数据，多人同时修改同一个图形时由 CRDT 自动合并，不需要自己写冲突处理
• Canvas 分三层绘制（背景网格、图形、选中框），拖动图形时只重绘选中层和图形层，200 个图形下拖动保持 60fps
• 断线重连后用 Yjs 的状态向量只同步缺失的更新，不重新拉全量数据；在弱网模拟下断开 30 秒再恢复，画布内容能正确合并

微信小程序 / 云开发 / TypeScript

和两位同学一起做的校内二手交易小程序，上线一学期注册用户 2600 多人，成交 900 多单。我负责前端和商品搜索。

• 商品列表图片多，低端机上滑动掉帧。用分页加载 + 图片按可视区懒加载，长列表超过 200 条时回收顶部节点，滑动基本不卡
• 发布商品时图片先在本地压缩到 1080 宽再上传，单张从 3~5MB 降到 300KB 左右，上传失败率明显下降
• 搜索在云函数里做分词和同义词扩展（如「自行车」「单车」），无结果率从约三成降到一成左右

教育经历

• GPA 3.7 / 4.0，专业排名前 15%，两次获校级二等奖学金
• 主修课程：数据结构、操作系统、计算机网络、数据库原理、编译原理
• 浙江省大学生服务外包创新应用大赛二等奖（团队前端负责人）

个人优势

• 三年前端开发经验，主要做 B 端 SaaS，负责过看板、报表、权限和审批几个完整模块，能从需求评审跟到上线复盘
• 熟悉 Vue 3 响应式和编译期优化，参与并主导了 600 多个组件从 Vue 2 迁到 Vue 3，迁移期间业务正常发版
• TypeScript 用得比较深，给团队组件库写过泛型表格、泛型表单组件，类型提示能精确到列字段
• 做过大数据量图表的性能优化：把聚合计算挪到 Web Worker，维度切换不再卡顿
• 有表单引擎的实际经验，基于 JSON Schema 做过联动、校验和可视化配置，目前承载公司 60 多个审批表单
• 重视组件沉淀，封装的表格、筛选栏、弹窗表单配了 Storybook 文档，新做一个标准列表页从两三天缩到一天以内
• 能独立写 Node.js 小服务，用 Koa 写过 BFF 接口和文件上传服务，熟悉分片上传和断点续传
• 有线上问题的排查习惯：接入 Sentry 后按接口报错、白屏、JS 异常分类告警，大部分问题当天就能发现
• 做过 uni-app 小程序，熟悉分包、图片压缩和弱网下的离线提交
• 关注可用性细节，组件默认支持键盘操作和错误状态，低配笔记本上也会自测一遍
• 技术栈：Vue 3、Pinia、Element Plus、TypeScript、Sass、Vite、Webpack、Vitest、Storybook、ECharts、uni-app、Sentry

工作经历

公司做企业级数据分析 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 以内，首次打开时间明显缩短

教育经历

个人优势

• 四年前端开发经验，做过社交平台的增长业务和金融 H5，负责过活动搭建平台、监控 SDK 和灰度发布三个基础项目
• 性能治理有完整闭环：用 Web Vitals 真实用户数据定位问题，改完按 P75 指标验收；把拉新落地页 LCP 从 3.4s 降到 1.7s
• 熟悉 React 18 并发特性和 Hooks 原理，用过 Zustand、Redux Toolkit、React Query，能说清它们各自适合的场景
• 有低代码编辑器的设计经验：物料协议、iframe 画布隔离、基于 Immer patch 的撤销重做，平台每月产出 300 多个活动页
• 做过 Monorepo 改造，pnpm workspace + Turborepo 远程缓存，CI 从 20 多分钟降到 7 分钟左右
• 自研过前端监控 SDK（错误、白屏、Web Vitals），压缩后约 4KB，接入公司 30 多个项目
• 熟悉前端发布和回滚：设计过按用户尾号分桶的灰度方案，回滚时间从半小时缩到 1 分钟
• 金融场景经验：支付防重、订单幂等、金额精度、支付回跳状态丢失，支付成功率提升约 2 个百分点
• 能写 Node.js 服务，做过 BFF 和活动页预渲染服务，熟悉 Koa 和 Express
• 推动过团队规范落地：发布前检查清单、体积预算、关键接口降级预案，上线以来大促期间没有 P1 级前端事故
• 技术栈：React 18、Next.js、TypeScript、Zustand、React Query、Tailwind CSS、Vite、Turborepo、Sentry、Node.js、微信小程序

工作经历

所在的增长前端组负责活动、拉新和会员相关页面，组内 8 人。我负责活动搭建平台和核心落地页的性能。

• 活动搭建平台：负责平台的编辑器和物料体系，运营自助搭建活动页，每月产出 300 多个页面，日常运营活动基本不再需要前端开发
• 落地页性能治理：拉新落地页移动端 LCP（P75）长期在 3.4s 左右。用 Performance 面板和 Web Vitals 数据定位到三个原因：首屏大图、同步加载的第三方统计 SDK、首屏外模块打进了主包。分别做了图片换 AVIF 并按设备像素比出图、SDK 改为空闲时异步注入、非首屏模块按需加载，LCP 降到 1.7s，落地页跳出率下降约 15%
• Monorepo 改造：组内 20 多个包原来分散在不同仓库，依赖升级要逐个仓库改。迁到 pnpm workspace + Turborepo，开启远程缓存跳过未改动的包，CI 从 20 多分钟降到 7 分钟左右
• 稳定性：建立落地页发布前的检查清单（体积预算、Lighthouse 分数、关键接口降级），上线以来大促期间没有出现 P1 级前端事故

公司做互联网理财，我在 6 人前端组负责理财购买链路和公共组件。

• 负责理财产品购买和赎回 H5。统计支付失败原因后发现，重复点击和支付回跳丢失状态占了大头，补上按钮防重、订单号幂等和支付结果轮询兜底，支付成功率提升约 2 个百分点
• 设计前端灰度发布方案：静态资源按版本号上传 CDN，入口 HTML 由网关按用户尾号分桶下发，出问题时修改网关配置即可切回上个版本，回滚时间从 半小时缩短到 1 分钟
• 参与公共组件库建设，负责金额输入、验证码、协议勾选等金融场景组件，统一了键盘、精度和防重的处理

项目经历

React / TypeScript / Zustand / Node.js / iframe

面向运营的低代码平台，通过拖拽物料、配置属性和数据源来搭建活动页，发布后生成静态页面上线。

• 物料协议：设计物料协议，包含属性 Schema、事件和数据源三部分，业务组件按协议注册即可在编辑器中拖拽和配置；目前平台有 120 多个物料，由 3 个业务团队共同维护
• 样式隔离：早期画布和编辑器在同一个文档里，物料的全局样式会影响编辑器界面。改为画布放进 iframe，主窗口和画布之间通过 postMessage 同步页面配置和选中状态
• 撤销重做：页面配置用不可变数据管理，每次修改记录 patch（Immer），撤销重做只需要应用反向 patch，长时间编辑内存也比较稳定
• 发布链路：发布时用 Node.js 把页面配置预渲染成静态 HTML 上传 CDN，和原来的 SSR 方案相比少了一次服务端渲染，大促流量高峰时不会给服务端增加压力

TypeScript / Rollup / Performance API

团队自研的监控 SDK，接入了公司 30 多个前端项目，数据进公司的日志平台做告警和看板。

• 采集 JS 错误、Promise 未处理异常、资源加载错误、接口错误、白屏和 Web Vitals 指标，SDK 压缩后约 4KB
• 白屏检测：页面加载后在视口内取若干采样点，用 elementsFromPoint 判断是否只有容器节点，连续多次为空判定为白屏
• 上报做了采样、批量合并和页面关闭时 sendBeacon 兜底，上报请求量比逐条上报减少约 90%
• 错误按「消息 + 堆栈首帧」做指纹聚合，配合 Source Map 在后台还原源码位置，同一个问题不再刷屏告警

Node.js / Nginx / CDN / 网关配置中心

理财 H5 每次发版都是全量上线，出问题只能重新打包回滚，最长一次影响了 40 分钟交易。

• 静态资源按版本号目录上传 CDN 且永不覆盖，入口 HTML 不缓存，由网关根据用户尾号决定返回哪个版本的入口
• 发布流程拆成「1% → 10% → 50% → 全量」四档，每档观察监控大盘的错误率和支付成功率，异常时一键切回
• 上线一年，期间拦下 3 次有问题的版本，影响用户都控制在 1% 灰度范围内

React / Rollup / Babel / Storybook

• 沉淀 30 多个金融场景组件（金额输入、安全键盘、验证码、协议勾选、风险测评），统一了精度、防重和无障碍处理
• 组件库原来整包引入，接入方页面平白多出 200KB 的代码。改为每个组件独立入口并声明 sideEffects，配合 Tree Shaking 实现按需引入，典型页面减少约 150KB（gzip 前）
• 金额输入统一用整数分计算和展示时格式化，避免浮点误差；补齐边界单测（大额、负数、粘贴带逗号的数字）

教育经历

个人优势

• 八年前端经验，近四年带 12 人团队，负责云控制台前端（40 多个云产品），主导过微前端拆分、设计系统和质量体系三项基础建设
• 架构上能从团队协作反推技术方案：把巨石控制台拆成微前端，发布从每周一次的全员协调变成各产品按需独立发布
• 熟悉 qiankun 和 Module Federation 的原理与取舍，处理过沙箱样式泄漏、共享依赖版本冲突、子应用预加载等实际问题
• 推动过跨职能的设计系统：设计规范、Design Token、组件库、Figma 组件四件套，覆盖 6 条产品线
• 建立前端质量门禁（单测覆盖率、体积预算、Lighthouse、接口契约检查）和值班机制，线上故障数同比下降约 60%
• 移动端有深度经验：设计过 Hybrid 离线包方案，命中率 96%，司机端页面秒开率从六成多提到九成以上
• 熟悉编译工具链，写过 Babel 插件和 ESLint 规则，用 codemod 批量完成过 2000 多个文件的组件库大版本升级
• 能写服务端：用 NestJS 做过 BFF 和研发效能平台，熟悉 Docker 和 Kubernetes 上的部署与灰度
• 带人有方法：建立技术方案评审、Code Review 和季度分享机制，两年内 4 人晋升，核心成员没有流失
• 保持一线编码，每个季度至少负责一个关键模块的实现，技术判断不脱离代码
• 技术栈：React 18、Vue 3、Next.js、TypeScript、qiankun / Module Federation、Webpack、Vite、Playwright、Node.js（NestJS）、Docker / Kubernetes

工作经历

负责云控制台前端，控制台承载计算、存储、网络等 40 多个云产品，由各产品团队共同开发。

• 微前端架构：控制台原来是一个巨石应用，任何一个产品发版都要全量构建，一次发布要协调所有团队，构建一次 20 多分钟。主导拆分为微前端，各产品独立开发、独立发布，发布频率从每周一次变为按需随时发布
• 设计系统：推动设计和前端共建设计系统（设计规范、Design Token、组件库、Figma 组件），覆盖 6 条产品线；组件库作为唯一的 UI 基础，表单、表格等交互在各产品间保持一致
• 质量保障：建立前端质量门禁（单测覆盖率、包体积预算、Lighthouse 分数、接口契约检查），接入线上监控和值班机制，控制台前端线上故障数同比下降约 60%
• 团队管理：管理 12 人团队，负责招聘、技术规划和绩效。建立技术方案评审、Code Review 和季度技术分享机制；两年内团队有 4 人晋升，核心成员没有流失

司机端前端组，负责司机 App 内的 H5 页面和运营后台，组内 9 人。

• Hybrid 性能优化：司机端大量页面是 App 内嵌 H5，弱网下打开很慢。设计离线包方案，页面秒开率从约 六成提升到九成以上（详见项目经历）
• 前端 BFF：司机端一个页面要调五六个后端接口，字段多且冗余。设计 Node.js BFF 层统一做鉴权、接口聚合和字段裁剪，前端调用的接口数减少约三分之一，首屏接口耗时明显下降
• 负责司机端前端技术栈从 jQuery 迁移到 React，制定迁移规范和公共组件，新老页面并行运行半年后完成切换

项目经历

qiankun / Module Federation / React / TypeScript

• 主子应用职责划分：主应用负责登录态、顶部导航、菜单、权限和公共布局，子应用通过约定的生命周期接入，只关心自己的业务页面
• 应用间通信：全局状态只向子应用暴露只读快照和事件通道，子应用之间不允许直接引用，避免出现隐式耦合导致无法独立发布
• 依赖共享：React、组件库等公共依赖通过 Module Federation 共享，子应用平均产物体积减少 四成多；共享依赖的版本由主应用统一管理，升级时有兼容性检查
• 加载体验：按菜单点击热度预加载子应用资源，子应用加载失败时展示降级页并上报；子应用切换耗时从 1 秒多降到 300ms 左右

React / Design Token / Storybook / Figma / Playwright

6 条产品线原来各有一套组件，同样是表格，筛选和分页的交互各不相同，客户在产品间切换要重新适应。

• 和设计团队一起定义 Design Token（颜色、间距、圆角、字号），Figma 和代码共用一份 Token 源文件，改一次两边同步
• 组件库 80 多个组件，每个组件配 Storybook 文档和 Playwright 截图回归，视觉改动在 PR 里就能看到对比
• 制定组件的废弃和迁移流程：新版本发布时附 codemod，旧 API 保留两个大版本并在控制台打印迁移提示
• 一年内 6 条产品线全部切到新组件库，设计验收中「交互不一致」类问题减少了大半

React / Node.js / CDN / JSBridge

• H5 资源打包后随 App 启动预下载，WebView 请求时优先命中本地资源，未命中再回源
• 支持增量更新（按文件哈希差分）和版本回退，出问题时服务端下发回退指令，不需要发 App 版本
• 离线包命中率 96%，页面秒开率从约六成提升到九成以上，弱网下页面打开失败的投诉明显减少

Node.js / NestJS / GitLab CI / Docker

• 统一脚手架、代码规范、发布流水线和质量门禁，新项目从创建到第一次上线只要 半天
• 提供构建产物分析和依赖升级看板，按团队展示包体积变化和过期依赖，推动各团队定期治理
• 用 Babel 插件写了一批 codemod，批量完成组件库大版本升级中的 API 迁移，改动 2000 多个文件

教育经历

个人优势

• 五年全栈开发经验，在 6 人技术团队里负责前端和一半后端服务，能独立把一个功能从页面、接口、数据库做到部署上线
• 熟悉 Next.js App Router，理解 SSR、SSG、ISR 和 RSC 的区别，用它重写官网和文档后自然搜索流量涨到原来的 2 倍多
• 后端以 NestJS + PostgreSQL + Redis 为主，排查过慢查询、索引失效和缓存一致性问题，核心接口 P95 从 800ms 左右降到 120ms
• 做过多租户 SaaS 的数据隔离和权限模型（角色 + 数据范围），前后端共用一份权限定义
• 熟悉异步任务和队列，用 BullMQ 改造过万行级 Excel 导入导出，失败行可下载错误报告
• 有数据库变更的安全习惯：加字段 → 双读 → 回填 → 删旧字段，发布前在预发用脱敏数据验证迁移耗时
• 负责过部署体系：GitHub Actions 构建镜像 + 蓝绿发布 + 健康检查，发布用户无感，异常可秒级切回
• 做过日志检索服务，把按天扫文件改为写入 ClickHouse，常用查询从分钟级降到秒级
• 落地过 RAG 客服助手（文档切片、pgvector 检索、SSE 流式输出），上线三个月人工工单减少约三分之一
• 关注成本，梳理云资源后把低频计算改为定时任务、数据库读写分离，服务器成本下降约 30%
• 技术栈：Next.js、React、TypeScript、Tailwind CSS、NestJS、Prisma、PostgreSQL、Redis、ClickHouse、Docker、GitHub Actions、pgvector / RAG

工作经历

公司做中小企业客户管理系统，技术团队 6 人，我负责前端和一半的后端服务，产品服务 300 多家企业客户。

• 官网和文档重构：官网和帮助文档原来是客户端渲染，搜索引擎收录很差，用 Next.js 重写（详见项目经历），半年内官网自然搜索流量增长到原来的 2 倍多
• 多租户数据隔离：所有业务表带租户字段，在 ORM 层统一注入租户条件，查询时如果漏了租户条件直接报错，从机制上避免数据串号
• 部署和运维：从手动登录服务器部署改为 GitHub Actions 构建镜像 + 蓝绿发布，健康检查通过后再切流量，发布过程用户无感；接入日志和告警，常见故障有对应的排查手册
• 成本控制：梳理云资源用量，把低频的报表计算改为定时任务，数据库按读写分离调整规格，服务器成本下降约 30%

游戏运营平台组，前后端共 5 人，支撑公司 3 款游戏的日常运营。

• 开发游戏运营后台（活动配置、礼包发放、玩家查询、数据报表），用 React + Ant Design Pro 搭建
• 礼包发放原来由运营填表、后端手动执行脚本，改为后台可视化配置 + 审批，发放出错的情况基本消失
• 运营查询玩家行为日志要等几分钟，用 Node.js 写了日志检索服务（详见项目经历），常用查询从 分钟级降到秒级

项目经历

Next.js / NestJS / PostgreSQL / Redis / BullMQ / Docker

• 接口性能：客户列表在大客户（几十万条数据）那里经常超时。通过慢查询日志定位问题，补了联合索引，计数改为异步更新的统计表，热点数据加 Redis 缓存并在写入时主动失效；核心接口 P95 从 800ms 左右降到 120ms
• 异步任务：Excel 导入导出原来是同步接口，万行级数据经常超时。改为 BullMQ 任务队列，前端轮询进度，失败的行生成错误报告供用户下载修改
• 权限模型：设计基于角色和数据范围的权限模型（本人、本部门、全公司），前后端共用一份权限定义，前端按钮和后端接口校验保持一致
• 发布回滚：数据库变更采用先加字段、代码双读、数据回填、最后删除旧字段的顺序；一次租户配置异常在健康检查阶段被发现，直接切回上一版镜像，没有让客户看到错误页面

Node.js / SSE / pgvector / 大模型 API

• 帮助文档按标题层级切片，向量化后写入 pgvector；用户提问时先检索相关片段，再交给大模型生成回答，答案附文档出处链接
• 回答用 SSE 流式输出，首字时间 1 秒左右；对检索不到的问题记录下来，作为补充文档的依据
• 检索结果按相似度设门槛，低于门槛直接转人工，不让模型凭空回答；上线三个月后，人工客服工单减少约 三分之一

Next.js App Router / MDX / Vercel OG

• 文档用 MDX 写，构建时静态生成，内容更新后按需再验证（ISR），不用整站重新构建
• 补齐页面标题、描述、结构化数据和站点地图，每篇文档自动生成分享卡片图
• 文档搜索用构建期生成的倒排索引，在浏览器端检索，不依赖第三方服务；首屏 LCP 稳定在 1.2s 左右

Node.js / ClickHouse / Kafka

• 游戏服务器的玩家行为日志原来按天落文件，运营查一个玩家一周的记录要扫 7 个大文件，耗时几分钟
• 改为日志经 Kafka 写入 ClickHouse，按玩家 ID 和时间建排序键，支持按玩家、事件类型、时间范围组合查询
• 常用查询从分钟级降到 1 秒以内，运营排查玩家投诉的效率明显提升；存储按月分区，过期数据自动清理

教育经历

个人优势

• 三年跨端前端经验，负责本地生活平台的微信、支付宝、抖音三端小程序，合计日活约 50 万
• 推动三端代码用 Taro 统一，从新页面开始渐进迁移，现在大部分需求只开发一次
• 小程序性能有实战：重新划分分包、预下载、setData 只传变化字段，主包从接近 2MB 降到 1.1MB，冷启动减少约四成
• 熟悉三端在登录、支付、分享、定位上的差异，封装了统一适配层，业务代码不再写平台判断
• 参与 React Native 下单链路开发，处理过长列表、图片解码和低端安卓机卡顿
• 弱网和异常流程考虑得比较细：支付回跳状态不一致、重复点击、超时，分别有幂等和提示策略
• 沉淀 40 多个跨端组件，每个组件附三端截图对比，组件改动自动做视觉回归
• 熟悉 H5 与原生之间的 JSBridge 通信，处理过 WebView 生命周期、权限状态刷新等兼容问题
• 有真机回归习惯，和测试一起整理了 12 台常见机型的回归清单，不只在开发机上验证
• 在 CI 里加了小程序包体积检查，超预算阻止合并，PR 里能直接看到体积变化
• 技术栈：微信 / 支付宝 / 抖音小程序、Taro、uni-app、React Native、React、TypeScript、JSBridge

工作经历

负责商家券和外卖下单相关的小程序，三端小程序合计日活约 50 万，组内 7 人。

• 三端统一：原来微信、支付宝、抖音三端各维护一套代码，一个需求要做三遍。推动用 Taro 统一，先从新页面开始，再按访问量逐步迁移老页面，大部分需求现在只开发一次
• 包体积和启动：微信小程序主包接近 2MB 上限，新功能加不进去。按页面访问量重新划分分包，把低频页面和大体积依赖（图表、富文本）移出主包，首页依赖的分包做预下载；主包降到 1.1MB，冷启动耗时减少约 四成
• 渲染性能：商品详情页切换规格时明显卡顿，排查发现是一次 setData 传了整个商品对象。改为只传变化的字段并合并高频更新，切换规格基本无卡顿
• 设备兼容：真机测试中发现部分安卓 WebView 回到前台后定位权限状态没有刷新，用户看到旧位置。监听生命周期并重新检查权限，失败时展示手动选择地址入口；和测试一起整理 12 台常见机型的回归清单

• 参与商城 H5 的多语言改造，抽出文案字典并按语言包按需加载，支持 6 种语言
• 处理不同语言下文案长度差异导致的布局错乱问题，整理了多语言布局规范
• 商品详情页的价格在不同币种下格式不统一，改用 Intl.NumberFormat 统一处理货币和千分位

项目经历

Taro / React / TypeScript

• 平台差异适配层：登录、支付、分享、定位四类能力在三个平台的接口和流程都不同，封装统一的适配层，业务代码不再写平台判断
• 体积监控：在 CI 中加入小程序包体积检查，主包或分包超出预算时阻止合并，并在 PR 里展示体积变化明细
• 灰度和回滚：小程序发版审核慢，关键功能加了远程开关，出问题时不用等审核就能关闭
• 弱网下单：用户从商家页跳支付时可能切到后台，回来后本地状态与服务端订单不一致。提交时带幂等订单号，支付回跳后重新查询服务端结果；对超时、重复点击、取消支付分别给出提示。试点地区相关客服咨询从每周 20 多件降到个位数

React Native / TypeScript / FlashList / Reanimated

App 内的门店列表、商品选购和购物车三个页面用 React Native 重写，覆盖下单流程的主要环节。

• 门店列表从 ScrollView 换成 FlashList，配合固定高度的骨架行，低端安卓机上滚动掉帧明显减少
• 商品图按可视区加载并限制解码尺寸，长时间浏览后的内存占用比原来低了约三分之一，闪退率随之下降
• 加购动画用 Reanimated 跑在 UI 线程，JS 线程忙于计算价格时动画也不掉帧

React Native / Taro / Storybook

• 沉淀 40 多个跨端组件（选择器、弹层、表单项、商品卡片等），三端视觉和交互保持一致
• 每个组件附 Storybook 示例和三端截图对比，组件改动自动生成截图对比，减少视觉回归问题
• 对日期选择、图片上传等系统能力差异大的组件只共用协议和数据校验，各端保留原生交互；减少了大量平台分支，适配新系统版本时也能按端定位问题

教育经历

个人优势

• 5 年 React 经验，长期维护高流量下单链路和商家工作台，习惯从用户指标、性能数据和故障记录反推技术优先级
• 熟悉 React 18 并发渲染、Suspense、Hooks 闭包与依赖问题，排查过重复渲染、Context 更新过宽和水合不一致
• 性能治理按真实用户 P75 指标验收：下单页 LCP 从 3.2 秒降到 1.9 秒，提交率提升约 1.4 个百分点
• 状态管理有清晰的分层：服务端数据用 TanStack Query，跨页状态用 Zustand，表单草稿留在组件内
• 处理过金额和并发一致性问题：价格计算收进纯函数、服务端为准、乐观更新带版本号冲突检测
• 做过大规模表单：规格矩阵分块计算，300 个规格组合下输入延迟控制在 80ms 以内
• 有测试与发布的工程习惯：主链路 Playwright 冒烟测试跑在灰度环境，拦下过两次接口字段变更
• 建过团队内部的性能排查工具，把 React Profiler 和 Performance 长任务对照，用于 9 次性能专项评审
• 熟悉 Next.js App Router 与 RSC 的边界，做过商家帮助中心的 SSR 改造
• 在 6 人小组承担方案设计和代码评审，能把性能预算、回归用例和发布检查落到日常流程
• 技术栈：React、TypeScript、Zustand、Redux Toolkit、TanStack Query、Vite、Webpack、Vitest、Playwright

工作经历

交易前端组负责商家工作台和用户下单链路，前端 6 人；工作台约 1.6 万日活商家，下单高峰会集中在午晚餐时段。

• 下单页性能：和产品确定先看移动端 P75 LCP 与提交转化率。通过真实用户监控定位到首屏图片、同步地图 SDK 与过大的公共包；图片改分辨率自适应，地图移到选择地址后加载，公共包按路由拆分。灰度一个月后 LCP 从 3.2 秒降到 1.9 秒，提交率提升约 1.4 个百分点
• 购物车状态：原先活动价和满减价由三个组件各自计算，切换门店时偶发金额不一致。把价格计算收进纯函数，服务端价格为最终值，前端只展示预估；补齐跨店、券失效和并发加购用例，相关客服工单从每周十余件降到 2 件以内
• 商家表单：把营业时间、配送范围和商品规格三个高频表单的字段协议统一，复杂联动仍由业务组件处理，避免把所有逻辑塞进一个万能引擎。新门店开通流程从 14 个页面收敛到 8 个步骤，平均填写耗时降低约四成
• 发布质量：为下单主链路补 Playwright 冒烟测试，覆盖地址、优惠券、支付回跳与重试。测试在灰度环境运行，发现两次接口字段变更后才推进全量；上线后季度内没有重复出现支付状态丢失问题

公司面向连锁零售企业提供库存与订货系统，前端团队 4 人，我负责订货工作台和公共组件。

• 订单列表原来一次渲染数百行且每行有多个 Popover。用虚拟列表仅渲染可视区域，弹层挂到统一容器，并对筛选条件做 URL 持久化；低配办公电脑上的筛选响应从约 900ms 降到 200ms
• 建立组件库的版本发布流程：变更说明、示例页、视觉回归和废弃期。推动 12 个页面从复制粘贴的表格代码迁到同一套列配置，后续修复固定列错位只需改一处
• 配合后端梳理导出任务：大文件导出改成提交任务、轮询状态、完成后下载，失败显示可重试原因。减少了用户反复点击导致的重复任务

项目经历

React / TypeScript / Zustand / TanStack Query / Vitest

商家可批量编辑价格、库存和多规格商品。此前每个字段失焦即提交，弱网时后返回的旧请求会覆盖新输入；需求由客服和商家运营共同提出。

• 将页面状态分成服务端快照、未提交草稿和校验错误三层。批量保存时携带版本号，遇到冲突让商家选择保留本地或刷新，而不是静默覆盖
• 对规格矩阵使用分块计算，输入一项只更新受影响的 SKU；在 300 个规格组合下，输入延迟由肉眼可见的卡顿降到 80ms 以内
• 保存失败按字段显示原因，成功后再刷新缓存；对价格范围、库存边界和并发冲突写纯函数测试。灰度期间批量编辑的失败工单每周由 20 多件降到个位数

React Profiler / Chrome DevTools / TypeScript

团队内部工具，记录业务页面一次交互中的组件提交次数和耗时，帮助新人定位“点一下刷新半屏”的问题。

• 用 Profiler 收集 commit 时长与组件树，按交互名称聚合；和浏览器 Performance 长任务对照，避免只凭 render 次数判断性能
• 给常见问题写可复现示例：不稳定的对象 props、过宽的 Context、昂贵的派生计算。半年内用于 9 次性能专项评审，相关页面的中位交互耗时降低约三成

Next.js App Router / React Server Components / MDX

帮助中心原来是客户端渲染的 SPA，商家在搜索引擎里搜不到答案，只能找客服。

• 文档内容改为 MDX + 服务端组件渲染，目录、相关文章在服务端生成，客户端只保留搜索和反馈两个交互组件，页面 JS 体积减少约 六成
• 文章按更新频率分别使用静态生成和按需再验证，运营改完文档几分钟内上线，不用整站构建
• 上线半年，帮助中心来自搜索的访问量增长到原来的 3 倍左右，「怎么设置营业时间」这类基础咨询明显减少

教育经历

个人优势

• 4 年 Vue 经验，负责过供应链订货、仓储和教务排课等复杂中台，熟悉业务表单从需求澄清到上线维护的全过程
• 熟悉 Vue 3 响应式、依赖收集和 watch 刷新时机，主导过 400 多个组件从 Vue 2 渐进迁移，期间每周正常发版
• 组件设计讲究边界：通用字段组件只管交互和校验，审批、排课的业务状态机留在各自模块
• 做过扫码枪连续操作场景的性能优化，增量接口 + 批量队列，扫描反馈从约 1 秒降到 200ms
• 权限体系有落地经验：资源码清单由路由、菜单、按钮共用，服务端做最终鉴权，误显示反馈从十多次降到 1 次
• 金额计算统一按「分」做整数运算，修复过多处浮点误差导致的一分钱问题
• 可观测性按影响客户数告警，而不是按错误次数；首次报障到定位从半天缩短到约 20 分钟
• 大数据量计算会移到 Web Worker，补货工作台的交互卡顿从 1.3 秒降到 250ms 左右
• 熟悉 Vite 插件、Vitest、Cypress 和 CI 质量门禁，组件改动配 Storybook 和交互测试
• 重视一线用户的操作时间，会到仓库和客服现场看真实操作，再决定先优化哪一步
• 技术栈：Vue 3、TypeScript、Vite（含插件开发）、Vitest、Cypress、CI 质量门禁

工作经历

产品服务连锁门店的采购、仓储与补货流程，约 500 家企业客户。前端组 5 人，我负责门店订货与仓库管理两条线。

• Vue 3 迁移：老系统 400 多个组件依赖 Vue 2 与 Element UI，业务不能停。先做依赖盘点和兼容测试，保留旧路由并逐模块迁到 Vue 3；把公用 API 适配层单独维护，避免每页散落版本判断。历时 10 周迁完核心模块，期间正常每周发版
• 拣货页效率：仓库员工使用扫码枪连续操作，旧页面每次扫描都重新请求整张单据。和后端约定增量变更接口，前端用批量队列合并短时间扫描结果；100 行订单下扫描反馈由约 1 秒降到 200ms，仓库试点每天少花约半小时核对
• 权限收敛：不同客户的岗位权限配置不一致，按钮权限以前靠页面内散落的条件判断。建立资源码清单，由路由、菜单和按钮共用，服务端仍做最终鉴权；补齐无权限、权限过期和切换租户的用例，季度权限误显示反馈从十多次降到 1 次
• 线上故障治理：接入前端错误和接口耗时监控，将租户、版本和路由写入上下文；按影响客户数而非错误次数报警。定位并修复一个只在旧版安卓扫码浏览器触发的异常，客服首次报障到定位从过去的半天缩短到约 20 分钟

所在 4 人小组维护教务排课和讲师工作台，学期开学前两周访问量明显上升。

• 负责排课日历的拖拽与冲突提示：课程跨校区、教师和教室三个维度验证，前端先给即时反馈，提交时服务端二次校验；排课员需要来回修改的次数减少约三分之一
• 将一批散落的弹窗表单整理为可复用字段组件，但审批和排课使用不同的业务状态机，保留在各自模块，避免共享层吞进业务规则
• 为讲师课表加缓存与离线提示，网络恢复后重新验证最新排课；移动浏览器里的误操作投诉逐月下降

项目经历

Vue 3 / TypeScript / Pinia / ECharts / Web Worker

运营根据过去销量、促销计划和库存水位，为门店生成补货建议。一位运营通常一次审核 30 到 80 家店，页面需要同时展示趋势图和明细表。

• 原来前端在主线程聚合门店与 SKU 数据，切换筛选条件要卡住 1 秒以上。把纯计算移到 Worker，数据按批次发送，图表只更新受影响的序列；普通办公电脑上的交互卡顿从 1.3 秒降到 250ms 左右
• 用 URL 保存筛选维度，审核员复制链接给同事时能打开同一视图；批量采纳建议前展示异常库存与缺失数据，减少误下单
• 联合数据团队给建议值增加来源说明，用户可追溯销量区间、预测版本和人工调整记录。试点客户的“为什么推荐这个数量”咨询量下降约四成

Vue 3 / TypeScript / Storybook / Vitest

为采购、审批和财务页面提供统一的金额、日期、门店选择组件，目标是减少重复实现和边界错误。

• 金额输入统一按“分”做内部整数运算，展示层才转元，修复多处浮点计算造成的一分钱误差
• 门店选择器支持按租户分页搜索、已选项回显和权限变化提示；组件在 18 个页面复用，平均新建业务表单的前端工时由 2 天缩至约 1 天
• 为键盘导航、清空、异步加载失败写交互测试，并在 Storybook 标记不兼容的旧属性，升级时页面可以逐个迁移

Vue 3 / Pinia / WebSocket / IndexedDB

仓库员工用扫码枪连续拣货，一张单子上百行，高峰期每人每小时扫描 600 次以上。

• 扫码枪按键盘输入模拟，连续扫描时字符会串在一起。按输入间隔区分人工输入和扫码，扫码结果进入批量队列，每 100ms 合并提交一次
• 单据改用增量接口，服务端只返回变化的行，前端按行 ID 合并；100 行订单下扫描反馈从约 1 秒降到 200ms
• 仓库网络不稳定，扫描记录先写 IndexedDB，断网时界面显示「待同步」数量，恢复后自动补交，重复扫描由服务端按扫描 ID 去重
• 试点仓库每天核对时间减少约半小时，后续推广到 23 个仓库

教育经历

工作经历

交易平台在开票高峰会出现短时流量尖峰。服务端组 8 人，我负责订单查询、支付状态回传和商家管理 BFF，和 Java 交易核心团队协作。

• 订单聚合：用户订单页需要分别请求票品、座位、支付、退款四类服务，旧 BFF 串行调用导致 P95 超过 1.8 秒。按依赖关系并发查询，对非关键的活动信息设置超时降级，接口 P95 降至 620ms；同时明确部分失败时页面该显示什么，避免出现“空订单”
• 支付回调幂等：第三方回调可能重复或乱序，原处理逻辑会多次写订单状态。增加业务幂等键与状态转移校验，将回调原文保存在审计日志；补测“先退款后收到成功回调”等边界，季度内没有再次发生重复发券事故
• 突发流量治理：将购票资格查询的热点结果短缓存，把非关键营销查询隔离到独立连接池，并为队列消费者设置并发上限。大型开票场景下订单查询服务保持可用，峰值 每分钟约 9 万次请求时 P99 未出现持续上升
• 排障工具：给核心链路统一 traceId，串起 BFF、消息消费者和交易服务；把事件循环延迟、堆内存、连接池等待列入看板。一次慢接口从报警到定位由过去约 40 分钟缩到 10 分钟以内

团队提供审批和消息产品，前后端共 10 人，我负责通知中心接口及管理后台。

• 为审批通知设计消息模板和发送队列，把同步邮件发送移出请求链路；接口平均耗时由 700ms 左右降到 140ms，失败通知可追踪和重试
• 将零散的 Express 路由迁到 NestJS 模块，统一参数校验、错误码和权限守卫；迁移按业务域逐个发布，老客户端协议保持兼容
• 和测试一起搭建接口契约测试，覆盖字段增删、分页与权限边界，减少前后端联调阶段的重复返工

项目经历

NestJS / PostgreSQL / Redis / OpenTelemetry

面向商家客服，支持按手机号尾号、订单号和场次查询订单。客服高峰时需要在数秒内答复用户，涉及个人信息必须按权限脱敏。

• 原 SQL 把多个筛选条件写成 OR，索引命中不稳定。按查询入口拆 SQL，建立对应复合索引，并限制时间范围；千万级历史订单表的典型查询由 2 秒以上降至 180ms 左右
• 查询结果按商家与场次短缓存，更新事件触发失效；客服查看用户联系方式需要单独鉴权并留下审计记录
• 用 k6 回放脱敏生产流量，发现连接池容量设置过大反而让数据库排队恶化；按实例数量重新预算连接数，压测 P95 更稳定

Node.js / RabbitMQ / Redis / PostgreSQL

订单状态变更后，要分别发送短信、站内信和邮件；供应商会限流，部分消息允许延迟但不能无声丢失。

• 以业务事件 ID 加渠道作为幂等键，消费者成功后写投递记录，重复消费直接返回；失败按指数退避重试，超过次数进入人工可查看的死信列表
• 给供应商接口加并发和速率限制，返回限流错误时延后而非立即重试。大促期间短信供应商故障持续 20 分钟，恢复后队列在一小时内消化，未造成重复发送
• 运维台展示事件来源、尝试次数和最后错误，客服可按订单号追踪通知状态；通知类工单的平均定位时间从半天缩短到约 15 分钟

NestJS / PostgreSQL / Redis / OpenTelemetry

商家后台的开票和对账页面要调用财务、订单、支付三个系统，页面首屏要请求 9 个接口，经常因为其中一个超时整页报错。

• BFF 按页面聚合接口，非关键数据（统计卡片、提示信息）允许降级为空，关键数据失败才整体报错；首屏请求数从 9 个降到 2 个
• 下游调用统一加超时、熔断和并发限制，财务系统抖动时不再拖垮整个 BFF 进程
• 接入 OpenTelemetry，一次请求在网关、BFF 和下游服务的耗时串成一条链路；对账页 P95 从 1.6 秒降到 600ms 左右

个人优势

• 5 年数据可视化经验，做过运营看板、城市车辆调度地图和工业三维监控，能区分「数据处理慢」和「绘制慢」两类问题
• 熟悉 ECharts、Canvas、WebGL、Three.js 和 deck.gl，按点位数量、交互方式和设备性能选技术，不为三维而三维
• 大数据量渲染有实战：轨迹按可视区裁剪和像素误差抽稀，数万点只需绘制几百个点
• 熟悉 GPU 拾取、实例化渲染和图层优先级管理，点选延迟保持在 100ms 以内
• 三维性能会从资源入手：和建模同事约定面数、材质和纹理预算，glTF 压缩并按楼层拆包，可交互时间从 12 秒降到 4 秒
• 时序数据做过分层采样：缩小保留每桶最值，放大再取原始数据，几十万点也能快速定位突变
• 有 7×24 小时大屏的稳定性经验：内存泄漏排查、WebGL 上下文丢失恢复、断网状态的明确展示
• 重视数字口径和可读性，和数据工程师对齐指标定义，告警同时用颜色、形状和文字表达
• 做过线上问题的录制回放工具，用同一段数据流复现乱序和坐标异常
• 长期参与现场验收，能处理高 DPI 工控屏、集成显卡和老旧浏览器上的兼容问题
• 技术栈：Canvas 2D、WebGL、Three.js、deck.gl、Mapbox GL、ECharts、React、TypeScript、Web Worker

工作经历

负责城市交通调度系统的地图与指挥大屏。产品接入车辆、路口与事件流，日常在指挥中心连续运行，前端组 5 人。

• 海量点位：旧方案用 DOM 标记车辆，超过 3000 辆时缩放明显掉帧。把静态道路和实时车辆分层，车辆交给 WebGL 实例化绘制，轨迹按视口范围裁剪；一万点位的缩放交互稳定在 45 帧以上
• 实时更新：消息每秒最多几千条，逐条更新图层导致主线程长期满载。服务端改二进制增量包，Worker 中解码并按 200ms 合帧，主线程只提交最新位置；高峰时网络流量下降约 60%，地图操作不再明显迟滞
• 告警设计：和调度员走访后发现红色告警覆盖底图，看不清附近道路。重新定义严重等级、聚合阈值和选中态，增加键盘定位与文字说明；试点中心查找异常车辆的平均用时缩短约四成
• 稳定运行：定位大屏运行一天后内存增长的问题，发现移除图层时纹理和监听器未释放；建立图层生命周期约定与 72 小时压力测试，上线后大屏不再需要每日人工重启

参与工厂设备监控产品，设备数据由边缘网关每 5 秒上报一次，客户会在车间触控屏和办公室电脑查看。

• 开发设备状态总览和趋势图，按设备类型建立可复用的量纲、阈值和时间轴组件，避免不同页面把摄氏度与华氏度混用
• 对跨度一年的传感器曲线做分层采样：缩小时保留每桶最值，放大后请求原始数据；数十万点数据仍能快速查看突变点
• 参与现场验收，修复高 DPI 工控屏上点击区域太小和断网后状态被错误显示为“正常”的问题，补上最后更新时间与离线状态

项目经历

React / TypeScript / Mapbox GL / deck.gl / Web Worker

调度员要同时看实时车辆、历史轨迹、拥堵热区和报警事件，地图会在一块 4K 大屏和普通办公电脑上使用。

• 给图层定义统一输入协议与优先级：底图、热力、轨迹、车辆、告警各自管理数据源；切换业务场景只启用所需图层，降低 GPU 内存占用
• 轨迹数据先按时间窗口和可视区域裁剪，再按像素误差做抽稀；一条数万点的轨迹通常只需绘制几百个点，视觉上仍保留拐弯细节
• 鼠标拾取使用离屏颜色编码而非遍历所有点位，点选延迟保持在 100ms 以内；对低性能终端自动减少装饰图层
• 建立基于录制数据的回放工具，线上问题可用同一段车辆流复现。半年内用于定位 7 次乱序或坐标异常，减少依赖现场视频猜测

Three.js / TypeScript / glTF / ECharts

客户希望把设备告警定位到厂房楼层和机台，但三维场景必须能在普通办公电脑运行，不能依赖独立显卡。

• 与建模同事约定模型面数、材质数量和纹理尺寸预算；加载前压缩 glTF 并按楼层拆包，首屏只加载当前厂房
• 设备状态通过实例化标记展示，点击机台才加载详细曲线；在集成显卡电脑上首次可交互时间由约 12 秒降到 4 秒
• 为色觉障碍用户提供形状与文字双重告警提示，二维列表与三维视图共用同一份选中状态；项目通过客户现场验收

ECharts / TypeScript / Web Worker / JSON 配置

运营每周要新增十几个指标图表，原来每个都要前端排期开发。

• 把图表抽象为「数据源 + 指标 + 维度 + 图表类型」的 JSON 配置，运营在界面上配置，渲染端生成 ECharts option
• 同比、环比、占比等派生计算在 Worker 里完成，主线程只渲染；一个看板 20 个图表时切换筛选不再卡顿
• 指标定义统一维护口径说明，图表悬停可查看计算方式，「两个看板数字对不上」类的问题明显减少
• 上线后常规看板需求不再进前端排期，团队每月节省约 40 人时

教育经历

个人优势

• 8 年前端经验，近 4 年专注多团队共用的构建、组件和质量基础设施，服务 20 多个业务团队
• 平台建设先找业务阻力再定能力边界，用接入率、构建耗时和故障率衡量成果，而不是功能数量
• 做过从零到一的设计系统：语义 Token、亮暗与高对比主题、组件状态测试，接入后页面交付周期缩短约 25%
• 主导过多仓库到 pnpm Workspace 的迁移，先统一 lint、测试和发布元信息，再抽公共组件，不在一次迁移里同时换框架
• 熟悉构建性能治理：远程缓存、按变更范围构建、产物分析，大型仓库 CI 时间有过成倍下降
• 建立按业务级别配置的质量门禁，交易页要求关键路径冒烟，内部页面不强制同样的性能阈值
• 发布与回滚：Source Map 绑定版本、发布后自动对比错误人数和 LCP，资源缺失导致的回滚从每季度 6 次降到 1 次
• 写过 codemod 和 ESLint 规则推动大版本升级，提供兼容窗口，业务可以按风险分批迁移
• 带 5 人基础建设小组，负责规划、评审和对外支持，平台问题有值班和响应时效
• 保持对一线业务的感知，每季度轮岗参与一个业务需求，验证平台在真实场景里的体验
• 技术栈：TypeScript、Vite、Webpack、Rollup、pnpm Workspace、Turborepo、微前端、设计系统、CI/CD

工作经历

负责云控制台公共前端平台，控制台包含 30 多个产品域、约 70 名前端开发；我带 5 人小组维护构建、组件和监控体系。

• 构建平台：旧仓库一次全量构建平均 28 分钟，业务改一处文案也要等完整流水线。先按包依赖图拆任务，接入远程缓存与受影响包检测；缓存命中时 CI 中位耗时降到 8 分钟，未命中时仍能完整构建验证
• 组件治理：设计系统此前有 3 套 Button 和 4 套表格，升级成本高。和设计、无障碍、业务代表制定 Token 与组件 API，写 codemod 迁移常见调用；一年内核心组件在 21 个产品域接入，重复问题和视觉偏差显著减少
• 发布隔离：控制台多个产品共用一套入口，某产品静态资源错误会拖累整站。建立按产品发布的清单和资源版本锁，保留回滚入口；一次产品配置故障仅影响对应路由，未扩散到其他业务
• 监控标准：规定错误事件必须带产品域、版本、租户与 traceId，统一采集白屏和关键页面性能。告警按受影响用户数分级，线上问题由业务反馈后发现占比从六成降到两成以内
• 团队推广：用 RFC 说明迁移成本和例外情况，每两周与业务组复盘。没有要求一次性重写旧页面，先在新需求中采用，再按业务窗口迁存量；平台月活开发者超过 60 人

负责门店运营系统前端架构，团队从 6 人扩到 24 人，页面和仓库数量迅速增长。

• 将 11 个独立仓库迁入 pnpm Workspace，先统一 lint、测试和发布元信息，再抽公共业务组件；避免迁移初期同时改运行时框架和构建系统
• 给门店订单、库存等高频页面设置体积与 LCP 预算，超出后由负责人解释业务收益或给出拆包方案；典型低端设备 LCP 从 4 秒多降到约 2.5 秒
• 设计前端灰度开关，按门店与用户组放量，回滚只改配置；大促期间两次线上问题都在十分钟内回到稳定版本

项目经历

React / TypeScript / CSS Tokens / Storybook / Playwright

各产品线设计与代码实现长期分叉，用户在不同页面看到不同的表单和导航。目标是建立能被持续维护的共同语言。

• 先盘点 200 多个页面的交互模式，把表格筛选、权限提示和异步状态列为首批，不靠“换颜色”伪装成设计系统
• Token 区分语义与具体色值，亮暗主题和高对比模式使用同一套组件 API；表单字段按错误、警告、只读、加载等状态写测试
• 组件发布采用语义版本和变更说明，对破坏性更新提供 codemod；接入团队可以先替换低风险组件，业务高峰后再迁复杂表单
• 接入一年后，常见后台页面从设计验收到首次交付的平均周期缩短约 25%，组件缺陷由平台组集中修复

Node.js / GitLab CI / Lighthouse / Sentry

平台对每个前端项目提供同一套发布前证据：类型、单测、关键路径冒烟、包体积与性能趋势。

• 质量门禁按业务级别配置，交易页需要关键路径冒烟，内部低流量页不强制相同的性能阈值，避免一刀切拖慢团队
• 把 Source Map 上传与版本号绑定，Sentry 报错能对应到准确源码；发布后自动对比前后版本的错误人数和 LCP 分布
• 平台上线后，因静态资源缺失导致的回滚从季度 6 次降到 1 次；CI 耗时虽然增加约 2 分钟，但故障排查时间明显下降

pnpm Workspace / Turborepo / Rspack / Renovate

主仓库 60 多个包，全量构建 25 分钟，依赖版本各自为政，同一个日期库在产物里出现 4 个版本。

• 引入任务图和远程缓存，只构建受影响的包；构建工具从 Webpack 迁到 Rspack，保留插件兼容层逐步替换
• 用 Renovate 按分组自动提依赖升级 PR，配合构建产物分析标出重复依赖，半年内重复依赖减少约 七成
• 主仓库 CI 平均时间从 25 分钟降到 8 分钟左右，业务团队等待合并的时间明显缩短

教育经历

个人优势

• 5 年中后台开发经验，近 3 年负责低代码表单与页面搭建平台，熟悉运营人员实际使用的配置流程
• 能把物料协议、数据源、权限、发布和回滚连成完整链路，避免只做出「能拖拽」的演示版
• 物料协议设计有经验：展示属性、行为事件、数据源输入分开，复杂物料可以自带配置面板
• 编辑器基础能力扎实：命令模式撤销重做、连续操作合并、离线草稿和断网提示
• 规则引擎强调安全：表达式只允许白名单字段和运算符，不执行任意脚本，保存时做循环依赖检查
• 大表单性能有优化经验：规则计算放进 Worker，只提交变化字段，几百个字段下输入不卡
• 发布锁定物料版本，历史页面不会因为组件库升级突然变样，并提供版本对比和回滚
• 财务场景熟悉：金额舍入、发票字段、附件上传失败和重复提交都有对应处理
• 推动平台在销售、客服、财务三个团队落地，承载约 1800 个客户页面，月均发布 600 余次
• 重视可调试性，做了规则调试面板，运营能看到「字段为什么被隐藏」，减少来回截图沟通
• 技术栈：React、TypeScript、JSON Schema、Node.js、PostgreSQL、Vitest、Playwright

工作经历

公司为连锁零售客户提供 CRM 与运营系统，实施团队经常为不同客户重复开发相似表单。我在 7 人平台组负责编辑器、物料协议和发布预览。

• 页面搭建：原来一个客户定制页面要前端排期 5 到 8 天。和实施、设计团队挑出稳定的表格、表单、图表场景，定义物料属性和数据源协议；试点客户的标准页面平均 2 天内完成配置上线，个性化逻辑仍交给代码扩展
• 表单联动：早期字段变化后遍历全部规则，字段多时输入卡顿。将规则依赖建图，按受影响节点增量计算，并在发布前检测循环依赖；40 字段表单的输入延迟从 300ms 级降到 50ms 左右
• 预览隔离：运营配置的 CSS 会覆盖编辑器按钮和弹窗。预览画布改入 iframe，用版本化消息协议传属性、选中态和高度；修复多个客户主题互相影响的问题，同时加上消息来源校验
• 发布安全：页面配置存不可变版本，发布前做 Schema 校验、权限校验和测试环境预览，正式发布按客户灰度。某次客户数据源字段误删时在 3 分钟内回滚到上一版，无需重新构建前端
• 推广与反馈：每周跟实施同事看实际操作录屏，把“找不到组件”“不知道为什么联动失效”这类问题写进产品待办；平台月活配置人员约 120 人，三个月后返工工单下降约三成

负责费用报销与审批中台，前端团队 5 人，业务规则受组织架构和费用类型影响很大。

• 开发多级审批流程可视化配置，前端先做合法路径提示，服务端保存时重新校验权限与组织范围，减少无法提交却找不到原因的工单
• 将金额、发票和附件字段封装为业务组件，单测覆盖舍入、上传失败与重复提交；新版报销页的错误提交率下降约两成
• 为权限变化提供明确提示：切换公司后清理旧缓存并重新拉取字段可见性，避免用户看到不属于当前公司的数据

项目经历

React / TypeScript / Zustand / iframe / Node.js

实施人员通过拖拽物料搭建客户专属的运营页，页面发布后由客户员工使用，涉及登录态、数据权限和不同租户主题。

• 物料协议拆分展示属性、行为事件和数据源输入；复杂物料可以自带配置面板，不把所有差异强塞进通用表单
• 编辑器用命令记录变更，连续拖动合并为一条，支持撤销重做；离开页面前自动保存草稿，断网时保存在本地并提示未同步
• 发布过程生成静态资源并锁定物料版本，历史页面不会因为组件库升级突然变样；同时提供版本对比与回滚入口
• 平台承载约 1800 个客户页面，月均发布 600 余次，常见页面的实施交付周期明显缩短

TypeScript / JSON Schema / AJV / Web Worker

财务审批表单会根据员工职级、费用类型和城市显示不同字段。旧方案把条件判断分散在页面里，规则越来越难维护。

• 规则表达式限制可使用字段与运算符，不执行任意脚本；保存时做语法、循环依赖和权限检查
• 大表单的规则计算放进 Worker，输入时只提交变化字段；界面保持响应，错误提示定位到具体规则和字段
• 将规则解释结果记录在调试面板，业务运营可看到“字段为什么隐藏”。上线后客服定位联动问题由反复截图沟通变成查看规则记录

TypeScript / JSON Schema / Node.js 沙箱

搭建页面要对接各业务系统的接口，原来每个数据源都要前端写适配代码。

• 数据源配置包括请求定义、参数映射和返回值转换，转换用受限的表达式而不是任意 JS，配置可在线调试并查看每一步结果
• 接口凭证由服务端代理注入，前端配置里不出现密钥；按租户限制可访问的域名
• 支持请求合并和缓存策略配置，同一页面多个组件用同一数据源时只请求一次
• 上线后新接入一个业务系统从平均 3 天缩短到 半天左右，大部分由实施同事自行完成

教育经历

个人优势

• 6 年前端经验，其中 4 年开发 Windows 与 macOS 桌面产品，熟悉主进程、渲染进程与系统能力的安全边界
• 负责过自动更新、离线数据、文件导入、托盘和系统通知等完整交付链路，能排查只在某个系统版本出现的问题
• 安全上收紧过 IPC：参数 schema 校验、速率限制、contextIsolation 和最小权限的 preload 暴露
• 本地数据用 SQLite，事务写入并定期 checkpoint，意外断电后能从最近一次成功提交恢复
• 本地搜索做过增量索引和过期查询取消，十万级文档块首屏结果通常在 200ms 内返回
• 熟悉跨平台构建、签名和公证，CI 为每个平台验证安装和启动后再发布
• 灰度按企业 ID 稳定分桶，崩溃率异常时自动停止扩量，保留上一版安装包和数据迁移回滚脚本
• 关注安装成功率、启动时长和崩溃率三项指标，冷启动时间做过专项优化
• 处理过大量平台差异：Windows 路径大小写和文件占用、macOS 权限与沙箱、高 DPI 缩放
• 和测试、客户支持一起建立诊断包导出流程，默认不含正文，跨平台问题复现效率明显提高
• 技术栈：Electron、Node.js、React、TypeScript、Zustand、SQLite、自动更新与代码签名

工作经历

产品是面向企业的知识库客户端，用户在本地编辑文档并同步到团队空间；桌面组 6 人，我负责离线编辑、搜索和发布链路。

• 离线同步：旧版断网编辑后容易在重连时覆盖同事的新版本。把本地变更写入持久化队列，服务端返回版本冲突时给出段落级差异与人工选择；同步失败率从约 4% 降到不足 0.5%，客服不再需要手工恢复大多数冲突文档
• 启动性能：用 CPU Profile 找到首屏启动时同时加载全文索引、插件和同步任务。先显示最近文档，索引增量加载，插件在首次调用时初始化；普通办公电脑冷启动可交互时间从 7 秒多降到约 2.5 秒
• 自动更新：用户处于企业内网，更新包下载常中断。支持断点续传和签名校验，下载完成后在空闲时提示重启；按企业批次灰度，失败时保留可回滚版本，升级成功率保持在 98% 以上
• 安全边界：将渲染进程的 Node 集成关闭，文件、剪贴板和系统通知只通过白名单 preload API 暴露；对导入的 HTML 做清理，修复了一处文档预览可执行脚本的漏洞
• 排障能力：崩溃报告附应用版本、系统版本、最近操作和匿名 traceId，去掉文档正文与本地路径；客户支持能在控制台查到故障上下文，复杂问题平均定位周期由数天缩到一天内

参与设计素材管理工具，用户主要在 Windows 笔记本上批量整理图片和字体文件。

• 开发文件夹监听与增量索引，避免每次打开项目全盘扫描；1 万个文件的索引更新时间从数分钟缩到十几秒
• 将缩略图生成放到独立进程，限制并发并缓存结果；大批量导入时界面不再因解码图片卡死
• 处理 Windows 路径大小写、文件占用和 macOS 权限差异，给用户明确的失败原因及重试入口

项目经历

Electron / React / TypeScript / SQLite / Node.js

产品需要支持本地离线编辑、全文搜索和团队同步。客户对文档隐私有严格要求，不允许问题日志带正文。

• 主进程负责文件与更新，渲染进程负责界面；IPC 参数做 schema 校验和速率限制，避免插件或异常页面调用任意本地 API
• SQLite 存文档索引与待同步变更，写入使用事务并定期 checkpoint；意外断电后能从最近成功提交的位置恢复
• 搜索索引按文档块增量更新，输入时取消过期查询；十万级文档块的本地搜索首屏结果通常在 200ms 内返回
• 配套设计“本地未同步”“正在重试”“冲突待处理”三个显式状态，避免用户误以为编辑已上云

Electron Builder / GitHub Actions / 私有更新服务

产品需支持 Windows x64、macOS Intel 与 Apple Silicon，企业内网用户还需要离线安装包。

• CI 为不同平台分别构建、签名、验证安装和启动，再发布到私有更新服务；发布清单记录包哈希与兼容系统版本
• 灰度按企业 ID 稳定分桶，更新失败或崩溃率异常时停止扩量；保留上一版安装包和数据迁移回滚脚本
• 为客户支持准备诊断包导出工具，默认不含文档正文，用户确认后才包含更详细的匿名日志；跨平台问题的复现效率明显提高

Electron / V8 Snapshot / esbuild

客户端冷启动在老旧 Windows 笔记本上要 8 秒以上，是用户反馈最多的问题。

• 用启动追踪拆分耗时：主进程同步加载了全部模块、首屏渲染前等待了非必要的数据同步
• 主进程模块改为按需加载并用 esbuild 打包成单文件，减少磁盘读取；首屏只依赖本地缓存数据，同步放到窗口显示之后
• 窗口先显示骨架再填充内容，避免长时间白窗
• 老旧笔记本上冷启动从 8 秒多降到 3 秒左右，启动慢相关的反馈减少约七成

教育经历

工作经历

商户平台组负责商户入驻、收款、结算和对账，服务约 2 万家跨境卖家，小组 5 人。

• 结算服务：原结算逻辑写在定时脚本里，失败只能人工补跑。用 Go 重写为状态机驱动的结算服务，每笔结算有明确状态和重试策略，配合每日对账任务；人工介入的结算单从每周 40 多笔降到 3 笔以内
• 服务拆分：商户、收款、结算原来在一个单体里共享数据库。按数据归属拆成三个服务，迁移期间新老系统双写并每小时比对，历时四个月完成切换，期间交易无中断
• 商户后台：统一权限模型（角色 + 数据范围）和表单方案，后台 120 多个页面迁到同一套框架；新页面平均开发时间从 3 天降到 1.5 天
• 稳定性：接入 Prometheus 和链路追踪，为核心接口设置 SLO 和告警；建立值班和故障复盘制度，季度 P1 故障从 3 次降到 0 次

负责门店管理系统和配送调度后台，团队 12 人。

• 用 Go 开发配送调度的派单接口，高峰期单机 QPS 从 800 提升到 3000，P99 稳定在 50ms 以内
• 前端用 React 重写门店后台，状态和接口层统一，线上 JS 报错量下降约七成
• 推动慢 SQL 治理，给 30 多条高频查询补索引或改写，数据库 CPU 峰值从 85% 降到 45%

项目经历

Go / Kafka / MySQL / React / ECharts

• 每天拉取 6 家支付渠道的账单，按渠道适配器统一成内部格式，差异自动分类：长款、短款、金额不符、状态不符
• 对账任务按商户分片并行，200 万笔交易的全量对账从 2 小时缩短到 15 分钟
• 前端提供差异处理工作台，财务可以批量标记、备注和导出，月末关账时间从 5 天缩短到 2 天

Go / Redis / OpenTelemetry

• 统一鉴权、限流、灰度路由和审计日志，十几个内部服务不再各自实现一遍
• 限流按商户和接口两级配置，配置变更实时生效，不需要重启
• 所有请求带 traceId，前端报错时把 traceId 展示给客服，排查时间明显缩短

个人优势

• 5 年 Android 开发经验，负责过日活 800 万的内容社区 App，主导启动、卡顿、崩溃三项性能指标的治理
• Kotlin 和协程用得扎实，团队新模块全部 Kotlin 编写；推动 Jetpack Compose 在新页面落地，并处理了和老 View 体系的混用问题
• 启动优化做过完整链路：任务编排、类加载、布局预加载、首帧数据缓存，冷启动从 2.3 秒降到 1.1 秒
• 稳定性有体系：崩溃按版本、机型、系统聚合，ANR 有自动抓栈，Native 崩溃能用 addr2line 定位到行
• 关注包体积，做过资源混淆、图片格式转换、动态下发和无用代码清理，安装包从 98MB 降到 61MB
• 熟悉组件化和模块解耦，Gradle 构建速度从 6 分钟降到 2 分半，团队日常开发体验明显改善
• 能和 iOS、前端同学对齐跨端方案，做过 WebView 容器和 JSBridge 的性能优化
• 技术栈：Kotlin、Java、Jetpack Compose、Coroutines、Room、Retrofit / OkHttp、Hilt、Gradle、Perfetto、Matrix

工作经历

客户端基础架构组负责性能、稳定性和构建工具，Android 4 人，服务全公司 30 多名客户端开发。

• 冷启动：用 Perfetto 拆解启动耗时，发现 SDK 初始化串行、首页布局层级过深、首屏数据等待网络。改为有向无环图编排初始化任务，非首屏 SDK 延后到首帧之后，首页数据先读本地缓存。冷启动 P50 从 2.3 秒降到 1.1 秒
• 卡顿治理：接入 Matrix 统计帧率和慢函数，信息流页的掉帧集中在图片解码和复杂文本排版。图片按控件尺寸解码、文本布局在子线程预计算，信息流滑动掉帧率下降约 60%
• 稳定性：建立崩溃和 ANR 的版本对比看板，新版本灰度期间自动对比崩溃率；处理了一批厂商 ROM 上的系统 Bug。崩溃率从 0.18% 降到 0.05%，ANR 率降到 0.1% 以下
• 包体积：清理无用资源和代码，大图转 WebP，非核心功能（直播礼物特效、AR 滤镜）改为动态下发。安装包从 98MB 降到 61MB，下载转化率提升约 3 个百分点

负责司机端 App 的接单和导航模块，Android 团队 8 人。

• 接单页从 Activity 堆叠改为单 Activity + Fragment 导航，页面切换耗时下降约一半，内存泄漏问题基本消除
• 后台定位保活适配各厂商的省电策略，司机端定位断档率从 7% 降到 1.5%
• 为订单状态推送设计长连接 + 轮询兜底，弱网下订单状态延迟从分钟级降到 10 秒以内

项目经历

Jetpack Compose / Kotlin / Hilt / Paging 3

• 制定 Compose 页面的状态管理规范：UI 状态单向流动，副作用集中在 ViewModel，避免重组时重复请求
• 处理 Compose 与老 RecyclerView 列表的嵌套滑动冲突，封装通用的混用容器
• 建立重组次数和稳定性检查，在 CI 里拦截不稳定参数导致的过度重组；新页面开发效率提升约 30%

Gradle / Build Cache / KSP

• 用 Build Scan 分析构建耗时，kapt 迁移到 KSP，模块间依赖改为 api / implementation 精确声明
• 开启远程构建缓存，CI 和本地共享缓存产物
• 全量构建从 6 分钟降到 2 分半，增量构建大多在 30 秒以内

教育经历

个人优势

• 6 年 iOS 开发经验，负责过日活 500 万的健身 App 的训练和社区模块，App Store 评分维持在 4.8
• Swift 和 SwiftUI 是主力，新功能用 SwiftUI 编写，老页面按模块逐步迁移，和 UIKit 混用时的布局与生命周期问题处理过很多
• 对体验细节较真：手势过渡、键盘避让、动态字体、深色模式和无障碍都按系统规范适配
• 性能优化做过启动、滑动和内存三项：冷启动从 1.9 秒降到 0.9 秒，长列表滑动稳定 60 帧
• 熟悉 Swift Concurrency，把回调式的网络和数据库层改为 async/await，并用 Actor 解决共享状态的数据竞争
• 做过 Widget、Live Activity 和 Apple Watch 扩展，训练数据在手表和手机之间可靠同步
• 工程化方面推动了模块化和 CI：Tuist 管理工程，单元测试和快照测试跑在每个 PR 上
• 技术栈：Swift、SwiftUI、UIKit、Combine、Swift Concurrency、Core Data、HealthKit、WidgetKit、Instruments、Tuist

工作经历

训练业务组负责课程播放、训练记录和社区，iOS 5 人，与设计团队密切合作。

• 训练播放页：课程视频、动作计时、心率数据和语音提示需要同步。用状态机统一管理播放状态，计时基于媒体时间而不是定时器，锁屏、来电和切后台后恢复不再错位，相关差评下降约 70%
• Apple Watch 联动：手表实时采集心率并回传手机，弱连接时在手表端缓存，恢复后按时间戳合并。训练数据丢失的反馈从每周二十多条降到个位数
• Live Activity：训练进度显示在锁屏和灵动岛上，上线后训练完成率提升约 6 个百分点
• 启动优化：用 Instruments 定位启动耗时，动态库合并、首页数据预取和非必要 SDK 延迟初始化，冷启动从 1.9 秒降到 0.9 秒
• SwiftUI 迁移：训练模块 40 多个页面迁到 SwiftUI，沉淀了一套组件库和设计 Token，新页面开发时间减少约 40%

负责信息流和详情页，iOS 团队 10 人。

• 信息流改用预排版 + 异步绘制，复杂卡片滑动从 45 帧提升到稳定 60 帧
• 详情页图文混排改用 TextKit 2，长文章内存占用下降约 40%，再没有出现过因内存被系统杀掉的问题
• 搭建崩溃自动归因脚本，按版本、系统和调用栈聚合，崩溃率从 0.2% 降到 0.06%

项目经历

Swift Concurrency / Core Data / CloudKit / HealthKit

• 训练记录本地优先写入 Core Data，后台同步到服务端，冲突按“最后修改 + 字段级合并”处理
• 用 Actor 封装同步队列，消除多线程写数据库导致的偶发崩溃
• 与 HealthKit 双向同步，避免同一次训练在“健康”App 里重复记录

XCTest / SnapshotTesting / Tuist / GitHub Actions

• 为核心组件建立快照测试，覆盖深色模式、动态字体和不同屏幕尺寸
• Tuist 生成工程，消除 .xcodeproj 合并冲突；CI 上并行跑单元测试和快照测试
• 上线前的 UI 回归问题从每版五六个降到一两个

教育经历

个人优势

• 5 年移动端经验，前 2 年做 H5，近 3 年负责电商 App 的 React Native 业务，RN 页面占全 App 的六成以上
• 主导 RN 从旧架构升级到新架构（Fabric + TurboModules），处理了第三方库兼容和原生模块迁移
• 性能问题能定位到具体层面：JS 线程阻塞、桥通信过多、列表重渲染还是原生渲染慢，分别有对应的工具和方案
• 能写 iOS 和 Android 原生模块，做过支付、推送、相机和本地存储的封装
• 搭建过热更新平台：差量包、灰度发布、版本回滚和崩溃自动回滚，发版不再受应用商店审核限制
• 重视一套代码在两端的体验一致：手势、键盘、状态栏和安全区都有统一的封装和测试清单
• 技术栈：React Native、TypeScript、React、Hermes、Reanimated、FlashList、Zustand、Objective-C / Swift、Kotlin、Detox

工作经历

App 日活约 120 万，覆盖东南亚 5 个国家；移动端 9 人，其中 RN 4 人、原生 5 人。

• 新架构升级：RN 从 0.68 升级到 0.74 并开启新架构，逐个梳理 40 多个第三方库和 12 个自研原生模块的兼容性，自研模块改写为 TurboModules。升级后商品详情页首屏渲染时间缩短约 35%
• 长列表性能：商品瀑布流在低端 Android 机上掉帧严重。换用 FlashList，图片按尺寸裁剪和预取，列表项去掉不必要的重渲染；低端机滑动帧率从 38 帧提升到 55 帧以上
• 热更新平台：自建差量热更新，按国家、版本和用户比例灰度；新版本崩溃率超过阈值自动回滚。业务需求从提交到全量的时间从一周缩短到 1 天以内
• 支付与原生能力：封装 5 个国家的本地支付 SDK，统一成同一套 JS 接口，新增支付渠道的接入时间从两周降到 3 天

前期负责 H5 活动页，后期参与 App 的 RN 化改造，团队 7 人。

• 把门店详情、订单列表等 8 个高频页面从 H5 迁到 RN，页面打开耗时从 1.8 秒降到 0.6 秒
• 封装 RN 与 H5 共用的业务请求层和埋点 SDK，两端数据口径一致
• 搭建 RN 页面的 Detox 冒烟测试，覆盖登录、下单和支付主流程

项目经历

Hermes / Flipper / 自研 SDK

• 采集页面首屏时间、JS 线程卡顿、桥调用次数和内存，按页面和机型聚合
• 发现商品页一次渲染有 300 多次桥调用，合并后首屏耗时下降约 20%
• 卡顿超过阈值时自动采集 JS 调用栈上报，定位到多处在渲染期间做大量计算的代码

React Native / TypeScript / Reanimated / Storybook

• 沉淀 60 多个业务组件，动画统一用 Reanimated 在 UI 线程执行
• 每个组件附 iOS 和 Android 两端的截图对比，Storybook 里可以直接切换平台预览
• 安全区、键盘避让、深色模式统一封装，新页面基本不再出现两端表现不一致的问题

教育经历

个人优势

• 4 年 Flutter 开发经验，负责过一款在线教育 App 的 iOS、Android 和鸿蒙三端，一套代码维护三个平台
• 混合栈开发经验丰富：Flutter 页面嵌在原生 App 里，处理过多引擎内存、页面栈同步和原生通信的问题
• 渲染性能有实战：用 DevTools 定位重建范围过大、图片解码和 Shader 编译卡顿，课堂页稳定 60 帧
• 状态管理用 Riverpod，按功能模块划分 Provider，业务逻辑可以脱离 UI 单测
• 做过直播课堂的白板和音视频互动，Platform View 嵌入原生播放器，处理了层级和手势冲突
• 关注包体积和启动速度，Flutter 产物拆分、按需加载字体和图片，安装包减少 18MB
• 技术栈：Dart、Flutter、Riverpod、Dio、Isar、Platform Channel、Kotlin、Swift、ArkTS（鸿蒙适配）、Firebase Crashlytics

工作经历

学生端 App 日活约 60 万，移动端 6 人，Flutter 负责全部学习类页面。

• 直播课堂：课堂页包含视频、白板、聊天和答题四个区域。视频用 Platform View 嵌入原生播放器，白板用 CustomPainter 绘制并按笔迹增量重绘，低端机上课堂页从 40 帧左右提升到稳定 58 帧以上
• 鸿蒙适配：参与 Flutter 鸿蒙版的适配，梳理 30 多个插件的兼容情况，自研插件用 ArkTS 重写平台端；鸿蒙版按期上架，核心功能与 iOS、Android 一致
• 离线学习：课程视频和课件支持离线下载，断点续传、存储空间不足提醒、过期自动清理；离线播放相关的投诉下降约 80%
• 包体积与启动：拆分 Flutter 产物，非首屏资源延迟加载，字体按需子集化；安装包减少 18MB，冷启动缩短约 0.4 秒

负责企业审批 App，团队 5 人，从原生迁到 Flutter 的过程中加入。

• 参与 30 多个页面从原生迁到 Flutter，迁移期间新老页面共存，统一了页面路由和登录态
• 封装审批表单的动态渲染组件，服务端下发配置即可生成表单，新审批类型无需发版
• 用 Isolate 处理大附件的压缩和上传，上传过程中界面不再卡顿

项目经历

Flutter / Kotlin / Swift / Platform Channel

• 原生和 Flutter 页面统一用 URL 路由，页面栈由原生侧管理，返回手势和转场动画两端一致
• 多个 Flutter 页面共享一个引擎，打开新的 Flutter 页面内存增量从 30MB 降到 5MB 左右
• 页面间传参和结果回传有类型约束，减少了因参数拼错导致的线上问题

Flutter / CustomPainter / WebSocket

• 老师端的笔迹通过 WebSocket 实时下发，学生端按笔画增量绘制，不重绘整个画布
• 笔迹数据做了平滑和压缩，传输量下降约 60%
• 支持课后回放：按时间轴重放笔迹，和课堂录像同步

教育经历

个人优势

• 5 年 Java 后端经验，负责过电商交易链路里的订单、库存和优惠券服务，经历过三次双 11 大促
• 熟悉高并发下的数据一致性：库存预扣 + 异步确认、本地消息表、TCC 补偿都在生产环境落地过，知道各自的适用边界
• MySQL 调优有实战：慢查询治理、分库分表迁移、在线加索引不锁表，千万级订单表的查询稳定在 50ms 以内
• 熟悉 Redis 和 RocketMQ 的常见坑：缓存击穿、热 key、消息重复与乱序，处理过因此引发的线上事故
• 排查线上问题有方法：Arthas 看调用耗时、jstack 定位线程阻塞、GC 日志调堆参数，Full GC 从每小时数次降到每天不到 1 次
• 写代码重视可测试性，核心服务单测覆盖率保持在 75% 以上，接口改动先补契约测试
• 技术栈：Java 17、Spring Boot、Spring Cloud Alibaba、MyBatis-Plus、MySQL、Redis、RocketMQ、Elasticsearch、Docker、Kubernetes、SkyWalking

工作经历

交易中台组 12 人，支撑平台全部下单、支付和售后流程，日均订单约 60 万。我负责库存与优惠券两个服务，同时承担大促期间交易链路的值班负责人。

• 库存超卖治理：旧方案在下单时直接扣减数据库库存，大促峰值出现行锁等待和偶发超卖。改为 Redis 预扣 + 订单确认后异步落库，配合每日对账任务修正差异；大促峰值下单接口 P99 从 1.2 秒降到 280ms，当年大促零超卖
• 优惠券核销一致性：下单失败后优惠券偶尔不回退，每月产生约 200 张客诉。用本地消息表保证「订单取消」和「券回退」最终一致，补偿任务失败超过 3 次转人工处理；此类客诉降到每月个位数
• 订单表分库分表：单表超过 8000 万行，后台查询频繁超时。按用户 ID 分 16 库 64 表，迁移期间双写加数据比对，按商家分批切流，全程未停服；商家后台订单查询 P95 从 3 秒以上降到 400ms
• 大促保障：牵头梳理交易链路的 23 个依赖，给非核心依赖加熔断降级开关，组织两轮全链路压测；双 11 当天峰值 每秒 3200 单，核心接口可用性 99.99%

商户组 6 人，负责商户入驻、门店管理和结算对账。

• 重构商户结算对账流程：原来每天凌晨全量比对需要 4 小时，改为按渠道增量对账并行执行，耗时降到 35 分钟，对账差异当天可见
• 门店搜索从 MySQL 模糊查询迁到 Elasticsearch，支持按距离、品类和评分排序，搜索接口 P95 从 900ms 降到 120ms
• 接手一个没有测试的老结算模块，先补 160 个单测把现有行为固定下来，再拆分重构，上线后零资损

项目经历

Spring Boot / RocketMQ / MySQL 影子表 / SkyWalking

大促前的压测此前靠测试环境估算，和线上差距很大。平台目标是在生产环境用影子流量压测，不污染真实数据。

• 压测流量带标记透传到下游，数据库、缓存、消息分别路由到影子表、影子 key 和影子 topic；上线前用 50 条用例验证隔离，没有出现压测数据进入生产库
• 支持按真实流量比例回放和逐级加压，压测报告自动对比各接口的 RT 与错误率，定位出 4 个此前没发现的慢 SQL 和 1 个连接池瓶颈
• 平台在后续两次大促前各执行 3 轮压测，容量评估误差从过去的 40% 左右缩小到 10% 以内

教育经历

个人优势

• 4 年测试经验，从功能测试做到负责团队的自动化和质量体系，熟悉电商和支付两类业务的测试重点
• 能独立设计测试方案：按业务风险划分用例优先级，资金、库存、权限这类高风险点一定有边界和异常用例
• 自动化落地有结果：搭建接口自动化框架，覆盖 1200 多个用例，回归时间从 2 天缩到 40 分钟
• 会用数据说话：推动缺陷按根因归类分析，线上缺陷逃逸率从 8% 降到 3% 以下
• 熟悉性能测试：用 JMeter 和 Locust 做过下单、支付的压测，能读懂 TPS、RT 曲线并和开发一起定位瓶颈
• 沟通上能站在开发和产品的角度看问题，评审阶段提出的需求遗漏平均每个版本 5 条以上
• 技能：Python、Pytest、Requests、Selenium、Appium、JMeter、Locust、Jenkins、MySQL、Charles、Postman、禅道 / Jira

工作经历

质量组 7 人，负责收银台、账户和清结算三条业务线的测试，我负责收银台和账户，同时维护团队的接口自动化平台。

• 接口自动化平台：原有脚本散在个人电脑上，没人能完整跑一次回归。基于 Pytest 统一用例结构、数据准备和断言规范，接入 Jenkins 每晚定时执行并推送结果到企业微信；现覆盖 1200+ 接口用例，版本回归从 2 天降到 40 分钟
• 资金类测试：梳理收银台 46 个资金场景，补齐重复支付、部分退款、超时关单、对账差异等异常用例；一年内收银台线上资金类缺陷为 0
• 缺陷根因分析：每月把线上缺陷按「需求遗漏 / 设计缺陷 / 编码错误 / 环境配置」归类，推动开发在提测前补单测、产品在评审时给出异常流程；线上缺陷逃逸率从 8% 降到 2.6%
• 性能测试：大促前对下单到支付链路做压测，发现数据库连接池配置偏小导致 TPS 在 800 左右封顶，调整后达到 2400，满足大促目标

负责商城 App 和商家后台的功能测试，团队 5 人。

• 负责商品、购物车和订单模块的功能测试，每个版本编写和执行用例 300 条左右，参与需求评审和上线验证
• 用 Appium 编写 App 冒烟用例 80 条，每次发版前自动执行，发版前的手工冒烟时间从半天缩短到 1 小时
• 整理团队的测试用例模板和缺陷提交规范，新人上手时间从 3 周缩短到 1 周左右

项目经历

账户系统从老架构迁到新的分布式架构，涉及 300 多万用户的余额和流水，要求迁移前后数据完全一致、用户无感知。

• 制定分三阶段的测试方案：数据迁移校验、新老系统双跑比对、灰度切流验证，每阶段设定明确的放行标准
• 编写数据比对脚本，逐账户比对余额、冻结金额和最近 90 天流水，双跑期间发现 3 类数据差异并推动修复
• 灰度从 1% 用户开始，每一档观察 48 小时的资金指标；全量切换后 30 天内无资金差错

教育经历

个人优势

• 5 年产品经验，前 2 年做 C 端社区，近 3 年负责企业协作 SaaS 的审批与报表模块，熟悉从客户调研到商业化的完整流程
• 需求判断有方法：每个季度访谈 20 家以上客户，用「出现频次 × 影响付费」给需求排序，拒绝过不少只对单个客户有用的定制需求
• 用数据验证结果：关键功能上线前定好成功指标和观察期，审批模板功能上线后新客户 30 天激活率提升 11 个百分点
• 能和研发高效协作：PRD 写清楚边界和异常流程，评审后的需求变更率控制在 10% 以内
• 熟悉 B 端商业化：参与制定版本定价和功能分级，配合销售做过 30 多场客户演示
• 技能：需求调研、用户访谈、Axure、Figma、SQL（能独立取数）、神策 / GrowingIO、Xmind、项目管理

工作经历

负责审批与报表两个模块，对接研发 9 人、设计 2 人；产品服务约 1.2 万家付费企业。

• 审批模板库：调研发现 62% 的新客户卡在「不会配置审批流」，平均要找客服 3 次。设计按行业预置的 40 套审批模板，配置步骤从 11 步减到 3 步；新客户 30 天激活率从 48% 提升到 59%，审批相关客服咨询下降约 35%
• 报表自定义：大客户普遍需要自定义报表，过去全靠研发排期定制。拆出「字段选择 + 筛选 + 图表」三层能力，覆盖了约 80% 的定制需求；定制需求排期从平均 3 周降为客户自助完成，该功能成为专业版的主要卖点之一
• 版本分级与定价：和商业化团队一起重新划分基础版、专业版和企业版的功能边界，依据是各功能在不同规模客户中的使用率；调整后专业版占新签比例从 22% 提高到 34%
• 需求管理：建立需求池和季度规划机制，每个需求记录来源客户、频次和预期收益；评审后的需求变更率从约 25% 降到 9%

负责内容发布和互动功能，App 日活约 80 万。

• 重做发布流程：发现 40% 的用户在选择话题这一步放弃发布，改为发布后再由系统推荐话题，发帖转化率从 18% 提升到 27%
• 设计评论区「热评置顶 + 折叠低质评论」，配合运营制定判定规则；人均评论数提升 15%，评论举报量下降约 30%
• 推动建立 AB 实验流程，和数据分析同事一起定义实验指标，半年内完成 14 个实验，其中 5 个全量上线

项目经历

老审批流只支持串行节点，中大型客户的会签、条件分支都要靠拆成多个流程绕过去，是销售丢单的前三大原因之一。

• 访谈 18 家流失或濒临流失的客户，整理出 9 类高频审批场景，按覆盖客户数确定首期只做条件分支、会签和加签三项能力
• 和研发一起评估新老流程的兼容方案，老流程不做迁移、新建流程默认使用新引擎，避免一次性切换带来的风险
• 上线前邀请 12 家客户参与内测，收集问题 40 多条，修复后再全量发布；上线半年内因审批能力不足丢单的比例从 17% 降到 6%

教育经历

个人优势

• 4 年运营经验，做过在线教育和电商两个行业的用户运营，负责过从拉新、激活到复购的完整链路
• 习惯用数据做决策：每次活动前定好目标和对照组，活动后复盘 ROI，不只看参与人数
• 搭建过用户分层体系：按生命周期和价值把用户分成 6 层，针对性触达后沉默用户召回率提升到 14%
• 社群运营有实操：管理过 200 多个社群、约 6 万名用户，制定 SOP 后单个运营可维护的社群数从 15 个提升到 40 个
• 文案和策划能力扎实，独立策划的裂变活动单场带来 2.3 万新用户，获客成本比投放渠道低 60%
• 技能：活动策划、用户分层、社群运营、企业微信 SCRM、SQL 基础取数、Excel（数据透视、函数）、神策数据、文案写作、简单海报设计（Canva / 稿定）

工作经历

增长组 8 人，负责成人职业教育产品的用户转化与留存，我负责私域运营和会员续费，向增长负责人汇报。

• 私域转化：原来公众号粉丝只靠推文转化，正价课转化率不到 1%。搭建「公众号 → 企业微信 → 社群 → 直播课」的转化路径，按用户兴趣标签推送不同试听内容；正价课转化率提升到 3.8%，私域贡献的月营收占比从 12% 提高到 31%
• 会员续费：分析发现续费用户在到期前 30 天的学习频次明显更高。设计「学习打卡 + 到期前阶梯优惠」的续费方案，并对低活跃会员提前人工跟进；年度会员续费率从 34% 提升到 46%
• 用户分层：和数据同事一起按注册时长、学习行为和付费情况把用户分成 6 层，每层制定触达频率和内容；沉默 60 天以上用户的召回率从 6% 提升到 14%，同时把推送退订率控制在 2% 以内
• 社群 SOP：把入群欢迎、每日内容、答疑、转化节点整理成标准流程和话术库，配合企业微信自动化工具；单个运营可维护社群从 15 个提升到 40 个，社群 7 日留存提升 9 个百分点

负责社区团购业务的拉新和团长运营。

• 策划「邀请好友得免单」裂变活动，设置邀请上限和风控规则防止刷单；单场带来 2.3 万新用户，获客成本约 6 元，是投放渠道的四成
• 负责 300 多名团长的培训和激励，制定按订单量分级的佣金方案；团长月均订单量提升 22%，团长流失率从每月 15% 降到 8%
• 每周输出拉新渠道数据周报，推动停掉了 2 个 ROI 持续低于 1 的投放渠道

项目经历

年中是会员到期高峰，往年同期续费率只有三成左右。活动目标是在不加大折扣的前提下提高续费率。

• 先拉取近一年到期会员的数据，确认学习频次和续费率正相关，把活动设计成「打卡满 21 天解锁续费优惠」，而不是直接降价
• 按活跃度把 1.4 万名到期会员分成三组，高活跃用户只发提醒，中活跃用户配学习计划，低活跃用户由班主任一对一跟进
• 设置 10% 的对照组观察真实效果；活动组续费率 44%，对照组 31%，活动投入约 3 万元，带来续费收入约 85 万元

教育经历

个人优势

• 5 年设计经验，做过 C 端 App 和 B 端后台两类产品，能从交互流程一直跟到视觉落地和上线走查
• 搭建并维护过公司级设计系统：120 多个组件、配套 Figma 组件库和前端组件对照，新页面设计时间缩短约 40%
• 重视用设计解决业务问题：每个改版都定义要改善的指标，结算页改版后下单转化率提升 6.5 个百分点
• 做过 30 多场可用性测试和用户访谈，能把访谈里的问题整理成可执行的设计改动
• 熟悉前端实现的限制，交付时标注好状态、间距和动效参数，设计走查还原度问题比上线前减少一半以上
• 技能：Figma、Sketch、Principle、ProtoPie、Adobe Illustrator / Photoshop、设计系统、可用性测试、用户访谈、基础 HTML / CSS

工作经历

设计团队 6 人，负责乘客端 App 的下单与支付链路，以及司机端的部分功能，和 3 个研发小组协作。

• 下单页改版：数据显示 23% 的用户在选择车型时退出。访谈 15 位用户后发现主要问题是价格差异看不明白，重新设计车型卡片，把预估价、等待时间和差价放在同一视线；车型页退出率降到 14%，整体下单转化率提升 6.5 个百分点
• 设计系统：原来各业务线的按钮、弹窗有十几种样式。牵头整理 120 多个组件，制定颜色、字号和间距规范，并和前端一起维护代码组件对照表；新功能设计时间平均缩短约 40%，视觉走查问题数减少一半
• 无障碍与适老化：负责大字版和读屏适配，重新梳理关键页面的对比度和点击区域，大字版上线后 60 岁以上用户的下单完成率提升 12%
• 设计走查：建立上线前设计走查清单，覆盖异常状态、空状态和多机型适配；版本上线后的界面类缺陷从平均每版 15 个降到 6 个

负责客户管理后台和数据看板的界面设计。

• 重新设计客户列表页的筛选和批量操作，常用操作的点击次数从 6 次减到 2 次，客户反馈的易用性评分从 3.4 提升到 4.2（满分 5 分）
• 设计数据看板的图表规范，统一 9 类图表的配色和交互，被沿用到公司另外两条产品线
• 配合市场团队完成官网和产品宣传物料的视觉设计

项目经历

司机在行驶中操作接单界面，误触和漏看订单信息的投诉每月有 300 多起，这个项目要在不增加操作步骤的情况下降低误触。

• 随车观察 8 位司机的真实操作，发现主要问题是按钮离屏幕边缘太近、关键信息字号偏小，行驶中很难看清
• 重新设计接单卡片：放大目的地和预估收入，接单按钮改为底部大面积热区，拒单需要二次确认
• 和研发一起在 5% 的司机中灰度两周，误触投诉下降约 60%，接单响应时间没有变长，之后全量上线

教育经历

个人优势

• 4 年数据分析经验，支持过电商和内容两类业务，擅长把业务问题拆成可以用数据回答的问题
• 搭建过完整的指标体系：从北极星指标拆到 40 多个过程指标，统一口径后各部门的数据对不上的问题基本消失
• AB 实验经验丰富：设计并分析过 60 多个实验，能处理样本量估算、多重比较和新奇效应等常见问题
• 分析能落到决策：用户流失分析的结论推动产品调整了新手引导，新用户 7 日留存提升 5 个百分点
• 工具熟练：SQL 写得快且规范，Python 做建模和自动化报表，把团队每周 2 天的手工报表工作压缩到半天
• 技能：SQL（Hive / MySQL / ClickHouse）、Python（Pandas、Scikit-learn）、Tableau、Excel、AB 实验、统计检验、指标体系、用户分群

工作经历

数据分析组 6 人，我对接内容增长和推荐两个业务团队，负责指标体系、实验分析和专题分析。

• 指标体系：各团队对「活跃用户」「有效阅读」口径不一，周会经常在对数。牵头梳理 40 多个核心指标的定义和计算逻辑，沉淀成指标字典和统一数据表；口径争议类问题基本消失，日报产出时间从上午 11 点提前到 9 点
• 新用户留存分析：拆解新用户前 7 天的行为路径，发现首日关注少于 3 个作者的用户 7 日留存只有关注 5 个以上用户的三分之一。推动产品在新手引导中加入兴趣选择，新用户 7 日留存从 31% 提升到 36%
• 实验平台推广：为业务团队制定实验设计规范，提供样本量计算工具和标准分析报告模板；一年内支持实验 60 多个，实验结论被业务直接采纳的比例从约 40% 提高到 70%
• 自动化报表：用 Python + SQL 把 12 张周报改成自动生成并推送，团队每周用在手工报表上的时间从约 2 天降到半天

负责营销活动的效果评估和用户分群。

• 建立大促活动复盘模板，按拉新、转化、客单价和利润四个维度评估，帮助营销团队停掉了 3 类 ROI 长期为负的补贴玩法，年节省预算约 600 万元
• 基于 RFM 模型对 500 万用户分群，配合运营制定差异化触达策略，高价值用户的季度复购率提升 8%
• 搭建优惠券核销预测模型，预测准确率 85% 左右，帮助财务更准确地预估活动成本

项目经历

推荐团队每月上线多个策略实验，但常出现「实验组点击率涨了、整体时长却下降」的情况，结论难以判断。

• 和推荐、产品团队一起确定实验的主指标和护栏指标，主指标看人均阅读时长，点击率、负反馈率和作者曝光分布作为护栏
• 针对新奇效应，规定实验至少观察 14 天，并单独比较新老用户的表现；用 CUPED 方法降低指标方差，所需样本量减少约 30%
• 评估体系上线后，有 3 个原本准备全量的策略因护栏指标恶化被拦下，全年上线策略带来的人均时长累计提升约 9%

教育经历