小鹏汽车前端（仿真）二面：SDD与Figma转代码

《面试题目》

1. 做一下自我介绍。
2. 实习相关内容（原帖略）。
3. 有没有使用 AI 做开发？Figma 转代码的效果如何？
4. 什么是 SDD（规范驱动编程）？你们团队的 SDD 完整流程是怎样的？
5. 你在项目中是否遵循 SDD 开发？
6. AI 能不能精准实现设计稿里圆角、字体、颜色等细节？
7. Figma 图层混乱，AI 转换代码会遇到什么问题，如何约束？
8. 你如何看待 AI 能力变强，会不会替代前端开发？
9. 对前端职业发展怎么看，如何应对 AI 带来的变化？
10. 团队对前端工程师的定位：不只做页面落地，需要往前对接用户需求、理解业务；往后也要具备后端基础能力。
11. 前端写后端代码容易遇到什么问题？（数据库、索引、分页、性能）
12. 反问：前端参与写后端，使用的技术栈是什么？
13. 反问：仿真平台是 ToB 内部工具，平台迭代节奏（发布周期）是怎样的？
14. 反问：平台有没有结合 AI 的工作流/自动化能力？
15. 反问：面向平台用户的 AI 能力（知识库答疑机器人）？
16. 反问：面试结果多久可以出？

《参考解析》

SDD（Spec-Driven Development，规范驱动编程）是什么、流程怎么走：SDD 的核心是把「自然语言需求」先固化成一份可评审、可追溯的规范，再让 AI（或人）照着规范实现，而不是让 AI 直接面对一句模糊的需求。一条完整流程通常是：① 需求澄清与写 Spec——明确目标、范围、非目标、验收标准、接口契约、边界与异常路径，写成仓库里的文档（如 specs/xxx.md）；② 设计与任务拆解——把 Spec 拆成可独立验证的任务清单，标注依赖与风险；③ 实现——AI 按任务逐条实现，每个任务都对应 Spec 里的条目；④ 验证——用测试、类型检查、E2E 或人工验收对照验收标准逐条勾选；⑤ 变更管理——需求变了先改 Spec 再改代码，保持文档与实现同步；⑥ 沉淀——把踩到的坑回写到规范或 rules 文件，下一轮受益。面试时如果被追问「你们团队怎么做的」，最好给出具体载体（Spec 文档放哪、谁评审、用什么工具串起来、有没有和 CI 打通），而不是只讲概念。

Figma 转代码的效果与细节还原：现阶段 AI 从设计稿生成代码能覆盖结构和大致样式（布局容器、Flex/Grid、文本层级、常见间距），但细节还原度普遍不够，原因是设计稿到代码之间存在信息缺失与歧义：Figma 里很多数值来自「智能参考线/自动布局的推算」而不是设计意图，圆角、字体族与字重、行高（Figma 的 lineHeight 百分比换算到 CSS 的 px/倍数经常差一两像素）、颜色透明度与叠加、阴影的多层参数、断点下的响应式规则，都很难从图层里直接读出；变量（design token）和组件实例、auto layout 的嵌套约束也常被扁平化。提升还原度的做法是「把不可推断的信息显式化」：用 Figma Variables/tokens 导出设计变量表，让代码里用 token 而不是硬编码色值；保持图层命名与组件结构清洁；在提示词里给出项目既有的组件库与样式约定（「用现有的 Button 组件，不要重新实现」）；生成后用截图对比（视觉回归测试）逐块校验并让 AI 自己修 diff，而不是靠肉眼扫一遍。

Figma 图层混乱时如何约束 AI：图层混乱的典型症状是绝对定位满天飞、分组语义不明、命名是 Frame 427、同一元素多层嵌套包装。约束手段：一是预处理，转换前先把关键区域手动整理或用插件扁平化/重命名，宁可多花十分钟也别让 AI 猜；二是给约束而不是给自由，明确要求「优先用 flex 布局、禁止用绝对定位除非是覆盖层」「间距只用 4 的倍数」「颜色只能取自 token 表」，并给出一个已实现页面的示例作为风格参照；三是缩小任务粒度，整页一次性生成必然发散，按区块（导航/表单/列表）分别生成再拼装；四是用可执行校验兜底，生成后跑截图对比与 lint（禁止硬编码颜色、禁止 !important、禁止内联样式），把偏差变成可量化的 diff 再回喂给 AI 迭代。

AI 会不会替代前端、前端职业发展怎么看：这个问题面试官想看的是判断力和心态，不是口号。可用的回答框架是「分层看替代」：会被大量替代的是重复度高、可被规范描述、有明确验收标准的工作（按设计稿还原静态页面、写表单 CRUD、补测试、做简单的埋点与文案改动）；难以替代的是需要判断力的部分——需求澄清与产品取舍、复杂状态与性能问题的定位、跨端与架构设计、对业务领域的理解、以及「定义什么叫做好」的验收标准与质量体系。所以前端不会消失，但「只会写页面的前端」会越来越难，出路是往上（业务/产品理解、体验与性能、工程化与质量体系）和往深（跨端、可视化/图形、Node/BFF、AI 应用工程）。回答时最好结合自己的实际做法（比如你怎么用 AI 提升效率、把省下来的时间投到哪），比空谈趋势更有说服力。

前端写后端容易遇到什么问题：常见坑集中在四类。数据库与索引：习惯用 ORM 随手 findAll 再在内存里过滤，导致全表扫描；不知道联合索引最左前缀，WHERE 里对字段做函数运算导致索引失效；一次请求里 N+1 查询；事务边界写错（该在一个事务里的操作拆开，或者事务里包含远程调用导致长事务锁等待）。分页：深翻页 LIMIT 1000000, 20 越翻越慢，应该改成基于游标（WHERE id > last_id ORDER BY id LIMIT n）；COUNT(*) 大表统计昂贵，应该用近似值或维护计数表；分页排序字段没有索引会触发 filesort。性能与稳定性：缺连接池配置、缺超时与重试、缺少限流与幂等（前端思维容易忽略「同一个请求可能来两次」）；接口返回全量字段、把内部数据结构直接暴露成 API；缓存没有失效策略。工程习惯：日志与错误处理不统一、异常直接 500、缺少监控与慢查询观测。补救思路很明确：先看慢查询日志和 EXPLAIN，再谈优化；把「先验证再上线」的习惯带过去。