一天一个 vibe coding 小技巧，今天讲：前端骨架。
如果你用 AI 写出来的前端项目，每个页面都像一个独立产品，那大概率不是 AI 不会写页面，而是你一开始没有做好前端骨架。
很多人一拿到项目，就是让 AI 一股脑地横推页面。首页、详情页、登录页、后台页、弹窗、表单，全都让 AI 直接往前写。
如果项目只有一两个页面，问题可能还不明显。
但如果是十几个甚至几十个页面的复杂项目，这样做后面一定会乱。页面越多，风格越散，组件越重复，代码越难维护。
我自己每次拿到一个前端项目，第一步都不是让 AI 先写页面，而是先把前端骨架定下来。
它包括：整体设计风格、前端技术方案、UI 组件库、目录结构、模块边界、组件复用规则、样式系统，以及后面的实施计划。
这些东西先有标准，AI 后面才知道该按什么方式写。
一、先确定整体设计风格
前端骨架里的第一件事，是确定整体设计风格。
设计风格不是某一个页面好不好看，而是整个 UI 呈现出来的统一视觉语言。
比如产品是偏简洁、偏商务、偏科技、偏年轻、偏工具化，还是偏内容型。
再具体一点，常见风格有很多。
比如苹果系统里的玻璃拟态、液态玻璃、半透明模糊背景。
比如 Google 的 Material Design，层级清楚，组件规范完整。
比如后台管理系统常见的企业级管理台风格，信息密度高、表格多、操作效率优先。
比如 SaaS 产品常见的现代极简风格，卡片清楚，按钮克制，留白适中。
比如 AI 产品常见的科技感风格，深色背景、渐变、发光元素、动效更多。
比如内容社区常见的信息流风格，重点是阅读舒服、内容层级清楚。
这些风格最后都会落到具体细节上：颜色、字体、字号层级、行高、间距、圆角、卡片样式、按钮形态、页面布局和信息密度。
如果你不知道自己想要什么风格，可以找几个喜欢的网站，把链接发给 AI。
如果是 App，就找几张参考截图发给 AI。
让 AI 分析这些界面的视觉风格、布局方式、组件特点，以及这种风格适不适合你的项目。
注意，这不是让你抄 UI。
成熟产品的视觉节奏、留白方式、组件组织方式，可以学习。
参考是为了确定方向，不是直接复制。
风格一旦确定，后面的页面就要围绕同一套视觉语言来做。
二、再确定前端技术方案和 UI 组件库
设计风格确定之后，再确定前端技术方案和 UI 组件库。
这两个东西不要混在一起。
前端技术方案解决的是项目怎么组织、怎么运行。
比如页面怎么放，路由怎么写，目录怎么分，项目怎么启动，构建和部署怎么处理。
常见方案有 React、Vue、Angular、Next.js、Nuxt。
如果是小程序，也有微信小程序原生框架、Taro、uni-app 这类方案。
UI 组件库解决的是界面元素怎么统一。
比如按钮、输入框、弹窗、表格、菜单、卡片、提示信息这些东西怎么写。
常见组件库有 Ant Design、Element Plus、Naive UI、MUI、Mantine、Vant、NutUI。
还有一些特殊方案，比如 Radix UI 更偏无样式组件基础库，shadcn/ui 更偏组件源码方案，Tailwind UI 更偏模板型组件方案。
你不需要一下记住这些名字。
先理解一句话就行：前端框架管项目结构，UI 组件库管界面统一。
框架不一定自带 UI 组件库，UI 组件库也不一定是框架。有些完整方案会自带自己的组件体系和主题规则。
这里也要注意，不是说不用成熟框架、不用 UI 组件库，就一定做不好前端。
专业前端当然可以自己搭目录、自己封装组件、自己设计样式系统。
但如果你不懂技术，主要靠 AI 写前端，我强烈建议优先选成熟方案。
因为成熟框架通常有目录规范、开发规范和最佳实践。
成熟组件库也已经把按钮、表单、弹窗、提示、表格这些常用组件统一好了。
你不是不能从零写，而是没必要让 AI 在没有边界的情况下从零发明一套前端结构。
你可以直接告诉 AI：
这个项目必须遵守当前前端框架的官方规范，优先复用选定的 UI 组件库，不允许到处手写重复组件，也不允许绕开框架最佳实践。
这句话就是在给 AI 画边界。
三、把目录、模块和组件规则定下来
前端骨架真正要解决的，不是先做多少页面，而是后面的页面应该怎么写。
第一，目录边界要清楚。
页面放哪里，组件放哪里，请求接口放哪里，工具函数放哪里，样式文件放哪里，都要有规则。
第二，模块边界要清楚。
登录、用户、订单、内容、设置这些功能区域，不要全部混在一个地方。
模块清楚，AI 后面改某个功能时，才不会到处乱动。
第三，组件复用规则要清楚。
按钮、输入框、卡片、表格、弹窗、提示框、导航栏，这些东西会反复出现。
能用 UI 组件库，就优先用组件库。
组件库不够用，再基于组件库封装项目自己的业务组件。
这里有一个简单判断标准：只要 UI 相似度比较高，并且在项目里出现超过 2 次，就应该考虑封装成组件。
不要每个页面重新写一遍按钮、弹窗、表格。
你也可以把这条写进 agent 宪法里：
同类 UI 结构出现超过 2 次时，必须优先抽象为可复用组件，不允许复制粘贴重复实现。
这样 AI 后面写页面时，就会主动判断哪些东西应该复用，而不是到处重复写。
四、提前准备样式系统
前端骨架里，样式系统也要提前准备。
第一，设计 token。
这里的 token，不是 AI 的 token，而是设计变量。
比如颜色、字号、行高、间距、圆角、阴影、边框。
这些东西必须在写页面前定好。
否则 AI 今天写 16px，明天写 18px，后天又写 15px。
最后项目里到处都是重复 CSS，代码不干净，设计也不统一。
你要告诉 AI：
所有颜色、字号、间距、圆角、阴影，都必须从统一设计 token 里取，不允许到处硬编码样式。
第二，多语言规范。
如果项目未来可能支持中文、英文，前端文案就不要到处硬编码。
按钮文字、页面标题、提示信息、错误信息，都应该统一管理。
因为中文两个字能放下，英文可能变成一整句。
如果一开始不考虑，后面切语言时，很容易出现按钮撑爆、标题换行、布局错位。
第三，主题规则。
主题不是为了炫技，而是为了让颜色体系可控。
比如先确定一个默认主色调，再预留主题扩展方式。
主题色不能散落在每个页面里手写。
否则后面想换主色调，就要全项目到处改。
五、写进实施计划，再让 AI 搭骨架
前面这些确定之后，一定要落实到详细的实施计划里。
不要只是口头聊完，就直接让 AI 开始写代码。
实施计划里至少要写清楚：
整体设计风格是什么。
前端技术方案是什么。
UI 组件库用什么。
目录结构怎么组织。
模块边界怎么划分。
哪些组件先封装。
设计 token 怎么定义。
多语言和主题规则怎么预留。
第一阶段只做哪些内容。
验收标准是什么。
这些内容写清楚之后，你就可以让 AI 开始敲代码了。
但注意，这一步也仅仅是做骨架。
不要让 AI 一次性做完所有页面和功能。
这一轮目标只有一个：项目能跑起来，基础结构是对的。
比如项目能启动，首页能打开，路由结构清楚，目录规范正确，UI 组件库接入完成，设计 token 准备好，主题规则接入完成，常用组件有基础版本。
这就够了。
前端骨架阶段，重点不是做多少页面，而是让后面的页面都长在同一套规则上。
骨架跑通之后，先提交一次 Git。
然后再一个模块一个模块往里加功能。
六、最后
做前端，最怕的不是页面丑。
最怕的是没有统一规则。
如果你不懂技术，又没有提前定设计风格，AI 就容易把页面写得不像一个整体。
如果没有目录规范，AI 就容易乱建文件夹。
如果没有组件规范，AI 就容易到处手写按钮、弹窗、表格。
如果没有组件复用规则，AI 就容易复制一堆相似代码。
如果没有设计 token，AI 就容易到处硬编码样式。
所以让 AI 写前端之前，先搭骨架。
先定设计风格，再选前端技术方案和 UI 组件库，然后定目录、模块、组件复用、设计 token、多语言和主题规则。
接着把这些内容写进实施计划。
最后再让 AI 搭一个能跑起来的前端基础结构。
