从人机交互到表达意图:当软件退居幕后

1. 跨越鸿沟

最近在读杰弗里·摩尔的《跨越鸿沟》。书中有一张著名的钟形曲线图，描述新技术进入市场的过程，并将技术采用者从左到右分成五类：创新者、早期采用者、早期大众、后期大众和落后者。

最左边的创新者只占约2.5%。他们喜欢技术本身，愿意尝试不成熟的产品，即使遇到问题，也乐于自己研究解决。接下来约13.5%的早期采用者，更关注新技术可能带来的突破性价值。他们未必喜欢折腾技术，但愿意为了率先获得某种优势而承担风险。接下来是早期大众和后期大众，各占约34%。早期大众希望看到可靠的产品、成熟的使用经验，以及能够真正解决现实问题的完整方案。后期大众则更倾向于等待技术普及、价格降低和使用门槛下降。最后约16%的落后者，通常会尽可能维持自己熟悉的方式。

摩尔把早期采用者与早期大众之间难以跨越的市场断层称为“鸿沟”。前一群人愿意接受的复杂性，到了后一群人那里，可能恰恰成为拒绝使用的理由。一种技术能够让早期采用者兴奋，不等于它已经准备好进入大众市场。上世纪90年代的Palm就是一个有意思的例子。

1996年，Palm推出Pilot掌上电脑。那时距离第一代iPhone问世还有十一年，人们已经能够把通讯录、日程、备忘录装进一个口袋大小的设备，使用触控笔操作，并与电脑同步数据。Palm曾经流行一时，成为商务精英掌中的常见工具。后来公司还推出了结合移动电话功能的Treo，也大受欢迎。然而，那个时代的掌上设备仍然要求用户适应触控笔、专门的输入方式以及一套不太直观的使用流程。尽管取得过商业成功，Palm始终没有像后来的智能手机那样，成为普通人普遍使用的日常工具。随着iPhone及其应用生态逐步成熟，智能手机才真正成为更广泛人群每天依赖的工具。Palm则逐渐淡出市场，如今已经很少有人听说过这个曾经知名的品牌。

率先实现一种技术、最早做出成功产品，并不意味着能够最终主导这项技术在大众市场的普及。最近使用内置AI Agent的操作系统Omarchy的时候，我又想起了这张图。按照我们过去对操作系统的认识，这类产品似乎天然只适合技术爱好者。但实际使用之后，我却发现了一种与传统认识截然不同的体验。

2. Omarchy的反转：从复杂到易用

很多人都知道Linux，但真正愿意把它当作日常桌面系统的人并不多。这倒不是因为Linux缺乏什么功能。它拥有成熟的工具、丰富的开源软件和高度可配置的系统环境。问题在于使用这些能力的方式，与普通人熟悉的操作习惯差别很大。

在Windows或macOS上，一个人遇到问题可以尝试打开设置界面，寻找相关选项。但在许多Linux桌面环境中，同样一件事可能需要了解软件包、系统服务、配置文件和命令行。网上虽然有大量教程，却未必适用于自己的发行版和桌面环境。照着执行几条命令之后，如果问题仍然没有解决，接下来往往比开始时更令人头疼。

我以前也尝试过Ubuntu这样的Linux桌面发行版。虽然它也有图形界面，但我感觉自己大部分时间花在配置工具、解决问题上。最近我开始使用基于Arch Linux生态的Omarchy。它强调键盘操作、终端和高度可配置的系统工具。按照传统的易用性标准，这显然不是什么面向普通人的友好设计。许多原本通过图形界面完成的工作，在这里可能需要使用命令和配置文件。例如安装中文输入法，或者解决系统休眠后无法正常恢复的问题。

这两件事听起来都不复杂。一个是让电脑能够输入中文，另一个是让电脑在休眠之后正常恢复。但在Linux环境中，它们可能牵涉输入法框架、桌面会话、系统服务、驱动程序和各种配置。过去遇到这些问题，我通常需要先搜索资料，再判断应该修改什么。出现错误后，还得继续查看日志，尝试不同的解决方案。真正费时间的不是输入几条命令，而是弄清楚这些命令为什么要执行，以及下一步应该怎么办。现在，这些工作可以交给系统中集成的Coding Agent。我只需要告诉它遇到了什么问题，它就可以检查系统环境、寻找相关工具、阅读技术文档、执行命令，再根据执行结果继续排查。我不再需要为了一个具体问题，先把背后的系统组件逐个研究一遍。

过去，我们判断一套操作系统是否容易使用，主要看它的界面是否直观、软件是否容易安装、各种功能是否方便找到。这些都是传统人机交互设计关注的重要问题。按照这些标准，Omarchy很难比成熟的消费级操作系统更友好。可是当Agent开始承担大量操作工作，软件是否容易使用，可能就不再主要取决于人能否直接操作它：我不必知道某个设置藏在哪个菜单里，也不必记住每条命令的参数。许多原本操作复杂、对普通用户不太友好的系统工具，如今却因为能够被Agent直接调用，反而成为一种优势。

软件本身没有变得更简单，但我使用它的方式却发生了根本变化。这也让我开始思考一个以前没有认真考虑过的问题：如果软件的主要操作者不再是人，那么究竟怎样设计软件，才算容易使用？

3. Agent如何改变人与软件的关系

如果问普通人最不愿意使用哪一种计算机操作界面，命令行终端恐怕会排在前列。面对一个黑乎乎的窗口，用户需要自己输入命令，却不知道有哪些功能，也不知道参数应该怎样填写。拼错一个字符，或者进入了错误的目录，就可能得到一串天书般的报错信息。从图形界面普及以来，软件行业花了几十年努力让普通用户远离命令行。菜单、按钮、图标、对话框，以及后来越来越完善的触屏交互，都让人们不再需要记忆复杂的操作指令。

有意思的是，对人类用户不太友好的命令行，却非常适合Agent。因为很多命令行工具都支持一个简单的帮助参数：--help。在命令后加上这个参数，程序通常就会列出支持的操作、可用参数和基本使用方法。对普通用户来说，这仍然是一段枯燥的技术说明。但对于能够阅读文本、调用工具并分析执行结果的Agent来说，它足以成为认识一个陌生程序的起点。

类似的方式也在向更多软件扩展。过去，开发者通过API让程序调用其他软件的功能。如今，面向AI应用的MCP则提供了一套标准化机制，让兼容的Agent能够发现可用工具、了解其功能并进行调用。MCP和命令行虽然采用不同的方式，却都让软件能力可以绕过面向人类的图形界面，直接被其他系统调用。

对人类使用者来说，界面是否直观、操作是否方便十分重要。但对于Agent来说，功能是否清晰、接口是否容易调用、执行结果是否能够检查，远比界面是否漂亮、按钮摆放是否合理更重要。

过去，用户必须适应软件；现在，Agent开始替用户适应软件。Agent还不只是替用户完成一连串点击。它可以根据需要选择不同工具，把原本互不相关的软件组合起来。必要时甚至可以修改或生成程序，让软件反过来适应具体需求。

现在，当我想解决某个问题时，为什么一定要先找到一款完整的软件，学习它的使用方法，再按照它提供的流程操作？也许我真正需要的并不是某款软件，而只是其中某项功能。这种区别在使用专业软件时尤其明显，比如三维建模。

4. 从完整产品里挑选具体能力

现在3D打印机越来越容易买到，也越来越容易使用。把准备好的打印文件存入存储卡，选择文件后就可以开始打印。不过，大部分人仍然只会从网上下载别人制作的模型。要自己设计一个可以打印的零件，对很多人来说仍然很困难。比如，家里某个塑料零件坏了，你想自己打印一个替代品，就需要先准确测量尺寸，再使用三维设计软件画出相应的结构，还要考虑厚度、孔位和打印公差。

对于熟悉CAD的人，这是一件很普通的事情。但对大部分人来说，学习一套三维建模软件，比打印那个零件困难得多。比如Blender、FreeCAD这样的软件拥有相当丰富的专业功能，但学习门槛也很高。对于只想偶尔打印一个小零件的人，实在没有多少理由为了这一次需求，先投入大量时间学习复杂的建模操作。但现在已经出现了另一种方式。

一些开源项目正在通过MCP等接口，让Agent直接操作Blender、FreeCAD或OpenSCAD。用户可以用自然语言描述想要的模型，Agent则通过软件接口创建和修改三维对象，调用建模功能，甚至生成可供进一步检查和导出的模型文件。原本需要用户花时间学习才能完成的建模操作，如今已经可以在一定程度上交给Agent。

过去，一个人想使用专业软件的能力，就必须先掌握专业软件。软件功能越强大，通常意味着越多的菜单、参数和操作流程，以及更陡的学习曲线。软件公司一方面不断增加专业功能，另一方面又不得不花大量精力让用户理解这些功能。Agent则可能让专业功能的开发与用户对这些功能的学习逐渐分离。

类似的变化也可能发生在Photoshop这样的专业图像处理软件上。一个人偶尔需要去除照片里的物体，或者调整一张图片，不一定有必要为此学习完整的图像处理流程。对于这些任务，用户可能只需要表达要求，再由Agent调用适当的处理能力。

从普通用户的角度看，过去那些必须经过专门学习才能使用的专业软件，现在未必还需要亲自掌握。专业软件长期积累的算法、工程经验和功能，用户如今不一定要通过原有的操作界面才能使用。AI正在让大量早已存在、却难以被普通人直接使用的专业能力，发挥出更多价值。

这种变化还可能影响软件的交易方式。专业用户仍然需要完整的设计、建模和图像处理环境，因此可能会继续购买或订阅专业软件。但对于偶尔使用某项功能的普通用户，按调用次数、按任务或者按交付结果付费，也可能逐渐成为另一种选择。过去，人们往往购买包含大量功能的完整软件；未来人们可能越来越多地为完成具体任务所需要的能力付费。

到这里，我们讨论的仍然是已经存在的软件。Agent负责寻找和调用功能，背后依靠的还是专业开发者长期积累的工具。但如果我需要的功能根本不存在呢？

5. 先有鸡，还是先有蛋？

调用已有的软件功能是一回事，为一个从未被满足的需求创造新功能，则是另一回事。过去的软件行业，通常是先开发产品，再寻找用户。一个团队发现某类需求，判断市场足够大，于是投入时间开发软件，再通过销售、订阅或者其他方式收回成本。即使是免费开源软件，也需要有人愿意承担开发和维护工作。这样的生产方式，自然更倾向于满足具有一定规模的需求。

如果一个问题只困扰几十个人，甚至只有某个人自己会遇到，开发一款软件就可能不划算。有些需求并不是技术上无法实现，而是实现这些需求的成本远远超过了它们本身的价值。比如，一个人需要把一批格式混乱的文件整理成特定结构，再从中提取一些信息。这样的工作可能只做一次，要求又和现成软件的功能不完全相同。过去大概很少有人愿意为了这件事专门开发程序。现在Agent的编程能力正在大幅降低满足这种需求的成本。

随着AI编程工具越来越普及，由个人和小群体开发的软件可能会越来越多。一个人可能只是为了解决自己的问题而开发一个小工具，如果其他人也觉得有用，就可能把它分享出去。随着使用者增加，原本的小程序也许会逐渐发展成长期维护的产品。还有一些程序，可能从一开始就没有长期存在的必要。它们在某个任务出现时被生成，完成工作之后便不再使用。

过去软件通常先被开发出来再寻找用户；未来可能先有具体需求，然后才由Agent生成相应的软件。如果这种方式逐步成熟，软件的生产规模、存在周期以及交付方式，都可能与今天很不一样。

不过，这种变化究竟能走多远，还取决于一个容易被早期采用者忽略的问题：让Agent能够生成程序，与让普通人愿意使用这些程序是两回事。两者之间仍然存在一道很深的鸿沟。

6. 当软件消失在视野之外

回到《跨越鸿沟》。在Omarchy上，我已经体会到Agent能够替我承担很多复杂工作。对于愿意尝试新工具、也有能力判断执行结果的人来说，这种变化已经很有价值。但普通用户未必愿意接受同样的使用方式。

他们不想知道什么是终端，不想记住任何快捷键，也没有兴趣研究Agent究竟调用了什么工具。这些解决问题的方式之所以让我感到兴奋，是因为我知道完成同样的任务过去有多困难。但对于普通人来说，提出需求之后，任务能够顺利完成，本来就应该是理所当然的事情。他们并不会因为后台运行了几十条命令而觉得这项技术更有价值。真正的挑战，是让Agent能够稳定、可靠地完成任务。

Agent需要正确理解用户的需求，知道应该使用什么工具，能够发现并处理执行过程中的错误。在涉及重要文件、资金或系统设置时，Agent还必须能够判断哪些操作需要用户确认，而不是一味追求自动化。还有，Agent使用成本也不能高到让人宁愿回到原来的操作方式。只有这些条件逐渐成熟，我们才有理由认为Agent开始从技术爱好者的工具，进入更广泛的日常生活。

我把这种未来称为软件的无人驾驶时代。它与汽车自动驾驶有一个相似之处：用户最终关心的不是系统内部采用了多少复杂技术，而是能否安全可靠地抵达目的地。

真正的软件无人驾驶，是用户不再需要关心使用了什么软件、调用了哪个Agent，只需提出需求，就能可靠地获得结果。到了这个阶段，软件不会消失。操作系统仍然需要管理计算机，专业软件仍然由开发者维护，各种工具也仍然承担不同的工作。只是对于普通人来说，这些东西可能逐渐退到后台。

回过头看Omarchy，它给我最大的启发其实不是Linux能否变得容易使用，而是我们可能仍然在用过去的标准衡量AI时代软件的易用性。过去，我们关心一款软件有没有直观的界面，学习成本有多高。我们甚至有一个专门研究人与计算机如何交互的领域，叫作HCI（人机交互）。未来软件本身可能会变得更加复杂，但人们使用计算机的方式反而会越来越简单。

《跨越鸿沟》中的早期采用者，愿意为了新技术的潜力承担额外成本。但一项技术真正跨越鸿沟的标志，是普通人已经能够依靠它，可靠地解决自己的问题。如果有一天，这种能力真的成为日常生活的一部分，操作系统、应用程序甚至软件本身，也许都不再是人们特别关心的事情。

到那时，衡量一台计算机的标准，或许不再是它支持多少软件、提供多少功能，而是一个更加简单的问题：它究竟能替人完成多少事情？