← 返回文章

2026/08/16 · 8 MIN

AI对UX工作流的影响

复杂度并不会消失。设计能做的,是让它在正确的时间、以正确的形态出现。
#AI&UX
Article
2026/08/16

B端设计做了好些年了,没有哪个工具或者概念能给我的工作方式带来这么多改变。如果说变化最多的是什么,那就是累。AI 增强我能力的同时,也让我的工作范围变得更广,工作事项更繁琐。从这点来说,我是很讨厌 AI 的。

具体而言,AI 主要帮我完成的内容包含三部分:分解业务和需求,设计灵感和Review ,以及Coding 。

分解业务和需求

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

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

而在完成一个需求后,我会让 AI 帮我梳理成 MD 文档,存在知识库里,在之后的设计流程中当成上下文来引用。
建议用 Skill 来将需求转为知识库的,例如:


这一阶段,我用 Gemini 或者 Google AI Studio ,以及 Claude。

设计灵感

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

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

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

我一般是这么整理喂给 AI 的知识库:一个总的MD,主要介绍产品的背景,用户群体,解决的问题,以及大致的信息架构和功能等。其他的 MD 则按照功能划分(每个产品都不一样且也看个人习惯)。

这里用的AI还是 Gemini 为主,偶尔用用 Stitch ,我一直认为直接生成设计稿的 AI 思考深度没有生文的 AI 深。Stitch 给的视觉效果还可以,会酌情采纳。

当然 AI 很多时候给的东西我也是不认可的,所以会和他 battle 一下。但是 Gemini 的讨好型人格太容易顺从了,必须给它下达类似“务必诚实”的指令。

AI Review 的阶段,把自己的设计稿和理解扔过去,会得到很多设计细节的补充。比如一些状态,描述等等。

Coding

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

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

比如这是线上情况:

然后调整样式:


通过 Figma MCP 就能还原不少视觉了,对不满意的地方持续的对话就好。同时这一步也建议使用 Skill,可以自己写一个适合自己的,例如:


等组件达到预期,就可以正式替换了

接下来?