原型用户画像Skill：几小时搭出可对齐、可验证的用户假设画像
- 它是什么：原型用户画像Skill（英文名 proto-persona，技能ID 11355）是一个“组件型”AI 技能，用来在产品早期快速产出一份基于假设、结构化、可迭代的目标用户画像，而不是一份需要数月研究才能得到的已验证画像。
- 它解决什么：当团队还没做大规模用户研究、却必须马上讨论“我们到底为谁做”时，它能防止“为所有人设计”，也防止设计被多人意见拉扯。
- 它怎么产出：按固定结构填写名称、简介与人口统计、引语、痛点、试图实现什么、目标、态度与影响，并为不确定内容打上“假设—验证”标记。
- 它的边界很清楚：技能详情明确写了“这不是已验证研究”“不是用户研究的替代品”，它的作用是指导研究，并告诉你接下来该去采访谁。
- 它可组合：技能引用
jobs-to-be-done、problem-statement，并可被positioning-statement、user-story等技能复用，形成从问题定义到用户故事的完整链路。
该技能叫什么？如何一键安装 AI 技能提升开发效率？
技能中文名：原型用户画像Skill
技能英文名：proto-persona
技能ID：11355
技能类型：组件（component），建议文件名为 proto-persona.md，建议放置位置为 /skills/components/。
它要解决的问题非常具体：产品开发的早期阶段，往往既有“必须马上给出方向”的压力，又缺少足够的用户研究支撑。此时团队对“目标用户是谁”各有一套理解，需求评审容易变成观点之争。原型用户画像技能把这种模糊状态，转化成一份明确标注了假设、结构统一、可被团队共同引用的画像文件，让讨论从“我觉得用户会……”变成“我们假设用户会……，这个假设待验证”。
一键安装的思路与步骤：
- 确认安装前提：你的 AI 助手或开发环境需要支持 Skills 机制（即能读取技能目录中的
.md技能文件）。具体支持范围与版本要求以官方说明为准。 - 获取技能：优先通过技能市场/技能库的安装入口，按技能ID 11355 或英文名 proto-persona 检索并安装；若你的环境采用文件式技能管理，也可按详情建议，把技能文件命名为
proto-persona.md并放入/skills/components/目录。具体的安装命令、入口路径与调用方式以官方说明为准。 - 补齐依赖：该技能依赖
skills/jobs-to-be-done/SKILL.md与skills/problem-statement/SKILL.md，建议一并安装，这样“痛点”和“问题陈述”部分才能真正写实，而不是空泛描述。 - 验证是否生效：在对话中直接提出“用原型用户画像技能，为我正在做的产品生成一份原型人物画像”，观察返回内容是否包含名称、引语、痛点、目标、态度与影响等完整结构，并且是否主动标注了“假设—验证”缺口。若结构完整、且引用了
template.md的填写框架，说明技能已生效。
该技能的主要功能和特点
- 从零上下文也能起步：技能指导你先收集“已有研究、分析数据、市场数据、利益相关者见解、产品上下文”五类信息；如果确实没有，明确要求不要编造，而是标注缺口并规划研究去填补。
- 结构化的画像骨架：固定输出名称、简介与人口统计、引语、痛点、此人试图实现什么、目标、决策权、决策影响因素、信念与态度等字段，避免“只写年龄和城市”的伪画像。
- 强制区分“原型”与“已验证”：技能内自带对比表，明确原型画像在几小时到几天内完成、基于假设与有限研究、用于早期对齐；已验证画像需数周至数月、基于广泛研究、用于指导详细设计。
- 行为导向的质量检查：每个字段都附质量检查标准，例如人口统计必须带行为上下文（“远程工作、活跃于多个 Slack 社区、同时处理 3 个副项目”），痛点必须具体到“每周花 3 小时手动在工具间复制数据”。
- 反模式清单，防止误用：明确指出它不是已验证研究、不是用户研究的替代品、不只是人口统计数据、不是永久不变的文档。
- 五类常见陷阱与修复方案：包括“没有行为的人口统计”“把原型当事实”“一次做 10 个原型画像”“编造引语”“从不验证”，每条都给出症状、后果与修复方法。
- 与技能链路联动：画像可喂给问题陈述、JTBD、定位陈述与用户故事技能，让“作为一个[人物画像]，我想要……”真正有据可依。
对比普通“让 AI 随便写个人物画像”的做法，它的差异在于：输出有结构、有质量检查、有假设标记、有验证路径，而不是一段看起来漂亮但无法落地的营销文案。
如何使用该技能？
步骤 1：收集可用上下文 在正式生成前，把手上有的材料整理给 AI：用户访谈笔记、调查结果、支持工单、使用数据与人口统计、行业报告与竞品分析、销售/支持/客户成功团队的观察、以及你要解决的问题本身。材料越具体，画像越不像“模板作文”。
步骤 2：定义画像身份 技能要求给画像起一个头韵、易记、非通用的名字，例如“经理迈克”“初创莎拉”，避免“用户 1”“人物画像 A”。随后填写简介与人口统计，但只保留影响产品决策的项。
输入示例：
我们是做研发效能工具的，目标用户是中型科技公司的研发管理者，想生成一份原型用户画像。
输出片段示例：
名称：经理迈克 简介与人口统计：35–45 岁，居住在城市地区；中型科技公司总监级别（50–500 人）；活跃于领英与行业社群，每年参加 2–3 个会议；已婚有年幼孩子，重视工作与生活平衡。
步骤 3：捕捉他们的声音 填写 2–3 条引语，优先使用访谈、工单、销售通话中的真实语句。判断标准是“是否暴露心态”，例如“我每周花 10 小时在状态会议上，这些会议本可以是电子邮件”就比“我需要更好的工具”有信息量。尚无真实引语时，标注为占位符并注明需要研究。
步骤 4：记录他们的上下文 写清痛点（具体、与你的产品相关）、此人试图实现什么（可观察、结果导向，如“提前 2 周交付项目”而非“使用仪表板”）、目标（兼顾短期战术目标与长期抱负目标，也可涵盖个人目标）。
步骤 5：理解影响因素 补充决策权（是否有预算权、超过多少需要上级批准）、决策影响因素（同行推荐、分析师报告、社群讨论等）、信念与态度（例如“怀疑需要培训的工具”“重视数据驱动决策”）。
步骤 6：验证与迭代 带着画像与团队对齐：是否有人“认得出这个人”？把不确定处统一打上“[假设—验证]”标签，列出接下来要采访谁、验证哪几条假设，并在获得新信息后更新画像，置信度足够高时升级为已验证人物画像。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 原型用户画像Skill（proto-persona） | 早期阶段的结构化假设画像生成组件 | 按固定模板生成名称、引语、痛点、目标、态度与影响；内置质量检查、反模式与陷阱清单；标注假设缺口 | 需支持 Skills 的环境，通过技能ID 11355 或文件方式安装，并配置依赖技能；门槛以官方说明为准 | 早期产品、新功能立项、跨职能对齐、识别研究缺口 | 优势：结构统一、可直接复用到下游技能、明确不编造；不足：本身不提供研究数据，质量高度依赖你输入的上下文 |
| 通用大模型 + 自写提示词 | 直接用对话生成人物画像 | 灵活、可随意调整格式 | 无安装门槛，但需要自己设计提示词与校验标准 | 临时性、一次性的画像草稿 | 优势：上手最快；不足：输出结构不稳定、容易写成营销文案、缺少假设标记与验证路径，多人协作时口径难统一 |
| 在线用户画像模板/画布工具 | 可视化填写画像画布 | 提供画布版式与协作编辑 | 通常需要在网页端手动填写，具体以官方说明为准 | 工作坊、团队共创、汇报展示 | 优势：直观、适合现场讨论；不足：内容仍靠人填，缺少质量校验与“假设—验证”机制，容易停留在人口统计层面 |
| 传统深度用户研究形成的已验证人物画像 | 研究驱动的正式画像 | 基于大量访谈与数据，置信度高 | 需要数周至数月的研究周期与人力投入 | 成熟产品、详细设计决策 | 优势：可信度最高；不足：速度慢，无法满足早期立项的即时对齐需求，成本高 |
可以看出，原型用户画像Skill 的生态位是“研究之前的那一步”：它不替代深度研究，而是把等待研究的那段时间利用起来，让团队先有共同参照，并且把研究目标定得更准。
该技能的典型应用场景与实际体验情况
场景一：新产品立项的产品经理 产品经理在立项会上被追问“目标用户到底是谁”，但手上只有零散的用户反馈与行业报告。使用该技能可以在半天内产出一份带引语、痛点与目标的原型画像，并在评审中明确标注哪些是假设。实际体验是：上手难度低，照着结构填即可，但效果取决于你是否愿意把“具体到数字与行为”的细节写进去，写得越具体，团队越容易“认得出这个人”。
场景二：设计团队避免“为所有人设计” 设计在早期容易陷入“每个角色都要照顾”，导致界面堆功能。技能明确给出的建议是从 1–2 个画像起步（主要 + 次要），并提示“一次做 10 个原型画像”会导致分析瘫痪。实际体验中，这一步能有效收敛讨论范围，注意事项是：不要让画像变成“谁声音大就写谁”。
场景三：销售、支持与产品的口径对齐 销售和支持团队天天接触真实用户，但他们的洞察常常停留在口头。使用该技能时，把销售通话与工单中的原话作为引语来源，可以快速把一线洞察转成结构化文档。实际体验是：引语部分最见成效，但也最容易踩“编造引语”的坑，技能里专门把“听起来像营销文案的引语”列为陷阱，提醒改用真实语句或标注占位。
场景四：为下一轮用户研究定方向 团队准备做访谈，却不知道该找谁。原型画像中的“决策权”“决策影响因素”和标注出的假设缺口，可以直接转成招募条件与访谈提纲。实际体验是：这一步的产出往往比画像本身更有价值，因为它把“我们要验证什么”写清楚了。需要注意：若长期不验证，画像就会退化成一份过期文档，技能也专门提示“计划研究冲刺”。
该技能能为用户带来的价值
- 把对齐时间从“周”压到“小时/天”：技能明确原型画像在几小时到几天内完成，而验证画像需数周至数月，早期决策不必再空等研究结论。
- 降低跨职能沟通成本：一份统一结构的画像成为共同参照点，讨论从“我觉得”转向“我们假设……待验证”，评审效率明显提升。
- 把隐含假设显性化：通过“[假设—验证]”标记与缺口清单，团队知道自己不知道什么，后续研究不再盲目。
- 提升下游产出的质量：画像可被问题陈述、JTBD、定位陈述、用户故事技能复用，让“作为某类用户，我想要……”有真实依据，而不是填空。
- 长期价值在于可演化：画像随学习持续更新，置信度足够高时升级为已验证画像，团队的用户认知资产是累积的，而非每次立项重做一遍。
- 降低方法门槛：内置的质量检查、反模式与陷阱修复，让没有用户研究背景的开发者、创业者也能按专业流程走一遍，避免常见错误。
常见问题 FAQ
Q1：这个技能怎么安装？需要什么前提？
A：它是一个组件型技能（技能类型为 component），建议文件名为 proto-persona.md、放置于 /skills/components/。可通过支持 Skills 的环境按技能ID 11355 或英文名 proto-persona 检索安装，也可按文件方式放入对应目录；同时建议安装 jobs-to-be-done 与 problem-statement 两个依赖技能。具体的安装命令、入口与调用方式以官方说明为准。
Q2：使用这个技能收费吗？ A：技能详情中未涉及任何价格或授权信息，是否收费取决于你所使用的技能平台与运行环境，请以官方说明为准。
Q3：它和“让 AI 直接写一个用户画像”有什么区别？ A：普通对话生成的人物画像通常结构随意、容易写成营销文案。该技能提供固定的填写结构、逐项质量检查、原型与已验证画像的对照、反模式与常见陷阱清单，并要求对不确定内容标注假设、规划验证，输出更接近可直接用于团队协作的工作文档。
Q4：它适合谁用？不适合谁用？ A：适合早期产品阶段的 PM、创业者、设计师、需要与产品对齐的销售与支持团队。不适合已完成广泛用户研究、应直接创建已验证画像的团队，也不适合用户细分已高度明确的成熟产品；更不能把它当作定量数据或用户研究的替代品。
Q5：生成的画像一定准确吗？ A：不一定，也不应该这样期待。技能明确定位它是“基于假设的工作假设”，用于早期对齐与指导研究。如果发现画像从未更新、引语像宣传语、或团队把假设当事实引用，就说明踩中了技能中列出的陷阱，应按修复建议补充真实引语、打上验证标记并安排研究。