为什么 AI 需要 UX 开发者

Source: Dev.to

UX 开发者角色

UX 开发者的角色一直很难向普通人解释。“那你是设计东西的？”不完全是。
“那你是写代码的？”算是。多年来，坐在设计与工程之间的人们一直在争取一个本不为他们而设的席位。随后 AI 出现，彻底颠覆了整个局面。

成为 UX 开发者自带身份危机。你对设计团队来说不够设计师，对工程团队来说又不够工程师。你的头衔每两年就会随 LinkedIn 上的热门趋势而更换——“UI developer”、 “design technologist”、 “frontend engineer”。工作内容却保持不变：在说不同语言的两组之间进行翻译，并确保最终构建的东西真正符合原本的意图。

在我大部分职业生涯中，这种翻译工作一直被低估。组织不知道该把我们放在哪里，于是不断重组，直到把问题推给别人。我们会在部门之间被调来调去，项目启动时被遗漏，规划时被跳过。随后有人会要求我们证明自己的角色是否必要，因为“设计师只要交付规范，工程师就能直接实现”。当然可以。你也可以把足球扔向别人的脸，然后说那是一次传球。

AI 实际需要的是什么

AI 工具可以以在三年前看来荒唐的速度生成 UI 代码。你只需用普通英语描述一个组件，几秒钟后就能得到可用的代码。这令人印象深刻，而且只会越来越好。

但生成代码并不是难点。难点在于生成正确的代码——遵循你的设计系统 API 约定、使用正确的 token 而不是硬编码值、符合你的可访问性模式，并且能够融入团队多年构建的架构中。除非有人教会它，否则 AI 并不知道这些。

这个“有人”就是已经同时了解两方面的人：设计团队为何选择特定的间距尺度，以及工程团队如何实现它。能够看一眼 AI 生成的输出，就立刻发现它使用了错误的组件变体或忽略了正好为此用例准备的语义 token 的人。

这就是 UX 开发者。也就是桥梁角色。是你们组织仍然不知道该把它放在哪个位置的那个人。

新的杠杆

这很惊人的是，UX 开发者的日常工作——编写组件文档、定义 token 分类法、以及构建使用指南——现在直接为 AI 系统提供输入。你编写的文档成为了上下文窗口。你设计的组件 API 成为约束，使生成的代码保持在正轨上。那些你以 token 形式编码的设计决策？那就是 AI 用来做出选择的词汇表。

这并非理论上的假设。我一直在构建 MCP 服务器和 Claude Code 技能，使 AI 工具能够直接与我们的设计系统交互。整个过程是一种桥接工作。你必须对设计意图有足够深入的理解，以便将其编码为规则；同时也要对工程架构有足够的了解，才能让这些规则在开发工作流中真正有用。去掉任意一方，整个体系都会崩溃。

UX 开发者的角色已经从“可有可无”变成了倍增器。当 AI 能生成代码却无法做出判断时，提供判断的人就在掌舵。你并不是在拖慢进度；恰恰相反，你是输出能够真正可用的关键原因。

踏入其中

我写这篇并不是在庆祝胜利；显然这里仍然非常混乱。这个角色仍然面临它一贯的挑战：模糊性、组织结构中的特殊情况以及不断的解释工作。不过，杠杆已经改变。如果你花了多年时间构建设计与工程之间的联系，你就拥有了让 AI 不仅仅是快速，而是有用的精准技能组合。

• 对其承担所有权。
• 定义 AI 与你的系统如何交互。
• 创建作为训练上下文的文档。
• 开发确保生成输出符合团队标准的工具。

原来我们一直在搭建这座桥。唯一改变的是，现在包括机器人在内的所有人都必须跨过它。