企业官网建设流程全解析

1. 一个月AI写页面的真实体验：从兴奋到崩溃

最开始决定让AI帮我写页面，想法特别简单——重复性的列表页、表单页、详情页，样式大同小异，逻辑也差不多，与其自己一行行敲，不如把需求描述清楚让AI生成，我负责审阅和微调。头一个星期确实爽，一个中等复杂度的管理后台页面，从描述到能跑起来，快的时候二十分钟搞定，慢的也就一个小时。那段时间我甚至觉得，前端开发这个工种是不是要变天了。

但到了第二周，问题开始集中爆发。AI生成的页面单看每一个都没毛病，可一旦放到同一个项目里，问题就藏不住了。按钮的圆角一会儿是4px，一会儿是6px，输入框的高度有的32px有的36px，卡片阴影深浅不一，间距更是随心所欲——这个页面用16px，那个页面用20px，还有的用24px。你可能会说，这些细节让AI统一一下不就行了？问题是，当你面对三十多个已经生成的页面，每个页面都有自己的一套“风格”，统一的工作量比自己从头写还大。

更让人头疼的是交互逻辑的碎片化。同样是一个“删除确认”的弹窗，AI在A页面用了自己实现的一套Modal，在B页面用了另一套，在C页面干脆直接调用了浏览器原生的confirm。分页组件的逻辑也是各写各的，有的用页码，有的用“加载更多”，有的用无限滚动。这些差异在单独看每个页面时都不明显，但用户在实际使用中会明显感觉到“这个系统和那个系统不是一个人做的”。

到了第三周，我意识到问题的本质：AI生成的是“页面”，而不是“系统”。它擅长在局部范围内给出看起来合理的代码，但它没有全局的组件复用意识，没有设计系统的概念，更不会主动去维护一套统一的视觉语言。你给它的每一个prompt都是独立的，它返回的每一段代码也是独立的。这种“孤岛式”的生成方式，在页面数量少的时候还能靠人工缝合，一旦规模上去，维护成本呈指数级上升。

第四周我几乎放弃了让AI直接生成完整页面的做法，转而让它只生成业务逻辑部分，UI层我自己来。但这样效率又回到了原点。那段时间我一直在想，有没有一种方式，能让AI在生成页面的时候，天然就遵循一套统一的规范？或者说，有没有一种组件库，它的设计初衷就是为了让AI更好地生成页面？

2. 为什么传统组件库在AI生成场景下“水土不服”

在找到解决方案之前，我先复盘了一下为什么主流的组件库在AI辅助开发场景下表现不佳。这不是组件库本身的问题，而是它们的设计假设和AI生成的工作方式之间存在根本性的错位。

2.1 传统组件库的“人类优先”设计假设

主流组件库的设计逻辑是：人类开发者会阅读文档，理解组件的API设计哲学，然后在自己的项目中按需引入、按规范使用。所以它们提供了丰富的props、slots、事件回调，以及详细的文档和示例。这套体系对人类来说是高效的，因为人类有上下文记忆能力，能理解“这个组件的设计意图是什么”。

但AI不一样。AI在生成代码时，依赖的是训练数据中的模式匹配。它看到“按钮”这个词，会联想到无数种按钮的实现方式，然后从中选一个它认为最合理的。它不会去读你的组件库文档，也不会理解你为什么要封装一个Button组件而不是直接用原生button标签。结果就是，AI生成的代码里，原生HTML元素和组件库组件混用，样式覆盖和优先级冲突层出不穷。

2.2 样式隔离与主题系统的“隐形门槛”

传统组件库通常有一套完整的主题系统，通过CSS变量或预处理器变量来控制颜色、间距、圆角等设计token。这套系统对人类来说是清晰的，但对AI来说却是一道隐形门槛。AI在生成页面时，往往直接写死样式值，而不是引用主题变量。比如它会把按钮背景写成#1890ff，而不是var(--primary-color)。单看一个页面没问题，但当你想换主题色的时候，就会发现有一堆硬编码的颜色需要手动替换。

更麻烦的是样式隔离。很多组件库采用CSS Modules或Scoped CSS，AI在生成代码时经常忘记加对应的类名，或者加错了类名，导致样式不生效。它也不理解“为什么这个组件的样式要写在那个文件里”，只是机械地模仿它见过的代码结构。

2.3 组件粒度与AI生成粒度的错配

传统组件库的组件粒度通常比较细，一个表格组件可能拆成Table、TableColumn、TableHeader、TableBody等好几个子组件。这种设计对人类来说是灵活的，但对AI来说却是负担。AI在生成一个列表页时，需要同时记住这么多组件的用法和它们之间的嵌套关系，很容易出错。它更擅长生成“一个完整的、自包含的代码块”，而不是“一堆需要正确组合才能工作的零件”。

这就导致了一个尴尬的局面：AI生成的页面，要么完全不用组件库，自己从头写一套；要么用了组件库，但用法错误百出，需要大量人工修正。无论哪种情况，都背离了“让AI提升效率”的初衷。

3. Auland-UI的破局思路：为AI生成而生的组件设计

接触到Auland-UI是在一个前端技术群里，有人提到“这个组件库的文档结构对AI特别友好”。当时我正被AI生成的页面一致性问题折磨得不行，就抱着试试看的心态去了解了一下。结果发现，它的设计思路和传统组件库确实不一样——它不是先考虑人类怎么用，而是先考虑AI怎么生成。

3.1 单文件组件：让AI一次生成一个完整单元

Auland-UI最核心的设计决策是：每个组件都是一个自包含的单文件，包含完整的模板、逻辑和样式。这意味着AI在生成页面时，只需要引入一个组件，就能获得完整的视觉和交互效果，不需要再额外引入样式文件、配置文件或子组件。

举个例子，传统组件库的表格可能需要这样用：

<Table :data="tableData"> <TableColumn prop="name" label="姓名" /> <TableColumn prop="age" label="年龄" /> </Table>

而Auland-UI的表格组件是这样的：

<AuTable :columns="columns" :data="tableData" />

所有配置都通过一个columns数组传入，AI只需要生成一个数据结构，不需要理解组件的嵌套关系。这种“配置化”的设计，恰好匹配了AI擅长生成结构化数据的特点。

3.2 语义化的组件命名：降低AI的认知负担

Auland-UI的组件命名非常直白，基本就是“Au+功能名”的格式：AuButton、AuInput、AuTable、AuModal、AuForm。没有缩写，没有隐喻，AI看到组件名就能准确理解它的用途。相比之下，有些组件库用Btn代替Button，用Inp代替Input，对人类来说省了几个字符，但对AI来说却增加了歧义。

更重要的是，Auland-UI的props命名也遵循同样的原则。比如按钮的尺寸用size="small|medium|large"，而不是sm|md|lg；类型用type="primary|secondary|danger"，而不是theme或variant。这种一致性让AI在生成代码时，能够更准确地预测下一个属性应该是什么。

3.3 内置设计token：让AI生成的页面天然统一

Auland-UI把所有的设计token（颜色、间距、圆角、阴影、字体大小）都内置在组件内部，并且通过CSS变量暴露出来。AI在生成页面时，不需要关心具体的样式值，只需要使用组件即可。组件内部会自动应用统一的设计token，保证所有页面在视觉上的一致性。

这一点对我的项目来说太重要了。之前AI生成的页面之所以风格混乱，就是因为每个页面都在自己定义样式值。现在用了Auland-UI，AI只需要写<AuButton type="primary">提交</AuButton>，按钮的颜色、圆角、内边距、字体大小全部由组件内部决定，生成一百个页面也不会出现样式不一致的问题。

4. 把Auland-UI接入AI工作流：从Prompt到页面的完整链路

理解了Auland-UI的设计思路之后，我开始把它接入到我的AI辅助开发工作流中。这个过程不是简单的“换个组件库”，而是需要重新设计prompt策略和代码组织方式。

4.1 重构Prompt：把组件库文档变成AI的“系统提示词”

之前我让AI生成页面时，prompt通常是这样的：“帮我写一个用户管理页面，包含搜索栏、表格和分页，表格列有姓名、邮箱、角色、状态、操作。”AI收到这个prompt后，会根据自己的理解去选择用什么组件、怎么写样式。结果就是每次生成的代码风格都不一样。

接入Auland-UI之后，我在prompt里加入了一段“系统提示词”，明确告诉AI：你正在使用Auland-UI组件库，所有UI元素必须使用Au前缀的组件，禁止使用原生HTML元素或自定义样式。然后附上常用组件的简要说明，比如AuTable的columns配置格式、AuForm的字段定义方式等。

这段系统提示词不需要很长，关键是让AI知道“有哪些组件可用”以及“怎么用”。我实测下来，只要把AuTable、AuForm、AuButton、AuInput、AuModal、AuSelect这几个核心组件的用法说清楚，AI就能覆盖80%的页面生成场景。

4.2 用MCP协议打通组件库与AI工具链

MCP（Model Context Protocol）是最近在AI开发圈子里讨论很多的一个协议，它的核心思路是让AI模型能够以标准化的方式访问外部工具和数据源。我把Auland-UI的组件文档和示例代码通过MCP协议暴露给AI工具，这样AI在生成代码时，可以直接查询组件的最新用法，而不是依赖训练数据中的旧版本。

具体做法是：在项目根目录下配置一个MCP服务，指向Auland-UI的文档目录。当AI需要生成某个组件时，它会先通过MCP查询该组件的API定义和示例，然后再生成代码。这样做的好处是，即使组件库更新了，AI生成的代码也能保持同步，不会出现“AI用了旧版API”的问题。

配置MCP服务的过程不复杂，核心是定义一个manifest文件，描述组件库的入口和文档结构。然后在AI工具的配置中注册这个MCP服务。我用的是支持MCP协议的AI编程助手，配置好之后，AI在生成代码时会自动调用MCP查询，整个过程对用户是透明的。

4.3 建立“组件白名单”与“禁用清单”

为了让AI生成的代码更加可控，我在prompt中明确列出了“组件白名单”和“禁用清单”。白名单里是允许AI使用的组件，禁用清单里是明确不允许使用的原生元素或第三方组件。

比如，我禁止AI使用原生<input>、<select>、<button>标签，必须使用对应的AuInput、AuSelect、AuButton。禁止AI写内联style，所有样式必须通过组件的props或CSS变量来控制。禁止AI引入除Auland-UI之外的任何UI库。

这份清单看起来有点“霸道”，但实测下来效果很好。AI在明确的约束下，生成的代码质量明显提升，几乎不需要人工修正样式问题。

5. 实测对比：传统组件库与Auland-UI在AI生成场景下的差异

为了更直观地展示差异，我拿同一个页面需求做了对比测试。需求是生成一个“订单管理页面”，包含搜索栏（订单号、状态、日期范围）、表格（订单号、客户名、金额、状态、创建时间、操作）、分页和新建订单弹窗。

5.1 代码一致性对比

用传统组件库时，AI生成的代码里出现了以下问题：搜索栏的输入框有的用了组件库的Input，有的用了原生input；表格的列宽有的固定有的自适应；分页组件用了两个不同的实现；弹窗的关闭按钮位置不一致。人工修正这些不一致花了将近四十分钟。

用Auland-UI时，AI生成的代码里所有UI元素都是Au前缀组件，搜索栏统一用AuForm+AuInput+AuSelect+AuDatePicker，表格用AuTable，分页用AuPagination，弹窗用AuModal。代码结构高度一致，几乎不需要修正样式问题。整个生成过程不到十分钟，生成即可用。

5.2 样式冲突排查时间对比

传统组件库方案下，AI生成的页面出现了三处样式冲突：表格的hover效果被全局样式覆盖、弹窗的z-index和下拉菜单冲突、按钮的focus outline被重置。排查这些冲突花了将近一个小时。

Auland-UI方案下，因为所有样式都封装在组件内部，且使用了Shadow DOM或高优先级的CSS变量，没有出现样式冲突。唯一需要调整的是页面级别的布局间距，这个通过AuLayout组件的gap属性统一控制，两分钟搞定。

5.3 后续维护成本对比

传统组件库方案下，后续如果要修改主题色，需要找到所有硬编码颜色的地方逐一替换，还要处理样式覆盖的优先级问题。粗略估计，三十个页面的主题色替换至少需要半天时间。

Auland-UI方案下，主题色通过CSS变量统一控制，只需要修改根节点的变量值，所有页面自动生效。而且因为AI生成的代码里没有硬编码颜色，不存在遗漏的问题。

6. 踩过的坑与实战心得

这套工作流不是一开始就顺畅的，中间踩了不少坑，有些是Auland-UI本身的限制，有些是我对AI生成机制的理解偏差。

6.1 AI会“自作聪明”地绕过组件库

即使我在prompt里明确说了“必须使用Auland-UI组件”，AI有时候还是会“自作聪明”地写原生HTML。比如生成一个简单的标签展示，它会写<span class="tag">...</span>而不是<AuTag>...</AuTag>。原因是AI在训练数据中见过太多原生HTML的写法，当它认为“这个场景很简单，不需要用组件”时，就会绕过约束。

解决办法是在prompt里加一句：“即使是最简单的元素，也必须使用对应的Au组件。如果Auland-UI没有提供对应组件，则使用AuBox作为容器并说明原因。”这样AI就没有借口了。

6.2 复杂表单的字段联动逻辑仍需人工介入

Auland-UI的AuForm组件支持通过schema定义表单字段，AI生成简单的表单没问题。但涉及到字段联动（比如选择“企业客户”时才显示“公司名称”字段），AI生成的逻辑经常有bug。它会把联动条件写在错误的位置，或者忘记处理初始状态。

我的做法是：让AI生成表单的基础结构，联动逻辑我自己来写。因为联动逻辑通常和业务规则强相关，AI很难从简单的prompt中理解完整的业务语义。与其反复调试AI生成的逻辑，不如自己写来得快。

6.3 组件库版本更新后，AI的“记忆”会过时

AI的训练数据有截止日期，它“记住”的Auland-UI API可能是旧版本的。当组件库更新后，AI生成的代码可能使用了已废弃的props或事件名。这个问题通过MCP协议可以缓解，但前提是MCP服务配置正确且AI工具支持实时查询。

我的经验是：每次升级Auland-UI后，先手动更新MCP服务的文档缓存，然后在prompt里附上“当前版本号”和“本次更新的破坏性变更列表”。这样AI在生成代码时会优先使用新API。

6.4 不要指望AI理解“设计意图”

AI可以生成符合组件库规范的代码，但它不理解“为什么这个按钮要用primary而不是secondary”。它只是根据prompt中的描述和训练数据中的模式来选择。所以，对于有明确设计规范的页面，最好在prompt中直接指定每个元素的类型和状态，而不是让AI“猜”。

比如，不要写“生成一个提交按钮”，而要写“生成一个AuButton，type为primary，尺寸为medium，文字为‘提交’”。虽然prompt变长了，但生成结果的准确率大幅提升。

7. 从“AI写页面”到“AI写系统”的思维转变

用Auland-UI配合AI工作流一个月之后，我最大的收获不是效率提升了多少，而是对“AI辅助开发”这件事的理解发生了变化。

以前我把AI当成一个“代码生成器”，给它需求，它给我代码。但这种模式下，AI生成的是孤立的代码片段，我需要花大量精力去整合、去统一。现在我把AI当成一个“系统构建助手”，我负责定义系统的规则（用什么组件库、遵循什么设计规范、有哪些约束），AI负责在这个规则框架内填充具体实现。

这个思维转变的关键在于：约束比自由更重要。给AI越多的自由，它生成的代码越多样，整合成本越高。给AI明确的约束（组件白名单、样式规范、代码结构），它反而能生成更一致、更可维护的代码。Auland-UI的价值就在于，它提供了一套“AI友好”的约束框架，让AI在生成页面时天然就遵循统一的设计语言。

如果你也在用AI辅助前端开发，并且遇到了和我类似的问题——生成的页面风格混乱、维护成本高、组件复用率低——我的建议是：不要试图通过更详细的prompt来解决所有问题，而是从组件库层面入手，选择一个为AI生成场景设计的组件库。Auland-UI不一定适合所有项目，但它的设计思路值得参考：组件自包含、命名语义化、配置化API、内置设计token。这些特性不仅对AI友好，对人类开发者来说也能降低认知负担。

最后分享一个我在实际使用中总结的小技巧：把常用的页面模板（列表页、表单页、详情页）做成prompt模板，每个模板里预置好Auland-UI的组件结构和常用配置。AI生成新页面时，只需要在模板基础上替换业务字段即可。这样既保证了页面结构的一致性，又减少了每次从头描述组件用法的重复劳动。我目前维护了六个这样的模板，覆盖了项目中90%的页面类型，实测下来，新页面的生成时间从平均四十分钟压缩到了十分钟以内。