上周和一个四人创业团队聊天他们说现在最痛苦的不是写代码也不是画图而是设计师交付完 Figma 后开发者用 AI 生成了一版界面结果两边都觉得对方没把自己的东西当回事。设计师觉得开发没有还原视觉细节开发觉得 AI 生成已经够好了再改成本很高。这不是个例。AI 时代小团队里开发者和 UI/UX 设计师的协作正在从一个“交接问题”变成“谁对最终体验负责”的问题。过去大家默认流程是设计稿、评审、切图、开发、还原边界清晰。现在设计师可以用 AI 批量生成样式开发者可以用 AI 把图片直接转成代码AI 甚至能根据一句描述生成完整布局。工具变强了但模糊地带也变多了。我的核心判断是小团队要真正用好 AI不是让设计师和开发各自用 AI 提升单点效率而是要把协作流程重新设计成一套以 AI 为中间层的反馈系统。换句话说AI 不是替代设计师或开发者而是逼着两边把过去靠“默契”和“口头沟通”的东西变成显性的输入、输出和验收标准。谁先把这件事想清楚谁就能省下大量返工时间。1. 先搞清楚 AI 时代协作问题到底变了没有1.1 表面是工具变了实际是“交接物”变了过去设计师交付的核心是设计稿设计稿里包含布局、颜色、字号、间距、组件状态甚至标注。开发者拿到设计稿后按照标注去还原。这个交接物是双方协作的锚点它越完整协作越顺利。AI 时代这个锚点开始松动。设计师可以用 AI 快速生成多套视觉方案开发可以用 AI 直接从设计稿生成代码甚至后端的同事也能用 AI 生成一个看起来不错的前端页面。于是“设计稿”这个中间产物不再是唯一的事实来源取而代之的是设计系统的 token 定义组件的行为描述页面状态和数据流一条条能复用的提示词换句话说交接物从“一张图”变成了“一套结构化上下文”。如果团队还在用过去的方式只传一张 Figma 截图让开发去定位 AI 生成代码里的具体样式就会非常低效。问题就出在这里工具已经变了但工作流还没有跟上。所以我建议小团队先不要急着买各种 AI 工具先梳理一个问题设计师最终交付的到底是一张图还是一份包含设计意图和约束条件的文档1.2 过去的分工为什么容易产生摩擦先回顾一下非 AI 时代小团队里设计和开发为什么经常打架。最常见的原因是信息损耗。设计师在 Figma 里精心调整了 8px 的间距、一个 hover 状态、一个 loading 态样式但开发在实现时往往只能看到静态稿看不到背后的判断逻辑。开发基于自己对“合理”的理解去实现结果做出来和设计预期不一致。另一个原因是专业语言不同。设计师会说“留白不够透气”“这个按钮层级不够突出”开发者听到的是“具体哪里改间距多少颜色值多少”如果中间没有人能翻译讨论就会变成互相觉得对方不专业。AI 的出现放大了这个摩擦。过去设计师用一套固定组件开发至少能照着做现在设计师用 AI 生成了一版非常规布局开发用 AI 一键生成代码结果生成出了一个“看起来很像但细节没有对齐”的页面。于是两边都觉得自己没错错的是 AI 没有完全理解需求。本质问题是过去的交接物里藏了很多隐性信息比如设计决策背后的用户场景。AI 时代隐性信息不会自动消失反而因为流程变快而更容易被跳过。1.3 AI 工具让边界变模糊在传统团队里设计师负责“视觉”开发负责“实现”。现在这个边界已经模糊了。开发者用 AI 生成一个页面本质上也是在“设计”设计师用 AI 生成代码块本质上也在触碰“实现”。这不一定是坏事。边界模糊意味着更多人可以参与之前自己不擅长的环节小团队尤其受益。但同时也意味着如果没有人对最终结果负责就会出现“大家都在产出版本但没有人在做决策”的局面。我比较认可的一种处理方式是保持角色分工但把“决策权”重新划清。设计师仍然是视觉体验的负责人开发仍然是技术实现和性能的负责人AI 是双方的协作者而不是裁判。更具体一点设计师要负责定义“为什么长这样”开发要负责定义“怎么高效稳定地实现”而 AI 负责把双方的需求转换成初始版本。2. 从设计稿到代码AI 到底能接管哪一段2.1 设计侧AI 生成 UI 和设计系统现在很多设计工具已经内置了 AI 能力可以基于文本描述生成布局、配色、图标甚至整页 UI。这类工具对早期探索很有价值设计师不需要花 2 小时从空白画布开始而是先生成几个方向再筛选、微调。但这里有一个常见误解AI 生成的 UI 看起来完整实际上缺少“设计约束”。比如 AI 可能生成一套鲜艳的渐变卡片视觉上很抢眼但不满足你们产品的可访问性对比度要求也没有考虑状态变化。如果设计师直接把 AI 结果当作终稿开发再用 AI 照着实现最后出来的产品可能会很好看但用户操作时会有很多细节问题。所以我建议设计团队把 AI 生成当作“前期发散”阶段。具体做法是先用 AI 生成 3 到 5 个视觉方向。再人工筛选并确定一个方向。然后基于选定方向手动整理出关键设计 token例如主色、辅助色、圆角、间距、字体大小。最后把 token 和视觉案例一起交给开发。这一步看起来多了一些工作但在 AI 时代反而更省时间。因为开发侧的 AI 代码生成能力再强也需要明确约束条件否则每次生成都会偏离。2.2 开发侧AI 从设计稿生成代码但离生产还有距离开发侧的场景更直接拿到一张设计图让 AI 生成 HTML/CSS 或 React 组件。很多 AI 编程工具已经能识别图片生成结构不错的代码。对于中后台页面或营销页这个能力已经能节省 50% 以上的初始工作量。但“生成代码”和“可运行代码”之间还差三层状态与交互逻辑。设计稿可能是静态的AI 生成的代码也大概率是静态的但真实页面需要处理 loading、空数据、错误提示、点击反馈、表单校验等状态。这部分 AI 很难从一张图里推断出来。数据层对接。生成出来的组件还需要接入接口、鉴权、路由、权限控制。这些和环境强相关AI 只依赖单张图片无法完成。设计系统一致性。AI 生成的代码会随意使用颜色值、字号、间距不一定符合团队已有的设计系统。 比如团队统一用 CSS 变量--color-primaryAI 生成的代码可能写死#3B82F6。所以一个实用判断是AI 可以生成初始版本但开发者不能把 AI 生成的结果直接推上线。开发者需要把 AI 生成的代码纳入原有的工程规范里比如把颜色值替换成设计 token把组件状态补全再接入数据。2.3 真正适合 AI 接管的环节是“重复转换”而不是“产品判断”如果让我用一个词概括 AI 在设计与开发之间的价值那就是“转换”。它能高效完成从设计 token 到 CSS 变量、从组件描述到基础代码、从视觉稿到 HTML 结构这类转换任务。更适合 AI 接管的环节通常具备三个特征输入和输出都是结构化的比如设计 token、JSON、CSS。规则相对明确比如命名规范、间距倍数、状态后缀。重复度高比如批量生成表单页、列表页。不适合 AI 接管的环节是“产品判断”。比如这个页面是否满足用户目标这个按钮放在这里是否会分散注意力这个表单到底该分几步这类问题需要人来决策不取决于 AI 生成的代码多快。如果小团队希望建立稳定协作流程最好先盘点一遍团队里有多少任务是“重复转换”并把它们交给 AI再把“产品判断”留到人工阶段。这个区分越清晰AI 带来的效能提升就越可预测。3. 小团队协作的四个关键动作3.1 建立单一事实源设计稿、组件库和代码库怎么对齐AI 时代最怕的是同一个组件有多个版本。设计师在自己的文件里维护一份规范开发在代码仓库里维护一份AI 生成时又可能产生第三份。小团队没有专门资源去维护三份同步所以必须建立单一事实源。我的建议是这样设计系统以代码仓库中的 token 和组件实现为准。设计师在 Figma 中使用同一套 token 的插件或链接而不是自己维护一套颜色值。AI 生成代码时需要提供当前项目已有的 token 定义作为上下文。每次组件或 token 修改都要同步到设计工具和开发仓库的文档中。可以先用一个简单的表格记录当前协作的事实源对象唯一事实来源维护者颜色、间距、字号代码仓库中的 design-token 文件开发者组件行为与使用场景组件文档MDX 或 Markdown设计师与开发者共同维护页面整体布局Figma 设计稿设计师业务状态与交互逻辑产品需求文档或 Issue 描述产品经理与开发者共同维护一旦每类信息有了明确归属AI 就能更准确地被使用。否则AI 只是一个“更快的生成器”还会放大混乱。3.2 让设计师参与“AI 提示词”的制定而不是只交付静态图很多小团队现在让开发用 AI 工具读取设计稿生成代码。但如果设计师只发一张图开发把它喂给 AIAI 生成的代码往往不够准确。问题在于图片没有表达出设计背后的约束。更有效的方法是设计师在交付设计稿时同时附上一份“设计意图描述”。这份描述可以很短但必须包含页面对应什么用户场景。不同屏幕尺寸下布局如何变化。哪些状态必须保留。哪些视觉风格是硬性约束哪些可以灵活处理。例如一个表单页的设计意图描述可以这样写这是一个倒计时抽奖活动的报名表单。移动端优先操作按钮始终在视口底部保证单手操作。 展示字段按优先级排列手机号、姓名、城市。 提交成功后显示成功态卡片失败时保留用户输入并在按钮上方显示错误提示。 视觉上使用品牌主色 #FF6A00圆角 12px卡片间距 16px。开发拿到这个描述后再结合设计图去生成代码AI 输出的结果会贴近很多。而且设计师参与提示词制定还有一个好处它能倒逼设计师把“感觉”翻译成“规则”这对设计系统和后续维护都是加分项。3.3 开发者在 AI 生成代码后要负责“设计验收”过去设计稿到开发的验收通常由设计师来做。但 AI 生成代码后一些细节问题会大量出现比如颜色被写死、间距不统一、 hover 状态缺失。如果等到设计师在看已经上线的页面时才发现返工成本很高。我建议小团队把设计验收前置到开发阶段。开发者在拿到 AI 生成代码后要先做一轮“设计还原检查”而不是直接合并代码。检查清单可以包含这几项颜色是否使用了设计 token而不是写死的十六进制值。间距是否符合设计稿的 4px 或 8px 基准。按钮、输入框、卡片是否有定义 hover、active、focus、disabled 状态。页面在 375px、768px、1440px 宽度下是否不破版。字体大小、行高是否落在设计系统范围内。这件事不需要很复杂只要在代码 review 的模板里多加一个“设计验收”复选框。它会把很多问题提前吃掉而不是留到设计师和开发者互相拉扯时才处理。3.4 用版本管理和评论机制替代“口头同步”小团队最大的敌人不是技术而是“口头同步”。设计稿更新了一个按钮位置开发在聊天群里看到但没来得及改AI 重新生成了一版代码保存在本地没有提交仓库设计师对某个样式有意见直接在会议里说了但没有留下记录。AI 时代流程更快这些临时信息更容易被漏掉。所以我的建议是所有设计变更和协作反馈都尽量落到可追踪的地方。设计变更在 Figma 或设计文件里留下版本说明让开发者知道这一版改了什么。代码变更通过 PR 提交附带设计稿链接和实现说明。样式反馈在组件库或设计系统仓库中提 issue而不是在聊天里描述。AI 生成结果保存为可复现的 prompt 和输出样例方便回溯。这不是为了让流程变得繁琐而是因为 AI 生成的版本足够多以后团队必须能回答一个问题当前线上版本对应的是哪一版设计、哪一版代码、哪一条提示词生成的。如果没有版本管理排查问题时所有环节都会变成问号。4. 在真实项目里跑通一条最小协作流程4.1 准备阶段确定设计系统与组件边界不要一开始就在整个项目里铺开 AI 协作。更稳妥的方式是挑一个中后台页面或一个 MVP 功能跑通一条最小协作流程。准备阶段建议做三件事梳理当前项目已经有的设计 token包括颜色、字号、间距、圆角、阴影。确认组件边界哪些是基础组件按钮、输入框、卡片哪些是页面级组件表单页、列表页、详情页。约定 AI 生成的代码要放置到哪里通常是在业务页面目录中基础组件不直接用 AI 生成除非是一次性原型。如果项目还没有设计 token可以先花半天时间从当前页面上抽取一份“临时 token 清单”。这个清单不追求完整但必须覆盖主色、辅助色、文本色、主字体、间距基础单位、圆角基础值。这样 AI 生成时就有约束。可以用一个简单模板{ colors: { primary: #FF6A00, text: #1A1A1A, background: #FFFFFF, border: #E5E5E5 }, spacing: { base: 8, cardPadding: 16 }, radius: { card: 12, button: 8 } }这个 JSON 可以作为 AI 提示词的一部分输入让生成的代码尽量遵守现有规范。4.2 从设计稿到可运行页面一个通用流程当准备完成后一个常见的协作流程可以这样定设计师输出设计稿并附上设计意图描述。开发者把设计稿截图和设计意图描述一起发给 AI生成页面级代码。开发者检查生成结果主要是样式 token、布局和状态是否完整。开发者把 AI 生成代码接入项目的数据层、路由和权限逻辑。设计师在浏览器里查看已实现页面给出反馈。开发者根据反馈迭代同时把反馈中涉及的设计规范更新到项目文档里。这种流程下AI 承担的是“第一版生成器”的角色节省的是从空白页面到完整结构的时间。但它不是终局流程因为真实项目还有数据、交互和异常状态。4.3 常见坑样式漂移、上下文丢失、视觉还原度不足实际用下来最容易遇到三个坑。第一个是样式漂移。AI 在第一次生成时通常能够遵循给定的 token但在后续“帮我改一下这个按钮”的增量修改中AI 可能只改按钮本身却把附近的间距和文字样式也带跑偏了。原因是模型只关注局部请求没有全局上下文。解决办法是把设计 token 和基础组件文档一直放在提示词里即使是在局部修改时也不省略。第二个是上下文丢失。AI 对话窗口能保留的信息有限。如果你们连续讨论了很多轮AI 很可能忘记原始的页面目标和设计约束。所以我建议不要在同一个对话里无限堆需求而是每完成一个独立页面或独立组件就开一个新对话并把核心设计上下文重新粘贴进去。第三个是视觉还原度不足。AI 生成的代码和设计稿相比往往在圆角、阴影、字体间距等细节上有偏差。这不是 AI 能力不行而是设计稿里的信息密度太高模型很难从一张图里完整提取。对策是不要只给一张全屏图还要给出关键局部的截图和说明。比如按钮的 hover 状态、列表的间距、空数据的展示。4.4 排查链路先看数据再看样式最后看逻辑当页面出现问题团队不要一上来就怪 AI。建议按照固定链路排查先确认使用的设计稿版本是否正确。很多时候是设计师更新了图但开发还用的是旧版。再检查生成的代码是否使用了设计 token。如果颜色写死大概率是提示词里没有提供 token 清单。然后看组件在不同宽度下是否正常。如果只在某个断点破版很可能需要单独的媒体查询。最后看交互状态和业务逻辑。样式对了但点击没反应那就是状态层没有接好和设计还原无关。这个排查顺序能帮助团队快速定位问题在哪一层。如果一上来就纠结“AI 生成得不准确”往往会漏掉真正的问题。5. 哪些场景适合 AI 协作哪些还是要人盯5.1 适合中后台表单、MVP 页面、设计系统维护、组件版本迁移从我的经验看下面几类场景最能在 AI 协作中受益。中后台表单是典型代表。它的布局规则相对固定无非是标签、输入框、校验、提交。AI 能很快生成一版接近需求的代码开发者只需要改字段配置和提交逻辑。MVP 页面也适合。创业团队想快速验证一个概念不需要像素级还原但需要把前后端串起来。AI 生成页面代码开发者接入数据一天内就能跑通一个原型。设计系统维护同样值得用 AI。比如把旧的 antd 主题改成自定义主题把散落页面的颜色统一成新的 token。这类工作重复度高AI 可以批量处理。组件版本迁移也是好场景。比如设计规范里把圆角从 4px 改成 8px全站影响几十个组件AI 可以基于 token 替换快速完成人工只需要 review 异常情况。5.2 不适合强品牌调性、复杂动效、无障碍细节、高风险交互有些场景不适合让 AI 做最终决策尤其是强品牌调性页面。品牌页面往往依赖设计师对目标用户的深刻理解AI 生成的“好看”可能只是平均水平不能代表品牌个性。复杂动效也不适合。AI 能生成 CSS 动画但一个微交互的物理曲线、时序、触发条件需要设计师和开发者紧密配合AI 目前还很难理解“这个动效要传达什么感觉”。无障碍细节是容易被忽略的重灾区。AI 生成的代码可能忽略了键盘导航、focus 状态、屏幕阅读器标签。小团队一般没有专业无障碍团队所以这部分必须有人工检查尤其是面向公众用户的产品。高风险交互也不适合全自动。比如支付流程、删除确认、权限设置这些页面的交互文案、顺序、误操作保护都需要人工仔细推敲。AI 可以生成初稿但必须经过严格的代码 review 和测试。5.3 边界判断如果一次修改涉及多变数先别急着全自动一个比较实用的判断标准是如果这次修改只涉及“单一维度”例如把全站主色从绿色改成蓝色可以放心让 AI 批量处理如果这次修改同时涉及布局、文案、交互、视觉层级还要适应多种用户状态那就不要全自动。AI 擅长的是在约束明确的情况下快速生成而不是在模糊目标里做创造性决策。团队里需要有人先定义清楚“这次修改属于设计升级、功能新增、还是策略调整”再决定 AI 参与的程度。另外无论 AI 参与多深最终上线前都建议做一次人工验收。这不是不信任 AI而是确保任何由 AI 引入的细节偏差都能被捕获。6. 把协作经验沉淀成团队可复用的框架6.1 极简协作协议输入、输出、验收标准与其每次都靠开会和聊天对齐不如沉淀一个极简协作协议。它不需要很长只需要回答三句话谁给谁什么产出什么怎么算完成。我用过的一个模板是这样的角色输入输出验收标准设计师用户需求、竞品分析设计稿 设计意图描述 token 清单开发者能够基于输入生成不偏离视觉风格的首版代码开发者设计稿 设计意图描述 工程上下文可运行的页面代码 PR 说明页面在主流分辨率下视觉还原度达标状态完整无样式写死AI结构化的设计上下文初始代码或视觉方案输出符合提示词中的约束允许人工修正这个协议最好贴在每个项目的 README 里并写成一个可以直接复制的提示词模板。比如“PR 描述模板”里强制要求填写关联设计稿链接、使用的 token、设计意图描述、AI 生成部分与人工修改部分。6.2 用“设计到代码还原度”作为检查指标团队可以约定一个“设计还原度”检查指标不一定要非常严格但至少要有统一标准。我一般会从五个维度检查色彩是否使用了设计 token和设计稿色值是否一致。间距是否遵循 4px/8px 基准卡片间距、输入框高度是否符合设计稿。字体字号、行高、字重是否匹配。状态按钮、链接、输入框是否有 hover、focus、active、disabled。响应式在几个常见宽度下布局是否不破版。每一项可以打“通过、略有偏差、不通过”。当偏差比较多时团队就暂停 AI 生成回过头补充设计意图描述或 token 清单。这个指标不仅用于验收也能反过来指导 AI 提示词怎么写。如果连续两周发现“间距”问题最多说明提示词里的“间距遵循 8px 基准”没有写清楚下次生成前就要单独强调。6.3 定期复盘哪些 AI 生成内容省力哪些反而增加返工每两到三周团队可以花半小时做一次 AI 协作复盘。不用复盘所有细节只回答三个问题本周哪些页面或组件用 AI 生成后几乎没有返工原因是提示词清晰、设计系统成熟还是场景简单。哪些任务看起来用了 AI但实际返工更严重原因往往是目标模糊、缺少设计 token、或 AI 输出太泛化。哪些环节应该改用更结构化的人工流程比如复杂交互页面也许一开始就不该让 AI 直接生成完整页面。通过复盘团队能逐步建立一张“适合用 AI / 不适合用 AI”的任务清单。这张清单比任何工具都重要因为它包含你们自己的项目特征。6.4 小团队的长期路径从工具链到工作流最后想说的是小团队不需要一步到位建设复杂的 AI 工作流。更合理的路径是先用 AI 生成一个简单页面跑通从设计到代码的基础链路。积累一批提示词模板和设计 token 清单让 AI 输出更稳定。在真实项目中验证效果同时建立设计还原度检查和 PR 模板。遇到批量替换、组件迁移等重复任务时再逐步扩大 AI 使用范围。最后形成一套属于你们团队的协作流程而不是盲目模仿别的团队。这个过程不需要一个专门负责人只要设计师和开发者都愿意把“输入写清楚”当成重要工作AI 带来的收益就会越来越明显。AI 时代最有价值的能力可能不是会用某个模型也不是能写出一段复杂提示词而是把团队里原本模糊的协作关系变成一套清晰、可迭代、让 AI 也能参与的协议。小团队的优势在于人少、沟通路径短更容易改变流程。抓住这个窗口先把前面提到的单一事实源、设计意图描述、AI 生成后的验收跑通你们的协作就会比大多数团队更顺滑。 AI时代小团队设计与开发协作：从设计稿到代码的流程重构
上周和一个四人创业团队聊天他们说现在最痛苦的不是写代码也不是画图而是设计师交付完 Figma 后开发者用 AI 生成了一版界面结果两边都觉得对方没把自己的东西当回事。设计师觉得开发没有还原视觉细节开发觉得 AI 生成已经够好了再改成本很高。这不是个例。AI 时代小团队里开发者和 UI/UX 设计师的协作正在从一个“交接问题”变成“谁对最终体验负责”的问题。过去大家默认流程是设计稿、评审、切图、开发、还原边界清晰。现在设计师可以用 AI 批量生成样式开发者可以用 AI 把图片直接转成代码AI 甚至能根据一句描述生成完整布局。工具变强了但模糊地带也变多了。我的核心判断是小团队要真正用好 AI不是让设计师和开发各自用 AI 提升单点效率而是要把协作流程重新设计成一套以 AI 为中间层的反馈系统。换句话说AI 不是替代设计师或开发者而是逼着两边把过去靠“默契”和“口头沟通”的东西变成显性的输入、输出和验收标准。谁先把这件事想清楚谁就能省下大量返工时间。1. 先搞清楚 AI 时代协作问题到底变了没有1.1 表面是工具变了实际是“交接物”变了过去设计师交付的核心是设计稿设计稿里包含布局、颜色、字号、间距、组件状态甚至标注。开发者拿到设计稿后按照标注去还原。这个交接物是双方协作的锚点它越完整协作越顺利。AI 时代这个锚点开始松动。设计师可以用 AI 快速生成多套视觉方案开发可以用 AI 直接从设计稿生成代码甚至后端的同事也能用 AI 生成一个看起来不错的前端页面。于是“设计稿”这个中间产物不再是唯一的事实来源取而代之的是设计系统的 token 定义组件的行为描述页面状态和数据流一条条能复用的提示词换句话说交接物从“一张图”变成了“一套结构化上下文”。如果团队还在用过去的方式只传一张 Figma 截图让开发去定位 AI 生成代码里的具体样式就会非常低效。问题就出在这里工具已经变了但工作流还没有跟上。所以我建议小团队先不要急着买各种 AI 工具先梳理一个问题设计师最终交付的到底是一张图还是一份包含设计意图和约束条件的文档1.2 过去的分工为什么容易产生摩擦先回顾一下非 AI 时代小团队里设计和开发为什么经常打架。最常见的原因是信息损耗。设计师在 Figma 里精心调整了 8px 的间距、一个 hover 状态、一个 loading 态样式但开发在实现时往往只能看到静态稿看不到背后的判断逻辑。开发基于自己对“合理”的理解去实现结果做出来和设计预期不一致。另一个原因是专业语言不同。设计师会说“留白不够透气”“这个按钮层级不够突出”开发者听到的是“具体哪里改间距多少颜色值多少”如果中间没有人能翻译讨论就会变成互相觉得对方不专业。AI 的出现放大了这个摩擦。过去设计师用一套固定组件开发至少能照着做现在设计师用 AI 生成了一版非常规布局开发用 AI 一键生成代码结果生成出了一个“看起来很像但细节没有对齐”的页面。于是两边都觉得自己没错错的是 AI 没有完全理解需求。本质问题是过去的交接物里藏了很多隐性信息比如设计决策背后的用户场景。AI 时代隐性信息不会自动消失反而因为流程变快而更容易被跳过。1.3 AI 工具让边界变模糊在传统团队里设计师负责“视觉”开发负责“实现”。现在这个边界已经模糊了。开发者用 AI 生成一个页面本质上也是在“设计”设计师用 AI 生成代码块本质上也在触碰“实现”。这不一定是坏事。边界模糊意味着更多人可以参与之前自己不擅长的环节小团队尤其受益。但同时也意味着如果没有人对最终结果负责就会出现“大家都在产出版本但没有人在做决策”的局面。我比较认可的一种处理方式是保持角色分工但把“决策权”重新划清。设计师仍然是视觉体验的负责人开发仍然是技术实现和性能的负责人AI 是双方的协作者而不是裁判。更具体一点设计师要负责定义“为什么长这样”开发要负责定义“怎么高效稳定地实现”而 AI 负责把双方的需求转换成初始版本。2. 从设计稿到代码AI 到底能接管哪一段2.1 设计侧AI 生成 UI 和设计系统现在很多设计工具已经内置了 AI 能力可以基于文本描述生成布局、配色、图标甚至整页 UI。这类工具对早期探索很有价值设计师不需要花 2 小时从空白画布开始而是先生成几个方向再筛选、微调。但这里有一个常见误解AI 生成的 UI 看起来完整实际上缺少“设计约束”。比如 AI 可能生成一套鲜艳的渐变卡片视觉上很抢眼但不满足你们产品的可访问性对比度要求也没有考虑状态变化。如果设计师直接把 AI 结果当作终稿开发再用 AI 照着实现最后出来的产品可能会很好看但用户操作时会有很多细节问题。所以我建议设计团队把 AI 生成当作“前期发散”阶段。具体做法是先用 AI 生成 3 到 5 个视觉方向。再人工筛选并确定一个方向。然后基于选定方向手动整理出关键设计 token例如主色、辅助色、圆角、间距、字体大小。最后把 token 和视觉案例一起交给开发。这一步看起来多了一些工作但在 AI 时代反而更省时间。因为开发侧的 AI 代码生成能力再强也需要明确约束条件否则每次生成都会偏离。2.2 开发侧AI 从设计稿生成代码但离生产还有距离开发侧的场景更直接拿到一张设计图让 AI 生成 HTML/CSS 或 React 组件。很多 AI 编程工具已经能识别图片生成结构不错的代码。对于中后台页面或营销页这个能力已经能节省 50% 以上的初始工作量。但“生成代码”和“可运行代码”之间还差三层状态与交互逻辑。设计稿可能是静态的AI 生成的代码也大概率是静态的但真实页面需要处理 loading、空数据、错误提示、点击反馈、表单校验等状态。这部分 AI 很难从一张图里推断出来。数据层对接。生成出来的组件还需要接入接口、鉴权、路由、权限控制。这些和环境强相关AI 只依赖单张图片无法完成。设计系统一致性。AI 生成的代码会随意使用颜色值、字号、间距不一定符合团队已有的设计系统。 比如团队统一用 CSS 变量--color-primaryAI 生成的代码可能写死#3B82F6。所以一个实用判断是AI 可以生成初始版本但开发者不能把 AI 生成的结果直接推上线。开发者需要把 AI 生成的代码纳入原有的工程规范里比如把颜色值替换成设计 token把组件状态补全再接入数据。2.3 真正适合 AI 接管的环节是“重复转换”而不是“产品判断”如果让我用一个词概括 AI 在设计与开发之间的价值那就是“转换”。它能高效完成从设计 token 到 CSS 变量、从组件描述到基础代码、从视觉稿到 HTML 结构这类转换任务。更适合 AI 接管的环节通常具备三个特征输入和输出都是结构化的比如设计 token、JSON、CSS。规则相对明确比如命名规范、间距倍数、状态后缀。重复度高比如批量生成表单页、列表页。不适合 AI 接管的环节是“产品判断”。比如这个页面是否满足用户目标这个按钮放在这里是否会分散注意力这个表单到底该分几步这类问题需要人来决策不取决于 AI 生成的代码多快。如果小团队希望建立稳定协作流程最好先盘点一遍团队里有多少任务是“重复转换”并把它们交给 AI再把“产品判断”留到人工阶段。这个区分越清晰AI 带来的效能提升就越可预测。3. 小团队协作的四个关键动作3.1 建立单一事实源设计稿、组件库和代码库怎么对齐AI 时代最怕的是同一个组件有多个版本。设计师在自己的文件里维护一份规范开发在代码仓库里维护一份AI 生成时又可能产生第三份。小团队没有专门资源去维护三份同步所以必须建立单一事实源。我的建议是这样设计系统以代码仓库中的 token 和组件实现为准。设计师在 Figma 中使用同一套 token 的插件或链接而不是自己维护一套颜色值。AI 生成代码时需要提供当前项目已有的 token 定义作为上下文。每次组件或 token 修改都要同步到设计工具和开发仓库的文档中。可以先用一个简单的表格记录当前协作的事实源对象唯一事实来源维护者颜色、间距、字号代码仓库中的 design-token 文件开发者组件行为与使用场景组件文档MDX 或 Markdown设计师与开发者共同维护页面整体布局Figma 设计稿设计师业务状态与交互逻辑产品需求文档或 Issue 描述产品经理与开发者共同维护一旦每类信息有了明确归属AI 就能更准确地被使用。否则AI 只是一个“更快的生成器”还会放大混乱。3.2 让设计师参与“AI 提示词”的制定而不是只交付静态图很多小团队现在让开发用 AI 工具读取设计稿生成代码。但如果设计师只发一张图开发把它喂给 AIAI 生成的代码往往不够准确。问题在于图片没有表达出设计背后的约束。更有效的方法是设计师在交付设计稿时同时附上一份“设计意图描述”。这份描述可以很短但必须包含页面对应什么用户场景。不同屏幕尺寸下布局如何变化。哪些状态必须保留。哪些视觉风格是硬性约束哪些可以灵活处理。例如一个表单页的设计意图描述可以这样写这是一个倒计时抽奖活动的报名表单。移动端优先操作按钮始终在视口底部保证单手操作。 展示字段按优先级排列手机号、姓名、城市。 提交成功后显示成功态卡片失败时保留用户输入并在按钮上方显示错误提示。 视觉上使用品牌主色 #FF6A00圆角 12px卡片间距 16px。开发拿到这个描述后再结合设计图去生成代码AI 输出的结果会贴近很多。而且设计师参与提示词制定还有一个好处它能倒逼设计师把“感觉”翻译成“规则”这对设计系统和后续维护都是加分项。3.3 开发者在 AI 生成代码后要负责“设计验收”过去设计稿到开发的验收通常由设计师来做。但 AI 生成代码后一些细节问题会大量出现比如颜色被写死、间距不统一、 hover 状态缺失。如果等到设计师在看已经上线的页面时才发现返工成本很高。我建议小团队把设计验收前置到开发阶段。开发者在拿到 AI 生成代码后要先做一轮“设计还原检查”而不是直接合并代码。检查清单可以包含这几项颜色是否使用了设计 token而不是写死的十六进制值。间距是否符合设计稿的 4px 或 8px 基准。按钮、输入框、卡片是否有定义 hover、active、focus、disabled 状态。页面在 375px、768px、1440px 宽度下是否不破版。字体大小、行高是否落在设计系统范围内。这件事不需要很复杂只要在代码 review 的模板里多加一个“设计验收”复选框。它会把很多问题提前吃掉而不是留到设计师和开发者互相拉扯时才处理。3.4 用版本管理和评论机制替代“口头同步”小团队最大的敌人不是技术而是“口头同步”。设计稿更新了一个按钮位置开发在聊天群里看到但没来得及改AI 重新生成了一版代码保存在本地没有提交仓库设计师对某个样式有意见直接在会议里说了但没有留下记录。AI 时代流程更快这些临时信息更容易被漏掉。所以我的建议是所有设计变更和协作反馈都尽量落到可追踪的地方。设计变更在 Figma 或设计文件里留下版本说明让开发者知道这一版改了什么。代码变更通过 PR 提交附带设计稿链接和实现说明。样式反馈在组件库或设计系统仓库中提 issue而不是在聊天里描述。AI 生成结果保存为可复现的 prompt 和输出样例方便回溯。这不是为了让流程变得繁琐而是因为 AI 生成的版本足够多以后团队必须能回答一个问题当前线上版本对应的是哪一版设计、哪一版代码、哪一条提示词生成的。如果没有版本管理排查问题时所有环节都会变成问号。4. 在真实项目里跑通一条最小协作流程4.1 准备阶段确定设计系统与组件边界不要一开始就在整个项目里铺开 AI 协作。更稳妥的方式是挑一个中后台页面或一个 MVP 功能跑通一条最小协作流程。准备阶段建议做三件事梳理当前项目已经有的设计 token包括颜色、字号、间距、圆角、阴影。确认组件边界哪些是基础组件按钮、输入框、卡片哪些是页面级组件表单页、列表页、详情页。约定 AI 生成的代码要放置到哪里通常是在业务页面目录中基础组件不直接用 AI 生成除非是一次性原型。如果项目还没有设计 token可以先花半天时间从当前页面上抽取一份“临时 token 清单”。这个清单不追求完整但必须覆盖主色、辅助色、文本色、主字体、间距基础单位、圆角基础值。这样 AI 生成时就有约束。可以用一个简单模板{ colors: { primary: #FF6A00, text: #1A1A1A, background: #FFFFFF, border: #E5E5E5 }, spacing: { base: 8, cardPadding: 16 }, radius: { card: 12, button: 8 } }这个 JSON 可以作为 AI 提示词的一部分输入让生成的代码尽量遵守现有规范。4.2 从设计稿到可运行页面一个通用流程当准备完成后一个常见的协作流程可以这样定设计师输出设计稿并附上设计意图描述。开发者把设计稿截图和设计意图描述一起发给 AI生成页面级代码。开发者检查生成结果主要是样式 token、布局和状态是否完整。开发者把 AI 生成代码接入项目的数据层、路由和权限逻辑。设计师在浏览器里查看已实现页面给出反馈。开发者根据反馈迭代同时把反馈中涉及的设计规范更新到项目文档里。这种流程下AI 承担的是“第一版生成器”的角色节省的是从空白页面到完整结构的时间。但它不是终局流程因为真实项目还有数据、交互和异常状态。4.3 常见坑样式漂移、上下文丢失、视觉还原度不足实际用下来最容易遇到三个坑。第一个是样式漂移。AI 在第一次生成时通常能够遵循给定的 token但在后续“帮我改一下这个按钮”的增量修改中AI 可能只改按钮本身却把附近的间距和文字样式也带跑偏了。原因是模型只关注局部请求没有全局上下文。解决办法是把设计 token 和基础组件文档一直放在提示词里即使是在局部修改时也不省略。第二个是上下文丢失。AI 对话窗口能保留的信息有限。如果你们连续讨论了很多轮AI 很可能忘记原始的页面目标和设计约束。所以我建议不要在同一个对话里无限堆需求而是每完成一个独立页面或独立组件就开一个新对话并把核心设计上下文重新粘贴进去。第三个是视觉还原度不足。AI 生成的代码和设计稿相比往往在圆角、阴影、字体间距等细节上有偏差。这不是 AI 能力不行而是设计稿里的信息密度太高模型很难从一张图里完整提取。对策是不要只给一张全屏图还要给出关键局部的截图和说明。比如按钮的 hover 状态、列表的间距、空数据的展示。4.4 排查链路先看数据再看样式最后看逻辑当页面出现问题团队不要一上来就怪 AI。建议按照固定链路排查先确认使用的设计稿版本是否正确。很多时候是设计师更新了图但开发还用的是旧版。再检查生成的代码是否使用了设计 token。如果颜色写死大概率是提示词里没有提供 token 清单。然后看组件在不同宽度下是否正常。如果只在某个断点破版很可能需要单独的媒体查询。最后看交互状态和业务逻辑。样式对了但点击没反应那就是状态层没有接好和设计还原无关。这个排查顺序能帮助团队快速定位问题在哪一层。如果一上来就纠结“AI 生成得不准确”往往会漏掉真正的问题。5. 哪些场景适合 AI 协作哪些还是要人盯5.1 适合中后台表单、MVP 页面、设计系统维护、组件版本迁移从我的经验看下面几类场景最能在 AI 协作中受益。中后台表单是典型代表。它的布局规则相对固定无非是标签、输入框、校验、提交。AI 能很快生成一版接近需求的代码开发者只需要改字段配置和提交逻辑。MVP 页面也适合。创业团队想快速验证一个概念不需要像素级还原但需要把前后端串起来。AI 生成页面代码开发者接入数据一天内就能跑通一个原型。设计系统维护同样值得用 AI。比如把旧的 antd 主题改成自定义主题把散落页面的颜色统一成新的 token。这类工作重复度高AI 可以批量处理。组件版本迁移也是好场景。比如设计规范里把圆角从 4px 改成 8px全站影响几十个组件AI 可以基于 token 替换快速完成人工只需要 review 异常情况。5.2 不适合强品牌调性、复杂动效、无障碍细节、高风险交互有些场景不适合让 AI 做最终决策尤其是强品牌调性页面。品牌页面往往依赖设计师对目标用户的深刻理解AI 生成的“好看”可能只是平均水平不能代表品牌个性。复杂动效也不适合。AI 能生成 CSS 动画但一个微交互的物理曲线、时序、触发条件需要设计师和开发者紧密配合AI 目前还很难理解“这个动效要传达什么感觉”。无障碍细节是容易被忽略的重灾区。AI 生成的代码可能忽略了键盘导航、focus 状态、屏幕阅读器标签。小团队一般没有专业无障碍团队所以这部分必须有人工检查尤其是面向公众用户的产品。高风险交互也不适合全自动。比如支付流程、删除确认、权限设置这些页面的交互文案、顺序、误操作保护都需要人工仔细推敲。AI 可以生成初稿但必须经过严格的代码 review 和测试。5.3 边界判断如果一次修改涉及多变数先别急着全自动一个比较实用的判断标准是如果这次修改只涉及“单一维度”例如把全站主色从绿色改成蓝色可以放心让 AI 批量处理如果这次修改同时涉及布局、文案、交互、视觉层级还要适应多种用户状态那就不要全自动。AI 擅长的是在约束明确的情况下快速生成而不是在模糊目标里做创造性决策。团队里需要有人先定义清楚“这次修改属于设计升级、功能新增、还是策略调整”再决定 AI 参与的程度。另外无论 AI 参与多深最终上线前都建议做一次人工验收。这不是不信任 AI而是确保任何由 AI 引入的细节偏差都能被捕获。6. 把协作经验沉淀成团队可复用的框架6.1 极简协作协议输入、输出、验收标准与其每次都靠开会和聊天对齐不如沉淀一个极简协作协议。它不需要很长只需要回答三句话谁给谁什么产出什么怎么算完成。我用过的一个模板是这样的角色输入输出验收标准设计师用户需求、竞品分析设计稿 设计意图描述 token 清单开发者能够基于输入生成不偏离视觉风格的首版代码开发者设计稿 设计意图描述 工程上下文可运行的页面代码 PR 说明页面在主流分辨率下视觉还原度达标状态完整无样式写死AI结构化的设计上下文初始代码或视觉方案输出符合提示词中的约束允许人工修正这个协议最好贴在每个项目的 README 里并写成一个可以直接复制的提示词模板。比如“PR 描述模板”里强制要求填写关联设计稿链接、使用的 token、设计意图描述、AI 生成部分与人工修改部分。6.2 用“设计到代码还原度”作为检查指标团队可以约定一个“设计还原度”检查指标不一定要非常严格但至少要有统一标准。我一般会从五个维度检查色彩是否使用了设计 token和设计稿色值是否一致。间距是否遵循 4px/8px 基准卡片间距、输入框高度是否符合设计稿。字体字号、行高、字重是否匹配。状态按钮、链接、输入框是否有 hover、focus、active、disabled。响应式在几个常见宽度下布局是否不破版。每一项可以打“通过、略有偏差、不通过”。当偏差比较多时团队就暂停 AI 生成回过头补充设计意图描述或 token 清单。这个指标不仅用于验收也能反过来指导 AI 提示词怎么写。如果连续两周发现“间距”问题最多说明提示词里的“间距遵循 8px 基准”没有写清楚下次生成前就要单独强调。6.3 定期复盘哪些 AI 生成内容省力哪些反而增加返工每两到三周团队可以花半小时做一次 AI 协作复盘。不用复盘所有细节只回答三个问题本周哪些页面或组件用 AI 生成后几乎没有返工原因是提示词清晰、设计系统成熟还是场景简单。哪些任务看起来用了 AI但实际返工更严重原因往往是目标模糊、缺少设计 token、或 AI 输出太泛化。哪些环节应该改用更结构化的人工流程比如复杂交互页面也许一开始就不该让 AI 直接生成完整页面。通过复盘团队能逐步建立一张“适合用 AI / 不适合用 AI”的任务清单。这张清单比任何工具都重要因为它包含你们自己的项目特征。6.4 小团队的长期路径从工具链到工作流最后想说的是小团队不需要一步到位建设复杂的 AI 工作流。更合理的路径是先用 AI 生成一个简单页面跑通从设计到代码的基础链路。积累一批提示词模板和设计 token 清单让 AI 输出更稳定。在真实项目中验证效果同时建立设计还原度检查和 PR 模板。遇到批量替换、组件迁移等重复任务时再逐步扩大 AI 使用范围。最后形成一套属于你们团队的协作流程而不是盲目模仿别的团队。这个过程不需要一个专门负责人只要设计师和开发者都愿意把“输入写清楚”当成重要工作AI 带来的收益就会越来越明显。AI 时代最有价值的能力可能不是会用某个模型也不是能写出一段复杂提示词而是把团队里原本模糊的协作关系变成一套清晰、可迭代、让 AI 也能参与的协议。小团队的优势在于人少、沟通路径短更容易改变流程。抓住这个窗口先把前面提到的单一事实源、设计意图描述、AI 生成后的验收跑通你们的协作就会比大多数团队更顺滑。