xiaohack's Blog - 人机交互
type: channel
link: https://blog.xiaohack.org/tag/78466a61-12c0a0/
items: AG-UI：让 AI 走出聊天框的“界面革命”
items: Agent 不是渐进升级，而是要“换代”了：Cursor 工程负责人放话未来三到六个月，行业将迎来大变局
items: 人脸机器人登上Science Robotics封面：用AI教会仿生人脸机器人「开口说话」 ｜
items: 译文｜Tahoe 的图标令人难评

AG-UI：让 AI 走出聊天框的“界面革命”
type: item
date: 2026-01-22T21:09:03+08:00
description: 序幕：从“百科全书”到“实时搭档”大家发现了吗？我们现在使用 AI 的方式，本质上还是在查阅一本超级百科全书。无论是在 ChatGPT 还是 Claude 的对话框里，我们总是重复着：提问、等待、阅读文字、复制粘贴。这种交流永远被困在一个小小的“聊天框”里，就像你雇佣了一个超级天才助手，但他被关在隔壁的小黑屋里，只能通过门缝给你“递纸条”。你在这头对着复杂的业务界面抓耳挠腮，他在那头空有一身才华却看不见你的屏幕。这种“隔靴操痒”的交互方式，是时候结束了。想象一下，如果 AI 不仅仅是那个能言善辩的聊天机器人，而是一个能实时看懂你的操作、感知你的困惑、并直接帮你操作界面的“数字化合伙人”？当你拖动地图，他立刻补全路径；当你填表卡壳，他直接变出最合适的选项。他不再躲在对话框后面，而是直接走进你的工作流，伸手接过了那把名为“UI”的钥匙。这就是 AG-UI（Agent-User Interaction Protocol） 正在发起的革命：让 AI 走出聊天框，让界面随心而动。第一部分：什么是 AG-UI？用最简单的话说，AG-UI 是 AI 智能体（Agent）和用户界面（UI）之间的“通用翻译官”。在 AG-UI 出现之前，如果你想把 AI 接入 App，程序员需要费劲地把 AI 的文字输出手动“翻译”成网页上的按钮。而且，市面上有无数种 AI 框架，又有无数种前端终端，要把它们两两连接，工作量巨大。AG-UI 的出现，就像是在 AI 大脑与屏幕之间修通了一条标准化的“高速公路”： 它不管后端用的是什么模型，前端用的是什么设备，只要接上这根管道，AI 就能从一个后台的“思考者”，变成前台的“协作者”。知识点：AG-UI vs A2UI这里有两个概念容易混淆。A2UI（Google 出品） 像是 UI 的“建筑图纸”，定义了界面长什么样；而 AG-UI 则是“物流快递”，负责把这张图纸实时、安全地送到你的屏幕上。第二部分：AG-UI 在智能体协议栈中的角色要理解 AG-UI 的威力，我们需要看它在整个 AI 智能体生态（Agent Protocol Stack）中的位置。它与其他两大主流协议相辅相成，共同构成了 AI 时代的底层架构：MCP (Model Context Protocol) —— 赋能工具： 负责连接 AI 与各种工具（Tools）或数据库。它让 Agent 拥有了“手”，可以去查资料、调 API。A2A (Agent-to-Agent) —— 协同合作： 负责不同 Agent 之间的通信。它让 Agent 拥有了“对讲机”，可以呼唤其他 AI 协作。AG-UI —— 触达用户： 这是最关键的一环。 它负责将 Agent 的能力引入到面向用户的应用程序中。它让 Agent 拥有了“窗口”，直接与人类在 UI 界面上共事。流程简述： Agent 通过 MCP 调用工具获取数据，通过 A2A 协同其他专家 AI，最后通过 AG-UI 将处理结果直接转化成你屏幕上的交互组件。第三部分：颠覆性的三宗“最”最懂你：生成式 UI (Generative UI)。 以前的软件是程序员提前写死的。有了 AG-UI，AI 可以根据对话内容，现场为你“造”软件。而且这过程非常丝滑——组件会随着 AI 的思考过程实时在屏幕上“生长”出来。最默契：共享状态 (Shared State)。 这就是“双向同步”的超能力。你在界面上拉动滑块增加了参数，AI 的“大脑”会立刻感知到这个动作并同步做出反馈。你们共享同一个“上下文”，就像并肩作战的战友。最安全：人在回路 (Human in the Loop)。 AG-UI 允许 AI 在关键时刻弹出一个确认界面。AI 没法乱写代码，它只能发送数据指令去调用你预设好的“安全积木”。第四部分：生态现状——工具已在手虽然协议发布时间不长，但它的生态爆发速度惊人：全明星后端支持： LangGraph、CrewAI、Microsoft Autogen 等主流框架均已接入。前端大厂入局： 除了 React 方案，Google 的 Flutter 团队已经推出了 GenUI SDK。这意味着“设计即基础设施”的时代已经开启。快速体验： 如果你想现在尝试，只需一行命令：npx create-ag-ui-app。第五部分：核心洞察——“设计”正在变成基础设施作为开发者，我感受到这场革命最震撼的地方在于：前端的工作方式将彻底重构。从“盖房子”到“造积木”： 以后前端不再负责拼装最终页面（那是 AI 的事），而是负责设计足够原子、具备强语义化的“组件积木”。框架的“降维打击”： 当 Flutter 等框架官方定义的“标准组件”已经足够美观且具备完美的 AI 语义时，企业将不再需要雇佣设计师去重新发明轮子。“设计”将从一项昂…

Agent 不是渐进升级，而是要“换代”了：Cursor 工程负责人放话未来三到六个月，行业将迎来大变局
type: item
date: 2026-01-19T20:03:41+08:00
description: 整理 | 华卫、Tina过去一年，编码 Agent 的变化速度，已经快到让人很难用“功能升级”来形容。如果把时间拨回到一年前，Agent 还主要停留在代码补全、对话式改几行代码的阶段；而今天，在 Cursor 内部，工程师已经开始同时运行多个 Agent 并行“甩活儿”，让它们在代码库中自主修改、调试、复盘，再由人类在最后阶段集中审核结果。开发者不再盯着 Agent 的每一步操作，而是开始习惯“等它跑完再看答案”。在最近一次访谈中，Cursor 工程负责人 Jason Ginsberg 给出了一个明确判断：这不是渐进式优化，而是一场正在发生的“换代”。更重要的是，他把这场变化的时间窗口，压缩到了未来三到六个月——在他看来，Agent 将不只是“更聪明”，而是会真正接管更长周期、更复杂的工程任务，整个行业的工作方式也将随之重塑。下面是详细对话内容，我们在不改变原意的基础上进行了翻译和删减，以飨读者。一年多时间，编码 Agent“翻天覆地”Harrison Chase：Jason，你能跟大家简单介绍一下自己吗？也给大家讲讲 Cursor 是什么吧。 Jason Ginsberg：好的。我目前在做一款 AI 编程工具，已经在 Cursor 工作了六个月，担任该产品的工程负责人。不过说实话，我日常的大部分时间还是在写代码和做设计工作。在加入 Cursor 之前，我在 Notion 负责 Notion Mail 相关工作。几年前，我创办了一家名为 Skiff 的公司，后来这家公司被 Notion 收购了。所以，我一直都在从事产品开发相关的工作，而且主要聚焦在生产力工具领域。 Harrison Chase：非常棒。我有很多话题想和你探讨。要不我先抛砖引玉，问问你对编码 Agent 的发展历程，以及这些年来人机交互模式演变的看法吧。你们可以说是这个领域的先行者之一，我认为编码 Agent 的发展经历了几个阶段的转变：从最初的代码自动补全，到集成在集成开发环境（IDE）中的对话式交互，再到如今出现的各类终端工具，以及基于云端的异步 Agent。我很想听听你的看法，你觉得这样概括其用户体验的演变历程是否准确？或者你们团队是如何看待这一发展过程的？ Jason Ginsberg：我认为编码 Agent 的发展确实可以用 “翻天覆地” 来形容，而且这些变革基本上都是在一年多一点的时间里发生的。正如你所说，Cursor 最早开启了代码自动补全的先河，这种模式主要是在逐行的层面上提供辅助，适用范围也基本局限在单个文件内。而此后，几乎每隔几个月，我们就不得不提升产品的抽象层级，这其实是一个极具挑战性的产品设计难题。显然，Agent 的出现让开发者能够在多个文件之间灵活切换，并且可以放心地让 Agent 自主完成代码修改工作。 在过去两个月左右的时间里，我发现行业又出现了新的转变：开发者现在已经能够做到从项目启动到结束全程信任 Agent，并且会对整个代码库中多个文件的内容进行批量审核。因此，我们不得不对产品的整体布局进行大幅重新设计，将核心从逐行的代码差异对比，转向更偏向代码审查的模式。 展望未来的产品开发方向，我们的工作重心其实会更多地放在多 Agent 协同运行上。我们需要实现的是，能够快速验证这些 Agent 是否在正常运行，并且可以让它们并行工作，同时避免受到当前单一对话模式下各种选项和选择的束缚。 Harrison Chase：推动这些变革的核心因素是什么？仅仅是因为大模型的性能变得越来越好，还是有其他更多的影响因素？ Jason Ginsberg：我认为大模型性能的提升是一个很关键的因素，这让开发者能够更加信任 Agent 编写的代码质量。要知道，以前大家必须对 Agent 生成的代码进行非常全面细致的审查。同时，现在也有了更完善的代码审查工具。比如我们有 BugBot，市场上其实还有很多类似的工具，它们都能够自动检查代码中存在的问题。 此外，我觉得从行业文化层面来看，开发者们对 Agent 工具的接受度和使用信心也在不断增强，甚至可以说已经 “上瘾” 于这类工具带来的便捷。而且，一旦习惯了完全依赖 Agent 进行编码的工作模式，再切换回传统的编码方式其实是很困难的。所以现在，我们能看到越来越多的开发者已经将 Agent 辅助编程作为默认的工作方式。最顶尖工程师的干活秘诀：全靠 Agent？Harrison Chase：你观察到大家使用 Cursor 的方式都有哪些不同？或者你自己平时是怎么使用 Cursor 的？ Jason Ginsberg：其实在我们公司内部，工程师们使用 Cursor 的方式就五花八门。甚至团队里有几位工程师，他们完全不使用 Cursor 的 Agent 功能，比如负责安全和基础设施的同事。所以，确实有一部分用户非常…

Agent 不是渐进升级，而是要“换代”了：Cursor 工程负责人放话未来三到六个月，行业将迎来大变局
type: item
date: 2026-01-19T19:55:10+08:00
description: 整理 | 华卫、Tina过去一年，编码 Agent 的变化速度，已经快到让人很难用“功能升级”来形容。如果把时间拨回到一年前，Agent 还主要停留在代码补全、对话式改几行代码的阶段；而今天，在 Cursor 内部，工程师已经开始同时运行多个 Agent 并行“甩活儿”，让它们在代码库中自主修改、调试、复盘，再由人类在最后阶段集中审核结果。开发者不再盯着 Agent 的每一步操作，而是开始习惯“等它跑完再看答案”。在最近一次访谈中，Cursor 工程负责人 Jason Ginsberg 给出了一个明确判断：这不是渐进式优化，而是一场正在发生的“换代”。更重要的是，他把这场变化的时间窗口，压缩到了未来三到六个月——在他看来，Agent 将不只是“更聪明”，而是会真正接管更长周期、更复杂的工程任务，整个行业的工作方式也将随之重塑。下面是详细对话内容，我们在不改变原意的基础上进行了翻译和删减，以飨读者。一年多时间，编码 Agent“翻天覆地”Harrison Chase：Jason，你能跟大家简单介绍一下自己吗？也给大家讲讲 Cursor 是什么吧。 Jason Ginsberg：好的。我目前在做一款 AI 编程工具，已经在 Cursor 工作了六个月，担任该产品的工程负责人。不过说实话，我日常的大部分时间还是在写代码和做设计工作。在加入 Cursor 之前，我在 Notion 负责 Notion Mail 相关工作。几年前，我创办了一家名为 Skiff 的公司，后来这家公司被 Notion 收购了。所以，我一直都在从事产品开发相关的工作，而且主要聚焦在生产力工具领域。 Harrison Chase：非常棒。我有很多话题想和你探讨。要不我先抛砖引玉，问问你对编码 Agent 的发展历程，以及这些年来人机交互模式演变的看法吧。你们可以说是这个领域的先行者之一，我认为编码 Agent 的发展经历了几个阶段的转变：从最初的代码自动补全，到集成在集成开发环境（IDE）中的对话式交互，再到如今出现的各类终端工具，以及基于云端的异步 Agent。我很想听听你的看法，你觉得这样概括其用户体验的演变历程是否准确？或者你们团队是如何看待这一发展过程的？ Jason Ginsberg：我认为编码 Agent 的发展确实可以用 “翻天覆地” 来形容，而且这些变革基本上都是在一年多一点的时间里发生的。正如你所说，Cursor 最早开启了代码自动补全的先河，这种模式主要是在逐行的层面上提供辅助，适用范围也基本局限在单个文件内。而此后，几乎每隔几个月，我们就不得不提升产品的抽象层级，这其实是一个极具挑战性的产品设计难题。显然，Agent 的出现让开发者能够在多个文件之间灵活切换，并且可以放心地让 Agent 自主完成代码修改工作。 在过去两个月左右的时间里，我发现行业又出现了新的转变：开发者现在已经能够做到从项目启动到结束全程信任 Agent，并且会对整个代码库中多个文件的内容进行批量审核。因此，我们不得不对产品的整体布局进行大幅重新设计，将核心从逐行的代码差异对比，转向更偏向代码审查的模式。 展望未来的产品开发方向，我们的工作重心其实会更多地放在多 Agent 协同运行上。我们需要实现的是，能够快速验证这些 Agent 是否在正常运行，并且可以让它们并行工作，同时避免受到当前单一对话模式下各种选项和选择的束缚。 Harrison Chase：推动这些变革的核心因素是什么？仅仅是因为大模型的性能变得越来越好，还是有其他更多的影响因素？ Jason Ginsberg：我认为大模型性能的提升是一个很关键的因素，这让开发者能够更加信任 Agent 编写的代码质量。要知道，以前大家必须对 Agent 生成的代码进行非常全面细致的审查。同时，现在也有了更完善的代码审查工具。比如我们有 BugBot，市场上其实还有很多类似的工具，它们都能够自动检查代码中存在的问题。 此外，我觉得从行业文化层面来看，开发者们对 Agent 工具的接受度和使用信心也在不断增强，甚至可以说已经 “上瘾” 于这类工具带来的便捷。而且，一旦习惯了完全依赖 Agent 进行编码的工作模式，再切换回传统的编码方式其实是很困难的。所以现在，我们能看到越来越多的开发者已经将 Agent 辅助编程作为默认的工作方式。最顶尖工程师的干活秘诀：全靠 Agent？Harrison Chase：你观察到大家使用 Cursor 的方式都有哪些不同？或者你自己平时是怎么使用 Cursor 的？ Jason Ginsberg：其实在我们公司内部，工程师们使用 Cursor 的方式就五花八门。甚至团队里有几位工程师，他们完全不使用 Cursor 的 Agent 功能，比如负责安全和基础设施的同事。所以，确实有一部分用户非常…

人脸机器人登上Science Robotics封面：用AI教会仿生人脸机器人「开口说话」 ｜
type: item
date: 2026-01-15T13:15:04+08:00
description: 人脸机器人登上Science Robotics封面：用AI教会仿生人脸机器人「开口说话」0%展开列表人脸机器人登上Science Robotics封面：用AI教会仿生人脸机器人「开口说话」今天实测夸克「千问划词快捷指令」，这7个邪修Prompt，建议收藏今天已证实！清华姚班陈立杰全职加入OpenAI，保留伯克利教职今天解锁任意步数文生图，港大&Adobe全新Self-E框架学会自我评估今天5分钟定制一个AI采购专家：讯飞发布“招采智能体工厂”，重新定义行业开发范式今天Agent时代，为什么多模态数据湖是必选项？今天大模型长脑子了？研究发现LLM中层会自发模拟人脑进化今天性能提升60%，英特尔Ultra3这次带来了巨大提升01月14日继宇树后，唯一获得三家大厂押注的自变量：具身模型不是把DeepSeek塞进机器人01月14日Sebastian Raschka 2026预测：Transformer统治依旧，但扩散模型正悄然崛起01月14日端到端智驾新SOTA | KnowVal：懂法律道德、有价值观的智能驾驶系统01月14日仅用10天？Anthropic最新智能体Cowork的代码竟然都是Claude写的01月14日AAAI 2026｜AP2O-Coder 让大模型拥有「错题本」，像人类一样按题型高效刷题01月14日用AI从常规病理切片重建空间蛋白图谱：基于H&E图像的高维蛋白质表达预测01月14日京东首届AI影视创作大赛启动 最高奖金10万元邀全民共创AI视频01月14日合合信息多模态文本智能产品“上新”，覆盖AI教育、AI健康、AI Infra多元场景01月14日500万次围观，1X把「世界模型」真正用在了机器人NEO身上01月14日跳出「黑盒」，人大刘勇团队最新大语言模型理论与机理综述01月14日百川开源全球最强医疗大模型M3，「严肃问诊」定义AI医疗新能力01月14日相约AAAI 2026 | 上海AI实验室北极星 X 星启交流会（报名开启）01月13日人脸机器人登上Science Robotics封面：用AI教会仿生人脸机器人「开口说话」胡宇航（网名 “U 航”），毕业于美国哥伦比亚大学，博士学位，首形科技创始人。长期专注于机器人自主学习的研究工作。研究成果发表于《Nature Machine Intelligence》，《Science Robotics》等国际顶级期刊。致力于赋予机器人 “自我模型” 能力，即构建对自身物理结构与运动的内部表征，使机器人能够更好地理解自身，并适应多变的形态、环境与任务。在仿生人机交互方向，他提出融合语音、视觉与动作的情绪理解与表达一体化系统，为机器人提供更加自然的交互能力。通过自监督学习机制，他的方法使机器人在无需人工干预的情况下不断提升人机互动质量，朝着具备终身学习能力的智能体不断迈进。论文地址：https://www.science.org/doi/10.1126/scirobotics.adx3017曾发表论文：Hu, Yuhang, et al. "Human-robot facial coexpression." Science Robotics 9.88 (2024): eadi4724.Hu, Yuhang, Jiong Lin, and Hod Lipson. "Teaching robots to build simulations of themselves." Nature Machine Intelligence (2025): 1-11.https://mp.weixin.qq.com/s/HdnbBweZseTjMedyWHDLSg2026 年 1 月 15 日，一项来自美国哥伦比亚大学工程学院的突破性研究正式发表于《Science Robotics》，并登上期刊封面。该研究展示了一项全新的机器人技术：一台具备仿生面部结构的人形机器人，通过深度学习实现与语音和歌曲同步的真实唇部运动。它能跟着人类的语言精准张合嘴唇，甚至，能跟着音乐唱歌。标志着人形机器人在人类最丰富的交流通道之一唇部表达上，迈出了突破性一步。为什么 “嘴唇” 如此重要？研究显示，在面对面的交流中，人类将近一半的注意力集中在唇部运动上。我们或许能容忍机器人走路笨拙、手部动作僵硬，但哪怕极其轻微的不自然面部表情，都会立刻引发本能的不适。这正是著名的 “恐怖谷”。长期以来，即便是最先进的人形机器人，在 “说话” 时也只能做出类似木偶的张合动作 —— 如果它们有脸的话。但这一次，情况正在发生改变。一个会自主学习表情的机器人在这项研究中，研究团队打造了一张高度仿生的机器人面孔：在一层柔性硅胶皮肤之下，隐藏着 20 余个微型电机，能够快速、安静且协同地驱动唇部形变。图 2. 机器人唇形硬件结构。（A）面部…

译文｜Tahoe 的图标令人难评
type: item
date: 2026-01-14T09:24:43+08:00
description: 编者注本文首发于 Nikita Prokopov 的个人博客，原文 It’s hard to justify Tahoe icons，少数派经作者授权转载、翻译。在编译过程中，我们参考了作者 @Nullpinter 的译文版本（发布于该作者的个人博客）的标题和部分二级标题，在此表示感谢。正文内容为少数派编辑部独立编译。在读 1992 年版的《Macintosh 人机交互指南》（Macintosh Human Interface Guidelines）的时候，我发现了这张精美的插图：随附的说明是：时间快转到 2025 年，Apple 发布了 macOS Tahoe。最主要的变化？当数每个菜单选项都加上了不讨喜、容易使人分心、难以辨认、杂乱无章、支离破碎、让人感到疑惑和沮丧的图标（这是 Apple 自己的说法，可不是我编的！）：Sequoia → Tahoe这就很糟糕了。但为什么呢？我们不妨深入探讨一下！免责声明：本文混合了来自 macOS 26.1 和 26.2 版本的截图，均取自系统预装的 Apple 原生应用。截图前未修改任何系统设置。图标应当具有区分度图标的主要功能是帮助你更快地找到所需内容。或许这听起来有违直觉，但给所有东西都加上图标却是错误的做法。与众不同的东西往往更加显眼，但如果所有东西都有一个对应的图标，那谁都没办法从中脱颖而出。同样的道理也适用于颜色：黑白图标看起来很整洁，但并不能帮你更快地找到目标！微软曾深谙此道：在下图右侧版本的菜单中，你会发现定位「保存」（Save）或「共享」（Share）的速度要快得多：右边的菜单看上去更清爽，也更整洁。如果是彩色版本效果则会更好（文本与图标分离得更清晰，找起来更快）：我知道你可能不喜欢它的样子，我也不喜欢，毕竟要把这些图标处理好并非易事。但背后的原则是依然成立的：即便这个色彩选用未经实际设计的粗糙版本，也是更易用的。应用间的一致性具备一致性（consistency）的图标才是真正有用的图标，毕竟在找到这些图标之前，我得先掌握它们的它们大概都有什么共性。例如在看到「剪切」（Cut）命令和它旁边的图标长什么样之后，那我下一次找寻「剪切」操作时或许就会省点功夫直接去找这个图标：Tahoe 在这方面表现如何呢？请看「新建」图标的「五十度灰」：我甚至把它们收集在了一起，好让这种荒谬感更加显而易见。诚然，其中一些图标所代表的操作与其他不同，所以图标也有差异。但如果说创建「智能文件夹」和创建「日记条目」是两码事，下面这些又该如何解释呢？或者这些：还有这些：还是别找借口了吧。「打开」这个操作也是一样：「保存」也是：是的，其中一个保存图标竟然是个勾选的标记，而且它们甚至连箭头的方向都统一不了！再看看「关闭」按钮：「查找」（有时叫搜索，有时叫筛选）：「删除」（出自剪切-拷贝-粘贴-删除操作）：「最小化窗口」：这些图标所对应的都不是什么生僻又特殊的功能，相反它们所代表的都是基础操作，是垒砌操作系统的基石。这些操作每个应用都有，并且布局上也总在相近的位置。它们看起来不应该有这么多花样！应用内的一致性图标也用于工具栏（toolbars）。从概念上讲，工具栏中的操作与通过菜单调用的操作是完全相同的，因此应该使用相同的图标。所以实现起来的方式也应该是最简单的：在同一个应用内、甚至通常同时出现在屏幕上的图标，保持一致能有多难呢？那我们看看「预览」：「照片」：同样的用了上述两种图标，但这次调换了一下顺序¯_(ツ)_/¯「地图」和其他应用在「缩放」功能上的图标选用也常有差异：图标复用和完全不具备一致性类似的，另一个大忌是将同一个图标用于不同的操作。想象一下：我已经学会了下面这个图标代表「新建」：并且我打开另一个应用也看到了它。「太棒了，」我想，「我知道这个图标是什么意思了」：上当了吧！你可能会想：好吧，下面这个图标代表「快速查看」：有时候确实如此，但在另一些时候，这个图标的意思是「显示已完成项」：有时候下面这个图标意味着「导入」：但有时候它也代表着「更新」：与上面提到的一致性问题类似，图标复用问题不仅发生在不同应用之间。有时你可以在工具栏看到这个图标：然后在同一个应用的菜单里，发现同一个图标代表了别的东西：有时完全相同的图标会在同一个菜单中相遇。有时还会贴在一起。有时它们甚至会将一整串相同的图标排成列：这显然对谁都没帮助。如果所有图标都一样，用户很难快速定位到菜单项，也不会正确理解其背后所指代的功能。目前为止图标复用最惨烈的案例是「照片」应用：感觉那个负责为每个菜单项选择一个对应图标的人，可能头发都已经掉光了。理解万岁。细节要素过多审视图标时，我们通常能包容它们在最终落地环节中的一些微小差异。例如下面这些理论上来说各不相同的路标，实际上都在帮助我们理解同一件事：图标也是如此：如果你在一个地方画了一个飞出盒子…

译文｜Tahoe 的图标令人难评
type: item
date: 2026-01-13T12:01:27+08:00
description: 编者注本文首发于 Nikita Prokopov 的个人博客，原文 It’s hard to justify Tahoe icons，少数派经作者授权转载、翻译。在编译过程中，我们参考了作者 @Nullpinter 的译文版本（发布于该作者的个人博客）的标题和部分二级标题，在此表示感谢。正文内容为少数派编辑部独立编译。在读 1992 年版的《Macintosh 人机交互指南》（Macintosh Human Interface Guidelines）的时候，我发现了这张精美的插图：随附的说明是：时间快转到 2025 年，Apple 发布了 macOS Tahoe。最主要的变化？当数每个菜单选项都加上了不讨喜、容易使人分心、难以辨认、杂乱无章、支离破碎、让人感到疑惑和沮丧的图标（这是 Apple 自己的说法，可不是我编的！）：Sequoia → Tahoe这就很糟糕了。但为什么呢？我们不妨深入探讨一下！免责声明：本文混合了来自 macOS 26.1 和 26.2 版本的截图，均取自系统预装的 Apple 原生应用。截图前未修改任何系统设置。图标应当具有区分度图标的主要功能是帮助你更快地找到所需内容。或许这听起来有违直觉，但给所有东西都加上图标却是错误的做法。与众不同的东西往往更加显眼，但如果所有东西都有一个对应的图标，那谁都没办法从中脱颖而出。同样的道理也适用于颜色：黑白图标看起来很整洁，但并不能帮你更快地找到目标！微软曾深谙此道：在下图右侧版本的菜单中，你会发现定位「保存」（Save）或「共享」（Share）的速度要快得多：右边的菜单看上去更清爽，也更整洁。如果是彩色版本效果则会更好（文本与图标分离得更清晰，找起来更快）：我知道你可能不喜欢它的样子，我也不喜欢，毕竟要把这些图标处理好并非易事。但背后的原则是依然成立的：即便这个色彩选用未经实际设计的粗糙版本，也是更易用的。应用间的一致性具备一致性（consistency）的图标才是真正有用的图标，毕竟在找到这些图标之前，我得先掌握它们的它们大概都有什么共性。例如在看到「剪切」（Cut）命令和它旁边的图标长什么样之后，那我下一次找寻「剪切」操作时或许就会省点功夫直接去找这个图标：Tahoe 在这方面表现如何呢？请看「新建」图标的「五十度灰」：我甚至把它们收集在了一起，好让这种荒谬感更加显而易见。诚然，其中一些图标所代表的操作与其他不同，所以图标也有差异。但如果说创建「智能文件夹」和创建「日记条目」是两码事，下面这些又该如何解释呢？或者这些：还有这些：还是别找借口了吧。「打开」这个操作也是一样：「保存」也是：是的，其中一个保存图标竟然是个勾选的标记，而且它们甚至连箭头的方向都统一不了！再看看「关闭」按钮：「查找」（有时叫搜索，有时叫筛选）：「删除」（出自剪切-拷贝-粘贴-删除操作）：「最小化窗口」：这些图标所对应的都不是什么生僻又特殊的功能，相反它们所代表的都是基础操作，是垒砌操作系统的基石。这些操作每个应用都有，并且布局上也总在相近的位置。它们看起来不应该有这么多花样！应用内的一致性图标也用于工具栏（toolbars）。从概念上讲，工具栏中的操作与通过菜单调用的操作是完全相同的，因此应该使用相同的图标。所以实现起来的方式也应该是最简单的：在同一个应用内、甚至通常同时出现在屏幕上的图标，保持一致能有多难呢？那我们看看「预览」：「照片」：同样的用了上述两种图标，但这次调换了一下顺序¯_(ツ)_/¯「地图」和其他应用在「缩放」功能上的图标选用也常有差异：图标复用和完全不具备一致性类似的，另一个大忌是将同一个图标用于不同的操作。想象一下：我已经学会了下面这个图标代表「新建」：并且我打开另一个应用也看到了它。「太棒了，」我想，「我知道这个图标是什么意思了」：上当了吧！你可能会想：好吧，下面这个图标代表「快速查看」：有时候确实如此，但在另一些时候，这个图标的意思是「显示已完成项」：有时候下面这个图标意味着「导入」：但有时候它也代表着「更新」：与上面提到的一致性问题类似，图标复用问题不仅发生在不同应用之间。有时你可以在工具栏看到这个图标：然后在同一个应用的菜单里，发现同一个图标代表了别的东西：有时完全相同的图标会在同一个菜单中相遇。有时还会贴在一起。有时它们甚至会将一整串相同的图标排成列：这显然对谁都没帮助。如果所有图标都一样，用户很难快速定位到菜单项，也不会正确理解其背后所指代的功能。目前为止图标复用最惨烈的案例是「照片」应用：感觉那个负责为每个菜单项选择一个对应图标的人，可能头发都已经掉光了。理解万岁。细节要素过多审视图标时，我们通常能包容它们在最终落地环节中的一些微小差异。例如下面这些理论上来说各不相同的路标，实际上都在帮助我们理解同一件事：图标也是如此：如果你在一个地方画了一个飞出盒子…