袁旭佳的简历

个人信息

  • 袁旭佳 / 男 / 1988
  • 毕业于浙江理工大学
  • 工作年限：10 年 +
  • 期望城市：北京
  • 邮箱：496065812@qq.com
  • 手机：13691513508
  • 微信：yuanxujia

工作经历

美团 (2017 年 8 月 ~ 至今)

闪购业务 (2024.01 ~ 至今) | 技术主 R

核心职责：

  • 负责用户端多渠道（小程序、H5、鸿蒙）技术建设，统筹商详页性能优化和工程质量治理
  • 主导一码多端小程序同构项目，推进核心链路跨端能力收敛
  • 支撑店内日常研发需求，承担新人培养和技术招聘工作

项目一：商详页性能优化 (主 R)

背景（S）：

  • 商详页作为导购链路关键环节，2025 年 2 月 RCF 均值仅 61.9 分，低端机 47.8 分
  • 性能指标在集团内相对落后（低于外卖、医药、小象等业务同类页面）
  • 工程质量存在历史债务：视图层级复杂、渲染流程散乱、数据冗余
  • Q3-Q4 设计主导的竞品对标带来额外性能压力

任务（T）：

  • 商详页 RCF 从 61.9 提升至 75+，低端机达到 68+
  • 竞品对标中实现高中端机 Beat 竞对，低端机 Meet 竞对
  • 在不影响需求迭代的前提下完成工程质量治理

行动（A）：

  1. 性能优化策略： 抓主要矛盾，通过高频试错理解指标/问题，将有限资源投在 ROI 较高的策略上
  2. 渲染流程重构： 从多层级数据透传 + 异步渲染，改为单层级通信 + 三级渲染（骨架 - 预渲染 - 最终渲染）+ 同步直出
  3. 服务端接口优化： 落地首屏独立渲染，解决主接口耗时长问题
  4. 工程质量治理： 跟随需求迭代 + 版本回归方式，分层逐步完成页面层级优化、渲染流程收口、组件规范化、冗余数据删减
  5. 竞品对标专项： 完成商详首屏渲染接口拆分&页面数据重组，解决回包体积大问题

结果（R）：

  • RCF 提升： 从 61.9 → 79.3（12 月末 80+），提升 17.4 分；低端机从 47.8 → 68.9，提升 21 分
  • 竞品对标： 高中端机 Beat 竞对，低端机 Meet 竞对
  • 接口性能： 首屏依赖接口端到端 AVG 从 458ms → 320ms，降低 30%
  • 工程质量： 完成页面层级优化、渲染流程收口、组件规范化、冗余数据删减，历史债务基本清零
  • 业务影响： 商家页 tab 加载实时性改造后，推荐 tab CXR +1.42%，订单量 +1.40%

亮点： 通过快速试错 + 小步快跑探索出的优化策略大多行之有效，未在错误的方向上浪费时间

项目二：小程序同构项目 (协同负责人)

背景（S）：

  • 店内存在小程序、H5、鸿蒙等多端代码，维护成本高
  • 核心链路页面在双端存在 20+ 处差异，质量问题难以收敛
  • MSC（美团自研动态渲染框架）改造为同构奠定基础

任务（T）：

  • 2024 年实现核心链路同构覆盖率达到 100%
  • 4 月完成购物车收敛改造，8 月完成频道&店内页面同构
  • 对齐双端差异，下线无流量需求

行动（A）：

  1. 技术选型： 分而治之，Mach 部分采用局部模板同构，MSC 部分采用整体页面同构
  2. 前置改造： 优先完成购物车 MSC 改造，同步下线 6 个无流量需求，对齐 20 处双端差异
  3. 基建建设： 完成 MSC 拆包开发，为小程序同构分包奠定基础
  4. 渐进式推进： 先完成新版订单详情 + 售后 H5 同构上线，再推全首页、果蔬频道页、频道搜小程序同构
  5. 风险控制： 商家页完成重构&提测，缓解同构到小程序体积&性能风险

结果（R）：

  • 同构覆盖： 首页、果蔬频道页、频道搜小程序同构已推全；新版订单详情 + 售后 H5 同构已上线（灰度中）
  • 差异对齐： 购物车完成 MSC 改造，同步下线 6 个无流量需求，对齐 20 处双端差异
  • 业务效果：
    • 频道搜同构后，曝光转化&曝光点击率小幅度波动
    • 首页&频道页同构后，CXR 实验期间正负波动，变化不明显

暗点： 受业务需求压力&核心人员变动影响，项目延期至明年 3 月；MSC 部分性能、体积风险仍未解除

业务成果汇总：

  • 名酒馆集合店研发：北京试点门店周实付 GMV 24.4 万，3C 手机集合店 7 城周销售额 487 万
  • 全年累计完成 38 次功能改动上线，无项目 delay，无 E 级以上事故

优选业务 (2020.09 ~ 2022.09) | 销售 CRM 地图业务主 R

核心职责：

  • 负责销售 CRM 系统直营方向业务基础能力和平台能力建设
  • 推动架构演进，建设可复用组件物料和 SDK

项目一：架构演进与性能优化 (主 R)

背景（S）：

  • 项目构建耗时平均 30 分钟，严重影响上线效率
  • 地图能力模块已应用在 8 个不同业务模块中，模块间高度耦合
  • 缺乏可复用业务组件，新增页面模块研发成本高

任务（T）：

  • 构建耗时从 30 分钟降至 3 分钟内（对标团长增长项目）
  • 建设 Map X SDK，解决 8 个业务模块地图能力耦合问题
  • 沉淀销售 CRM 业务组件和通用 UI 组件

行动（A）：

  1. 构建优化： 使用 speed-measure 分析工具定位问题，通过 Webpack 配置减少第三方插件参与构建
  2. 多线程编译： 利用多线程并行编译 TypeScript，提升编译速度
  3. Map X SDK 建设：
    • 调研内部（物流前端、快驴仓配、配送终端、外卖商家）和外部（leaflet-geoman、高德地图）地图场景
    • 实现图形绘制能力（split、cut），解决异形蜂窝边界调整难题
    • 独立封装为 SDK，支持跨工程复用
  4. 组件沉淀： 建设销售 CRM 业务组件、通用 UI 组件

结果（R）：

  • 构建性能： 项目构建耗时从 30 分钟降至 3 分钟内，提升 90%
  • Map X SDK：
    • v0.1.0 实现图形绘制能力，边界调整操作节省 10% 耗时
    • v1.0 实现地图组件物料积累，新业务复用节省 1PD 研发耗时
  • 工程质量： 解决 8 个业务模块地图能力耦合问题，模块职责清晰化

项目二：资源管理 - 作业效率提升专项 (主 R)

背景（S）：

  • 地图能力模块每月执行 16000+ 次蜂窝编辑调整
  • 缺乏连续划分能力，相邻蜂窝边界调整需 9 个操作步骤
  • 校园蜂窝场景缺乏灵活的切割（Cut）、分割（Split）能力

任务（T）：

  • 作业区域划分流程效率提升 10%
  • 实现图形绘制能力，优化存量业务区域编辑体验

行动（A）：

  1. 流程优化： 推动 PM 将多页操作改为单页完成，减少操作步骤
  2. 能力补齐： Map X SDK v0.1.0 优先实现 split、cut 图形绘制能力
  3. 产品策略： 与 PM 配合多次迭代，优化优先级为：操作效率 > 用户体验 > 能力补齐

结果（R）：

  • 作业效率： Map X v0.1.0 实现后，边界调整操作预计节省 10% 耗时
  • 新业务提效： Map X v1.0 支持新业务复用，节省研发耗时 1PD

项目三：社区字典项目 V1.0 (负责人)

背景（S）：

  • 美团用户总数 6 亿+，全国人口 14 亿+，大量优质社区未被覆盖
  • 采集人员无高清卫星地图，无法直观判断待采集区域内楼宇情况
  • 涉及 10 个功能模块、30+ 社区信息字典，协调 App 端、PC 管理端、地图审核平台 3 个团队

任务（T）：

  • 完成兰州试点 500 条有效社区信息采集
  • 建设卫星地图服务，支持采集端 App 和 PC 管理端

行动（A）：

  1. 细粒度拆分： 将 10 个模块拆分为 15 个任务并分配到人，协调外部沟通让成员专注开发
  2. 数据协议统一： 联合后端优先约定接口出入参，采集端、后端、前端共用文档
  3. 卫星地图服务：
    • 谷歌卫星图：申请公司公网域名，通过香港建立转发服务（法务确认合规）
    • 腾讯卫星图：作为备用方案

结果（R）：

  • 采集目标： 实际采集 517 条有效社区信息，超额完成 500 条目标
  • 流程建设： 完成采集流程、信息管理流程、审核流程
  • 服务落地： 卫星地图服务已应用在采集端 App 和 PC 管理端

项目四：直代模式落地 (核心成员)

背景（S）：

  • 直代模式与直营网格站存在数据&业务流程耦合问题
  • 127 个直代区县乡镇下沉覆盖率需达到 90%+

任务（T）：

  • 解决直代模式与直营网格站数据&业务流程耦合问题
  • 形成标准 SOP，覆盖率达到目标

行动（A）：

  1. 全链路落地： 联合上下游业务完成直代模式全链路实施方案
  2. SOP 制定： 形成标准操作流程文档

结果（R）：

  • 下沉覆盖： 127 个直代区县乡镇下沉覆盖率达 91.20%（直营 92.15%，代理 91.78%）
  • SOP 沉淀： 形成标准 SOP，支持后续快速复制

团队与文化贡献：

  • 建立第三方插件规范、Pull Request 规范
  • 线上无资损级事故（S9=5000 元内/S3=5000-5 万/S2=5 万 -20 万）
  • 季度 PR comments 172 次（上季度 101 次），提升代码审查质量
  • 指导实习生、社招新人完成基础平台使用、H5 开发总结

支付业务 (2017.06 ~ 2020.09) | Hybrid 收银台前端开发

核心职责：

  • 负责 Hybrid H5 端版本迭代和性能优化
  • 推动订单转化率对齐标准收银台

项目一：Hybrid 收银台转化率优化 (核心成员)

背景（S）：

  • Hybrid 收银台订单转化率与标准收银台差距较大
  • 外卖业务放量至 4%，日均 20-30 万单，对转化率要求更高
  • Hybrid H5 侧存在桥成功率低、离线包命中率不足等问题

任务（T）：

  • 订单转化率与标准收银台差距缩小到 10~20BP 内波动
  • 外卖业务放量至 4%，日均 20-30 万单

行动（A）：

  1. 数据分析驱动： 通过漏斗分析定位影响转化率的关键因素，AB 对照测试优化
  2. 桥成功率优化：
    • 发现桥并发调用耗时长问题，完成优化
    • 识别关键桥调用成功率偏低，针对性提升
  3. 离线包命中率： 优化离线包机制，提升命中率
  4. 异常问题排查： 发现 iOS 端 Webview 被释放问题导致前端业务错误偏多（系统自身问题，暂时无法修复）

结果（R）：

  • 转化率对齐： 订单转化率高点时与标准收银台差距缩小到 10BP 以内
  • 业务放量： 外卖业务放量至 4%，日均 20-30 万单
  • 关键优化： 提升桥成功率 + 提升离线包命中率成为核心优化手段

项目二：版本迭代与质量保障 (主 R)

背景（S）：

  • Hybrid H5 端需高频迭代支撑业务需求
  • 金融业务场景对项目质量要求极高

任务（T）：

  • 支撑 Hybrid H5 版本迭代，保障上线质量
  • 形成稳定的敏捷流程

行动（A）：

  1. 迭代模式演进：
    • 基于流程的敏捷流程：多干系人需求，由主 R 统一安排
    • 基于迭代的敏捷流程：H5 独立实现，单周交付
  2. 质量保障：
    • 严格代码检查、执行自测
    • 提测阶段整理清楚影响范围，与 QA 做好沟通

结果（R）：

  • 版本迭代： 支撑 Hybrid H5 版本迭代 22 次，个人千行 bug 率 0.02（低于目标 0.04）
  • 上线次数： 主导上线 36 次，S9 级以上事故为零
  • 敏捷流程： 形成两种稳定的敏捷流程，支持不同场景下的快速迭代

团队贡献：

  • 负责团队建设，面试 33 人次
  • 培养新人 2 人，新人在职期间上线无事故

技术栈

框架与语言： Vue, React, JavaScript, TypeScript
工程化： Webpack, Gulp
工具链： Git, ESLint