夜雨聆风前言
我之前写过两篇 CC 开发心得，后端篇和前端篇。后端的套路相对固定——CRUD、数据库、API 接口，CC 搞定这些已经很成熟了。前端是另一个故事。
最近看到一个观点说得挺好：AI 10 分钟改完的代码，你可能要花 2 小时收拾。
样式不统一，组件边界乱，useEffect 乱飞，类型看着能过，接进项目才发现一堆隐患。
这跟我的实际体验一致。AI 写前端最大的问题不是写不出来，是写得太顺手——页面能跑，但经不起推敲。
问题的根源不是 AI 能力不行，是你没有给它配一套工作流。
一、问题出在哪？
很多人用 AI 写前端，本质上还是一句话硬冲：
帮我做一个用户管理页面，支持搜索、新增、编辑、删除。AI 会很快给你一大段能跑的代码。页面有了，按钮有了，表格有了，弹窗也有了。
但真实项目不只看"能不能跑"，还要看：页面像不像专业产品、组件能不能复用、主题统不统一、状态边界清不清楚、性能有没有隐患、类型可不可靠、移动端会不会炸、上线前有没有人审。
如果这些事都靠一个 Prompt 解决，AI 写得快，你改得也久。
我在前端开发心得里提过，前端对 AI 来说挑战更大，关键在于做好约束。而这个约束，不应该每次都靠你的 Prompt 来补——应该拆成一组专职的 Skill，按流程调用。
二、我的前端 Skill 工作台
我把前端开发常用的 Skill 分成三层：
第一层 - 做页面： frontend-design shadcn-ui tailwind-theme-builder第二层 - 控结构： vercel-composition-patterns vercel-react-best-practices第三层 - 做审查： typescript-react-reviewer web-design-guidelines openai-docs这 8 个 Skill 不要一次全开，按任务调用：
做新页面： frontend-design->shadcn-ui->tailwind-theme-builder重构老组件： vercel-composition-patterns->typescript-react-reviewer上线前检查： vercel-react-best-practices->web-design-guidelines->typescript-react-reviewer接 AI 能力： openai-docs->vercel-react-best-practices->typescript-react-reviewer
三、第一层：先把页面做稳
我在前端心得里选的技术栈是 Tailwind CSS + shadcn/ui，原因很简单：不会特别好看，但绝对不会丑，组件一致性强，对 AI 友好。
这一层有三个 Skill 保驾护航。
3.1 frontend-design — 页面结构和视觉层级
做页面之前不要急着写业务逻辑。先用这个 Skill 把页面结构、视觉层级和交互状态定下来。
请使用 frontend-design，帮我设计一个用户管理页面。要求信息密度高，有清晰的筛选区、列表区、详情区和操作区。它解决的是：页面第一眼看上去像不像专业产品。
3.2 shadcn-ui — 组件体系
我在前端心得里说过，shadcn/ui 提供了一套设计规范，不会出现"每个页面长得不一样"的问题。
这个 Skill 负责把表格、弹窗、菜单、Tabs、Toast 这些基础组件接进项目：
请使用 shadcn-ui，实现一个带筛选、批量操作、分页和行内菜单的数据表格。要求复用已有组件风格，不要新增不必要的 UI 抽象。它解决的是：组件体系稳不稳。
3.3 tailwind-theme-builder — 主题和样式
Tailwind 的原子化 CSS 对 AI 非常友好，但如果 class 越写越散，就会变成长期债务。
这个 Skill 帮你先把主题定好：
请使用 tailwind-theme-builder，设置 Tailwind v4 和 shadcn/ui 主题。要求支持亮色/暗色模式，颜色通过 CSS variables 管理。它解决的是：样式以后还好不好维护。
四、第二层：把代码结构收住
AI 写前端最容易犯的错误，是组件越写越胖，props 越加越多，状态越传越深。
你一定见过这种组件：
<UserTable showSearch showFilter showBatchAction enableExport enableInlineEdit showAdvancedMode isAdmin isLoading isCompact/>能跑，但以后每次改它都很痛苦。
4.1 vercel-composition-patterns — 组件拆分
请使用 vercel-composition-patterns，重构这个 UserTable 组件。目标是减少 boolean props，用组合式 API 拆出 Toolbar、Filter、TableBody、Pagination 和 RowActions。它解决的是：组件以后还能不能继续改。
4.2 vercel-react-best-practices — 性能和边界
请使用 vercel-react-best-practices，审查这个页面。重点检查组件边界、数据获取、useEffect 使用、bundle 体积和渲染性能。它解决的是：页面能跑，但会不会越来越慢。
五、第三层：让 AI 自己过审
我在前端心得里提到过，E2E 验证是最后一步——Playwright Skill 自动化测试，加上视觉走查。
这一层是同样的思路：AI 写完代码，第一件事不是合并，是让另一个 Skill 审一遍。
5.1 typescript-react-reviewer — 代码审查
请使用 typescript-react-reviewer，帮我 Review 这次改动。只看真实风险，不要泛泛夸奖。按严重程度列出问题，给出文件和修改建议。重点是那句"只看真实风险，不要泛泛夸奖"。你不需要 AI 给你情绪价值，你需要它帮你拦住真实问题。
5.2 web-design-guidelines — 体验检查
请使用 web-design-guidelines，审查页面的 UI、可访问性和移动端适配。重点看文字是否溢出、操作是否清晰、状态是否完整。它解决的是：用户会不会用着难受。
5.3 openai-docs — AI 功能接入
如果你的前端项目需要接 AI 能力（聊天界面、流式输出等），这个 Skill 帮你查最新的官方文档，避免用旧 SDK、旧参数、旧模型名。
请使用 openai-docs，基于最新官方文档，设计一个前端 AI 聊天功能的调用方案。要求支持流式输出、错误处理和前端状态管理。六、如果只配 3 个，先配这 3 个
不想一次折腾太多，先从这 3 个开始：
frontend-design — 把页面做像样 typescript-react-reviewer — 把代码审一遍 web-design-guidelines — 上线前检查体验
前端最常见的返工就三类：页面不好看、代码不稳、体验不完整。这 3 个 Skill 基本能挡住。
七、和我之前前端心得的关系
我在《CC 实战心得（二）：前端开发篇》里总结的流程是：
后端开发 → API 测试 → 前端开发 → UI 优化 → E2E 验证这套 Skill 工作台，其实是把这个流程里"前端开发"到"UI 优化"之间的空白填上了。
之前我的做法是：Orval 生成类型、Tailwind + shadcn/ui 做组件、Playwright 做 E2E。现在可以更进一步——每个环节都有专职 Skill 把关，从设计到结构到审查，全链路覆盖。
写在最后
用 AI 做前端，真正的分水岭不是会不会写 Prompt。
Prompt 是一句话，Skill 是岗位，工作流是团队。
我的前端开发心得总结成一句话：
把设计交给 frontend-design，把组件交给 shadcn-ui，把审查交给 reviewer，把验证交给 Playwright。剩下的，交给 CC。
有问题欢迎评论区交流 👇
作者简介：河南爱编程网络科技有限公司负责人，专注 AI 驱动的软件开发服务。官网：devlovecode.com[1]
引用链接
[1]devlovecode.com: https://devlovecode.com
