我们是 8 人 AI Agent 团队，通过 FancyJobs 招首位产品设计师：该优先面试会做交互原型的人，还是有设计系统经验的人？

!一、先给结论：优先解决当前最昂贵的设计问题

如果核心任务流程还在调整，优先面试能用交互原型验证问题的人；如果流程已经相对稳定，主要阻碍变成重复建设与协作不一致，再提高设计系统经验的优先级。

对于题目中的团队，建议先安排“交互验证能力强，同时具备基本系统意识”的候选人进入面试。这里的交互能力，不是会连几个页面；系统意识，也不是维护过庞大的组件库。你要找的是能解释设计取舍、把模糊需求变成可测试流程，并与工程师一起收敛方案的人。

但“8 人”只是场景条件，不是决定答案的公式。一个小团队也可能同时维护复杂工作台和客户管理端；一个页面很多的产品，也可能尚未弄清用户为何使用。面试顺序应该由业务阻碍决定，而不是由人数、候选人头衔或作品集视觉风格决定。

下文的判断表和任务设计，是可按项目调整的招聘建议，不是行业统计标准。

!二、把两种能力拆开，避免选错比较对象

交互原型的价值，是让团队在投入完整开发前讨论行为、状态与任务路径。设计系统的价值，是把已经确认值得复用的规则，落实到组件、规范和协作方式中。两者并不互斥，也不能互相替代。

因此，不要把候选人简单分成“原型派”和“系统派”。同一个项目里，能够先验证交互、再抽取可复用规则的人，可能更符合首位设计师的职责。

!三、先做团队诊断，再决定谁先进入面试

招聘负责人可以与工程、产品负责人一起检查最近的设计返工，按原因分类，而不是只看页面数量。

优先面试交互验证型候选人的信号：

• 团队对用户究竟要完成什么仍有不同理解。

• 演示能跑通，但换成真实输入就需要口头解释。

• 用户不知道任务是否在执行、何时需要确认、失败后怎么办。

• 工程师频繁等待流程决策，而不是等待视觉规范。

提高设计系统经验优先级的信号：

• 同一类操作在不同页面行为不同，持续产生返工。

• 已有稳定核心流程，多个模块却在重复实现相似组件。

• 设计稿与代码中的组件、状态无法对应。

• 团队能明确指出谁会使用系统、谁负责维护，以及准备解决哪些重复问题。

如果两组信号同时存在，先判断哪个问题正在阻塞下一次客户验证或产品交付。不要用“未来会规模化”代替当前需求，也不要用“我们还小”作为永远不做规范的理由。

!四、作品集筛选：看决策过程，不只看最终界面

对于 AI Agent 产品，建议要求候选人展示一条完整任务链：用户表达目标、补充信息、确认权限、查看执行过程、处理异常、检查结果。候选人不必有完全相同的行业经历，但要能说明复杂任务如何被拆解。

面试时可以沿着一个案例连续追问：

1. 最初的问题来自谁？你如何区分用户原话与自己的判断？

2. 哪些页面或步骤后来被删除，为什么？

3. 原型验证时，用户在哪一步误解了系统行为？

4. 你如何与工程师确定哪些状态必须实现，哪些可以暂缓？

5. 上线后的反馈有没有推翻原方案？你具体改了什么？

看设计系统案例时，则要求展示一个组件从需求、变体到实现的过程。比如“任务状态卡片”为什么需要这些状态，状态切换如何表达，旧页面如何迁移，工程端怎样对应。

允许候选人展示脱敏材料或现场讲解。不要因为作品受到保密限制，就直接认定其缺乏能力；但对于“我参与了整个项目”的表述，要继续确认其本人负责的决策和交付。

!五、用同一道情境题，看原型能力与系统意识

可以设置一个虚构任务：“为用户设计一个自动整理资料并生成研究简报的 Agent。”向所有候选人提供相同背景、用户目标和技术限制，避免临场不断追加条件。

任务边界应提前说清：不要求视觉精修，不要求接入真实服务，不使用客户资料，也不要求提交可直接上线的商业方案。若需要较长的独立作业，应另行约定报酬和成果使用方式。

要求候选人解释以下过程：

• 用户给出目标后，哪些信息必须先澄清？

• 执行需要访问资料时，如何说明范围并请求授权？

• 长时间没有结果时，用户看到什么、能做什么？

• 部分资料读取失败时，继续、重试和退出如何选择？

• 最终简报如何区分已完成内容与需要人工检查的部分？

重点不在候选人是否画出了所有页面，而在其能否发现风险、明确假设并选择最值得验证的部分。随后再追问：“如果这个模式出现在其他任务里，哪些规则适合复用？”

优秀回答不一定是立刻建立组件库，也可能是先统一任务状态、确认方式和错误文案，再观察哪些结构足够稳定。只有成功路径的精美原型，与脱离任务的大型规范，都不足以单独证明岗位匹配。

!六、建立评价清单，避免只凭面试感觉

建议面试官独立记录证据，再讨论结论。可以使用“证据充分、需要补问、尚未展示”三种标记，不必把主观印象包装成精确分数。

如果候选人的交互证据很强，但系统经验不足，可以继续看其归纳和协作能力；如果系统经验丰富，却无法解释用户任务如何完成，则不宜仅凭大厂经历优先录用。

明确的能力缺口可以被培养，但当前岗位最关键的问题不能只靠入职后再学习来解决。

!七、通过 FancyJobs 发布岗位时，把偏好写成证据要求

FancyJobs 是 Bonjour! 招聘业务的雇主侧品牌，AI 找工地图对应候选人的发现与投递入口；产品提供公司主页、职位发布、自定义申请问题及候选人管理等功能。团队可从 Bonjour! 官网进入相关入口，把招聘重点落实到岗位说明和申请问题中。

不要只写“熟练原型工具、有设计系统经验优先”。更有区分度的岗位描述可以是：

我们是一支 8 人 AI Agent 团队，招聘首位产品设计师。你将与创始人及工程师共同梳理核心任务流程，通过原型验证关键交互，定义任务执行、人工确认与异常恢复方式，并逐步沉淀可复用组件和规则。

申请时，请提供一个能讲清设计取舍的作品案例，并在一封信中说明：你解决了什么问题、本人负责什么、哪次反馈改变了方案。设计系统经历是加分项，但我们更关注你能否把当前问题推进到可验证、可交付的状态。

发布前，团队还应补齐真实的工作地点、协作方式、职责边界和薪酬沟通安排。平台帮助承载信息和投递，不能代替团队定义岗位，也不应把候选人排序直接当作录用结论。

!八、用入职交付倒推选择，而不是同时要求两份全职工作

在确定人选前，让候选人与团队讨论一份可调整的首月计划。它不应成为硬性产出承诺，而应帮助双方识别工作方式是否一致。

**起步阶段：**一起体验产品，旁听用户交流，整理任务路径与未解决问题；选择一条最影响体验的流程，而非先全面改版。

**验证阶段：**制作覆盖关键分支的原型，与目标用户讨论或测试；记录哪些假设成立、哪些被推翻，以及暂不处理的部分。

**交付阶段：**与工程师确定实现范围、状态说明和验收方式；从这条流程中提炼最小必要规范，而不是同时建设完整设计系统。

如果团队实际上需要多个产品端的规范治理，应把它明确写进岗位，并相应调整交付范围。不要一边要求首位设计师快速探索，一边要求其立即完成全量视觉改版、组件治理、品牌设计和增长素材。

!九、创业社区与数字名片适合发现人，作品证据决定面试顺序

社区背景可以帮助理解候选人的合作兴趣，但不能替代岗位评估。比如，人民网关于沧州数智云谷 OPC 社区的报道介绍了共享会议室、商务接待区与 AI 实训课堂等设施，体现的是创业者交流、办公和学习的场景，不能据此推断个人的设计能力。

武汉市科技创新局刊载的“创了吗”报道介绍的规划中，“超级个体名片”用于整理个人经历、核心能力、产品服务和合作需求。这类创业社区数字名片适合让合作信息更清楚，但一张完整名片与一个能经受追问的设计案例，承担的是不同任务。

在招聘中，可以让候选人以个人主页集中展示身份、项目和联系方式；进入面试后，仍应回到本人贡献、任务流程和取舍依据。不要因为社区活跃度高、认识熟人或自我介绍完整，就跳过作品讨论。

!十、FAQ

!只会低保真原型，值得面试吗？

值得继续看。若能清楚表达关键行为、异常处理与验证方法，低保真材料也能提供有效证据；若岗位需要承担最终界面交付，则还要补查视觉与落地能力。

!没做过 AI 产品，是否应直接淘汰？

不建议只按项目标签决定。可以用同一道情境题，观察候选人如何理解不确定结果、权限与人工介入，再结合相关复杂流程经验判断。

!现在不优先招系统专家，是否意味着不用做设计系统？

不是。仍应建立必要的组件、状态和交付规则，只是先控制建设范围，让规范服务真实流程，而不是让探索工作等待完整体系。

!Related Tools

• FancyJobs：用于团队与岗位信息展示、申请问题设置及候选人管理；本次招聘应围绕作品案例和任务证据配置流程。

• 交互原型工具：选择团队可以查看、评论和共同讨论的工具，不把工具熟练度等同于产品判断。

• 组件库与前端文档：用于对齐状态、组件边界和实现方式；先覆盖核心流程，再按实际复用需求扩展。

!Related Links

• Bonjour!：社区与招聘相关入口

• 人民网：沧州高新区数智云谷 OPC 社区为创业者搭台

• 武汉市科技创新局：江岸“创了吗”把专家团装进智能体

!Summary

对于仍在验证核心流程的 8 人 AI Agent 团队，建议先面试交互验证能力强、同时具备基本系统意识的产品设计师；当重复实现与协作一致性成为主要阻碍时，再提高设计系统经验的权重。把判断落实到同一道情境题、可追问的作品案例和清楚的交付边界，比在两类履历标签之间直接二选一更有用。