1. 从“写前端像在搬砖”到“找回手感”的转折点前端开发这件事做了几年之后很容易陷入一种疲惫期。不是不会写而是写起来太琐碎一个响应式布局要调半天断点一个表单校验要处理十几种边界情况一个动画效果要在脑子里反复推演缓动曲线。很多时候不是技术难度大而是重复劳动多、心智负担重。我身边不少做了五六年前端的朋友都有类似感受——代码越写越熟练但那种“做东西很爽”的感觉反而越来越淡。最近一段时间我重新用大模型辅助前端开发意外地找回了当年刚入行时的那种手感。具体来说是那种“脑子里想一个界面很快就能看到它在浏览器里跑起来”的流畅感。这篇文章不聊虚的就聊聊我是怎么把大模型真正嵌进前端工作流里的哪些环节它确实能帮上大忙哪些环节它反而会添乱以及我踩过的那些坑。先说结论大模型在前端领域最擅长的不是“从零生成一个完整项目”而是在局部高频迭代和样式细节调整这两个场景里表现突出。如果你指望它一句话生成一个能上线的后台系统大概率会失望但如果你把它当成一个随时待命、不知疲倦的“样式助手”和“逻辑补全器”它会极大提升你的开发节奏。这篇文章适合几类人看一是前端老手想看看怎么把大模型塞进现有工作流二是刚入门前端的新人想知道哪些环节可以借助工具快速上手三是做全栈但前端偏弱的开发者想找个靠谱的“前端搭子”。我会从实际场景出发把每个环节的操作逻辑、参数取舍、避坑经验都讲清楚。2. 为什么大模型写前端和写后端是两回事2.1 前端代码的“视觉可验证性”决定了协作方式后端代码写完你得跑测试、看日志、查数据库才能验证对不对。前端代码写完刷新一下浏览器对不对一眼就能看出来。这个差异直接决定了大模型在前端场景里的使用方式——你可以用“看效果”来快速判断它生成的东西能不能用而不需要逐行读代码。我自己的习惯是让大模型生成一段样式代码后直接贴进浏览器看效果。如果视觉上没问题再回头读代码看有没有冗余或者不规范的地方。这个顺序很重要因为前端代码的“正确”很大程度上是视觉正确而不是逻辑正确。一个flex布局写成grid也能实现只要效果对很多时候没必要纠结。但这也带来一个问题大模型很容易生成“看起来对但实际有隐患”的代码。比如它给你写了一个绝对定位的弹窗视觉上没问题但滚动穿透没处理、层级上下文没考虑、移动端适配没做。这些在静态截图里看不出来一上真机就露馅。所以我的经验是视觉验证之后必须再过一遍交互验证尤其是涉及滚动、点击、输入的场景。2.2 前端技术栈的碎片化让大模型更容易“串味”后端生态相对收敛一个语言配一套框架版本差异虽然有但不算离谱。前端不一样光是构建工具就有好几代样式方案从预处理器到原子化 CSS 再到 CSS-in-JS状态管理从 Redux 到 Zustand 到 Signals路由方案更是五花八门。大模型在训练数据里见过所有这些组合但它不一定知道你当前项目用的是哪一套。我遇到过好几次这种情况项目里用的是原子化 CSS 方案结果大模型给我生成了一堆传统类名加嵌套选择器项目里状态管理用的是轻量方案它给我整了一套 Redux 的 action 和 reducer。代码本身没错但和项目风格完全不搭改起来比自己写还费劲。解决办法其实很简单在对话开头把技术栈说清楚最好把关键依赖的版本号也带上。比如“这是一个使用 Vite 构建、样式用原子化方案、状态用轻量库、路由用文件路由的 React 项目”一句话就能把大模型的输出范围框住。如果项目有自定义的目录约定或者组件命名规范也一并告诉它。这个前置说明花不了一分钟但能省掉后面大量的返工。2.3 大模型对“设计意图”的理解远弱于对“代码模式”的掌握这是我在实际使用中感受最深的一点。你让大模型写一个“卡片列表”它能给你写出结构完整、样式规范的卡片。但你说“我想要那种很轻盈、有呼吸感、鼠标移上去有微妙反馈的卡片”它大概率会给你加一堆阴影和过渡效果很重完全不是你要的“轻盈”。原因在于大模型擅长的是代码模式的复现而不是设计意图的翻译。“轻盈”“呼吸感”“微妙”这些词在代码层面没有直接对应它只能靠猜。猜对了是运气猜错了是常态。我的应对策略是把设计意图拆解成具体的视觉参数。不说“轻盈”说“卡片之间间距 24px圆角 12px阴影用极低透明度的黑色模糊半径不超过 8px悬停时阴影扩散范围增加 2px 但透明度不变”。这些参数大模型能精确执行效果也基本符合预期。说白了你得先自己把设计想清楚大模型才能帮你落地。它是个执行者不是决策者。3. 我实际用下来最顺手的几个前端场景3.1 样式微调从“调半天”到“说一句”前端开发里最耗时的往往不是写逻辑而是调样式。一个按钮的间距、一个卡片的圆角、一个弹窗的动画时长这些细节改起来琐碎但必须做。以前我的做法是打开开发者工具一点点试数值试到顺眼为止。现在我的做法是直接告诉大模型“这个按钮的左右内边距改成 20px上下改成 12px圆角改成 8px悬停背景色加深 5%”它直接给我改好的代码。这个场景之所以顺手是因为样式调整的需求非常明确没有歧义。你知道自己要什么大模型只需要执行。而且样式代码的验证成本极低贴进去看一眼就知道对不对。我统计过纯样式调整类的工作用大模型辅助大概能省掉一半以上的时间而且改出来的代码往往比我手动调的更规范因为它不会像我一样偶尔漏掉某个状态的样式。但这里有个细节要注意大模型改样式时容易“过度设计”。你让它改一个按钮的间距它可能顺手把字体大小、字重、颜色都给你调了。所以我的习惯是明确告诉它“只改我提到的属性其他不要动”。如果它改完还是动了别的我会直接指出“你改了不该改的地方请只保留我要求的修改”。多轮对话里保持这种约束输出会越来越精准。3.2 组件逻辑补全把“我知道要写但懒得写”的部分交出去前端组件里有很多逻辑是“我知道怎么写但写起来很烦”的。比如一个下拉选择组件要处理键盘上下键选择、回车确认、ESC 关闭、点击外部关闭、滚动到可视区域。这些逻辑不复杂但写全了得几十行而且容易漏掉某个边界情况。这种场景特别适合交给大模型。我的做法是先把组件的结构和样式写好然后把交互需求列出来让大模型补全逻辑部分。它生成的代码我一般会通读一遍重点看边界处理是否完整。实测下来它在处理这类“有明确规则可循”的交互逻辑时表现相当稳定键盘导航、焦点管理、防抖节流这些常见模式基本不会出错。不过有一个坑我踩过好几次大模型生成的逻辑代码有时会依赖它自己引入的第三方库。比如它给你写了一个滚动监听然后 import 了一个你没装的工具库。代码本身没问题但项目里多了一个依赖构建体积就上去了。所以每次它生成带 import 的代码我都会检查一下引入了什么不需要的依赖让它用原生 API 重写。3.3 响应式适配断点逻辑的快速生成响应式布局是前端里比较烦人的一块因为要同时考虑多个断点下的表现。以前我写响应式得在脑子里模拟不同宽度下的布局变化然后一个个断点写媒体查询。现在我会直接告诉大模型“这个区域在移动端单列、平板双列、桌面三列移动端隐藏侧边栏平板侧边栏收起为图标桌面展开”它能把媒体查询和对应的样式都生成好。这个场景的提效非常明显因为断点逻辑是高度模式化的大模型见过大量类似代码生成质量很稳定。而且响应式代码的验证也简单浏览器拉宽拉窄看一眼就知道对不对。但要注意一点大模型默认生成的断点值不一定符合你的项目规范。有的项目用 768/1024/1280有的用 640/960/1200。如果你不指定它会随机选一套。所以最好在对话开头就把项目的断点规范告诉它或者让它用你项目里已有的断点变量。这个细节不注意的话生成出来的代码和项目其他部分会对不齐。3.4 动画与过渡从“脑补缓动曲线”到“直接看效果”动画这块是我觉得大模型帮助最大的地方之一。以前写动画我得在脑子里推演缓动曲线或者去翻 cubic-bezier 的参考表试来试去才能找到感觉。现在我会直接描述“这个元素从下方 20px 处淡入持续 300ms先快后慢”大模型能直接给我对应的 keyframes 和 transition 配置。更实用的是它还能帮我生成一些我平时不太写的复杂动画比如列表项的依次入场、数字的滚动变化、骨架屏的闪烁效果。这些动画自己写要查不少资料交给大模型基本一次成型。不过动画这块有个经验大模型生成的动画时长和缓动函数往往偏“重”。它默认给的 300ms、400ms 在它看来是“流畅”但实际用起来会觉得拖沓。我一般会把时长砍掉三分之一到一半缓动函数也换成更干脆的。这个没有固定标准得根据具体场景调但“大模型给的动画偏慢”这个规律我验证过很多次。4. 那些让我踩坑的环节和应对办法4.1 它写的代码“能跑但不对”隐蔽的逻辑漏洞大模型生成的前端代码有一个特点表面上看不出问题跑起来也不报错但实际行为不符合预期。我遇到过一个典型例子让大模型写一个搜索框的防抖逻辑它写出来的代码确实有防抖但防抖的触发时机搞反了——它是在输入时立即执行、停止输入后延迟取消而不是停止输入后延迟执行。这个 bug 在快速输入时看不出来只有慢慢输入再停顿才会暴露。这类问题的根源在于大模型对“时序”和“状态流转”的理解不如对“代码结构”的理解那么扎实。它知道防抖要用定时器但定时器什么时候清、什么时候设它可能会搞混。我的应对办法是对涉及时序、状态、异步的代码必须手动过一遍逻辑。具体来说就是拿一张纸把状态变化和时间线画出来看代码的执行顺序是否和预期一致。这个步骤花不了几分钟但能拦住大部分隐蔽 bug。另外如果项目里有测试环境把大模型生成的逻辑代码跑一遍单元测试也是个好办法虽然写测试本身也要时间但对于核心逻辑值得。4.2 样式冲突它不知道你项目里的全局样式前端项目里通常有一些全局样式比如重置样式、主题变量、通用类名。大模型在生成组件样式时默认是按“干净环境”来写的它不知道你项目里已经有一个.card类定义了内边距也不知道你的主题变量叫--color-primary还是--primary-color。结果就是它生成的样式和项目现有样式冲突或者用了不存在的变量页面渲染出来一片混乱。我遇到过最离谱的一次是它给一个组件写了position: fixed而项目里有个全局的transform导致 fixed 定位失效排查了半天才发现是全局样式的问题。解决办法有两个一是在对话里把项目的全局样式约定说清楚比如“项目使用 CSS 变量做主题主色变量名是--brand圆角变量是--radius-md不要用固定值”二是生成样式后先在小范围里试别直接全局替换确认没冲突再铺开。第二个办法虽然笨但最稳妥。4.3 依赖引入的“隐形膨胀”前面提过一嘴这里展开说。大模型生成代码时如果遇到它觉得“用库更方便”的场景会毫不犹豫地 import 一个第三方库。比如处理日期它想用日期库处理类名它想用类名工具库处理请求它想用请求库。这些库单个看都不大但积少成多构建体积就上去了。更麻烦的是有些库它引入的版本和你项目里已有的版本不一致导致打包时出现重复依赖或者版本冲突。我遇到过一次它引入了一个工具库的某个版本而项目里另一个依赖也引了这个库但版本不同最后打包出来两份代码体积直接翻倍。我的做法是在对话开头明确告诉它“不要引入新的第三方依赖用原生 API 实现”。如果某个功能确实用原生写很麻烦我会自己判断要不要加依赖而不是让它替我做决定。这个约束加上之后生成代码的“干净度”明显提升。4.4 它对你项目上下文的“失忆”大模型在多轮对话里对上下文的记忆是有限的。聊了十几轮之后它可能忘了你最开始说的技术栈或者忘了你之前定的命名规范。表现就是前面几轮生成的代码风格一致后面突然变了类名命名方式换了组件结构也不一样了。这个问题没有完美的解决办法但可以缓解。我的做法是每隔几轮就把关键约束重新说一遍比如“提醒一下项目用原子化 CSS组件用函数式写法状态用轻量库”。另外如果某个组件的代码比较长我会把已经确定的部分固定下来只让它在固定部分的基础上改而不是每次重新生成整个组件。这样即使它“失忆”影响范围也有限。5. 把大模型嵌进工作流的具体操作节奏5.1 先定结构再填细节别让它从零开始我试过直接让大模型“写一个用户列表页面”结果它给了一个能跑但结构很随意的版本组件拆分不合理、状态放错位置、样式和逻辑混在一起。后来我改了策略先自己把组件结构和数据流定好再让大模型填具体实现。具体操作是我先写一个骨架把组件层级、props 接口、状态定义都列出来然后让大模型填充每个组件的内部实现。这样它只需要关注局部逻辑不需要做架构决策生成质量高很多。而且因为结构是我定的后续维护和扩展也符合我的习惯。这个节奏的关键在于架构决策必须由人来做大模型只负责执行。前端的架构决策包括组件怎么拆、状态放哪里、数据怎么流这些想清楚了剩下的都是体力活交给大模型正好。5.2 小步快跑一次只改一个点大模型一次能处理的上下文是有限的你给它的需求越多它越容易顾此失彼。我早期的错误做法是一次性把一堆修改需求丢给它结果它改了这个忘了那个或者改出了新的问题。现在的做法是一次只提一个明确的修改点改完验证验证通过再提下一个。比如先改布局确认没问题再改交互确认没问题最后改样式细节。虽然对话轮次多了但每轮的质量高返工少总体反而更快。这个节奏还有一个好处出问题的时候容易定位。如果一次改了很多地方页面出问题了你不知道是哪个改动导致的。一次改一个点问题范围就锁定了。5.3 验证顺序视觉、交互、边界、性能大模型生成的代码我有一套固定的验证顺序。第一步看视觉刷新页面看布局、颜色、间距对不对。第二步试交互点击、输入、滚动、悬停都试一遍看行为是否符合预期。第三步查边界空数据、超长文本、极端数值、快速操作这些情况都过一遍。第四步看性能打开性能面板看有没有不必要的重渲染或者布局抖动。这个顺序是从“最容易发现问题”到“最难发现问题”排列的。视觉问题一眼就能看到交互问题点几下就能发现边界问题需要刻意构造性能问题需要工具辅助。按这个顺序走大部分问题在前两步就能拦住不用走到后面。5.4 什么时候该放弃大模型自己写不是所有场景都适合用大模型。我总结了几种情况遇到这些我会直接自己写不浪费时间跟大模型来回涉及复杂状态机的逻辑比如多步骤表单、拖拽排序、撤销重做。这些逻辑的状态流转很复杂大模型容易写乱自己写反而更快。需要精确控制渲染性能的场景比如长列表虚拟滚动、高频动画。这些场景对渲染时机要求很高大模型生成的代码往往有性能隐患。和项目现有代码深度耦合的改动比如要改一个已经写了很久的复杂组件大模型不了解上下文改出来的东西可能破坏原有逻辑。涉及安全敏感的逻辑比如权限校验、输入过滤。这些逻辑必须自己写自己审不能交给大模型。判断标准很简单如果这个逻辑你自己写只要十分钟那就自己写如果自己写要半小时以上且逻辑比较模式化那就交给大模型。这个权衡在实际工作中很实用。6. 几个让我印象深刻的实际案例拆解6.1 一个弹窗组件的三轮迭代过程我最近做一个弹窗组件需求是支持多种尺寸、支持自定义内容、支持底部按钮配置、支持滚动锁定、支持 ESC 关闭、支持点击遮罩关闭。第一轮我让大模型直接生成它给了一个基础版本视觉上没问题但滚动锁定没做、ESC 关闭没做、遮罩点击关闭也没做。第二轮我把缺失的功能列出来让它补它补上了但滚动锁定的实现有问题——它用的是overflow: hidden在移动端会导致页面跳动。我指出这个问题后第三轮它改用了固定定位加偏移补偿的方案这次对了。这个案例让我意识到大模型的第一版通常只能覆盖主流程边界情况需要你主动提。它不会主动想到“移动端滚动锁定会导致页面跳动”这种细节因为这是经验性的知识不是代码模式。所以我的习惯是拿到第一版后自己先列一遍边界情况再让它逐个补。6.2 一个表单校验逻辑的排查过程有个表单需要校验手机号、邮箱、身份证三种格式我让大模型写校验函数。它写出来的代码看起来没问题正则表达式也像模像样。但实测发现身份证校验对某些合法号码返回了 false。我排查的过程是这样的先拿几个已知合法的身份证号测试确认确实有误判然后把正则拆开逐段测试发现是出生日期部分的校验逻辑有问题——它没有考虑闰年和月份天数。这个 bug 很隐蔽因为大部分身份证号能通过只有特定日期的会失败。修复方案是我自己重写了日期校验部分没有继续让大模型改因为它对日期逻辑的处理确实不够可靠。这个案例的教训是涉及日期、数值边界、编码规则的逻辑大模型生成的代码必须仔细验证不能因为它“看起来对”就放过。6.3 一次样式重构的提效记录有个老项目的样式很乱类名没有规范嵌套层级很深改一处经常影响另一处。我决定用大模型辅助重构。做法是先把一个模块的样式代码贴给它让它分析出样式之间的依赖关系然后按原子化思路重新组织。它给出的重构方案质量不错把重复的样式抽成了公共类嵌套层级也压平了。但有一个问题它把一些语义化的类名改成了纯功能性的类名比如.user-card-header改成了.flex-between-center。功能上没问题但可读性下降了后来接手的人可能看不懂这个类名对应什么业务含义。我的处理是保留它的重构思路但把类名改回语义化的。这个案例说明大模型在“代码质量”和“可维护性”之间的权衡上倾向于前者。它会让代码更“干净”但不一定更“好懂”。所以重构类的任务它的输出需要人工再过一遍命名和注释。7. 关于“找回手感”这件事的一些个人体会用大模型辅助前端开发这段时间我最大的感受是它把前端开发里“体力活”的部分接过去了让我能把精力放在真正需要思考的地方。以前写一个页面可能 70% 的时间花在调样式、补逻辑、处理边界上只有 30% 的时间在想架构和交互。现在这个比例反过来了我有更多时间思考“这个交互怎么设计更顺”“这个状态怎么组织更清晰”。但“手感”这个东西不是大模型直接给的而是它帮你省下时间之后你重新投入到设计思考里慢慢找回来的。以前被琐碎工作淹没的时候没精力想这些现在琐碎工作被接走了思考的空间就出来了。这大概就是标题里说的“找回当年的感觉”——不是写代码的速度变快了而是做东西的节奏变顺了。还有一个体会是大模型不会让你变懒反而会逼你更严谨。因为它生成的代码你需要验证验证的过程就是重新审视自己设计的过程。以前自己写代码写完就过了现在它生成的代码你得逐段看、逐段试反而对代码的理解更深了。这个“被迫严谨”的过程长期看是好事。最后说一个实际的小技巧把大模型当成一个“需要明确指令的初级开发者”来用。你不会跟一个初级开发者说“做个好看的页面”你会说“这个页面分三个区域顶部导航固定高度 64px左侧边栏宽度 240px 可折叠主内容区自适应移动端侧边栏隐藏”。用这种颗粒度跟大模型沟通它的输出质量会稳定很多。这个心态转变是我用下来觉得最关键的一点。