夜雨聆风过去一年，我陆续和一些 AI 创业团队合作，也自己做过几个小的 AI 项目。最近加入了一家做 AI Agent 的公司，角色偏设计工程师。相比之前大部分时间在大厂做设计，这段经历给我一个很明显的感受：在 AI native 的团队里，设计工作的方式和边界变得不太一样。
最根本的变化是，你可以通过 AI 轻松地访问代码仓库、用户行为数据、用户反馈数据、产品指标等几乎所有数据。
这会带来一些很具体的变化：UX/UI 的产物会变，和工程协作的方式会变，用户研究能看到的证据也会变。
这篇文章不是想做什么行业定论，也不是说大厂那套方法已经失效了。更像是一份工作手记：把自己最近看到的、踩到的、感受到的变化整理出来，聊聊在一个 AI native 的团队里，做 UX/UI、做用户研究，会有什么不一样。
UXUI设计
在 AI native 的团队里，做 UXUI 最大的变化是：离真实产品更近了。
场景1：从0到1的设计
从 0 到 1 做新功能时，很多场景下完全可以跳过 Figma，直接在代码仓库里拉一个分支，做一个可交互原型。
这个原型不一定要接真实数据，也不一定要写得很优雅。它可以只是一个 demo 页面，甚至是一个大几千行的临时代码页面。页面里的信息、功能、状态都可以先 mock 出来，重点是让团队能真正点进去看、操作一下、感受一下流程。
这种方式的好处是，讨论会更具体。大家看到的不再是一张静态图，而是一个接近真实产品的东西。交互是否顺、信息是否够、状态切换会不会别扭，很多问题一上手就暴露出来了。
当然，Figma 依然有它的价值。尤其是多方案并行讨论时，Figma 的画布形式仍然很方便。它可以把多个页面、多个流程、多个状态平铺出来，让大家一眼看到整体差异。
场景2：已有模块的重构/改版
做已有模块的重构时，最大的痛点通常是：遍历到底有多少种状态。
一个页面在 Figma 里看起来可能很简单，但真实产品里往往藏着很多状态：空状态、加载状态、错误状态、权限状态、历史数据状态、异常边界状态。传统设计流程里，设计师很容易只看到其中一部分，然后基于不完整的信息做改版。
而代码是 single truth。从代码仓库的最新状态切一个分支出来，在本地遍历真实页面，判断会更扎实。你可以看到线上到底有哪些状态，哪些组件被复用，哪些逻辑是历史遗留，哪些地方改动会影响别的页面。
在这个过程中，ASCII 低保真原型图很好用。它不精致，但很快，特别适合在对话里说明页面布局、模块关系、信息层级和位置变化。
场景3：设计系统维护
设计系统在 AI native 团队里也会变得更动态。
因为改代码、改组件、改页面都太方便了，设计系统不一定要在一开始就被完整定义好。我现在更倾向于先让页面自然生长一段时间，等不同类型的页面逐渐收敛，再去抽象设计规则、设计模式和代码化组件。
这样做的好处是，设计系统不会变成一套脱离业务的规则。它不是先被设计出来，再强行套到产品上，而是从真实页面和真实需求里长出来。
更多有关利用AI搭建设计系统的内容可移步告别手动创建设计系统，利用Cursor高效开发风格统一的高品质UI【源码已开源】
AI时代依旧有价值的原则
虽然工具变了，能做的事情变多了，但一些基本原则没有变。
首先，MVP 的工作原则依然有效。
先低保真，再高保真。 先把问题和结构说清楚，再进入视觉细节。 先用文档、草图、低成本原型验证方向，再投入更多时间做代码和高保真。
AI 会让执行速度变快，但它不会自动帮你判断什么才是当前最值得做的。越是能快速生成，越需要先想清楚目标、约束和取舍。
其次，视觉包装依然重要，但它的重要性不是线性的。
如果一个产品还没达到 60 分，视觉包装的价值可能非常高。因为用户第一眼看到一个不严肃、不可信、不像正规产品的界面，很可能根本不会继续尝试。这个阶段，视觉包装不只是“好不好看”，它直接影响用户愿不愿意相信你。
但从 60 分到 95 分，情况会不一样。此时继续提升视觉细节，带来的边际收益会变小。很多时候，真正影响用户体验的会变成功能是否解决问题、流程是否顺、结果是否可靠。
到了 95 分以上，视觉本身又会重新变得非常重要。这个阶段，视觉不再只是包装，而是体验本身的一部分，会带来溢价。
早些时候，AI 在排版、视觉选择、细节处理上的默认品味还比较差，很容易做出“AI味”很重的东西。但现在 AI 已经明显追上来了。整个行业的审美下限正在被不断抬高。
这对设计师反而提出了更高要求。做出一个 60 分、70 分的界面会越来越容易，但做出真正有辨识度、有气质、没那么模板化的 95 分以上体验，会越来越难。
用户研究
在 AI native 的团队里，做用户研究最大的变化是：离用户现场更近了。
以前在大厂，很多用户信息其实是二手的。比如运营同学转述用户反馈，数分同学拉看板，用研同学输出访谈报告。你看到的往往已经是被别人筛选、压缩、总结过的信息。
很难判断一个结论是怎么来的。用户原话是什么？当时发生了什么？他是真的不会用，还是只是某一步出错了？他说的问题，和他真实行为暴露的问题，是不是同一个问题？
在 AI native 的创业团队里，因为权限更开放，可以直接看很多原始材料。比如用户反馈、报错信息、用户行为轨迹、业务数据、数据库里的真实状态，甚至用户和产品里的 AI 的交互记录。
场景1：从一句用户反馈追到真实链路
用户反馈里经常会出现很模糊的话，比如“这个功能不好用”“结果不对”“我不知道下一步该干嘛”。
如果只看这句话，其实很难判断问题在哪里。它可能是入口太深，可能是文案没讲清楚，可能是流程太长，可能是系统报错，也可能是用户预期本来就和产品能力不匹配。
但如果能看到更多原始证据，就可以继续往前追。不仅看用户说了什么，也要看用户实际做了什么。
可以看这个用户是从哪里进来的，第一次点了什么，在哪一步停住了，有没有反复尝试，有没有遇到报错，后面有没有回来继续用。他说“功能不好用”，但真实情况可能是他根本没找到入口；他说“结果不对”，但真实情况可能是前面的引导让他误以为产品能完成另一类任务。
场景2：把主观反馈和客观行为串起来看
用户反馈很重要，但单看反馈也很容易误判。
有些用户会非常明确地表达不满，但行为上仍然持续使用；有些用户嘴上没说什么，但用了一次就再也没有回来。还有一些问题，在反馈里声音很大，但实际只影响少数高频用户；另一些问题没人主动反馈，但会悄悄卡住大量新用户。
所以更重要的不是单独看某一种材料，而是把几类证据串起来。
比如用户说某个流程复杂，可以同时看完成率、停留时间、报错情况、重复操作、后续留存。这样会更容易判断：这是一个真实影响使用的问题，还是少数用户的表达偏好。
场景3：当证据不够时，可以自己补证据
以前很多时候会卡在一句话上：“有没有这个数据？”
如果没有，就只能靠经验判断，或者等数分同学排期。但在 AI native 的团队里，设计师可以更主动地问：“我要验证这个判断，还缺哪段证据？”
如果缺关键行为数据，可以自己补一个轻量埋点。比如一个入口有没有被点击，一个关键步骤有没有完成，一个新功能上线后有没有被真实使用起来。
如果用户输入太 raw，也可以用 AI 先做一轮打标、聚类，再人工校正。尤其是 AI Agent 类产品里，用户 query 往往很散，但聚起来看，可能会洞察一些反复出现的需求和问题。
AI时代依旧有价值的原则
当然，数据更容易拿到，不代表结论更可靠。
通过 MCP、CLI 读取拿数据，现在确实比以前方便很多。但该清洗还是要清洗，该对口径还是要对，该查来源还是要查。数据本身不准，分析不仅没用，还会产生反作用。
尤其是早期团队，样本通常不大，用户类型也很不稳定。几个重度用户的行为，不一定代表主流用户；一两个特别强烈的反馈，也不一定代表最重要的问题。离现场更近了，但也更容易被单个 case 打动，所以更需要保留一点警惕。
埋点也是一样。早期团队很容易什么都想埋，因为加起来太方便。但如果没人维护，埋点很快会膨胀成一堆没人敢删、没人敢信、也没人说得清的数据。老埋点甚至会在分析时混淆视听。
