面试官您好，我是北京理工大学工业设计27届研究生王佳颖。是一名懂业务、精 AI、强协作的全链路设计师。

在专业实践方面，我先后在百度智能云和快手研发线担任 UX 设计师，参与过 MaaS 平台、AI 产品、中台进行复杂系统的设计。

在快手期间，我主要负责万擎平台的设计，同时也参与了7个平台的设计、完成71项需求，独立负责49需求的设计，并推动63个需求落地。

在百度期间，我负责AI 播客产品的体验设计，推动产品从 0.5 实验版升级至 1.0 商业版。同时，我也参与资源管理平台等中台产品的设计，并通过组件库建设降低后续维护成本。

这两段经历让我不仅能够完成交互和视觉方案，也能从业务目标、技术边界和用户价值出发，与产品、研发团队共同推进项目。

在 AI 实践方面，我长期关注 AI 与 UX 的发展，并能运用AI于工作与生活中，建立了自己的 AI 辅助设计工作流。也学习过c++ python等工具，能够更顺畅地理解技术逻辑并与研发同学沟通。

此外，我本科期间担任班长，在项目中也经常承担组长角色，具备较强的协作、沟通与项目推进能力。

以上是我的自我介绍。非常希望能够加入火山团队，参与到企业级 AI 产品的创造中。

[第 1 页]

这个题目的任务要求很明确，主要就是解决多 Agent 协作中的任务进度查看、产物查看和二次编辑。

我把这次方案概括为：从任务发起到成果迭代，建立可确认、可追踪、可参与的协作体验。

[第 2 页] [移到：业务目标]

业务上，主要希望提升多 Agent 任务的使用率、降低交付成本，以及促进成果的持续使用。

[第 3 页] [移到：用户旅程]

题目里的目标用户也比较清晰，所以我沿着任务的完整流程，分别看了新手和进阶用户的需求。

新手更关心现在做到哪儿了、结果能不能用；进阶用户则希望知道具体由谁负责，以及能不能只调整其中一个环节。

所以整体上采用分层展示，默认看整体，需要时再深入到具体任务。

[第 4 页] [移到：六个竞品的分析区域，快速扫过，再停在竞品总结]

竞品分析看了六个产品的完整链路，主要看三个环节：生成前怎么确认分工，生成中怎么跟进和干预，以及生成后怎么继续修改成果。

这轮样本里，角色展示和执行详情都有值得借鉴的方式。我更关注的是它们怎么衔接：看到进度以后，能不能进入具体任务；补充要求以后，能不能继续更新相关成果。

[第 5 页] [移到：现有产品衔接页]

我以火山方舟的现有控制台作为设计承载，梳理了已有的能力和页面结构。

现有产品已经有 Agent 的创建和管理能力，所以生成前主要解决怎么把这些能力接到任务里，重点还是放在执行过程和成果修改上。

[第 6 页] [移到：设计目标与策略页，这一页讲完再进入具体方案]

对应到设计上，我拆了三个目标。

1.建立协作预期，通过展示 Agent 的匹配结果，让用户先知道有哪些角色、分别做什么，同时连接现有管理能力。

2.增强过程掌控，通过进度总览、Agent 执行详情和局部干预，让用户跟得上，也能插手。

3.提升成果修改效率，集中组织产物，支持直接编辑和对话修改，再通过联动更新处理文件之间的关联。

[第 7 页] [移到：生成前方案探索，先看左侧探索，]

生成前虽然不在题目重点里，但用户如果一开始不清楚角色和分工，后面就很难判断执行是否符合预期。所以我补充了这一环节，并比较了几种确认方式。：发送前确认、发送后确认，以及在输入框里选择 Agent。

[第 8 页] [移选定方向]

相比执行后再调整，我希望用户先确认分工，减少任务启动后的返工，所以选择在发送前展示匹配结果，让用户先确认角色和分工，再开始执行。推荐方案可以直接使用，也保留自行添加和调整的入口。

[第 9 页] [移到：生成前右侧“预期进行”说明，简短带过]

后续可以继续补充输入框里的 Agent 选择，以及区分“预置”和“我的”的 Agent 广场。

[第 10 页] [移到：“生成中—主对话”上方主界面]

接下来就是这次的重点，生成中怎么增强过程掌控。

最初我把进度放在思考链里，但入口比较深；后来尝试把总进度放在输入框上方，具体任务留在正文里，信息又比较分散，所以我判断，整体进度和具体任务需要集中展示，并且能从状态直接进入对应任务。

这里按任务阶段组织，因为同一个 Agent 可能先做分析、再写文档，按阶段更容易看清工作推进到了哪里。

[第 11 页] [横向移到：“生成中—整体进展”上方主界面]

右侧总览可以逐层查看 Agent 和执行步骤。等待时也会说明依赖关系，比如设计 Agent 正在等 PM 的文档，让用户知道为什么没开始、接下来会发生什么。

异常直接显示在任务状态处，并提供重试入口；需要调整执行时，也可以找到相应的停止和终止操作。

[第 12 页] [横向移到：“生成中—详细进展”上方主界面]

如果用户只想调整某个环节，直接发到主对话里，可能不清楚由谁处理。所以我把局部补充放在对应 Agent 详情中，并提示“消息仅发送给当前 Agent”，明确这次沟通的对象。

[第 13 页] [“生成中—产物查看”有三张]

执行过程中，用户可以提前查看已经生成的文件。

这里主要解决提前查看的问题，编辑和版本操作放到生成后。未完成文件能展示多少内容，还需要与研发对齐。

[第 14 页] [移到下一排：“生成后—整体进展”，先停在完成态主界面]

任务完成后提供明确反馈，用户可以直接打开文件，或进入产物树查看完整结果。

[第 15 页] [向下移到：保存临时 Agent 的交互说明和弹窗]

好用的临时 Agent 可以保存到“我的 Agent”，保存前检查模型、Skill 和提示词等配置。多个 Agent 支持依次保存或跳过，方便下次复用。

[第 16 页] [横向移到：“生成后—产物查看”]

多个 Agent 会产生不同文件，用户需要集中找到成果，并确认是谁生成的、依据是什么。所以左侧集中找文件，右侧直接预览，文件上方保留生成它的 Agent 和上下游关系，相关结论附近提供引用来源，方便继续核查。用户核查后，可以继续编辑、评论或查看版本。

[第 17 页] [移到：“生成后—产物编辑” 编辑]

编辑这部分，我先以 Markdown 为重点，支持直接编辑和自动保存。

然后区分两种情况：用户知道具体怎么改，就自己编辑；

[第 18 页] [AI修改，3]

知道修改方向，但希望 AI 帮忙完成，可以选中内容，提出要求，可以使用 AI 修改，

[第 19 页] [评论修改，2]

也可以添加评论，把具体位置和修改意见一起交给主 Agent。

接下来需要处理的，是修改对其他成果的影响

[第 20 页] [移到：“二次 Agent 修改—确认更新范围”，在这里稍微停留]

比如竞品结论变了，需求文档和设计方向也可能受影响。如果还要用户逐份检查、分别通知，协调成本就没有解决。

所以系统先分析影响，展示建议更新的文件和位置，用户勾选确认后，再交给对应 Agent 修改。

这里保留勾选确认，是因为文件有关联，但并不代表每次都要全部重做。用户需要提前知道这次会改到哪里，也能决定改到哪里。

[第 21 页] [向下移到：确认后重新执行的界面，简短带过]

确认以后，就沿用前面的进度展示和干预方式，继续跟进更新。

[第 22 页] [diff]

更新结束后，系统会反馈涉及哪些文件。打开文件以后，可以通过diff，检查具体改了什么。

[第 23 页] [历史版本]

修改不合适时，可以对比和恢复历史版本。恢复会另存为新版本，原有记录继续保留。

[第 24 页] [停留在最后的说明区域；以下属于后续计划，不作为已完成能力介绍]

以上就是最后一公里的设计，后续还需要补充几个实际使用中的问题。

比如用户离开页面后，任务完成怎么提醒；文件和历史版本积累以后，怎么删除和管理。

另外也需要和研发讨论成本：执行时哪些上下文需要保留，过程和历史版本怎么归档、清理，在可追溯和使用成本之间做好取舍。

后续验证，我会让用户实际完成一次任务，再补充要求、修改结果，看看他能不能看懂进度、把要求发给正确的对象，以及完成关联更新和版本核查。

[第 25 页] [移到：设计过程区域，简短讲，不逐个介绍工具]

设计过程中，我先用插件提取页面的基础框架，再手动搭完整体结构；也用 AI 辅助细化需求、探索局部方案，再转成可编辑内容继续调整。

过程中主要还是由我判断信息分层、操作对象和更新范围。

我的汇报到这里，谢谢。

[第 1 页]

“这个项目是快手内部的 AI Agent MyFlicker，产品形态可以类比 Codex、WorkBuddy

它的前身 CodeFlicker 是一款面向研发人员的 IDE 产品，这次需要升级为面向全体员工的 AI 工作伙伴。我主要负责开箱、生成链路交互和品牌感知的完整重构。

这个项目的核心不是换一套界面，而是当产品的用户从研发人员变成全体员工以后，产品应该如何跟着升级。”

[第 2 页]

从业务角度，这次升级希望建立一个能够接入内部知识和公司能力的统一 AI 入口。

对员工，希望减少工具切换和学习成本；对组织，希望把常用 Skill 和内部知识沉淀为可复用的资产；对平台，则希望提升 MaaS 能力的复用和 Token 使用效率。”

[第 3 页]

但统一入口还不够，产品也要适应新用户。原来主要服务研发，核心任务是 Coding；面向全员以后，还需要覆盖写作、分析、设计和办公自动化。

这些用户不一定理解 IDE，也不一定知道如何配置工具。因此，我需要重新梳理他们从认识产品、开始任务到获得结果的完整路径，同时保留研发用户需要的专业能力。

[第 4 页]

“为了看清当前使用情况，我们做了 194 份问卷和 7 位访谈。

研究有三个关键发现：第一，研发用户渗透率超过 80%，非研发用户不足 20%；第二，通用办公需求已经不低于 Coding，文档写作占 58.3%，Coding 和 Review 占 44.7%；第三，在通用场景中，用户更常选择 ChatGPT、Kimi 等产品，CodeFlicker 只占 7%。

这说明公司内部并不缺少 AI 需求，但原产品还没有进入很多非研发用户的选择集合。”

[第 5 页]

“访谈进一步发现，不同角色最一致的第一印象是‘这是程序员的工具’。在真正使用前，用户就已经判断它不适合自己。

进入产品以后，模式入口多、Skill 和 MCP 等技术概念难理解，又让他们不容易开始。使用中还有生成反馈不足，输出质量也会影响体验。”

[第 6 页]

“基于这些发现，我们把用户分成技术和非技术两类：技术用户关注任务连续性、上下文和执行效率；非技术用户更关注能不能快速理解、顺利开始并得到可信的结果。带着这两个要求，去看竞品如何组织完整任务链路”

[第 7 页]

“竞品中，这里重点讲codex和Qoderwork的全链路调查， Codex 主要关注如何降低任务启动成本”

[第 8 页]

“QoderWork如何建立过程预期”

[第 9 页]

“再结合办公任务旅程，我把机会点定义为：做一款能够接入内部知识、聚合公司能力，并承接完整办公任务的 AI 工作伙伴”

[第 10 页]

“基于前面的研究，确定了三个目标：让用户理解产品、顺利完成任务、并在过程中建立对 AI 的信任。接下来我围绕这三个目标讲设计决策。”

[第 11 页]

“第一个目标是让用户理解产品，开箱需要说明它能帮用户做什么，并引导用户配置能力。”

[第 12 页]

“具体流程分三步：先说明 MyFlicker 是谁、能做什么；再选择角色和高频任务；最后把这些选择转成可调用的 Skill。让用户第一次进入时，就有一个与自己工作相关的起点，”

[第 13 页]

“移动端采用同一逻辑，只进一步压缩步骤和信息量。”

[第 14 页]

“角色技能配置需要让用户看得懂、选得顺。所以我比较了卡片形式、是否命名、技能排布和选择后的反馈。”

[第 15 页]

“在桌面端，需要同时承接能力选择和伙伴认知，所以采用左右布局：左侧先选角色、再配置 Skill，右侧展示伙伴形象和擅长的工作。”

[第 16 页]

“同样的配置放到手机上，一屏信息较多，更需要保证选项清楚、方便点击。左右布局改为纵向：上方展示伙伴形象，下方依次选择角色、配置技能和确认。”

[第 17 页]

“除了布局，角色本身也需要帮助用户理解能力。我们通过 MECE 将 Skill 组织成四类工作伙伴。让用户先判断需要怎样的伙伴，再由系统预置相应能力；角色也为 AI 的回应提供相应的表达语境”

[第 18 页]

“角色只是推荐起点，不能限制用户之后的工作。因此，推荐技能可以增减，让用户在容易上手的同时，保留调整空间。”

[第 19 页]

“第二个目标是重构核心交互链路，包括真实任务路径、首页框架和生成中交互。”

[第 20 页]

“我先以一个设计任务为例，串联用户从表达需求、补充信息、调用能力到获得结果的全过程，用它确认产品需要提供哪些入口、反馈和控制。”

[第 21 页]

“先看任务从哪里开始。首页把品牌和输入区集中在中间，方便用户直接表达需求。左侧则承接快捷功能、分组和历史任务”

[第 22 页]

“首页还需要兼顾两类用户。所以使用 Work 和 Code 两种模式。让非技术用户从办公任务开始，也让研发用户继续使用原有工程能力。两种模式共享品牌和任务状态，保持产品整体的连续感。”

[第 23 页]

“进入任务以后，还要考虑用户中途离开的情况。任务往往无法一次处理完，因此设置分组、进度和历史记录，让用户回来后能找回任务、确认状态，并沿着原有上下文继续处理。”

[第 24 页]

“前面解决了任务的开始和找回。对于暂时没有明确需求的用户，还需要提供灵感，所以接下来回到输入区，展开灵感入口的设计。

这里主要比较入口铺开和收敛两种方式：用户需要时是否好找，不需要时又会不会挤占主要对话空间

[第 25 页]

最终把灵感收在输入区的图标中，点击后用弹窗展开。这样，用户需要时能浏览和查找较完整的内容，平时则减少对主对话流的占用。

[第 26 页]

“同样在任务输入阶段，模型状态的表达也需要清楚。pm给出的方案是使用感叹号标记异常，但它容易被理解成禁用、报错，甚至让用户觉得平台不稳定。所以我们把表达改为更中性的状态信号”

[第 27 页，稍微停留]

“任务发出后，用户怎样跟进生成过程是这部分的重点。第一版直接沿用了 IDE 的思考链，但在全员办公场景里有两个明显问题：没有调用工具时，缺少明确的生成提示，用户会感觉产品卡住；思考链也无法整体收起，占用了大量正文空间。”

[第 28 页]

“所以我结合竞品重新调整信息层级。我们的目标不是展示全部技术过程，而是让用户知道进行到哪一步、调用了什么、是否还需要等待，以及什么时候需要介入。”

[第 29 页]

“最终框架围绕可控、可跟随、可回溯展开。执行步骤可见，工具和阶段产物可以展开，关键节点允许用户确认；任务完成后也能回看过程和来源。

同时，我们加入 IP 动效和状态文案，明确告诉用户系统仍在生成、并没有卡顿，从而降低等待焦虑。这一版在公司内部也获得了比较积极的反馈。”

[第 30 页]

“第三个目标是通过统一的视觉语言和状态反馈建立信任。”

[第 31 页]

“我结合快手品牌和用户偏好，把视觉关键词收敛为亲和、灵活和智能。亲和降低非技术用户的距离感，灵活对应 AI 能力的动态组合，智能则需要体现产品的能力和效率。”

[第 32 页]

“接下来进行了竞品视觉分析。对比 Lovable 和 QoderWork 、WorkBuddy等 产品的形态、色彩与 IP 表达。

圆润形态和渐变色更容易传达亲和感，但具象机器人也容易同质化。因此，我们保留液态、渐变和轻量 IP 的方向，再结合快手品牌形成自己的表达”

[第 33 页]

“IP 贯穿开箱、首页和生成过程，并随思考、工具调用和任务完成改变状态，让品牌感知和功能反馈被放在同一套体系里。”

[第 34 页]

“上线后，我们也针对一些数据做了回溯。比如，首次任务创建率提升了 71.8%，首次任务完成率也达到 82.6%，分别帮助我们判断用户能否顺利发起任务，以及任务链路能否支持完成工作”

[第 35 页]

“这个项目让我认识到，设计 AI 产品既要让技术用户看到深度，也要让普通用户感受不到复杂。对于非技术用户，第一次成功完成任务，本身就是留存前提。

同时，AI 可以提高设计执行效率，但问题定义、方向取舍和最终质量仍然需要设计师负责。”

本项目共 30 页。重点讲清楚“为什么做、为谁做、四个目标如何解决完整链路”。竞品、样式探索和移动端细节边说边翻，不逐项念页面。

[第 1 页]

“第二个项目是百度内部孵化的 AI 播客平台音秘 AudioMyst，用户可以克隆自己的音色，并用文字、文件或链接快速生成播客。

传统播客从选题、脚本到录制剪辑，通常需要三到四天；音秘希望把这个过程缩短到几分钟。比如自媒体创作者可以用自己的声音快速发布内容，学生也可以把论文和资讯转成更容易理解的解说音频。

我在这个项目中担任设计 Owner，负责从产品定位、用户研究、完整创作链路到跨端体验和内容运营的 0.5 到 1.0 体验升级。”

[第 2 页]

“接手项目后，我先对齐它在百度 AI 生态中的位置。当时百度已经覆盖文生图、文生视频等 AIGC 方向，但语音生成应用仍有空白。音秘一方面补齐语音内容生产能力，另一方面也能通过真实创作和消费数据反哺语音模型。”

[第 3 页]

“当时产品处在 0.5 的内部探索期，已经有底层能力、基础功能和初步视觉，所以我没有重新定义所有内容，而是围绕核心功能和 AI 生成链路，确定为一次全体验升级。

目标分为用户和业务两侧：用户侧提升播客制作效率；业务侧实现增长、变现，并拓展百度 AI 生态。”

[第 4 页]

“早期产品采用 PGC 和 UGC 混合模式，但没有清晰的用户分层，因此功能方向比较模糊。为此我主导完成了 58 份问卷、5 位深度访谈、3 个社群观察和两次线下地推。

研究发现，主要问题集中在生成状态不清楚、创作功能不完整、路径繁琐、移动场景不顺畅，以及生成后缺少持续使用的理由。”

[第 5 页]

“最终我们明确了两类核心人群。第一类是自媒体创作者，他们时间紧，希望低成本、快速地完成从内容输入到发布；第二类是播客爱好者，其中学生占比较高，他们希望把论文和资讯转成音频，并且需要字幕、进度、连续播放等基础收听能力。

这两类用户分别代表生产和消费两端，也决定了项目不能只优化生成按钮，而要处理完整的内容链路。”

[第 6 页]

“竞品研究分成两轮：第一轮扫描了 10 款 AI 播客产品，第二轮再从三个赛道各选一个代表产品拆解。

ListenHub 代表专业生产型，启发是进度可视和脚本编辑；豆包代表轻量日常型，优势是简单和移动端效率；NotebookLM 代表深度研究型，启发是章节化和生成后的互动。这里我重点关注的不是功能数量，而是它们怎样服务不同任务深度。”

[第 7、8 页]

“结合研究和竞品，我把现有链路按生成前、生成中和生成后重新梳理。最后收敛成四个问题：生产力不足、等待时缺少掌控感、跨场景体验不完整，以及生成后缺少留存动力。”

[第 9 页]

“对应地，我提出四个设计目标：提升创作流畅度、增强生成进度反馈、提升跨端体验一致性，以及构建内容留存驱动力。下面主要讲这四个目标中最关键的设计决策。”

[第 10 页]

“第一个目标是重构从内容输入到发布的 AI 播客创作链路。”

[第 11 页]

“我把链路分成生成前的输入配置、生成中的收听编辑，以及生成后的分享和生态操作，确保创作不是在音频生成出来时突然结束。”

[第 12 页]

“首先是首页。原来文字、文件和链接是三个割裂入口，音色和参数也需要多次跳转。我把输入方式合并进同一个对话框，并把主播、背景音乐和时长等配置集中在生成前，让用户在一处完成内容和参数准备。”

[第 13 页]

“其次是脚本编辑。很多平台只能听结果，创作者无法继续修改。我对多种编辑形式做了探索，最终采用分段卡片，让用户清楚看到说话人、可编辑范围和当前状态，修改后可以重新生成对应音频。”

[第 14 页]

“为了支持海外内容，我们还定义了界面语言和生成语言的切换规则，并针对外文长度做自适应，避免把‘使用什么界面’和‘生成什么语言’混在一起。”

[第 15 页]

“生成完成后，用户可以继续下载、分享和生成二维码，补齐内容发布环节。整套链路上线后，AI 生成转化率提升了约 25%。”

[第 16 页]

“第二个目标解决 AI 生成过程中‘不知道是否还在工作’的问题。”

[第 17 页]

“视觉方向上，我根据两类用户的偏好和 AI 产品的状态表达建立情绪板，最后形成偏科技、动态但不过度复杂的设计语言。这一页主要是方向推导，我会快速带过。”

[第 18 页]

“真正落到交互上，我把状态反馈放在用户刚刚点击的生成按钮附近，并呈现当前阶段、预计时间和停止生成入口。生成期间也允许用户进入播客广场收听内容。核心不是增加动效，而是让等待可见、可预期，也允许用户中止。”

[第 19 页]

“第三个目标是移动端适配、双色模式和碎片化收听体验的一致性。”

[第 20 页]

“移动端不是把桌面端等比缩小。我保留相同的任务逻辑，但重新评估屏幕空间、操作优先级和触达方式。例如生成页优先呈现输入和核心配置，低频参数通过分层方式展开，音色定制则作为高识别入口单独呈现。”

[第 21 页]

“字幕无法像桌面端一样和播放器长期并排，所以最终把字幕入口放在右上角，同时用状态球反馈生成和播放状态。用户可以在音频与字幕间切换，但不会丢失当前进度。”

[第 22 页]

“登录和播客广场则统一了移动端入口、卡片结构和品牌识别，让用户从生成自然过渡到内容消费。”

[第 23 页]

“Light 模式不是简单反色。我依据 WCAG 标准重新调整颜色、描边、阴影和不同背景下的品牌色，最终沉淀 Dark 和 Light 两套组件规范，预计降低约 30% 的后续维护成本。”

[第 24 页]

“针对学生和运动场景，我增加了适合长内容的深度模式和顺序播放，使播客可以连续收听，减少用户频繁切换和操作。”

[第 25 页]

“第四个目标是让音秘从一次性的生产工具，进一步具备内容消费和回访价值。”

[第 26 页]

“市场分析说明，播客不仅有创作需求，也有稳定的收听需求；AI 又能降低持续生产内容的成本。因此我们把播客广场作为连接生产与消费的入口。”

[第 27 页]

“我独立负责了自动化日更播客的产品和设计，从用户想快速了解的科技、财经、黄历等主题出发，完成需求定义、PRD、内容规则和视觉方案。通过自动采集、生成和更新，为用户提供持续回访的理由。”

[第 28 页]

“此外，我们还围绕节庆活动持续运营，产出 Banner、弹窗、海报、动图和宣传视频。春节活动带动了约 6% 的新增用户注册转化，也让平台保持内容新鲜感。”

[第 29 页]

“上线后，我们通过 86 份满意度问卷继续验证，超过七成用户处于满意或非常满意。反馈也帮助我们继续识别音色质量、播客广场入口和移动端切换等问题，并进入下一轮优化。

[第 30 页]

这个项目让我认识到，AI 内容产品不能只设计‘输入和结果’，等待过程、修改控制、跨端消费和生成后的留存都属于核心体验。设计师的价值也不只是把功能画出来，而是把模型能力组织成一条用户愿意完成、并愿意再次回来的产品链路。”

本项目共 9 页。主线只讲三件事：为什么要把设计资产转成 Skill、这套 Skill 怎样参与真实任务、设计师在 AI 工作流中负责什么。第 6–8 页边翻边讲，不展开页面细节。

[第 1 页]

“第三个项目是 iTokens 的 AI 设计工程化实践。iTokens 是快手万擎的海外商业版 MaaS 平台。

在 mentor 带领下，把设计系统、业务组件和设计原则等服务于人的设计资产，转成 AI 能读取、调用和检查的规则，并用模型广场、开发者文档和 Blog 三类真实任务验证。最终完成了模型广场和文档的移动端适配，部分页面由 AI 生成后直接上线，整体提效约 50%。”

[第 2 页]

“传统流程里，需求、产品、设计和开发依次交接，设计意图需要经过多轮沟通和还原。

AI 介入后，执行链路被缩短，但设计工作并没有消失。设计师的职责从单纯绘制和交付方案，转向定义问题、制定规则、判断方向和验证结果。简单来说，AI 负责执行，设计师负责判断。”

[第 3 页]

“这个项目最核心的策略，是把组件、Token、业务边界和验收标准转成 AI 可读取、可执行、可验证的 Skill，也就是一组结构化的 Markdown 规则。

它不只是告诉 AI 页面长什么样，还要说明什么场景使用、组件怎样组合、哪些边界不能突破，以及生成以后怎样判断结果是否正确。这样设计资产服务的对象就从人扩展到了 AI Agent。”

[第 4 页]

“这套 Skill 不是一个固定页面模板，而是一套根据任务动态检索和组合规则的决策框架。

它会先识别任务粒度、目标用户和操作路径，再明确设计目标和关键决策；之后调用视觉、结构、交互、业务组件、可用性和文案规则，最后用同一套标准做设计评测。这样规则可以适应不同任务，而不是每次只复制一个已有页面。”

[第 5 页]

“在真实任务中，我把流程串成五个关键环节。首先由 AI 帮助整理 PRD、业务上下文和竞品信息；然后调用知识库和 Design.md 生成首版可运行方案。

接下来由设计师校准业务逻辑、信息结构和特殊样式，再把代码推送到仓库并部署验证；最后用评测结果定位问题，并把有效经验回补到规则里。

AI 缩短的是执行链路，但需求是否理解正确、方案是否符合业务、哪些结果可以上线，仍然需要设计师在关键节点判断和收敛。”

[第 6 页]

“基于同一套规则，我完成了模型广场和开发者文档两个不同信息场景的响应式方案，并推进到可运行版本。

模型广场的重点，是在有限屏幕里兼顾模型信息密度和筛选效率；开发者文档的重点，则是让用户阅读长内容时始终知道当前位置，并能快速切换相关内容。这也验证了 Skill 不是只能生成一种页面，而是可以根据不同任务调整决策。”

[第 7 页]

“这里还遇到一个很真实的问题：本地环境没有真实数据，生成出来的页面无法验证信息密度和边界。

所以经过多轮研究后，发现把 Staging 环境的登录态同步到本地验证环境，让页面在真实内容下运行。这个过程也说明，能生成页面不等于完成设计，真实数据验证才是上线前的关键一步。”

[第 8 页]

“Blog 是一个新增模块，而且内容会持续更新。如果只交付一张静态首页，后续运营仍然需要反复找设计和开发。

所以我让 AI 输出了可复用的数据结构和样式代码，同时制作设计稿兜底，把它从一次性页面变成能够接入动态数据、持续运营的模块。”

[第 9 页]

“这个项目让我确认，AI 不仅能提高执行效率，也让设计师更早参与实现和验证。可运行的方案能把原来没想清楚的业务边界和使用问题暴露出来，帮助我更快形成判断。但 AI 也可能沿已有信息快速收敛，缺少对隐性业务、历史决策和具体用户感受的理解。因此，设计师仍然需要理解需求、做策略和审美取舍，并对最终质量负责。”

本项目共 11 页。主线只讲“为什么要把跨角色验证收回平台、如何降低配置成本、如何提升执行与分析效率”。页面中的字段、尺寸和全部备选方案不逐项念。

[第 1 页]

“第四个项目是快手万擎的应用评测体验设计。它服务于运营和算法人员，用来批量验证一个 AI 应用在真实数据集上的输出质量。

我负责从问题梳理、竞品研究到配置、执行和结果分析三段核心链路的体验重构。

这个项目的重点在于把原来依赖运营和研发协作的验证过程，沉淀为运营可以独立完成的闭环。”

[第 2 页]

“原来运营搭建完应用后，无法直接批量验证效果，需要找研发临时写脚本，再由运营人工核对结果。

这带来三个问题：第一，业务验证依赖研发排期；第二，配置和执行分散在不同工具里，每轮都要重复沟通；第三，结果缺少统一沉淀，发现问题后也很难快速重新评测。

所以设计目标是把配置、验证、执行和分析收回同一平台，减少等待和重复操作。”

[第 3 页]

“我对比了 Coze、阿里云百炼和百度千帆的评测链路。得出三点启发：评估器需要先试运行再沉淀为资产；复杂配置要支持分层展开；结果页既要看整体趋势，也要能继续定位具体 Case。

[第 4 页]

“我把完整流程梳理成九步，从准备数据集和评估器，到配置任务、试运行、全量执行、查看指标、筛选 Case，再回到应用或 Prompt 调整。

本次设计聚焦在任务配置、任务详情和评测结果三个主要页面，其余模块用于支撑完整链路。”

[第 5 页]

“对应地，我把目标收敛为更快完成配置、更早发现执行问题，以及更快定位评测问题。下面按配置、执行、分析来讲。”

[第 6 页]

“配置页最大的挑战是数据集、应用、评估器和运行方式存在明确依赖。我没有把它们并列堆在页面上，而是按照用户完成任务的顺序组织：先选数据集，再选应用和评估器，最后决定是否试运行。

后续选项会根据前面的配置逐步开放；如果数据集已经包含应用输出，用户也可以关闭应用执行。字段映射直接嵌入对应配置区，减少跨模块理解和反复确认。”

[第 7 页]

“在信息呈现上，我探索了不同层级、顺序和映射样式，最终默认展开当前最需要处理的内容，把固定信息和可配置项区分开；在字段很多时，限制单个区域高度，避免一个应用把整页无限撑长。

评估器还会补充描述和适用模型，因为这些信息会直接影响用户是否选对，而应用头像等低价值信息则被弱化。”

[第 8 页]

“任务创建后，详情页需要让用户快速复核整套配置。我延续卡片结构，用双列布局承载多个对象，用标签直接表达字段映射，并通过等高和局部滚动平衡完整性与页面密度。让信息可扫读、可核对，也能在复杂场景下继续扩展。”

[第 9 页]

“第二个目标是把问题暴露在全量执行之前。

我在两个层级加入试运行：新建评估器时，可以用真实字段快速检查评估逻辑；配置任务时，也可以先抽取少量样本验证应用、字段映射和结果是否正确。试运行结果会把评估结论和原始输出并排呈现，用户既能看分数，也能回看实际内容。确认无误后再全量执行

[第 10 页]

“第三个目标是缩短从整体结果到问题 Case 的分析路径。

我把结果分成三个层级：先在任务结果里掌握整体表现，再按评估器和指标查看各维度差异，最后进入具体 Case 查看输入、应用输出和评测结果，并完成人工标注。

图表适合快速看分布和异常，表格适合核对具体数值，所以两种视图可以切换。这样不同分析意图都能在一条链路里完成，而不需要导出后再手工拼接。”

[第 11 页]

“这个项目在我提出离职后上线，所以还没有一些数据支撑，但希望能得到一些指标的支撑

它让我更明确，复杂 B 端设计的价值不是把所有字段都展示出来，而是把依赖关系、验证节点和分析层级组织清楚，让专业用户在保留控制权的同时减少认知和协作成本。”

Q1 有什么优势：

我觉得自己比较突出的优势，主要有三个。

首先，我有贴近这个岗位的云和 AI 产品经验

在快手，我参与过 MaaS 平台的界面与交互设计，也做过面向内部员工的通用 AI Agent；在百度，我参与过 AI 播客，以及 MaaS 平台基础设施相关产品的设计。这些经历让我对 AI 产品从底层平台到应用层的使用场景都有一定了解，也积累了处理复杂交互的经验，能帮助我更快理解火山的业务和用户。

第二，我能把需求理解、设计和 AI 辅助实现连接起来。

在百度时，我是在产品经理+研发的团队中工作，参与过 需求梳理和PRD 编写。也会借助 AI，把设计方案进一步做成可以运行的产品。

也用vibe coding的方式做了很多产品，比如我在快手和mt一起做了一个能对接工程并实际上线的平台skill，以及围绕营销需求，全流程的设计了一个营销平台及skill。

第三，我会主动发现需求之外的机会，并提出自己的判断。

比如之前我们万擎做数字员工，产品需求是沿用另一个平台的头像。我注意到，数字员工出现在 IM 场景里，是一个很好的让用户认识万擎的一个接触点，所以提出设计一组属于万擎的头像，希望把这个触点也用于建立品牌认知。

在团队讨论中，我也会保持这种习惯：先理解需求背后的目的，发现问题或有更合适的方案时，主动提出，再和团队一起推进。

Q2 在快手和百度的两段实习中 最大的收获是什么

我觉得这两段实习给我带来的收获比较多，主要可以从四个方面来说

第一是设计思维。在实习过程中，我深度参与了产品的全流程设计，因此，在判断用户需求、理解业务目标，以及从产品视角思考问题等方面，都得到了比较充分的锻炼。我现在看待一个设计需求时，会结合用户、业务和产品的关系来做判断。

第二是对 AI 的理解。尤其是在快手，我直接参与了 MaaS 平台及 AI 相关产品的工作，因此，对前沿 AI 技术、不同模型之间的差异，以及多 Agent 协同、Coding 等能力，都有了更深入的理解。这让我在做 AI 产品时，能够更好地理解技术特点与产品体验之间的关系。

第三是设计基本功。通过实际项目，我的交互设计和视觉审美能力都得到了进一步锻炼，能够将对问题的理解落实到具体的设计方案中。

第四是团队协作。实习中的项目推进，让我在与团队沟通、协作方面也获得了锻炼。

Q3 你在快手主要做了什么 有哪些贡献和价值

在快手，我的工作主要分为三个部分。

第一是 MaaS 平台及相关产品的设计，包括国内和海外版平台，也涉及官网和中台。我承担了具体项目的界面与交互设计，其中部分项目独立负责，从理解需求、形成方案，到交付和工程衔接。这个部分主要是支持平台能力的产品化，让用户能够理解和使用这些能力。

第二是内部 AI Agent 产品 MyFlicker。这是从面向研发的 CodeFlicker，升级为面向全员的 AI 工作伙伴。我主要负责开箱和生成链路的交互重构，并参与品牌感知的方案探索。我的贡献主要是围绕非技术用户的使用障碍，重新组织产品认知、能力配置和执行反馈，让用户更容易开始任务，也能理解和跟进生成过程。

第三是团队工作方式的沉淀。在导师带领下，我参与了产品设计的 AI 化探索，把已有规则、设计规范，以及与工程衔接的内容整理成可调用的 Skill。把项目中的经验转成能够重复使用的能力，减少重复整理，也让后续设计与实现有更一致的依据。

所以，这段实习中，我既有具体产品项目的设计交付，也参与了团队方法和工具的建设。

Q4 描述一个你参与过的有挑战性的项目，并陈述你的执行过程。

我想讲一次灰度配置功能的设计。它的挑战主要有两个：一是需要把已有业务组件扩展到新的使用场景；二是涉及四位产品经理、四项需求，需要梳理不同场景的差异，确认各自的使用方式。

这次需求希望把灰度配置直接放在页面中，并支持自适应。我先围绕当前需求设计方案，并和 mentor 讨论。后续相关需求进来时，我们发现，过往有一个需求做过类似功能，但它只使用过一次，没有沉淀到组件库中，而且主要用于下拉和弹窗，不能直接满足这次页面内嵌的要求。

因此，我需要进一步比较：已有方案中哪些可以复用，哪些需要针对新的承载方式调整，同时兼顾另外几项需求。

评审时，部分需求方未能到场，涉及不同场景的使用边界也没能当场确认。会后，我把方案组合、适用场景和选择理由集中整理到 Figma，让后续讨论有共同的依据。

然后在下一轮的会议时，我们基于这份材料逐项讨论，确认各场景的使用方式。我再按照结论，重新梳理四项需求对应的页面，最终这些需求都完成了上线。

这次经历让我更明确，跨场景复用需要判断组件原有的适用边界，以及新需求带来的变化。同时，多方评审需要把方案差异、选择依据和待确认的问题呈现清楚，帮助大家形成结论，再落实到具体页面。

Q5 熟悉maas平台熟悉到什么程度

我对 MaaS 平台的熟悉，主要体现在产品功能、用户操作流程，以及相关的业务约束上。

从接触范围来说，在快手，我参与的是万擎平台面向使用者的界面与交互设计，也做过内部通用 AI Agent 工具；在百度，我接触过资源管理等基础设施相关产品。所以，我既有用户侧的设计经验，也接触过支撑平台运行的管理类产品。

从熟悉程度来说，在自己负责过的需求范围内，我能够理解功能为什么要做、用户需要哪些信息、操作有什么前置条件，以及它与其他功能的依赖关系。这些理解会直接影响交互设计，比如什么情况需要确认、应该提示哪些影响，以及不同状态下提供什么操作。

日常比较明确的需求，我可以根据业务规则完成设计；遇到复杂流程，我也会进一步判断产品原型是否存在体验问题，并和产品、研发讨论调整。

所以，我比较有把握的是实际参与模块的业务和交互逻辑，也有迁移到其他平台需求的经验。具体可以结合我作品集中的万擎项目展开。

Q6 AI 让界面越来越少，体验设计师的价值在哪里？

我认为，界面减少并不意味着体验设计师的价值减少。界面只是把我们对产品体验的思考，落实为具体呈现的一种方式。作为体验设计师，我们需要为用户体验和业务负责。

第一，设计思维和产品判断依然重要。我们仍然需要理解用户要完成什么任务、业务希望达成什么目标，判断真正需要解决的问题，并在用户需求、技术能力和实现成本之间做取舍。这些思考不会因为界面减少而消失。

第二，AI 产品也需要完整的交互体验。它需要确认用户意图、展示执行过程、处理异常。这些环节如何组织，用户怎样理解、参与和调整，都需要设计师把关，而不只是把结果呈现出来。

第三，AI 时代还会带来新的体验问题，比如如何构建用户的信任感和安全感，如何组织多个 Agent 的协同，以及如何把控 AI 的行为。这些都与体验直接相关，也都是设计师需要持续承担的工作。

Q7 你对 AI 有什么看法？AI 会替代设计师吗？

我觉得 AI 是一个很好的工作伙伴。它提高了执行效率，也让设计师有机会参与更完整的构建过程。我主要从三个方面理解。

第一，AI 拓展了设计师参与的范围，也让设计与工程重新连接起来。这让我想到达芬奇那种把设计构想与工程探索结合起来的工作方式：设计师既要提出想法，也要理解它怎样被实现。现在，AI 降低了上手工程的门槛，让我们可以边做边学，从负责某个环节，走向参与需求、设计、开发和验证的完整过程。比如在 AdLume 项目里，我就借助 AI，把需求梳理、交互和视觉设计、网页开发与部署串了起来。

第二，AI 加快了形成判断的过程，但不能替我们完成判断。方案进入实际开发和使用以后，原本没想清楚的依赖关系、异常状态和使用问题，会更早暴露出来，帮助我们及时调整。不过，AI 也可能顺着我们的输入方向继续生成，或者沿用一些熟悉的模式。所以设计师仍然需要主动质疑和判断：这个需求是否成立，方案有没有遗漏，是否值得继续投入。

第三，设计师对具体用户的共情和情境理解，仍然是 AI 目前难以替代的。用户的痛点、情绪和使用感受，很难仅靠一组量化指标说明，需要结合真实场景去理解；业务中的隐性约束和历史决策，也需要设计师补充给 AI。

所以，我更希望和 AI 一起学习、一起思考。在不熟悉的领域，可以先借助它检索和梳理信息，再结合自己的判断推敲方案，并通过实际实现和验证继续调整。对我来说，这不仅提高了效率，也缩小了“想得到”和“做得到”之间的距离。

Q8 你的职业规划是什么

我希望成为一名精通 AI、了解不同模型特点，同时具备商业与策略能力的全链路产品体验设计师。

如果有机会加入火山引擎团队，我会分三个阶段推进。

第一阶段，先扎实地了解团队和产品。包括团队典型的工作模式、协作方式和 SOP，产品主要服务什么用户，以及当前模型有哪些特点。我会先从较小的需求开始，保证交付质量，逐步建立对业务和协作的理解。

第二阶段，我希望成为业务驱动型的设计师。AI、模型和 Coding 都是工具，关键是能否通过这些工具创造业务价值、带来更好的体验。因此，我希望逐渐承接更完整、更大的需求，用设计推动业务进展与增长，并支持实际商业化产品的推广和销售。

长期来看，我对 AI，尤其是企业级 AI 服务方向很感兴趣，这也与我此前选择快手 MaaS 平台相关经历的方向一致。我希望能够持续深耕这个领域，积累行业理解，逐步成长为能够在这一方向上提供专业判断的设计师。

Q9 如果给offer会来吗

会的，这个机会在我的求职选择里优先级很高。

首先，岗位和我过去的经历比较契合。我参与过 MaaS 平台、AI Agent 工具和 AI 应用，希望继续在这个方向积累，也有信心把已有经验用到实际工作中。

第二，我很看好字节在 AI 方向的发展，也希望有机会参与前沿产品，探索新的交互方式。

第三，我认可字节的平台，也期待在实际业务和团队协作中进一步提升自己的产品判断、设计和落地能力。

Q10 你的缺点是什么？还需要提升什么？

我目前比较需要提升的是，面对比较强烈的不同意见时，沟通方法还不够灵活。

有时候我会连续几轮解释自己的设计理由，但如果一直没有达成一致，就会请 mentor 一起判断。回头看，我应该更早识别讨论为什么卡住，再换一种方式推进，比如用具体场景、方案比较和实现约束来讨论。

之前灰度配置的需求中，我后来把不同方案和理由都整理到 Figma，和几位产品一起确认。这让我意识到，把选择和依据摆清楚，比反复解释同一个方案更有帮助。这也是我希望继续提升的地方。

Q11 你怎么理解这个岗位？

我理解这个岗位，需要把企业级产品或 AI 产品中的复杂能力，转化成用户能够理解和顺畅使用的体验。

具体包括理解业务与用户任务、梳理信息架构和流程、完成交互和视觉，并和产品、研发一起处理落地中的取舍。AI 产品还会涉及生成过程、不确定结果、异常处理和成果修改等问题。

所以我认为，除了设计基本功，还需要产品理解、协作推进和验证意识。我的平台设计、AI 应用和个人开发实践，可以为这些工作提供相关经验。

Q12 为什么选择火山引擎？

首先，从这份 JD 看，企业级产品和前沿 AI、Agent 产品都是团队关注的方向，与我过去的平台和应用经验比较契合。

其次，我很看好字节在 AI 方向的发展，希望有机会参与相关产品，探索新的交互方式。我也认可字节的平台，期待在实际业务和团队协作中继续提升。

另外，杭州符合我的工作地点偏好。所以综合岗位、发展方向、平台和城市来看，这个机会对我有很强的吸引力。

Q13 最大的失败经历是什么？

我想讲一次灰度配置功能的设计评审。这次让我意识到，自己在跨场景方案梳理和评审前对齐上还有不足。

最开始我以为这类样式没有现成方案，就做了新方案，并和 mentor 沟通。大约一个月后，新的相关需求来了，我才发现其他场景已经做过类似功能。但旧样式与新的页面内嵌、自适应场景又不完全适配，因此需要重新讨论。

这次涉及四位产品和四项需求，其中有旧需求，也有三项新需求。我已经和两位产品确认过，但其他相关方的休假和反馈时间影响了对齐，关键相关方也没有完整参加初次评审。我当时判断可以先在会上看其他部分、之后统一调整，但对尚未达成一致的部分准备还不够充分，现场出现了分歧，我的沟通也比较被动。

会后，我把各方案的组合、适用场景和理由整理到 Figma。下一周相关方回来后，我们一起讨论并确认使用方式。我再按照确认后的样式重新梳理四项需求对应的页面，最后这些需求都上线了。

回头看，我需要承担的部分是：前期对已有方案摸排不够充分，评审前对未决问题的处理也不够清晰。如果重新处理，我会先确认已有设计及其适用场景，把方案比较提前准备好，并明确哪些内容还没确认、需要谁参与决策。

Q14 和产品或研发发生分歧怎么办？

我会先确认分歧来自哪里，以及各自最关注什么，再围绕具体问题比较方案。

比如产品可能更关注业务目标和时间，研发可能更关注实现成本，设计侧则需要讲清楚用户在什么场景下会遇到什么问题。必要时，我会把不同方案、适用场景和代价整理出来，让大家基于同一份信息讨论。

之前灰度配置的需求，我就是在初次评审没有形成一致后，把方案和理由整理到 Figma，再和相关产品一起确认，最后推进上线。

如果仍然无法达成一致，我也会带着分歧点和已有依据，请 mentor 或负责人协助判断。确认方向以后，再把方案和后续动作落实。

Q15 如何缓解工作压力？

我会先判断压力主要来自任务量、时间限制，还是问题不够清楚，然后分别处理。

如果任务比较多，我会先确认优先级和交付时间，把工作拆成阶段；如果有不确定的地方，就尽早澄清，避免一直带着疑问推进。发现进度可能受影响时，也会及时沟通，让团队一起判断取舍。

工作之外，我会通过看小说、唱歌等方式切换状态，给自己一些放松的时间。

Q16 能接受加班吗？

可以接受。我在快手实习期间有配合团队节奏、在较晚时间完成工作的经历，对这样的工作节奏有实际了解。

如果项目节点需要集中推进，我愿意配合，也会关注优先级和交付，尽量减少反复修改和返工。

Q17 为什么离开上一段实习？

我在快手实习了六个月，到九月时，需要集中准备秋招。同时，当时团队有组织调整，留用的 HC 还没有明确，所以我希望给自己留出时间，了解和争取更适合的正式岗位机会。

这段实习让我积累了企业级平台和 Agent 产品的设计经验，也让我更明确接下来希望继续发展的方向。结束实习是结合求职时间和岗位安排作出的选择。

Q18 兴趣爱好是什么？

工作之外，我比较喜欢看小说和玩剧本杀，因为我喜欢推理、分析线索的过程。平时也会唱歌、看电影和漫画，给自己换一种状态。

我还对塔罗和画画有兴趣，之后希望尝试做一个塔罗插画的个人账号，把兴趣和创作结合起来。

Q19 最有成就感的一件事是什么？

最近比较有成就感的一件事，是从零到一完成百度的测试题项目，并把它做成能够访问和交互的网页。

这次我需要自己梳理产品思路、设计交互，也需要关注视觉完成度，还要思考怎样把整个设计过程整理成作品集，让别人理解我的判断。我借助 AI 推进实现，再持续检查和调整。

让我有成就感的是，我把产品思考、交互、视觉和实现串了起来，最终形成了一个能够展示和操作的作品。

这个过程让我对自己的能力有了更具体的认识，也让我更想继续探索产品、设计和 AI 辅助实现相结合的工作方式。

Q20 如果有幸进入团队，我主要负责哪些工作？

Q21 团队目前最希望候选人具备哪些能力？

Q22 您通常会从哪些方面判断入职初期做得比较好？如果希望做到超出预期，最关键的是哪一点？

回答时先给结论，再补 1–2 条证据。下列内容是口语参考，不建议逐字背诵；涉及原始样本结构、D7 时间窗或 CES 阈值时，以当时研究记录和数据看板为准。

项目一｜MyFlicker

研究参与范围：团队在 1.0 上线后开展研究，本人主要阅读报告。旧稿中的样本量、比例和用户引语尚需核实，下面的数据口径用于准备追问，不代表本人完成统计或已经验证这些数字。

数据口径速查

面试中先说明每个指标的分母。若以下四项是逐层转化，则不要把 67.3% 直接理解为全部首访用户的 D7 回访率。

产品策略与研究

1. 为什么不直接在原来的 CodeFlicker 上增加通用功能？

因为这次变化的不只是功能范围，而是用户、任务和心智模型都变了。原来的研发用户理解 IDE、Skill、MCP 等概念，非技术用户进入产品时首先关心的是“它能帮我做什么”。如果只叠加通用功能，工程化入口和复杂模式仍然存在，反而会增加理解成本。所以我们优先重构产品认知、任务入口和生成反馈，再承接通用能力。

2. 这轮用户研究你具体参与了什么？

这里需要说明研究的时间和分工：这轮调研是在 1.0 上线后由团队开展的，问卷处理和访谈执行由相关同事负责，我没有直接参与执行，主要阅读了团队报告。

因此，我会把它作为上线后的反馈资料来引用，和我在设计阶段自己的判断分开说明。具体样本量、招募渠道、角色比例和用户引语需要以核实后的报告为准，我不会凭记忆补充。

3. 怎么判断问题来自产品认知，还是模型能力？

我会把进入产品前的理解障碍，和实际完成任务时的结果质量分开看。入口、命名和技术概念是否容易理解，需要通过任务观察或可用性测试验证；模型效果则需要结合具体任务、输出质量和修改成本判断。

在这个项目里，我没有执行前期用户研究，不能用尚未核实的比例证明某个结论。我的设计贡献可以从产品转型目标、方案比较和具体交互决策展开；上线后的团队报告作为另一类反馈资料引用。

4. 三个设计目标是如何排优先级的？

我按照用户路径和影响范围排序：认知问题发生在使用之前，决定用户会不会进入；核心链路决定第一次任务能不能完成；信任感影响用户是否愿意持续使用。它们分别对应使用前、使用中和使用后的关键阻力，也与“找得到、能上手、能完成、愿意回来”的业务验证路径一致。

5. 为什么优先聚焦设计类非技术场景？

这是优先聚焦的场景，不代表设计师能够覆盖所有非技术岗位。设计任务会涉及文字、图片、分析和工具切换，适合检查较完整的任务链路，但不能据此推断运营、人力等角色也有相同需求。

如果继续推进，我会按实际岗位和任务补充分层验证。研究范围和样本覆盖只按真实记录说明，不把设计假设包装为已经得到验证的用户结论。

6. 用角色包装 Skill，会不会又增加一层学习成本？

角色的目的是用熟悉的工作语言提供起点，让用户先理解可以完成什么任务，再配置对应能力。推荐配置可以增减，不应该要求用户同时学习一套新的角色分类和底层技术概念。

它是否降低了理解成本，还需要单独验证，比如用户能否说清每个角色的用途、能否选到合适的能力，而不能只用整体转化数据证明这一点。

7. 四种角色真的符合 MECE 吗？用户可能同时属于多个角色怎么办？

这里的 MECE 是用于整理主要工作方式和输出偏好，不是给用户做永久、互斥的职业分类。现实用户一定会有重叠，所以角色只是首次使用的推荐起点，不是固定标签；用户可以修改能力组合，也可以根据不同任务切换。

8. 推荐 Skill 的依据是什么？如何避免替用户做决定？

推荐围绕角色对应的高频任务提供一个默认起点，同时保留增减和后续调整。具体推荐与研究资料的对应关系，需要以实际记录说明。设计原则是降低第一次选择的成本，同时让用户能够理解和修改配置。

交互方案与视觉决策

9. 既然原来模式太多，为什么最后还保留 Work 和 Code 两种模式？

问题不是产品里绝对不能有模式，而是模式过多、边界不清、命名难懂。Work 和 Code 对应两类差异明显的任务环境：一个服务通用办公，一个保留完整 IDE 能力。我们把原来的多个入口收敛为两个，并通过默认入口、场景说明和界面差异明确边界，本质上是模式合并而不是继续叠加。

10. Work 和 Code 的任务能互通吗？

原则上共享用户身份、历史任务、上下文资产和品牌状态，但操作环境特有的内容需要分别承载。设计上先保证用户能识别边界，再逐步打通可复用资产，避免为了表面统一把复杂 IDE 能力硬塞进通用办公界面。

11. 生成过程到底展示多少才合适？

我们不会展示模型的原始推理过程，而是只呈现与任务结果和用户决策有关的信息，例如当前阶段、调用了什么工具、产生了什么阶段结果、是否异常，以及是否需要用户确认。判断标准是：这条信息能不能帮助用户等待、介入、修改或停止；如果不能，就应该折叠或隐藏。

12. 你说方案获得公司内部好评，这能算结果吗？

不能把内部好评当作定量结果，它只能作为方案接受度的定性反馈。因此在汇报中我会把它放在设计过程里轻描淡写，真正的结果仍然看入口发现、任务创建、任务完成、回访和费力度等行为数据。

13. IP 会不会让企业级产品显得不专业？

关键不在于有没有 IP，而在于它承担什么功能、出现多强。这里的 IP 主要承接生成、调用工具、完成和异常等状态，不覆盖核心内容；在尺寸、动效和语气上也保持克制。它的作用是降低等待焦虑并统一反馈，而不是把产品做成娱乐化界面。

数据验证与复盘

14. 有 28.2% 的用户没有创建首次任务，问题出在哪里？

只看这个数字不能直接归因。我会继续拆分角色选择完成率、开箱退出率、首页场景点击率、输入后未发送率，并结合退出问卷或访谈判断是价值没理解、入口没看到、不会写需求，还是当时没有任务。不同原因对应的优化完全不同，所以不会凭一个漏斗数字下结论。

15. 首次任务有 17.4% 没有完成，怎么排查？

需要先区分用户主动取消或离开、模型或工具执行失败，以及交互导致的误操作。埋点上会结合任务状态、错误类型、退出节点和中途修改行为；如果集中在等待阶段，就优化状态反馈和恢复能力；如果集中在工具调用失败，就优先解决能力稳定性。

16. D7 有效回访率 67.3% 是怎么算的？会不会太高？

它不是以所有首访用户为分母，而是以前一层满足条件的有效用户为分母，所以是逐层转化。若四个指标都按顺序计算，整体从首访到 D7 有效回访约为 86.4% × 71.8% × 82.6% × 67.3% ≈ 34.5%，这个结果并不低。所谓“有效回访”还需要过滤测试账号、空任务、误触和立即取消。至于是严格第 7 天还是第 7 天时间窗，要以当时的数据看板定义为准，面试中不要猜。

17. 日活破万，怎么证明是设计带来的，而不是运营推广或模型升级？

我不会把全部增长归因于设计。日活会同时受到推广、模型能力、组织策略等因素影响。设计更直接影响的是漏斗中的入口发现、首次创建、任务完成和回访；日活破万只能说明产品已经达到一定使用规模。如果有灰度实验或改版前后同口径对照，才能进一步讨论设计的因果贡献。

18. Token 消耗占内部 AI 产品的 86%，为什么这是好指标？

Token 占比本身只说明使用规模，不等于成功。如果 Token 很高但失败率也高，反而可能意味着浪费。所以我会把它和任务完成率、回访率、低费力度一起看；更理想的指标是单位有效任务的 Token 成本，以及不同任务类型的完成质量。

19. 低费力度 85.7% 和平均费力度 1.86 是怎么计算的？

如果采用 7 点 CES 量表，1 代表非常轻松，7 代表非常费力，那么平均费力度 1.86 是所有有效答卷得分之和除以有效样本数；低费力度 85.7% 是落入预先定义的低费力区间的样本数除以全部有效样本数。平均值反映整体水平，低费力占比更直观。低费力的具体阈值必须以当时问卷设定为准，如果记不清，不要现场编口径。

20. 如果重新做一次，你最想补哪部分？

我会补两类长期验证：第一，按研发、设计、运营、人力等角色拆分漏斗，确认通用方案是否掩盖了群体差异；第二，不只看“完成了任务”，还看结果是否被修改、是否真正用于工作，以及节省了多少时间。现有数据能说明用户找得到、做得完、愿意回来，下一步需要进一步证明它创造了真实工作价值。

21. 怎样避免用户访谈中的诱导性提问？

这轮访谈并不是我主持的，所以我不会保证当时的具体执行方式。如果由我设计后续访谈，我会从用户最近一次真实任务开始，用中性问题了解过程，而不是在问题里预设产品复杂或不好用。

例如先问“最近一次用 AI 完成工作是什么，能讲讲过程吗”，再追问当时的选择、卡点和处理方式。最后区分用户原话、研究解释和设计假设，不把访谈自述直接当作行为证据。

22. LUI 和 GUI 怎样结合？未来只需要聊天吗？

在设计上，我会把自然语言交互用在表达目标、补充背景和提出修改方向上；把可视化界面用在浏览、比较、选择、查看状态和精确操作上。

例如测试题里，用户通过对话提出任务，再通过进度卡片、Agent 列表、文件树和版本对比处理具体工作。两种方式结合，才能让表达目标和控制过程都更顺畅。

23. Agent 的成本、速度和质量怎样平衡？

我会先明确任务目标和可接受的等待、预算，再和产品、研发讨论选择。界面侧可以帮助用户理解执行范围、重要的资源使用信息，以及何时需要补充确认。

对于重复执行，可以探索只更新受影响的部分，但前提是关联关系明确、结果仍然可靠。是否减少实际调用成本，需要以实现和运行数据验证。

另外，展示历史记录和把历史重新发送给模型是两个不同问题，不能直接认为隐藏或删除界面记录就节省了模型调用费用。

24. 怎样判断 Agent 产品真的有价值？

我会先定义用户要完成的任务和验收标准，再关注任务完成率、结果是否被采纳、完成时间、人工修改或介入成本，以及失败后的恢复情况。

同时考虑系统运行成本。使用次数增加可以作为线索，但不能单独证明用户价值；更重要的是有没有把工作完成到可用程度。

验证时也要控制任务难度、用户经验、模型版本和测试条件，避免把其他变化都归因于界面设计。

项目二｜音秘 AudioMyst

1. 你在音秘项目中具体负责什么？

我担任体验设计 Owner，负责从产品定位、用户研究到创作链路、跨端体验和内容运营的 0.5 到 1.0 升级。可以具体展开的贡献，是输入与配置整合、分段脚本编辑、生成状态反馈、移动端适配，以及自动化日更播客的产品和设计。

项目涉及团队协作，我会区分自己负责的方案和实现由哪些同事推进，不把整个版本的成果都归到个人。

2. 为什么不只优化生成按钮，而要做完整链路？

音秘同时服务内容生产和消费。创作者需要从输入、编辑走到分享发布，收听者需要连续播放、字幕和移动场景体验。只优化生成按钮，解决不了生成后怎样使用、修改和继续回来的问题。

所以我沿生成前、生成中、生成后梳理了创作效率、等待反馈、跨端一致性和内容留存四个方向。

3. 四个设计目标怎样排优先级？

我会先保证用户能完成核心创作，再处理过程中的等待和不确定性；跨端体验让用户在不同场景中继续完成任务，内容消费与持续更新则承接生成后的使用和回访。

优先级要结合实际卡点、影响范围与实现成本判断，不是四个目标同时铺开。每个方向都应有对应的任务和验证标准。

4. 为什么把文字、文件和链接合并到一个入口？

三种方式的共同目标都是提供播客内容。割裂入口会让用户先理解输入类型的产品结构，再多次跳转配置。我把它们合并在同一输入区，并在生成前集中准备主播、音乐和时长等参数。

输入区仍需说明不同材料的要求、识别状态和失败后的处理方式，合并入口不等于隐藏使用边界。

5. 为什么用分段卡片编辑脚本？

创作者往往需要修改具体一句或一段，并确认说话人和可编辑范围。分段卡片能够把内容、说话人、状态和操作放在一起，帮助用户理解修改影响到哪一部分。

修改后的局部重新生成，还需要与研发确认上下文、音频衔接和失败恢复的规则。不能只因为页面上有一个按钮，就声称完整机制已经实现。

6. 生成等待时间不确定时，怎样提供反馈？

我把状态反馈放在生成按钮附近，让用户知道当前阶段、是否仍在执行，以及能否停止或先做其他事。预计时间只有在系统有可信依据时才展示，避免给出虚假的进度。

停止后保留哪些内容、能否继续、异常后如何重试，需要和研发一起确认，再落实到文案和操作。

7. 移动端为什么不能直接缩小桌面页面？

移动端的屏幕、触达和收听场景不同。我保留相同的任务逻辑，但优先展示输入和核心配置，低频参数分层展开；字幕、播放进度和生成状态也需要适合单手操作与碎片化使用。

一致性主要体现在任务、状态和品牌表达，而不是两端必须使用同一套空间布局。

8. 生成转化提升、活动增长和满意度能证明什么？

这些分别反映不同问题：转化用于观察创作链路，活动注册用于观察当期增长，满意度反映回答者对体验的主观评价。面试时需要说明分母、时间窗、样本和版本条件。

不能把多项改动叠加后的变化全部归因于设计，也不能把预计维护成本下降说成已实现的收益。更稳妥的是结合任务完成、修改成本、回访和实际反馈判断，并明确归因的限制。

项目三｜iTokens AI 设计工程化

1. 你说的 Skill 和普通 Prompt 有什么区别？

Prompt 更像一次任务中的指令，Skill 则是可复用的规则资产。它除了说明要生成什么，还包含适用场景、组件与 Token、业务边界、异常状态和验收标准，并能被 Agent 在不同任务中检索和组合。我的重点不是把提示词写得更长，而是把隐性的设计判断转成可执行、可验证的规则。

2. 为什么选择 Markdown 承载，而不是直接做成页面模板？

固定模板只能复刻已有页面，很难适应不同任务。Markdown 便于人和模型共同阅读、版本管理和持续补充，也能把决策条件写清楚。页面结构仍然可以复用，但 Skill 的核心是决策框架，而不是某一张固定界面。

3. 约 50% 的提效是怎么计算的？

这个数字应按同类任务的完整工时对比，而不是只看 AI 第一次生成用了多久。通常会比较改造前后从理解需求、出首版、适配、修改到可交付版本的总投入，并排除环境搭建等一次性成本。如果当时没有严格对照实验，我会明确说它是基于项目记录的阶段性估算，不把它包装成精确因果结论。

4. ‘部分页面直接上线’是不是意味着没有设计和代码评审？

不是。‘直接上线’指 AI 生成的代码经过设计师校准、真实数据验证和研发流程检查后，不需要重新手工还原整张页面。需求判断、代码合并、测试和发布门槛都没有被取消，改变的是执行方式，不是质量责任。

5. 怎么证明这套 Skill 能泛化，而不是只适合一个页面？

我选择了模型广场、开发者文档和 Blog 三类结构明显不同的任务验证：分别强调高密度筛选、长内容导航和持续运营。如果同一套底层规则能够在不同信息场景中调用不同组件和布局，并通过统一标准检查，才说明它具备一定泛化能力。更严谨的下一步是继续扩大任务样本并记录失败类型。

6. AI 生成结果最常见的问题是什么？你做了什么？

最常见的不是视觉完全错误，而是忽略隐性业务、特殊状态和真实数据边界。例如本地假数据看起来成立，换成真实内容后可能出现密度、长度和权限问题。我通过补充规则、接入真实数据验证，并把修改原因回写到 Skill 中，让一次修正成为后续可复用的约束。

7. 同步 Staging 登录态会不会有安全风险？

这部分只在公司允许的开发与测试边界内进行，并且不把凭证写进设计资产或代码仓库。面试中我会强调目标是让本地页面读取合规的测试数据，而不是绕过权限；具体实现需要遵守内部安全规范。如果环境不允许，就应该使用脱敏快照或专门的测试接口。

8. AI 会不会最终替代设计师？

AI 很适合执行明确、可验证的任务，但它不知道组织里的隐性背景，也不能独立承担业务取舍和最终质量责任。设计师的工作会从大量重复绘制，转向定义问题、构建规则、评估结果和处理非标准场景。这个项目证明的是职责在迁移，不是判断被取消。

9. 模型广场中模型很多，怎样帮助用户选择？

我会先确认用户的任务，再组织模型信息。用户可能关心内容效果、输入输出形式、响应速度、费用和使用限制，不同任务的优先级不同。

界面可以先按任务提供入口，再支持查看模型差异、用代表性样例体验和比较。推荐结果也要说明依据，方便用户判断是否适合自己。

10. AI 做出可运行页面后，怎样确认真实实现和能力边界？

我会把设计希望实现的行为拆成具体问题，和研发确认：数据从哪里来、哪些操作能够执行、有哪些状态、失败后能否恢复，以及哪些承诺目前做不到。

比如停止是否可以继续、生成中的文件能否预览、修改后能否只更新关联部分，都需要逐项明确。然后再决定界面展示和用户预期，必要时通过原型验证。

在个人项目中，也需要区分已经真实实现的功能与演示状态，把自己的判断、AI 协助实现和实际验证过程讲清楚。

项目四｜万擎应用评测

1. 这是偏平台和产品的项目，UX 设计师的核心价值是什么？

核心价值是把复杂专业逻辑组织成可理解、可验证的任务流程。数据集、应用、评估器、字段映射和运行方式都有依赖，单纯把需求字段画出来会让配置成本非常高。我的工作是明确依赖顺序、渐进开放选项，并让配置、执行和分析形成闭环。

2. 这个项目为什么没有像前两个项目一样做大规模用户调研？

这是面向内部专业用户的明确业务需求，用户范围较窄，项目重点是梳理现有协作流程和专业配置逻辑。因此主要依据运营、产品和研发的流程访谈、需求评审、竞品链路以及原型走查，而不是用大样本问卷寻找人群。如果进入上线验证阶段，我会补充可用性测试和行为数据。

3. 为什么配置顺序是数据集、应用、评估器、运行方式？

因为后续配置依赖前一步的结构。数据集决定有哪些输入和标准答案；应用决定实际输出字段；评估器需要同时引用评测集和应用输出；最后才能确定如何抽样和运行。按依赖顺序组织，可以减少用户填到后面才发现前置条件不成立的返工。

4. 为什么应用可以关闭？这不会让用户困惑吗？

有些数据集已经保存了应用的历史输出，这时再次调用应用只会增加成本。开关不是让用户随意跳过关键步骤，而是承接两种真实数据状态；旁边需要明确说明关闭条件，关闭后同步隐藏应用选择和相关映射，保证界面与实际执行逻辑一致。

5. 字段映射为什么不单独做一个步骤或弹窗？

字段映射依赖当前应用和评估器的上下文。如果拆成独立步骤，用户需要反复记忆来源和目标，也不容易发现配置遗漏。我把它放回对应对象内部，用来源到目标的方向表达关系，使用户在配置对象时就完成核对。字段非常多时再通过局部滚动控制页面长度。

6. 详情页为什么选择双列卡片，而不是表格？

详情页的任务是复核不同类型、不同字段量的配置对象。表格适合同构数据，但应用和评估器的信息结构并不完全一致；单列卡片又会让页面过长。双列卡片能保留对象边界并提高横向利用率，再配合等高、标签化映射和高度限制，兼顾扫读与扩展。

7. 为什么评估器试运行和任务试运行都要做，会不会重复？

两次试运行验证的对象不同。评估器试运行检查单个评估规则、输入字段和输出是否正确；任务试运行验证数据集、应用、字段映射和多个评估器串起来后能否正常工作。前者保证资产可用，后者保证整条链路可执行，所以是分层验证，不是重复功能。

8. 只重试失败项如何保证结果一致性？

前提是保留原任务版本、数据集版本、应用版本、评估器配置和已成功结果，只对失败样本重新执行，并记录新的运行时间与状态。如果依赖配置发生变化，就不能和旧结果直接拼接，应提示用户创建新一轮评测或重新全量运行。这个一致性约束需要产品和后端共同保证。

9. 为什么结果页要分整体、指标和 Case 三层？

不同层级回答的问题不同：整体结果回答这次评测是否达标，指标层回答哪个能力维度有问题，Case 层回答具体失败发生在哪里以及是否需要人工纠正。按这三层组织，用户可以先判断方向，再逐步缩小范围，避免一开始就陷入大量明细。

10. 项目还没上线，怎么证明方案有效？

不能用预期提升代替真实结果。现阶段可以证明的是流程完整性、依赖关系合理性、关键任务能否在原型中完成，以及利益相关方评审是否通过。上线后再验证任务配置时长、一次配置成功率、试运行发现问题的比例、失败重试成本、结果下钻到异常 Case 的时间，以及研发协作次数是否下降。

11. 评测平台具体服务谁，怎样区分不同任务？

这个项目主要服务运营和算法人员。运营关注能否独立配置数据集、应用和评估器，并顺利执行；算法侧更需要理解指标差异和具体 Case，定位质量问题。具体角色和权限以项目中的真实定义为准。

因此我把配置、执行和分析放在同一链路，同时按任务层级组织信息，而不是把所有专业配置一次展示给所有人。

12. 权限不足、额度不足或执行失败，应该怎样提示？

我会先区分原因，确认哪些属于用户可以处理的问题，再给出对应的下一步。例如权限问题引导申请或联系管理员，配额问题解释限制，暂时性故障说明重试方式。

同时保留已经填写的信息，尽量避免用户重新配置。对技术用户，可以提供进一步排查的信息；主提示仍然需要清楚说明发生了什么、影响什么、接下来能做什么。