技术面逐项应答稿
面试官您好，我是韦业，有三年前端开发经验，目前负责智慧停车业务的前端开发。我参与搭建了覆盖车主端 H5、小程序和运营管理后台的平台，负责停车缴费、欠费追缴、订单和设备运维等核心模块，推动停车欠费查询、在线缴费和运营跟进的业务闭环落地。此外，我是 Wot UI 组件库核心成员，主导开发过高扩展性的瀑布流组件，也参与了 Wot Starter 脚手架建设。我具备 C 端小程序、H5 及 B 端复杂业务开发经验，与贵公司的岗位场景比较匹配，期待进一步交流。谢谢。
一、开源贡献
1. "介绍一下你在 Wot UI 中的角色和贡献"
- 考察开源参与深度、协作能力、组件设计能力。
我是 Wot UI 的核心成员之一。Wot UI 是一个面向 UniApp 的移动端组件库，目前有 2.3k+ Star，今年还获得了 Gitee 平台年度开源项目第一名。
我重点主导的是高拓展性瀑布流组件。这个组件在 UniApp 跨端下的挑战很大——各平台渲染机制和 DOM API 都不一致，而瀑布流又依赖精确的高度测量和异步加载。
我设计了一套基于队列驱动的增量排版引擎，核心机制是：
第一，排版队列 + 最短列优先算法。子项挂载后不立即计算位置，而是进入一个等待队列，由排版控制器按序逐个消费。每次从队列头部取出一个加载完成的项目，找到当前高度最短的那一列追加到它后面。做到「加载一个、排版一个」，而不是等全部加载完再统一排，首屏速度更快。
第二，异步加载编排。子项挂载时注册到父组件，通过 Vue 的 watch + Promise 等待它的内容加载完毕、拿到 DOM 精确高度后才计算位置。如果超时，有最大等待时长兜底，使用默认高度继续排，不会阻塞整列。所有正在等待的 watcher 统一管理，页面切到后台时批量清理，防止内存泄漏。
第三，四级错误处理策略。暴露四种异常处理模式：失败即结束，用默认高度兜底、失败后显示占位图、自动重试指定次数、三层兜底——先重试、再占位图、最后文字兜底。使用者按业务场景选，不需要自己写容错逻辑。
第四，完整的布局生命周期。支持 reflow（列数/间距变化后保留数据重新计算位置，防抖 16ms）和 reset（清空所有数据准备接收新列表）。支持通过 order 属性在任意位置插入项目，插入后自动全量重排。页面切后台时中断排版并清理资源，切回前台时自动恢复。
另外我也参与了代码 Review 和 Issue 维护，帮助社区 contributor 更好地合入代码。
2. "Wot Starter 脚手架做了什么？"
- 脚手架的价值：降低上手成本
- 最佳实践示例代码 + 文档，帮助数百名开发者落地
Wot Starter 是 Wot UI 的官方项目脚手架。我参与建设时，重点做的是编写完整的最佳实践示例代码和文档——因为 UniApp 项目的配置链路比较长（Vite 插件、主题定制、按需加载、跨端适配等），很多新用户第一步就卡住了。我把这些典型场景做成开箱即用的模板工程，配合文档说明，用户 clone 下来就能跑起一个带真实业务结构的项目。目前项目 1k+ Star，社区反馈说确实帮他们省了不少踩坑时间。
二、工作经历总览
3. "你在稳安特科技担任前端负责人，具体负责什么？"
提问意图：考察管理范围和职责定位。
应答要点：
- 前端负责人 = 架构设计 + 工程体系 + 核心交付，不是纯管理
- 覆盖停车业务 + AI 两个方向
- 点出四个关键成果（产品闭环、追缴提效、技术栈统一、RAG 平台）
稳妥表达：
我在稳安特科技担任前端负责人，负责智慧停车和 AI 方向核心项目的前端架构设计与落地。具体来说有几块：
第一，主导了停车生态核心产品的建设，打通了停车缴费、商户转化、欠费追缴到清结算的完整业务闭环。
第二，负责欠费追缴体系的产品化落地，推动追缴率提升了 18%，累计追缴欠费超过 200 万元。
第三，统一了公司多个项目的技术栈和工程体系，沉淀了一套内部脚手架，让新业务能快速启动。
第四，负责了企业运维知识库 RAG 平台的方案设计和研发，这是 AI 能力在内部工具中的工程化落地尝试。
整体来说，我既要负责技术选型和架构方案，也要参与核心模块的编码交付，同时协调团队资源。
三、停车综合运营平台（核心项目）
4. "停车运营平台整体架构是什么样的？服务哪些用户？"
提问意图：考察项目全局观和业务理解。
应答要点：
- 多端架构：PC 运营端 + 公众号 H5 + 微信小程序
- 用户角色：停车运营人员（4类岗位）+ 车主
- 覆盖规模：18 个车场/道路点位，3000+ 泊位，2800+ 设备
稳妥表达：
这是一个典型的多端统一平台。PC 端面向停车运营管理人员，覆盖车场管理、订单收费、客服处理、财务结算、设备运维和经营分析这些日常运营工作。移动客户端面向车主，以公众号 H5 和微信小程序为载体，提供停车缴费、欠费追缴、附近车场查询、停车券、商户优惠券等功能。
目前支撑了 18 个车场/道路点位、3000+ 道路泊位和 2800+ 台设备的统一运营管理。技术栈以 Vue 3 + UniApp 为核心，配合 Element Plus 做 PC 端、Wot UI 做移动端，可视化部分用 ECharts 和高德 SDK。
5. "运营工作台的可配置能力是怎么做的？"
提问意图：考察架构抽象能力和业务理解，是否能把通用需求沉淀为可复用方案。
应答要点：
- 基于动态组件 + JSON Schema 构建 Widget 编排引擎
- 数据看板、待办、快捷入口抽象为可注册卡片
- 结合 RBAC 实现 4 类岗位首页按需配置，覆盖 10+ 高频入口
- 减少首页改版的重复开发
稳妥表达：
运营工作台首页涉及不同岗位的差异化需求——运营人员关注数据看板和待办，客服关注工单，财务关注结算，运维关注设备告警。如果每个岗位单独开发首页，改版和维护成本很高。
我设计了一套 Widget 编排引擎：把数据看板、待办列表、快捷入口等模块抽象为可注册卡片，每张卡片用 JSON Schema 描述它的布局、数据源和权限要求。运营人员通过后台配置，按岗位角色自由组合卡片，不需要前端发版。
底层结合 RBAC 做权限过滤，4 类岗位各有默认配置模板，也支持个性化调整。覆盖了 10+ 个高频入口，后续新增卡片只需要注册新的 Widget，首页框架不需要改动。
6. "智能渲染容器是怎么实现的？解决了什么问题？"
提问意图：考察性能优化和框架原理深度。
应答要点：
- 基于 IntersectionObserver
- 离开视口时劫持
component.render返回subTree，冻结更新但不销毁 - 重新可见时恢复 render，期间有更新请求则立即
component.update()同步 - 不可见时显示 fallback 占位，首次可见才渲染真实组件
稳妥表达：
这个需求的背景是：有些有大量数据看板、实时图表和长列表，全部同时渲染时主线程负载很高，低端设备卡顿明显。
我把它做成了一个通用懒渲染容器组件，基于 IntersectionObserver 监听可见性。核心思路分三段：
组件首次进入视口时渲染真实内容并缓存 VNode。离开视口时不销毁组件——而是劫持组件实例的 render 函数，让它直接返回当前的 subTree，跳过之后的 patch 和 update，相当于把组件"冻住"。同时记录冻结期间有没有触发过更新请求。重新进入视口时恢复原始 render，如果冻结期间有过更新请求就立即执行一次 component.update()，把积压的状态同步回来。
这个方案比 v-if 好在哪里？v-if 离开视口会销毁组件实例、丢失状态，回来要重建；我这个只会暂停更新，状态保持、不反复走 mount/unmount 生命周期，回来时恢复代价也低很多。
7. "设备 GIS 监控和道路泊位远程值守是怎么做的？"
提问意图：考察地图集成能力和 IoT 数据处理经验。
应答要点：
- GIS 监控：地图 SDK 聚合展示多类型设备（地磁、ETC、相机、手持终端）状态
- 远程值守：定时抓拍 + 前端轮询泊位状态，图片按时间轴回溯
- 量化成果：异常核验从 30 分钟缩至 5 分钟
稳妥表达：
设备 GIS 监控这部分，我们是基于高德地图 SDK 做的。把地磁、ETC、相机、手持终端这些设备按经纬度标注在地图上，支持按设备类型、在线状态、告警级别做筛选。点击设备标记可以查看设备详情和最近的告警记录，实现 2800+ 台设备的集中监控。
道路泊位远程值守的思路是：每个泊位对应的设备定时抓拍上传图片，前端通过轮询接口获取泊位状态和抓拍图片。我们构建了一个按时间轴回溯的图片稽核界面，人工可以远程查看某个泊位在某个时间段的照片，判断是否存在异常占位、设备故障等。这样一来，以前需要现场巡检 30 分钟才能发现的异常，现在远程 5 分钟内就能定位和处理。
8. "停车场地图与寻车场服务是怎么做的？"
提问意图：考察地图 SDK 集成经验和跨端（公众号 H5/小程序）开发能力。
应答要点：
- 车场数据来自后端接口（内部停车场数据）
- H5：
AMap.Map初始化 → 后端拿车场列表 → 遍历new AMap.Marker标注 → 导航走AMap.Driving - 小程序：微信
<map>组件渲染 → 后端拿车场列表 → 绑定到markers渲染 → 导航走wx.openLocation - 封装：渲染层独立，数据 service 层统一
稳妥表达：
这些车场是我们运营平台自己的数据，后端接口返回车场列表（含坐标、车位余量、收费标准这些），前端只负责在地图上标注展示。
H5 端：
AMapLoader.load()加载完 JSAPI 后new AMap.Map('container', {...})初始化地图。调后端接口拿到车场列表，遍历new AMap.Marker({position, content})创建标注点，map.add(marker)添加到地图上。点击标注弹窗展示详情，导航按钮调用AMap.Driving.search()规划路线。小程序端：渲染靠微信原生
<map longitude="{{...}}" latitude="{{...}}" markers="{{markers}}">组件。同样调后端接口取数据，把返回的车场列表映射成markers数组（latitude、longitude、iconPath、width、height），设置data让模板渲染。点击标注用<map bindmarkertap="onMarkerTap">，导航用wx.openLocation调起微信内置导航。封装：渲染层（地图初始化、标注交互）两端 SDK 完全不同，各自独立实现。数据层抽了一个
parkingMapService，车场查询和路线规划封装成统一 async 接口，内部用// #ifdef条件编译判断 H5 还是小程序，切换底层 SDK 调用，上层页面代码只调 service 不感知环境。
9. "微信支付流程是怎么对接的？"
提问意图：考察支付业务对接经验，是否理解完整链路而非只会调 API。
应答要点：
- 小程序端
wx.login获取 code → 后端换 openId - 购买接口传商品信息 + openId，后端生成订单 + 调微信支付统一下单获取 prepay_id
- 后端返回 prepay_id + 签名，前端调
wx.requestPayment唤醒支付窗口 - 支付结果异步通知前端和后端
稳妥表达：
完整链路分四步：
第一步，用户点击下单后，小程序调
wx.login()获取临时 code，传给后端去换 openId。第二步，前端把商品信息加上 openId 一起发给购买接口，后端生成订单后调微信支付统一下单接口拿到 prepay_id，同时根据微信 SDK 规则生成预付款签名，一并返回给前端。
第三步，前端拿到 prepay_id 和签名后调
wx.requestPayment()，微信内部唤醒支付窗口，用户输密码或指纹完成支付。第四步，微信后台处理结果会异步通知两端——同时推送给小程序的回调和后端配置的支付通知地址，两边各自更新订单状态。这样即使前端切走页面，后端也能收到结果，防止丢单。
10. "追缴率提升 18%+ 是怎么做到的？"
提问意图：考察业务驱动技术的能力和量化思维。
应答要点：
- 全流程线上化：欠费查询 → 在线缴费 → 处理回传 → 运营跟进
- 可嵌入式追缴模块，兼容多商户多车场
- 技术侧 + 业务侧配合
稳妥表达：
追缴率的提升是技术和业务配合的结果。从技术角度看，我主要做了几件事：
第一，打通了追缴全流程的线上化闭环——以前欠费查询、缴费、处理回传、运营跟进是割裂的，车主和运营人员之间需要电话沟通，效率很低。我把这个流程全部搬到了线上，车主在公众号或小程序上就能查看欠费记录并在线缴费。
第二，封装了可嵌入的追缴模块——因为我们的停车场涉及多个商户，每个商户的计费模型和数据权限都不一样。我设计了一套统一的参数传递和结果回调机制，把这个追缴模块做成了可以快速接入不同商户端的组件，在公众号 H5 和小程序上都能复用。
第三，在运营端建设了追缴看板和跟进功能，运营人员可以实时看到哪些欠费单已经推送、哪些已缴费、哪些需要人工介入，形成了完整的运营闭环。
最终追缴率提升了 18% 以上，累计追缴欠费超过 200 万元。
11. "性能优化从 4.2s 优化到 1.5s 以内，具体做了哪些？"
提问意图：考察性能优化实战经验，能否讲清从发现问题到解决问题的完整思路。
应答要点：
- 按「发现问题 → 分析瓶颈 → 逐步优化」三段讲
- 直接贡献首屏的：Gzip+Brotli、代码分割、CDN+缓存、图片懒加载
- 首屏之外也做了：虚拟滚动、智能渲染容器、图片预加载（一句话带过）
稳妥表达：
我是按先发现、再分析、后逐步优化的流程做的。
发现问题：通过 Lighthouse 加 Performance API 做生产采样，发现首屏加载平均 4.2s，FCP 和 LCP 都偏高。
分析瓶颈：用 Network panel 配合 Bundle Analyzer，定位到三个核心问题——一是静态资源 6.8M 没压缩；二是路由没做懒加载，首屏载入了大量非首屏模块；三是图片全部同步加载，首屏请求数过多。
逐步优化：优先做收益最高的——先上 Gzip 和 Brotli 压缩，资源降到 4.1M；再做路由级代码分割，按需加载；然后加图片懒加载。配套上了 CDN 和强缓存，二次访问直接命中缓存。三步下来首屏稳定在 1.5s 以内。
首屏之外也做了虚拟滚动、智能渲染容器和图片预加载，这些不贡献首屏指标，但整体体感提升明显。
12. "说说这个图片预加载插件是怎么设计的"
提问意图：考察工程化能力和插件开发经验。
应答要点：
- Vite 插件，扫描指定目录下的图片文件，自动注入预加载
- 开发环境用源码路径，生产环境映射到带 hash 的构建产物
- 两种策略：link 标签注入（浏览器调度）和 runtime script 预热（可控并发）
- 不是分析路由依赖，而是基于目录配置
稳妥表达：
这是一个 Vite 构建时插件，可以扫描指定目录下的图片文件，自动注入预加载。
核心是路径映射——开发环境直接使用源码路径，生产环境通过构建产物的
originalFileName匹配到带 hash 的最终路径，还做了字节级内容比对作为兜底，保证路径解析可靠。我做了两种策略：一是注入
<link rel="preload" as="image">标签到 head，让浏览器自己调度优先级；二是注入一段内联 script，用new Image()配合并发控制参数做运行时预热，避免一次性抢占太多浏览器连接。配置上只需要指定要预加载的图片目录，其他路径映射逻辑插件内部自动处理。
13. "全局反馈体系解决了 UniApp 的什么问题？"
提问意图：考察跨端开发对框架局限性的理解。
应答要点：
- UniApp 非 Vue 上下文无法调用 UI 组件
- 基于 Pinia 维护全局 Toast 状态，在布局层注入 GlobalToast 组件监听变化
- 在请求封装、路由拦截、支付回调等场景统一异常提示
稳妥表达：
UniApp 有一个典型的痛点：在一些非 Vue 上下文中——比如请求拦截器、路由守卫、支付回调——你没法直接调用 UI 组件，因为没有组件实例。但恰恰是这些场景最需要 toast、loading 这样的反馈。
我的方案是：基于 Pinia 维护全局 Toast 状态，在布局容器中注入 GlobalToast 组件监听状态变化。任何地方——无论是 Vue 组件还是纯 JS 逻辑——只需要调用
toast.show()更新 Pinia 状态，布局层的 GlobalToast 就能响应式地展示出来。这样我们在请求封装里统一处理网络错误提示、在路由拦截里处理登录过期提示、在支付回调里处理支付结果展示，整个应用的异常反馈体验就统一了。
四、多模态 RAG 设备运维知识库
14. "介绍一下你做的 RAG 项目"
提问意图：考察 AI 应用落地经验，是否真正理解 RAG，还是只是调 API。
应答要点：
- 场景驱动：面向停车设备现场运维，解决资料分散、图纸检索难
- 多模态：图文联合检索，支持故障照片召回相似案例
- 混合检索：三路召回（稠密向量 + 稀疏检索 + 元数据过滤）→ 加权融合 → rerank 精排
- 上下文工程：短期会话 + 长期记忆 + 阈值过滤
- 评估闭环：参考 RAGAS 做离线评测
稳妥表达：
这个项目的背景是：停车设备的现场运维人员查手册、找故障方案平均要花 40 分钟，尤其是故障照片这种图片信息以前根本没法检索。
我们做的多模态 RAG 系统核心要解决几个问题：图片搜不了、单路检索不稳、知识不能累积。具体来说：
多模态知识建模——图文分开处理。图片走多模态模型做向量化，支持上传故障照片召回相似案例；纯文本用独立文本向量索引，兼顾效果和成本。
混合检索——构建了稠密向量、稀疏检索和元数据过滤三路召回，用加权融合策略合并结果，再用 qwen3-rerank 做精排重排序，保证高相关片段进入 LLM 上下文窗口。
上下文工程——Redis 维护短期会话，异步任务把有价值的交互摘要沉淀为长期记忆。检索层设 distance 阈值过滤低质量结果，避免无关上下文污染生成链路。
评估闭环——参考 RAGAS 设计离线评测，检索侧看 Context Precision/Recall，生成侧看 Answer Relevancy/Faithfulness。每次迭代跑指标对比，形成量化优化闭环。
最终完成 1100 份文档入库，故障定位从 40 分钟缩到 10 分钟，自助解决率提升 68%。
15. "混合检索的三路召回具体是怎么做的？"
提问意图：考察对 RAG 检索环节的深入理解，是否真的做过工程调优。
应答要点：
- 三路召回：稠密向量（语义）+ 稀疏检索 BM25（精确命中）+ 元数据过滤（降噪）
- 加权融合 + rerank 精排
- 为什么做多路：设备运维场景问题类型杂，单路不稳
稳妥表达：
我们这个项目里的混合检索，本质上是多路召回。因为设备运维场景的问题比较复杂，单靠一种检索方式效果不稳定。比如向量检索擅长理解语义，适合处理口语化描述和同义表达；但像设备型号、错误码、专业术语这种内容，关键词检索往往更准。所以我们最后做的是稠密向量检索、稀疏检索和元数据过滤三路结合。
具体做法上，第一路是向量检索。我们把文档切成 chunk 之后做 embedding，用户问题也转成向量，到向量库里召回语义相近的片段。第二路是稀疏检索，也就是全文检索或 BM25，主要保设备型号、故障码、术语这些精确命中。第三路是元数据过滤，我们在入库时给文档片段打上设备类型、型号、文档类别、故障标签这些信息，检索时如果 query 里能识别出这些条件，就先做过滤，减少无关内容进来。
两路结果回来之后，我们没有直接拿原始分数做加权，而是用了 RRF，也就是倒数排名融合。原因是向量相似度和 BM25 分数不是一个量纲，直接相加不太稳定。RRF 的思路是看一个结果在不同召回列表里的排名，如果一个片段在向量检索里排得靠前，在 BM25 里也排得靠前，那它最终综合排序就会更高。这样可以比较稳地把语义相关和关键词精确命中结合起来。RRF 融合完之后，我们再把候选结果交给 rerank 模型做精排，因为前面的召回和融合更偏‘尽量别漏’，而 rerank 更适合做细粒度相关性判断，最后再选出最适合放进上下文的几个片段给大模型生成答案。
所以整个链路可以理解成：向量检索负责找语义，BM25 负责保精确命中，RRF 负责把多路结果稳健融合，rerank 负责最后精排。这样整体效果会比单一路召回稳定很多，尤其适合设备型号、错误码和自然语言故障描述混在一起的场景。
16. "图文联合检索具体怎么实现的？多模态模型用的什么？"
提问意图：考察对多模态 RAG 的理解深度，是调 API 还是有架构思考。
应答要点：
- 图片：用多模态模型（qwen3-vl）生成图片描述向量 + 图片本身的视觉特征向量
- 文本：用 text-embedding-v4 做文本向量化
- 检索时：用户问题向量同时检索图片库和文本库
- 也可以上传图片作为 query
稳妥表达：
我们用到的多模态模型是 qwen3-vl。具体做法是：对文档中的故障照片、设备示意图等图片，用 qwen3-vl 提取视觉特征向量，同时结合图片的标题、上下文文字生成描述向量，两者融合后存入向量数据库。
检索时支持两种模式：用户输入文字问题，文字经过 text-embedding-v4 向量化后，同时在图片向量库和文本向量库中做相似度搜索。也支持用户上传一张故障照片，用 qwen3-vl 提取这张图的特征向量，去召回历史相似的故障案例。
这样运维人员遇到一个没见过的故障，拍张照传上去，系统就能告诉他以前有没有类似的故障、当时是怎么修的，效率提升很明显。
17. "RAG 评估体系是怎么搭建的？具体用什么指标？"
提问意图：考察工程严谨性，能不能量化地做迭代。
应答要点：
- 参考 RAGAS 框架
- 检索侧：Context Precision（检索到的内容是否相关）、Context Recall（相关的内容是否都被检索到了）
- 生成侧：Answer Relevancy（答案是否对问题有针对性）、Faithfulness（答案是否忠实于检索到的上下文，不胡编）
- 用评测结果驱动迭代
稳妥表达：
我参考了 RAGAS 的评估框架，设计了两层四指标的离线评测体系。
检索侧关注两个指标：
- Context Precision：检索到的内容中，真正相关的比例有多高——这是衡量「噪音」的。
- Context Recall：所有相关的内容，系统检索出来了多少——这是衡量「漏检」的。
生成侧也关注两个指标：
- Answer Relevancy：生成的答案是不是回答了用户的问题，而不是答非所问。
- Faithfulness：答案是否忠实于检索到的上下文，有没有编造不存在的信息。
评测方式是构建一套标注好的测试集，每次迭代检索策略、分块方式、或者提示词之后，都跑一遍评测，对比指标变化。这样就形成了一个可量化的优化闭环，而不是靠感觉调参。
18. "上下文工程中短期会话和长期记忆是怎么设计的？"
提问意图：考察 RAG 高阶话题——记忆管理和状态维护。
应答要点：
- 短期：Redis 维护会话上下文（最近 N 轮对话）
- 长期：异步任务对关键交互做摘要 → 向量化 → 存入长期记忆库
- 检索时：结合 query 召回相关的长期记忆，作为额外上下文
稳妥表达：
我是分两层做的：
短期会话直接基于 Redis 维护。每次对话的 query 和 answer 都按时间序存入一个会话链，系统取最近 N 轮的上下文作为当前问题的背景。Redis 的过期机制可以自动清理超时会话。
长期记忆是通过异步任务沉淀的。当一轮对话被判定为「有价值」——比如用户问了一个很少见的故障处理方案——后台会把这个交互内容做摘要，然后再向量化，存入长期记忆的向量库。下次当用户提出类似的问题时，检索层会同时从文档库和长期记忆库中召回相关内容，作为额外上下文注入。
这样做的目的是：系统能从每一次使用中持续积累经验，不仅仅是依赖文档中的静态知识。
19. "检索到了正确内容，模型还是编造了信息，怎么处理幻觉？"
提问意图：考察对 RAG 幻觉问题的系统性理解，不是只会加 Prompt。
我们至少做了三个层面的组合。 Prompt层面，明确要求只基于检索结果回答，没有就说不知道。 生成层面，用输出自校验，生成后再过一遍模型检查每条信息是否有依据 参数层面，把temperature调低到0.1到0.3之间，降低随机性 另外我们还有一个兜底机制——把生成的回答和检索到的上下文做一次相似度对比，如果语义距离太大，说明模型很可能在胡编，这时候直接返回"抱歉，未找到相关信息"，不让答非所问的东西出去。
这一套组合下来，我们项目的幻觉率从 30% 降到了 12% 左右。
五、通用高频问题
20. "你为什么从上一家公司离职？"
提问意图：考察稳定性、职业规划、抗压能力。
稳妥表达：
在普罗格科技我参与的是物流 WMS 系统的前端开发，积累了很多 ToB 业务系统的交付经验。但我发现在那家公司，技术上能接触到的新东西比较有限，成长曲线开始变平了。而我当时对 AI 前端应用和更复杂的业务场景很感兴趣，正好稳安特这边有智慧停车 + AI 方向的机会，既涉及复杂的业务闭环，又有 AI 落地的探索空间，所以选择了过去。我换工作比较看重技术成长和业务复杂度，不太会因为薪资的小幅波动跳槽。
21. "你从上一份工作经验中学到的最重要的东西是什么？"
提问意图：考察复盘能力和成长思维。
稳妥表达：
在普罗格做 WMS 系统时，让我感受最深的是通用能力的抽象。出入库、订单、库存盘点这些模块，看起来业务不同，但底层都是大量的表单和表格操作。我当时就在想：能不能把表单的校验规则、表格的列配置、操作的权限控制这些通用逻辑抽出来，做成配置化的方案？后来果然这样做了，开发新模块时复用率很高。这个思维方式我带到了现在的工作中——做停车平台时，无论是追缴模块的可嵌入设计，还是运营工作台的 Widget 编排引擎，本质上都是「先抽象再复用」的思路。
22. "你 Vue 3 熟悉的程度如何，能说说响应式原理吗？"
提问意图：考察框架原理，看是不是停留在 API 使用层面。
稳妥表达：
Vue 3 的响应式基于 Proxy 实现，不同于 Vue 2 的 defineProperty。核心是 reactive 和 ref 两个 API。
reactive 用 Proxy 拦截 get/set 操作——get 时通过 track 函数收集依赖（当前正在运行的 effect），set 时通过 trigger 函数触发所有依赖的 effect 重新执行。
ref 本质上是把值包装成 { value: ... } 的结构，在模板中自动解包。如果 ref 传入的是对象，底层还是会走 reactive。
依赖收集的核心数据结构是一个 WeakMap：key 是目标对象，value 是一个 Map，这个 Map 的 key 是属性名，value 是 Set，存的是 effect 函数。这样当属性变化时，就能精确地找到哪些 effect 需要重新执行，不会触发不必要的更新。
23. "你有带团队的经验吗？"
提问意图：考察管理能力和协作方式，虽然是技术面但负责人角色可能会被追问。
稳妥表达：
在稳安特我是前端负责人，团队规模不算大，但职责覆盖了技术决策、任务拆解和代码质量把控。我主要负责核心架构的设计和难点攻坚，日常开发中会做 Code Review 和技术方案评审。我不属于传统意义上的「管人」式管理，更多是技术引领 + 把事情做规范——比如统一技术栈、沉淀脚手架、建立编码规范，让团队协作更顺畅。遇到技术难题时我会和大家一起讨论方案，也鼓励团队成员参与开源项目。
七、面试当天 Checklist
- 对自己的每个项目能用 1 分钟讲清全局（什么人、什么场景、解决了什么问题）
- 对每个技术亮点能用 3 分钟讲深（实现原理 + 为什么这样做 + 量化效果）
- 准备好反问面试官的问题（如：团队当前的技术栈是什么？前端在 RAG/LLM 方向的规划？）
- 准备 2-3 个带数字的成果随时脱口而出（追缴 200 万、4.2s→1.5s、68% 自助解决率）
- 确认已掌握以下高频追问的细节以防被深挖：
- Vue 3 响应式 / diff 算法 / nextTick 原理
- IntersectionObserver 兼容性和 polyfill 方案
- RAG 的 Chunking 策略和 Embedding 模型选型
- 地图 SDK 的内存泄漏处理
- UniApp 和原生小程序的区别与限制