午间杂谈：别被那些新词唬住，AI编程助手的真相只有一个

本文探讨AI编程助手如何优化前端开发流程。作者指出，与其被AI工具的新概念困扰，不如聚焦两个核心：建立清晰的技术栈规则（Rules）和封装高频工作流（Skills）。通过配置.cursorrules文件明确项目规范，使用Commands快速生成CRUD页面，并合理接入设计稿、API文档等外部工具，可显著提升开发效率。关键在于让AI理解前端上下文，而非盲目追求功能全面。建议从封装常用组件开始，逐步构

木斯佳

573人浏览 · 2026-01-30 09:20:25

木斯佳 · 2026-01-30 09:20:25 发布

午间杂谈：别被那些新词唬住，AI编程助手的真相只有一个

在这里插入图片描述

最近跟几个前端老哥喝咖啡，聊到个挺有意思的事儿。

阿凯说：“以前带新人，最头疼的就是让他配Webpack，现在更头疼——让他学明白AI编程那一堆新词儿，什么Skills、MCP、Hooks……比我当年学Vue响应式原理还头大。”

我笑了：“那你咋办的？”

阿凯喝了口美式：“我告诉他，你就记住两件事儿——这玩意儿得懂你的技术栈，还得能帮你写组件。别的都是扯淡。”

这话在理。

一、为什么我们烦透了一遍遍交代“前端那些事儿”？

在这里插入图片描述
你想过没有，每次用Claude Code写前端代码，最耗时间的是什么？

不是等它生成JSX，而是你得像个产品经理一样，反复交代那些它本该知道的技术选型：

“这是Next.js 14项目，用App Router，别给我整Pages Router那套……”
“组件库用Ant Design 5.x，主题色是#1890ff，别用默认的……”
“这个老组件用class写的，别动，重构计划排到下个季度……”

这不就是当年带实习生时的感觉吗？同样的交代，每天重复八遍。

后来我学乖了。在每个前端项目根目录扔了个 .cursorrules 文件，里面写着：

// 前端技术栈
框架: Next.js 14 (App Router模式)
UI库: Ant Design 5.x + Tailwind CSS
状态管理: Zustand (禁止用Redux)
HTTP客户端: Axios (统一拦截器已配置)

// 代码规范
组件: React函数组件 + TypeScript严格模式
样式: Tailwind优先，特殊场景用CSS Module
命名: 组件PascalCase，函数camelCase，常量UPPER_CASE

// 特殊约定
1. 所有API请求必须走封装的request.ts
2. 页面组件必须用async，服务端组件优先
3. 客户端交互组件必须加'use client'指令

// 历史包袱警告
- /src/components/legacy/ 下的Class组件不要动
- /pages/api/ 是旧的，新接口写在/app/api/
- 那个叫'临时样式'的CSS文件千万别引用

这下世界清净了。Claude Code每次开工前先看这“前端开发手册”，生成的组件八九不离十。

这就叫Rules——不是冰冷的规则，是你和Claude Code之间的技术默契。 就像和资深前端搭档，一说“按钮组件”，他就知道要加loading态和防抖。

二、把前端重复劳动变成“一句暗号”

有些前端活儿，干多了鼠标手都犯了。
在这里插入图片描述

比如每次新建一个CRUD页面，我都得：

建页面文件 app/users/page.tsx
建接口定义 lib/api/users.ts
建组件 components/users/UserTable.tsx
建表单 components/users/UserForm.tsx
配置路由，加权限校验……

一天搞几遍，Ctrl+C/V按到手指疼。

现在？我就敲 /next-crud
在这里插入图片描述

Claude Code听到暗号，自动生成全套：

Next.js 14的App Router页面
TypeScript接口定义
Ant Design Pro Table组件
Modal表单带验证
甚至把React Query的hooks都配好了

这玩意儿官方叫Commands，我叫它“前端脚手架指令”。

更妙的是，我把团队常用的指令都存到一个文件里，新人来了直接复制一份。以前要培训半天的项目规范，现在新人用 /component 生成的组件风格完全统一。

省时间倒是其次，关键是技术统一。 以前团队里有人用MUI有人用Antd，现在清一色Ant Design 5 + Tailwind，维护成本直接减半。

三、让Claude Code走出“代码编辑器”

但之前的Claude Code有个毛病——它像个纯前端，只看得懂React代码，对外面的世界一无所知。

它不知道：

Figma上那个设计稿最新版本是什么
后端OpenAPI文档里User接口返回字段变了没
Sentry上今天报了多少个前端错误
腾讯云COS的图片上传地址是什么

这不行啊，得让它“全栈一点”。
在这里插入图片描述

于是我给Claude Code接上了MCP（前端版工具箱）。现在它能：

读取Figma API，把设计稿直接转成React组件代码
同步Swagger文档，自动更新TypeScript类型定义
查询Sentry错误：“把今天Top 10的前端错误按PV排序”
调用云服务：“把这个base64图片上传到COS，返回CDN地址”

Claude Code终于从“代码生成器”变成了“前端开发伙伴”。

但这里有个坑：别贪多。我有次一口气给Claude Code接了Figma、Jira、Sentry、监控平台……结果让它写个简单Button，它非要去分析Figma设计系统规范，还建议我“根据用户点击热力图，这个按钮应该放大10%”……

大哥，我就要个antd的Button组件啊。

四、“前端专项模式”才是王道

后来我想明白了，不能要求Claude Code既写组件又搞性能优化。

于是我开始给它“切模式”：

写业务组件时，我切到“业务模式”。这个模式的Claude Code眼里只有产品需求、交互逻辑、数据流，它不会纠结该用useMemo还是useCallback。
性能优化时，我切到“性能模式”。这个模式只关心Bundle大小、渲染次数、内存泄漏，它手里拿着Chrome DevTools，建议都是“这个组件该用React.memo”、“这个依赖数组该精简”。
写工具函数时，我切到“工具库模式”。这个模式输出纯净的utility函数，无副作用、类型完备、测试友好。
处理样式时，我切到“Tailwind模式”。这个模式精通各种响应式写法，知道什么时候该用md:，什么时候该用dark:。

限制它的视野，反而让它更专业。

就像你不会让UI设计师去配Babel插件，对吧？

五、最后的保险：给前端AI上“代码规范”

但说实在的，Claude Code再聪明，写TypeScript也有抽风的时候。

它心情好时，类型推断完美；心情不好时，给你来个any大法，或者把useState的泛型写错。

前端工程容不得类型体操失误，需要的是100%确定。

所以我给关键流程加了Hooks（前端专用钩子），这是代码提交前的“ESLint加强版”：

提交前端代码前：
  - 必须通过TypeScript严格检查（noImplicitAny: true）
  - 必须通过ESLint + Prettier（团队规范）
  - Bundle分析：新增依赖必须小于10kb
  - 必须检查是否有console.log残留
  
生产构建前：
  - 必须跑完Vitest单元测试（覆盖率>80%）
  - 必须检查未使用的import
  - 必须验证所有图片有alt属性
  - 必须人工确认（@UI设计师看效果）

这些钩子不商量、不妥协。Claude Code生成得再快，ESLint不过，代码就提交不了。

六、说白了，前端AI就两件事儿

在这里插入图片描述

回顾这一路，概念越来越多，但本质没变。

你只需要记住两个东西：

Rules（你的前端技术栈说明书）
- 精简、明确、常更新
- 发现Claude Code用了已废弃的API，就去改Rules
- 这是你和AI磨合的过程，像和UI对设计稿，得来回几次
Skills（你的前端工具箱）
- 把高频工作流封装起来：组件生成、页面模板、工具函数
- 按需取用，写页面时不需要图标生成Skill
- 好的Skill是越用越顺手的，不好用的就重构

七、今天就能开始的前端实操建议

从最烦的一个组件开始
打开你最近的项目，想想哪个组件写起来最模板化。是Table列表页？是Form表单？还是Modal弹窗？先把这个做成Claude Code Command。
写一份“前端技术栈说明书”
花10分钟，写个最简单的.cursorrules。不用全，就三条：用什么框架、什么UI库、代码规范是什么。看看Claude Code生成的组件会不会更符合预期。
接一个最有用的前端工具
别贪多，就一个。团队用Figma？让Claude Code能读设计稿。用Sentry？让Claude Code能看错误日志。慢慢来。
设一条前端底线
在你最常出错的地方加个Hook。比如我总忘记写TS类型，就在提交前强制检查类型覆盖率。