AI 辅助前端开发工作流
前端研发中从需求分析到生成、review、重构和验证的 AI 协作工作流。
[!info] related notes
AI 辅助前端开发工作流
AI 在前端研发里最有价值的地方，不是替代工程师做判断，而是把一部分标准化、重复性高、可验证的工作加速完成。
一句话定义
AI 辅助前端开发工作流，核心是把需求分析、代码生成、代码检查、重构和验证串成闭环，让 AI 提效而不是失控。
一个常见的闭环流程
需求分析
- 让 AI 帮忙拆解需求边界
- 列出风险点、待确认项和技术方案草稿
编码生成
- 生成页面骨架、类型定义、重复逻辑和测试样例
- 优先交给 AI 处理规则明确的部分
Review 与检查
- 检查命名、重复逻辑、空值风险、类型完整性
- 检查是否符合项目规范和目录结构
重构与抽象
- 拆大组件
- 抽 hooks
- 统一风格
- 抽公共能力
验证闭环
- lint
- test
- 本地运行
- 人工 review
如果任务本身适合被切成稳定行为，进一步把 test 这一步前移成 AI 编码时代的 TDD 会更稳：先定义 failing test，再让 AI 只写最小实现，而不是先生成一大段代码再补验收。
面试里怎么讲“如何准备 AI 编码上下文”
这类题不能只回答“我会把需求发给 AI”，更稳的答法是把上下文拆成几层：
- 目标是什么
- 边界条件是什么
- 项目约束是什么
- 输出格式是什么
- 我怎么验证它
例如我会给 AI 明确这些信息：
- 当前要改哪个模块
- 相关文件路径和已有代码风格
- 使用的技术栈、状态管理、请求层、组件库
- 不能动哪些边界
- 我希望它输出“分析 / 修改方案 / 代码 / 测试点”
一个更实战的上下文模板
目标：给搜索页增加防抖搜索和空态展示
范围：只改 SearchPage、SearchInput、useSearch
技术栈：React + TypeScript + Zustand
约束：保留现有接口，不改视觉风格，不新增依赖
输出：先分析，再给 patch，最后列测试点面试里怎么讲“10 分钟内用 AI 还原网页”
这类题通常不是考你会不会点 Cursor，而是考你有没有稳定流程。
更稳的回答是：
- 先快速拆视觉结构和模块边界
- 把页面分成布局、组件、数据、交互四层
- 让 AI 先出骨架，不要求一次到位
- 自己做人类 review，重点盯结构、间距、语义和可复用性
- 最后再补交互、状态和细节
一个更工程化的表达
- 第一轮让 AI 生成静态结构和基础样式
- 第二轮补响应式和状态逻辑
- 第三轮做语义化、无障碍和代码整理
这样比“直接让 AI 还原整个页面”更稳。
AI 更适合做什么
- 样板代码
- 重复逻辑
- 初步 review
- 受约束的重构
AI 不适合直接替代什么
- 核心业务边界判断
- 架构决策
- 复杂上下文理解
- 最终责任承担
面试官真正想听什么
- 你是不是有稳定的 AI 协作流程
- 你会不会给足上下文和约束
- 你有没有验证闭环
- 你是否清楚 AI 擅长什么、不擅长什么
常见误区
- 把 AI 当成“自动写完全部业务”的工具
- 没有验证闭环就直接接受输出
- 只会聊天式提问，不会给上下文和约束
最短记忆方式
先约束，再生成，再验证，最后由工程师负责。
面试要点
来自 cursor-vs-traditional-ide-interview-question 的面试视角整理。
补充来自 how-to-understand-ai-frontend-engineer-role-interview-question：
补充来自 what-tasks-is-ai-good-at-in-frontend-interview-question：
一句话回答
AI 更适合页面骨架生成、类型补全、重复逻辑实现、测试样例生成、初步 code review 和受约束的重构；而复杂业务边界、架构设计和最终责任仍然要由开发者主导。
最稳的回答主线
- 先强调规则明确、重复性高、可验证
- 再举几个具体前端任务例子
- 最后补边界：关键判断还是工程师负责
可以举的典型任务
- 页面骨架和表单模板生成
- 类型补全和接口映射
- 重复逻辑抽取和简单重构
- 测试样例、文档、注释草稿
- 第一轮 code review 和风险扫描
面试里最好补的一句
我会优先把标准化任务交给 AI，把需要上下文判断和业务权衡的部分留给人来做。
常见误区
- 只说“写页面很快”，没有提可验证性
- 把架构设计和复杂业务判断也交给 AI
- 忽略后续 review、测试和收敛成本
可能追问
- 哪些任务你明确不交给 AI
- AI 在代码 review 里最有价值的地方是什么
- 你怎么判断一个任务适不适合交给 AI
最短记忆方式
标准化任务交给 AI，关键判断留给工程师。
一句话回答
我把 AI 当成加速器而不是替代判断。它适合做方案对比、初稿生成、边界条件补充和代码阅读，但涉及安全、鉴权、数据一致性的代码必须回到项目上下文验证，不能直接照搬。
使用场景
信息处理加速
- 方案对比：让 AI 列出几种可行方案的优劣，再自己做最终判断
- 文档整理：快速理解不熟悉的 API 或库的使用方式
- 代码阅读：让 AI 帮忙解释复杂代码或陌生代码库的结构
开发辅助
- 测试样例：生成边界条件测试、类型测试
- 类型体操：复杂工具类型、条件类型的推导思路
- 重构建议：识别代码坏味道、提出重构方向
学习加速
- 建立上下文：在不熟悉的模块里先用 AI 快速建立全局认知
- 概念解释：用类比和例子理解抽象概念
- 对比分析：不同技术选型的对比维度
边界控制
三件必须注意的事
- 生成内容必须回到项目上下文验证：AI 不知道你的业务约束和历史包袱
- 涉及安全、鉴权、数据一致性的代码不能直接照搬：这些地方的错误成本太高
- AI 适合加速信息处理，不适合替代架构判断：架构决策需要理解业务全貌
企业场景的额外要求
如果面亿格云这类企业安全产品公司，要补一句：
企业产品里使用 AI，更重要的是可验证、可审计和边界清晰，而不是”能生成就行”。生成代码必须经过 code review、安全扫描和测试覆盖。
面试回答主线
如果问”你平时怎么用 AI”
我主要在三个环节用：一是做方案调研时让 AI 帮我快速对比不同方案的优劣；二是写代码时让它补测试样例和边界条件；三是读代码时用它快速建立上下文。但我会特别注意，涉及安全和数据一致性的代码必须自己验证，不会直接照搬。
如果问”AI 会不会让前端门槛变低”
会降低入门门槛，但不会降低高质量交付门槛。因为页面代码更容易被生成，但真正拉开差距的是需求抽象能力、架构与边界设计、性能与稳定性、安全与协作，以及对业务问题的理解。AI 会替代机械劳动，但不会替代工程判断。
最短记忆方式
AI 辅助 = 加速信息处理 + 辅助开发 + 学习上下文 + 严格验证 + 边界清晰
一句话回答
AI 前端工程师既要有扎实的前端工程能力，也要会把 AI 工具接入研发流程提升团队效率，同时还能理解 AI 产品在流式输出、稳定性、交互不确定性上的特殊要求。
最稳的回答主线
- 第一层是正常前端基本功
- 第二层是 AI 工具驱动研发能力
- 第三层是 AI 产品场景下的工程落地能力
可以怎么展开
- 普通前端更关注页面、状态、性能和工程规范
- AI 前端还要理解流式输出、不确定性体验、长任务反馈和异常恢复
- 如果岗位偏提效，还要会把 AI 接进开发流程，沉淀成可复用工作流和工程资产
面试里最好补的一句
我会把这个岗位理解成“前端基本功 + AI 工具工程化 + AI 产品交互落地”三层能力的组合，而不是只会调接口或者只会用 AI 写代码。
常见误区
- 把 AI 前端理解成只会接一个聊天接口
- 把 AI 前端理解成只会使用 Cursor 之类工具
- 忽略稳定性、监控、性能和结果不确定性
可能追问
- 你觉得 AI 前端和普通前端最大的差别是什么
- 如果让你做一个 AI 对话产品，你最关注哪些前端问题
- 你怎么体现自己不只是会用工具，而是真的有工程能力
最短记忆方式
不是只会 React，也不是只会问 AI，而是能把前端能力和 AI 工程化结合起来。
一句话回答
传统 IDE 主要提供代码编辑、补全和调试能力；Cursor 这类 AI IDE 在此基础上增加了代码理解、自然语言交互、跨文件修改和任务级辅助能力，更像高级协作开发助手。
最稳的回答主线
- 传统 IDE 偏编辑器和静态工具支持
- AI IDE 更偏任务级辅助和代码理解
- 但最终架构判断和质量责任仍然在开发者手里
可以怎么展开
- 传统 IDE 强在编辑、补全、调试、跳转和插件生态
- AI IDE 强在自然语言协作、跨文件理解、批量修改和任务拆解
- 真正有价值的点不是“能写代码”，而是能减少在阅读、搬运和低层重复劳动上的时间
面试里最好补的一句
我会把 Cursor 看成是 IDE 上面叠了一层任务协作能力，而不是简单的智能补全升级版。
常见误区
- 只说补全更强，没有说到任务级协作
- 把 AI IDE 当成可以替代工程判断的自动开发工具
- 忽略代码安全、上下文理解偏差和验证闭环
可能追问
- 你平时会怎么把 AI IDE 接进开发流程
- 什么场景你会主动不用 AI IDE
- AI IDE 和命令行 Agent、代码审查工具有什么区别
最短记忆方式
传统 IDE 帮你写代码，AI IDE 开始帮你做开发任务。