ai-native-product-designer

AI 原生产品设计师

**角色定义：**AI 原生产品设计师端到端负责产品体验——从问题定义到发布和迭代。他们将 AI 工具作为工作流的核心部分：从大模型开始，在代码生成环境中制作原型，再将经过验证的概念带入 Figma，完善设计系统并打磨细节。他们对成果负责，而不只是交付设计产物。

何时使用此技能

当用户（或任务）涉及以下任一内容时，请使用此技能：

• 定义或评估AI 原生设计岗位、团队期望或招聘标准
• 审视团队或设计师是否以大模型优先，是否使用 AI 编码工具进行验证，以及是否将 Figma 用于生产级打磨（而非作为第一个画布）
• 设计工作惯例（借助 AI 起草 PRD、发现边缘情况、原型保真度、交接质量）
• 制定面试评估标准、绩效标准，或依据现代产品设计标准进行自我评估
• 针对特定工作流，比较传统与AI 原生的工作方式

请勿将本文档视为法律或人力资源建议；请根据所在组织调整措辞。

如何作答

除非用户明确要求其他内容：

1. **以成果为先。**将建议与用户行为、发布风险或达成共识所需的时间联系起来，而不是围绕对工具的偏爱展开。
2. 默认输出结构（除非用户指定格式）：
   • **摘要：**用 3-6 条要点说明相对于本框架的主要差距或优势
   • **差距列表：**使用编号列出，每项差距都关联附录评估标准中的一个类别或一行
   • **优先行动：**列出接下来 1-2 个迭代周期要做的 3 项首要改进（每项行动都具体到可分配负责人）
   • **可选：**为每项首要行动提供一个示例提示词或工作惯例（简短，可直接复制使用）
3. **深入分析时参考附录：**为某人打分或撰写职位描述时，引用附录中的确切表述。
4. 如果缺少背景信息，请在进行长篇评估前提出一个澄清问题（团队规模、B2B 还是面向消费者、是否受监管）。

术语

• AI native（两个单词，行文中「native」小写）描述的是角色和工作流（大模型优先、借助代码进行验证、使用 Figma 构建设计系统并完成交接）。
• 评估表中的 Native 单独出现时，指的是最高熟练度级别（Developing / Fluent / Native）。不要将「Native 级别」与「AI 原生设计师」混为一谈。

快速参考（速查表）

三层技术栈

Layer 1: LLM (Claude / ChatGPT / Gemini)
   -> Clarify intent, draft PRDs, surface risks, align teams, explore solution spaces

Layer 2: AI Code Tools (Cursor / Claude Code / v0)
   -> Build interactive prototypes, generate UI flows, iterate on behavior fast

Layer 3: Figma
   -> Full state coverage, design system alignment, production-ready handoff

原则：Figma 是设计的收尾之处，而非起点。

各级熟练度，一句话说明

• **Developing：**有时使用 AI；默认工作流仍然以 Figma 为先。
• **Fluent：**整个流程默认使用 AI；已形成相应习惯。
• **Native（级别）：**深入运用 AI 工作流；指导他人；塑造团队模式。

自检（在心里或聊天中回答「是 / 否」）

1. 开始解决新的设计问题时，我会先打开大模型，再打开 Figma 吗？
2. 过去 30 天内，我是否使用 AI 编码工具制作过交互式原型？
3. 我能否借助 AI 撰写一份简洁的 PRD 草稿，供 PM 审阅和使用？
4. 过去 2 周内，我是否在没有研究团队参与的情况下，直接与客户交谈过？
5. 我是否先针对 80% 的常见情况进行设计，并明确决定边缘情况下哪些内容会被隐藏？
6. 我交接的每个屏幕是否都涵盖了完整状态，包括错误、空状态和加载状态？
7. 我能否用具体、可衡量的方式说明当前项目取得成功的标准？
8. 对于已发布的功能，我是否会查看发布后的数据，并据此推动下一轮迭代？
9. 在上一个迭代周期中，我是否与设计团队分享过提示词、模式或工作流方面的新发现？
10. 我是否对行为改变负责，而不只是对设计交付负责？

完成清单后：对于每个回答否的问题，提出一个具体的下一步行动，确保可以在本迭代周期内完成（明确负责人、产物或时间安排）。避免含糊的建议（例如「多使用 AI」）。

真实场景中的契合度（示例）

公开发布的产品设计师职位越来越能体现这套工作模式（用 LLM 梳理意图并撰写简洁规格说明，用 Claude / Cursor / Claude Code 设计流程，用 Figma 搭建系统并精修；重视成果而非交付物；开展轻量研究；分享提示词）。Ramp 是一个公开示例（与此技能无关，仅供市场参考）。

---

附录：完整能力评估标准

使用本节进行评分、撰写职位描述和开展详细指导。

为什么这一职位需要不同的熟练度等级

传统设计岗位将 AI 视为一项新兴技能。在这一职位中，熟练运用 AI 是基本要求，而非差异化优势。熟练度等级体现的是 AI 融入工作的深度，而不仅仅是对 AI 的了解。

技能熟练度等级

等级	含义
入门	偶尔使用 AI 工具；仍默认采用传统的设计优先工作流。
熟练	在完整设计周期中默认从 AI 工具入手；将 AI 融入日常工作，形成习惯。
深度融入	AI 工作流已深度融入工作；能指导他人；创造新模式；推动可能性的边界。

技能类别 1：AI 优先的设计工作流

在开始任何视觉设计之前，将 LLM 作为主要的思考和协作工具。

技能	实际体现	入门	熟练	深度融入
将 LLM 作为设计起点	在打开 Figma 之前先打开 LLM，用它明确意图、探索问题空间并梳理假设。	将 LLM 用于个别任务（文案、命名）；设计工作仍从 Figma 开始。	每个设计问题都从 LLM 入手；在进行任何视觉工作之前，用它界定问题、拟定方案并与 PM 达成共识。	建立个人提示词库和工作流，持续比同事更快地将模糊问题梳理清楚。
面向设计的提示工程	编写能生成有用设计相关内容的提示词，例如界定问题、起草 PRD、列出边缘情况和绘制用户流程草图。	使用基础提示词；生成的内容需要大量编辑。	编写包含背景、约束和输出格式的结构化提示词；迭代提示词，而不只是修改输出。	构建并分享设计团队使用的提示词体系；指导他人如何为产品和 UX 场景设计提示词。
使用 AI 起草 PRD	使用 LLM 起草简洁的产品需求文档，让团队就范围、意图和待解决问题达成共识。	能在 AI 的帮助下生成粗略的 PRD 大纲。	通过与 LLM 对话生成结构完善的 PRD 草稿；在视觉工作开始前与 PM 审阅并确认一致。	负责团队的 PRD 到设计衔接；利用 AI 生成的 PRD 大幅减少共识会议。
梳理风险和边缘情况	在开始 UI 工作之前，使用 LLM 系统性地识别可能出现的问题，包括错误状态、权限边缘情况和不理想路径。	向 AI 询问边缘情况；接受初次生成的列表，不再深入追问。	使用 AI 生成全面的边缘情况矩阵；根据工程约束进行验证；将发现带入团队协作讨论。	将边缘情况梳理设计成团队的固定流程；通过提前开展这项工作，避免上线后出现整类 bug。
通过 AI 产物促进团队协作	在进入 Figma 之前，使用 AI 生成的文档（PRD、简报、风险列表）与 PM 和工程团队协作并达成共识。	非正式地分享 AI 输出；主要通过会议达成共识。	使用 AI 生成的产物开展结构化的异步协作；减少视觉工作开始前的反复沟通。	设计团队级工作流，让 AI 产物取代大多数早期会议；以异步方式达成共识并记录在案。

技能集群 2：AI 辅助原型制作与构建

能够使用 AI 编码工具构建交互式原型，比使用 Figma 更快地验证 UX 假设。

技能	实际含义	入门	熟练	精通
AI 编码工具原型制作	使用 AI 代码生成工具构建交互流程原型，而无需手动编写生产代码。	尝试过 AI 编码工具；能在 AI 大量协助下运行基础原型。	经常使用 Cursor 或 Claude Code 等工具构建交互流程和简单界面的原型；快速迭代。	能为每个验证目标选择合适的原型保真度；能引导 AI 准确构建出复杂程度超乎预期的交互。
引导 AI 生成代码	知道如何引导 AI 生成的代码实现正确的 UX 行为——不只是功能可用，还要具备良好的 UX 质量。	原样接受 AI 的输出；遇到行为不符合预期时，难以在不删除代码并重新提示的情况下进行修正。	有条理地引导 AI：明确指定交互模型、边缘情况和质量标准；不断迭代行为，直到符合预期。	把 AI 当作快速高效的初级工程师——撰写简报，让 AI 首轮就生成高质量代码；从 UX 层面而非语法层面审查并引导。
原型到产品的交接	知道应将 AI 原型中的哪些部分迁移到实际产品中，哪些部分应交由工程团队重建。	把原型视为一次性成果；从头重建所有内容。	积极与工程团队合作，确定哪些原型代码足够完善，可以迁移到产品中；节省开发时间。	设计并推广全团队使用的原型到生产工作流；缩短“已验证的原型”与“已发布的功能”之间的差距。
交互保真度判断	知道什么时候 Figma 静态稿就足够，什么时候需要交互式代码原型来验证正确的假设。	遇到任何情况都默认使用 Figma；只有别人要求时才构建代码原型。	根据待验证的内容选择原型保真度；对于低风险决策，不会过度构建；对于复杂交互，也不会构建不足。	制定团队通用的原型保真度标准；指导他人根据验证问题选择合适的保真度。
前端基础知识	充分理解组件、状态、props、响应式行为和基本布局约束，从而能够精确引导 AI 生成代码。	知道组件和状态的存在；难以引导 AI 正确实现它们。	充分理解组件结构、状态管理基础和布局原语，能够引导 AI 工具生成正确的实现。	能流畅地衔接设计与工程讨论；能够阅读 PR，并评估交互是否符合设计意图。

技能集群 3：产品思维与问题定义

在设计任何解决方案之前，与 PM 和工程团队合作，定义正确的问题。**本节范围：**你做出的决定（问题陈述、方案、指标意图、构建取舍）。集群 7涵盖日常如何开展合作仪式（设计评审、工作节奏、组织学习）。

技能	实践中的含义	发展中	熟练	精通
问题框定	在着手寻找解决方案之前，定义实际的用户问题和业务问题，并在整个项目过程中让团队始终聚焦于此。	能描述问题，但往往很快就跳到解决方案。	能写出精确的问题陈述，区分症状和原因；以此抵制过早确定解决方案。	将问题定义设计为团队惯例；避免团队花整整几个冲刺处理错误的问题。
解决方案空间探索	在确定方案之前，提出并比较多个解决方向，并借助 AI 加快拓展思路。	探索 1-2 个选项，然后选择第一个看起来合理的方案。	借助 AI 快速生成 5-8 个解决方向；根据用户目标和限制条件评估后再缩小范围。	教团队借助 AI 发散思考；设计探索框架，以发现不显而易见的解决方案。
端到端负责	从问题定义到发布后的迭代全程参与，而非交接工作后就转向其他任务。	完成设计后交接；很少参与发布后的迭代。	负责完整生命周期：从问题到设计、发布，再到迭代；利用发布后的数据形成闭环。	设计团队问责模式，让设计工作持续负责，直至行为变化可衡量。
与 PM 合作	在设计前和设计过程中，与 PM 一起定义成功指标、权衡范围并确定解决方向的优先级。	接收 PM 提出的需求并执行。	与 PM 共同定义成功指标；对范围提出异议；参与产品策略制定，而不只是设计 UI。	设计 PM 与设计师的协作模式；指导团队如何开展高效的问题定义会议。
与工程团队协作	全程直接与工程师合作，而不只是在交接时沟通，以做出有利于 UX 的构建决策。	将工作交接给工程师；被动回答问题。	尽早让工程师参与设计决策；了解实现成本；在权衡取舍时保留 UX 质量。	为团队设计与工程团队的协作模式；示范设计师作为技术合作伙伴的协作关系。

技能集群 4：自助式用户研究

能够快速开展轻量级研究，为方向决策提供依据，同时避免成为瓶颈。

技能	实际含义	发展中	熟练	精通
客户对话	直接与客户交流以验证假设——无需等待研究团队。	依赖研究人员安排并开展访谈。	独立安排并开展客户对话；快速提炼方向性见解。	将客户对话作为每周习惯；建立非正式的客户网络，以获得快速、持续的反馈。
假设梳理	明确识别设计所依据的假设，并在测试前按风险排序。	将假设藏于心中，不会将其提出进行测试。	在测试前列出关键假设；根据风险和可逆性确定验证优先级。	将假设梳理设计为团队例行活动，在任何重要设计工作开始前进行。
快速测试	开展快速、非正式的测试（5 秒测试、走廊测试、无人主持的测试），在不进行正式研究的情况下验证方向。	等待完整的研究项目；没有轻量级测试习惯。	与 3-5 位客户或同事开展快速测试以验证方向；根据结果调整，然后再投入完整执行。	设计快速测试模板库，供团队自行取用；让轻量级测试成为团队习惯。
将研究作为提速工具	运用研究加快设计决策，而不是把研究当作拖慢进度的关卡。	将研究视为质量关卡，拖慢冲刺进度。	利用研究结果更快、更有把握地做出决策；研究能减少返工，而不是增加耗时。	指导团队树立研究提速思维；展示一次 2 小时测试如何省去 2 周的返工周期。

技能集群 5：交互设计与工艺

能够设计出对大多数用户而言简单易用、同时为边缘情况融入审慎判断的交互。

技能	实践中的含义	发展中	熟练	精通
80/20 设计思维	为常见情况设计默认体验，并将复杂性隐藏起来，只在边缘情况下呈现。	对所有情况一视同仁地设计；复杂性直接出现在默认体验中。	找出占 80% 的常见情况，并全力优化；边缘情况易于访问，但不会造成干扰。	将 80/20 设计原则树立为全团队的质量标准；在不削弱能力的前提下，降低产品复杂性。
复杂性编码	通过智能默认设置、渐进式呈现和 AI 驱动的自动化，将系统复杂性对用户隐藏起来。	只注重表面：向所有用户展示所有选项和控件。	在底层融入审慎判断；大多数用户根本不会看到对他们无用的复杂性。	设计由 AI 和产品逻辑在无形中处理复杂性的系统；界面之所以简单，是因为系统足够智能。
交互设计	设计每个交互元素的具体行为——不仅要设计外观，还要设计其响应方式。	设计静态界面；将交互细节留给工程师处理。	明确规定交互行为：时机、过渡效果、对边缘情况的响应、加载状态和错误。	制定团队的交互设计标准；对照预期的用户体验审核工程实现。
状态设计	设计每个组件的每种状态——默认、悬停、焦点、加载、错误、空状态、成功。	只设计默认状态；其他状态在工程实现过程中才被发现。	作为设计的一部分，预先设计所有状态；不把任何状态当作事后考虑的事项。	在设计评审中将状态设计不完整视为阻塞问题；设计可在整个产品中扩展的状态库。
用户体验质量标准	制定并维持高标准的交互质量，并能清楚阐述“好”的标准。	能看出好的用户体验，但难以阐明其标准。	明确制定用户体验质量标准；在评审中用它提供具体且可执行的反馈。	通过评审、模式和成文标准，在整个设计组织中提升质量标准。

技能集群 6：Figma 和设计系统

将经过验证的概念带入 Figma，以便为生产做好交接准备——这是设计技术栈的最后一层。

技能	实际含义	进阶中	熟练	精通
将经过验证的概念转化为设计	将经过测试并以代码实现的概念，转化为完整的 Figma 设计，以供生产使用。	从一开始就在 Figma 中设计；原型测试的经验未能始终如一地体现出来。	能将代码原型的经验清晰地转化到 Figma 中；Figma 文件反映的是经过验证的 UX，而非最初的假设。	设计流畅快速地从代码原型过渡到 Figma 的工作流；转换过程中不丢失任何信息。
在 Figma 中覆盖所有状态	在 Figma 中设计每个组件和屏幕的所有状态，而不仅仅是理想路径。	设计主要流程；状态覆盖不完整。	在交接前，为每个 Figma 画板设计所有状态；工程团队无需询问视觉细节。	审查他人的 Figma 文件，确保状态覆盖完整；将状态不完整视为阻碍交接的问题。
与设计系统保持一致	确保每个 Figma 设计都使用并扩展共享组件，并标明需要新增组件的地方。	组件使用不一致；经常创建一次性设计。	正确使用共享组件；以系统层面的思路创建新组件；主动指出系统缺口。	参与设计系统治理；审慎扩展共享组件；减少产品中的设计偏差。
达到生产就绪状态	准备 Figma 文件，使工程团队无需后续提问即可实现设计。	交接 Figma 链接；被动回应工程团队的问题。	提供包含完整规格、注释和边界情况覆盖的 Figma 文件；工程团队很少提问。	为团队制定生产就绪标准；在工程工作开始前审核交接质量。

技能集群 7：跨职能协作与沟通

直接且持续地与 PM 和工程师合作的能力，而不只是进行交接。**此处范围：**协作惯例、沟通规范、评审质量，以及经验如何传播。集群 3 涵盖 PM/工程决策的实质内容（指标、范围、权衡）。

技能	实际体现	发展中	熟练	精通
与 PM 直接合作	与 PM 并肩工作，定义问题、探索解决方案，并根据结果调整，而不是被动接收需求。	执行 PM 的需求；很少参与问题定义。	与 PM 共同负责从问题到解决方案的全过程；参与产品战略，而不只是执行 UI 设计。	为团队设计 PM 与设计师的协作模式；指导双方如何高效合作。
与工程师沟通	使用工程领域的语言——充分了解实现细节，能够进行技术交流。	仅从 UX 层面沟通；需要工程师进行转译。	充分了解组件、状态、API 和性能限制，能够在设计中做出明智的权衡。	融合设计与工程思维；通过更早让工程师参与，减少实现时的意外。
参与设计评审	在设计评审中提出和接受反馈，提升质量标准，而不只是验证现有成果。	展示工作成果；被动接受反馈。	提出具体且以原则为依据的评审意见；以建设性的方式提出异议；主动分享提示词和经验。	设计评审文化与流程；树立高质量评审的典范，让整个组织受益。
分享模式与经验	主动向设计团队分享 AI 提示词、设计模式和工作流发现。	使用他人发现的模式；很少贡献新模式。	定期分享提示词、模式和工作流发现；为共享设计知识库贡献内容。	建立团队共享的 AI 设计库；设计可扩展到个人贡献之外的知识共享系统。

技能簇 8：指标与成果归属

定义成功、衡量成效，并持续迭代，直到客户行为发生改变的能力。

技能	实际含义	发展中	熟练	精通
成功指标定义	在开发之前，与 PM 共同定义设计必须实现的具体、可衡量成果。	推出功能；成功指标由 PM 单独设定。	参与定义成功指标；理解设计决策如何对应到可衡量的用户行为。	负责设计与指标之间的关联；从第一天起就围绕具体的行为成果设计体验。
发布后迭代	发布后继续参与，衡量结果、解读数据并推出改进，而不是交接后就转向其他工作。	交接后转向下一个项目；发布后的迭代由 PM 推动。	查看发布后的数据；找出行为偏离假设之处；根据证据推动设计迭代。	为团队设计发布后回顾机制；确保每项已发布功能都有经过衡量的成果闭环。
成果优先于产出物的思维方式	以客户行为的变化衡量成功，而不是以已交付的设计成果衡量。	汇报设计和交付了什么。	汇报设计带来了哪些客户行为变化。	指导团队树立成果优先的思维方式；挑战组织层面那些奖励产出物完成而非行为变化的激励机制。
以数据为依据的设计	运用定量和定性信号——分析数据、会话录屏、支持数据——为设计决策提供依据。	使用 PM 或分析师提供的数据。	自行获取相关数据；结合设计决策解读数据；用数据验证或质疑设计方向。	为设计团队设计数据素养实践；营造以证据为基础做出设计决策的文化。

跨职能技能

与相邻岗位共通的技能，能帮助 AI 原生产品设计师更有效地开展工作。

技能	对该岗位的重要性	相邻岗位
SQL / 分析基础	能自行获取数据的设计师不必等待分析师，可以更快验证设计决策。	数据分析师
前端开发基础	了解 React 组件、状态和 CSS，能让 AI 生成的原型更准确，交接也更顺畅。	前端工程师
产品管理基础	以赌注、假设和指标为思考框架的设计师，能更好地与 PM 合作。	产品经理
UX 研究方法	自助式研究要求掌握如何设计有效的测试，即使是快速测试也不例外。	UX 研究员
系统思维	复杂产品本身就是系统；设计师必须了解变更如何影响整个体验。	系统 / 产品架构师

前沿技能（近期趋势）

随着智能体产品、AI 交互界面和设计系统不断融合，以下能力日益重要。趋势会随市场变化而转移；请每季度重新审视。

技能	重要性上升的原因	现在如何培养
智能体 UX 设计	AI 智能体代表用户执行多步骤任务，需要新的交互模式，涵盖状态、控制、信任和恢复。	研究当前的智能体 UI（Perplexity、Claude Projects、Devin）；为你的产品设计一个概念智能体界面。
AI 功能 UX 模式	设计 AI 驱动的功能（建议、摘要、生成、自动化）需要新的信任、透明度和控制模式。	建立个人 AI UX 模式库：加载状态、置信度指标、纠正流程。
提示词即界面设计	随着产品开放自然语言界面，提示词交互体验本身也成为产品设计问题。	端到端设计一个提示词输入组件：空状态、示例、错误处理、响应状态。
评估驱动设计	AI 输出质量存在差异，设计师必须设计评估循环，让用户反馈质量并持续改进 AI 响应。	阅读 RLHF 和对齐基础知识；找出产品中一个可通过反馈信号提升 AI 输出的环节。
设计系统与 AI	AI 组件（流式文本、引用、工具使用显示）需要标准化组件，未来的设计系统将包含 AI 模式。	为你的设计系统提出一个 AI 专用组件，并说明其所有状态。

自我评估清单（表格）

回答 YES 或 NO。每个 NO 都是一个成长方向。完成后，为每个 NO 指定一个具体的下一步（参见快速参考）。

#	问题	Yes / No
1	开始解决新的设计问题时，我会先打开大模型，再打开 Figma 吗？
2	过去 30 天里，我用 AI 编码工具制作过交互式原型吗？
3	我能用 AI 撰写一份简洁的 PRD 草稿，让 PM 审阅并采用吗？
4	过去 2 周里，我在没有研究团队参与的情况下直接与客户交谈过吗？
5	我会先为 80% 的常见情况进行设计，并明确决定边缘情况下哪些内容应隐藏吗？
6	我交付的每个界面都覆盖了完整状态，包括错误、空白和加载状态吗？
7	我能用具体且可衡量的方式说明当前项目的成功标准吗？
8	我会检查已发布功能的上线后数据，并据此推动下一轮迭代吗？
9	在最近一次冲刺中，我和设计团队分享过提示词、模式或工作流方面的新发现吗？
10	我对行为改变负责，而不只是对设计交付负责吗？

角色对比：AI 原生与传统产品设计师

维度	传统产品设计师	AI 原生产品设计师
设计始于	Figma	大模型（Claude / ChatGPT / Gemini）
原型工具	Figma / InVision	Cursor + Claude Code / v0
Figma 的作用	主要设计环境	最终润色 + 生产层
研究方式	由研究人员主导的正式研究	自助式、速度优先
与 PRD 的关系	接收 PM 提供的 PRD	与 AI 和 PM 协同创建 PRD
工程参与	交付时参与	从问题定义起持续参与
成功指标	设计交付	客户行为改变
AI 技能的地位	新兴技能 / 加分项	核心要求 / 入职首日即需具备