半年前，我交给开发团队的是设计稿，加上写得密密麻麻的交互标注。最复杂的一个赛事模块，标注写了一万多字。

现在，我交给他们的是一份场景文档，加一个能点、能跑的 Demo。

我在一家创业公司做 UX 设计师，一个人负责产品方向、交互和界面。在这之前，我做了近 20 年体验设计，在一家招聘平台带过 19 人的设计团队。这半年，我用 AI 重新搭了一套和开发配合的方式。这篇记录一下是怎么变过来的，走过哪些弯路，以及哪些事 AI 替代不了。

一、标注写得越长，问题越多

规则简单的页面，设计稿加几句说明就够了。麻烦的是规则重的模块：多个角色、多种赛制、各种例外情况。

静态的设计稿只能画出“某一刻长什么样”，画不出“点了之后会发生什么”。于是只能靠标注补，标注越写越长，开发读起来越吃力。

我开始想：能不能直接给开发一个“会动的”东西？

二、先走了一段弯路：用 Figma Make 从零生成

今年 4 月，我开始用 Figma Make。在那之前，它生成的界面不太好用，4 月以后才基本可用。

我的做法是：把需求文档和手绘稿截图一起喂给它，再写一份结构化的英文提示词，把设计规范写成硬约束：只用黑白灰、8pt 栅格、页面边距 16px、圆角不超过 13px、只用线性图标。

效果比预想的好，但早期生成的界面达不到要求，我经常要回到 Figma 里手动改。它更适合把一个想法快速变成能看的样子；真正拿去和开发配合，后来发现还是另一种方式更顺。

现在我只用 Figma Make 快速验证创意。

三、现在的工作流：ChatGPT 想清楚，Cursor 做出来

4 月起，我在线下推动开发团队优先使用 Cursor；6 月起我自己也用上了，慢慢固定成了现在的分工。

ChatGPT 负责日常工作：分析数据，以及把场景文档写清楚。

我不再写需求文档，而是写场景文档。需求文档罗列“要做哪些功能”；场景文档描述用户旅程里实际的痛点：用户走到哪一步、卡在哪里、为什么卡。先把痛点写清楚，再决定做什么。

Cursor 负责做出来：在 Cursor 里调用 Opus 5.5 模型，在团队已经认可的设计稿基础上，把场景做成可交互的 Demo。

为什么在已有设计稿上做，而不是让 AI 从零生成？三个原因：

  1. 起点是大家已经认可的设计，评审时不用推倒重来。
  2. 先锁定一套 Design Token（颜色、字号、间距），Demo 和最终上线的样子一致。
  3. 产出就是网页和代码，开发能直接点、直接看，不用再“翻译”设计稿。

整个流程是五步：

  1. 用 ChatGPT 分析数据，找到用户旅程里的痛点
  2. 写成场景文档
  3. 在 Cursor 里用 Opus 5.5 做出 Demo
  4. 开会评审，大家点着 Demo 讨论
  5. 开发团队接手，做成正式功能上线

新想法、新需求都按这个流程走。评审会上不再是对着图猜“这里点了会怎样”，而是直接点一遍。

四、AI 做得出来，但“合理”要人来判断

用 AI 做 Demo，最容易被忽略的风险是：它会非常认真地做出一个不合理的东西。

举个例子。我让 AI 对照线上已有的一个赛事记分模块重做，它把旧版本的一个冲突原样搬了过来：比赛已经分出胜负，却没法结束。AI 不会主动告诉你“这里不对”，它只会照着做。

所以我给自己定了几条规矩，单独写成一份“合理性修正”：

  • 不照搬旧版本里的冲突，发现了就改，并写明为什么改
  • 不虚构数据，比如 Demo 里不编造选手的个人技术统计
  • 不假装有后台：Demo 里没有真正的权限校验，就不做出“像是校验过”的样子，免得开发误以为已经实现了

另一个办法是把“验收”做成清单。规则越复杂，越不能靠肉眼检查。我会把每一条功能写进一份功能覆盖清单，再配上自动检查的脚本。

一句话总结我的分工：我定规格，AI 写代码，我验收。

五、半年后的变化

  • 文档变了：不写需求文档，写场景文档。
  • 交付物变了：从“设计稿加标注”，变成“场景文档加能跑的 Demo”。
  • 全站做成了高保真的可交互 Demo，一个文件就能离线演示，给别人看不用装任何东西。

六、几点体会

  1. 先写清楚痛点，再让 AI 做。AI 做得很快，做什么得人先想清楚。
  2. 别从零生成。从团队已经认可的设计稿起步，AI 才是在帮你，而不是在另起炉灶。
  3. 验收比生成难。生成只要几分钟，判断它对不对才是真正花时间的地方。
  4. Demo 不是正式产品。权限、数据、性能这些，仍然是开发团队的专业；Demo 只负责把“要做成什么样”讲清楚。
  5. 设计师的价值没有变小，只是换了位置：从“画得好”，挪到了“判断得准、讲得清”。

AI 让“做出来”越来越容易，让人一眼看懂才更稀缺。这半年，我越来越确定这一点。