标签 人机交互 下的文章

序幕:从“百科全书”到“实时搭档”

大家发现了吗?我们现在使用 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 将处理结果直接转化成你屏幕上的交互组件。


第三部分:颠覆性的三宗“最”

  1. 最懂你:生成式 UI (Generative UI)。 以前的软件是程序员提前写死的。有了 AG-UI,AI 可以根据对话内容,现场为你“造”软件。而且这过程非常丝滑——组件会随着 AI 的思考过程实时在屏幕上“生长”出来。
  2. 最默契:共享状态 (Shared State)。 这就是“双向同步”的超能力。你在界面上拉动滑块增加了参数,AI 的“大脑”会立刻感知到这个动作并同步做出反馈。你们共享同一个“上下文”,就像并肩作战的战友。
  3. 最安全:人在回路 (Human in the Loop)。 AG-UI 允许 AI 在关键时刻弹出一个确认界面。AI 没法乱写代码,它只能发送数据指令去调用你预设好的“安全积木”

第四部分:生态现状——工具已在手

虽然协议发布时间不长,但它的生态爆发速度惊人:

  • 全明星后端支持: LangGraph、CrewAI、Microsoft Autogen 等主流框架均已接入。
  • 前端大厂入局: 除了 React 方案,Google 的 Flutter 团队已经推出了 GenUI SDK。这意味着“设计即基础设施”的时代已经开启。
  • 快速体验: 如果你想现在尝试,只需一行命令:npx create-ag-ui-app

第五部分:核心洞察——“设计”正在变成基础设施

作为开发者,我感受到这场革命最震撼的地方在于:前端的工作方式将彻底重构。

  1. 从“盖房子”到“造积木”: 以后前端不再负责拼装最终页面(那是 AI 的事),而是负责设计足够原子、具备强语义化的“组件积木”。
  2. 框架的“降维打击”: 当 Flutter 等框架官方定义的“标准组件”已经足够美观且具备完美的 AI 语义时,企业将不再需要雇佣设计师去重新发明轮子。“设计”将从一项昂贵的业务成本,变成框架自带的基础设施。

结语:拥抱流动的未来

2026 年是 AI 智能体爆发的元年。界面的脸孔将不再死板,它会随你的需求而流动。UI 不再是挡在你和功能之间的那层“膜”,而是变成了一种随用随取的资源。

未来的应用不是由菜单定义的,而是由你的意图定义的。

别再纠结 CSS 的像素偏移了,去研究 AI 如何理解你的业务意图吧。这场革命,正在你运行 npx create-ag-ui-app 的那一刻开始。

本文由mdnice多平台发布

整理 | 华卫、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,甚至会同时运行多个 Agent 并行处理任务。

 

至于我个人的使用习惯,我并不会去设计那些复杂繁琐的提示词,也没有什么所谓的 “Agent 使用秘籍”。我写的提示词往往都很简短,甚至还会带有拼写错误。我会针对手头不同的工作任务,或者同一个问题的不同模块,同时启动多个 Agent,然后等待它们返回结果。

 

目前我用得最多的是我们今天刚刚发布的一个新功能:调试模式。这个模式下,Agent 能够通过生成日志来进行自我评估,之后开发者复现相关操作步骤,Agent 就会通过查看日志判断问题是否得到解决。这个功能非常实用,因为它相当于通过投入算力去不断尝试解决问题,最终攻克那些手动排查起来极为棘手的难题。

 

Harrison Chase:调试模式具体是什么样的?为什么需要专门设置这样一个模式?难道不能自动完成调试吗?直接给 Agent 下达调试指令不也可以吗?

 

Jason Ginsberg:其实我也认同你的这个想法。所以在开发调试模式的时候,我们内部确实有过不少争论。主要原因在于,Cursor 目前已经有很多功能模式了,如规划模式、询问模式等等,这些模式其实不太容易被用户发现。我们一直认为,这些模式都很实用,理想的状态应该是,Agent 能够根据用户的操作场景,自动匹配并启用最合适的模式,无需用户手动切换。

 

而现阶段调试模式之所以需要手动开启,是因为它的交互方式比较特殊。在运行过程中,Agent 会暂停当前的工作,向用户提问以获取反馈。如果用户不熟悉这种交互逻辑,可能会觉得比较困扰。

 

Harrison Chase:Agent 具体会询问哪些问题,又需要用户提供什么样的反馈呢?

 

Jason Ginsberg:我举个例子吧。假设我正在开发一个前端应用,遇到了一个很让人头疼的问题:菜单总是在左上角弹出。这时候我会对Agent说:“这个菜单需要锚定到按钮的位置。” 随后,Agent 会启动服务器,并在整个代码库中添加大量日志,同时提出一系列可能导致该问题的假设,如 “可能是某个定位参数设置错误”、“可能是事件绑定逻辑有问题” 等。之后,Agent 会提示我:“麻烦你点击这个按钮,打开菜单,看看问题是否解决。” 如果我反馈问题依然存在,Agent 就会查看生成的日志,然后分析判断:“这个假设成立,那两个假设不成立”。通常这样反复两三次之后,Agent 往往就能找出并解决问题。

 

Harrison Chase:你觉得人类还需要手动操作多久?就不能让 Agent 自主完成点击、测试这类操作吗?

 

Jason Ginsberg:一两个月内,毕竟这个行业的发展速度实在太快了。

 

Harrison Chase:刚才你提到了 Agent 的多种不同模式,比如规划模式、解释模式、调试模式等等。这些模式在实际应用中到底意味着什么?难道只是为 Agent 设置不同的提示词这么简单吗?还是说背后有更复杂的逻辑?

 

Jason Ginsberg:很多时候,确实就是修改一下系统层面的提示词。不过在某些情况下,我们也需要对用户界面进行相应的调整。比如规划模式现在也加入了交互提问功能,运行过程中会主动打断用户操作,寻求反馈。用户有时也可以自行设置参数,如调整 Agent 打断的频率等。再比如询问模式,它不只是依赖特定的系统提示词,还会限制 Agent 调用某些与文件编辑相关的工具,以此来保证功能的稳定性和可靠性。

 

Harrison Chase:回到之前的话题,关于大家使用 Cursor 的不同方式,你觉得未来使用编码 Agent 或者说 Cursor,存在所谓的 “最佳方式” 吗?

 

Jason Ginsberg:我觉得并没有什么 “最佳方式”,具体的使用方法很大程度上取决于工程师的个人工作习惯以及他们所处理的具体工作内容。目前行业里,既有异步运行Agent的应用场景,也有开发者深度参与、实时交互的模式,就像一边编程、一边像画画一样实时调整代码或者进行可视化的编辑操作。不过我经常在推特上看到一些所谓的 “Agent 使用技巧”,其实对此我是有点持保留态度的。很多人会说 “这才是使用 Agent 的最佳方式”,但在我看来,这些技巧往往是凭空杜撰的。

 

我们团队内部其实并不会使用那些冗长复杂的提示词,也不会采用多阶段规划的策略。大多数时候,我们都是快速迭代,如果 Agent 运行的结果不理想,就直接终止进程,重新启动 Agent。通常这种方式的效率是最高的。

自然 “唠嗑”是 Cursor 最终交互模式?

Harrison Chase:如果让你预测一下一年后的情况,你认为开发者在 IDE、终端以及其他形态的载体上使用 Cursor 的时间占比会是怎样的?

 

Jason Ginsberg:当然,我肯定会带有一定的主观偏向性。但我认为,终端工具并不会成为用户的首选。我觉得,真正驱动行业发展的是用户对Agent的信任度不断提升,他们更希望等到Agent完成所有工作后再查看最终的修改结果,然后决定是否采纳,同时也愿意让 Agent 运行更长的时间,以实现更智能的处理。

 

而 IDE 之所以至关重要,是因为它是为整个软件开发周期量身打造的工具。从项目的构思规划,到运行代码修改、查看代码内容、清晰对比代码差异、提交代码合并请求,再到在浏览器中预览效果所有这些环节,都可以无缝集成在 IDE 的模块化功能之中。这一点其实很容易被忽视,毕竟 IDE 的这些功能是经过了数十年的发展才逐步完善起来的。

 

我认为,当前行业的一个明显趋势是,产品层面的设计变得越来越重要。现在 Cursor 用户使用频率最高的功能,如规划模式,其实都需要可视化编辑器的支持,用户需要能够在编辑器中添加注释,并进行实时交互。一旦脱离了按钮、弹窗和菜单这些可视化交互元素,用户与工具的交互难度会大大增加。

 

不过,我觉得未来并非所有操作都必须局限在笔记本电脑的 IDE 中完成。这种模式并不会被完全取代,具体的使用场景会根据实际需求灵活变化,适用的场景也会更加广泛。用户在更多场景下,都能够使用到 Cursor 这样的工具。

 

Harrison Chase:未来会有更多场景都能用上像 Cursor 这样的工具。你们应该有对应的官网吧?用户可以直接在网页上进行交互操作,是这个思路吗?

 

Jason Ginsberg:对,我们确实有官网。这么做的原因是用户可以通过手机等设备随时随地访问。我觉得在不远的将来,用户完全可以戴着 AirPods,开启语音模式,和Agent实时沟通、碰撞想法,让Agent不断优化方案。等用户到了办公室,打开笔记本电脑,就已经有一堆代码修改记录或者演示视频等着审核了,到时候只需要简单确认通过或者驳回就行。如果某些细节还需要微调,再把项目下载到本地修改就好。

 

Harrison Chase:我认为 Cursor 真正的优势,在于围绕 Agent 交互打造的整套设计和用户体验体系。你之前在 Notion 工作过,我记得即便是在生成式 AI 普及之前,Notion 的设计和用户体验就已经广受认可了。当然,他们在生成式 AI 时代也很好地完成了转型。从一家在生成式 AI 普及前就拥有出色设计积淀且顺利完成转型的公司,再到如今专注 Agent 相关工作,你觉得 Agent 的出现给产品设计和用户体验带来了哪些变化?现在的工作模式和之前有相似之处吗?

 

Jason Ginsberg:我觉得总体来说,我们产品的大部分设计其实并不是 AI 专属的。要知道,产品可用的交互组件和用户体验模式就那么多,市面上的应用本质上也都是基于一些传统的模式搭建的,如收件箱、仪表盘、聊天界面,这些都是很成熟的设计。所以我们的工作核心,更多是把这些现有的设计模式进行合理组合,然后在产品中恰当地呈现出来。这一点和 Notion 的产品理念是相通的,同时也是 Cursor 和集成开发环境(IDE)的核心特质:极高的模块化程度。

 

作为用户,你会发现每个人的 IDE 界面布局都可以千差万别。你可以自定义面板布局,把任意组件拖放到任意位置,和坐在你旁边的同事设置出完全不同的界面。我认为这种模块化设计对产品的适应性至关重要,毕竟如我之前所说,Agent 的能力发展日新月异,用户对产品的需求和期待几乎每隔几周就会发生变化。几个月前我们推出 Cursor 2.0 的时候,并没有把原来的产品推倒重来,只是把各个功能模块重新组合,调整为侧边栏收件箱式的管理布局,同时优化了聊天界面的信息密度而已。

 

Harrison Chase:听你这么说,很多组件的底层逻辑其实是相通的。那有没有出现新的组件?或者某些组件的优先级发生了变化?毕竟这些组件最初都是为 “人类与软件交互”“人类通过软件协作” 的场景设计的,现在加入了 Agent 这个新角色。这其中有没有产生什么新的变化?还是说其实本质上没有太大不同?

 

Jason Ginsberg:我认为底层的设计逻辑和核心要素其实没有变,关键变化在于谁在主导界面交互。而在这个核心框架下,其实可以演变出无数种交互形式。就拿交互的抽象层级来说,一年前大家使用Agent的时候,都恨不得盯着它的每一步操作,全程 “盯梢”。但现在 Agent 的操作步骤变得无比繁杂,用户根本看不过来。所以我们需要优化信息呈现方式:如何对操作步骤进行分组?如何提炼关键信息?

 

当用户足够信任 Agent 的操作后,我们就需要把重点放在文件的实际修改内容上,并且为这些修改添加更详细的注释说明。当然,我们也可以进一步提升交互的灵活度,比如聊天对象不再局限于单个 Agent,而是可以同时和多个 Agent 对话。这就需要一套更智能的后台交互逻辑来支撑 ,系统要能识别用户在和哪个子 Agent 对话,并且协调这些 Agent 完成对应的修改。未来这种交互的抽象层级还会不断提升。

 

Harrison Chase:你觉得交互的抽象层级最高能达到什么程度?我知道预测未来很难,但还是想听听你的看法。

 

Jason Ginsberg:我觉得未来,我们现在看到的各种操作选项,如选择模型、选择功能模式、选择运行环境这些都会逐渐消失。最终的交互模式会变得像和真人对话一样自然。但这并不意味着任何人都能随便写代码,在那个阶段,这个工具依然是为专业工程师服务的。因为你还是需要具备专业的行业术语知识,清楚自己想要修改的内容是什么。做产品的人,要明确自己想要的工作流程和功能需求;做基础设施的人,要足够了解代码库,知道什么样的架构和系统设计最适合当前要开发的项目。

 

而且我想强调的是,随着抽象层级的提升,我们并不会摒弃现有的功能。用户依然可以随时深入底层,查看细节、调整参数。只是产品的默认交互方式会不断优化升级。

Cursor 内部工作揭秘:少审代码、高频反馈

Harrison Chase:你之前提到了人类在 Agent 工作流程中的角色,比如查看代码差异、进行代码审查。你觉得 AI 会给代码审查工作带来哪些改变?

 

Jason Ginsberg:首先,就我们产品团队的工作模式来说,现在人工审查的比重已经大幅降低了。我们有一个叫 BugBot 的工具,它会自动检测代码问题,并且自主完成修复,还会在持续集成(CI)流程中不断迭代优化。这个工具的表现非常出色,也让我们对 AI 审查的代码质量更有信心。

 

其次是信息的语义化分组。用户查看代码差异时,可以清晰地看到 Agent 做了哪些修改。我们甚至可以展示 Agent 的原始指令,更理想的状态是,Agent 能够像人类一样,在处理大型代码合并请求时,为每一处修改附上注释,说明这么做的原因。我觉得这虽然算不上颠覆性的变革,但确实能给代码审查工作带来显著的优化。

 

Harrison Chase:出于好奇,我想问一下,Cursor 的工程师用 Cursor 写代码,用 BugBot 审查代码,那他们还需要和其他工程师沟通协作吗?

 

Jason Ginsberg:哈哈,这个问题很有意思。如果你以工程师的身份加入 Cursor,会立刻发现一个现象:所有人都在深度使用自家产品。我记得我入职第一周的时候,修改了一个快捷键设置。那个快捷键是 Alt+Shift+Command+J,非常冷门,我当时觉得选这个键肯定没人会注意到。结果刚改完不到半分钟,就有三个同事在 Slack 上发来消息:“你改的这个快捷键直接打乱了我的工作流程!到底怎么回事?”几乎任何产品改动,都会立刻收到同事们的强烈反馈。我觉得这其实是一件好事,大家就是在这种高频的反馈和交流中,快速推进产品迭代的。

 

Harrison Chase:从组织管理的角度,你们有没有采取什么措施来鼓励或者引导这种高频反馈的协作模式?毕竟大量的反馈涌进来,有时候也会让人应接不暇。

 

Jason Ginsberg:在我创办自己的公司之前,工程师们也会用邮件沟通,但用得并不多。大家甚至会说:“邮件只用来收垃圾邮件和购物通知,可别用它来发长篇大论的工作内容。”而在Agent这个赛道工作,其实完全不需要依赖邮件这种低效的沟通方式。我们团队的所有人都全身心投入工作,毕竟这是一个竞争非常激烈的领域,大家都对产品开发充满热情,会自然而然地用各种即时沟通工具协作。

 

另外,我在规划产品功能时,会遵循一个核心原则:我能开发什么功能,让自己的日常工作更轻松? 具体来说,就是思考 “做什么能帮我明天更高效地完成工作,不用再处理那些烦人的报错和问题”。这个原则指导着我们的大部分工作。毕竟这种功能开发出来之后,我们自己能立刻受益,比如修复了一个烦人的漏洞,以后上班就不用再被这个问题困扰了。

迭代狂飙背后,核心功能竟来自员工 “自嗨”?

Harrison Chase:你觉得你们的产品路线图,有多大比例是由 “让自己工作更轻松” 这个需求驱动的?又有多大比例是来自外部用户的需求?这个比例随着公司发展有变化吗?

 

Jason Ginsberg:这个比例确实随着公司规模的扩大在变化。现在我们也会制定月度的产品路线图和目标,但说实话,我们很多核心功能都来自自下而上的创新。比如 Cursor 的Agent功能,这可以说是大家提到 Cursor 时最先想到的核心功能。这个功能是我们团队的一个人开发的,最开始所有人都不看好这个想法,但他很快做出了原型。大家试用之后都惊叹:“哇,这东西居然真的能用!”

 

我之前提到的调试模式也是如此。感恩节假期的时候我闲着没事,就开发了这个自己很需要的功能,现在这个功能也即将上线。这些功能的开发初衷,都是为了解决团队内部的需求。我们判断一个功能是否具备发布条件,一个重要的衡量标准就是内部的使用率和认可度。

 

Harrison Chase:你们的产品迭代速度快得惊人,是怎么保持这种高效的开发节奏的?

 

Jason Ginsberg:说实话,我们的工作流程其实非常精简,没有太多繁琐的制度。公司里虽然有几间会议室,也有一两位产品经理,但我们很少通过撰写文档或者开对齐会议来推进工作,大部分的讨论和决策都是在代码层面完成的。而这一切能够实现的核心原因,是我们对人才的极高要求。今年年初的时候,公司总共也就 20 人左右。之所以团队规模增长缓慢,就是因为我们的招聘门槛高到近乎苛刻。我们会反复评估:这个人很优秀,但他能成为团队里最顶尖的那批人吗?

 

正因为团队里的每个人都足够出色,所以我们可以放心地把任务交给任何一个人。团队成员的主观能动性都极强,从提出想法、设计用户体验,到在推特上回复用户的支持请求、和企业客户沟通需求,再到最终将功能落地,整个流程都能独立完成。所以说,我们能保持这样的速度,归根结底还是人的因素。

 

Harrison Chase:你们是如何规划产品路线图的?你刚才提到了以月为单位的规划周期,这是目前的常规规划时长吗?有没有更长期的规划?另外,行业技术迭代的速度实在太快了,你们是如何平衡 “跟进现有技术浪潮” 和 “实现技术跨越式发展” 这两者的?会不会主动预判技术趋势,提前布局未来方向?

 

Jason Ginsberg:我们确实会投入不少精力去思考未来,比如预判未来三个月可能实现的技术突破,然后主动押注相关方向,团队里有相当一部分人都在做这类前瞻性的工作。我们制定的月度路线图更多是围绕核心产品功能展开,聚焦于用户的实际需求以及那些能优化日常使用体验的功能。而那些需要投入两个月时间重构底层逻辑的重大项目,则会纳入更长期的规划范畴。

此外,我们的应变能力其实非常强。

 

有时候我们会提前拿到新模型的测试版本,试用之后如果发现它在某些方面表现特别出色,团队成员往往会主动利用周末时间加班,争取在新模型正式发布前就完成相关功能的开发。很多重要功能其实几天之内就能搭建完成。

 

Harrison Chase:说到模型,你们发布了自研的 Composer 模型。开发这个模型的初衷是什么?目前用户的使用情况如何?这个模型有没有改变大家使用 Cursor 的习惯?

 

Jason Ginsberg:我们发现,工程师使用我们产品时的编码场景,需要有专门适配的模型来支撑。Composer 模型就是针对这类场景打造的,它定位非常明确,具备速度快、质量高、逻辑智能三大特点,尤其适合 “人机实时协作” 场景。我自己做前端开发时就经常用它,因为我需要频繁做出细微的交互设计决策,这就要求 Agent 能在几秒内给出反馈。Composer 就像一个高效的协作伙伴,能快速响应需求、碰撞想法,和那些适用于长周期异步任务的模型形成了很好的互补。

 

Harrison Chase:Cursor 的 Agent 相关研发工作是全员参与,还是有专门的团队负责?

 

Jason Ginsberg:我们确实有专门的团队负责 Agent 的性能优化,他们主要聚焦于工具链、调度框架的搭建以及效果评估。但正如我之前所说,我们的团队架构并不僵化,没有严格限制大家的工作范围。比如核心产品团队的工程师在开发规划模式时,如果需要对Agent进行调整,就会和Agent团队密切协作。而且在开发过程中,我们依然会深度使用自家产品进行测试,团队成员会分享使用感受,以此来评估功能的实际效果。

 

Harrison Chase:无论是 Agent 团队的成员,还是其他团队中擅长 Agent 研发的工程师,他们身上有没有什么共同特质?他们的专业背景或者个人能力有没有什么特别之处?

 

Jason Ginsberg:我觉得他们大多是偏产品方向的人才,而不是传统意义上的机器学习或算法研究专家。这些人经常在不同团队之间轮岗,因为Agent研发需要对用户的最终使用体验有很强的直觉,同时还要能准确解读团队的反馈意见。

 

Harrison Chase:上周你们和 OpenAI 合作发布了一篇博客,内容是针对 OpenAI 的新模型优化 Cursor 的 Agent 调度框架。我在推特上经常看到大家讨论 “Agent 调度框架” 这个概念。你们是如何看待模型的底层支撑架构的?这类架构是否需要和特定模型深度绑定?比如 Composer 模型和 CodeLlama 模型,对应的架构会不会有很大差异?

 

Jason Ginsberg:我其实没有深度参与这方面的工作,但据我了解,我们的核心目标是打造高度灵活的架构。毕竟我们需要不断尝试新技术、新功能模式,所以架构必须能够随着模型能力的升级快速适配。

 

Harrison Chase:很有道理。毕竟整个行业都在飞速变化。

开放问答

提问者 1:刚才提到了新增的可视化浏览器功能,我发现有些工具比如 Lovable 也有类似的功能。请问这个功能是朝着 “沉浸式可视化编码” 的方向发展吗?

 

Jason Ginsberg:我觉得它并不是为沉浸式可视化编码设计的。就像我之前说的,这个功能最初是我为自己开发的,我本身就是一名做产品的工程师,它的核心用户群体其实是专业工程师和设计师。大家在开发应用时,肯定都遇到过这种情况:精心设计的界面,最后却变成了大家都看腻了的紫黄渐变配色。这个功能就是为了让大家能够精准把控细节,比如把内边距调整到精确的像素值。它为用户提供了一套更直观的 “视觉化操作语言”,比纯文本指令的精度更高。

 

而且就算不使用侧边栏,你也可以直接点击页面元素,随时输入提示词下达指令。借助这个功能,你可以在几秒内同时启动六个 Agent。如果开启热重载功能,你的网站会实时呈现修改效果,用起来其实还挺有意思的。

 

提问者 2:我特别喜欢你们的浏览器 Agent,一直在用。但我发现一个小瑕疵:我想持续迭代优化设计方案,可 Agent 总是会中断我的工作,直接提交代码合并请求。未来有没有可能实现不间断的持续迭代?

 

Jason Ginsberg:当然可以。未来的发展方向就是让 Agent 具备自主评估能力,根据需求长时间持续运行、循环迭代。现在的调试模式还需要人工点击按钮来确认日志信息,但这只是过渡方案。理想的状态是,Agent能够自主完成评估、迭代,直到彻底解决问题。

 

提问者 3:我不知道你是否深度参与 Agent 相关的研发工作,但我注意到 Cursor 的内存管理功能做得很好。它可以根据工程师个人、部门乃至整个公司的偏好、规则和流程,自主管理相关信息。我们都知道,信息和上下文对 Agent 来说至关重要。请问你们有没有计划进一步拓展和升级这个功能?尤其是在长上下文处理方面,你们有什么思路?

 

Jason Ginsberg:我们正在进行大量的实验和探索。目前已经落地了规则管理、内存记忆、技能库等多个功能模块。现阶段,我们主要在研究高效的信息摘要技术。另外,借助我们的自研模型,我们也在探索让模型自主识别对话或代码中反复出现的关键信息。当然,跨组织的信息共享功能也很值得探索。不过这里有个需要注意的点,相关规则和信息可能会随着模型的迭代而过时。所以我们必须确保用户能够轻松更新这些内容,避免被过时的规则束缚。

 

提问者 4:关于你们发布的 Composer 模型,我认识一些开发者,他们基于 Gemini 模型微调了一个医疗领域的专用模型。但他们发现,这个微调后的模型效果还不如直接用原生 Gemini 模型做单次提示词调用。他们分析的原因是,微调模型需要持续维护,要跟上 Gemini 等基础模型的更新节奏。请问你们是如何制定策略,确保 Composer 模型不会落伍的?

 

Jason Ginsberg:你说的是 Composer 模型,对吧?我们会持续对它进行迭代优化,它并不是一个静态的模型。我们的核心关注点,是在速度和智能之间找到最佳平衡点,满足 Cursor 用户在大部分场景下的需求。不过在长上下文处理这类特定领域,我们确实还有提升空间。

 

提问者 5:我自己是产品经理,一直在用 Cursor 做原型开发,甚至在团队里还客串设计师,用它替代 Figma。我很好奇,有没有用户是在使用 Cursor 之前,从未安装过任何集成开发环境(IDE)的?这类用户会不会成为你们未来重点关注的群体?毕竟现在的编码 Agent 已经足够强大,很多工作都能在上面完成。

 

Jason Ginsberg:坦白说,我们目前并没有把这类用户作为核心关注点。当然,我们认同工具的使用门槛确实需要不断降低,而且 Cursor 的易用性也在持续提升,比如新增的浏览器工具对设计师就很友好。但我们的核心目标,其实是赋能顶尖工程师。我们一直在思考:如何让世界上最优秀的工程师变得更加强大?在这个过程中,我们开发的工具自然会惠及更多人群。不过在产品优化方面,我们确实还有很多工作要做,如优化新手引导和环境配置流程。毕竟设计师和产品经理在配置 GitHub 等工具时,经常会遇到困难。我们希望通过优化这些环节,吸引更多用户尝试 Cursor。

 

提问者 6:我一直在尝试用 Cursor 做智能合约的验证矩阵构建和试运行逻辑测试。请问在深度质量检测和安全加固方面,有没有什么不太为人知的实用工作流可以推荐?或者刚才提到的调试工具能不能派上用场?我对智能合约的质量检测特别感兴趣。

 

Jason Ginsberg:说实话,我们正在尝试让 Agent 自主完成测试工作,不过这项功能目前还没有完全发布。对于从事质量检测工作的人员来说,我强烈推荐试试我们刚发布的调试模式。这个功能定位问题的逻辑非常清晰,几乎可以说是确定性的,用起来会很有帮助。

 

提问者 7:您认为未来两到四个月,Cursor 面临的最大机遇是什么?会不会是语音 Agent?

 

Jason Ginsberg:我觉得机遇不在于语音 Agent。用户现阶段最核心的需求,其实是让 Agent 变得更智能、运行时间更长、能处理的任务更多。现在的很多 Agent,本质上只是在 “读取代码”,并不能真正判断修改后的代码是否有效。未来的发展空间非常大,我们可以投入更多算力,让 Agent 承担更多人类目前负责的校验工作。我觉得未来三到六个月,整个行业都会迎来巨大的变革,非常值得期待。

 

参考链接:

https://www.youtube.com/watch?v=dKSGK-fPFyU

整理 | 华卫、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,甚至会同时运行多个 Agent 并行处理任务。

 

至于我个人的使用习惯,我并不会去设计那些复杂繁琐的提示词,也没有什么所谓的 “Agent 使用秘籍”。我写的提示词往往都很简短,甚至还会带有拼写错误。我会针对手头不同的工作任务,或者同一个问题的不同模块,同时启动多个 Agent,然后等待它们返回结果。

 

目前我用得最多的是我们今天刚刚发布的一个新功能:调试模式。这个模式下,Agent 能够通过生成日志来进行自我评估,之后开发者复现相关操作步骤,Agent 就会通过查看日志判断问题是否得到解决。这个功能非常实用,因为它相当于通过投入算力去不断尝试解决问题,最终攻克那些手动排查起来极为棘手的难题。

 

Harrison Chase:调试模式具体是什么样的?为什么需要专门设置这样一个模式?难道不能自动完成调试吗?直接给 Agent 下达调试指令不也可以吗?

 

Jason Ginsberg:其实我也认同你的这个想法。所以在开发调试模式的时候,我们内部确实有过不少争论。主要原因在于,Cursor 目前已经有很多功能模式了,如规划模式、询问模式等等,这些模式其实不太容易被用户发现。我们一直认为,这些模式都很实用,理想的状态应该是,Agent 能够根据用户的操作场景,自动匹配并启用最合适的模式,无需用户手动切换。

 

而现阶段调试模式之所以需要手动开启,是因为它的交互方式比较特殊。在运行过程中,Agent 会暂停当前的工作,向用户提问以获取反馈。如果用户不熟悉这种交互逻辑,可能会觉得比较困扰。

 

Harrison Chase:Agent 具体会询问哪些问题,又需要用户提供什么样的反馈呢?

 

Jason Ginsberg:我举个例子吧。假设我正在开发一个前端应用,遇到了一个很让人头疼的问题:菜单总是在左上角弹出。这时候我会对Agent说:“这个菜单需要锚定到按钮的位置。” 随后,Agent 会启动服务器,并在整个代码库中添加大量日志,同时提出一系列可能导致该问题的假设,如 “可能是某个定位参数设置错误”、“可能是事件绑定逻辑有问题” 等。之后,Agent 会提示我:“麻烦你点击这个按钮,打开菜单,看看问题是否解决。” 如果我反馈问题依然存在,Agent 就会查看生成的日志,然后分析判断:“这个假设成立,那两个假设不成立”。通常这样反复两三次之后,Agent 往往就能找出并解决问题。

 

Harrison Chase:你觉得人类还需要手动操作多久?就不能让 Agent 自主完成点击、测试这类操作吗?

 

Jason Ginsberg:一两个月内,毕竟这个行业的发展速度实在太快了。

 

Harrison Chase:刚才你提到了 Agent 的多种不同模式,比如规划模式、解释模式、调试模式等等。这些模式在实际应用中到底意味着什么?难道只是为 Agent 设置不同的提示词这么简单吗?还是说背后有更复杂的逻辑?

 

Jason Ginsberg:很多时候,确实就是修改一下系统层面的提示词。不过在某些情况下,我们也需要对用户界面进行相应的调整。比如规划模式现在也加入了交互提问功能,运行过程中会主动打断用户操作,寻求反馈。用户有时也可以自行设置参数,如调整 Agent 打断的频率等。再比如询问模式,它不只是依赖特定的系统提示词,还会限制 Agent 调用某些与文件编辑相关的工具,以此来保证功能的稳定性和可靠性。

 

Harrison Chase:回到之前的话题,关于大家使用 Cursor 的不同方式,你觉得未来使用编码 Agent 或者说 Cursor,存在所谓的 “最佳方式” 吗?

 

Jason Ginsberg:我觉得并没有什么 “最佳方式”,具体的使用方法很大程度上取决于工程师的个人工作习惯以及他们所处理的具体工作内容。目前行业里,既有异步运行Agent的应用场景,也有开发者深度参与、实时交互的模式,就像一边编程、一边像画画一样实时调整代码或者进行可视化的编辑操作。不过我经常在推特上看到一些所谓的 “Agent 使用技巧”,其实对此我是有点持保留态度的。很多人会说 “这才是使用 Agent 的最佳方式”,但在我看来,这些技巧往往是凭空杜撰的。

 

我们团队内部其实并不会使用那些冗长复杂的提示词,也不会采用多阶段规划的策略。大多数时候,我们都是快速迭代,如果 Agent 运行的结果不理想,就直接终止进程,重新启动 Agent。通常这种方式的效率是最高的。

自然 “唠嗑”是 Cursor 最终交互模式?

Harrison Chase:如果让你预测一下一年后的情况,你认为开发者在 IDE、终端以及其他形态的载体上使用 Cursor 的时间占比会是怎样的?

 

Jason Ginsberg:当然,我肯定会带有一定的主观偏向性。但我认为,终端工具并不会成为用户的首选。我觉得,真正驱动行业发展的是用户对Agent的信任度不断提升,他们更希望等到Agent完成所有工作后再查看最终的修改结果,然后决定是否采纳,同时也愿意让 Agent 运行更长的时间,以实现更智能的处理。

 

而 IDE 之所以至关重要,是因为它是为整个软件开发周期量身打造的工具。从项目的构思规划,到运行代码修改、查看代码内容、清晰对比代码差异、提交代码合并请求,再到在浏览器中预览效果所有这些环节,都可以无缝集成在 IDE 的模块化功能之中。这一点其实很容易被忽视,毕竟 IDE 的这些功能是经过了数十年的发展才逐步完善起来的。

 

我认为,当前行业的一个明显趋势是,产品层面的设计变得越来越重要。现在 Cursor 用户使用频率最高的功能,如规划模式,其实都需要可视化编辑器的支持,用户需要能够在编辑器中添加注释,并进行实时交互。一旦脱离了按钮、弹窗和菜单这些可视化交互元素,用户与工具的交互难度会大大增加。

 

不过,我觉得未来并非所有操作都必须局限在笔记本电脑的 IDE 中完成。这种模式并不会被完全取代,具体的使用场景会根据实际需求灵活变化,适用的场景也会更加广泛。用户在更多场景下,都能够使用到 Cursor 这样的工具。

 

Harrison Chase:未来会有更多场景都能用上像 Cursor 这样的工具。你们应该有对应的官网吧?用户可以直接在网页上进行交互操作,是这个思路吗?

 

Jason Ginsberg:对,我们确实有官网。这么做的原因是用户可以通过手机等设备随时随地访问。我觉得在不远的将来,用户完全可以戴着 AirPods,开启语音模式,和Agent实时沟通、碰撞想法,让Agent不断优化方案。等用户到了办公室,打开笔记本电脑,就已经有一堆代码修改记录或者演示视频等着审核了,到时候只需要简单确认通过或者驳回就行。如果某些细节还需要微调,再把项目下载到本地修改就好。

 

Harrison Chase:我认为 Cursor 真正的优势,在于围绕 Agent 交互打造的整套设计和用户体验体系。你之前在 Notion 工作过,我记得即便是在生成式 AI 普及之前,Notion 的设计和用户体验就已经广受认可了。当然,他们在生成式 AI 时代也很好地完成了转型。从一家在生成式 AI 普及前就拥有出色设计积淀且顺利完成转型的公司,再到如今专注 Agent 相关工作,你觉得 Agent 的出现给产品设计和用户体验带来了哪些变化?现在的工作模式和之前有相似之处吗?

 

Jason Ginsberg:我觉得总体来说,我们产品的大部分设计其实并不是 AI 专属的。要知道,产品可用的交互组件和用户体验模式就那么多,市面上的应用本质上也都是基于一些传统的模式搭建的,如收件箱、仪表盘、聊天界面,这些都是很成熟的设计。所以我们的工作核心,更多是把这些现有的设计模式进行合理组合,然后在产品中恰当地呈现出来。这一点和 Notion 的产品理念是相通的,同时也是 Cursor 和集成开发环境(IDE)的核心特质:极高的模块化程度。

 

作为用户,你会发现每个人的 IDE 界面布局都可以千差万别。你可以自定义面板布局,把任意组件拖放到任意位置,和坐在你旁边的同事设置出完全不同的界面。我认为这种模块化设计对产品的适应性至关重要,毕竟如我之前所说,Agent 的能力发展日新月异,用户对产品的需求和期待几乎每隔几周就会发生变化。几个月前我们推出 Cursor 2.0 的时候,并没有把原来的产品推倒重来,只是把各个功能模块重新组合,调整为侧边栏收件箱式的管理布局,同时优化了聊天界面的信息密度而已。

 

Harrison Chase:听你这么说,很多组件的底层逻辑其实是相通的。那有没有出现新的组件?或者某些组件的优先级发生了变化?毕竟这些组件最初都是为 “人类与软件交互”“人类通过软件协作” 的场景设计的,现在加入了 Agent 这个新角色。这其中有没有产生什么新的变化?还是说其实本质上没有太大不同?

 

Jason Ginsberg:我认为底层的设计逻辑和核心要素其实没有变,关键变化在于谁在主导界面交互。而在这个核心框架下,其实可以演变出无数种交互形式。就拿交互的抽象层级来说,一年前大家使用Agent的时候,都恨不得盯着它的每一步操作,全程 “盯梢”。但现在 Agent 的操作步骤变得无比繁杂,用户根本看不过来。所以我们需要优化信息呈现方式:如何对操作步骤进行分组?如何提炼关键信息?

 

当用户足够信任 Agent 的操作后,我们就需要把重点放在文件的实际修改内容上,并且为这些修改添加更详细的注释说明。当然,我们也可以进一步提升交互的灵活度,比如聊天对象不再局限于单个 Agent,而是可以同时和多个 Agent 对话。这就需要一套更智能的后台交互逻辑来支撑 ,系统要能识别用户在和哪个子 Agent 对话,并且协调这些 Agent 完成对应的修改。未来这种交互的抽象层级还会不断提升。

 

Harrison Chase:你觉得交互的抽象层级最高能达到什么程度?我知道预测未来很难,但还是想听听你的看法。

 

Jason Ginsberg:我觉得未来,我们现在看到的各种操作选项,如选择模型、选择功能模式、选择运行环境这些都会逐渐消失。最终的交互模式会变得像和真人对话一样自然。但这并不意味着任何人都能随便写代码,在那个阶段,这个工具依然是为专业工程师服务的。因为你还是需要具备专业的行业术语知识,清楚自己想要修改的内容是什么。做产品的人,要明确自己想要的工作流程和功能需求;做基础设施的人,要足够了解代码库,知道什么样的架构和系统设计最适合当前要开发的项目。

 

而且我想强调的是,随着抽象层级的提升,我们并不会摒弃现有的功能。用户依然可以随时深入底层,查看细节、调整参数。只是产品的默认交互方式会不断优化升级。

Cursor 内部工作揭秘:少审代码、高频反馈

Harrison Chase:你之前提到了人类在 Agent 工作流程中的角色,比如查看代码差异、进行代码审查。你觉得 AI 会给代码审查工作带来哪些改变?

 

Jason Ginsberg:首先,就我们产品团队的工作模式来说,现在人工审查的比重已经大幅降低了。我们有一个叫 BugBot 的工具,它会自动检测代码问题,并且自主完成修复,还会在持续集成(CI)流程中不断迭代优化。这个工具的表现非常出色,也让我们对 AI 审查的代码质量更有信心。

 

其次是信息的语义化分组。用户查看代码差异时,可以清晰地看到 Agent 做了哪些修改。我们甚至可以展示 Agent 的原始指令,更理想的状态是,Agent 能够像人类一样,在处理大型代码合并请求时,为每一处修改附上注释,说明这么做的原因。我觉得这虽然算不上颠覆性的变革,但确实能给代码审查工作带来显著的优化。

 

Harrison Chase:出于好奇,我想问一下,Cursor 的工程师用 Cursor 写代码,用 BugBot 审查代码,那他们还需要和其他工程师沟通协作吗?

 

Jason Ginsberg:哈哈,这个问题很有意思。如果你以工程师的身份加入 Cursor,会立刻发现一个现象:所有人都在深度使用自家产品。我记得我入职第一周的时候,修改了一个快捷键设置。那个快捷键是 Alt+Shift+Command+J,非常冷门,我当时觉得选这个键肯定没人会注意到。结果刚改完不到半分钟,就有三个同事在 Slack 上发来消息:“你改的这个快捷键直接打乱了我的工作流程!到底怎么回事?”几乎任何产品改动,都会立刻收到同事们的强烈反馈。我觉得这其实是一件好事,大家就是在这种高频的反馈和交流中,快速推进产品迭代的。

 

Harrison Chase:从组织管理的角度,你们有没有采取什么措施来鼓励或者引导这种高频反馈的协作模式?毕竟大量的反馈涌进来,有时候也会让人应接不暇。

 

Jason Ginsberg:在我创办自己的公司之前,工程师们也会用邮件沟通,但用得并不多。大家甚至会说:“邮件只用来收垃圾邮件和购物通知,可别用它来发长篇大论的工作内容。”而在Agent这个赛道工作,其实完全不需要依赖邮件这种低效的沟通方式。我们团队的所有人都全身心投入工作,毕竟这是一个竞争非常激烈的领域,大家都对产品开发充满热情,会自然而然地用各种即时沟通工具协作。

 

另外,我在规划产品功能时,会遵循一个核心原则:我能开发什么功能,让自己的日常工作更轻松? 具体来说,就是思考 “做什么能帮我明天更高效地完成工作,不用再处理那些烦人的报错和问题”。这个原则指导着我们的大部分工作。毕竟这种功能开发出来之后,我们自己能立刻受益,比如修复了一个烦人的漏洞,以后上班就不用再被这个问题困扰了。

迭代狂飙背后,核心功能竟来自员工 “自嗨”?

Harrison Chase:你觉得你们的产品路线图,有多大比例是由 “让自己工作更轻松” 这个需求驱动的?又有多大比例是来自外部用户的需求?这个比例随着公司发展有变化吗?

 

Jason Ginsberg:这个比例确实随着公司规模的扩大在变化。现在我们也会制定月度的产品路线图和目标,但说实话,我们很多核心功能都来自自下而上的创新。比如 Cursor 的Agent功能,这可以说是大家提到 Cursor 时最先想到的核心功能。这个功能是我们团队的一个人开发的,最开始所有人都不看好这个想法,但他很快做出了原型。大家试用之后都惊叹:“哇,这东西居然真的能用!”

 

我之前提到的调试模式也是如此。感恩节假期的时候我闲着没事,就开发了这个自己很需要的功能,现在这个功能也即将上线。这些功能的开发初衷,都是为了解决团队内部的需求。我们判断一个功能是否具备发布条件,一个重要的衡量标准就是内部的使用率和认可度。

 

Harrison Chase:你们的产品迭代速度快得惊人,是怎么保持这种高效的开发节奏的?

 

Jason Ginsberg:说实话,我们的工作流程其实非常精简,没有太多繁琐的制度。公司里虽然有几间会议室,也有一两位产品经理,但我们很少通过撰写文档或者开对齐会议来推进工作,大部分的讨论和决策都是在代码层面完成的。而这一切能够实现的核心原因,是我们对人才的极高要求。今年年初的时候,公司总共也就 20 人左右。之所以团队规模增长缓慢,就是因为我们的招聘门槛高到近乎苛刻。我们会反复评估:这个人很优秀,但他能成为团队里最顶尖的那批人吗?

 

正因为团队里的每个人都足够出色,所以我们可以放心地把任务交给任何一个人。团队成员的主观能动性都极强,从提出想法、设计用户体验,到在推特上回复用户的支持请求、和企业客户沟通需求,再到最终将功能落地,整个流程都能独立完成。所以说,我们能保持这样的速度,归根结底还是人的因素。

 

Harrison Chase:你们是如何规划产品路线图的?你刚才提到了以月为单位的规划周期,这是目前的常规规划时长吗?有没有更长期的规划?另外,行业技术迭代的速度实在太快了,你们是如何平衡 “跟进现有技术浪潮” 和 “实现技术跨越式发展” 这两者的?会不会主动预判技术趋势,提前布局未来方向?

 

Jason Ginsberg:我们确实会投入不少精力去思考未来,比如预判未来三个月可能实现的技术突破,然后主动押注相关方向,团队里有相当一部分人都在做这类前瞻性的工作。我们制定的月度路线图更多是围绕核心产品功能展开,聚焦于用户的实际需求以及那些能优化日常使用体验的功能。而那些需要投入两个月时间重构底层逻辑的重大项目,则会纳入更长期的规划范畴。

此外,我们的应变能力其实非常强。

 

有时候我们会提前拿到新模型的测试版本,试用之后如果发现它在某些方面表现特别出色,团队成员往往会主动利用周末时间加班,争取在新模型正式发布前就完成相关功能的开发。很多重要功能其实几天之内就能搭建完成。

 

Harrison Chase:说到模型,你们发布了自研的 Composer 模型。开发这个模型的初衷是什么?目前用户的使用情况如何?这个模型有没有改变大家使用 Cursor 的习惯?

 

Jason Ginsberg:我们发现,工程师使用我们产品时的编码场景,需要有专门适配的模型来支撑。Composer 模型就是针对这类场景打造的,它定位非常明确,具备速度快、质量高、逻辑智能三大特点,尤其适合 “人机实时协作” 场景。我自己做前端开发时就经常用它,因为我需要频繁做出细微的交互设计决策,这就要求 Agent 能在几秒内给出反馈。Composer 就像一个高效的协作伙伴,能快速响应需求、碰撞想法,和那些适用于长周期异步任务的模型形成了很好的互补。

 

Harrison Chase:Cursor 的 Agent 相关研发工作是全员参与,还是有专门的团队负责?

 

Jason Ginsberg:我们确实有专门的团队负责 Agent 的性能优化,他们主要聚焦于工具链、调度框架的搭建以及效果评估。但正如我之前所说,我们的团队架构并不僵化,没有严格限制大家的工作范围。比如核心产品团队的工程师在开发规划模式时,如果需要对Agent进行调整,就会和Agent团队密切协作。而且在开发过程中,我们依然会深度使用自家产品进行测试,团队成员会分享使用感受,以此来评估功能的实际效果。

 

Harrison Chase:无论是 Agent 团队的成员,还是其他团队中擅长 Agent 研发的工程师,他们身上有没有什么共同特质?他们的专业背景或者个人能力有没有什么特别之处?

 

Jason Ginsberg:我觉得他们大多是偏产品方向的人才,而不是传统意义上的机器学习或算法研究专家。这些人经常在不同团队之间轮岗,因为Agent研发需要对用户的最终使用体验有很强的直觉,同时还要能准确解读团队的反馈意见。

 

Harrison Chase:上周你们和 OpenAI 合作发布了一篇博客,内容是针对 OpenAI 的新模型优化 Cursor 的 Agent 调度框架。我在推特上经常看到大家讨论 “Agent 调度框架” 这个概念。你们是如何看待模型的底层支撑架构的?这类架构是否需要和特定模型深度绑定?比如 Composer 模型和 CodeLlama 模型,对应的架构会不会有很大差异?

 

Jason Ginsberg:我其实没有深度参与这方面的工作,但据我了解,我们的核心目标是打造高度灵活的架构。毕竟我们需要不断尝试新技术、新功能模式,所以架构必须能够随着模型能力的升级快速适配。

 

Harrison Chase:很有道理。毕竟整个行业都在飞速变化。

开放问答

提问者 1:刚才提到了新增的可视化浏览器功能,我发现有些工具比如 Lovable 也有类似的功能。请问这个功能是朝着 “沉浸式可视化编码” 的方向发展吗?

 

Jason Ginsberg:我觉得它并不是为沉浸式可视化编码设计的。就像我之前说的,这个功能最初是我为自己开发的,我本身就是一名做产品的工程师,它的核心用户群体其实是专业工程师和设计师。大家在开发应用时,肯定都遇到过这种情况:精心设计的界面,最后却变成了大家都看腻了的紫黄渐变配色。这个功能就是为了让大家能够精准把控细节,比如把内边距调整到精确的像素值。它为用户提供了一套更直观的 “视觉化操作语言”,比纯文本指令的精度更高。

 

而且就算不使用侧边栏,你也可以直接点击页面元素,随时输入提示词下达指令。借助这个功能,你可以在几秒内同时启动六个 Agent。如果开启热重载功能,你的网站会实时呈现修改效果,用起来其实还挺有意思的。

 

提问者 2:我特别喜欢你们的浏览器 Agent,一直在用。但我发现一个小瑕疵:我想持续迭代优化设计方案,可 Agent 总是会中断我的工作,直接提交代码合并请求。未来有没有可能实现不间断的持续迭代?

 

Jason Ginsberg:当然可以。未来的发展方向就是让 Agent 具备自主评估能力,根据需求长时间持续运行、循环迭代。现在的调试模式还需要人工点击按钮来确认日志信息,但这只是过渡方案。理想的状态是,Agent能够自主完成评估、迭代,直到彻底解决问题。

 

提问者 3:我不知道你是否深度参与 Agent 相关的研发工作,但我注意到 Cursor 的内存管理功能做得很好。它可以根据工程师个人、部门乃至整个公司的偏好、规则和流程,自主管理相关信息。我们都知道,信息和上下文对 Agent 来说至关重要。请问你们有没有计划进一步拓展和升级这个功能?尤其是在长上下文处理方面,你们有什么思路?

 

Jason Ginsberg:我们正在进行大量的实验和探索。目前已经落地了规则管理、内存记忆、技能库等多个功能模块。现阶段,我们主要在研究高效的信息摘要技术。另外,借助我们的自研模型,我们也在探索让模型自主识别对话或代码中反复出现的关键信息。当然,跨组织的信息共享功能也很值得探索。不过这里有个需要注意的点,相关规则和信息可能会随着模型的迭代而过时。所以我们必须确保用户能够轻松更新这些内容,避免被过时的规则束缚。

 

提问者 4:关于你们发布的 Composer 模型,我认识一些开发者,他们基于 Gemini 模型微调了一个医疗领域的专用模型。但他们发现,这个微调后的模型效果还不如直接用原生 Gemini 模型做单次提示词调用。他们分析的原因是,微调模型需要持续维护,要跟上 Gemini 等基础模型的更新节奏。请问你们是如何制定策略,确保 Composer 模型不会落伍的?

 

Jason Ginsberg:你说的是 Composer 模型,对吧?我们会持续对它进行迭代优化,它并不是一个静态的模型。我们的核心关注点,是在速度和智能之间找到最佳平衡点,满足 Cursor 用户在大部分场景下的需求。不过在长上下文处理这类特定领域,我们确实还有提升空间。

 

提问者 5:我自己是产品经理,一直在用 Cursor 做原型开发,甚至在团队里还客串设计师,用它替代 Figma。我很好奇,有没有用户是在使用 Cursor 之前,从未安装过任何集成开发环境(IDE)的?这类用户会不会成为你们未来重点关注的群体?毕竟现在的编码 Agent 已经足够强大,很多工作都能在上面完成。

 

Jason Ginsberg:坦白说,我们目前并没有把这类用户作为核心关注点。当然,我们认同工具的使用门槛确实需要不断降低,而且 Cursor 的易用性也在持续提升,比如新增的浏览器工具对设计师就很友好。但我们的核心目标,其实是赋能顶尖工程师。我们一直在思考:如何让世界上最优秀的工程师变得更加强大?在这个过程中,我们开发的工具自然会惠及更多人群。不过在产品优化方面,我们确实还有很多工作要做,如优化新手引导和环境配置流程。毕竟设计师和产品经理在配置 GitHub 等工具时,经常会遇到困难。我们希望通过优化这些环节,吸引更多用户尝试 Cursor。

 

提问者 6:我一直在尝试用 Cursor 做智能合约的验证矩阵构建和试运行逻辑测试。请问在深度质量检测和安全加固方面,有没有什么不太为人知的实用工作流可以推荐?或者刚才提到的调试工具能不能派上用场?我对智能合约的质量检测特别感兴趣。

 

Jason Ginsberg:说实话,我们正在尝试让 Agent 自主完成测试工作,不过这项功能目前还没有完全发布。对于从事质量检测工作的人员来说,我强烈推荐试试我们刚发布的调试模式。这个功能定位问题的逻辑非常清晰,几乎可以说是确定性的,用起来会很有帮助。

 

提问者 7:您认为未来两到四个月,Cursor 面临的最大机遇是什么?会不会是语音 Agent?

 

Jason Ginsberg:我觉得机遇不在于语音 Agent。用户现阶段最核心的需求,其实是让 Agent 变得更智能、运行时间更长、能处理的任务更多。现在的很多 Agent,本质上只是在 “读取代码”,并不能真正判断修改后的代码是否有效。未来的发展空间非常大,我们可以投入更多算力,让 Agent 承担更多人类目前负责的校验工作。我觉得未来三到六个月,整个行业都会迎来巨大的变革,非常值得期待。

 

参考链接:

https://www.youtube.com/watch?v=dKSGK-fPFyU

人脸机器人登上Science Robotics封面:用AI教会仿生人脸机器人「开口说话」

0%
icon展开列表
人脸机器人登上Science Robotics封面:用AI教会仿生人脸机器人「开口说话」
今天
img
实测夸克「千问划词快捷指令」,这7个邪修Prompt,建议收藏
今天
img
已证实!清华姚班陈立杰全职加入OpenAI,保留伯克利教职
今天
img
解锁任意步数文生图,港大&Adobe全新Self-E框架学会自我评估
今天
img
5分钟定制一个AI采购专家:讯飞发布“招采智能体工厂”,重新定义行业开发范式
今天
img
Agent时代,为什么多模态数据湖是必选项?
今天
img
大模型长脑子了?研究发现LLM中层会自发模拟人脑进化
今天
img
性能提升60%,英特尔Ultra3这次带来了巨大提升
01月14日
img
继宇树后,唯一获得三家大厂押注的自变量:具身模型不是把DeepSeek塞进机器人
01月14日
img
Sebastian Raschka 2026预测:Transformer统治依旧,但扩散模型正悄然崛起
01月14日
img
端到端智驾新SOTA | KnowVal:懂法律道德、有价值观的智能驾驶系统
01月14日
img
仅用10天?Anthropic最新智能体Cowork的代码竟然都是Claude写的
01月14日
img
AAAI 2026|AP2O-Coder 让大模型拥有「错题本」,像人类一样按题型高效刷题
01月14日
img
用AI从常规病理切片重建空间蛋白图谱:基于H&E图像的高维蛋白质表达预测
01月14日
img
京东首届AI影视创作大赛启动 最高奖金10万元邀全民共创AI视频
01月14日
img
合合信息多模态文本智能产品“上新”,覆盖AI教育、AI健康、AI Infra多元场景
01月14日
img
500万次围观,1X把「世界模型」真正用在了机器人NEO身上
01月14日
img
跳出「黑盒」,人大刘勇团队最新大语言模型理论与机理综述
01月14日
img
百川开源全球最强医疗大模型M3,「严肃问诊」定义AI医疗新能力
01月14日
img
相约AAAI 2026 | 上海AI实验室北极星 X 星启交流会(报名开启)
01月13日
img

人脸机器人登上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/HdnbBweZseTjMedyWHDLSg

2026 年 1 月 15 日,一项来自美国哥伦比亚大学工程学院的突破性研究正式发表于《Science Robotics》,并登上期刊封面。该研究展示了一项全新的机器人技术:一台具备仿生面部结构的人形机器人,通过深度学习实现与语音和歌曲同步的真实唇部运动。它能跟着人类的语言精准张合嘴唇,甚至,能跟着音乐唱歌。标志着人形机器人在人类最丰富的交流通道之一唇部表达上,迈出了突破性一步。

为什么 “嘴唇” 如此重要?

研究显示,在面对面的交流中,人类将近一半的注意力集中在唇部运动上。我们或许能容忍机器人走路笨拙、手部动作僵硬,但哪怕极其轻微的不自然面部表情,都会立刻引发本能的不适。这正是著名的 “恐怖谷”。

长期以来,即便是最先进的人形机器人,在 “说话” 时也只能做出类似木偶的张合动作 —— 如果它们有脸的话。但这一次,情况正在发生改变。

一个会自主学习表情的机器人

在这项研究中,研究团队打造了一张高度仿生的机器人面孔:

在一层柔性硅胶皮肤之下,隐藏着 20 余个微型电机,能够快速、安静且协同地驱动唇部形变。

图片

图 2. 机器人唇形硬件结构。(A)面部机器人设计概览,重点展示了人机交互关键组件:包括扬声器、麦克风、高清摄像模块,以及用于固定柔软硅胶面皮的磁吸式快拆连接器。该连接器能实现面皮的精准定位,并通过推拉双向运动驱动硅胶面皮,完成说话时所需的复杂唇部动作。(B)搭载柔软硅胶面皮的人形机器人外观展示。其底座内部集成有边缘计算设备。(C)唇部驱动系统特写,展示上唇、下唇与唇角连接器分别对应固定于相应唇部支架。柔软可替换的面皮通过磁吸连接器固定,可便捷拆卸以进行维护或个性化调整。

随后,机器人被 “带到镜子前”…

就像一个第一次对着镜子学做表情的孩子,机器人通过观察自己面部在不同电机驱动下的变化,构建 Facial Action Transformer (FAT) 模型,逐渐学会如何控制自己的脸(机器人自我建模 Robotic Self-modeling)。研究团队将这一过程称为一种 “视觉 — 动作” 的自监督学习

图片

图 3. 机器人能实现的口型及其对应音标展示。该机器人展示了再现关键英语音标的能力,例如爆破音(/p/ 和 /b/)、双唇音(/m/)以及圆唇元音(/u/ 和 /o/)。通过独立控制上唇、下唇及嘴角,每帧图像均捕捉到其实现的典型唇部运动效果。这些数据为机器人在说话时实现正确的唇形匹配奠定了基础。

依靠纯声音驱动嘴形动作

接着,机器人通过观看合成的机器人视频(通过 Wav2Lip)在不同语音语料(由 TTS 和 ChatGPT 生成)的真实唇部变化,进一步学习声音与唇部运动之间的对应关系。最终,这两种能力被整合在一起 —— 机器人得以将收到的声音信号,直接转化为连续、自然的唇部运动。无需理解语义,机器人已经能 “对得上口型”。

图片

图 4. 机器人唇形同步的自监督学习框架。 (A) 数据收集阶段:机器人通过与语音相关的随机指令自主生成数据集,利用 RGB 摄像头捕捉广泛的唇部运动,以获取 3D 唇形数据。(B) 部署过程:始于来自 ChatGPT 的文本输入,文本被转换为音频,随后利用 Wav2Lip 技术合成机器人视频。利用真实机器人视频及其对应指令,训练由编码器和解码器(VAE)组成的机器人逆向变换器,以生成平滑、准确、可供真实机器人执行的电机指令。

多语言能力

研究团队测试了机器人在多种语言、不同语音环境甚至歌曲中的表现。结果显示,即使在复杂的语音节奏下,机器人也能完成连贯的唇部同步,甚至演唱来自其 AI 生成的曲目。

      机器人多语言口型对齐能力

图片

图 5. 多语言唇语同步性能量化表现。x 轴标签下方标注的样本量 n 对应每种语言的测试句子视频帧数。结果表明,所有非英语语言的同步误差均保持在英语误差范围内,显示出稳健的跨语言泛化能力。

当然,这还不是终点。研究者坦言,像 “B” 这类需要完全闭唇的音,以及 “W” 这类涉及明显撮唇的发音,仍然存在挑战。但关键在于 —— 这是一种可以随着学习持续进化的能力,而不是写死的规则。

跨越恐怖谷的 “缺失环节”

在研究者看来,面部表情 —— 尤其是唇部的自然运动,正是长期以来机器人能力中的 “缺失环节”。“当前的人形机器人更多关注行走和抓取,但凡是需要与人面对面交流的场景,面部表达同样关键。”

随着人形机器人逐渐进入娱乐、教育、医疗、陪护等高度依赖情感沟通的领域,一张温暖、自然、可信的‘脸’将不再是加分项,而是入场券。经济学家预测,未来十年全球或将制造超过十亿台人形机器人进入人们的生活场景。而几乎可以确定的是 —— 它们不可能都没有脸。

从实验室走向现实

这项封面研究,不仅是一次学术突破,也展示了中国学者在国际人形机器人领域具备独特的创新能力。

第一作者胡宇航博士表示,当唇部同步能力与对话型大模型结合时,机器人与人类之间的连接将发生质变。“我们交流中有大量情感信息并不在语言本身,而在面部和身体语言中。机器人正在开始触碰这条通道。”

当机器人真正学会像人一样 “说话” 和 “表达”,

恐怖谷,正在被一步步填平。

人类与机器人的信任和情感,将会迎来新的篇章。

编者注

本文首发于 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)。从概念上讲,工具栏中的操作与通过菜单调用的操作是完全相同的,因此应该使用相同的图标。所以实现起来的方式也应该是最简单的:在同一个应用内、甚至通常同时出现在屏幕上的图标,保持一致能有多难呢?

那我们看看「预览」:

「照片」:同样的用了上述两种图标,但这次调换了一下顺序¯_(ツ)_/¯

「地图」和其他应用在「缩放」功能上的图标选用也常有差异:

图标复用

和完全不具备一致性类似的,另一个大忌是将同一个图标用于不同的操作。想象一下:我已经学会了下面这个图标代表「新建」:

并且我打开另一个应用也看到了它。「太棒了,」我想,「我知道这个图标是什么意思了」:

上当了吧!

你可能会想:好吧,下面这个图标代表「快速查看」:

有时候确实如此,但在另一些时候,这个图标的意思是「显示已完成项」:

有时候下面这个图标意味着「导入」:

但有时候它也代表着「更新」:

与上面提到的一致性问题类似,图标复用问题不仅发生在不同应用之间。有时你可以在工具栏看到这个图标:

然后在同一个应用的菜单里,发现同一个图标代表了别的东西:

有时完全相同的图标会在同一个菜单中相遇。

有时还会贴在一起。

有时它们甚至会将一整串相同的图标排成列:

这显然对谁都没帮助。如果所有图标都一样,用户很难快速定位到菜单项,也不会正确理解其背后所指代的功能。

目前为止图标复用最惨烈的案例是「照片」应用:

感觉那个负责为每个菜单项选择一个对应图标的人,可能头发都已经掉光了。

理解万岁。

细节要素过多

审视图标时,我们通常能包容它们在最终落地环节中的一些微小差异。例如下面这些理论上来说各不相同的路标,实际上都在帮助我们理解同一件事:

图标也是如此:如果你在一个地方画了一个飞出盒子的箭头,在另一个地方也画了同样的内容,但箭头的角度、描边的宽度,或者一个是实心的另一个不是,都不影响我们将这两个图标理解为同一个意思。

比如指望下面这个两个图标表达完全不同的两个意思是在想什么呢?得了吧!

两个仅仅在字号上有细微差别的字母 A:

铅笔代表「重命名」,但稍粗一点的铅笔就代表「高亮」?

方向不同的对角线箭头?

占据 2/3 空间的三个点 vs. 占据全部空间的三个点。认真的吗?

颜色更深的点?

一张因纸角是否折叠,或纸上是否有线条而改变含义的纸?

但「大 Boss」还得是箭头。下面这些箭头的意义各不相同:

按上面这张图的道理,用户必须专业到足以区分圆圈被挤压的程度、箭头从顶部向右还是底部向右出发,以及箭头末端各延伸了多长。

我在乎这些细节吗?说实话,不在乎。如果 Apple 能将这里的连续性一以贯之地应用到图标上,我或许会试试。但 Apple 指望我在一个地方区分「新建」的两种图标样式,同时又要我在另一个地方留意这种微小的细节?

抱歉,看完上面这一切之后,这已经是信任问题的范畴了。

细节过多

图标理应在一定距离外也易于识别。每个图标设计师都知道:太细即是禁忌。为了特定的美学追求偶尔可以包容,但你不能依赖细节。

Tahoe 菜单里的图标就可以说是太细了。它们中的大多数都容纳在 12×12 像素的正方形内(因为 Retina 屏幕的原因实际分辨率为 24×24),而且由于许多图标不是正方形,这些图标的某些尺寸往往小于 12 个像素。

这可没有多少发挥的空间!要知道 Windows 95 的图标甚至都是 16×16 的。如果我们按同时代最具代表性的每英寸 72 点的 DPI 来计算,我们能得到一个物理大小为 0.22 英寸(5.6 毫米)的图标——而在配备 254 DPI 屏幕的现代 MacBook Pro 上,Tahoe 的 24×24 图标换算下来为 0.09 英寸(2.4 毫米)。24 固然比 16 更大,但实际效果却是这些图标的面积变成了原来的四分之一!

模拟 72 DPI 下的 16×16(左)与 254 DPI 下的 24×24(右)的物理尺寸对比

所以当我看到下面这个菜单时:

我有些纠结了。我知道这些图标各不相同,但我很难分辨它们具体画的是什么。

即使放大 20 倍也依然是一团糟:

还有这三个不同的图标:

难道我应该在这里分清楚加号和星标吗?

有些线条比其他线条厚了半个像素,这竟然也是决定图标意义的关键:

这画的是箭头?

还是笔刷?

看,这里有个小照相机。

它甚至有一个更小的取景器,如果你放大 20 倍就几乎清晰可见了:

还有这里。一个方框,方框里有一个圆,圆里面还有小到只有 2 个像素高度的字母 i:

没看见?

我也没看见。但它确实有个 i……

还有下面这个居然是一个窗口!它甚至有「红绿灯」按钮!真是太可爱了:

请记住:这些都是 retina 像素,是真实像素的 1/4。乔布斯本人曾说过它们理应是不可见的。

It turns out there’s a magic number right around 300 pixels per inch, that when you hold something around to 10 to 12 inches away from your eyes, is the limit of the human retina to differentiate the pixels.

但 Tahoe 的图标却指望你能看清它们。

像素网格

当发挥空间有限时,每个像素都至关重要。审慎对待每一个像素,才能做出好的图标。

在 Tahoe 的图标这里,Apple 决定使用矢量字体来替代老式的位图(bitmaps)。这为 Apple 节省了资源——绘制一次,随处可用,并且还具备尺寸、显示分辨率和字宽上的灵活性。

但这样做是有代价的:字体很难在垂直方向上精确渲染,比如它们的尺寸无法直接与像素一一对应,描边宽度也无法与像素网格(pixel grid)形成 1 对 1 映射等。所以这些矢量字体虽然随处可用,但处处都模糊且平庸:

Tahoe 图标(左)及其像素对齐版本(右)

可用的像素越多,或图形越简单,它们的观感自然也会更好一点。

iPad OS 26 vs macOS 26

但「复杂的细节」和「微小的图标尺寸」是个致命的组合。在 Apple 发布 380+ DPI 的 MacBook 之前,我们仍然得在像素网格这件事情上多加留意。

令人困惑的隐喻

图标还可以有另一个功能:帮助用户理解命令的含义。

例如,在知晓特定使用上下文(移动窗口)的前提下,这些图标比文字更能快达意:

但这些图标发挥作用的前提是,用户必须理解图标上画的是什么。它必须是用户熟知对象和计算机操作之间的清晰转化(如垃圾桶 → 删除),是被广泛使用的符号、易于理解的图示。《人机交互指南》(HIG)指出:

比如最低级的错误是对对象的错误呈现。例如这是选中操作实际看起来的样子:

但选中操作的图标长这样:

老实说,我这篇随笔前前后后写了一个星期,但我至今完全不理解它为什么长这样。无边记/预览应用中有一个类似的对象,但它代表的一个文本框:

它在 SF Symbols 中也被叫做 character.textbox

那为什么它变成了「全选」的隐喻?我猜这可能是一个失误。

另一个地方则在 Mac 上使用了 iOS 的文本选择样式作为隐喻!

有些概念对应显而易见或约定俗成的隐喻。在这种情况下,不使用它们也是一种错误。例如书签:

Apple 出于某些原因选择了一本书:

有时你也有现成的界面元素可以用于图标,但这种做法也容易给用户造成混淆。比如长方形里的点看起来像输入密码而不是权限编辑:

再比如这里的图标显示的是「勾选」,但实际动作却对应「取消勾选」。

这是糟糕的情况:图标不仅没有提供帮助,反而主动误导了用户。

构建一个对象加上某种指示符的双层级图标也很诱人,比如一个复选框加一个叉号,意思理应是「删除复选框」:

或者一个用户加一个复选标记,意思理应「选择用户」:

所以不幸的是这类图标构造很少真的有效。用户不会根据你提供的积木来造句,他们根本没有兴趣去解这些谜。

寻找隐喻(metaphors)很难,相对来说名词比动词隐喻更好找,但菜单项大多是动词。「打开」这个操作看起来像什么?为什么会像一个指向右上角的箭头?

我并不是说 Apple 搞错一个显而易见的「打开」的隐喻,事实上确实没有这种隐喻。但这其实也是关键:如果你找不到好的隐喻,不使用图标比使用一个糟糕的、令人困惑或违背直觉的图标要好。

我喜欢通过一个游戏来测试隐喻的质量。即去掉标签,试着猜测含义。不信你试试:

只要够努力就能给每个操作找到一个完美对应的图标,这事儿纯属痴心妄想。这是一场从一开始就注定失败的战斗,再多的资金或「管理层决策」都无法改变这一点。这当中的问题百分之百也都是自找的。

话虽如此,我还是要在该表扬的地方表扬 Apple。他们选得好的那些隐喻,确实是非常直观:

成对操作

在所有令人困惑的隐喻中,有一个场景尤为特别:为那些功能完全相反的成对操作选择隐喻。比如撤销/重做、打开/关闭、左/右。

如果这些图标使用相同的隐喻,那效果是极好的:

因为这能节省你的时间和认知资源。学会一个,就能举一反三。

正因如此,为相互关联的成对操作使用不同的隐喻也是一个常见错误:

或者这里:

另一个错误是在没有成对操作的地方制造关联。比如「返回」和「查看全部」?

Tahoe 中有些菜单同时存在这两个错误。例如「显示/隐藏」缺少成对操作的关联性,而「已完成/子任务」之间却有:

「导入」与「共享」互为成对操作,而不是「导出」:

图标中的文字

再次引用 HIG:

HIG 的作者反对将文字作为图标的一部分。所以像这样的:

或者这样的:

至少在 1992 年是行不通的。

我表示同意,但 Tahoe 有更严重的问题:完全由文字组成的图标。比如这个:

很难分清「不应被字面阅读的、抽象的隐喻式图标文字」在哪里结束,而真正的文本又从哪里开始。图标和菜单操作文本在这里使用相同的字体、相同的颜色,那我该如何区分它们呢?图标在这里反而成了障碍:A...完成?Aa 字体?这些操作到底是什么意思?

我也许能理解下面这两个图标:

里面的点应该代表着什么,由此推导出下面这个图标的思维过程也可以理解:

但是这个图标呢?

没有任何装饰、没有任何效果,就是纯文本的 Abc,认真的吗?

文本转换

有人可能会认为使用图标来演示文本转换是个好主意。

比如当你看到这个:

或者这个:

或者这个:

仅凭图标就能理解文本会发生什么变化,图标即操作。

另外 BIU 对应的操作(加粗、斜体、下划线)在文本处理领域已有共识,那这样做似乎没有缺点?

不完全是。问题还是一样——文字图标看起来像文字而不是图标。此外,这些图标也是多余的,取第一个字母并重复一遍有什么意义?「Bold」(加粗)这个词本身就是以字母「B」开头的,读起来也不拗口,为什么要出现两次?当你再看它时:

它甚至作为快捷键提示又被重复了一次……

这个菜单其实有一个更好的设计方案:

而且 Apple 至少在 33 年前就知道了。

图标中的系统元素

操作系统当然会为了自己的目的使用一些视觉元素。比如窗口控件、大小调整手柄、光标、快捷方式等。在图标中使用这些元素也是错误的。

不幸的是,Apple 也掉进了这个陷阱。他们重复使用了箭头。

快捷键符号:

HIG 甚至有一个专门针对省略号(ellipsis)的章节,说明在菜单以外的其他地方使用是多么的危险。

而这正是 Tahoe 所面临的问题。

图标打断了阅读

如果没有图标,你可以直接从上到下扫视菜单,只读头几个字母。因为它们都是对齐的:

macOS Sequoia

但在 Tahoe 中,有些菜单项有图标、有些没有,所以它们的对齐方式也不一样了:

有些项目可能既有复选标记又有图标,或者只有其中一个,或者两个都没有,于是我们就遇到了这样的情况:

麻了。

特别提名

这个菜单值得单独拿出来说一说:

不同的动作使用相同的图标、没有显而易见的隐喻、不知为何让第一个图标比第二和第三个稍小一点。恭喜!它集齐了所有缺点。

HIG 还有参考价值吗?

我多次提到 HIG,你可能会想:一份 1992 年的界面手册在今天还有参考价值吗?计算机经历了巨变,我们不也该套用一份新的原则、设计和规范吗?

是,也不是。比如如何让图标适应黑白显示器的建议已经过时了。但设计规则——只要是好的规则——在今天依然适用,因为它们是基于人、而不是计算机的运作方式才提出来的。

人类不会每年发布一个新版本,我们的记忆力不会翻倍,我们的视力也不会变得更敏锐。注意力的运作方式一如既往。视觉识别、运动技能——这一切都和 1992 年一模一样。

所以没错,在我们直接与脑机接口相连之前,HIG 将永远具有参考价值。

结语

在我看来,Apple 选择了一项不可能完成的任务:为每个菜单项添加一个对应图标。而事实上根本没有足够多合理的隐喻来支撑这样的做法。

即便是有,这项任务的前提本身也值得商榷:所有东西都有图标,并不意味着用户能更快地找到他们想要的东西。

即便前提成立,我仍然希望我能说:考虑到目标宏伟,他们已经尽力了。但这也不是事实:他们在一致性地应用隐喻以及图标本身的设计方面,做得实在很糟糕。

Apple 成功地在一个操作系统版本中集齐了图标设计中的常见错误,而我希望这篇文章能帮助大家避免它们。我热爱计算机、热爱界面设计、热爱视觉交互。看到 30 年前就已经人人可用的好设计共识在今天被完全忽视或抛弃,让我感到很难过。

往好的方面想:拥有比 Apple 更好设计已经没那么难了!让我们为此干杯。新年快乐!

来自 SF Symbols:一个正在打电话的笑脸

注释

在审阅本文时,有人向我推荐了 Jim Nielsen 的文章,他的观点与我不谋而合。我认为这是我们的推论背后存在某种共同真理的迹象。

另外请注意:Safari 的「文件」菜单自 26.0 以来变得更糟了,以前它只有 4 个图标,现在有 18 个!

感谢 Kevin、Ryan 和 Nicki 阅读本文的草稿。

更新:鸣谢

> 关注 少数派公众号,解锁全新阅读体验 📰

> 实用、好用的 正版软件,少数派为你呈现 🚀

    编者注

    本文首发于 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)。从概念上讲,工具栏中的操作与通过菜单调用的操作是完全相同的,因此应该使用相同的图标。所以实现起来的方式也应该是最简单的:在同一个应用内、甚至通常同时出现在屏幕上的图标,保持一致能有多难呢?

    那我们看看「预览」:

    「照片」:同样的用了上述两种图标,但这次调换了一下顺序¯_(ツ)_/¯

    「地图」和其他应用在「缩放」功能上的图标选用也常有差异:

    图标复用

    和完全不具备一致性类似的,另一个大忌是将同一个图标用于不同的操作。想象一下:我已经学会了下面这个图标代表「新建」:

    并且我打开另一个应用也看到了它。「太棒了,」我想,「我知道这个图标是什么意思了」:

    上当了吧!

    你可能会想:好吧,下面这个图标代表「快速查看」:

    有时候确实如此,但在另一些时候,这个图标的意思是「显示已完成项」:

    有时候下面这个图标意味着「导入」:

    但有时候它也代表着「更新」:

    与上面提到的一致性问题类似,图标复用问题不仅发生在不同应用之间。有时你可以在工具栏看到这个图标:

    然后在同一个应用的菜单里,发现同一个图标代表了别的东西:

    有时完全相同的图标会在同一个菜单中相遇。

    有时还会贴在一起。

    有时它们甚至会将一整串相同的图标排成列:

    这显然对谁都没帮助。如果所有图标都一样,用户很难快速定位到菜单项,也不会正确理解其背后所指代的功能。

    目前为止图标复用最惨烈的案例是「照片」应用:

    感觉那个负责为每个菜单项选择一个对应图标的人,可能头发都已经掉光了。

    理解万岁。

    细节要素过多

    审视图标时,我们通常能包容它们在最终落地环节中的一些微小差异。例如下面这些理论上来说各不相同的路标,实际上都在帮助我们理解同一件事:

    图标也是如此:如果你在一个地方画了一个飞出盒子的箭头,在另一个地方也画了同样的内容,但箭头的角度、描边的宽度,或者一个是实心的另一个不是,都不影响我们将这两个图标理解为同一个意思。

    比如指望下面这个两个图标表达完全不同的两个意思是在想什么呢?得了吧!

    两个仅仅在字号上有细微差别的字母 A:

    铅笔代表「重命名」,但稍粗一点的铅笔就代表「高亮」?

    方向不同的对角线箭头?

    占据 2/3 空间的三个点 vs. 占据全部空间的三个点。认真的吗?

    颜色更深的点?

    一张因纸角是否折叠,或纸上是否有线条而改变含义的纸?

    但「大 Boss」还得是箭头。下面这些箭头的意义各不相同:

    按上面这张图的道理,用户必须专业到足以区分圆圈被挤压的程度、箭头从顶部向右还是底部向右出发,以及箭头末端各延伸了多长。

    我在乎这些细节吗?说实话,不在乎。如果 Apple 能将这里的连续性一以贯之地应用到图标上,我或许会试试。但 Apple 指望我在一个地方区分「新建」的两种图标样式,同时又要我在另一个地方留意这种微小的细节?

    抱歉,看完上面这一切之后,这已经是信任问题的范畴了。

    细节过多

    图标理应在一定距离外也易于识别。每个图标设计师都知道:太细即是禁忌。为了特定的美学追求偶尔可以包容,但你不能依赖细节。

    Tahoe 菜单里的图标就可以说是太细了。它们中的大多数都容纳在 12×12 像素的正方形内(因为 Retina 屏幕的原因实际分辨率为 24×24),而且由于许多图标不是正方形,这些图标的某些尺寸往往小于 12 个像素。

    这可没有多少发挥的空间!要知道 Windows 95 的图标甚至都是 16×16 的。如果我们按同时代最具代表性的每英寸 72 点的 DPI 来计算,我们能得到一个物理大小为 0.22 英寸(5.6 毫米)的图标——而在配备 254 DPI 屏幕的现代 MacBook Pro 上,Tahoe 的 24×24 图标换算下来为 0.09 英寸(2.4 毫米)。24 固然比 16 更大,但实际效果却是这些图标的面积变成了原来的四分之一!

    模拟 72 DPI 下的 16×16(左)与 254 DPI 下的 24×24(右)的物理尺寸对比

    所以当我看到下面这个菜单时:

    我有些纠结了。我知道这些图标各不相同,但我很难分辨它们具体画的是什么。

    即使放大 20 倍也依然是一团糟:

    还有这三个不同的图标:

    难道我应该在这里分清楚加号和星标吗?

    有些线条比其他线条厚了半个像素,这竟然也是决定图标意义的关键:

    这画的是箭头?

    还是笔刷?

    看,这里有个小照相机。

    它甚至有一个更小的取景器,如果你放大 20 倍就几乎清晰可见了:

    还有这里。一个方框,方框里有一个圆,圆里面还有小到只有 2 个像素高度的字母 i:

    没看见?

    我也没看见。但它确实有个 i……

    还有下面这个居然是一个窗口!它甚至有「红绿灯」按钮!真是太可爱了:

    请记住:这些都是 retina 像素,是真实像素的 1/4。乔布斯本人曾说过它们理应是不可见的。

    It turns out there’s a magic number right around 300 pixels per inch, that when you hold something around to 10 to 12 inches away from your eyes, is the limit of the human retina to differentiate the pixels.

    但 Tahoe 的图标却指望你能看清它们。

    像素网格

    当发挥空间有限时,每个像素都至关重要。审慎对待每一个像素,才能做出好的图标。

    在 Tahoe 的图标这里,Apple 决定使用矢量字体来替代老式的位图(bitmaps)。这为 Apple 节省了资源——绘制一次,随处可用,并且还具备尺寸、显示分辨率和字宽上的灵活性。

    但这样做是有代价的:字体很难在垂直方向上精确渲染,比如它们的尺寸无法直接与像素一一对应,描边宽度也无法与像素网格(pixel grid)形成 1 对 1 映射等。所以这些矢量字体虽然随处可用,但处处都模糊且平庸:

    Tahoe 图标(左)及其像素对齐版本(右)

    可用的像素越多,或图形越简单,它们的观感自然也会更好一点。

    iPad OS 26 vs macOS 26

    但「复杂的细节」和「微小的图标尺寸」是个致命的组合。在 Apple 发布 380+ DPI 的 MacBook 之前,我们仍然得在像素网格这件事情上多加留意。

    令人困惑的隐喻

    图标还可以有另一个功能:帮助用户理解命令的含义。

    例如,在知晓特定使用上下文(移动窗口)的前提下,这些图标比文字更能快达意:

    但这些图标发挥作用的前提是,用户必须理解图标上画的是什么。它必须是用户熟知对象和计算机操作之间的清晰转化(如垃圾桶 → 删除),是被广泛使用的符号、易于理解的图示。《人机交互指南》(HIG)指出:

    比如最低级的错误是对对象的错误呈现。例如这是选中操作实际看起来的样子:

    但选中操作的图标长这样:

    老实说,我这篇随笔前前后后写了一个星期,但我至今完全不理解它为什么长这样。无边记/预览应用中有一个类似的对象,但它代表的一个文本框:

    它在 SF Symbols 中也被叫做 character.textbox

    那为什么它变成了「全选」的隐喻?我猜这可能是一个失误。

    另一个地方则在 Mac 上使用了 iOS 的文本选择样式作为隐喻!

    有些概念对应显而易见或约定俗成的隐喻。在这种情况下,不使用它们也是一种错误。例如书签:

    Apple 出于某些原因选择了一本书:

    有时你也有现成的界面元素可以用于图标,但这种做法也容易给用户造成混淆。比如长方形里的点看起来像输入密码而不是权限编辑:

    再比如这里的图标显示的是「勾选」,但实际动作却对应「取消勾选」。

    这是糟糕的情况:图标不仅没有提供帮助,反而主动误导了用户。

    构建一个对象加上某种指示符的双层级图标也很诱人,比如一个复选框加一个叉号,意思理应是「删除复选框」:

    或者一个用户加一个复选标记,意思理应「选择用户」:

    所以不幸的是这类图标构造很少真的有效。用户不会根据你提供的积木来造句,他们根本没有兴趣去解这些谜。

    寻找隐喻(metaphors)很难,相对来说名词比动词隐喻更好找,但菜单项大多是动词。「打开」这个操作看起来像什么?为什么会像一个指向右上角的箭头?

    我并不是说 Apple 搞错一个显而易见的「打开」的隐喻,事实上确实没有这种隐喻。但这其实也是关键:如果你找不到好的隐喻,不使用图标比使用一个糟糕的、令人困惑或违背直觉的图标要好。

    我喜欢通过一个游戏来测试隐喻的质量。即去掉标签,试着猜测含义。不信你试试:

    只要够努力就能给每个操作找到一个完美对应的图标,这事儿纯属痴心妄想。这是一场从一开始就注定失败的战斗,再多的资金或「管理层决策」都无法改变这一点。这当中的问题百分之百也都是自找的。

    话虽如此,我还是要在该表扬的地方表扬 Apple。他们选得好的那些隐喻,确实是非常直观:

    成对操作

    在所有令人困惑的隐喻中,有一个场景尤为特别:为那些功能完全相反的成对操作选择隐喻。比如撤销/重做、打开/关闭、左/右。

    如果这些图标使用相同的隐喻,那效果是极好的:

    因为这能节省你的时间和认知资源。学会一个,就能举一反三。

    正因如此,为相互关联的成对操作使用不同的隐喻也是一个常见错误:

    或者这里:

    另一个错误是在没有成对操作的地方制造关联。比如「返回」和「查看全部」?

    Tahoe 中有些菜单同时存在这两个错误。例如「显示/隐藏」缺少成对操作的关联性,而「已完成/子任务」之间却有:

    「导入」与「共享」互为成对操作,而不是「导出」:

    图标中的文字

    再次引用 HIG:

    HIG 的作者反对将文字作为图标的一部分。所以像这样的:

    或者这样的:

    至少在 1992 年是行不通的。

    我表示同意,但 Tahoe 有更严重的问题:完全由文字组成的图标。比如这个:

    很难分清「不应被字面阅读的、抽象的隐喻式图标文字」在哪里结束,而真正的文本又从哪里开始。图标和菜单操作文本在这里使用相同的字体、相同的颜色,那我该如何区分它们呢?图标在这里反而成了障碍:A...完成?Aa 字体?这些操作到底是什么意思?

    我也许能理解下面这两个图标:

    里面的点应该代表着什么,由此推导出下面这个图标的思维过程也可以理解:

    但是这个图标呢?

    没有任何装饰、没有任何效果,就是纯文本的 Abc,认真的吗?

    文本转换

    有人可能会认为使用图标来演示文本转换是个好主意。

    比如当你看到这个:

    或者这个:

    或者这个:

    仅凭图标就能理解文本会发生什么变化,图标即操作。

    另外 BIU 对应的操作(加粗、斜体、下划线)在文本处理领域已有共识,那这样做似乎没有缺点?

    不完全是。问题还是一样——文字图标看起来像文字而不是图标。此外,这些图标也是多余的,取第一个字母并重复一遍有什么意义?「Bold」(加粗)这个词本身就是以字母「B」开头的,读起来也不拗口,为什么要出现两次?当你再看它时:

    它甚至作为快捷键提示又被重复了一次……

    这个菜单其实有一个更好的设计方案:

    而且 Apple 至少在 33 年前就知道了。

    图标中的系统元素

    操作系统当然会为了自己的目的使用一些视觉元素。比如窗口控件、大小调整手柄、光标、快捷方式等。在图标中使用这些元素也是错误的。

    不幸的是,Apple 也掉进了这个陷阱。他们重复使用了箭头。

    快捷键符号:

    HIG 甚至有一个专门针对省略号(ellipsis)的章节,说明在菜单以外的其他地方使用是多么的危险。

    而这正是 Tahoe 所面临的问题。

    图标打断了阅读

    如果没有图标,你可以直接从上到下扫视菜单,只读头几个字母。因为它们都是对齐的:

    macOS Sequoia

    但在 Tahoe 中,有些菜单项有图标、有些没有,所以它们的对齐方式也不一样了:

    有些项目可能既有复选标记又有图标,或者只有其中一个,或者两个都没有,于是我们就遇到了这样的情况:

    麻了。

    特别提名

    这个菜单值得单独拿出来说一说:

    不同的动作使用相同的图标、没有显而易见的隐喻、不知为何让第一个图标比第二和第三个稍小一点。恭喜!它集齐了所有缺点。

    HIG 还有参考价值吗?

    我多次提到 HIG,你可能会想:一份 1992 年的界面手册在今天还有参考价值吗?计算机经历了巨变,我们不也该套用一份新的原则、设计和规范吗?

    是,也不是。比如如何让图标适应黑白显示器的建议已经过时了。但设计规则——只要是好的规则——在今天依然适用,因为它们是基于人、而不是计算机的运作方式才提出来的。

    人类不会每年发布一个新版本,我们的记忆力不会翻倍,我们的视力也不会变得更敏锐。注意力的运作方式一如既往。视觉识别、运动技能——这一切都和 1992 年一模一样。

    所以没错,在我们直接与脑机接口相连之前,HIG 将永远具有参考价值。

    结语

    在我看来,Apple 选择了一项不可能完成的任务:为每个菜单项添加一个对应图标。而事实上根本没有足够多合理的隐喻来支撑这样的做法。

    即便是有,这项任务的前提本身也值得商榷:所有东西都有图标,并不意味着用户能更快地找到他们想要的东西。

    即便前提成立,我仍然希望我能说:考虑到目标宏伟,他们已经尽力了。但这也不是事实:他们在一致性地应用隐喻以及图标本身的设计方面,做得实在很糟糕。

    Apple 成功地在一个操作系统版本中集齐了图标设计中的常见错误,而我希望这篇文章能帮助大家避免它们。我热爱计算机、热爱界面设计、热爱视觉交互。看到 30 年前就已经人人可用的好设计共识在今天被完全忽视或抛弃,让我感到很难过。

    往好的方面想:拥有比 Apple 更好设计已经没那么难了!让我们为此干杯。新年快乐!

    来自 SF Symbols:一个正在打电话的笑脸

    注释

    在审阅本文时,有人向我推荐了 Jim Nielsen 的文章,他的观点与我不谋而合。我认为这是我们的推论背后存在某种共同真理的迹象。

    另外请注意:Safari 的「文件」菜单自 26.0 以来变得更糟了,以前它只有 4 个图标,现在有 18 个!

    感谢 Kevin、Ryan 和 Nicki 阅读本文的草稿。

    更新:鸣谢

    > 关注 少数派公众号,解锁全新阅读体验 📰

    > 实用、好用的 正版软件,少数派为你呈现 🚀