AI对UX工作流的影响

B端设计做了好些年了，没有哪个工具或者概念能给我的工作方式带来这么多改变。如果说变化最多的是什么，那就是累。AI增强我能力的同时，也让我的工作范围变得更广，工作事项更繁琐。从这点来说，我是很讨厌AI的。以下内容纯手打，0 AI 介入。 具体而言，AI主要帮我完成的内容包含三部分：分解业务和需求，设计灵感和 Review，以及 Coding。

分解业务和需求

B端业务都比较复杂，特别是我现在的行业。让我一个学设计的去理解包含了大量高阶物理/数学的需求还是太强人所难就。而 AI 会尽可能的通俗易懂的去把这些知识抽象出来，让作为普通人的我，也能比较容易的知道这个需求到底在干什么事。

这对我而言是非常非常重要的，B端设计，业务理解程度很多时候比设计能力要重要。所以现在我拿到 PRD 或者用户 Feedback 的第一时间，是喂给 AI ，让它帮我剖析成我更容易看懂的内容。

而在完成一个需求后，我会让 AI帮我整理PRD和我的设计，随后存在知识库里，在未来的设计流程中当成上下文来引用。为了知识库便于 AI理解，格式尽量统一，用 Skill来做是最合适的。比如我个人的 Skill：

这一阶段，我个人习惯用 Gemini 或者 Claude。

设计灵感和设计 Review

在这个阶段之前，一定要一定要一定要自己先去思考设计方案。不然容易被AI带偏，且形成依赖后，自身思考能力会快速下降。

我个人流程是：获取需求-Figma古法设计-AI设计灵感-AI review - 设计定稿。

在通过 AI 获取设计灵感的时候，上下文非常重要。可能遗漏一部分内容会得到完全不一样的回复。所以我让AI 分析完需求后要整理成知识库，知识库足够丰富后，在征求AI 意见的时候，调取需求相关的MD文档，更容易得到好的结果。

顺便说一下我个人的知识库思路，一个总的MD文档，介绍产品的背景，用户群体，解决的问题，以及大致的信息架构和功能等。然后按照功能切碎， 每一个小的功能点都整理成 MD平铺开来，想过分类汇总之类的，但功能错综复杂互相关联不太好分，干脆直接拍平拉倒。 这里用的AI是 Gemini 为主（推荐使用 Google AI Studio），偶尔用用Stitch。我个人感觉直接生成设计稿的 AI 思考深度没有生文的 AI深。 Stitch 给的视觉效果有时候还可以，会酌情采纳， 交互逻辑则有点一言难尽。

AI 的产出质量参差不齐，所以需要多多和它 battle 一下。但是 Gemini 的讨好型人格太容易顺从了，必须给它下达类似“务必诚实”的指令。

在综合 AI 的建议产出设计后，我会把自己的设计稿和理解扔过去，让 AI Review，会得到很多设计细节的补充。以及一大堆夸夸。 这一阶段，我个人习惯用 Gemini 或者 Claude。

Coding

我没有多少开发基础，所以 Coding 对我来说也是一次全新的尝试，往真实的复杂项目里提交代码是我以前不敢想的。
目前我通过 Coding 调整的只有交互和视觉，不涉及复杂的业务逻辑和接口联调。

很常见的场景就是修改和替换组件库，开发用的组件库是 Ant D（很多团队的选择），样式和一些交互上和预期有差距的，像这种就很适合设计师用 Cursor 之类的调整。举个实际的例子，线上环境 Dropdown 使用非常混乱，要统一成我们想要的样式，可以先排查，再纠正样式，最后逐步替换。

排查线上情况：

调整样式： 因为 Ant D组件被其他项目也引用了我不太好直接覆盖，而是再包了一层用在我的项目里。 新增组件后，顺带让 AI把 Storybook 也补充完善，方便预览和修改。需要注意的是，让 AI 做组件，前提是设计自己知道组件有哪些属性、类型等。毕竟让 AI完成的前提是自己知道想要什么。

至于让 AI还原设计的样式和细节，如果 Figma设计稿严格使用 Auto layout，那么更新后的MCP 我觉得已经勉强够用了，Opus 4.6第一遍就能还原大部分的设计细节，接下来的精雕细琢就多来几轮对话就好。不过我依旧习惯在让 AI还原设计稿的时候引入Skill，比如这是我根据我们项目和仓库创建的 Skill：

在组件达到预期后，就可以着手替换了