AI 效能与工程师素养

约 30 道题，考察候选人的 AI 使用深度、好奇心、探索欲和工程师思维方式。
这些"软题"往往是 5 年经验面试中区分"优秀"和"卓越"的关键。
与传统技术题不同，这类题没有标准答案，解答以引导型为主：面试官隐藏意图 → 好答案特征 vs 差答案特征 → 示例回答 → 追问方向。
难度分级：⭐ 基础 / ⭐⭐ 进阶 / ⭐⭐⭐ 深入

第一部分：AI 认知与使用程度

考察候选人对 AI 工具的实际使用深度和思考深度，而非"知不知道 ChatGPT"

Q1: 你日常开发中使用哪些 AI 工具？能具体说说它们分别在什么环节帮到你了？ ⭐

面试官隐藏意图

不是在考"你知道哪些 AI 工具"，而是考：

真实使用深度——是偶尔尝鲜还是已经融入工作流
场景意识——能否区分 AI 擅长和不擅长的场景
工具组合能力——是否根据不同场景选择不同工具

好答案 vs 差答案

好答案特征 ✅	差答案特征 ❌
能说出具体工具 + 具体场景 + 具体效果	只说"用过 ChatGPT 写代码"
提到在工作流的多个环节使用	只在一个环节使用
有自己的使用心得和踩坑经验	照本宣科，无实际体验
知道 AI 工具的局限性	过度吹捧或完全排斥
持续跟进新工具，有对比思考	只知道一两个工具

示例回答

我的 AI 工具箱大概分五个层面：

1. 日常编码：Cursor（主力 IDE）
   - Tab 补全处理重复代码，准确率大概 70%+
   - Cmd+K 内联编辑，比如"给这个函数加错误处理"
   - Chat 窗口做架构讨论，会先用 @codebase 让它理解项目结构

2. 代码审查：用 Cursor 或 Copilot 做 PR Review 的第一轮扫描
   - 主要找逻辑漏洞、边界条件、命名不规范
   - 但安全问题和业务逻辑还是人工审

3. 文档和测试：ChatGPT / Claude
   - 生成 JSDoc 注释和 README
   - 根据实现代码生成测试用例（给它函数签名 + 边界条件）

4. 技术调研：Claude（长上下文优势）
   - 喂它技术文档，让它做对比分析
   - 比如最近选 Zustand vs Jotai，让它从 bundle size、API 设计、
     TypeScript 支持等维度对比

5. 调试和性能分析：
   - 把报错堆栈和上下文喂给 AI，比自己 Google 快很多
   - 性能优化时让 AI 分析 Lighthouse 报告给建议

最大的心得：AI 对"有明确模式"的任务很强（正则、类型定义、测试用例），
但对"需要理解业务上下文"的任务容易出错，这类场景我只把 AI 当参考。

追问方向

你用 AI 生成的代码上线过吗？有没有出过问题？
如果你的同事完全不用 AI 工具，你会怎么说服他？
你觉得现阶段 AI 编码工具最大的痛点是什么？

Q2: 用 AI 辅助编码时，你是如何 Review AI 生成的代码的？有没有踩过坑？ ⭐⭐

面试官隐藏意图

代码质量意识——是否无条件信任 AI 输出
审查方法论——有没有系统的 Review 策略
经验积累——踩过的坑反映了使用深度

好答案 vs 差答案

好答案特征 ✅	差答案特征 ❌
有明确的 Review 流程/清单	"看一眼没问题就用了"
能举出具体的踩坑案例	没有实际案例
根据场景调整信任程度	要么完全信任要么完全不信
提到了类型检查/测试/lint 等验证手段	纯靠肉眼看

示例回答

我有一个"三步 Review"流程：

第一步：快速扫描意图匹配
  → AI 生成的代码是否真的在做我要求的事？
  → 有时候 AI 会"理解偏差"，比如你要它改 A 逻辑，它把 B 也改了

第二步：关键路径审查
  → 重点看：边界条件、错误处理、类型是否正确
  → 看它用了什么依赖——AI 经常推荐已经废弃的库或不存在的 API

第三步：运行验证
  → 必须跑 TypeScript 编译 + 测试
  → 如果是 UI 代码，必须在浏览器看效果

踩过最大的坑：
AI 给我生成了一个 React useEffect 的代码，逻辑看起来完全正确，
但它在 cleanup 函数里用了过期的闭包变量，导致内存泄漏。
上线后偶发 crash，排查了两天才定位到。

从那以后的教训：
1. 涉及副作用和闭包的代码，必须手动审查作用域
2. AI 对"运行时行为"的理解远弱于"静态语法"
3. 跑 React.StrictMode 和 ESLint exhaustive-deps 规则永远不能关

追问方向

你会把 AI Review 流程写成团队规范吗？包含哪些检查项？
AI 生成的代码在性能方面有什么常见问题？
你觉得 AI 最容易在哪类代码上出错？

Q3: Copilot / Cursor / Trae 这类 AI IDE 的核心差异？你选择工具的标准是什么？ ⭐⭐

面试官隐藏意图

技术选型能力——是否有自己的评估框架
工具理解深度——不只是"用过"，而是理解工具的设计哲学
务实态度——不盲目追新，而是根据需求选择

好答案 vs 差答案

好答案特征 ✅	差答案特征 ❌
有多维度对比框架	"Cursor 比较火所以用 Cursor"
了解工具的底层差异（上下文策略、模型选择等）	只知道表面功能
有自己的选择标准和权衡	人云亦云
承认各工具的优缺点	只吹一个踩一个

示例回答

我的评估框架有五个维度：

1. 上下文理解能力
   - Cursor：@codebase 全仓库索引 + @file 精确引用，上下文最强
   - Copilot：基于当前文件 + 相邻 Tab，上下文窗口较小
   - Trae：整合了 Builder 模式，支持多文件同时编辑

2. 交互方式
   - Cursor：Cmd+K 内联编辑 + Chat + Composer（多文件编排）
   - Copilot：Tab 补全为主，Chat 为辅
   - Trae：Chat + Builder + 内联，多模态输入（截图→代码）

3. 模型灵活性
   - Cursor：支持 GPT-4o / Claude 3.5 / 自定义 API
   - Copilot：绑定 GitHub 生态
   - Trae：字节旗下，支持豆包大模型 + Claude

4. 开发体验
   - Cursor：VS Code fork，插件生态完整
   - Copilot：VS Code 原生插件，最轻量
   - Trae：VS Code fork，中文体验好

5. 成本
   - Cursor：$20/月 Pro
   - Copilot：$10/月（GitHub 学生免费）
   - Trae：目前免费

我目前的选择：主力 Cursor，因为多文件编排（Composer）能力最强，
做重构和新功能开发效率最高。但团队协作项目我会同时开 Copilot，
因为它对 Git 工作流的集成更好（PR 描述生成等）。

追问方向

如果给团队选一个 AI IDE，你的决策流程是什么？
你觉得 AI IDE 的下一步发展方向是什么？
如何衡量 AI IDE 对个人生产力的实际提升？

Q4: 你用 AI 做过最复杂的一件事是什么？效果如何？有什么局限性？ ⭐⭐

面试官隐藏意图

使用天花板——AI 在你手里能发挥多大价值
问题拆解能力——复杂任务能否拆成 AI 可处理的子任务
反思能力——是否清楚 AI 的边界在哪里

好答案 vs 差答案

好答案特征 ✅	差答案特征 ❌
任务确实复杂（非"帮我写个函数"）	只做过简单的代码补全
描述了拆解和协作的过程	"直接让 AI 写，一次搞定"
诚实讲述 AI 的局限和自己的干预	只讲成功不讲失败
提到了迭代过程（多轮对话/Prompt 调优）	描述过于简单化

示例回答

最复杂的一次是用 AI 辅助做一个老项目的 JS → TS 迁移。
项目大概 200+ 文件，没有任何类型定义。

我的做法：

1. 先让 AI 分析项目结构，生成模块依赖图
   → 效果不错，帮我确定了迁移顺序（从叶子模块开始）

2. 分模块迁移
   → 每次给 AI 一个文件 + 它的上下游接口
   → AI 加类型注解的准确率大概 60-70%
   → 主要问题：复杂的泛型推断、联合类型、类型守卫经常不对

3. 我的干预策略
   → AI 生成初稿 → 我用 tsc --strict 检查 → 把报错喂回给 AI 修复
   → 对于核心业务模型（20+ 个接口），我手写类型定义，AI 只负责使用

4. 测试修复
   → 类型迁移导致 30% 测试失败
   → AI 批量修复测试中的类型问题，效率很高

最终效果：
- 原计划 4 周，实际 2 周完成
- AI 大概节省了 50% 的时间
- 但核心类型设计还是得人来做，AI 设计的类型层次往往太扁平

局限性总结：
- AI 擅长"模式迁移"（见过足够多 JS→TS 的例子）
- 但不擅长"架构设计"（需要理解业务语义才能设计好的类型层次）

追问方向

你是怎么把复杂任务拆解成 AI 可处理的粒度的？
在这个过程中 Prompt 迭代了几轮？有什么 Prompt 技巧？
如果再做一次，你会改进什么？

Q5: AI 写代码的"幻觉"问题你怎么看？实际工作中如何避免被误导？ ⭐⭐

面试官隐藏意图

对 AI 局限性的理解深度——不只是"知道有幻觉"
防御策略——有没有系统性的应对方法
实际案例——是否真的遇到过并解决了

好答案 vs 差答案

好答案特征 ✅	差答案特征 ❌
能解释幻觉的技术原因	"AI 有时候会瞎编"
分场景分析幻觉频率和危害	笼统地说"不能信"
有具体的防御策略和工具链	只说"多检查"
能举实际案例	纯理论无实践

示例回答

幻觉在编码场景主要有三类：

类型 1：API 幻觉（最常见）
  AI 调用了不存在的方法或参数
  例：给 React 18 建议用 ReactDOM.render（已废弃）
  防御：TypeScript 严格模式 + 编辑器红线提示

类型 2：逻辑幻觉（最危险）
  代码语法正确但逻辑有误
  例：排序函数的比较器返回值反了，不报错但结果错
  防御：单元测试覆盖核心逻辑 + Code Review

类型 3：依赖幻觉
  推荐的 npm 包不存在或已废弃
  例：建议安装 "react-stream-renderer"（不存在的包）
  防御：先 npm search 确认包存在，检查下载量和更新时间

我的防御体系：

1. 工具链守门
   - TypeScript strict + ESLint 严格规则
   - 这能自动拦截 70% 的 API 幻觉

2. 测试验证
   - AI 写的核心逻辑必须配测试
   - 如果 AI 连测试一起写的，我会检查测试是否真的在测对的东西
   （AI 有时候写的测试和实现"共享同一个 bug"）

3. 高危标记
   - 涉及金钱/权限/数据删除的代码，AI 辅助后必须人工逐行审查
   - 这类代码 AI 写完我会手动跑边界用例

4. 心理模型
   - 把 AI 当"能力很强但不靠谱的实习生"
   - 它的输出是"初稿"，不是"终稿"

追问方向

你遇到过 AI 的测试和实现"共享同一个 bug"的案例吗？
如何让 AI 减少幻觉？Prompt 层面有什么策略？
AI 幻觉在不同模型（GPT-4o vs Claude vs 开源模型）之间有差异吗？

Q6: 如何用 AI 提升 Code Review 效率？你会把什么类型的 Review 交给 AI，什么不会？ ⭐⭐

面试官隐藏意图

工程流程优化意识——是否在思考如何将 AI 嵌入现有工作流
任务分类能力——能区分 AI 擅长和不擅长的 Review 类型
质量底线意识——知道哪些不能完全交给 AI

好答案 vs 差答案

好答案特征 ✅	差答案特征 ❌
明确区分了 AI 可做和不可做的 Review 类型	"让 AI Review 所有代码"
有具体的 Review Prompt 或工作流	只说"用 Copilot Review"
提到了与人工 Review 的互补关系	想用 AI 完全替代人工 Review
考虑了团队协作和知识传递	只关注效率不关注质量

示例回答

我把 Code Review 分为"AI 主导"、"AI 辅助"、"纯人工"三个层次：

AI 主导（80%+ 信任度）：
  ✅ 代码规范检查（命名、格式、最佳实践）
  ✅ 重复代码检测
  ✅ TypeScript 类型问题
  ✅ 明显的 bug 模式（空值访问、数组越界）
  ✅ 依赖安全漏洞扫描

AI 辅助（50% 信任度，人工复核）：
  ⚠️ 性能问题（AI 能发现明显问题但可能误报）
  ⚠️ 测试覆盖度建议
  ⚠️ 代码复杂度分析
  ⚠️ API 设计建议

纯人工（AI 参考但不依赖）：
  ❌ 业务逻辑正确性（AI 不懂你的产品）
  ❌ 架构合理性（组件拆分、状态管理策略）
  ❌ 知识传递目的的 Review（带新人，需要解释 why）
  ❌ 安全敏感代码（认证、授权、加密）

我的实际工作流：
  1. PR 提交后 → GitHub Actions 触发 AI Review bot
  2. AI 留评论标注：规范问题 / 潜在 bug / 建议
  3. 人工 Reviewer 看到 AI 标注后，跳过已覆盖的检查项
  4. 人工重点审查：业务逻辑 + 架构 + AI 无法判断的部分

效果：
  - 人工 Review 时间从平均 45 分钟降到 20 分钟
  - Review 覆盖率提升（以前小 PR 经常草草过，现在 AI 至少做了基础检查）
  - 但有个问题：新人过度依赖 AI Review，自己的 Review 能力没长

追问方向

AI Review bot 你用的是什么？自己搭的还是第三方？
如何防止团队成员因为有 AI Review 就降低人工 Review 质量？
AI Review 的误报率高吗？怎么控制？

Q7: 你有没有用 AI 辅助做过技术方案设计或架构决策？效果怎么样？ ⭐⭐⭐

面试官隐藏意图

AI 使用层次——是否已经超越了"写代码"，在更高层次使用 AI
架构思维——即使用 AI 辅助，也能展现架构能力
判断力——是否知道 AI 在高层决策中的角色和边界

好答案 vs 差答案

好答案特征 ✅	差答案特征 ❌
用 AI 做方案"探索"而非"决策"	"让 AI 帮我设计架构"
AI 提供选项 + 自己分析权衡	完全采纳 AI 的方案
描述了 AI 在方案设计中的具体价值	无法区分自己贡献和 AI 贡献
知道 AI 方案的局限（缺乏业务上下文）	对 AI 方案无批判性思考

示例回答

最近一次是设计团队的状态管理架构重构方案。

我用 AI 的方式：

1. 问题梳理阶段
   把现有架构的痛点描述给 Claude：
   "我们有一个 React 项目，目前混用了 Context + Redux + 本地 state，
   数据流混乱，有 50+ 个 Context Provider，性能有问题..."
   
   AI 帮我系统化地梳理了痛点分类，比我自己想到的多了 2-3 个维度

2. 方案探索阶段
   让 AI 分别给出 3 种重构方案（Zustand / Jotai / 继续 Redux）
   每种方案包括：迁移步骤、风险、代码示例
   
   AI 给的方案结构很清晰，但有一个关键问题：
   它不知道我们团队只有 3 个前端，也不知道我们有一半是 Vue 背景
   所以它推荐了 API 最复杂但最灵活的 Jotai

3. 我的判断
   结合团队情况选了 Zustand：
   - API 简单，Vue 背景的同事上手快
   - 社区生态好，文档全中文
   - 性能够用，不需要 Jotai 的原子化细粒度

4. 方案细化
   让 AI 帮我基于 Zustand 写 store 模式模板和迁移指南
   这一步 AI 非常高效，节省了至少一天的文档编写时间

总结：AI 在方案设计中的角色是"全面的参谋"，不是"决策者"。
它能快速给出结构化的方案对比，但缺少团队上下文和业务判断力。
最终的决策必须结合"人、团队、业务"这些 AI 看不到的维度。

追问方向

你觉得 AI 在什么层次的架构决策上可以信任？
如何用 AI 做技术方案的 Trade-off 分析？
你有没有 AI 推荐的方案后来证明不合适的案例？

Q8: Prompt Engineering 在日常开发中的应用：你是怎么写 Prompt 让 AI 生成更精准的代码的？ ⭐⭐

面试官隐藏意图

Prompt 素养——是否有意识地优化自己和 AI 的交互
沟通能力的延伸——能否清晰地表达需求（对 AI 和对人都一样）
方法论思维——是否总结了可复用的 Prompt 策略

好答案 vs 差答案

好答案特征 ✅	差答案特征 ❌
有可复用的 Prompt 模板或策略	"直接描述需求就行"
理解上下文、约束、示例对输出的影响	不了解 Prompt 技巧
有 A/B 对比的经验（改 Prompt 看效果变化）	从不优化 Prompt
结合了角色设定、示例驱动等技巧	Prompt 又长又模糊

示例回答

我总结了一个"CRISP"框架来写编码 Prompt：

C - Context（上下文）
  "这是一个 React 18 + TypeScript + Zustand 的项目"
  "目标浏览器：Chrome 90+"
  "项目用 ESLint airbnb 规范"

R - Role（角色）
  "你是一个资深的 React 工程师"
  有时加约束："不要使用 class 组件，只用函数组件 + Hooks"

I - Instruction（指令）
  具体说做什么、不做什么
  "实现一个 useDebounce Hook，要求：
   - 支持 value 和 callback 两种模式
   - 支持 leading / trailing 选项
   - 返回 cancel 方法"

S - Samples（示例）
  给一个输入输出示例或期望的代码风格
  "参考这种 Hook 的 API 风格：
   const debouncedValue = useDebounce(value, 300)
   const { run, cancel } = useDebounceFn(fn, { wait: 300 })"

P - Post-conditions（后置条件）
  "需要完整的 TypeScript 类型定义"
  "包含 JSDoc 注释"
  "提供至少 3 个测试用例"

实际效果对比：

模糊 Prompt：
  "写一个防抖 Hook" → 生成了 JS 版本，没类型，没测试

CRISP Prompt：
  → 生成了完整的 TS 代码 + 类型 + 测试 + 文档
  → 一次通过率从 30% 提到 80%

另一个常用技巧：Chain of Thought（分步指令）
  复杂任务不要一次丢给 AI，而是分步：
  Step 1: "先列出实现方案和 API 设计"
  Step 2: "基于方案 A 实现核心逻辑"
  Step 3: "添加边界条件处理和测试"

追问方向

你有没有团队共享的 Prompt 库？
不同模型（GPT-4o vs Claude）对 Prompt 风格有偏好差异吗？
你怎么教团队成员写好 Prompt？

Q9: AI 会取代前端工程师吗？你认为未来 3 年前端工程师的核心竞争力是什么？ ⭐⭐⭐

面试官隐藏意图

行业认知深度——不是要"正确答案"，而是看思考深度
自我定位——是否有清晰的职业发展认知
危机意识 + 行动力——不仅看到趋势，还在做准备

好答案 vs 差答案

好答案特征 ✅	差答案特征 ❌
有结构化的分析框架	"不会取代" 或 "会取代" 一句话回答
区分了不同层次的前端工作	把前端工作笼统地谈
提出了具体的"不可替代"能力	抽象地说"创造力"
自己正在做准备	只谈观点不谈行动
承认不确定性	过于肯定

示例回答

我的看法分三层：

第一层：哪些工作会被 AI 替代（1-2 年内）
  - 静态页面切图（设计稿 → 代码）
  - 标准化 CRUD 页面
  - 简单的 Bug 修复
  - 代码格式化、类型补全
  → 这些是"模式匹配"型工作，AI 已经做得不错了

第二层：哪些工作会被 AI 增强但不会被替代（2-3 年）
  - 复杂交互实现（拖拽、动画、手势）
  - 性能优化（需要理解浏览器运行时行为）
  - 组件/架构设计（需要理解业务演进方向）
  → AI 加速 50%+，但决策和质量判断靠人

第三层：哪些工作 AI 短期内做不了（3-5 年）
  - 跨团队技术方案协调
  - 产品-设计-工程三方权衡
  - 用户体验的直觉判断
  - 技术团队管理和人才培养
  → 需要人际理解和商业判断

我认为 5 年经验前端的核心竞争力正在转向：

1. AI 协作能力
   → 能驾驭 AI 的人 vs 不能的，效率差 3-5 倍
   → Prompt 工程、AI 工作流设计、AI 输出质量把控

2. 系统设计能力
   → AI 能写模块，但"模块怎么组合"需要人来设计
   → 微前端、BFF、状态管理策略、性能架构

3. 领域专深
   → 在一个方向上有 AI 替代不了的深度
   → 比如低代码引擎、可视化、编辑器、实时协作

4. 产品 Sense
   → 能从用户视角思考技术决策
   → 技术方案的 ROI 分析

我自己正在做的准备：
  - 深入 AI Agent + 前端结合（这个面试库就是实践之一）
  - 往全栈方向拓展（Node.js + 数据库 + 部署）
  - 刻意练习系统设计（每周做一个系统设计题）

追问方向

如果你是 CTO，会调整前端团队的招聘标准吗？
你觉得 5 年后"前端工程师"这个 Title 还存在吗？
AI 原生应用的前端和传统 Web 前端有什么本质不同？

Q10: 你团队中有推动 AI 工具落地的经验吗？遇到了什么阻力？怎么解决的？ ⭐⭐⭐

面试官隐藏意图

影响力——是否能推动技术变革，而不仅是自己用
执行力——推动过程中遇到困难是否能解决
同理心——是否理解他人的顾虑和阻力来源

好答案 vs 差答案

好答案特征 ✅	差答案特征 ❌
有完整的推动故事（发起→执行→效果→反馈）	"给大家分享了一下"
理解阻力的根本原因	"他们不愿意学新东西"
有渐进式的推动策略	一上来就全面推广
用数据证明效果	只凭感觉说"变好了"
考虑了不同角色的诉求	只从技术角度推动

示例回答

我在团队推动 Cursor 落地的完整过程：

阶段 1：个人验证（2 周）
  - 自己先用 2 周，记录具体的效率数据
  - 对比：有 AI 辅助 vs 无 AI 辅助的同类任务耗时
  - 结论：日常编码效率提升约 40%，Code Review 提升约 30%

阶段 2：小范围试点（1 个月）
  - 拉了 3 个愿意尝试的同事组成试点组
  - 每周分享使用心得和 Prompt 技巧
  - 建了一个 Prompt 共享库

遇到的阻力和解决方案：

阻力 1：安全顾虑——"公司代码传到 AI 服务器不安全"
  → 解决：整理了 Cursor 的数据安全白皮书
  → 和安全团队确认：Cursor Business 支持不存储代码
  → 建议高敏感项目用本地模型（Ollama）

阻力 2：学习成本——"现有工作流已经很顺了，不想改"
  → 解决：不要求全面切换，先从一个场景开始
  → 选了"写单元测试"作为切入点（痛点大、AI 效果明显）
  → 效果立竿见影后，大家主动探索其他场景

阻力 3：质量担忧——"AI 写的代码出了 bug 算谁的？"
  → 解决：制定了 AI 代码审查规范
  → 明确：AI 是辅助工具，代码责任仍归开发者
  → 必须通过现有的 Code Review + CI/CD 流程

阻力 4：ROI 质疑——老板问"这玩意值 $20/月/人 吗？"
  → 解决：用试点组的数据
  → PR 平均合并时间从 4.2 天降到 2.8 天
  → 单元测试覆盖率从 45% 提到 72%
  → 换算：每人每月节省约 2 天工作量

阶段 3：全面推广
  - 出了《AI 辅助开发最佳实践》团队手册
  - 每月"AI Tips"分享会
  - 3 个月后：团队 8 人全部日常使用

核心心得：推动技术变革不能靠"这个东西很酷"，
要解决具体痛点、用数据说话、尊重每个人的接受节奏。

追问方向

推广后有没有观察到什么副作用？
团队中 AI 使用水平参差不齐怎么办？
如果你现在要在一个 50 人的前端团队推广，策略会怎么调整？

Q11: 如何评估 AI 工具对团队生产力的实际提升？有没有量化的方法？ ⭐⭐

面试官隐藏意图

数据驱动思维——是否习惯用数据而非直觉做判断
指标设计能力——能否设计合理的度量体系
全面性——是否考虑了效率之外的维度（质量、满意度）

好答案 vs 差答案

好答案特征 ✅	差答案特征 ❌
有多维度的度量指标	"感觉快了很多"
有对照实验的思路	无法说出具体数字
考虑了负面指标（如代码质量下降）	只看效率不看质量
区分了短期和长期指标	只看短期

示例回答

我设计过一个 AI 效能评估体系，分四个维度：

维度 1：效率指标（最直观）
  - 功能交付周期（Feature Lead Time）
  - PR 从创建到合并的平均时间
  - 每个 Sprint 完成的 Story Point
  - 人均每日代码产出（行数不是好指标，用"有效功能点"）
  
  度量方法：记录引入 AI 前 4 周 vs 引入后 4 周的数据

维度 2：质量指标（防止"快而烂"）
  - 线上 Bug 率（每千行代码的缺陷数）
  - Code Review 打回率
  - 单元测试覆盖率变化
  - TypeScript 类型错误趋势
  
  关键观察：如果效率↑但质量↓，说明 AI 使用方式有问题

维度 3：过程指标（理解 AI 在哪起作用）
  - AI 补全接受率（Cursor/Copilot 后台有数据）
  - 每天使用 AI Chat 的次数和时长
  - AI 生成代码在最终提交中的占比（git blame 分析）
  
  这个维度帮助定位 AI 的价值区域

维度 4：团队感知指标（不能只看数字）
  - 开发者满意度调查（NPS 式评分）
  - "你觉得 AI 帮助最大的场景是？"
  - "你觉得 AI 最让你头疼的问题是？"
  
  每月一次匿名问卷

对照实验设计：
  理想情况：A/B 分组，一组用 AI 一组不用
  现实做法：同一团队，引入前 vs 引入后对比
  注意：要排除其他变量（如需求难度差异、人员变动）

我的实际数据（6 人前端团队，3 个月对比）：
  - 功能交付周期：-25%（从 8 天降到 6 天）
  - PR 合并时间：-33%（从 3 天降到 2 天）
  - 测试覆盖率：+60%（45% → 72%，AI 写测试特别高效）
  - 线上 Bug 率：持平（没降也没升，说明质量守住了）
  - 开发者满意度：8.2/10

追问方向

如果数据显示效率提升了但质量下降了，你怎么调整策略？
不同角色（初级/高级工程师）的 AI 效能提升有差异吗？
如何向非技术的管理者解释 AI 的 ROI？

Q12: 如果让你给团队制定一套 AI 辅助开发规范，你会怎么设计？ ⭐⭐⭐

面试官隐藏意图

规范设计能力——能否制定可落地的技术规范
全面性——是否考虑了安全、质量、流程等多个层面
平衡感——规范太严会抑制效率，太松会失控

好答案 vs 差答案

好答案特征 ✅	差答案特征 ❌
有清晰的结构和分级	零散的几条规则
覆盖全链路（编码/Review/测试/文档）	只关注编码环节
有安全和合规考量	忽略数据安全
有落地和监督机制	只有规范没有执行保障

示例回答

我会设计一个"三级四域"的 AI 辅助开发规范：

═══ 三个使用级别 ═══

L1 - 自由使用（无需审批）
  - 代码补全和格式化
  - 生成注释和文档
  - 生成测试用例
  - 技术调研和学习

L2 - 谨慎使用（需代码审查）
  - 生成业务逻辑代码
  - 代码重构建议
  - 数据库 Query 生成
  - API 接口设计

L3 - 限制使用（需资深 Review + 特别标注）
  - 涉及认证/授权的代码
  - 处理用户敏感数据的代码
  - 金融计算相关代码
  - 生产环境配置变更

═══ 四个规范域 ═══

域 1：安全规范
  - 禁止将 API Key、密码、Token 等发送给 AI
  - 用户隐私数据在发给 AI 前必须脱敏
  - 团队使用企业版 AI 工具（数据不存储、不训练）
  - 定期审计 AI 工具的数据安全政策

域 2：质量规范
  - AI 生成的代码必须通过现有 CI/CD 流程（lint + type check + test）
  - L2/L3 级代码必须在 PR 中标注 "AI-assisted"
  - AI 生成的代码同样适用代码规范（命名、复杂度、注释）
  - 禁止提交未经理解的 AI 代码（"不理解就不合并"原则）

域 3：流程规范
  - 新成员入职培训增加"AI 工具使用指南"模块
  - 团队维护共享 Prompt 库（Notion/Confluence）
  - 每月"AI 实践分享"会议
  - 季度 AI 效能评估

域 4：伦理规范
  - AI 生成内容不用于伪造代码贡献
  - 开源贡献中标注 AI 辅助部分
  - 不完全依赖 AI 做技术决策
  - 鼓励理解 AI 输出的原理，而非盲目使用

═══ 落地机制 ═══
  - 写入团队 Wiki，入职必读
  - CI 检查：扫描提交是否包含 API Key（已有工具如 GitGuardian）
  - Code Review Checklist 新增"AI 代码检查项"
  - 季度回顾和规范迭代

追问方向

如何让规范不变成"形式主义"？怎么确保大家真的遵守？
开源项目和商业项目的 AI 使用规范有什么不同？
如果公司完全禁止使用 AI 工具，你怎么看？

Q13: AI 生成代码的安全隐患有哪些？如何建立团队的 AI 代码安全审查流程？ ⭐⭐⭐

面试官隐藏意图

安全意识——是否意识到 AI 编码的安全风险
系统化思维——能否建立流程而非靠个人警觉
实际案例——是否真实了解 AI 代码的安全问题

好答案 vs 差答案

好答案特征 ✅	差答案特征 ❌
能列举具体的安全风险类型	"AI 代码不安全" 一句话
有预防 + 检测 + 响应的完整链路	只说"多检查"
提到了工具链支持	完全靠人工审查
考虑了数据泄露和知识产权问题	只考虑代码 Bug

示例回答

AI 代码的安全隐患我分为五类：

类型 1：注入漏洞
  AI 经常生成不做输入验证的代码
  例：直接拼 SQL 字符串而非参数化查询
  例：innerHTML 赋值未转义 → XSS

类型 2：敏感信息泄露
  - AI 可能在代码注释中包含示例数据（看起来是假的其实是真的）
  - 硬编码的 API Key（AI 从训练数据中"记住"了某些 Key 模式）

类型 3：依赖链攻击
  AI 推荐不存在的 npm 包 → 攻击者抢注同名恶意包
  （2024 年已有真实案例，叫 "AI package hallucination attack"）

类型 4：逻辑安全漏洞
  - 权限校验不完整（AI 不理解业务权限模型）
  - 竞态条件（AI 不擅长并发安全）
  - CSRF/CORS 配置不当

类型 5：知识产权风险
  AI 可能"记住"并输出开源代码片段
  如果项目是商业闭源，可能引入 GPL 许可证的代码

安全审查流程设计：

┌─────── 开发阶段 ───────┐
│ IDE 层：                 │
│ - 实时扫描 AI 生成代码   │
│ - 检测硬编码的密钥/Token │
│ - 标记未转义的用户输入   │
└────────────┬────────────┘
             ▼
┌─────── 提交阶段 ───────┐
│ Pre-commit Hook：       │
│ - GitGuardian 密钥扫描  │
│ - ESLint security 规则  │
│ - 依赖包存在性验证      │
└────────────┬────────────┘
             ▼
┌─────── CI/CD 阶段 ──────┐
│ Pipeline：               │
│ - Snyk/Dependabot 依赖扫描│
│ - SAST 静态安全分析      │
│ - npm audit              │
│ - License 合规检查       │
└────────────┬────────────┘
             ▼
┌─────── Review 阶段 ─────┐
│ Code Review：            │
│ - AI 代码安全检查清单    │
│ - 重点关注：认证/权限/数据│
│ - 资深成员对 L3 级代码签字│
└──────────────────────────┘

团队落地优先级：
P0（立即）：Pre-commit 密钥扫描 + npm audit
P1（1 周）：ESLint security 规则 + SAST
P2（1 月）：完整 CI 安全 Pipeline + License 检查

追问方向

你提到的"AI 包名幻觉攻击"能详细说说吗？
如何在不影响开发效率的情况下增加安全检查？
前端特有的安全问题（XSS/CSRF/CSP）AI 经常忽略哪些？

Q14: 你怎么看 AI 对初级工程师成长的影响？如果你带团队，会如何引导新人使用 AI？ ⭐⭐

面试官隐藏意图

Leader 视角——5 年经验应该有带人意识
教育理念——对技术成长路径的理解
辩证思维——AI 对新人是"拐杖"还是"加速器"

好答案 vs 差答案

好答案特征 ✅	差答案特征 ❌
看到 AI 对新人的双面影响	只说好处或只说坏处
有具体的引导策略	"让他们自己探索"
区分了不同阶段的使用方式	一刀切的建议
提到了基本功的重要性	认为"有 AI 不需要学基础"

示例回答

AI 对初级工程师是一把双刃剑：

正面影响：
  1. 降低入门门槛 → 更快产出可运行的代码
  2. 即时学习 → 不懂的立刻问 AI，比翻文档快
  3. 接触最佳实践 → AI 生成的代码通常遵循主流模式
  4. 减少挫败感 → 不会卡在低级问题上很久

负面风险：
  1. "知其然不知其所以然" → 代码能跑但不理解原理
  2. 调试能力退化 → 出错直接问 AI，不训练自己的排查能力
  3. 基础薄弱 → 不理解 JS 原型链、闭包等核心概念
  4. 过度依赖 → 离开 AI 无法独立编码

如果我带团队，会设计"三阶段"引导方案：

阶段 1：打地基（前 3 个月）——限制使用
  - 核心概念必须自己学、自己写
    → 闭包、原型链、异步、Promise 必须手写
    → React/Vue 的响应式原理必须能讲清楚
  - 允许用 AI 做"解释器"（问原理）但不允许用来"写答案"
  - 每周 1 次代码手写练习（白板编程）
  
  原则：先学会走，再跑

阶段 2：学会协作（3-6 个月）——引导使用
  - 教 Prompt Engineering 基础
  - 要求 AI 生成的代码必须能向 mentor 解释清楚
  - 刻意练习：AI 写代码 → 新人 Review AI 的代码
    （反转角色，训练审查能力）
  - 鼓励用 AI 写测试（低风险、高效率、能学到边界思维）

阶段 3：自主驾驭（6 个月+）——自由使用
  - 自己决定什么场景用 AI、什么场景手写
  - 参与团队 Prompt 库建设
  - 开始用 AI 做更高级的任务（重构、方案设计）

检验标准：
  新人能否在"断网模式"下独立完成一个中等复杂度的功能？
  如果能 → 基本功扎实，AI 是加速器
  如果不能 → 过度依赖，需要回到阶段 1 补课

追问方向

如果新人反对限制使用 AI（"都什么年代了还手写"），你怎么沟通？
高级工程师有类似的"过度依赖"问题吗？
未来的前端培训体系应该怎么调整来适应 AI 时代？

Q15: 不同类型的开发任务（新功能 / Bug 修复 / 重构 / 性能优化），AI 的适用程度分别怎样？ ⭐⭐

面试官隐藏意图

场景判断力——能否根据任务类型选择最优策略
AI 能力边界认知——哪些任务 AI 强、哪些弱
实践经验——有没有在不同场景下的真实体会

好答案 vs 差答案

好答案特征 ✅	差答案特征 ❌
逐类型分析，有具体的适用度评分	"都能用 AI" 或 "都不太行"
每种类型能说出 AI 擅长和不擅长的点	笼统的描述
基于实际经验	纯理论推测
有"如何用"的具体方法	只说"能用/不能用"

示例回答

我按 AI 适用度从高到低排列：

━━━ 新功能开发 ━━━ 适用度：★★★★☆（80%）
  AI 强项：
  - 脚手架代码生成（组件模板、CRUD 接口、表单）
  - 从设计稿或需求文档生成初版代码
  - API 类型定义和数据 Mock
  
  AI 弱项：
  - 理解业务需求的隐含逻辑
  - 和已有架构的契合度
  
  最佳实践：
  - AI 生成 80% 的"骨架"代码
  - 人工补充业务逻辑和边界处理

━━━ 写测试 ━━━ 适用度：★★★★★（90%）
  AI 强项：
  - 根据函数签名生成测试用例
  - 覆盖边界条件（null/undefined/空数组/极大值...）
  - 生成 Mock 数据
  
  AI 弱项：
  - 不知道哪些业务场景是"关键路径"
  - 集成测试中的环境配置
  
  最佳实践：
  - 人工列出核心测试场景
  - AI 负责实现测试代码 + 扩展边界用例

━━━ Bug 修复 ━━━ 适用度：★★★☆☆（60%）
  AI 强项：
  - 分析报错堆栈，快速定位可能原因
  - 常见 Bug 模式匹配（空值、类型错误、竞态）
  - 给修复方案和代码补丁
  
  AI 弱项：
  - 复现环境相关的 Bug（需要看日志、网络请求）
  - 多因素交叉的 Bug（A 模块改了导致 B 模块出错）
  - 需要理解用户操作路径的 Bug
  
  最佳实践：
  - 先自己定位到问题范围
  - 把相关代码 + 错误信息喂给 AI
  - AI 提供修复方案 + 人工验证

━━━ 代码重构 ━━━ 适用度：★★★☆☆（55%）
  AI 强项：
  - 机械性重构（重命名、提取函数、移动文件）
  - 语法迁移（JS→TS、Options API→Composition API）
  - 依赖升级的 breaking change 修复
  
  AI 弱项：
  - 架构层面的重构（组件拆分策略、状态管理重新设计）
  - 跨模块的重构影响评估
  - 保持重构的"渐进性"（一步一步来 vs 大翻新）
  
  最佳实践：
  - 人工确定重构目标和策略
  - AI 执行具体的代码改写
  - 每步重构都跑测试验证

━━━ 性能优化 ━━━ 适用度：★★☆☆☆（40%）
  AI 强项：
  - 代码层面的优化建议（memo/useMemo/懒加载）
  - 分析 Lighthouse 报告给通用建议
  - Bundle 分析和 Tree Shaking 建议
  
  AI 弱项：
  - 需要 Profiler 数据的优化（渲染瓶颈定位）
  - 特定设备/网络条件下的优化
  - 架构级优化（SSR/ISR/Edge Computing 决策）
  - 性能和功能的 trade-off 决策
  
  最佳实践：
  - 先用工具（DevTools/Lighthouse/WebPageTest）收集数据
  - 把数据给 AI 分析，AI 给建议菜单
  - 人工判断优先级并实施

追问方向

有没有一类任务是你认为完全不应该用 AI 的？
随着 AI 能力提升，你觉得哪个类型的适用度会提升最快？
如何根据任务类型自动选择最佳的 AI 使用策略？

第二部分：好奇心、探索欲与工程师素养

考察思维方式、学习能力、技术视野——区分"螺丝钉"和"技术驱动者"

Q16: 最近半年你关注到的最有意思的前端技术/工具是什么？为什么觉得有意思？ ⭐

面试官隐藏意图

技术敏感度——是否持续关注行业动态
思考深度——不只是"看到了"，而是"想过了"
个人兴趣——有没有真正的技术热情

好答案 vs 差答案

好答案特征 ✅	差答案特征 ❌
提到的技术/工具确实是近半年的	提了一个两三年前的东西
能说出"有意思"的具体原因	"XX 很火所以关注了"
有自己的思考甚至尝试	只看了标题没深入
能联系到实际工作场景	和自己的工作完全无关

示例回答

最近最让我兴奋的是两个方向：

1. React Server Components 的成熟
   有意思的点不是 RSC 本身，而是它代表了一种思维转变：
   前端不再是"全在浏览器跑"，而是"服务端和客户端的最优分配"。
   
   我尝试了 Next.js 15 的 RSC 模式：
   - 把数据获取移到 Server Component，减少了 30% 的 JS Bundle
   - 但也踩了坑：Server/Client 的边界划分需要经验
   - 我觉得这个模式会改变前端的面试方向——以后不只是问"虚拟 DOM"
   
   延伸思考：这和 PHP/Rails 的"后端渲染"有什么本质区别？
   → 本质区别是"可组合性"——RSC 是组件级的混合渲染，不是页面级的

2. Bun 的崛起
   不只是"又一个 runtime"，而是"all-in-one"的理念：
   包管理 + 打包 + 运行 + 测试 全内置
   
   我在个人项目中试了 Bun：
   - npm install 速度是 pnpm 的 3-5 倍
   - 内置的 test runner 性能接近 Vitest
   - 但生态兼容性还是有 gap（一些 npm 包跑不起来）
   
   延伸思考：前端工具链是走向"整合"还是"专精"？
   我觉得是整合趋势——Bun、Turbopack、Biome(Rust) 都在做这件事

追问方向

除了这个，还有什么让你失望的技术？本来很期待结果不行的？
你是通过什么渠道了解到这些新技术的？
你觉得这些趋势会怎么影响你的技术选型？

Q17: 你有自己的 Side Project 或者开源贡献吗？动机是什么？ ⭐⭐

面试官隐藏意图

自驱力——是否在工作之外还投入技术
目的性——做 Side Project 的动机（学习/创造/社区）
持续性——是一时兴起还是持续投入

好答案 vs 差答案

好答案特征 ✅	差答案特征 ❌
有具体的项目 + 动机 + 收获	"想过但没时间"
项目有一定复杂度和完成度	只是 fork 了别人的仓库
动机真实（不是为了"刷 GitHub"）	动机虚假（"为了面试好看"）
从项目中获得了具体的技术成长	说不出收获

示例回答

我目前维护着两个项目：

项目 1：DevCraft（就是这个面试题库项目）
  技术栈：pnpm monorepo + VitePress + TypeScript
  动机：自己要准备面试，同时想系统化整理知识
  收获：
  - 被迫把"感觉会"的知识写成"能讲清楚"的文档
  - 实践了 monorepo 管理和 VitePress 自定义主题
  - mini-react 的实现过程让我真正理解了 Fiber 和 Hooks
  
  核心感悟：教是最好的学——把知识写出来的过程中发现了很多以为懂但其实不懂的盲区

项目 2：一个轻量级的 React 表单验证库
  技术栈：React + TypeScript + Zod
  动机：工作中觉得 React Hook Form 对简单场景太重了
  收获：
  - 第一次发布 npm 包（配置 package.json、CI/CD、语义化版本）
  - 收到了几个 Issue 和 PR，体验了开源协作
  - 设计 API 的过程让我理解了"好用"和"灵活"的平衡

开源贡献：
  - 给 Zustand 文档修过两个中文翻译错误（很小但是第一次 PR）
  - 给 VitePress 报过一个 SSR hydration 的 Bug（被接受了）
  
  感悟：开源贡献的门槛没有想象中高，
  文档翻译和 Bug 报告是很好的起步点

追问方向

做 Side Project 和工作/生活怎么平衡时间？
如果你的项目有人提了一个很大的 Feature Request，你怎么评估要不要做？
你觉得"有 Side Project"和"没有"的工程师有什么差别？

Q18: 你是怎么学习一门新技术的？能用一个具体的例子说说你的学习路径？ ⭐⭐

面试官隐藏意图

学习方法论——有没有可复用的学习框架
学习效率——方法是否高效，能否快速上手
深度学习能力——是否只停留在"能用"层面

好答案 vs 差答案

好答案特征 ✅	差答案特征 ❌
有明确的学习方法论/框架	"看文档，写 Demo"
能用具体例子展示学习路径	抽象地谈方法论
学习路径有层次（浅→深）	一开始就死磕源码
有输出（文档/项目/分享）	只输入不输出

示例回答

我有一个"四层学习法"，以最近学 Zustand 为例：

第 1 层：快速原型（1-2 天）
  目标：能用起来
  - 读官方 Getting Started（不超过 30 分钟）
  - 照着文档写一个 TodoList Demo
  - 不深究原理，先建立"手感"
  
  Zustand 案例：用 create() 写了一个 counter store，
  在组件里用了 useStore，30 分钟跑起来

第 2 层：对比学习（2-3 天）
  目标：理解设计哲学
  - 和我熟悉的技术对比（Zustand vs Redux vs Context）
  - 搞清楚"为什么要用它"（不只是"怎么用"）
  - 阅读作者的设计文档/博客/RFC
  
  Zustand 案例：
  - 画了一张对比表（API 复杂度、Bundle Size、开发体验、TS 支持）
  - 看了 dai-shi（作者）的几篇博客，理解了"去 Provider"的设计动机
  - 用 AI 辅助做技术调研，让 Claude 从 5 个维度对比

第 3 层：源码阅读（1 周）
  目标：理解原理
  - 先看整体架构（入口 → 核心 → 工具）
  - 重点突破 1-2 个核心机制
  - 写笔记记录理解过程
  
  Zustand 案例：
  - Zustand 源码只有 ~400 行，非常适合阅读
  - 核心突破：发现它本质是发布-订阅模式 + useSyncExternalStore
  - 写了一篇笔记《Zustand 源码 400 行里的设计智慧》

第 4 层：实战输出（持续）
  目标：真正掌握
  - 在实际项目中使用
  - 写一个 Mini 版本（加深理解）
  - 分享给团队或写博客
  
  Zustand 案例：
  - 在工作项目中替换了一个 Context + useReducer 的状态管理
  - 写了一个 50 行的 mini-zustand
  - 在团队内做了一次分享

这个方法的关键原则：
  ① 先广后深（快速上手 → 逐步深入）
  ② 对比学习（新知识锚定到已有知识）
  ③ 以输出倒逼输入（写文章/分享/造轮子）
  ④ 不追求一次学到位（允许多轮迭代）

追问方向

你的学习时间怎么安排？工作日和周末的分配？
有没有学了一半放弃的技术？为什么放弃了？
如何判断一门新技术值不值得深入学习？

Q19: 说一个你在工作中主动发起的技术改进，不是被要求的，是你自己想做的 ⭐⭐

面试官隐藏意图

主动性——是否只做被安排的任务
技术敏锐度——能否发现问题和改进空间
推动力——发现问题后能否推动解决

好答案 vs 差答案

好答案特征 ✅	差答案特征 ❌
是自己发现的问题、自己发起的	"Leader 让我优化的"
有明确的问题 → 方案 → 实施 → 效果	只说了方案没说效果
经历了困难和阻力并克服了	一帆风顺没有挑战
给团队带来了可量化的价值	效果模糊

示例回答

我主动推了一个"前端构建提速"项目。

发现问题：
  某天等 CI 构建的时候看了下数据：
  - 本地 dev 启动：45 秒
  - CI 构建：8 分钟
  - 团队每天跑 50+ 次 CI
  → 每天浪费 50 × 8 ÷ 60 ≈ 6.7 小时在等构建
  这个数字让我震惊了

发起过程：
  1. 先花了 2 天做分析，用 speed-measure-plugin 定位瓶颈
  2. 做了一个 Proposal，给 Leader 看数据和方案
  3. 申请了 2 个 Sprint 的"技术改进 Buffer"

具体改进（Webpack 5 → Vite 迁移 + CI 优化）：
  1. 本地开发从 Webpack 迁移到 Vite
     - 最大挑战：项目有 100+ 个 require() 需要改成 ESM
     - 用了 babel 插件批量转换，剩余手动修复
     
  2. CI 构建优化
     - 开启持久化缓存（Webpack 5 filesystem cache）
     - 引入 Turborepo 做增量构建
     - Docker Layer 缓存优化 node_modules

  3. 依赖优化
     - 用 Bundle Analyzer 找出了 3 个巨大的依赖
     - moment.js → dayjs（-300KB）
     - lodash 全量引入 → 按需引入（-200KB）

遇到的阻力：
  "现在构建能跑就行，改万一出问题怎么办？"
  → 我做了详细的风险评估和回滚方案
  → 先在一个非核心子项目试点，成功后再推广

最终效果：
  - 本地 dev 启动：45s → 3s（Vite 的 No-Bundle 模式）
  - CI 构建：8min → 2min（缓存 + 增量）
  - Bundle Size：-500KB（依赖清理）
  - 按之前的计算，每天节省 ~5 小时等待时间

个人收获：
  - 深入理解了构建工具的工作原理
  - 学会了用数据驱动技术决策
  - 获得了团队信任，后来 Leader 给了我更多技术决策权

追问方向

如果这个改进做到一半发现效果不好，你会怎么处理？
除了构建速度，你还发现过什么值得改进但被忽视的问题？
你怎么判断一个技术改进"值得做"而不是"为了技术而技术"？

Q20: 你怎么看待"技术债务"？遇到遗留代码你的第一反应是什么？ ⭐⭐

面试官隐藏意图

工程素养——对技术债务有没有成熟的认知
务实态度——是"洁癖式重写"还是"渐进式改良"
同理心——是否能理解历史代码存在的原因

好答案 vs 差答案

好答案特征 ✅	差答案特征 ❌
承认技术债务是正常的、不可避免的	"有债务说明之前的人水平不行"
有分类和优先级策略	"全部推翻重写"
理解债务背后的历史原因	只看到表面问题
有"还债"的方法论	要么不还，要么一口气还完
在功能迭代中逐步改善	停下业务专门还债

示例回答

我的技术债务观：

首先，技术债务不是"坏事"——它是一种"权衡"。
就像金融里的贷款，合理的债务能加速发展，
关键是要"有意识地借债"和"有计划地还债"。

我把技术债务分为四象限：

               有意                     无意
  ┌─────────────────────┬─────────────────────┐
  │ 战略性债务            │ 认知性债务            │
审│ "先上线，之后重构"    │ "当时不知道更好的方案"  │
慎│ → 需要记录和计划还债  │ → 需要 Code Review 预防│
  ├─────────────────────┼─────────────────────┤
  │ 投机性债务            │ 草率性债务            │
鲁│ "管它呢先交差"        │ "随便写的，能跑就行"  │
莽│ → 最危险，要及时止损  │ → 需要编码规范约束    │
  └─────────────────────┴─────────────────────┘

遇到遗留代码，我的反应顺序：

1. 先理解，不要急着改
   → "为什么当时写成这样？"
   → 去看 Git History 和 PR 描述
   → 可能当时有特殊约束（紧急需求/历史 API/兼容性）

2. 评估影响范围
   → 这段代码还活跃吗？改动频率高不高？
   → 如果半年没人碰，可能不值得现在改
   → 如果每个 Sprint 都因为它出 Bug → 高优先级

3. 渐进式改善（Scout Rule）
   → "让代码比你发现它时更好一点"
   → 每次碰到这个文件，改善一小部分
   → 比如：加个类型、提取个函数、补个测试

4. 如果需要大改，先写 RFC
   → 评估 ROI：改的成本 vs 不改的持续痛苦
   → 定义"目标状态"和"迁移路径"
   → 分阶段实施，每个阶段可独立上线

实际案例：
  接手一个 3000 行的"上帝组件"（God Component）
  第一反应不是重写，而是：
  - 先给它加了测试（40+ 个测试用例保护行为）
  - 然后每个 Sprint 从中提取 1-2 个子组件
  - 6 个 Sprint 后，拆成了 12 个清晰的子组件
  - 全程没有 regression，因为测试保护了每步改动

追问方向

你怎么说服产品经理给你时间还技术债？
"重写 vs 重构"你怎么选择？
如何防止新代码引入新的技术债务？

Q21: 前端的边界在哪里？你觉得前端工程师应该往什么方向扩展能力？ ⭐⭐

面试官隐藏意图

技术视野——是否看到了前端之外的世界
成长规划——有没有清晰的技术发展方向
深度 vs 广度——如何平衡专精和全栈

好答案 vs 差答案

好答案特征 ✅	差答案特征 ❌
有结构化的思考框架	"什么都学一点"
能说出前端边界正在扩展的具体方向	"前端就是写页面"
有自己的扩展方向和行动	只有想法没有行动
理解"深度"和"广度"的平衡	要么过窄要么过散

示例回答

我觉得前端的边界正在从三个方向扩展：

方向 1：向下——底层和基建
  - 构建工具（Vite/Turbopack/Rspack）
  - 跨端方案（React Native/Tauri/Electron）
  - 编译器和 AST（Babel/SWC/OXC）
  - WebAssembly / WebGPU
  
  适合人群：对底层原理有热情、喜欢写工具链的人
  我的尝试：实现了 mini-react，理解了 Fiber 和 Reconciliation

方向 2：向上——全栈和产品
  - Node.js 后端（BFF、SSR、API 层）
  - 数据库和 ORM（Prisma/Drizzle + PostgreSQL）
  - DevOps 基础（Docker/CI/CD/Vercel）
  - 产品思维和用户体验
  
  适合人群：想独立交付完整功能的人
  我的尝试：用 Next.js + Supabase 做了一个全栈项目

方向 3：向前——AI 和新交互
  - AI Agent 前端（Prompt UI/流式渲染/工具调用）
  - MCP 协议和 Skill 系统
  - 空间计算（AR/VR/Vision Pro）
  - 多模态交互（语音/手势/视觉）
  
  适合人群：喜欢探索新技术、愿意做第一批吃螃蟹的人
  我的尝试：正在系统学习 AI Agent + 前端结合

我个人的策略是"T 型"发展：

    AI Agent   全栈
       │         │
  ─────┼─────────┼─────── 前端核心（深度）
       │         │
       
  横轴：前端核心能力（React/性能/架构）保持深度
  纵轴：选 1-2 个方向做深入探索

为什么选 AI + 全栈：
  - AI：增量最大的新方向，前端是 AI 应用的第一入口
  - 全栈：能独立交付产品，提升个人价值密度
  - 两者结合：全栈 AI 应用开发者是市场稀缺角色

追问方向

"T 型"和"π 型"人才你更推荐哪种？
如何在工作中创造机会去扩展技术边界？
你觉得 5 年后前端工程师的 JD 会怎么写？

Q22: 你有没有读过某个开源库的源码？选它的原因是什么？收获了什么？ ⭐⭐

面试官隐藏意图

学习深度——是否有"透过现象看本质"的习惯
源码阅读能力——这是区分"使用者"和"理解者"的标志
技术选择——为什么读这个而非那个

好答案 vs 差答案

好答案特征 ✅	差答案特征 ❌
说出了具体读的库和动机	"看过 React 源码"（大而空）
能讲出核心机制和关键代码	只知道大概结构
有明确的收获和应用	"看了但记不清了"
读的是适合自己水平的库	生啃万行巨型项目

示例回答

我读过 3 个库的源码，深度不同：

1. Zustand（完整精读，~400 行）
   选择原因：工作中用得多 + 代码量小 + 设计精妙
   
   核心收获：
   - 本质是 createStore（发布-订阅）+ useSyncExternalStore（React 集成）
   - 理解了"为什么不需要 Provider"：Store 是模块级单例，不依赖 Context
   - 中间件模式特别优雅：
     create 接受一个 stateCreator 函数
     中间件本质是对 stateCreator 的包装/拦截
     devtools、persist、immer 都是同一个模式
   
   应用：我仿写了一个 50 行的 mini-zustand，用在团队分享中

2. SWR（选读核心，~2000 行）
   选择原因：想理解数据请求库的缓存策略
   
   核心收获：
   - stale-while-revalidate 策略的实现
   - 缓存用 Map，key 是序列化后的参数
   - deduplication（请求去重）：同一个 key 的并发请求只发一次
   - 全局状态同步：一个组件 revalidate，所有同 key 的组件都更新
   
   应用：理解了 SWR 后，在技术选型时能精准对比 SWR vs React Query

3. Vite（选读 HMR 模块）
   选择原因：迁移 Webpack → Vite 时想理解 HMR 原理
   
   核心收获：
   - Vite 的 HMR 基于 ESM 的 import.meta.hot API
   - 模块图（Module Graph）：记录模块间依赖关系
   - HMR 传播机制：从变更文件沿依赖图向上传播
   - 找到 accept 边界就局部更新，找不到就全量刷新
   
   应用：解决了一个 HMR 不生效的问题
   （某个循环依赖导致传播路径断裂）

源码阅读方法论：
  ① 从小库开始（<1000 行）
  ② 带着问题读（"它怎么实现 XX 功能的？"）
  ③ 先看入口和 Public API，再深入内部
  ④ 用 debugger 跟执行流程
  ⑤ 读完写笔记或分享

追问方向

你读源码时遇到看不懂的部分怎么处理？
读源码对你写代码的风格有什么影响？
你会推荐哪些库适合初学者读源码？

Q23: 技术选型时你考虑哪些因素？有没有一次选型后来证明是错的？你怎么处理的？ ⭐⭐⭐

面试官隐藏意图

决策能力——技术选型是 5 年工程师的核心技能
评估维度——是否有系统的评估框架
反思能力——能否从错误中学习

好答案 vs 差答案

好答案特征 ✅	差答案特征 ❌
有多维度的评估框架	"选最火的"
考虑了团队和业务因素，不只是技术	只看技术指标
有失败案例且能反思原因	从未选错过（不真实）
有止损和补救策略	选错了硬扛到底

示例回答

我的技术选型框架叫"TEAMS"：

T - Technical Fit（技术匹配度）
  → 能否满足当前和预期的技术需求？
  → 性能表现如何？有没有硬伤？
  
E - Ecosystem（生态）
  → 社区活跃度？npm 下载量趋势？
  → 插件/扩展是否丰富？
  → 是否有商业公司/基金会支持？

A - Adoption Cost（使用成本）
  → 团队学习曲线？和现有技术栈兼容性？
  → 迁移成本？如果要换掉，退出成本高不高？

M - Maintenance（可维护性）
  → 文档质量？TypeScript 支持？
  → 更新频率？Breaking Changes 多不多？
  → 长期生命周期（会不会突然停更）？

S - Scale（规模适配）
  → 能否支撑业务增长？
  → 团队规模扩大后还合适吗？

一次选错的案例：

项目：团队内部管理后台
选型：选了 Ant Design Pro（全家桶方案）

当时的判断：
  ✓ 开箱即用，开发快
  ✓ 组件丰富，后台场景完美
  ✓ 团队有 React 经验

后来暴露的问题：
  ✗ 强绑定 umi + dva（Redux-Saga），太重了
  ✗ 升级困难，每次 Ant Design 大版本升级都是噩梦
  ✗ 脚手架生成了大量"约定大于配置"的代码，团队不理解内部机制
  ✗ 定制需求和框架约定冲突，改底层代码很痛苦

反思错在哪：
  我当时过于看重"开发速度"（T 维度高分），
  忽视了"退出成本"和"定制成本"（A 和 M 维度）。
  
  全家桶方案 = 高启动速度 + 高耦合度 + 低灵活性
  适合标准化项目，不适合需要大量定制的项目。

补救措施：
  1. 没有推翻重来（沉没成本太高）
  2. 逐步解耦：用 React Router 替换 umi 路由
  3. 新页面用独立组件方案（Ant Design + 自己的布局）
  4. 制定迁移路线图，随功能迭代逐步替换

教训总结：
  选型前问自己三个问题：
  ① 如果半年后这个方案不行了，我能全身而退吗？
  ② 团队新人来了，能快速理解这套方案吗？
  ③ 1 年后业务规模翻 3 倍，这个方案还撑得住吗？

追问方向

你怎么说服团队接受你的选型建议？
如何做技术选型的 PoC（概念验证）？
选型分歧时，团队怎么达成一致？

Q24: 你觉得一个优秀的前端工程师和一个普通的前端工程师，核心差别在哪里？ ⭐⭐

面试官隐藏意图

自我认知——对"优秀"的定义反映了你的价值观
成长方向——你在朝什么方向努力
团队视角——是否理解个人能力如何转化为团队价值

好答案 vs 差答案

好答案特征 ✅	差答案特征 ❌
不只是技术维度，包含软技能	"技术好就是优秀"
有具体的行为差异描述	空泛的形容词
能结合自身经历说	纯理论
承认自己还在路上	暗示自己已经是"优秀"

示例回答

我观察到的核心差别有五个层次：

第 1 层：解题能力
  普通：能按需求写出功能
  优秀：能用最合适的方案解决问题，而不是第一个能跑的方案
  
  例子：实现一个列表筛选
  普通 → 直接在组件里 filter，能用就行
  优秀 → 考虑数据量、是否需要服务端筛选、筛选条件是否要持久化到 URL

第 2 层：工程思维
  普通：关注"这个功能怎么实现"
  优秀：关注"这个功能如何可维护、可测试、可扩展"
  
  例子：写一个表单
  普通 → 一个大组件搞定
  优秀 → 拆分为 FormField 组件、验证逻辑、提交逻辑
         考虑复用性和未来的需求变更

第 3 层：全局视角
  普通：只看自己负责的模块
  优秀：理解整个系统，知道自己的代码如何影响其他部分
  
  例子：修一个 Bug
  普通 → 修好这个 Bug
  优秀 → 修 Bug + 思考为什么会出这个 Bug + 怎么防止同类问题

第 4 层：影响力
  普通：自己写好代码
  优秀：提升团队整体水平
  
  体现在：
  - Code Review 不是挑毛病，而是传递最佳实践
  - 主动建设基础设施（组件库、工具、规范）
  - 乐于分享和带人

第 5 层：商业意识
  普通：完成产品经理的需求
  优秀：理解需求背后的业务目标，提出更好的技术方案
  
  例子：产品要一个"实时搜索"功能
  普通 → 每次输入都请求 API
  优秀 → 加 debounce + 缓存 + 建议用户用明确的搜索词
         并反馈"如果加个搜索建议下拉框，用户体验会更好"

我给自己的定位：
  第 1-2 层已经比较扎实
  第 3 层正在提升（通过做架构设计和跨团队协作）
  第 4-5 层是下一步的重点（正在通过带人和技术分享来实践）

追问方向

你觉得这五个层次可以通过什么方式训练？
你见过"技术很强但不算优秀"的工程师吗？差在哪？
在面试中你怎么判断候选人处于哪个层次？

Q25: 如果给你一周的自由学习时间，你会去研究什么？ ⭐

面试官隐藏意图

内在驱动力——没有外部压力时，你的技术兴趣在哪
选择能力——面对无限可能，你如何聚焦
自我认知——是否清楚自己的知识短板

好答案 vs 差答案

好答案特征 ✅	差答案特征 ❌
有明确的主题和计划	"看看有什么新技术"
说出选择的理由	没有逻辑，随便挑一个
计划可执行（一周能出成果）	目标太大不切实际
和个人发展方向一致	和当前方向完全无关

示例回答

如果有一周自由时间，我的计划：

主题：从零实现一个 Mini LangGraph（AI Agent 编排引擎）

为什么选这个：
  1. 这是我技术路线图上的关键缺口
     → 目前在前端 AI 方面更偏"UI 层"
     → 想深入理解 Agent 的"编排层"
  
  2. 一周刚好能出成果
     → LangGraph 的核心是状态机 + 消息传递
     → 简化版大概 500-800 行代码

  3. 学以致用
     → 实现后可以集成到 DevCraft 项目中
     → 可以写一篇深度技术文章

一周计划：

Day 1-2：研究 + 设计
  - 精读 LangGraph 源码中 StateGraph 的核心
  - 理解节点（Node）、边（Edge）、条件边（ConditionalEdge）
  - 画出简化版的架构图

Day 3-4：核心实现
  - 实现 StateGraph 类（addNode/addEdge/compile）
  - 实现 Annotation（状态定义 + reducer）
  - 实现条件路由和循环支持
  - 用 TypeScript 写，确保类型安全

Day 5：集成 LLM
  - 对接 OpenAI API
  - 实现一个 Tool Calling Node
  - 写一个 ReAct Agent 的 Demo

Day 6：测试 + 文档
  - 单元测试覆盖核心逻辑
  - 写 README 和使用指南
  - 和官方 LangGraph 做对比

Day 7：输出
  - 写一篇《500 行实现一个 Mini LangGraph》博客
  - 在团队做一次分享
  - 发布到 GitHub

预期收获：
  ① 真正理解 Agent 编排的核心机制
  ② 一个可展示的开源项目
  ③ 一篇高质量的技术文章
  ④ 为后续做 AI Agent 应用打下基础

追问方向

如果只给你 3 天呢？你会怎么缩减？
你觉得"自由学习时间"在公司里应该被鼓励吗？
上一次你真正拿出时间自由学习是什么时候？

Q26: 说一个你最有成就感的技术项目，你在其中承担什么角色？做了哪些关键决策？ ⭐⭐

面试官隐藏意图

项目深度——是否在项目中有核心贡献
决策能力——关键决策体现技术判断力
影响力范围——是个人贡献还是团队级影响

好答案 vs 差答案

好答案特征 ✅	差答案特征 ❌
有明确的项目背景和目标	"我做了很多项目"
清晰的角色和贡献	描述了团队成果但看不出个人贡献
有关键决策 + 决策理由 + 决策效果	只说做了什么不说为什么
有成就感的原因是真实的	成就感来源是"被表扬了"

示例回答

最有成就感的项目：公司内部低代码平台的前端架构设计

项目背景：
  - 公司有 30+ 个内部管理后台，每个都是独立项目
  - 大量重复开发：表格、表单、审批流程...
  - 目标：做一个低代码平台，让非前端也能搭建管理后台

我的角色：前端架构负责人（3 人前端小组）

关键决策 1：渲染引擎选型
  选项 A：基于模板（JSON Schema → 固定组件）
  选项 B：基于 AST（可视化编辑 → 生成代码 → 运行代码）
  
  我的决策：选 A，因为：
  - 用户是运营和产品，不需要代码级灵活性
  - 模板方案开发成本低 3 倍
  - 更好控制产出质量（不会生成垃圾代码）
  
  效果：3 个月上线 MVP，覆盖了 80% 的常见场景

关键决策 2：组件通信方案
  平台中的组件需要互相联动（如选择器联动、条件显隐）
  
  方案对比：
  - Props Drilling：太死板
  - 全局 Store：太重
  - 事件总线：灵活但难调试
  
  我的决策：设计了一个"响应式数据流"方案
  - 每个组件声明自己的输入/输出
  - 平台维护一个数据流图（DAG）
  - 当一个组件输出变化，自动触发依赖它的组件更新
  - 类似 Excel 公式的依赖传播
  
  效果：用户可以通过"连线"配置组件联动，零代码

关键决策 3：发布策略
  低代码平台的页面如何部署？
  
  我的决策：页面配置存在数据库，运行时动态渲染
  而非生成静态代码部署
  
  原因：
  - 允许"实时发布"（修改配置立即生效）
  - 避免了代码构建和部署流程
  - 牺牲了一点首屏性能，但后台场景可以接受

成就感来源：
  不是被表扬，而是看到运营同事用我们的平台
  10 分钟搭建了一个审批页面——这之前需要前端开发 3 天。
  "用技术解放他人的生产力"是最大的成就感。

追问方向

这个项目中最大的技术挑战是什么？
如果重新做，你会改变哪个决策？
你是怎么获得架构负责人这个角色的？

Q27: 遇到一个你完全不了解的技术领域，你会怎么在 2 周内快速上手并产出？ ⭐⭐⭐

面试官隐藏意图

快速学习能力——这是高级工程师的核心竞争力
方法论——有没有可复用的"快速上手"策略
务实产出——不是"学会了"，而是"能产出"

好答案 vs 差答案

好答案特征 ✅	差答案特征 ❌
有清晰的分阶段策略	"看文档、写 Demo"
强调"产出"而非"学完"	想把整个领域学完再动手
善于利用外部资源（人、AI、社区）	闭门造车
有具体的时间分配	没有时间规划

示例回答

我用"RAPID"方法论快速上手新领域：

R - Research（第 1-2 天）：快速扫描
  - 花 2 小时看该领域的 Awesome List / 综述文章
  - 用 AI 做"新手入门"问答：
    "WebGL 领域的核心概念有哪些？按学习顺序排列"
  - 找到该领域 Top 3 的学习资源
  - 目标：建立全局认知，知道"不知道什么"
  
A - Ally（第 2-3 天）：找到"领路人"
  - 找一个该领域有经验的同事做 30 分钟访谈
  - 问三个关键问题：
    ① 新手最容易踩的坑是什么？
    ② 哪些概念是"必须懂的"，哪些可以跳过？
    ③ 推荐一个最能说明核心思想的小项目
  - 如果没有人可以问，就去 Discord/GitHub Discussion 问

P - Prototype（第 3-7 天）：动手做最小原型
  - 不要从零开始，找一个 Starter Template / 官方示例
  - Clone 下来跑起来 → 理解每一行代码
  - 在此基础上做微调/扩展
  - 遇到不懂的就查，但不深究（记录下来以后再学）
  
  关键原则：80/20 法则——用 20% 的知识产出 80% 的效果

I - Iterate（第 7-12 天）：在产出中迭代
  - 开始做实际的产出任务
  - 每天记录"今天不懂的东西"，晚上花 30 分钟补课
  - 频繁向有经验的人请教 Review
  - 不求完美，先完成再完善

D - Document（第 12-14 天）：输出文档
  - 把学到的知识整理成文档/指南
  - 包括：核心概念、常见坑、最佳实践
  - 既是自己的学习总结，也是给后人的参考

实际案例：2 周上手 Three.js + WebGL

  Day 1-2：看了 Three.js Journey 前 5 课 + AI 问答核心概念
  Day 2-3：找到公司 3D 团队的同事，做了一次 1 对 1
  Day 3-7：照着 Three.js 官方示例做了一个 3D 产品展示
  Day 7-12：在实际项目中实现了一个 3D 数据可视化面板
  Day 12-14：写了《前端工程师的 Three.js 2 周速成指南》

产出质量当然不如资深 WebGL 工程师，
但对于项目需求来说完全够用了。

追问方向

快速上手和深入精通之间，你怎么决定要不要继续深入？
有没有这个方法失败的时候？
如何评估自己的"上手程度"是否足够产出？

Q28: 你和同事在技术方案上产生分歧怎么办？能举一个实际的例子吗？ ⭐⭐

面试官隐藏意图

沟通协作能力——技术分歧考验的不只是技术
说服力——能否用理性而非权威说服他人
开放心态——是否能接受自己可能是错的

好答案 vs 差答案

好答案特征 ✅	差答案特征 ❌
有具体案例，不是泛泛而谈	"我们会讨论然后达成一致"
展示了尊重对方观点	"我证明了我是对的"
用事实/数据/实验说话	靠职级/年资压人
接受过自己是错的情况	每次都是自己赢

示例回答

一次真实的案例：状态管理方案选择

背景：
  新项目启动，需要选状态管理方案。
  我推荐 Zustand，同事 A 推荐 Redux Toolkit。

分歧点：
  我：Zustand 更轻量、API 更简单、团队学习成本低
  A：Redux Toolkit 生态更成熟、有 RTK Query、企业级验证更多

我的处理过程：

1. 先听对方讲完（不急着反驳）
   → A 的核心担忧是：Zustand 遇到复杂场景够用吗？
   → 这是合理的担忧，我需要回应而不是回避

2. 对齐评判标准
   "我们先定一下这次选型最看重的 3 个因素吧"
   → 达成一致：学习成本 > TypeScript 支持 > 中间件生态

3. 用事实替代观点
   → 我花了半天写了两个 PoC：
   → 同一个功能（CRUD + 乐观更新 + 缓存）用两种方案实现
   → 对比代码量、类型推断、开发体验

4. 让第三方参与
   → 拉了 2 个没参与讨论的同事来看 PoC
   → 让他们"盲选"哪个代码更好理解
   → 结果 2:0 选了 Zustand 版本

5. 做出让步
   → A 提出的 RTK Query 的服务端状态管理确实更好
   → 最终方案：Zustand（客户端状态）+ React Query（服务端状态）
   → 取两者之长

这次的经验：
  - 技术分歧的本质不是"谁对谁错"，而是"信息不对称"
  - PoC 比争论有效 100 倍
  - 最好的方案往往是"综合两方观点"
  - 即使你是对的，让对方有参与感很重要

我也有被说服的时候：
  某次我推 CSS-in-JS，同事推 Tailwind
  实际用了 2 周后发现 Tailwind 的开发速度确实更快
  我主动承认"你是对的"，然后全面切换
  → 承认错误不丢人，固执己见才丢人

追问方向

如果是和你的 Leader 产生分歧呢？
如何在团队中建立"安全的技术讨论"文化？
你有没有因为坚持自己的观点最后导致不好结果的经历？

Q29: 如何衡量前端项目的技术健康度？如果接手一个"烂摊子"项目，你的前 3 步是什么？ ⭐⭐⭐

面试官隐藏意图

工程判断力——能否快速评估项目质量
系统化思维——有没有评估框架
务实行动力——评估完后能否有效行动

好答案 vs 差答案

好答案特征 ✅	差答案特征 ❌
有量化的健康度指标	"看看代码写得好不好"
有优先级排序的行动计划	"全部重写"
先稳定再改进（不是先推翻）	上来就大刀阔斧改
考虑了团队和业务因素	只看技术维度

示例回答

一、技术健康度评估框架（"HEALTH" 模型）

H - How it runs（运行状态）
  □ 线上错误率（Sentry 报错趋势）
  □ 性能指标（Core Web Vitals：LCP/FID/CLS）
  □ 构建成功率
  → 评分：绿（健康）/ 黄（需关注）/ 红（紧急）

E - Engineering Quality（工程质量）
  □ TypeScript 覆盖率
  □ 测试覆盖率
  □ ESLint 违规数量
  □ 代码复杂度（Cyclomatic Complexity）
  → 可以用 SonarQube / CodeClimate 自动扫描

A - Architecture（架构）
  □ 组件粒度是否合理？有没有"上帝组件"？
  □ 状态管理是否清晰？数据流向是否单向？
  □ 依赖关系是否合理？有没有循环依赖？
  □ 模块边界是否清晰？

L - Lifecycle（生命周期）
  □ 依赖是否过时？有没有安全漏洞？
  □ Node.js / 框架版本是否在维护期内？
  □ 构建工具是否现代化？

T - Team（团队维度）
  □ 新人上手需要多长时间？
  □ 有没有文档和 README？
  □ 代码规范是否一致？

H - History（历史债务）
  □ TODO/FIXME/HACK 注释数量
  □ 知名的"雷区"（大家都知道不能碰的代码）
  □ 长期未关闭的 Issue 数量

二、接手"烂摊子"的前 3 步

第 1 步：止血（第 1 周）
  不改任何架构，先解决最痛的问题
  
  具体动作：
  - 搭建监控：接入 Sentry（如果没有的话）
  - 修复 P0 Bug：影响用户的关键问题
  - 加安全网：
    → npm audit fix（修复安全漏洞）
    → 对核心功能加最基础的 E2E 测试（防止后续改动 break）
  
  原则：先让它"不再恶化"

第 2 步：摸底（第 2 周）
  全面评估，形成"体检报告"
  
  具体动作：
  - 跑 HEALTH 评估，给每个维度打分
  - 画模块依赖图（可以用 madge 工具）
  - 找 3 个最老的团队成员聊天，了解"为什么变成这样"
  - 输出：一份项目体检报告 + 问题优先级列表
  
  原则：先理解再判断

第 3 步：规划（第 3 周）
  制定改进路线图
  
  具体动作：
  - 按 ROI 排序问题（高影响 + 低成本 → 先做）
  - 区分"修"和"改"：
    → 修：在不改架构的情况下修补
    → 改：需要架构调整的改进
  - 把改进任务融入日常迭代（每个 Sprint 留 20% 给改进）
  - 设定阶段目标（比如"3 个月内测试覆盖率从 5% 到 40%"）
  
  原则：渐进改善，不要大爆炸式重写

切记不要做的事：
  ✗ 第一天就说"这代码太烂了要重写"
  ✗ 不了解历史就批判前人
  ✗ 停下业务全力还债
  ✗ 不和团队对齐就开始改

追问方向

你怎么和业务方沟通"需要时间还债"？
如果体检后发现问题太多，你怎么选择优先级？
你有没有真的接手过"烂摊子"？最后结果怎么样？

Q30: 你关注哪些技术社区/信息源？怎么筛选有价值的技术信息？如何避免"信息焦虑"？ ⭐

面试官隐藏意图

信息获取能力——是否有高效的信息渠道
信息筛选能力——面对信息爆炸能否聚焦
学习可持续性——有没有良性的学习习惯

好答案 vs 差答案

好答案特征 ✅	差答案特征 ❌
有结构化的信息获取体系	"刷推特看到什么读什么"
有筛选机制和优先级	什么都看，信息过载
兼顾广度和深度	只关注一两个渠道
有自己的"反焦虑"策略	因为跟不上而焦虑

示例回答

我有一个"三层信息漏斗"：

第 1 层：广撒网（每天 15 分钟，手机上刷）

  信息源：
  - Twitter/X：关注了 Dan Abramov、Evan You、Theo、
    Guillermo Rauch 等核心人物
  - GitHub Trending：每周看一次前端相关趋势
  - 前端早早聊 / 奇舞精选 / 前端之巅（公众号）
  - Hacker News 前端相关
  
  目的：知道"行业在发生什么"

第 2 层：精筛选（每周 2-3 小时，电脑上读）

  信息源：
  - 官方博客：React Blog、Vercel Blog、Chrome Developers
  - 技术周刊：JavaScript Weekly、React Status、Node Weekly
  - 技术大会：React Conf、ViteConf、Next.js Conf（看录播）
  - YouTube：Fireship、Theo、Jack Herrington
  
  筛选标准（我的"3 问"过滤器）：
  ① 和我当前工作或学习方向有关吗？
  ② 是趋势级变化还是噪音？
  ③ 我看完能用在实际工作中吗？
  
  通过 3 问的 → 精读
  没通过的 → 标题扫过，收藏但不深入

第 3 层：深研究（每月 1-2 次，投入半天到一天）

  方式：
  - 读一篇 RFC 或技术规范
  - 读一个开源库的源码
  - 做一个技术 PoC
  - 写一篇学习笔记
  
  最近的深研究：
  - 精读了 MCP 协议规范
  - 读了 Zustand 源码
  - 做了 Vercel AI SDK 的 PoC

如何避免"信息焦虑"：

1. 接受"不可能全部跟上"
   → 前端生态太大了，没人能全部了解
   → 关键是在自己的方向上保持深度

2. 定义"关注圈"和"忽略圈"
   → 我的关注圈：React 生态 + AI 前端 + 全栈
   → 我的忽略圈：Angular、Flutter、游戏开发
   → 忽略圈的信息只要知道存在就行，不需要深入

3. 批量处理而非实时处理
   → 不开推送通知
   → 每天固定 15 分钟"刷信息"时间
   → 看到好文章收藏到 Raindrop.io，周末集中读

4. 以输出倒逼输入
   → 不是"什么都学"，而是"为了做 X，我需要学 Y"
   → 项目驱动 > 好奇心驱动 > 焦虑驱动

5. 定期清理
   → 每季度 Review 一次关注的信息源
   → 取关不再有价值的账号/频道
   → 退订不看的邮件列表

追问方向

你怎么向团队成员推荐好的信息源？
英文信息和中文信息的比例大概是多少？
你觉得 AI 时代信息获取方式会怎么变化？

AI 效能与工程师素养 ​

第一部分：AI 认知与使用程度 ​

Q1: 你日常开发中使用哪些 AI 工具？能具体说说它们分别在什么环节帮到你了？ ⭐ ​

面试官隐藏意图 ​

好答案 vs 差答案 ​

示例回答 ​

追问方向 ​

Q2: 用 AI 辅助编码时，你是如何 Review AI 生成的代码的？有没有踩过坑？ ⭐⭐ ​

面试官隐藏意图 ​

好答案 vs 差答案 ​

示例回答 ​

追问方向 ​

Q3: Copilot / Cursor / Trae 这类 AI IDE 的核心差异？你选择工具的标准是什么？ ⭐⭐ ​

面试官隐藏意图 ​

好答案 vs 差答案 ​

示例回答 ​

追问方向 ​

Q4: 你用 AI 做过最复杂的一件事是什么？效果如何？有什么局限性？ ⭐⭐ ​

面试官隐藏意图 ​

好答案 vs 差答案 ​

示例回答 ​

追问方向 ​

Q5: AI 写代码的"幻觉"问题你怎么看？实际工作中如何避免被误导？ ⭐⭐ ​

面试官隐藏意图 ​

好答案 vs 差答案 ​

示例回答 ​

追问方向 ​

Q6: 如何用 AI 提升 Code Review 效率？你会把什么类型的 Review 交给 AI，什么不会？ ⭐⭐ ​

面试官隐藏意图 ​

好答案 vs 差答案 ​

示例回答 ​

追问方向 ​

Q7: 你有没有用 AI 辅助做过技术方案设计或架构决策？效果怎么样？ ⭐⭐⭐ ​

面试官隐藏意图 ​

好答案 vs 差答案 ​

示例回答 ​

追问方向 ​

Q8: Prompt Engineering 在日常开发中的应用：你是怎么写 Prompt 让 AI 生成更精准的代码的？ ⭐⭐ ​

面试官隐藏意图 ​

好答案 vs 差答案 ​

示例回答 ​

追问方向 ​

Q9: AI 会取代前端工程师吗？你认为未来 3 年前端工程师的核心竞争力是什么？ ⭐⭐⭐ ​

面试官隐藏意图 ​

好答案 vs 差答案 ​

示例回答 ​

追问方向 ​

Q10: 你团队中有推动 AI 工具落地的经验吗？遇到了什么阻力？怎么解决的？ ⭐⭐⭐ ​

面试官隐藏意图 ​

好答案 vs 差答案 ​

示例回答 ​

追问方向 ​

Q11: 如何评估 AI 工具对团队生产力的实际提升？有没有量化的方法？ ⭐⭐ ​

面试官隐藏意图 ​

好答案 vs 差答案 ​

示例回答 ​

追问方向 ​

Q12: 如果让你给团队制定一套 AI 辅助开发规范，你会怎么设计？ ⭐⭐⭐ ​

面试官隐藏意图 ​

好答案 vs 差答案 ​

示例回答 ​

追问方向 ​

Q13: AI 生成代码的安全隐患有哪些？如何建立团队的 AI 代码安全审查流程？ ⭐⭐⭐ ​

面试官隐藏意图 ​

好答案 vs 差答案 ​

示例回答 ​

追问方向 ​

Q14: 你怎么看 AI 对初级工程师成长的影响？如果你带团队，会如何引导新人使用 AI？ ⭐⭐ ​

面试官隐藏意图 ​

好答案 vs 差答案 ​

示例回答 ​

追问方向 ​

Q15: 不同类型的开发任务（新功能 / Bug 修复 / 重构 / 性能优化），AI 的适用程度分别怎样？ ⭐⭐ ​

面试官隐藏意图 ​

好答案 vs 差答案 ​

示例回答 ​

追问方向 ​

第二部分：好奇心、探索欲与工程师素养 ​

Q16: 最近半年你关注到的最有意思的前端技术/工具是什么？为什么觉得有意思？ ⭐ ​

面试官隐藏意图 ​

AI 效能与工程师素养

第一部分：AI 认知与使用程度

Q1: 你日常开发中使用哪些 AI 工具？能具体说说它们分别在什么环节帮到你了？ ⭐

面试官隐藏意图

好答案 vs 差答案

示例回答

追问方向

Q2: 用 AI 辅助编码时，你是如何 Review AI 生成的代码的？有没有踩过坑？ ⭐⭐

面试官隐藏意图

好答案 vs 差答案

示例回答

追问方向

Q3: Copilot / Cursor / Trae 这类 AI IDE 的核心差异？你选择工具的标准是什么？ ⭐⭐

面试官隐藏意图

好答案 vs 差答案

示例回答

追问方向

Q4: 你用 AI 做过最复杂的一件事是什么？效果如何？有什么局限性？ ⭐⭐

面试官隐藏意图

好答案 vs 差答案

示例回答

追问方向

Q5: AI 写代码的"幻觉"问题你怎么看？实际工作中如何避免被误导？ ⭐⭐

面试官隐藏意图

好答案 vs 差答案

示例回答

追问方向

Q6: 如何用 AI 提升 Code Review 效率？你会把什么类型的 Review 交给 AI，什么不会？ ⭐⭐

面试官隐藏意图

好答案 vs 差答案

示例回答

追问方向

Q7: 你有没有用 AI 辅助做过技术方案设计或架构决策？效果怎么样？ ⭐⭐⭐

面试官隐藏意图

好答案 vs 差答案

示例回答

追问方向

Q8: Prompt Engineering 在日常开发中的应用：你是怎么写 Prompt 让 AI 生成更精准的代码的？ ⭐⭐

面试官隐藏意图

好答案 vs 差答案

示例回答

追问方向

Q9: AI 会取代前端工程师吗？你认为未来 3 年前端工程师的核心竞争力是什么？ ⭐⭐⭐

面试官隐藏意图

好答案 vs 差答案

示例回答

追问方向

Q10: 你团队中有推动 AI 工具落地的经验吗？遇到了什么阻力？怎么解决的？ ⭐⭐⭐

面试官隐藏意图

好答案 vs 差答案

示例回答

追问方向

Q11: 如何评估 AI 工具对团队生产力的实际提升？有没有量化的方法？ ⭐⭐

面试官隐藏意图

好答案 vs 差答案

示例回答

追问方向

Q12: 如果让你给团队制定一套 AI 辅助开发规范，你会怎么设计？ ⭐⭐⭐

面试官隐藏意图

好答案 vs 差答案

示例回答

追问方向

Q13: AI 生成代码的安全隐患有哪些？如何建立团队的 AI 代码安全审查流程？ ⭐⭐⭐

面试官隐藏意图

好答案 vs 差答案

示例回答

追问方向

Q14: 你怎么看 AI 对初级工程师成长的影响？如果你带团队，会如何引导新人使用 AI？ ⭐⭐

面试官隐藏意图

好答案 vs 差答案

示例回答

追问方向

Q15: 不同类型的开发任务（新功能 / Bug 修复 / 重构 / 性能优化），AI 的适用程度分别怎样？ ⭐⭐

面试官隐藏意图

好答案 vs 差答案

示例回答

追问方向

第二部分：好奇心、探索欲与工程师素养

Q16: 最近半年你关注到的最有意思的前端技术/工具是什么？为什么觉得有意思？ ⭐

面试官隐藏意图