星源智2面
核心问题与回答
Q1：请做个自我介绍
原始回答：
- 我是伟业，有三年前端开发经验，目前在广东中山文安特负责智慧停车业务线的前端开发
- 参与搭建了覆盖车主端、H5小程序和运营管理后台等平台
- 负责停车缴费、欠费追缴、订单和设备运维等核心模块
- 是 uniapp 移动端 Wot UI 组件库成员，参与开发过高拓展性瀑布流组件和 Wot Star 脚手架
回答质量： ⭐⭐⭐
复盘后的标准回答：
- 面试官你好，我叫伟业，有 3 年前端开发经验，目前就职于广东中山文安特公司，负责智慧停车业务线的前端开发
- 技术栈以 Vue3 和 UniApp 为主，参与搭建了覆盖车主端 H5 小程序和运营管理后台的完整管理平台
- 核心负责停车缴费、欠费追缴、订单和设备运维等模块，推动了欠费查询、在线缴费到运营跟进的业务闭环
- 同时是 Wot UI 组件库的核心成员，主导开发了高拓展性的瀑布流组件，并参与了脚手架工具 Wot Star 的建设
- 在 AI 方向也有实践，负责过公司 RAG 知识库问答系统的前端开发
Q2：你现在还在职吗？在哪个城市？后面怎么规划？
原始回答：
- 目前仍在职
- 工作地点在广东中山
- 未来工作地点可以灵活调整
回答质量： ⭐⭐
复盘后的标准回答：
- 目前仍在职，工作地点在广东中山
- 如果贵公司有异地办公需求，我可以灵活调整，包括 relocation 到其他城市
- 强调灵活性和稳定性：在职状态说明能力被认可，同时表达出对新机会的诚意
Q3：能展示一些相关的前端项目吗？整个平台是几个前后端配合的？
原始回答：
- 展示了停车运营管理后台系统
- 系统包含首页图表、运营中心模块、道路值守模块
- 使用了百度地图 SDK 进行地图渲染，支持查看道路车位情况
- 项目由一个前端和一个后端共同开发维护
- 另外还有车主端的公众号、H5 和小程序，同样是一前端一后端负责
回答质量： ⭐⭐
复盘后的标准回答：
- 展示的停车运营管理后台系统，主要包含三大模块：
- 首页图表： 展示停车数据概览（车位使用率、收入趋势、设备状态等）
- 运营中心： 管理停车订单、欠费追缴、设备运维等核心业务
- 道路值守： 使用百度地图 SDK 渲染道路车位分布，支持实时查看车位占用情况
- 项目规模：1 前端 + 1 后端，独立负责前端全部开发工作
- 除了管理后台，还维护了车主端的公众号、H5 和小程序
- 技术亮点：地图可视化、数据大屏、复杂表单管理、权限控制等
- 建议展示时突出个人贡献和技术难点，而非简单罗列功能
Q4：有接过类似于 RTSP 流或者是实时的点云流这些吗？
原始回答：
- 这个倒是没有，那个模块不是我做的
- 路边有运营中心，通过网线直接推流到监控屏上面显示视频，但那个模块我没有负责
回答质量： ⭐
复盘后的标准回答：
- 目前没有在前端处理过 RTSP 流或点云流的实时渲染
- 项目中涉及视频监控的部分，是通过网线直接推流到运营中心的监控屏，由硬件方案解决，前端没有参与
- 如果需要在浏览器端播放 RTSP 流，我知道可以通过以下方案实现：
- 使用 FFmpeg 转码为 HLS 或 WebRTC 流
- 使用 MSE（Media Source Extensions）或 WebSocket 代理播放
- 使用第三方服务如阿里云直播 SDK 或腾讯云移动直播 SDK
- 建议表达：虽然没有实际做过，但对相关技术方案有了解，且有信心快速上手
Q5：你在这个平台上负责的是哪些工作？数据可视化是你做的吗？
原始回答：
- 主要负责首页的数据图表、运营中心的车厂管理模块
- 停车数据可视化是我做的
回答质量： ⭐⭐
复盘后的标准回答：
- 我负责的主要模块包括：
- 首页数据大屏： 停车数据可视化图表，展示车位使用率、收入趋势、设备状态等
- 运营中心： 车厂管理、订单管理、欠费追缴等核心业务模块
- 道路值守： 地图可视化展示车位分布和状态
- 数据可视化部分完全由我独立开发，包括数据接入、图表渲染、交互设计
Q6：你们使用什么地图 SDK？地图有哪些功能？是平面地图还是三维的？
原始回答：
- 主要使用百度地图 SDK，也可切换高德地图
- 地图功能包括数据概览面板、车位点位标记展示
- 是平面地图，不含三维模型功能
回答质量： ⭐⭐
复盘后的标准回答：
- 主要使用百度地图 SDK，同时预留了高德地图的切换能力（通过抽象地图适配层实现）
- 地图核心功能：
- 数据概览面板：展示区域停车数据统计
- 车位点位标记：在地图上标记每个车位的位置和状态（空闲/占用/故障）
- 聚合展示：密集区域自动聚合，缩放时拆分
- 点击交互：点击标记点查看详情
- 热力图，查看停车热图
- 目前是 2D 平面地图，没有使用三维模型
- 技术要点：通过适配器模式封装地图 SDK，方便后续切换或升级
Q7：大屏上的动画是直接切的图还是自己用 CSS 写的？加载慢怎么处理？
原始回答：
- 是贴的动图（GIF），前端写 CSS 太麻烦了，需要精确计算位置
- 目前确实存在加载慢的问题
- CSS 写的话需要定位到具体渲染位置，精确计算，前端处理比较麻烦
回答质量： ⭐
复盘后的标准回答：
- 大屏动画不一定都适合用 CSS 或动画库来做，这个要看动画复杂度和交付目标。像闪烁、呼吸、流光、数字变化这类简单重复动效，用 CSS 或图表库自带动画就够了，性能也更好
- 但我们项目里的背景动画更偏视觉装饰和设计稿还原，如果完全用 CSS 或动画库去拼，实现成本会比较高，调试和维护也更重，所以当时选择直接使用 APNG 资源来承载这部分动画
- 存在的问题： 这种资源方案虽然交付快、还原度高，但 APNG 的体积通常偏大，尤其帧数多、分辨率高的时候，会对首屏加载有一定压力
- 优化方案（下次可以这样回答）：
- 方案分层： 简单重复动画继续用 CSS，图表类动画优先用图表库自带能力，只有这类复杂背景装饰动画才交给资源方案处理
- 资源层优化： 控制图片尺寸，减少无效帧，适当降帧和压缩，必要时评估替换为 WebP 动画或视频方案
- 加载链路优化： 对首屏关键动画资源做预加载，静态资源走 CDN，结合 HTTP 缓存和浏览器缓存减少重复请求
- 工程经验补充： 我之前做过一个基于 Vite 的图片预加载插件，可以在构建阶段自动注入 preload，也支持脚本控制并发预热，所以会重点关注首屏关键资源优先到达，减少页面首屏等待和切换卡顿
- 补充比较： GIF 画质和透明度表现一般，所以我们没有优先用它；如果后续要进一步压体积，也会评估 WebP 动画这类方案
- 回答要点：先说明为什么不是所有动画都用 CSS 或动画库，再解释为什么背景动画用了 APNG，最后把资源优化、加载优化和自己的预加载插件经验串起来
Q8：你觉得 Wot UI 相比其他组件库（如 Ant Design、uView）有什么优势？
原始回答：
- Ant Design 在 uniapp 技术栈上没有
- 对标的是 uniapp 生态里的 uView 等传统组件库
- Wot UI 是 23 年开始构建的，组件比较多
- 对 AI 友好，有完整的生态，包括脚手架和插件
- 支持 npm 和原生两种导入方式
- 配套有 VS Code 提示插件、原子 CSS 方案
- 更新迭代速度快
回答质量： ⭐⭐⭐
复盘后的标准回答：
- Wot UI 是一个基于 Vue 3 + TypeScript 构建的 UniApp 跨端组件库，支持微信、支付宝、钉钉等多个小程序平台，以及 H5 和 App。我自己主要参与了核心组件和生态工具的建设，比如瀑布流组件、Toast 体系、脚手架、文档和工具能力完善
- 相比其他 UniApp 生态组件库，我觉得优势主要有这几个：
- 技术栈更现代： 基于 Vue 3 + TS 构建，类型支持、组合式 API 适配和整体可维护性会更好
- 跨端支持更完整： 不只是把组件堆起来，而是更关注 UniApp 多端场景下的一致性和兼容性处理
- 生态完整、AI 友好： 除了组件库本身，我们还有脚手架、VS Code 插件，以及面向 AI 使用的 mcp、CLI、skill以及llm.txt，原子 CSS 方案适配更好。开发者从初始化到查文档、写页面，整条链路会更顺
- 使用方式更灵活： 支持 npm 和 easycom 两种使用方式，能适配不同项目习惯
- 文档和上手体验更友好： 很多组件库不是不能用，而是文档、示例和边界说明不够，开发者需要自己踩坑，这块我们会比较重视
- 迭代速度快： 社区活跃，版本更新频繁，已迭代到第二个大版本，能快速响应 bug 和需求
- 对比竞品：
- 和 Ant Design 这类 Web 组件库相比，Wot UI 更聚焦 UniApp 跨端移动端场景，不是简单把 Web 交互迁过去
- 和 uView 这类传统 UniApp 组件库相比，Wot UI 在 Vue 3、TypeScript、生态工具链和 AI 友好性上会更有优势
Q9：你贡献 Wot UI 的是哪一部分？是脚手架吗？
原始回答：
- 贡献了脚手架（Wot Star）
- 封装了一些使用示例，配置好相关插件方便开发者一键使用
- 还有文档维护、解决 bug
- 瀑布流组件
回答质量： ⭐⭐
复盘后的标准回答：
- 我主要贡献了以下几个部分：
- Wot Star 脚手架： 封装使用示例和插件配置，方便开发者一键启动项目
- 瀑布流组件： 主导开发高拓展性的瀑布流组件
- 文档维护： 完善组件使用文档和示例
- Bug 修复： 解决社区反馈的问题
- 参与开源的方式从使用 → 提 issue → 提 PR → 成为核心成员，逐步深入
Q10：你们用 Figma，是有开 Figma 的编辑会员吗？还是有其他方案？
原始回答：
- Figma 插件要付费
- 如果付费可以用，也可以用开源的 MCP 工具平替
- 如果 UI 不用 Figma，可以用其他的工具如 Penpot、Google 的（忘记名字）
- 配合 UI 规范文档，让 AI 理解设计规范
- 实现阶段可以让 AI 先分析页面元素和布局结构，生成实施文档
回答质量： ⭐⭐⭐
复盘后的标准回答：
- Figma 的 MCP 插件需要付费使用
- 替代方案：
- 使用开源 MCP 工具平替 Figma 插件
- 使用 Penpot（开源 Figma 替代品）或 Google 的类似工具
- 编写 UI 规范文档放在项目根目录，让 AI 参照实现
- 实施流程：
- 截图或让 AI 调用 MCP 读取 UI 文件
- AI 先分析页面元素和布局结构，生成实施文档
- 然后分步还原，人工校验
- 核心思路：不依赖单一工具，多种方案组合使用
Q11：你对 vibe coding 能力怎么样？项目中有多少是通过 AI 生成的？
原始回答：
- 主要使用 codex 开发
- 引入了 Superpowers 等工作流工具
- 工作中 80-90% 代码由 AI 生成，主要负责设计架构和校验
- 强调技术术语理解和多 agent 协作的重要性
回答质量： ⭐⭐⭐
复盘后的标准回答：
我会用 vibe coding，但不是把 AI 当自动写代码机器，而是把它放进一套工程化流程里。比如用多 Agent 架构做任务分工，用会话分叉并行探索方案，配合 Codex、MCP、Skill、CLI、CodeGraph 这些工具提升产出效率和上下文利用率。AI 在我项目里不仅参与写代码，也参与文档、测试、验证、交付和日志分析。但我不会把关键判断外包给 AI，我会严格控制能力约束、权限边界和安全风险。对我来说，真正的能力不是生成了多少代码，而是能不能把 AI 产出变成一个可控、可验证、可交付的系统
反问环节
原始提问：
- 确认工作地点是否在北京
- 了解入职后的主要工作任务和紧急任务
- 询问团队规模和技术栈要求
- 确认 AI 使用是否有报销额度
- 了解比较看重应聘者的哪些能力
复盘后的提问思路：
- 关于业务： 请问这个岗位主要负责哪些业务线？目前比较紧急的任务是什么？希望入职后能完成什么？
- 关于团队： 团队目前的规模和分工是怎样的？前端团队有多少人？前后端协作模式是怎样的？
- 关于技术栈： 团队目前使用的技术栈是什么？有没有计划迁移到更新的技术？
- 关于工作方式： 公司对 AI 辅助编程的态度是怎样的？是否有相关的工具或预算支持？
- 关于成长： 公司对新人的培养机制是怎样的？比较看重应聘者的哪些能力？
- 提问技巧： 提问时避开面试官已透露的信息，表现出对业务和团队的真实兴趣；先问业务再问待遇，展现职业态度
薄弱环节与改进方向
| 薄弱点 | 改进建议 | 关联知识点 |
|---|---|---|
| RTSP 流 / 点云流实时渲染完全不了解，回答被动 | 系统学习浏览器端视频流播放方案：WebRTC、HLS、MSE、WebSocket 代理等，至少能说出 2-3 种方案 | 待补充：浏览器视频流播放方案 |
| 大屏动画使用 GIF，加载慢但没给出优化方案 | 学习 CSS Animation、Lottie、Canvas/WebGL 等动画方案，面试时主动给出替代方案 | 待补充：前端动画性能优化方案 |
| 地图功能描述过于简单，只说"调 SDK" | 深入理解地图 SDK 的高级功能（聚合、热力图、自定义覆盖物、适配器模式封装），面试时展示技术深度 | 待补充：地图 SDK 高级功能与封装实践 |
| 项目展示时简单罗列功能，没有突出个人贡献 | 使用 STAR 法则组织项目介绍：背景 → 任务 → 行动 → 结果，突出技术难点和解决方案 | 待补充：STAR 法则面试表达技巧 |
| 开源贡献回答零散，没有系统化 | 按贡献类型分类（脚手架、组件、文档、Bug），用数据量化贡献（如 PR 数量、issue 解决数） | 待补充：开源项目贡献经验总结 |
访谈总结
本次面试为星源智公司的二面，有两位面试官参与（马总和许萌）。面试详细了解了面试者的前端开发经验，特别是智慧停车系统的开发实践和开源组件贡献。面试官特别关注了大屏可视化的动画实现方案、地图 SDK 的使用经验、Wot UI 组件库的贡献以及 AI 辅助编程（Vibe Coding）的实践能力。面试者也主动了解了工作地点、团队规模、技术栈要求和 AI 工具支持等情况。
整体表现： 面试者在自我介绍、Wot UI 优势、AI 辅助编程和反问环节表现较好，展示了扎实的技术功底和对新技术的敏锐度。但在 RTSP 流、大屏动画优化和地图功能深度方面暴露了不足，需要在后续面试中加强准备。项目展示时建议更多使用 STAR 法则突出个人贡献，而非简单罗列功能。