企业官网建设流程全解析

1. 这不是偷懒，是工作流的彻底重构

“自从有了 AI，我就再也不想拼 UI 了……”——这句话最近在设计群、前端茶水间和产品例会上高频出现，不是抱怨，更像一种带着点得意的宣言。它背后藏着的，不是设计师或开发者的懈怠，而是一场静默却剧烈的生产力迁移：UI 构建这件事，正从“手工组装”加速滑向“意图驱动生成”。我做交互设计和前端落地十多年，亲手拖过上千个 Sketch 图层、写过上万行 CSS 布局代码、调过数不清的间距像素，也经历过 Figma 插件刚火起来时那种“终于不用手动对齐”的小确幸。但这次不一样。AI 不是又一个效率插件，它是直接把“拼”这个动作从工作流里物理删除了。

核心关键词“AI”和“拼 UI”在这里有明确指向：它不指代泛泛的 AI 工具，而是特指能理解自然语言描述、理解设计约束、理解组件语义，并能输出可运行前端代码（HTML/CSS/JS 或 React/Vue 组件）的生成式模型。它解决的也不是“画图快不快”，而是“从需求到可用界面之间那道最耗神、最易错、最反直觉的鸿沟”。比如，产品经理说“做个会员续费弹窗，要突出价格优势，按钮要醒目，底部加个‘联系客服’小字”，过去你要拆解成：弹窗容器尺寸、蒙层透明度、标题字号颜色、价格数字的加粗与色块、主按钮的圆角阴影悬停态、小字的行高与颜色、响应式断点处理……现在，你把这些话原样喂给工具，它吐出来的不只是静态图，而是带交互逻辑、可直接嵌入项目的代码块。适合谁？不是取代资深 UI 设计师，而是让设计师从“像素搬运工”回归“体验架构师”，让前端工程师从“样式调试员”升级为“逻辑校验者”，让产品经理第一次真正拥有“所想即所得”的原型能力。

这背后的技术支点，是多模态大模型在视觉理解（ViT）、代码生成（CodeLlama、StarCoder）、设计语言建模（Figma 的 Design Language Model）三个维度的交叉突破。它不是魔法，而是把过去十年积累的设计系统（Design System）、组件库（Component Library）、CSS-in-JS 工程实践，全部压缩进模型的训练数据里，再用自然语言当钥匙打开。所以，它不适用于“我要一个抽象艺术风格的首页”，但极其擅长“按 Ant Design 规范，生成一个带搜索框、分页器和操作列的用户管理表格”。它的价值，不在天马行空，而在精准复现与高效组合——而这，恰恰是日常工作中占比 80% 的 UI 任务。

2. 为什么“拼 UI”正在失效：一场被忽视的底层成本清算

要理解“再也不想拼 UI”背后的决绝，得先算一笔没人明说但人人承受的隐性账。过去我们默认“拼 UI”是必要劳动，就像程序员敲代码一样天经地义。但仔细拆解，这个过程消耗的远不止时间。

2.1 时间成本：线性增长 vs 指数衰减

传统拼 UI 是典型的线性工作：需求增加 10%，工作量几乎就增加 10%。做一个按钮，花 5 分钟；做十个同类型按钮，保守估计要 40 分钟——因为要反复检查间距、对齐、状态样式、响应式适配。而 AI 生成是近似常数时间：描述一次“带 loading 状态的主按钮”，生成十个不同场景下的按钮，耗时仍是 15 秒左右。我实测过一个真实项目：重构一个含 12 个表单字段、3 种校验状态、2 套主题色的注册页。团队两人协作，手写 HTML+Tailwind CSS，耗时 3 小时 27 分；用 Claude 3 + 自定义提示词生成基础结构，再人工微调，全程 48 分钟。节省的不是 2 小时，而是那 2 小时里反复切换上下文、核对设计稿像素、调试 Safari 兼容性的精神损耗。

2.2 一致性成本：人工无法逾越的鸿沟

“拼 UI”最大的幻觉，是认为自己能保证一致性。现实是，哪怕同一个设计师，在不同时间、不同情绪下，对“中等间距”“轻微阴影”的判断都会有毫秒级偏差。我们依赖设计系统文档、组件库、Code Review 来对抗这种熵增，但效果有限。AI 则天然具备“绝对一致性”：只要提示词不变、约束条件不变，它生成的第 1 个按钮和第 1000 个按钮，在 padding、border-radius、transition-duration 上的数值误差为 0。更重要的是，它能跨组件理解约束。比如你要求“所有卡片圆角统一为 8px，且内边距为 p-4”，它不会只改卡片容器，还会自动同步调整卡片内的标题、描述、操作按钮的内边距层级，避免人工遗漏导致的视觉断裂。这种一致性不是靠流程管控，而是模型内在的逻辑绑定。

2.3 沟通成本：从“像素级翻译”到“意图对齐”

传统流程里，UI 落地是三方博弈：设计师产出高保真图，前端解读图层含义，产品经理质疑“这里和上次说的不一样”。每一次沟通，都在消耗对“那个蓝色是不是 Pantone 2945C”“这个动画是 ease-in-out 还是 cubic-bezier(0.25, 0.46, 0.45, 0.94)”的精确共识。AI 介入后，沟通对象变成了提示词（Prompt）。当产品经理写下“用户头像右上角加个绿色在线标识，大小为头像的 1/4，居右上角 4px”，这个句子本身就是一个无歧义的、可执行的契约。设计师不再需要画出标识位置，前端不再需要猜测“4px”是相对于头像还是容器，大家共同聚焦于“这个描述是否准确表达了业务意图”。沟通成本从“解释像素”降维到“校准语言”，这是质变。

提示：别迷信“一句话生成全站”。AI 擅长的是原子级、模式化、有明确约束的 UI 片段。把“生成一个电商首页”这种模糊需求丢给 AI，结果大概率是灾难性的。真正的生产力提升，来自把大需求拆解为“生成商品卡片”“生成购物车侧边栏”“生成支付成功弹窗”这样的可定义、可验证、可复用的单元。这反而倒逼团队建立更清晰的模块化思维。

3. 核心技术点拆解：AI 不是黑箱，是可配置的 UI 工厂

把 AI 当作一个神秘黑箱去“用”，很快会撞墙。真正释放其价值，必须理解它内部的三个关键控制旋钮：提示词工程（Prompt Engineering）、约束注入（Constraint Injection）、后处理校验（Post-processing Validation）。它们共同构成一个可预测、可复现、可迭代的 UI 生成流水线。

3.1 提示词：不是聊天，是编写 UI 的 DSL

很多人以为提示词就是“说人话”，比如“给我一个登录按钮”。这只能得到一个粗糙的、脱离上下文的产物。专业级提示词，本质是一种轻量级的领域特定语言（DSL），必须包含四个强制维度：

• 角色定义：明确 AI 的身份。“你是一个资深前端工程师，精通 Tailwind CSS 和 React 最佳实践，熟悉 Ant Design 设计规范。” 这决定了它输出的代码风格、组件封装方式和可访问性（a11y）意识。
• 输入约束：限定输入源。“基于以下 Figma 设计稿链接中的‘用户列表’页面，提取所有交互元素。” 或 “严格遵循公司设计系统文档 v3.2 中的色彩系统和间距标尺。”
• 输出规范：规定交付物。“输出一个完整的 React 函数组件，使用 TypeScript 编写，包含 props 接口定义；CSS 使用 Tailwind 类名，禁止内联 style；必须包含 loading 和 error 状态的占位逻辑。”
• 质量守则：设置底线。“禁止使用 magic number（如top: 12px）；所有颜色必须引用设计系统变量；响应式断点需覆盖 mobile/tablet/desktop 三档。”

我常用的提示词模板如下（已脱敏）：

你是一名专注企业级应用的前端工程师，熟悉 Ant Design 5.x 和现代 React（18+）最佳实践。 请基于以下需求生成一个可复用的 React 组件： 【需求】：一个带搜索、排序、分页的用户管理表格，支持点击行选中，选中行高亮显示，顶部有“新增用户”按钮。 【约束】：1. 使用 Ant Design 的 Table 组件；2. 表格列包括：头像+姓名、邮箱、角色、状态（标签）、操作（编辑/删除）；3. 状态标签需按“active/inactive/pending”映射为 Ant Design 的 Tag 颜色；4. 所有文案使用 i18n key（如 `user.name`）。 【输出】：1. 完整的 TypeScript React 函数组件；2. 包含必要的 props 接口（如 `data: User[]`, `onSelect: (id: string) => void`）；3. 使用 `useMemo` 优化渲染性能；4. 添加 JSDoc 注释说明组件用途和 props。 【禁令】：禁止硬编码中文；禁止使用非 Ant Design 的 UI 元素；禁止忽略键盘导航（tabindex）。

这个提示词之所以有效，是因为它把 AI 从“自由发挥者”变成了“严格守约的承包商”。它不关心“美不美”，只关心“是否满足契约条款”。

3.2 约束注入：让 AI 在轨道上奔跑

没有约束的 AI，就像没有轨道的高铁。约束注入，就是给它铺设铁轨。常见约束类型有三类：

• 设计系统约束：这是最硬的约束。将设计系统的 JSON Schema（如色彩值、间距标尺、字体层级、组件 API）作为上下文注入提示词。例如，提供一个spacing对象：{ xs: '4px', sm: '8px', md: '12px', lg: '16px', xl: '24px' }，AI 在生成margin或padding时，就只会从这个集合里选值，杜绝了p-3.5这种非法类名。
• 框架约束：指定技术栈细节。要求“使用 React Server Components 语法”“输出 Vue 3 的<script setup>格式”“CSS 必须用 CSS Modules 模块化”，这些指令直接决定输出代码的工程兼容性。
• 业务逻辑约束：这是最容易被忽略的。比如“用户状态标签，当status === 'pending'时，显示为黄色并禁用操作按钮”，这类规则必须显式写出，否则 AI 只会生成静态 UI，无法承载真实业务流。

实操中，我习惯把约束整理成一个 YAML 文件，每次生成前加载为提示词的一部分。这比在每次对话里重复粘贴更可靠，也便于版本管理。一个典型约束文件片段：

designSystem: colors: primary: "#1890ff" success: "#52c418" warning: "#faad14" danger: "#f5222d" spacing: - "px" - "1" - "2" - "3" - "4" - "6" - "8" typography: heading: "font-bold text-lg" body: "text-base leading-relaxed" framework: library: "Ant Design" version: "5.12.0" componentStyle: "CSS-in-JS"

3.3 后处理校验：AI 的“质检员”不能是人

生成的代码再好，也不能直接扔进生产环境。必须有一套自动化校验流程，充当 AI 的“第二双眼睛”。我搭建了一个极简但有效的本地校验链：

1. 语法校验：用 ESLint（针对 JS/TS）和 Stylelint（针对 CSS/Tailwind）跑一遍，确保无基础错误。
2. 设计系统校验：写一个小型脚本，扫描生成代码中的颜色值、间距值，比对是否在设计系统约束列表内。发现bg-red-500而设计系统只允许bg-danger，立刻报错。
3. 可访问性校验：用 axe-core 浏览器插件或 CLI 工具，检查生成的组件是否通过 WCAG 2.1 AA 标准，重点看aria-label、role、键盘焦点顺序。
4. 视觉回归测试：用 Storybook + Chromatic，将 AI 生成的组件与人工编写的基准组件并排渲染，用像素级对比工具检测差异。哪怕只是 1px 的边框宽度偏差，也会被捕捉。

这套校验不是为了证明 AI 错了，而是为了建立信任。当校验通过率稳定在 98% 以上时，“人工审核”就从“逐行检查”降级为“抽查逻辑”，这才是可持续的工作流。

4. 实操全流程：从需求到可部署代码的七步法

光讲原理不够，得给你一套能立刻上手、踩过坑的实操路径。下面是我团队正在用的“AI 辅助 UI 开发七步法”，每一步都附带真实参数、工具链和避坑心得。整个流程，从接到需求到代码合并，平均耗时 1 小时 15 分钟。

4.1 第一步：需求原子化拆解（10 分钟）

绝不直接喂给 AI 一个 PRD 文档。必须人工拆解为最小可生成单元。以“用户管理后台”为例：

• ❌ 错误做法：“生成用户管理页面”
• ✅ 正确拆解：
  • 原子组件 1：用户头像徽章（含在线状态）
  • 原子组件 2：带搜索和筛选的表格头部
  • 原子组件 3：用户数据行（含头像、信息、状态标签、操作按钮）
  • 原子组件 4：分页器（含总条目、当前页、跳转）
  • 原子组件 5：新增用户弹窗（含表单、校验、提交）

拆解原则：每个单元必须有独立的视觉边界、明确的交互反馈、可单独测试。这步花的时间，省下了后续 80% 的返工。

4.2 第二步：构建专属提示词库（一次性投入，长期受益）

不要每次现写提示词。建立一个 Markdown 格式的提示词库，按组件类型分类。每个条目包含：

• 场景描述：一句话说明适用情境
• 标准提示词：已验证有效的完整提示词
• 约束文件链接：指向对应的 YAML 约束
• 典型输出示例：展示生成的代码片段
• 常见失败案例：记录曾因什么描述不清导致生成错误，并给出修正版

例如，“状态标签”条目：

## 状态标签（Status Badge） **场景**：用于展示用户、订单、任务等实体的生命周期状态。 **标准提示词**：你是一个前端工程师，熟悉 Ant Design。请生成一个 React 组件，接收 `status: 'active' | 'inactive' | 'pending' | 'archived'` 属性，根据 status 值渲染对应颜色的 Ant Design Tag。Tag 内容为国际化文案（如 `status.active`）。禁止硬编码文字。 **约束文件**：`constraints/design-system/colors.yaml` **输出示例**： ```tsx import { Tag } from 'antd'; interface StatusBadgeProps { status: 'active' | 'inactive' | 'pending' | 'archived'; } export const StatusBadge = ({ status }: StatusBadgeProps) => { const colorMap = { active: 'success', inactive: 'default', pending: 'warning', archived: 'error', }; return <Tag color={colorMap[status]}>{`status.${status}`}</Tag>; };

失败案例：曾因未指定colorMap映射规则，AI 输出了style={{ backgroundColor: '#52c418' }}，违反了设计系统约束。修正：在提示词中明确要求“使用 Ant Design Tag 的color属性，禁止内联 style”。

这个库让新人上手零成本，也避免了团队内提示词风格混乱。 ### 4.3 第三步：选择生成引擎（工具选型实战对比） 市面上工具很多，但真正能融入工程流的不多。我实测过 5 款主流工具，结论很明确： | 工具 | 优势 | 劣势 | 适用场景 | 我的推荐指数 | |------|------|------|----------|--------------| | **Claude 3 Opus** | 逻辑推理强，长上下文（200K tokens），对复杂约束理解最好 | 生成速度慢（15-20秒/次），API 成本高 | 复杂组件、多步骤交互、强约束场景 | ★★★★☆ | | **Cursor（集成 Claude/GPT）** | IDE 深度集成，可直接在 VS Code 里生成、修改、运行代码 | 依赖本地算力，对超长提示词支持不稳定 | 日常开发，快速生成单个组件 | ★★★★★ | | **Galileo AI** | 专为 UI 设计，支持 Figma 插件，能直接从设计稿生成代码 | 输出格式固定（React+Tailwind），定制化弱 | 设计师主导，快速将设计稿转代码 | ★★★☆☆ | | **Vercel v0** | 生成速度快，UI 美观度高，支持 Next.js | 对自定义设计系统支持弱，输出代码较“重” | 快速原型、营销页、内部工具 | ★★★★☆ | | **GitHub Copilot X** | 与 VS Code 无缝衔接，补全精准 | 对复杂 UI 结构生成能力有限，易陷入局部优化 | 辅助编写已有组件的逻辑，非端到端生成 | ★★☆☆☆ | 我的主力组合是：**Cursor（日常开发） + Claude 3 Opus（复杂组件攻坚）**。Cursor 胜在“所见即所得”，写完提示词，回车，代码就出现在编辑器里，还能一键运行预览；Claude 3 则用来攻克那些需要多轮对话澄清、涉及复杂状态管理的组件。两者互补，覆盖 95% 场景。 ### 4.4 第四步：生成与初筛（5 分钟/组件） 在 Cursor 中打开一个新文件，粘贴提示词，按 `Cmd+K`（Mac）或 `Ctrl+K`（Win）触发生成。关键技巧： - **不要一次生成全部**：先生成最核心的组件（如表格主体），确认结构正确后，再生成配套的头部、分页器。 - **利用“继续生成”功能**：如果第一版缺少某个状态（如 loading），不要重写提示词，直接选中生成的代码，输入“添加 loading 状态，显示 skeleton 骨架屏”，AI 会精准补全。 - **初筛三原则**：1）代码是否符合约定的框架和语法？2）关键 props 是否定义完整？3）是否有明显违反约束的硬编码？不符合任一原则，立刻重试。 ### 4.5 第五步：约束校验与微调（15 分钟/组件） 将生成的代码放入本地项目，运行校验脚本： ```bash # 运行 ESLint npm run lint:fix # 运行设计系统校验（自研脚本） npm run validate:design-system -- --file src/components/UserTable.tsx # 运行 a11y 校验 npm run test:a11y -- --component UserTable

校验失败是常态，但失败点高度集中：

• 颜色/间距硬编码：AI 偶尔会“忘记”约束，用bg-blue-500代替bg-primary。修复：全局替换，或在提示词中加入更强约束“所有颜色类名必须以bg-或text-开头，且后缀必须是设计系统定义的 token”。
• 缺失 TypeScript 类型：AI 有时会漏掉 props 接口。修复：用 Cursor 的Cmd+I快捷键，选中组件名，输入“为这个 React 组件添加完整的 TypeScript 接口定义”，它会精准补全。
• 无障碍缺陷：如button缺少aria-label。修复：在提示词中强化“所有交互元素必须包含语义化 aria 属性”。

微调不是推翻重来，而是用 AI 修复 AI 的瑕疵，形成正向循环。

4.6 第六步：Storybook 集成与视觉验收（10 分钟）

将校验通过的组件，添加到 Storybook：

// UserTable.stories.tsx import type { Meta, StoryObj } from '@storybook/react'; import { UserTable } from './UserTable'; const meta = { title: 'Components/UserTable', component: UserTable, parameters: { layout: 'centered', }, tags: ['autodocs'], } satisfies Meta<typeof UserTable>; export default meta; type Story = StoryObj<typeof UserTable>; export const Default: Story = { args: { data: [ { id: '1', name: '张三', email: 'zhang@example.com', role: 'admin', status: 'active' }, { id: '2', name: '李四', email: 'li@example.com', role: 'user', status: 'pending' }, ], }, }; export const Loading: Story = { args: { loading: true, data: [], }, };

启动 Storybook，直观对比 AI 生成的组件与设计稿。重点看：

• 像素级对齐：用浏览器测量工具，检查间距、圆角、阴影是否一致。
• 状态完整性：逐一点击，验证 active/inactive/pending 状态下的视觉反馈是否正确。
• 响应式表现：切换设备尺寸，确认布局断点生效。

这一步，是人机协作的临界点：AI 负责“生成”，人负责“确认意图是否被准确表达”。不是找 bug，而是校准语义。

4.7 第七步：提交与知识沉淀（5 分钟）

代码通过所有校验和视觉验收后，提交 PR。但关键在 PR 描述：

• 必填字段：
  • [AI Generated]标签
  • 使用的提示词摘要（非全文，如“基于‘用户表格原子组件’提示词 v2.1”）
  • 约束文件版本（如constraints/design-system/v3.2.yaml）
  • 校验报告链接（指向 CI 的 ESLint/a11y/DesignSystem 校验日志）
• 附加说明：记录本次生成中遇到的特殊问题及解决方案（如“首次生成缺少 keyboard navigation 支持，已在提示词中补充aria-*要求”）

这个 PR 描述，就是团队的知识资产。它让 Code Review 不再是“这个代码对不对”，而是“这个提示词和约束是否足够健壮”。久而久之，团队沉淀的不是一堆代码，而是一套可复用、可演进的“AI UI 工程化方法论”。

5. 常见问题与排查技巧实录：那些没写在文档里的坑

再好的流程，也会遇到意料之外的状况。以下是我在真实项目中踩过的、文档里绝不会写的 7 个典型问题，以及经过验证的排查路径。

5.1 问题 1：AI 生成的代码“看起来对，但跑不起来”

现象：生成的 React 组件在 Storybook 里渲染正常，但集成到主应用时，onClick事件不触发，或useState报错。

排查路径：

1. 检查 React 版本兼容性：AI 常默认使用最新语法（如useActionState），但你的项目可能还在用 React 17。在提示词中明确指定React 18.2。
2. 检查 Hook 规则：AI 有时会把useState写在条件语句里。用 ESLint 的react-hooks/rules-of-hooks规则捕获。
3. 检查依赖注入：生成的组件可能用了lodash的debounce，但项目里没装。在提示词中加入“禁止使用未声明的第三方依赖，所有工具函数必须内联实现或使用 React 原生 API”。

独家技巧：在 Cursor 的设置里，开启Auto-imports，它会在生成代码时自动补全缺失的 import 语句，大幅降低此类错误。

5.2 问题 2：提示词明明写了“用 Ant Design”，AI 却生成了原生 HTML

现象：要求“用 Ant Design 的 Button”，结果输出<button className="...">。

根本原因：AI 对“Ant Design”这个词的理解，是“一个 UI 库”，而不是“一个具体的、有 API 的组件集合”。它需要更精确的锚点。

解决方案：

• 在提示词中，必须提供具体组件的官方文档链接。例如：“参考 Ant Design 官方文档 https://ant.design/components/button-cn/ 中的 Button 组件 API，使用type="primary"和loading属性。”
• 提供最小可行代码片段作为上下文。例如，粘贴一段你项目里已有的、正确的 Ant Design Button 用法：

  import { Button } from 'antd'; <Button type="primary" loading={loading}>提交</Button>

  这相当于给 AI 一个“样板”，它会优先模仿这个模式。

5.3 问题 3：生成的响应式代码在移动端错乱

现象：桌面端完美，手机端元素堆叠、文字溢出。

深层原因：AI 对 CSS 媒体查询的理解，是基于训练数据中的常见模式，而非你项目里实际的断点配置。它可能用md:而你的 Tailwind 配置是tablet:。

排查与修复：

1. 校验断点命名：运行npx tailwindcss-config-viewer查看项目真实的断点配置，将其写入约束文件。
2. 在提示词中锁定断点：“使用项目配置的断点：mobile: 'max-width: 639px',tablet: 'min-width: 640px',desktop: 'min-width: 1024px'。所有响应式类名必须严格匹配此命名。”
3. 强制使用@apply：对于复杂响应式逻辑，提示词中要求“使用@apply指令在 CSS 文件中定义响应式类，而非在 JSX 中写md:text-lg”，这样能绕过 AI 对类名的误判。

5.4 问题 4：AI 对“设计系统”的理解严重偏离

现象：约束文件里写了primary: "#1890ff"，AI 却生成bg-blue-500。

真相：AI 的训练数据里，“blue-500” 出现频率远高于"#1890ff"。它选择了“统计学上更可能”的答案，而非“你约束里规定的答案”。

终极解法：

• 在约束文件中，用“禁止”代替“要求”。不要写“请使用bg-primary”，而写“禁止使用任何bg-*或text-*类名，所有颜色必须通过style={{ backgroundColor: theme.colors.primary }}设置”。
• 提供设计系统变量的导入路径：“所有颜色必须从@/styles/theme.ts中的theme.colors对象导入并使用。”

这看似增加了复杂度，但换来的是 100% 的确定性。

5.5 问题 5：生成的组件可访问性（a11y）评分极低

现象：axe 扫描报告里，<div>缺少role，<img>缺少alt，键盘 tab 顺序混乱。

根源：可访问性不是 AI 的默认优先级。它需要被明确设为“硬性要求”。

实操方案：

• 在提示词开头，加入一行强力声明：“可访问性（WCAG 2.1 AA）是最高优先级，所有输出必须通过 axe-core 扫描，无中高风险项。”
• 提供 a11y 检查清单作为上下文：

  必须满足： - 所有交互元素有 `role` 和 `aria-*` 属性 - 所有图片有 `alt` 属性（图标用 `alt=""`） - 所有表单控件有 `label` 或 `aria-labelledby` - 键盘 tab 顺序符合 DOM 顺序 - 颜色对比度 ≥ 4.5:1

• 用 AI 生成 a11y 修复：当扫描出问题，选中问题代码，输入“为这段代码添加 WCAG 2.1 AA 合规的可访问性属性”，它通常能精准修复。

5.6 问题 6：多人协作时，AI 生成风格不一致

现象：A 同事生成的按钮用className，B 同事生成的用style；C 同事的组件用props，D 同事的用children。

病灶：缺乏统一的“风格指南”（Style Guide）。

处方：

• 制定团队级 AI 风格指南，包含：
  • 组件封装粒度（函数组件 vs 类组件）
  • Props 命名规范（onSubmitvshandleSubmit）
  • 状态管理偏好（useStatevsuseReducer）
  • 错误处理模式（try/catchvserror boundary）
• 将风格指南固化为提示词的一部分。每次生成前，自动注入这段指南。
• 用 Prettier + ESLint 强制格式化，让代码风格在提交前自动统一，减少人为差异。

5.7 问题 7：AI 生成的代码“太完美”，反而难以维护

现象：生成的组件逻辑高度抽象，用了复杂的useMemo、useCallback、自定义 Hook，但实际业务很简单。

反思：AI 的“最优解”，未必是团队的“最适解”。工程师的首要职责不是写出最优雅的代码，而是写出最易懂、最易改、最易交接的代码。

平衡之道：

• 在提示词中加入“简洁性优先”原则：“在保证功能正确的前提下，优先选择最直接、最少抽象层的实现。避免为未来可能的需求提前设计。”
• 人工干预点：生成后，第一件事不是运行，而是问自己：“一个刚入职的 junior，能在 5 分钟内看懂这个组件的逻辑吗？” 如果不能，就删掉那些炫技的useMemo，换成直白的map和if。
• 记住：AI 是杠杆，人是支点。支点的位置，决定了杠杆放大的是效率，还是复杂度。

6. 未来已来：当“拼 UI”消失后，设计师和前端该练什么新肌肉？

“再也不想拼 UI”不是终点，而是新赛跑的起跑线。当原子级 UI 构建被 AI 托底，真正的价值高地，正迅速向两端迁移：一端是更上游的“意图定义”，一端是更下游的“体验整合”。这要求从业者主动卸下旧肌肉，长出新筋骨。

6.1 向上游进化：成为“意图架构师”

过去，设计师的核心竞争力是“把想法变成像素”。未来，是“把模糊的业务目标，翻译成 AI 能精准执行的、无歧义的、可组合的意图单元”。这需要三种新能力：

• 需求解构力：能一眼看出 PRD 里的“用户旅程图”，哪些环节可以拆解为 AI 可生成的原子组件，哪些必须人工深度介入（如情感化动效、复杂数据可视化）。
• 提示词工程力：不是写作文，而是写契约。要精通如何用最少的词，定义最严的约束，激发最准的输出。这本质上是一种新的编程语言能力。
• 设计系统治理力：AI 的质量，直接取决于设计系统的完备性。设计师要从“画组件”转向“定义组件的语义边界、状态流转规则、约束接口”。一个设计系统文档，就是喂给 AI 的“宪法”。

我团队的新招聘 JD 里，已经把“熟练使用 Figma 插件”换成了“能独立编写并维护设计系统约束文件（YAML/JSON Schema）”。

6.2 向下游进化：成为“体验整合者”

前端工程师的价值，正从“让 UI 跑起来”，跃迁到“让体验连贯起来”。AI 生成的，永远是孤立的、完美的“零件”。把它们组装成一台运转流畅的“机器”，才是人的不可替代之处。关键新技能：

• 状态流编排力：AI 能生成一个“登录表单”，但无法生成“登录成功后，自动跳转到仪表盘，并触发欢迎动画，同时更新全局用户状态”。这需要工程师用 Zustand、Jotai 或 React Query，把多个 AI 组件的状态串联起来。
• 性能与可靠性兜底力：AI 生成的代码，在 90% 场景下没问题。但那 10% 的边缘 case（如网络抖动、内存泄漏、极端数据），需要工程师用监控、降级、缓存策略来兜底。这不再是“锦上添花”，而是“生存必需”。
• 跨端一致性保障力：AI 可能为 Web 生成一套代码，为 App 生成另一套。工程师要建立统一的状态管理、统一的 API 适配层、统一的错误处理中心，确保用户在不同端看到的，是同一套体验逻辑，而非两套平行世界。

6.3 一个务实的行动建议：从明天开始，做三件事

不必等待公司政策或购买新工具。改变，可以从明天早上开工的第一分钟开始：

1. 立刻建立你的个人提示词库：新建一个 GitHub Gist 或 Notion 页面，把今天用过的、有效的提示词存进去。哪怕只有 3 个，也是起点。
2. 给一个现有组件“AI 化”：挑一个你项目里最枯燥、最重复的组件（比如各种状态的 Toast 提示），用 AI 重新生成，走一遍七步法，对比耗时和质量。
3. **在