设计 AI on Hi, I'm 5key

Google DESIGN.md 实践：把设计系统写成 AI 能读的 Markdown

Sun, 19 Apr 2026 00:00:00 +0000

TL;DR

用 AI Coding 做产品时最大的问题不是「AI 不会用组件」，而是「AI 不知道什么时候不该用」。

Google 的 DESIGN.md 给出了一个轻量方案：把设计系统写成 Markdown 放进代码仓库，让 AI 每次 Coding 都能读到设计约束。

篇首语

最近这段时间，我一直在用 Claude Code 做一个数据分析系统。

最开始启动的时候，整体的体验还是非常不错的。我只需要写好需求描述文档，准备好各种 API，Claude 很快就能交付一个质量相当不错的结果。

指定好 React + Tailwind + Shadcn 的技术栈，再配合上 Shadcn 提供的 Skill，Claude 在 Coding 上的确非常顶。整个过程中最大的瓶颈其实是自己，写需求的速度赶不上 AI 写代码的速度，最后还是搞得自己非常累 😅

不过这也算不上是问题，真正的问题其实发生在一段时间之后。随着功能不断推进，界面设计的质量开始有些不太可控了。组件错用，样式不统一，交互流程前后不一致，这些问题开始频繁冒出来。

我用的已经是 Shadcn 了，组件库的文档也给了 AI，为什么还是管不住？

DESIGN.md 是什么？

DESIGN.md 是 Google 提出的一种设计系统文档约定：把产品的视觉风格、组件规则、交互约束用 Markdown 写入代码仓库，供 AI 编码助手（如 Claude Code、Cursor、Codex）在每次 Coding 前读取。它相当于写给 AI 的「设计决策指南」，解决传统组件库文档只回答「怎么用」、不回答「什么时候用、什么时候不该用」的问题。

简单说，DESIGN.md 把设计约束变成了 AI 的上下文。配合 CLAUDE.md 等启动加载规则，AI 每次生成界面前都会先读一遍这份设计规范，按其中的 Do’s and Don’ts 来生成代码，这是设计系统在 AI Agent 时代的一个轻量落地方案。

从概念到落地，产品界面的 AI 生成究竟卡在哪儿了？

Mon, 31 Mar 2025 00:00:00 +0000

TL;DR

AI 生成产品界面的 Demo 看起来很惊艳，但真正进入企业业务流程时几乎都「跑不动」。

原因不在 AI 能力本身，而在三道坎：生成质量（结果不稳定）、生成认知（不理解业务逻辑）、生成结构（输出不具确定性）。

设计系统的 AI 化，可能是跨过这条鸿沟的真正路径。

前两天，一位朋友兴奋地告诉我，TA 的机会来了，终于可以在公司的产品设计流程中，尝试用 AI 来进行界面设计的生成了。

说实话，看到这个事儿能有进展我也挺开心的。

几个月前 TA 约了次咖啡，说自己正负责团队里的设计系统，想听听我怎么看，有没有什么方向可以尝试。当时我跟 TA 聊到一个思路：可以尝试着把 AI 与设计系统进行结合，让它来自动完成一些重复性的界面生成。TA 听得挺认真，觉得这个方向挺有意思，回去之后也开始做了不少的功课。

虽然主管当时觉得时机未到，这项工作后来被搁置了，但 TA 并没有放弃。正好最近公司内部架构调整，AI 被提到了战略层面，就顺势把自己平时的研究，做了个演示 Demo 找主管做了一次汇报。

这个 Demo 本质上和现在市面上常见的界面生成方式差不多，都是通过输入一段需求描述，让 AI 自动生成对应的界面。

上图为文章配图案例，与真实业务无关

但不同的是，它生成的结果从布局结构到视觉风格，再到字段内容的业务贴合度，都与他们的产品高度一致。看上去不是那种“拼凑感”很强的概念稿，反倒更像是我们在日常项目评审里会看到、可以直接拿来走流程的设计方案。主管和业务团队看完之后也觉得眼前一亮，如果这个 AI 能力能做到这样的程度，那还是非常值得投入的。

AI 生成产品界面的 Demo 看似可行，真正落地有多难？

从 Demo 来看，效果的确不错。但我们其实都清楚，这只是一个演示 Demo，从“能演示”到“能实现”之间，还有很多的问题需要一个个解决。

大家看到的是一个界面，但它其实是由数十个组件、数个 Pattern 的组合，再叠加上层层的业务逻辑，才拼出来的这个看起来“顺理成章”的结果。要把这么多复杂的因子结合起来交给 AI 来“操作”，并不容易。

“前台”的简单，其实是“后台”的复杂。AI 让界面生成这一步看上去变得轻松了，但真正难的部分，那些规则、逻辑依旧存在，只是被藏在了后面。客观来说，这个 Demo 只是用了更贴合业务的“包装方式”来让公司接受，而其背后需要解决的问题依旧存在，一直都没有变过。

设计师的 2024：边界在消失，2025 该怎么走？

Sun, 22 Dec 2024 00:00:00 +0000

TL;DR

2024 年设计行业经历了两个本质变化：体验设计师向产品设计师演化、AI 在敲打设计的边界。

本文是我对 2024 的复盘和对 2025 的判断，也宣布了我从「OFF UX」专栏到「OFF DESIGN」专栏的品牌升级：从聊体验设计走向跳出设计本身、从产品视角看设计。

2024 年设计行业的本质变化

每到年末，我都会写点东西，总结这一年的起伏。总结，不只是为了回顾，而是为了看清下一步的方向。今年也不例外。

但是，今年的总结似乎又有些不同。2024年的设计行业，已经不再是过去那种按部就班的延续，而是在经历一次显而易见的本质变化。

过去，我们总以为设计行业会一年一年地稳步发展：工具更高效了，流程更完善了，用户需求更复杂了…

然而，事实是，变革早已悄然发生。边界正在被打破，规则正在被改写，连角色的护城河也开始崩塌。

今年，这些变化变得尤为明显，甚至显得近在咫尺。设计行业的边界正在模糊，角色的护城河正在被削弱，连游戏规则本身也在被重新书写。

这种变化不像以往那样渐进，而更像是一次推倒重来的重建。那些曾经熟悉的技能优势、行业规范和职业分工，如今似乎都站在了不确定的边缘。对于设计师来说，这不仅仅是工具的升级，而是一次重新思考自身角色与价值的挑战。

最近，我特别想和大家分享两件事情。它们看起来没有太大关联性，但仔细想想，变化其实早就在我们身边发生了。

01. 体验设计师 → 产品设计师

LinkedIn 上，一位朋友的岗位从「体验设计师」改成了「产品设计师」。他发了一条动态，说这并不是他的个人行为，而是公司的一次整体的调整。

原因很简单，公司希望大家别再沉迷于自己的一亩三分田了，别再只盯着设计细节、搞专业，而是把目光更多地放在业务价值思考上。换句话说，设计师要从「体验设计」转向「业务设计」。

Title 的变化只是表象，背后是公司对设计师期望的彻底重塑。 过去，体验设计师讲究的是“以用户为中心”，可企业的视角可不一样，它更在意的是设计为企业带来的增长和利润。

企业需要的是一个「利润中心」，而不是一个只烧钱、不赚钱的「成本中心」。

设计师的角色也随之发生了根本性的转变。从「体验设计师」到「产品设计师」，意味着设计师不仅要画界面、做优化，还得能想清楚：这个设计能不能提高转化率？能不能直接带来收入？

这背后是企业策略的转变，用更直接的话说，设计师不仅要设计“看得见的好”，还得为“看不见的利润”负责。这不仅仅是一个岗位名称的变化，而是设计行业的一场结构性调整。

02. AI 在敲门，边界在消失

上个月，我开始用 Cursor 和 Windsurf 做一些小工具。刚开始是写写脚本练练手，后来干脆用它们解决工作中的一些琐碎问题。就这样，一不留神，做出了 20 多个工具，这效果实在有点不像话了。更别说更为强大的 Devin，对于设计师来说，我们好像真的不需要工程师了。

过去，设计师不懂代码，这是个绕不过去的槛。很多时候冒出一些好点子都卡在“实现不了”这一步。

但现在，AI 工具把这道门槛给直接拆了。只要你有想法，它就能帮你把想法变成产品。AI 不只是帮你提升效率，更是在改变你的工作边界：设计师可以写代码，工程师可以设计界面，产品经理甚至能用 AI 生成原型。

更关键的是，这种能力不再只是“少数高手的特权”。AI 工具的门槛越来越低，工种之间的界限也越来越模糊。 设计师、工程师、产品经理原本泾渭分明的角色，现在正在被重新定义。

这才是最让人不安的地方。当角色之间的护城河被填平，接下来会发生什么？答案可能比我们想象的要快得多。

看似毫不相关的两件事，实际上指向了同一个方向：设计行业的角色边界正在消失。

一方面，设计师的职责边界正在变化。过去，我们只需要关注用户体验和设计本身，但现在，企业希望我们把目光放得更远一些，思考设计对业务的直接价值。设计师不只是画图的，更是业务的推动者。

另一方面，AI 让我们的能力边界得到了无限扩展。不懂技术？没关系，AI 补上这块短板。曾经因为技术限制而束手束脚的事情，现在只需要一点想法，再交给工具去实现就行了。我们不再只是设计师，我们可以做更多。

不过，别高兴得太早，这件事对所有人都是公平的。设计可以跨界到研发，研发也可以跨界到设计，而产品经理甚至可以抛弃所有人，把问题直接转化为需求，再利用 AI 生成完整的解决方案。

Salesforce 的生成式画布，证明了 AI 在产品界面设计中的可行性？

Mon, 04 Nov 2024 10:34:56 +0000

TL;DR

Salesforce 的 Generative Canvas 给生成式 AI 在产品界面设计中找到了一条可行路径：它不是凭空生成 UI，而是基于成熟的 Lightning Design System 做约束式生成。

这恰好回答了过去两年 AI UI 工具失败的核心原因：缺乏可依赖的设计标准、缺乏对业务逻辑的理解。

设计系统才是 AI 生成 UI 的真正前提。

在上一期的专栏文章中，我们讨论了生成式 AI 在产品界面设计中遇到的问题（详见产品界面的 AI 生成式设计，为什么没人关注了？），以及为什么还无法运用到日常的设计工作中。

生成式 AI 在界面设计中遇到的问题

总的来说，主要体现在两个方面：

01.缺乏可依赖的设计标准

界面设计不仅仅是视觉上的创意，它更需要强有力的逻辑支持。

我们可以明确地定义一只猫或一辆汽车的外观，但对于购物车界面或下单支付流程，缺乏具体而明确的定义标准。在缺少这些明确规则的情况下，生成的 UI 可能只是各种组件的简单堆砌，缺乏逻辑性和良好的用户体验。

相比人类设计师的成果，生成式 AI 产出的界面往往不够稳定，难以达到企业级的需求标准。

02.缺乏对业务逻辑的理解

我们日常的设计工作都是围绕着具体的业务开展的。而如今现有的设计模型都只是通用模型，无法理解具体某个业务的特性和复杂度。这就导致 AI 的生成结果难以满足设计要求，无法直接应用到具体业务生产环节中去。

这两个问题是当前生成式 AI 在界面 UI 设计方面发展的最大挑战。然而，我们也注意到，生成式 AI 在一些特定的业务场景中已经取得了显著的进展。比如，Salesforce 的生成式画布就是一个很好的例子，展示了生成式 AI 在企业环境中应用的潜力。

本期的文章，我们将从 Salesforce 的生成式画布开始，与大家来一起看看当生成式 AI 与业务进行融合后，会给我们的设计带来哪些变化，给用户又带来哪些帮助。

Salesforce Generative Canvas

Generative Canvas（生成式画布）是 Salesforce 今年 10 月发布的一个新功能。它能够在 CRM 系统中基于用户的提示词，结合系统内实时业务数据来动态生成 Dashboard 的界面 UI。

产品界面的 AI 生成式设计，为什么没人关注了？

Mon, 21 Oct 2024 00:00:00 +0000

TL;DR

国内一年前还热闹的 AI 生成式 UI 设计工具，今年明显"冷场"了。

原因有四：AI 生成能力不足以应对真实业务复杂度、设计需求本身的业务深度、国内付费环境差、政策监管影响。

出海寻找新机会的公司，市场表现也并不乐观。

生成式 AI 在界面 UI 领域不是没机会，而是要重新定位场景。

不知大家是否有察觉到，曾经大受关注的界面 UI 的生成式设计，现在似乎有些“冷场”了。

一年多前，国内的几家设计工具平台纷纷砸钱入场搞生成式 AI，准备在产品界面 UI 领域大展拳脚。而一年后的现在，大家都渐渐没了声响，产品界面 UI 貌似已不再是大家在 AI 方面的重点。

这个曾经的热点是被大家抛弃了吗？其实也并不是，只不过是大家都默默地调转方向，转向了海外市场。尝试去寻找商业化和技术发展更大的空间。有的平台选择专注于相对容易入手的“官网”型界面设计，以满足中小企业的基础设计需求；有的则退回到设计助理的定位，专注于通过 AI 来辅助设计师更高效地工作。

为什么会发生这样的变化？

我认为主要有以下几点原因：

01. AI 生成能力尚且不足

虽然每一款产品都给我们展示了一些看上去还很不错的生成界面，但这些“不错”还是仅限于 Demo 中。对于真实的复杂设计需求，如今的生成能力还是不太能达到预期。

如果大家仔细试用过这类工具，就会发现，除了官方展示的几个经过优化的案例外，用户在实际操作中无论如何调整提示词，生成的界面效果都不太好，甚至出现一些非常低级的设计错误。这使得生成式 AI 还是很难参与到真实的工作中。

02. 设计需求的业务复杂度

在真实的设计工作中，我们的设计需求通常会包含很多复杂的业务逻辑和用户流程，而这些都是当前的系统无法理解的。

于是，在真实的业务需求面前，这些通用的 AI 模型基本就派不上用场了。

03. 国内的付费环境不佳

国内的付费环境相较于早几年的确有很明显的改善，但也仅限于刚需类的工具产品。其他的产品在缺少真正核心竞争力的情况下，都经营得非常艰难。

但从企业的视角来看，它并没能直接替代设计师的工作，大家明显对于回报信心不足，因此企业很难愿意为其买单。

主要原因在于生成式 AI 的效果仍不够理想，无法满足真实场景的复杂设计需求。在付费环境不佳的情况下，企业难以看到明确的投资回报，自然很难愿意为之付费。

04. 政策监管影响

随着国家对生成式 AI 技术的监管力度的不断加强，大模型的开发和应用受到了诸多的限制。很多优秀的大模型能力很难被应用到产品中，这样使得产品的能力建设也受到不小的影响。

在这样的大背景下，大家纷纷选择了将产品出海，去探索更多的机会。海外市场尤其是欧美等发达国家，对于新兴设计工具和生成式 AI 的付费意愿显著更高，这为 AI 产品的商业化提供了更大的潜力。同时，海外的政策相对更加宽松，为产品的快速发展提供了更好的条件。

这些公司出海后的表现如何呢？

这些产品在上线初期，都在 ProductHunt 上获得了非常大的曝光，引起了不少用户的兴趣。通过 ProductHunt 的平台，它们迅速积累了一批早期用户和初步的市场关注。

一年过去了，AI design 的进展如何？

Fri, 07 Jun 2024 16:34:56 +0000

TL;DR

一年过去了，AI 在 UI 界面设计上的进展并不如最初想象的快。

原因不在于 AI 不够强，而在于"界面设计"这件事本身的复杂度（业务导向、设计目的性、通用与特定标准、持续迭代）远超模型能直接处理的范围。

未来的发展不是单一替代，而是「平台型」和「定制型」两条路径同时演进。

去年年初 AI 浪潮席卷了整个科技互联网领域，从海外的 UIZard 到国内的即时设计、MasterGo，大家都在不断尝试探索新的模式将 AI Design 与 UI 界面进行结合。我也一直都在密切关注着它对设计行业所带来的变化，特别是在界面设计领域。

时间一转眼已经到了 9 月，尽管前面提到的这几家公司在文生 UI 领域都投入了大量的资源和精力，也获得了一些初步的成果，但就目前的结果来看 AI 在界面设计方面依旧处于一个比较初级的阶段。与此同时大家可能也会发现，这几家公司对这方面的发声也在慢慢变少，整个领域似乎进入了一个相对沉寂的时期，这股热潮似乎在默默的消退。

上周与一位老同事喝咖啡，一起深入探讨了一下当前 AI 设计的能力进展、现实中客户的真实需求以及未来的发展趋势。回来后我又重新整理了一下思路，想在这篇文章中，与大家分享一些我对当前AI 界面设计的思考和想法。

AI Design 在 UI 界面设计的复杂性

与创意设计领域中 Stable Diffusion、MidJourney 飞速进化相比，AI 在 UI 界面设计上的能力进展显然是缓慢的。

创意设计侧重于高概念的构思发散，而界面设计则是深入到具象的业务实现。这也就意味着从产品逻辑到交互模式，都是需要基于深入的用户洞察和对业务逻辑的细致理解。

这种差异化和复杂性为 AI 在界面设计方面的发展带来了巨大的挑战，迫使我们需要做更多深入的研究和基础建设才有可能获得实质性的进步。这里我们可以展开细说一下：

01. 业务导向的多维度设计

UI 界面不仅仅是产品功能的呈现，它还更需要综合用户需求、数据反馈来进行设计从而向达成业务目标前进。

这也就意味着在设计的过程中我们不仅需要关注产品的界面美观和使用体验，还需要考虑如何结合这些背景信息来进行产品的设计。这就让设计变得不那么“纯粹”，也没有足够明确的规律可遵循，更多的依赖于人的判断。

02. 复杂的设计目的性

相较于创意设计，UI 界面设计的目的性会复杂得多。每一个界面都可能需要满足用户不同场景下的多个诉求。

例如，一个电商平台的商品列表页不仅要向用户直观地展示具有吸引力的商品，还需要向用户提供商品的筛选 & 比价、加购 & 凑单以及平台的功能导航等不同场景下的用户使用路径，而这些功能在不同的状态下可能还会存在不同的逻辑。

这些需求的层层叠加会让产品的界面设计变得异常复杂，这就要求设计师在界面的布局和功能分配上进行精细的权衡，确保用户在不同的场景下都能快速找到自己需要的功能模块并完成后续的操作。

03. 通用与特定的设计标准

就像之前在设计系统的话题中我们一直讨论的，不同的行业和具体的业务中，都会存在其特有的设计需求和习惯。比如金融类产品中需要强调正式感和安全性，而社交娱乐型产品则更关注轻松、互动性的交互氛围。

系统级的设计系统为我们提供了普适性的界面设计原则和交互标准，但它无法为特定的业务提供具象的设计指引，更别说体现产品的品牌特性和“人设”了。这也就要求设计师针对于特定的行业、用户进行深入的研究，定义出符合业务的品牌特性。

04. 持续迭代的设计过程

产品的界面设计并不是一次性任务。它需要随着技术的进步、用户需求的变化以及市场环境的演变，来进行界面设计的不断优化和更新。这不仅仅是为了提供更好的产品使用体验，也是为了适应业务的发展和变化，确保产品始终保持竞争力。

由此可见，UI 界面设计是一个复杂且多维度的设计过程，涉及范围大、业务耦合度高，AI 想要在这个领域中真正的占有一席之地是还是非常难的。