interview202601

# 业务

萝卜快跑APP/wx小程序/支付宝小程序

打车入口，积分中心，好友助力，订单；各种运营活动

运营平台：

订单（长时用车，即时专送...），用户画像，渠道管理，新人福利，分享裂变，好友助力，拉新返现，积分商城
营销模块：优惠券，定价券，权益券；运营策略，计价策略，调价；订单对账，发票，合作企业管理...

打断平台：及时更新地图路况，同时验证站点连通性，及时高效地将最新的地图同步到车端

打断工单，工单版本，连通路段，路网；连通性子图
高清地图：用于自动驾驶和智能交通领域。它支持不同的数据格式和数据模型，包括道路拓扑、车道、交通信号和路况等信息。

站点渲染：webGL，几十万站点合并批量渲染，性能极佳

BMapGL：Polygon、Point、Size、InfoWindow

运力平台：城市区域管理，可跑路线，站点管理，车辆管理；，为萝⼘快跑的⾃动驾驶出⾏服务提供运⼒管理服务

监控平台：实时显示监控调度平台⻋辆、乘客单和⻋辆异常信息等情况

云控平台：提供任务规则配置，运营配置、⾃动驾驶参数配置、动态落盘参数配置

# 用户增长

用增营销模块

用户增长
- 拉新：分享裂变、渠道合作、好友助力
- 留存：新人福利，订单/拉新返现，任务奖励，积分商城，券包管理
营销管理：优惠活动（折扣/立减），渠道优惠，优惠券，定价券，权益券

用户增长包括获客、激活、留存、变现、推荐阶段

增⻓ = 流量获取 * 流量转化 * ⽤户替换成本

AARRR 模型

Acquisition（获取⽤户）、Activation（激活⽤户）、Retention（留存⽤户）、Revenue（⽤户变现）、Referral（⽤户推荐）等 5 个部分，形成⼀个⽤户流量漏⽃。

⽤户获取A：分享、裂变、好友助⼒•
⽤户活跃A：签到、做任务、积分兑换、抽奖.... •
⽤户留存R：新⼈福利、优惠券、折扣券…… •
⽤户收益R：特卖、满减、加1元购…… •
⽤户转介绍R：拼团降价，转发拿券，朋友帮忙砍价……

Growth Loops 模型：病毒式裂变（Viral loop）、补贴增⻓（Paid loop）、UGC内容循环（User-generated content loop

# 架构

背景 → 目标&约束 → 架构设计 → 产出&收益

背景
- 业务背景
- 现状痛点：效率、质量、稳定性、协作成本
目标与约束
- 产品目标
- 技术目标
- 对齐约束：业务形态、团队能力、交付节奏
架构设计
- 分层设计：视觉层、数据层、业务层、基础能力层
- 技术选型：候选方案对比、取舍依据、落地成本
- 演进策略：MVP -> 规模化 -> 治理化（可扩展、可回滚）
- 稳定性&安全
产出收益
- 交付产出
- 业务收益：量化指标
- 长期价值：能力复用、团队协作效率、组织沉淀

# 追加问题

遇到过哪些挑战？
踩过哪些坑？
你自己做过哪些决策？

# 项目

# B端低码平台

视图层：编辑端，渲染端；拖拽，可视化编辑，画布渲染；预览；沙箱隔离
协议层：渲染引擎， JSON schema 设计，事件流配置，组件树设计，状态与数据流管理
物料层：基础组件，业务组件，自定义组件，组件模板，页面模板
基础能力：
- 权限，版本管理，ci/cd工程化，插件机制；提供扩展api；安全，监控
- 创建逻辑：组件创建 =》页面创建 =》草稿态 =》发布 =》回滚；项目管理；
底层支持：后端能力，数据库

页面配置中配置的变量怎么进行渲染？

变量配置支持静态值、对象、变量、接口请求，保存的配置结构一般为{type:'', value: ''}；
在页面渲染入口会监听所有组件config配置修改，并在回调中执行变量处理；
在变量处理函数中会根据type判断，是静态值、对象、变量、函数表达式、接口请求，分别进行处理。
如果是type是变量，则会从全局保存的所有变量和表单数据中获取对应的值；
如果是函数表达式则通过new Function执行代码片段，将返回执行结果。
最后在页面渲染的结果就是处理后的变量值。

技术难点：事件流的配置、组件的插入拖拽（react-dnd）、变量的处理

# H5页面性能统计及性能优化

# 性能统计

从当前浏览器窗⼝卸载旧⻚⾯开始，到新⻚⾯加载完成，整个过程⼀共被切分为 9 个⼩块：提示卸载旧⽂档、重定向/卸载、应⽤缓存、DNS 解析、TCP握⼿、HTTP 请求处理、HTTP 响应处理、DOM 处理、⽂档装载完成。每个⼩块的⾸尾、中间做事件分界，取 Unix 时间戳，两两事件之间计算时间差，从⽽获取中间过程的耗时（精确到毫秒级别）。

页面准备阶段：cache、dns解析、tcp、ssl
页面请求阶段：HTTP Request处理、HTTP Response处理
页面渲染阶段：DOM 处理、⽂档装载完成

Google 中的核⼼⽹⻚指标有三个：LCP、FID 和 CLS。；75分位

LCP，最⼤内容绘制，视⼝中可⻅最⼤图⽚或⽂本块相对于⽤户⾸次导航到⽹⻚的呈现时间；衡量感知到的加载速度；<= 2.5s
FID，⾸次输⼊延迟，从⽤户第⼀次与⻚⾯交互直到浏览器对交互作出响应，并实际能够开始处理事件处理程序所经过的时间；衡量感知到的响应速度；<= 100ms
CLS，累积布局偏移，是⼀个重要的、以⽤户为中⼼的衡量视觉稳定性的指标；<= 0.1

FP，白屏时间；<= 1.8s
FCP，灰屏时间，首次内容绘制；<= 1.8s
longtask，长任务时间，>=50ms的js任务
Interaction to Next Paint (INP)，INP 是⼀项指标，通过观察⽤户在访问⽹⻚期间发⽣的所有点击、点按和键盘互动的延迟时间，评估⽹⻚对⽤户互动的总体响应情况；<= 200ms
TTFB（Time To First Byte），首字节到达时间;
TTI，首次可交互时间；<= 3s
js/img资源加载耗时；< 300ms, < 150k
首屏加载时间，FSP；利用 MutationObserver 自己计算

performance.getEntriesByName('first-paint')
performance.getEntriesByName('first-contentful-paint')

// fcp
 const observer = new PerformanceObserver((list: any) => {
        for (const entry of list.getEntries()) {
          if (entry.name === 'first-contentful-paint') {
            // ...
          }
        }
 });
 observer.observe({ type: 'paint', buffered: true });

//  lcp：largest-contentful-paint
// FID：first-input
// CLS：layout-shift
// longtask：longtask
const observer = new PerformanceObserver((list: any) => {
  let maxLong = null;
  for (const long of list.getEntries()) {
    if (maxLong === null || long.duration >= maxLong.duration) { // 获取耗时
      maxLong = long;
    }
  }
  observer.disconnect();
);
observer.observe({ type: 'longtask', buffered: true });

上报时机：window.requestIdleCallback、setTimeout
上报方式：navigator.sendBeacon、img、xhr、第三⽅

统计后结果：FCP >= 3.5s，需要优化

对数据上报的接⼝添加了⽩名单过滤、js拆包、图⽚压缩；
优化积分中⼼⻚⾯初始化接⼝请求逻辑：提前加载积分列表和详情接⼝，缩短业务侧耗时；
添加积分中⼼⻣架屏渲染时间统计，并进⾏上报；

收益：优化后LCP由3.5s左右缩短到1.5s左右，业务侧耗时较优化前缩短了2000ms左右；

# 性能优化

渲染优化：

css3动画、虚拟列表、长任务拆分，异步执行计算任务，rAF批量渲染
web worker 单开子线程执行计算比较复杂的任务，主线程只渲染数据结果
React组件用useMemo等缓存，避免重复渲染；恰当使用list key，避免diff重新渲染；
defer js优先，减少首屏DOM复杂度
减少重排重绘，简化dom操作，首屏css内联，减少css选择器复杂度，js外链放底部，css外链放顶部

http请求及资源加载优化

http强缓存，协商缓存；http2, cdn就近缓存；gzip压缩
组件懒加载，图片懒加载，预加载，路由懒加载，按需加载组件，雪碧图合并
低优先级资源异步加载，合并请求, 字体文件子集化
server worker离线缓存，客户端h5离线包，内容直出

构建优化

spitChunk拆分js；js压缩，css压缩，单独打包；多进程打包；静态资源打包压缩
tree shaking，scope hoisting；
不常用的第三方包cdn引入

架构策略优化

对搜索引擎排名有要求，想缩短白屏时间，可以考虑ssr渲染；SSR/SSG（静态站点生成）/流式 SSR；
组件库开发，有组件、文档、工具、实例等多个文件，可考虑用monorepo管理；
需要一套代码多端使用的，可考虑跨端框架，如taro、uni-app等；
模块化与组件化，高复用，低耦合，引入监控

# 秒杀页面，下单支付页面架构设计

视图层：
- 倒计时（减少diff渲染），innerText，获取服务器时间计算offset，定期用接口校准纠偏；极端情况（浏览器休眠）
- 秒杀按钮，动画，首屏重要静态资源预加载，组件封装；瀑布流+虚拟滚动
- 静态资源缓存，请求分级（p0/p1），低优先级异步加载；
业务层：秒杀资格判断 => 库存校验 => 订单创建 => 支付回调 => 状态更新；
数据层：
- 防重 + 状态机锁（isSubmitting） + 前端生成幂等 Key ；双token去重（前端幂等+后端payToken）；维护请求队列（高峰）；超时查询；
- 高并发重试策略（随机抖动，前端熔断，指数回避）；轮询查状态；取消请求逻辑处理；
- 下单状态：Idle → Submitting → Success | Failed | Cancelled | Queued
- 支付状态：未发起、创建支付、排队/等待通道（后端处理？）、处理中、成功/失败/取消、不确定态 UNKNOWN

# Taro跨端项目

好友助力、拉新返现、订单返现模块迁移到taro

实践问题：

taro 里面普通的div绑定addEventListener事件无效，需要用ScrollView组件进行绑定
taro 中使用 scrollIntoView 无效，换成ScrollView组件的scrollIntoView

优势：

React生态集成：可直接使用 React Hooks、Redux 等熟悉的状态管理方案；
多端适配能力：小程序端：支持微信、支付宝、百度、字节等主流小程序平台；可通过条件编译实现端特有功能
支持 CSS Modules、Sass、Less 等样式方案；完善的 TypeScript 支持，类型提示准确；开发工具链完善；

劣势：

性能问题：小程序端 setData 性能瓶颈；复杂列表渲染时性能下降明显；首次加载时间较长；大量动画场景表现不佳；
跨端兼容性：不同端 API 差异需要额外适配；复杂 UI 组件难以复用；样式兼容性问题需要特别处理；第三库兼容性需要评估

编译运行原理：

编译流程：
1. 代码解析阶段：源代码 =》解析jsx/tsx =》 AST转换 =》条件编译处理 =》分析依赖关系；
2. 代码转换阶段：组件转换，API转换，样式转换；
3. 代码生成阶段：生成目标平台代码，处理静态资源，生成项目配置文件
运行时处理：
1. 框架运行时初始化：生命周期映射，事件系统处理，状态管理适配；
2. 组件运行时：组件映射，属性转换，事件处理；平台适配层在组件渲染时会进行组件映射、API适配、样式适配
3. API运行时：API抹平层，平台差异化处理，polyfill支持
4. 平台执行阶段：渲染原生组件，处理原生事件，执行平台API

# 问题收集

Taro 的跨端核心原理是什么？编译时还是运行时？各端产物长什么样？

@tarojs/cli 是 Taro CLI 工具。CLI 里预先挂载了一系列的内置插件，每个命令、每个编译平台都是一个单独的 Taro 插件。

本质是“统一 React/Vue 语法 + 多端适配”，同时包含编译时和运行时两部分：
- 编译时 ：把你写的 TSX/JSX、模板语法、配置等转换成目标端能理解的结构（尤其是小程序端的模板/配置/样式等）。编译小程序时，CLI 会调用 @tarojs/mini-runner：
  - 负责根据开发者的编译配置调整 Webpack 配置；
  - 注入自定义的 PostCSS 插件；注入自定义的 Webpack 插件；注入自定义的 Webpack Loaders；
  - 调用 Webpack 开启编译；
  - 修改 Webpack 的编译产物，调整最终的编译结果。
- 运行时 ：在各端提供一套运行时适配层，把组件生命周期、事件、更新机制等桥接到目标端（小程序、H5 等）的运行环境里。@tarojs/runtime 是 Taro 的运行时适配器核心，它实现了精简的 DOM、BOM API、事件系统、Web 框架和小程序框架的桥接层等。
  - 为了让 React、Vue 等框架直接运行在小程序端，需要在小程序的逻辑层模拟浏览器环境，包括实现 DOM、BOM API 等。
  - Web 框架就可以使用 Taro 模拟的 API 渲染出一颗 Taro DOM 树，但是这一切都运行在小程序的逻辑层；而小程序的 xml 模板需要提前写死，Taro 如何使用一个静态的模板文件去渲染这颗动态的 Taro DOM 树呢？
  Taro 选择了利用小程序 <template> 可以引用其它 <template> 的特性，把 Taro DOM 树的每个 DOM 节点对应地渲染为一个个 <template>。这时只需要把 Taro DOM 树的序列化数据进行 setData，就能触发的相互引用，从而渲染出最终的 UI。
典型产物：
- H5 ：接近普通 Web 应用（React/Vue + Webpack/Vite 打包产物），DOM 直接渲染。
- 小程序：各平台的小程序产物（页面/组件的模板文件、逻辑 JS、配置 JSON、样式文件等），由小程序自身渲染层渲染，不是 DOM。
- 其他端（如 RN 等）：取决于项目是否启用对应端的适配与渲染方案，整体也是“目标端原生运行环境 + Taro 运行时适配”。

Taro 的编译链路/构建流程：JSX/TSX 如何转小程序？中间做了哪些转换与约束？

面试回答要点：Taro 的核心是“把组件树/页面结构静态化为模板 + 把动态部分变成数据驱动的绑定”。
过程可以这么讲（不讲过细实现细节，避免说错）：
- 解析源码：对 TS/JS、JSX/TSX 做语法解析，拿到结构化表示（AST）。
- 端能力约束与降级：识别不适合小程序渲染层的写法（例如依赖真实 DOM 的行为），在编译期做限制提示或转换成等价写法。
- 结构生成：把 JSX 里的结构映射到小程序组件/标签体系，生成模板（各端方言不同）。
- 数据/事件绑定生成：把 props/state/循环/条件渲染等变成模板绑定表达式、事件绑定，并生成相应的运行时胶水代码。
- 输出与打包：根据路由/页面配置生成各页面的配置文件与依赖关系，处理样式（px/rpx 转换、作用域等），最终输出到目标端目录结构。

为什么小程序端对 React 语法/DOM 能力有天然限制？Taro 里哪些点“能写但容易踩坑”？

根因：小程序是“双线程/双层模型”（逻辑层 + 渲染层），渲染层不是浏览器 DOM，UI 更新依赖数据通信（setData/数据桥），所以很多 Web 的能力在小程序端要么不存在，要么成本很高。
常见坑位（面试高频）：
- 直接依赖 DOM/布局测量 ：例如随意用 document/window 、依赖 DOM API、复杂的实时测量与动画。小程序要走 selector query、节点信息能力有限且异步。
- 高频更新导致性能问题 ：滚动跟手、mousemove 类交互、动画每帧 setState，会放大成高频 setData 通信，容易卡顿。
- 事件差异 ：事件对象字段、冒泡/捕获、手势事件在不同小程序端不完全一致；H5 写法照搬会出问题。
- 样式能力差异 ：CSS 特性支持不一致（尤其高级选择器、某些布局/特效），以及端侧样式隔离规则不同。

Taro 的运行时机制：生命周期、事件系统、setState 如何映射到小程序 setData？更新粒度与性能瓶颈在哪里？

核心认知：在小程序端，最终 UI 更新基本都要落到“把数据同步到渲染层”。Taro 的运行时负责把你熟悉的组件模型（state/props/lifecycle）映射到小程序页面/组件实例，并把更新合并后通过 setData（或等价更新接口）提交。
生命周期：React 组件生命周期/Hook 运行在逻辑层；页面级还要对齐小程序的页面生命周期（onLoad/onShow/onHide 等），通常由框架做映射/补齐。
更新粒度与瓶颈：
- 瓶颈通常不在 diff 本身，而在“跨线程数据通信 + 渲染层更新成本” 。
- 高频、大片数据、深层对象频繁变更会导致 setData payload 变大、序列化/传输开销增大。
你可以给面试官一个“工程化结论”：
- 少做高频 setState；把高频动效交给 CSS/原生动画能力或节流；拆分组件与数据结构，控制 setData 的体积与频次；避免巨型列表一次性渲染（用虚拟列表/分页/分片）。

多端差异治理怎么做：条件编译、适配层、组件/样式兼容策略？如何避免平台判断污染？

面试官想听的是“你有体系”，而不是到处 if (process.env.TARO_ENV) 。可以按三层讲：

架构层：适配层（Adapter/Port）

把“平台差异能力”封装成少数几个模块：如 storage 、 network 、 auth 、 clipboard 、 map 、 media 。业务只依赖适配层接口，不直接碰平台 API。

UI 层：跨端组件 + 端特化组件并存

绝大多数组件走跨端实现；少数差异大的组件做 Component.h5.tsx / Component.weapp.tsx 这种“同名多端实现”，由构建选择正确文件，业务侧不写条件分支。

工程层：条件编译只放在边界处

条件编译/平台判断集中在：适配层实现、端特化组件入口、少量路由/配置差异。
业务代码里原则：不出现平台判断；确实需要也通过 hook/工具函数抽象掉。
样式策略：统一设计变量/Token（颜色、间距、字号），用一套规范控制 rpx/px、暗黑模式、主题；对不稳定的 CSS 特性避免依赖，或提供端侧降级。

Taro 跟 uni-app、React Native、Flutter（或 KMM）跨端方案的本质区别是什么：渲染架构、性能模型、生态与团队技术栈成本各怎么权衡？你为什么选 Taro？

Taro（偏“前端工程化 + 多端编译适配”）
- 核心优势：对 Web/React/Vue 技术栈友好；能同时覆盖 H5 + 各类小程序；团队学习成本低；业务迭代快。
- 核心限制：受小程序宿主能力上限影响（UI/动画/渲染能力、节点能力、复杂交互）；性能天花板更接近“小程序原生”而不是原生 App。
uni-app（偏“Vue 生态 + 一体化工具链”）
- 适合：团队 Vue 为主、追求“上手快、插件多、生态一条龙”。
- 常见取舍：生态便利，但深度定制/工程可控性因团队、项目结构差异而不同；复杂场景依旧会遇到各端差异治理问题（不是框架能完全抹平的）。
React Native（偏“运行时跨端，原生渲染”）
- 适合：目标是 iOS/Android App，想要更接近原生的交互与性能；愿意投入原生侧能力建设（原生模块、桥接）。
- 局限：对小程序并不是天然目标（需要额外方案）；基础设施和发布链路更偏 App 研发。
Flutter（偏“自绘渲染引擎”）
- 适合：高一致性 UI、复杂动画/高帧率诉求强、希望跨 iOS/Android/桌面等统一体验。
- 取舍：包体积、与原生/现有 Web 体系融合成本、团队语言/生态（Dart）成本；对小程序不是典型主战场（存在探索方案但不是主流“稳态”路径）。
面试里讲“为什么选 Taro”可以这样落点
- 业务目标是 H5 + 多家小程序覆盖，而不是追求“原生 App 极致体验”。
- 团队技术栈（React/TS/工程化）可以直接复用，交付效率高。
- 清楚承认边界：复杂交互/高性能动画场景会做端内差异化（必要时原生/自定义组件/降级策略），而不是幻想“100% 一套代码无差异”。

跨端项目的路由、分包与资源管理怎么做：小程序分包/预加载、H5 路由模式、端侧限制（包体积、页面栈）在 Taro 中如何落地？

路由策略
- H5：通常采用 history/hash 路由（看部署条件），配合动态 import 做页面级拆包。
- 小程序：路由是页面栈模型（navigateTo/redirectTo/switchTab 等），栈深、跳转方式、tab 页规则都有限制；路由“形态”与 H5 不同，通常在业务层抽象“导航服务”统一入口，避免散落平台判断。
分包与首屏
- 小程序：必须关注包体积与首屏性能。做法一般是：
  - 主包只放首屏必需页面与公共基础能力
  - 业务按域拆分包（例如：用户中心、营销、订单）
  - 控制公共依赖下沉：把“很大但低频”的依赖放到分包，或做能力拆分
  - 配合“预下载/预拉取/预加载”（各平台能力不同）减少二跳等待
- H5：利用浏览器缓存、HTTP 缓存策略、按路由拆包 + 预加载关键 chunk。
资源管理
- 图片/字体/多媒体：小程序对资源体积、加载方式、域名白名单等约束更严格；H5 则关注 CDN、缓存与首屏关键资源优先级（preload/priority）。
- 多端一致性：尽量把“资源路径/域名/环境变量”集中配置；在 CI 里分别产出各端构建产物，避免手改。

跨端中的样式体系如何保证一致性：CSS Modules/Sass、设计稿适配（rpx/px/viewport）、样式隔离、原子化/Design System 在多端分别会遇到什么坑？

一致性的“现实原则”
- 多端不可能完全像素级一致，目标更合理的是：布局一致 + 关键视觉一致 + 交互一致，少量端差可接受且可控。
适配策略
- 小程序常见单位是 rpx（不同平台实现略有差异）；H5 通常用 px/viewport 方案。跨端项目里建议：
  - 形成统一的设计 token（间距、字号、圆角、颜色）
  - 对尺寸适配使用统一工具链（例如 px→rpx 或基于设计稿的换算），并把规则固化在构建/样式层
样式隔离与组织
- 建议组件级样式隔离（CSS Modules / BEM / scoped 思路），避免全局污染。
- 谨慎依赖复杂选择器、伪类/伪元素、某些 CSS 特性（不同小程序内核支持差异、以及与宿主组件实现有关）。
Design System
- 最稳的是“组件库 + token”：把按钮/表单/弹窗/列表骨架等抽成跨端组件，业务只组合，不到处写样式。
- 对极端差异组件（如长列表、富文本、复杂弹层）准备端内实现或降级版本。
常见坑（面试高频）
- 字体与行高在不同端渲染差异导致抖动/截断
- 1px 边框、阴影、fixed/sticky 在不同端表现不一致
- 弹窗层级（z-index）与滚动穿透处理在小程序/H5差异大

跨端状态管理与数据请求怎么设计：Redux/Zustand/MobX/Context 选择依据是什么？多端存储、登录态、网络层（拦截器、重试、并发控制）如何统一？

状态管理选型逻辑（面试要点是“边界清晰”）
- 本地组件状态：只影响当前组件/页面的，用组件 state。
- 页面级状态：页面内共享但不需要全局，用页面 store 或轻量方案。
- 全局状态：登录态、用户信息、权限、全局配置、购物车等，用全局 store（Redux/Zustand/MobX/Pinia 等按团队栈选）。
- 关键点：避免“所有东西都塞全局”，否则依赖混乱、更新难控。
网络层统一
- 抽象一个 request 模块：统一 baseURL、header、错误码处理、超时、重试、取消、日志（注意不要打敏感信息）。
- 拦截器能力：请求前注入 token；响应统一处理“登录失效/刷新 token/业务错误码”。
- 并发控制：常见需求是“同一接口合并/去重”“token 刷新时队列挂起后重放”“避免重复提交”。
多端存储与登录态
- 存储抽象：把 localStorage/小程序 storage 统一在一个 storage service 里；约定 key、版本、过期策略。
- 登录态：明确“token 过期”的策略（静默刷新 vs 强制重登），以及在多端的跳转差异（H5 路由 vs 小程序页面栈）。
我不确定的点说明
- 各小程序平台对“预拉取/预下载”与网络能力的具体 API 细节、限制参数会有差异，面试时可以说“策略一致、实现按平台文档落地”。

跨端的性能与工程化你怎么做：首屏/包体积优化、按需加载、缓存策略、埋点与监控（各端差异）、自动化测试与 CI/CD（多端构建发布）怎么落地？

性能优化抓手（按“可度量”回答）
- 首屏：减少主包体积、减少首屏接口数量与串行依赖、关键资源优先加载、骨架屏/占位提升感知性能。
- 包体积：按路由拆包、依赖按需引入、避免引入大而全库、剔除无用 polyfill、多端分别做构建分析（bundle 分析）。
- 渲染性能：避免过深组件树与高频 setState；长列表做虚拟列表/分页；减少不必要的重渲染（memo/useMemo/useCallback 的合理使用）。
缓存策略
- H5：HTTP 缓存 + CDN + Service Worker（若项目允许）+ 接口缓存（按业务场景）。
- 小程序：更多依赖本地存储缓存（带版本与过期）、预拉取/预加载能力（平台差异存在），以及减少重复请求。
监控与埋点（跨端要点是“统一模型，分端上报”）
- 指标统一：PV/UV、页面停留、首屏耗时、接口耗时、错误率、关键转化漏斗。
- 实现上：埋点 SDK 抽象统一接口，H5/小程序分别适配上报通道；错误采集包含 JS error、Promise rejection、接口错误。
- 注意：敏感数据脱敏，不记录 token/手机号等。
测试与质量
- 单元测试：工具函数、状态管理、请求层、关键业务逻辑优先（跨端最容易复用也最值得测）。
- 端到端：关键链路（登录/下单/支付前流程等）用最少用例覆盖；小程序 E2E 成本更高时，至少保证核心逻辑可测与灰度策略。
CI/CD
- 多端产物分开构建：同一代码仓库，CI 里按环境变量分别构建 H5 与各小程序产物。
- 配置管理：环境变量、域名、feature flag 集中管理；禁止手工改配置发版。
- 发布：H5 可走静态资源发布；小程序走各平台提审/发布流程，结合版本号与变更记录。

# 组件库

# 富文本编辑器

# ssr

# AI RAG知识库

目标：提供一个B端页面搭建聊天助手，方便用户通过提问查询如何搭建，方便用户快速上手搭建。

架构设计

视觉层：AI聊天助手、SSE流式输出
数据层：
- RAG模型（基于向量数据库）
- 向量模型（text-embedding-v4）、LLM语言大模型、重排模型（Cohere Rerank 3）、分类模型（用于路由分类模型）、向量数据库、向量存储VectorStore
底层支持：
- 敏感信息过滤、权限校验
- 日志与指标上报：
1. 把每一步耗时（检索、rerank、LLM）、命中率、失败率、token 成本、常见 query 分布都打点，异常时能定位是数据问题还是检索问题还是提示词问题。
2. 统计召回率，准确率，分析，优化；A/B测试，对比分析；

流程：

本地文档 =》文档切分 =》通义向量模型存储chunk到向量数据库；
前端传入问题 =》query向量化 =》去向量数据库检索 =》返回topK的检索结果 + 系统提示词 + 提问 =》 LLM语言大模型生成回答。

RAG系统的评估指标

召回率（Recall）：检索到的正确文档数 / 总的相关文档数；召回率从39%提到了81%
准确率（Precision）检索到的正确文档数 / 检索到的总文档数；Precision@5从0.73提到了0.89
事实准确性：回答是否准确。人工评估，或LLM自动评分
忠实度（Faithfulness）：生成的答案是否忠于检索到的文档？有没有瞎编？
相关性（Relevance）：通俗解释：回答是否切题？

ragas (Retrieval Augmented Generation Assessment) 是一个专门用于评估 RAG 系统的开源框架。

怎么统计召回率？

准备 20~50 个真实问题（先小规模就行），比如来自客服/群聊/工单。对每个问题，人工看知识库，标出“哪些文档片段能正确回答这个问题”。给这些片段一个唯一 ID（如 doc_12#chunk_3 ），这组 ID 就是这个问题的 Gold （标准答案证据集）。
需要存成这样一张表：query_id ：问题编号 / question ：问题内容 / gold_chunk_ids ：人工标注的相关片段 ID 列表

// 示例
q1 | "如何配置页面变量？" | [c101, c205]
q2 | "发布后如何回滚？"   | [c330]
q3 | "事件流怎么配置？"   | [c410, c411, c512]

然后每个问题去检索，拿 TopK 结果（比如 K=3），记录系统返回的 chunk ID 列表：

q1 -> [c101, c777, c205] // 系统返回的TopK结果，命中了c101和c205，召回率: 2/2=1; 准确率：2/3=0.66
q2 -> [c888, c330, c999] // 命中了c330，召回率: 1/1=1; 准确率：1/3=0.33
q3 -> [c410, c700, c800] // 命中了c410一个，召回率: 1/3=0.33; 准确率：1/3=0.33

计算召回率：命中的相关片段数 / 该问题人工标注的相关片段总数，统计平均值

有哪些优化策略？

查询优化：让大模型生成多个语义相似但表达不同的查询，然后用这些查询去检索，最后合并结果。（提高召回率，覆盖多角度，鲁棒性强）
路由优化：使用LLM作为路由分类器，根据用户查询，自动将查询分类到不同的路由中：sql查询、向量查询、网页查询。
分块优化：人工整理Q&A对，按固定格式组织成文档；按问题间空格分块，按语义分块。
检索优化：排序、过滤，使用重排模型（Cohere Rerank 3）对检索文档的相关性进行评分和排序，再重排，返回topK

怎么解决用户提问不在知识库范围内的问题（OOD，Out-of-Domain）？

在检索前、检索中、检索后、生成时层层过滤

检索前用分类模型给提问贴标签，不在预设标签范围内的提问不进行检索；
混合检索（关键词+向量），用BM25做关键词精确匹配；
重排序，排序打分，强约束系统提示词（不得胡乱编造）
强制引用、无证据不回答

为什么选择Langchain.js？

含有Models，Prompts，Memory等多个模块，提供了一套工具、组件和接口，简化了创建LLM应用的过程
Chains支持链式调用，支持数据流式传递，易于多步任务编排。
社区活跃，生态丰富，比其他同类框架成熟，支持LangGraph图标工作流，配置更灵活，方便进行自定义开发，也方便后续扩展

LlamaIndex支持索引查询，一站式文档处理，但不能灵活控制流程，而且社区不如langchain成熟
Qwen-Agent轻量，集成度高，配置简单，开箱即用；但不适合灵活配置场景。

LanChain做编排，LlamaIndex做索引。

Q：你项目中用了什么分块策略？为什么选它？

滑动窗口 + 句子边界

首先按句子边界切分，保证每个块语义完整
然后使用滑动窗口，设置20%重叠 (常见配置: chunk_size=512, overlap=50-100)
重叠确保跨块的信息不会丢失

选择原因:

我们的知识库是产品FAQ，段落之间有上下文依赖
用户问题可能涉及多个连续段落的信息
20%重叠在存储开销和检索质量间取得平衡

Q：Embedding模型选择都有哪些考虑因素？

语言支持：中文场景: BGE、text-embedding-v4；英文场景: OpenAI系列；多语言: bge-m3
部署方式：API调用: OpenAI、通义；私有化部署: BGE、M3E；混合: 都支持
性能指标：

延迟: 本地部署 < API调用；
吞吐: 取决于硬件/并发；
精度: 需要在自己数据上测试

成本考量：API按量付费，初期低；私有部署需GPU，长期划算；维度影响存储成本

Q：你在项目中用了哪个 Embedding 模型？为什么选它？

我使用了阿里的 text-embedding-v4:

中文优化: 我们的知识库主要是中文文档，该模型在中文语义理解上表现优秀
维度可配: 支持512/1024维度，我选择1024维，在精度和存储间平衡
成本合理: API价格比OpenAI便宜，适合我们的预算
生态兼容: 与通义千问系列模型配合使用，接口统一

Query和Document必须使用相同的Embedding模型：更换模型需要重建整个向量索引；建议在自己的数据集上做A/B测试选模型

Q：如果你的 RAG 效果很差，你会从哪几个方面去调试？

一、检索问题：找不到相关内容

召回内容不相关

原因：Embedding模型对领域词理解差
解决方案：换用领域微调的Embedding，或加同义词扩展

答案散落在多个块

原因：分块太小，信息被切断
方案：增大chunk_size，增加overlap

噪声太多

原因：分块太大，混入无关内容
方案：减小chunk_size，添加Rerank

用户口语化问题检索差

原因：用户问题与文档表述风格差异
方案：Query改写，HyDE假设文档生成

Top-K太大/太小：调整K值 + Rerank

二、生成问题：找到了但答案不对

答案与检索内容不符

原因：LLM幻觉，未遵循上下文
方案：强化Prompt指令："仅基于背景知识回答"

答案过于简短

原因：Prompt 未要求详细解释，导致答案过短
方案：添加输出格式要求

答案冗长有很多废话

原因：上下文噪声多
方案：Rerank精选，减少喂给LLM的内容

无法处理复杂推理

原因：LLM能力不足
方案：换用更强的模型，或添加CoT

Q：当用户的问题模糊，RAG 怎么优化？

step1: 问题类型分析

指代消解（它的退票政策是什么？），它指谁？：结合历史对话改写query
省略补全（那儿童票呢？）,省略了"退票政策"的上下文：从历史中补充完整语义
模糊问题（怎么买票？），缺少具体场景 (线上/线下/团购）：Query扩展或追问

Step2，Query 改写技术

历史融合，结合对话历史
query扩展，添加同义词
HyDE生成假设文档：先让LLM生成假设的答案文档，再用假设的答案文档的向量去检索，而不是原始Query
多Query生成多个变体

实践建议：

对话历史不宜过长，一般保留最近3-5轮
可以用LLM判断是否需要改写，避免每次都改写
改写模型可以用较小的模型，降低延迟
记录改写前后的Query，便于调试

Q：你只用了向量检索吗？它有什么缺点？什么是混合检索？

向量检索的缺点:

对精确关键词匹配不敏感 (如产品型号、人名)
可能漏掉字面完全匹配的内容
Embedding模型对领域专有词理解可能不准

混合检索: 结合向量检索和关键词检索 (BM25)，取长补短

Q：召回了 20 条文档，怎么确保给 LLM 的是最好的 3 条？

使用 Rerank (重排序)技术，对初步召回的结果进行精排。

Bi-Encoder (向量检索)，粗排：Query和Document分别编码，计算向量相似度

速度快，适合大规模召回
Query和Doc独立编码，交互信息少
精度相对较低

Cross-Encoder (Rerank)，精排：Query和Document拼接后一起编码，直接输出相关性分数

精度高，能捕捉细粒度交互
速度慢，只能处理少量候选
适合对Top-K精排

Rerank 实践建议:

召回数量 (recall_k) 一般设置为最终需要数量的5-10倍
Rerank模型选择: 中文推荐 BGE-Reranker，多语言用 Cohere
Rerank会增加延迟，需要在效果和速度间权衡
可以设置分数阈值，过滤低相关性结果

Q：系统上线后，你怎么维护和迭代你的知识库？

知识库维护是一个持续的过程，包括以下几个方面：

内容更新：新文档入库，旧文档更新，过期内容删除
质量监控：Bad Case收集，检索日志分析，用户反馈
版本管理：索引版本控制，回滚机制，A/B测试
自动化：定时增量更新，自动质量检查，告警监控

维护最佳实践:

定期审核: 每周/月审核Bad Case，识别系统性问题
增量更新: 避免全量重建，使用增量方式更新索引
版本控制: 保留历史版本索引，支持快速回滚
文档生命周期: 设置过期时间，自动标记/清理过期内容
监控告警: 检索空结果率、用户负反馈率等指标超阈值时告警

Q：如何处理知识库中的矛盾信息？

为文档添加时间戳元数据，优先使用最新的
为文档添加权威度标签，优先使用官方来源
检索时同时返回多个来源，让LLM综合判断
在Prompt中要求LLM指出信息冲突

Q：RAG 系统的延迟优化有哪些方法？

向量检索: 使用ANN索引 (HNSW, IVF)，降低精确度换速度
Embedding: 使用本地小模型，或异步预计算
Rerank: 减少候选数量，或使用蒸馏小模型
LLM: 使用流式输出，选择更快的模型
缓存: 相似Query复用检索结果

Q：如何处理超长文档？

分层索引: 先检索摘要，再检索详细段落
滑动窗口: 保留上下文的分块策略
长上下文模型: 使用支持128K+的模型 (如Qwen, Claude)
迭代检索: 先检索一部分，根据LLM判断是否需要更多

Q：如何防止 LLM 幻觉？

Prompt 明确指令: "仅基于提供的信息回答，不确定时说不知道"
要求引用: 让LLM标注答案来源于哪个文档
降低 temperature: 减少随机性
答案验证: 用另一个LLM检查答案是否有上下文支撑
Rerank 精选: 确保上下文高度相关

Q：多模态 RAG 怎么做？

图片: 使用多模态Embedding模型 (如 CLIP, 通义VL) 将图片向量化
表格: 转换为Markdown或JSON，保持结构信息
PDF: OCR提取文字 + 图表单独处理
视频: 抽帧 + 语音转文字，分别建索引
统一使用多模态Embedding，实现跨模态检索

Q：如何保证 RAG 系统的安全性？

Prompt 注入防护: 过滤用户输入中的指令
权限控制: 根据用户角色过滤可检索的文档
敏感信息处理: 脱敏后入库，或标记敏感级别
输出过滤: 检查生成内容是否包含敏感信息
审计日志: 记录所有查询和检索内容

Agent项目中的工程开发痛点&解决方案

全链路 Trace

痛点：模型答错后问题排查极慢，动辄半天，根本不知道从哪查起；无法追踪每条对话的完整执行过程和资源消耗
解决方案：记录每条对话的完整链路（Prompt 构建→模型调用→工具选择→工具执行→结果组装→流式输出）；实现分钟级问题定位

对话评估

痛点：产品和研发对 "回答好不好" 标准不统一，容易扯皮；缺乏量化指标，无法客观衡量迭代效果
解决方案：给每轮对话自动打分；跑同一批测试用例，对比迭代前后分数；统一产品验收、研发优化、测试回归的标准

Prompt 版本管理 & 调试

痛点：Prompt需要反复迭代，但验证周期极长（改→部署→人工体验→再改，一轮半天到一天）；多版本管理混乱，无法对比效果
解决方案：支持多版本并存、同一对话 A/B 对比；修改后立刻查看效果；将调试周期从半天压缩到几分钟

数据集管理

痛点：Agent 项目缺乏自动化测试，"正确性" 不是非黑即白；改了 Prompt 后无法判断效果是变好还是变差，不敢放心发版
解决方案：将典型场景固化成测试用例；每次改动后自动回归全量用例；对比历史结果，自动标出退化问题

# Vibe Coding的应用

# B端运营平台的 Harness Engineering 工程实践

背景：

运营平台里有很多CRUD类页面，里面的功能主要是增删改查类的表单功能；之前开发页面都是粘贴复制，然后改一改，里面代码逻辑比较重复；人效低；
有些业务代码逻辑比较复杂，容易忘，每次查问题的时候，都需要去一步步翻代码，耗时长；

实践：

Claude Code建立开发规范：CLAUDE.md、rules/*md，定义运营平台的开发规范和整体业务逻辑，以及各个文件的功能，以及项目代码组织逻辑；Skill/*md中定义每个业务逻辑的核心业务逻辑，以及备注内容（比如开发时与后端约定好的参数定义逻辑，接口调用逻辑，等等），方便后续查问题时，可以直接问AI，比如：

比如帮我查下项目中有哪些业务模块用到了优惠券或满减券，以及是什么业务场景下用的，各有什么差异？
或者工单创建流程是什么，涉及哪些业务模块？现在需要在工单发布上云之前添加质检操作，帮我梳理下添加该操作需要涉及修改的业务逻辑以及涉及的代码文件

hooks中可以一些脚本命令，方便在代码开发过程中执行一些操作；agents.md业务知识文档化；Skill/*md中也配置了一些页面模板，比如CRUD页面的模板，方便快速生成新的CRUD页面
建立 Spec 模板库：Spec/*md，定义每个业务逻辑的 Spec 模板，比如：list组件，按钮组件

step1: AI理解业务：代码库+文档 =》全景图 + 链路图；沉淀agent.md；
step2: Spec模式技术设计：需求理 + 理解 =》文档 + demo + 50%代码；沉淀Spec模板+skill；
step3: 人工Review + 补充：数据流转/外部依赖/个性化逻辑；沉淀踩坑记录；

收益：

可以快速帮助新人熟悉项目业务逻辑；之前排查问题需要去一步步翻代码，耗时长，现在可以直接问AI，耗时短；
之前开发一个CRUD页面，开发加联调一般在2.5天左右，现在1.5天左右；

# H5营销模块Harness Engineering 工程实践

背景：H5营销模块式包括秒杀、好友助力、新人福利、积分等不用用增的营销模块；里面有很多可复用的业务场景；想通过 AI 来加速开发，提高开发效率。

传统开发模式：产品设计 → 开发编写代码 → 测试验证 → 人工审查 → 上线

重复性编码工作量大（多状态切换、样式调试）；测试依赖人工，回归测试成本高；文档与代码容易脱节；开发周期长（复杂模块 5-7 个工作日）

AI协作模式：产品设计 → 编写 Spec 文档 → AI 生成代码 → 人工验证 → AI 自动化测试 → 上线

AI 承担重复性编码工作；AI 驱动自动化测试，质量闭环；文档与代码同步更新

团队沉淀出 "文档驱动 + AI 执行" 的开发范式：设计稿/Figma → Markdown Spec 文档 → AI 生成代码 → 验证 → 文档同步

组件 Spec 文档示例：

# 组件名称

## 功能描述
组件的核心职责和使用场景

## 尺寸规范
具体的宽高、间距、字号等数值

## 样式细节
颜色、圆角、阴影、图标 URL 等

## 交互行为
hover、click、右键等事件响应

## 数据结构
TypeScript 类型定义

团队建立了三层文档体系，让 AI 在不同粒度上理解项目：

项目级：CLAUDE.md，项目架构、技术栈、开发命令
规范级：AGENTS.md，代码风格、命名规范、导入顺序
组件级：src/components/*/doc/*.md，25+ 份组件规格文档
第三方skills: front-design, fullstack-developer, repository-analyzer, project-understanding
自己的skills: code-review, code-format, code-test, code-deploy，用于代码质量检查、格式化、测试等操作

收益：

代码采纳率：90%以上；AI 静态审查在编码阶段发现 4 个 P0/P1 Bug；开发周期缩短：首页模块从 5-7 天缩短到 4 天核心开发；
组件文档沉淀

可复用的方法论：

Step 1: 准备输入材料
├── 测试用例 Excel/文档（QA 提供）
├── Figma 设计稿（导出 HTML 或截图）
├── API 协议文档（完整的请求/响应字段说明）
└── 项目规范（CLAUDE.md 中的架构模式和约定）

Step 2: 为每个子模块编写 doc.md
├── 功能描述 + 业务逻辑
├── API 协议（请求参数 + 响应字段）
├── Figma HTML 参考代码
├── 布局规格 + 响应式断点
└── 特殊交互说明

Step 3: AI 生成代码
├── 按模块逐个生成（index.tsx + Store.ts + types.ts + 子组件）
├── 人工审查 AI 生成的代码，确认架构模式一致
└── 补充 AI 无法处理的平台 API 调用细节

Step 4: AI 驱动测试
├── Ducc 静态代码审查（对照测试用例 Excel）
├── Ducc 编写 + 执行 E2E 测试脚本
├── 根据测试报告修复 Bug
└── 迭代至通过率达标

# 多 agent 系统难以控制，实践中出现各类问题

架构约束（Architectural Constraints）

Q：流程推进混乱，还未完成需求和技术方案评审，windows开发者已经开始进行代码开发；多 Agent 协作时，如何通过硬性约束防止越权行为和状态混乱？

任务依赖硬编码：所有 stage 的依赖关系在启动时就写入 Task 系统，形成有向无环图。Agent 无法绕过依赖关系自行推进。
结构化状态管理：沉淀过程文档（progress / task_plan / task_status / findings）实现流程可观测，JSON 物理锁确保状态互斥，避免了分布式写冲突和状态撕裂。
三步唤醒协议：每个 Agent 启动时强制执行 Workspace 校验 → 代码状态检查 → 进度同步，确保动作一致性。
工具权限隔离：通过工具限制防止 agent 越界修改。

上下文工程（Context Engineering）

Q：Agent 执行任务时上下文耗尽，突然没有响应，状态未知，流程无法继续推进；多 Agent 并行时，如何精准获取正确信息，避免上下文污染和浪费？

差异化上下文注入：按角色精细裁剪上下文注入给每个 Agent 的运行时信息，架构师读取技术知识文档，需求负责人只读PRD。
知识工程代替源码扫描：禁止全量扫描代码库，知识库按代码层分层组织，code-map.md作为唯一入口。通过结构化文档获取架构信息，从功能→路径映射出发，避免全盘扫描带来的噪音和成本。
Context Reset 协议：Agent 耗尽上下文窗口时，自动生成交接内容 → 终止当前实例 → 新Agent注入交接内容启动替换实例，实现任务无损续接。

熵管理（Entropy Management ）

Q：长任务流程中输出逐渐偏离目标，多个agent进行多轮讨论，无法停下；随着流程推进，如何防止信息降级、状态漂移和知识流失？

闸门机制：每个阶段设定对应闸门，所有条件满足后进入下一阶段。反馈-循环保证生成质量达到标准，防止下游工作在上游未稳定前开始，阻断熵传播。
熔断器模式：单阶段连续 3 次失败 → 暂停该阶段；累计 5 次不同错误 → 全局停机；闸门 3 轮未通过 → 冻结并升级人工干预，对异常情况紧急停止。
执行沉淀协议：过程中经验和知识进行蒸馏，为下一次的流程做优化。规则明确：只提炼通用价值，去重已有条目，无新经验则跳过。防止知识库膨胀，也确保有效经验不丢失。

# OpenClaw的应用

业务场景：线上紧急修复、灰度发布前、活动页临发版 做法：在群里 @openclaw 触发固定流水线： lint + typecheck + unit + build + bundle budget + lighthouse ，结果直接回到聊天里（甚至附带报告/链接）
设计系统/组件库“规格化交付”：Spec 产物直接变成可执行资产

业务场景：Button/Modal/Table 这类组件，最怕“功能看似齐全但交互边界/A11y/受控模式没做对”
做法：先用 Spec 定义 Props/slots、键盘交互、ARIA、受控/非受控、主题变体；OpenClaw 驱动生成/补全：

运营后台“列表-筛选-导出”闭环自动化：防参数漂移与一致性翻车

业务场景：B 端后台需求高频变更，最常见 bug 是筛选参数/导出参数不一致、空错慢状态漏处理
做法：Spec 固化 QuerySchema、序列化规则、导出一致性策略；OpenClaw 触发回归用例（fixtures）：

线上故障“前端值班助手”：从告警到定位/止血更快闭环

业务场景：白屏、接口异常、CDN 资源 404、特定浏览器崩溃
做法：监控/告警 Webhook → OpenClaw 聚合关键信息（版本、路由、错误堆栈、最近发布变更）→ 自动生成排查路径与临时止血方案（开关降级/回滚建议）→ 必要时创建修复分支并跑门禁

定时“健康巡检”：把前端工程隐患变成每天自动汇报

业务场景：依赖漏洞、包体积慢慢膨胀、关键页面性能回退、i18n/a11y 退化
做法：用 OpenClaw 的 Cron 定时跑：依赖审计、bundle budget、关键路由 Lighthouse、端到端冒烟；结果每天推送到群里（Cron/Webhook 能力在官方文档的功能列表中有提及，来源同上）

# Cluade Code

约束层（.claude/claude.md）：工具使用（mcp、知识库、文件），代码库路径，知识库说明；通用能力和方法，为AI设定规范；
知识层（claude/knowledge）：全局架构图、业务模块知识、跨层功能、数据流、共享层、知识模板
Skill层（.claude/skills）:ai-bugfix，code-review，figma-to-code

————————————

# 离职原因

前司是一家做少儿在线英语教育的公司，19年教培行业因不可抗力发生大规模调整，原有的业务线被缩减。考虑到个人长期的稳定发展，我更愿意选择寻找一个更稳健、且业务方向更具前景的平台。
虽然在boss直聘期间成长了很多，也做得还可以，但我在前司工作期间，前司是单双休上班机制，且加班比较严重，长期加班导致我身体一直处于亚健康状态；考虑到身体健康原因，更倾向于选择一个wlb的公司
部门业务线发生调整，整个部门被拿掉了（被裁），且感觉个人发展进入了瓶颈期，想去一个AI业务方向的公司；为了持续提升自己的能力，我更愿意寻求一些新的挑战。
虽然我目前在百度做得还不错，因为我老家就是四川的，家里人希望我离他们近一点，方便照顾；在北京工作这么多年，我最近也是打断回到四川稳定下来，不打算做北漂了。目前百度所做业务跟AI方向没有直接关系，且部门经常调整，不能长期深耕在一个业务领域，我更希望去一个AI业务方向的公司，为了持续提升自己的能力，我更愿意寻求一些新的挑战。

——————————

# 自我介绍

你好，我叫周元，我之前在boss直聘、新浪微博等公司做过前端开发，目前是在百度萝卜快跑团队做前端开发工作。

做前端开发这几年做过的业务方向主要是用户增长，社区，电商、以及商业化相关的业务需求，

做过的业务模块类型也比较多，包括PC、H5、小程序、后台管理系统、全栈、跨端等等，都参与过，有一定的开发经验；

在前段基建项目上也参与过部门组件库搭建，脚手架，低码平台、监控平台等项目的开发。

目前我在百度所在团队主要负责日常业务需求的迭代开发与一些前端项目架构设计工作，目前属于一线开发+虚线带人这样一个角色，以上就是我的自我介绍~

——————————

职级：24年入职的时候是T5，今天4月份职级调整，不用T序列，把原来的T序列、P序列统一为数字职级；调整后职级为 7 级，六月份调整为 8 级，我理解对标T序列的话应该是T6或者T5+吧

上次更新: 9/11/2026, 7:53:26 PM