文 / STEM Career 编辑部
AI产品的UX作品集，最有价值的部分往往发生在模型没有顺利给出答案之后。用户如何知道结果依据，能否发现错误，怎样保留已经完成的工作，以及何时接回控制，都会影响产品是否真正可用。只画一个漂亮聊天框，容易把最需要设计判断的部分留在画面之外。
本文用原创“员工查询差旅规则”的文档助理案例，展示如何做一份包含不确定性、纠错、撤回与人工接管的作品集。案例是设计练习，没有虚构用户访谈或测试结果；你可以根据实际资源完成原型与小规模任务观察，再把真实记录补进自己的作品。
先定义用户要完成的决定
用户并不只是想和知识库聊天。假设员工要判断一笔住宿费用应走哪个申请流程，并找到适用的规则。真正任务包括辨认适用人群与日期、找到证据、知道资料不足时怎么办，以及将结果交给后续流程。把目标只写成“提升问答体验”，无法判断设计是否有效。
先选择一类用户和一个有限场景。本文只使用虚构公司的合成政策，处理查询与申请草稿，不直接发起报销或作最终审批。用户最终需要带走一份有出处的解释和下一步，而不是一个看上去很确定的答案。
需求说明应包括错误的代价：选错流程会产生返工，引用过期规则会误导判断，暴露不应访问的资料则涉及更严重的问题。不同错误不能用同一种红色提示处理；它们要求界面提供不同信息、动作和责任边界。
把AI设计岗位的要求转成作品标准
Anthropic Claude Developer Platform产品设计岗位强调复杂工作流、端到端交付、原型、技术理解与跨团队协作，并要求已有相关设计经历。它是经验型任务样本，不能据此宣称AI UX都是应届岗位或只要会某个工具即可申请。
对作品集的启发是：设计不应停在一张效果图。你需要说明输入如何进入系统，答案依据在哪里，哪些状态需要用户确认，以及发生错误后怎么继续。即使没有真实模型，也可以通过受控原型验证关键决策，但要把模拟和真实功能标清。
和传统作品集一样，个人贡献仍需具体。若工程同学提供了检索组件，你可以负责用户任务、状态设计、文案和测试，而不是把全部系统研发写成自己独立完成。作品集展示的是能够解释的设计责任，而不是工具清单。
先画状态 再画完整页面
至少列出初始、输入缺失、检索中、找到依据、依据冲突、无法回答、用户纠错和转人工等状态。每个状态写四件事：系统知道什么，用户需要知道什么，下一步可以做什么，以及当前工作如何保存。这样能提前发现流程断点。
例如“找到两份相互冲突的规则”与“网络请求失败”都可能没有最终答案，但前者需要比较版本和适用范围，后者需要重试或换方式查看文档。把两者合并为“AI出现错误，请重试”，会让用户重复无效操作。
状态表还应写入口与退出条件。用户补充出差日期后，是重新检索，还是沿用旧结果再修改；等待期间能否编辑问题；用户取消后已经获取的资料是否保留。只有页面稿，没有这些转换，工程实现时就会重新做一轮未被讨论的设计。
原创案例的一条正常路径
员工输入“下个月去外地，住宿标准是多少”。助理先识别需要的条件，询问目的地、日期和适用身份，再展示相关规则与解释。界面要清楚区分用户提供的事实、系统找到的依据和系统作出的归纳，避免把推断写成已确认资料。
回答区域可以先给可执行结论，再给引用与适用条件。点击引用应到达具体条款或可定位片段，而不是只跳到几十页文件的首页。用户能否找到并核对证据，是本任务要验证的行为，不只是卡片上有没有一个链接图标。
接下来是“保存查询结果”或“生成申请草稿”。在采取动作前，让用户看见将写入哪些字段、哪些仍待确认。按钮标签应表达实际动作，例如保存草稿；不要把未完成提交的状态写成“申请成功”，也不要用模糊的“继续”隐藏后果。
面对不确定性 设计具体的继续方式
Google People＋AI Guidebook的错误处理章节建议理解用户感知的失败，并提供能够继续完成任务的路径。对本文案例，更有用的做法是解释缺少哪项资料、给出补充入口，或让用户直接查看相关条款，而非只展示一句通用免责声明。
如果规则没有覆盖某种出差类型，可以显示已找到的范围和仍缺的部分，提供向相关负责人确认的草稿。不要用一个没有解释的置信度数字替代判断；用户并不一定理解它对应的是检索相关性、模型概率还是整项任务可靠性。
设计不确定状态时还要考虑信息负担。把所有风险一次铺满屏幕，会让用户忽略真正需要处理的条件。优先展示影响当前决定的缺口，再允许展开背景。你的作品集应说明为何把某项内容放在主界面，而不是仅以“更简洁”概括。
用户纠错要明确会改变什么
当用户说“我不是正式员工，是访问人员”，系统应先确认修改的是适用身份，再重新核对相关依据，并让用户看见结果为何改变。直接把上一条回答替换掉，会丢失用户理解变化的机会，也不利于追踪这次纠错的作用。
需要区分三种动作：修正本次输入，向团队报告内容问题，以及允许把反馈用于未来改进。它们并不天然等价。界面文案不能暗示按一次差评就已训练模型，也不能让用户误以为修改自己的草稿会改变所有人的政策。
原型里可以保留修改前后的关键差异，例如适用身份、引用版本与待确认事项。若系统仍不能确定正确流程，就继续显示缺口，而不是为了让纠错看起来成功而生成一个更肯定的答案。让用户看到边界，本身也是可用性的一部分。
人工接管不是放一个联系按钮
当任务超出资料覆盖范围时，接管入口应帮助用户把问题交出去。可以包含已确认条件、查过的条款、尚未解决的问题和拟发送对象，允许用户查看及修改。用户不应为了求助而从零重新描述整个过程。
同时要说明哪些内容会被发送。合成案例中可以预先设计数据摘要，但真实产品需要按适用权限处理；不要默认把整段对话、附件和个人资料一并交给所有人。设计稿应把发送前检查作为流程的一部分。
接管后还要有状态：草稿已准备、用户已发送、等待回复、收到补充。它们的证据不同。若原型没有真实通信能力，就停在可供用户复制的草稿，不能展示一个看似已经向负责人提交的成功提示。状态准确，比视觉上的“流程闭环”更重要。
把用户测试设计成可观察任务
测试题不宜是“你觉得这个AI好用吗”。可以请参与者判断一条有缺失条件的查询、找出回答所用的规则，并在给定身份变化后修正任务。观察他们在哪里停下、误解什么、是否发现依据过期，以及能否继续完成任务。
为了避免模型随机回答干扰设计比较，可以先用固定输出的受控原型。参与者看到相同的情景，差异更容易归因于信息组织和交互；以后再接真实系统检验。研究说明必须写清这只是界面与流程验证，不能因此宣布模型准确率已经提高。
测试记录按任务保留完成情况、需要的帮助、关键错误与用户解释。人数不多时，重点说明发现了什么具体问题，不把观察比例包装成整体市场统计。如果参与者都是同学，也要讨论他们和目标员工在知识、动机与工作环境上的差别。
原型迭代应能追溯到观察
假设测试中有人把“生成草稿”理解成已经提交，你可以修改按钮和结果状态，让用户在下一步看到草稿内容与提交责任。作品集展示原版、观察、修改依据和后续检查；如果还没有复测，说明预期要验证什么即可。
不要为了让故事完整，把每一个设计变更都写成大幅提升。一次修改可能解决标签误解，却增加了操作步骤；引用展开得更清楚，也可能让小屏幕阅读更复杂。记录收益和代价，说明最终选择的理由，才有可讨论的判断。
还要准备一个没有采纳的方案。例如始终显示很长的证据全文，虽然透明，却可能压过主要任务；只显示一句结论，虽然快，却难以核对。最终采用摘要加可定位引用，需要依据任务与观察，而不是声称所有AI产品都应该同样设计。
小屏幕与辅助操作也应进入原型检查。引用弹层打开后，用户能否回到原问题；等待状态改变时，是否有清楚反馈；不用鼠标时，能否移动到补充条件和取消按钮。不要把交互准确性只理解为桌面截图上的视觉秩序。
还可以设置一条长文档题，检查引用、解释和下一步是否抢占同一个阅读层级。用户需要先判断依据是否适用，再决定动作；若浮动操作栏遮住版本日期，或者点击来源后丢失输入，就会产生新的错误。把这些场景写入演示脚本，让作品的完成度由真实操作支持，而非只靠一组最顺利的截图。
与工程协作时把契约写到状态层
设计交付可以包含结果状态、引用标识、文档版本、缺失字段、可执行动作和错误类型。字段命名由团队决定，但含义必须一致：无结果和无权限不能共用一个空字符串，草稿创建成功和审批完成也不能共享同一个成功状态。
逐个核对异常如何到达界面。若后端只有通用错误码，前端就无法可靠呈现你设计的“规则冲突”；此时需要缩小界面承诺或补充接口，而不是凭文本猜测错误原因。技术约束会改变产品体验，应当在作品里正面说明。
演示时也可以展示一次联调分歧：设计希望保留历史结果，工程担心过期信息误导用户，你如何比较清除、折叠和标注版本等方案。即使只做教学项目，也可以根据真实实现约束记录自己的决定，而不必编造一场团队会议。
作品集最后怎样讲出设计判断
建议用任务、关键状态、证据与迭代组织叙事。先说明用户要做哪个决定，再展示最关键的一条正常路径和一条错误路径，接着解释设计选择怎样被观察或约束支持。原型页数多不等于深度，能讲清取舍才方便面试官追问。
准备回答三个问题：为什么这里需要确认，什么情况允许直接执行，用户不同意AI时如何继续。还要能说明本人尚未验证的部分，例如真实文档权限、长时间使用或实际通信。边界清楚，招聘方才能判断作品和目标任务有多大关联。
如果已有传统UX作品，不一定重做整个项目。可以先挑一个确实适合AI介入的用户任务，补上错误、纠错与接管的完整路径，再用实际观察迭代。怎样选择作品和讲本人贡献，可以接着读UX作品集面试指南与产品判断练习。
带一份现有作品、一段目标JD和你最难解释的设计决定，通过本页按钮添加蒸汽顾问微信，可以先讨论作品与目标岗位之间的证据缺口。求职方向与面试准备按实际支持范围沟通，不需要把尚未验证的原型包装成已经上线的业务成果。
常见问题（FAQ）
没有接真实模型，AI UX原型有意义吗？
受控原型能验证状态、信息和操作理解，但不能证明模型质量、真实权限或生产可靠性。
置信度数字应该一直展示吗？
先明确数字代表什么及用户如何使用。缺少可解释含义的百分比可能造成误解。
人工接管放一个客服入口就够了吗？
还应设计上下文交接、发送前检查、责任与后续状态，避免用户重新开始。
- Product Designer Claude Developer Platform· Anthropic
- Errors and Graceful Failure· Google People + AI Research
添加顾问微信，带现有作品、目标JD和一段设计取舍，讨论状态设计、测试依据与作品集表达。