2083 字
10 分钟
AI
AI
一、 日常研发效能与工作流构建
面试官关注点：你是把 AI 当高级百度，还是真正将其沉淀为了个人生产力工具？
参考回答话术：
“在日常开发中，我已经将 AI 从‘解答问题’的工具升级为‘结对编程’的伙伴。
- 工具选型的差异化判断：我深度体验过几款主流工具。相较于早期偏向于单行或代码块补全的 Codex，我现在重度使用 Cursor。Cursor 最核心的优势在于它的 Codebase 级别的上下文感知能力，这对于前端复杂的 Monorepo（比如基于 pnpm workspace 的项目）特别关键，它能跨包理解类型定义和依赖关系。
- 提效 30% 的真实场景：我的提效不是靠 AI 帮我写核心业务逻辑，而是将‘高耗时、低创造性’的工作剥离。主要体现在三个场景：一是繁琐的 Boilerplate 生成，比如一键生成带完整 TypeScript 定义的 React 组件和配套的单测骨架（Jest/Vitest）；二是复杂正则的编写与解释；三是框架间的语法翻译（比如将一段历史的 Vue 2 逻辑快速重构为 React Custom Hook）。
- 上下文管理与规则沉淀：为了避免每次都要重复给 AI 设定背景，我会在项目根目录配置
.cursorrules文件。我会明确规定：‘强制使用 Functional Components’、‘优先使用useMemo处理复杂计算’、‘组件库遵循特定命名规范’等。这相当于给 AI 戴上了符合我们团队规范的‘紧箍咒’，大幅降低了它的自由度，但也极大提升了生成代码的可用率。”
二、 工程化落地：AI 辅助 Code Review
面试官关注点：你是否有全局视野，能否将 AI 能力工程化并接入现有的 CI/CD 流程？
参考回答话术：
“我认为 AI 辅助 Code Review 不是用来取代现有的基建，而是作为重要的补充。我们要明确机器和大模型的职责边界。
- 明确的边界划分：像 ESLint 和 Prettier 负责的是‘确定性’问题（如基础语法、缩进、未使用的变量），这部分用 AST 解析最快最准，绝不能浪费大模型的算力。AI Review 负责的是‘非确定性’和‘意图性’问题，比如：命名是否符合业务语义？有没有潜在的竞态条件？或者是否过度渲染（React 性能问题）？
- 工程化实现路径：我的闭环思路是这样的——通过 Webhook 监听 Gitlab/GitHub 的 PR 创建或更新事件；触发 Node.js 中间件服务拉取本次提交的 Diff 数据；将 Diff 数据结合我们团队预设的 Prompt 模板发给 LLM API；最后将解析后的 JSON 结果转化为 Markdown，通过 API 回写为 PR 的 Review 评论。
- Prompt 调优与降噪：大模型很容易‘胡说八道’或进行过度重构。我的经验是，Prompt 必须非常具体。我会注入：‘你是一个资深的前端架构师，请仅指出逻辑漏洞、潜在的内存泄漏和严重的性能问题。忽略任何代码格式问题。如果不确定，请回复“无严重问题”’。通过设定极低的 Temperature（温度参数）和明确的负面提示词（Negative Prompts），可以有效控制误报率，避免给 Reviewer 增加心智负担。”
三、 AI 智能体与底层编排能力 (Dify / Agent / MCP)
面试官关注点：你是否具备 AI 原生应用（AI Native）的开发思维？
参考回答话术：
“前端工程师在 AI 时代不仅是界面的实现者，更应该是工作流的编排者。我非常看好并通过 Dify 这类平台实践过 Agent 工作流。
-
Dify 实践：Tailwind CSS 自动化升级：我曾构思/实践过一个将传统 CSS 迁移到 Tailwind 的工作流。这不仅仅是一个简单的 Prompt，而是一个编排链路：
- 输入节点：接收包含传统 CSS 的组件代码。
- LLM 节点：负责‘语义映射’，将原生 CSS 转化为最接近的 Tailwind Utility Classes。
- 代码执行节点（沙盒）：运行自定义的 Node.js 脚本（利用 AST 或正则），将原本的
class="box"替换为 LLM 生成的className="flex items-center p-4"，并清理废弃的 CSS 文件。 - 条件分支：如果遇到无法精确映射的复杂动画或伪类，流转给‘人工确认（Human-in-the-loop）’节点。
-
MCP 与生态接入：对于打通本地和云端的壁垒，MCP（Model Context Protocol）是未来的趋势。它解决的是让大模型安全、标准化地访问本地文件系统或数据库的问题。比如在调试本地前后端联调报错时，通过 MCP 让模型直接读取本地的网络请求日志和源码上下文，这比手动复制粘贴高效得多。”
四、 业务场景中的 AI 融合
面试官关注点：遇到复杂业务需求时，你如何将传统前端技术栈与 AI 结合来兜底和优化？
参考回答话术：
“在实际业务场景中，AI 是催化剂，但兜底的依然是扎实的前端底层知识。
- 复杂链路排障（以 Puppeteer 导出 PDF 为例）：这个场景非常考验对浏览器渲染机制的理解。用 AI 写出 Puppeteer 的基础脚本很容易，但处理 Bad Case 必须靠人工经验。例如，异步内容加载导致截图空白，需要配置
waitUntil: 'networkidle0'；跨页截断问题，需要熟练使用 CSS 的page-break-inside: avoid；特殊字体渲染丢失，要在 Node 端确保字体文件的预加载。AI 可以帮我快速查阅这些 API 配置，但排查渲染生命周期的链路，依然需要前端的专业判断。 - AI 业务开发配合：在开发类似 Chat-to-SQL 或企业内部大模型对话界面时，前端面临的挑战是‘不确定性输出’的渲染。我会处理 Server-Sent Events (SSE) 来实现流式打字机效果；在与后端配合时，我会建议针对不同的任务调整 Temperature——如果是生成 SQL 或严格的 JSON 数据结构，将 Temperature 设为 0，确保格式的绝对确定性；如果是生成总结性文本，则适当调高以增加语言的流畅度。”
五、 行业洞察与岗位认知
面试官关注点：面对 AI 的冲击，你的心态和职业规划是什么？（考察软素质与深度思考）
参考回答话术：
“我非常坦然地面对 AI 带来的冲击。
- 正视 Vibe Coding 的冲击：我承认，传统的、高度模式化的中后台 CRUD 页面，或者基础组件的编写，AI 已经做得比大多数初级工程师又快又好。Vibe Coding（自然语言编程）在处理‘确定的、低复杂度的需求’时，展现出了压倒性的优势。
- 前端工程师的职业壁垒：但这也恰恰凸显了人类工程师的真正价值。AI 的强项是‘实现确定的需求’，而我的核心竞争力在于**‘定义模糊的需求’**。实际开发中，大量时间花在与产品经理拉齐认知、处理前后端不合理的数据结构、解决极端的性能瓶颈，以及在大型 Monorepo 架构中进行依赖梳理。这些涉及业务博弈和系统全局观的工作，AI 目前无法替代。
- 风险意识与底层能力沉淀：在拥抱 AI 的同时，我有着严格的风险底线。我绝不会将公司的核心业务代码或敏感数据暴露给公有云模型。同时，我时刻警惕‘能力退化’——AI 可以帮我写出复杂的 CSS 动画或 Webpack 配置，但我依然要求自己必须理解背后的浏览器重绘重排原理和打包构建机制。因为当 AI 产生幻觉、代码跑不通时，只有掌握底层原理的人，才能成为最后的把关者。”