AI Persona Generator

这个场景熟悉到有些陈腐：一个小型产品团队有一周时间来验证一个新功能概念，然后才能把它放进路线图。产品经理、设计师和主开发在周一早上有一个时间槽，他们需要从这个时间槽里拿到足够的设计方向，以便在周五做出可信的"做还是不做"决策。

这是关于那个周一的一种方法的故事——具体来说，合成画像如何融入其中，在哪里有帮助，以及在哪里遇到了局限。

周一上午：界定问题空间

正在评估的功能是一个面向 B2B 项目管理工具的使用情况 Dashboard——会向团队领导展示过去 30 天里团队活跃度、瓶颈和产出速度的摘要。

房间里的第一个问题始终是"这是为谁做的？"团队有一个大致的用户模型：50 到 500 人公司的团队领导，主要在专业服务和软件开发领域。

但"200人公司的团队领导"不是一个有用的设计目标，它是一个类别。为类别设计会产出对谁都不特别有用的设计。

所以在打开 Figma 之前，产品经理打开了 AI Persona Generator，花 20 分钟配置了一个 Schema：

{
  "personaCount": 12,
  "projectDescription": "一个 B2B 项目管理工具，团队领导用它来追踪团队绩效和交付情况",
  "schemaMode": "hybrid",
  "fields": [
    {
      "name": "company_size",
      "values": ["50-100", "100-250", "250-500"],
      "valueWeightPercent": [40, 40, 20]
    },
    {
      "name": "industry",
      "values": ["软件", "咨询", "营销代理", "建筑"],
      "valueWeightPercent": [35, 30, 25, 10]
    },
    {
      "name": "team_size_direct_reports",
      "values": ["3-5人", "6-10人", "11-20人"],
      "valueWeightPercent": [50, 35, 15]
    },
    {
      "name": "data_comfort_level",
      "values": ["低", "中", "高"],
      "valueWeightPercent": [30, 50, 20]
    }
  ]
}

data_comfort_level 字段最终被证明是最重要的那个。它最初不在任何人的心理模型里——是在字段配置讨论过程中出现的，当时开发提到他们现有报告功能的支持工单，很大比例来自不理解数字含义的用户。

这 10 分钟的对话，由配置 Schema 的结构迫发出来，浮现出了一个单靠数据分析可能需要数周才能发现的洞察。

上午晚些时候：让画像变得具体

输出是 12 个画像。团队选了四个来使用——不是最复杂的那些，而是有代表性的分布：一个数据敏感度低的咨询公司团队领导、一个 400 人软件公司的高数据敏感度领导、一个营销代理的中等水平领导，以及一个建筑项目经理（基本上是他们想要压测的边界情况）。

面前有四个有名字有描述的具体人物，设计对话就变了。不再是"用户可能想按日期范围筛选"，而是"Elena 可能会在周一早上打开这个 Dashboard，她想先看到上周的摘要——她不会去自定义任何东西，她想要一个告诉她团队是否在正轨上的数字。"

具体到这种程度，才是重点所在。不是因为 Elena 这个生成画像是准确的——而是因为有一个具体的人可以争论，比围绕"用户"争论能逼出更清晰的思考。

下午早些时候：第一版设计

设计师把四个画像当作约束，而不是检查清单。不是"这个设计是否服务于所有四个人？"而是"如果 Elena 打开这个、30 秒内找不到她要的东西，我们漏掉了什么？"

三小时的设计工作产出了两个显著不同的线框方向。团队对两个方向都做了画像走查——字面意思是大声朗读每个画像的描述，然后一步步走过他们在界面里会做什么。

这暴露了方向 A 的一个结构性问题，此前没有人注意到：它默认显示图表视图，而理解这个图表需要先理解百分位分布是什么意思。数据敏感度低的用户（合成数据集的 30%，团队将其作为真实用户分布的代理）如果不事先知道图表的含义，就没有办法得出有用的结论。

方向 B 默认显示摘要卡片视图，有数字和趋势指示器。没那么复杂，但无歧义。

团队选择了方向 B。

下午晚些时候：检验假设

这里合成方法碰到了真正的局限。团队一直在为他们自己构建的 Elena 和其他三个画像做设计。他们在一致地使用这些画像方面很严格。但他们仍然不知道这一切是否映射到真实的团队领导身上。

产品经理做了一件花 45 分钟的事：她把方向 B 线框图的 Loom 视频发给了三位真实客户，附上一个问题——"这个 Dashboard 给了你周报里想要的东西吗？如果没有，缺什么？"

当天结束前两位回复了。一位说可以，另一位说她希望包含工时追踪集成数据——这不在当前路线图上，但在承诺一个暗示包含它的设计之前知道这一点很有价值。

合成画像加速了到这一步之前的所有事情。真实客户的确认是让决策站得住脚的东西。

这一天实际上说明了什么

合成画像在这个工作流里的价值，不是取代用户研究——而是压缩了从"我们有一个想法"到"我们有一个具体到足以获得有意义反馈的设计"之间的时间。

没有画像生成这一步，周一早上就会花在无休止地争论抽象用户类型上。设计工作会从更模糊的需求出发。画像走查会停留在假设层面。产品经理发给客户的会是一个连贯性差很多的线框图 Loom，得到的反馈也会不那么有用。

合成画像让工作更具体、更快速。真实用户检验让它可信。

这才是真正有效的分工——不是用 AI 画像替代用户，而是用 AI 画像快速推进，让和用户的对话变得有价值而不是仓促进行。

运行这个模式的实用注意事项

几件让这个方法更奏效的事：

以团队而非个人来配置 Schema 字段。 字段配置讨论是有价值洞察藏身的地方。建筑项目经理这个画像只是因为有人在设置过程中提到了它才出现——而最终发现他们 10% 的客户群在建筑行业。

生成比你要用的更多的画像。 生成 15-20 个，选 4-6 个能代表你关心的分布范围的。完整集合用于回顾；小集合才是你实际设计的对象。

主动而非装饰性地使用画像。 从具名画像的视角大声走查界面，一开始很不自然，但非常有用。避免"这是我们的画像"作为一张幻灯片、之后再也不提的模式。

不要跳过真实用户检验。 即使是轻量级的客户反馈——一个简短的 Loom、一封单问题邮件——也会改变 Sprint 结束时决策的质量。合成画像让你准备好了去提更好的问题；真实用户来回答它们。