【导读】本文探讨了软件设计的本质和未来趋势。作者通过分析三个爆款产品，提出了基于“概念”的软件设计方法。他认为，真正的创新在于简化应用场景，而非创造全新功能，创新往往不是创造新的东西，而是让原本的事情做起来更加简单。文章还讨论了如何利用概念思维进行编程，并预测随着 AI 代码生成技术的发展，人类工作将更多地转向概念设计和提示工程，而具体的代码编写则可能交给机器完成。
本文整理自 MIT 计算机与 AI 实验室（CSAIL）副主任、ACM Fellow Daniel Jackson 教授在 2024 全球软件研发技术大会中的演讲，同时收录于《新程序员 008》。《新程序员 008》聚焦于大模型对软件开发的全面支撑，囊括 Daniel Jackson 和 Daniel Povey 等研发专家的真知灼见与“AGI 技术 50 人”栏目的深度访谈内容，欢迎大家点击订阅年卡。
作者 | Daniel Jackson
责编 | 王启隆
出品丨新程序员编辑部
纵观软件设计的历史，可以见证这几十年来我们取得的巨大成功。
如今，软件具备了可用性，每天有数十亿人在工作和娱乐中使用软件。得益于编程技术、分布式计算、网络服务、数据库等领域的成功，软件具备了可扩展性。而且，由于人工智能技术的蓬勃发展，软件变得越来越智能。
但与此同时，我们也面临着一些巨大的挑战。
由于在用户界面、设计系统、以用户为中心的计算方面取得了诸多进展，软件逐渐变得可用了，但它仍然经常过于复杂，使用起来负担很重。用户经常需要花费大量时间去理解他们正在使用的软件，而这一点在企业软件中尤为明显。我们的软件或许是可扩展的，但它经常不安全，容易受到针对公司隐私和安全的攻击。而且它也常常存在安全隐患，有引发灾难的风险。还有个大家都很担心的问题：尽管软件正在变得更加智能，但也存在更加不可预测和不可靠的风险。
那我们该如何应对这些挑战呢？我的建议是，回归本源。作为工程师，不能仅仅通过发明新技术来解决这些基本的潜在问题，而是需要思考软件的本质是什么。特别是，工程师需要检查软件的功能，并提出问题：软件应该做什么？如何构建这种功能？
除此之外，软件模块化的问题可能比以往任何时候都更加重要。为了实现这点，还需要考虑用户的心智模型，即让用户理解我们正在构建的系统。为了探讨这些问题，我想分享三个所有人都很熟悉的成功产品案例。通过这些故事，再进一步思考：是什么让这些产品如此成功？
iPod 的成功之处：改变了人们听音乐的渠道
iPod 诞生于 2001 年，可谓是相当有年头的产品了。那么，iPod 的创新之处在哪里呢？显然，它的创新并不在于工业设计。原因是，只要你看看 Dieter Rams 在 1958 年设计的口袋收音机，就很容易能发现它对 iPod 外观设计的影响（如图 1 所示）。iPod 无疑是具有标志性的，但它在设计方面并不新颖。
图 1 iPod 和六十多年前的收音机设计雷同
在技术上，iPod 其实也没什么突破。史蒂夫·乔布斯在当年找到了东芝生产的一款异常小巧的 5GB 硬盘，从此缩小 iPod 的尺寸，取得了成功。而苹果公司本身也有一个文件传输协议，使上传音乐的速度变得更快。但这些都不是 iPod 真正必需的。因为数字设备公司（Digital Equipment Corporation, DEC）在 iPod 问世的几年前就已经生产过一台 5GB 的个人点唱机，名叫 Personal Jukebox。
因此，我认为 iPod 的成功源于一个更简单的原因。那就是 iPod 的基本应用场景简化了人们以前必须做的事情。试想在 iPod 出现之前，人们使用 MP3 播放器时必须经历的步骤：下载盗版音乐/转录 CD 光盘里的音乐 —— 上传至个人的播放设备 —— 开始播放音乐。其中，前两步的用户体验其实很差，因为用户要么只能偷偷盗版一些网络上的非法音乐，要么必须翻录自己的 CD 光盘收藏，而无论是哪种选择，操作都相当繁琐。然后，他们还得想办法弄清楚如何上传曲目到自己的个人设备，最后才能播放。
iPod 的出现，把一个非常简单的使用方式打包成了单一的应用场景。用户从 iTunes 购买歌曲后，可以立即在电脑上播放，同步到 iPod 后也可以在上面播放。在这个应用场景中，iTunes 作为辅助角色至关重要。事实上，如果观察 iPod 当年销量的爆炸性增长，会发现这款产品真正主导市场的时刻是在 2006 年左右。那时，iPod 的销量超过了任何其他 MP3 播放器。而在这一年，苹果已经通过 iTunes 销售了数亿首歌曲。
所以，iTunes 对 iPod 来说是必不可少的，因为它使这个简单的应用场景成为可能。现在，一个真正有趣的问题是：索尼为什么没能做到这一点？
你可能不知道，早在 1999 年，索尼就拥有成功所需的所有要素。索尼一直被视为全球最大的音乐集团之一，他们当时已经推出了一款出色的数字音频播放器 Network Walkman，这是其经典产品 Walkman 的后代。它甚至在日本已经有一间名为 Bitmusic 的歌曲商店，但不知何故，索尼无法将旗下的顶级播放器和歌曲商店整合在一起。关于原因，也已经有很多讨论，有人猜测可能是因为索尼使用了专有的压缩方案（ATRAC），还有人猜测是因为索尼将商店限制在了日本本土发布，更有甚者认为是数字版权管理（DRM）控制使软件难以使用……但我认为，最关键的是，他们没有一个简单的应用场景。
当我们打开索尼 Network Walkman 的用户手册时，只需浏览一页，就能立即感觉到这不是一个容易使用的设备（如图 2 所示）。显然，它缺乏一个简单的应用场景。
图 2 Network Walkman 繁杂的使用说明书
WhatsApp 的成功之处：群聊
第二个案例是 WhatsApp。很多人认为 WhatsApp 的创新在于提供了免费短信服务。但实际上，在此之前已经有免费短信应用了，那就是比 WhatsApp 早了三年的 TextFree。如果回顾 WhatsApp 的发展历程，我们会发现它从一开始就稳步增长，然后在 2011 年的某个时点突然出现爆发式增长。那时发生了什么？原来，WhatsApp 团队当时发布了一条推文（见图 3）：「群聊功能现已上线。」
图 3 WhatsApp 的历史性推文
但在 2011 年的时候，其实有许多不同的公司都在争相成为手机上运行群聊的首选应用程序，比如 GroupMe, Beluga 和 Yobongo。而 WhatsApp 最终在这场竞争中胜出。群组和群聊为什么如此重要？我认为，这还是与简化应用场景有关，并且还是一个非常简单的创新。
仔细想想，在没有群组的应用场景中，比如说电子邮件，每次你想扩大参与对话的人群时，新成员都必须被明确地添加为对话的接收者。这个过程和下载盗版音乐一样，其实非常繁琐。而通过群聊，你可以邀请人们，他们可以异步加入对话。这本质上是一种分布式的负担：每个人都以自己的节奏加入聊天，而不是由发起人一次性添加所有成员，让人被迫接受对话。这样，发送消息的人不会因为添加新成员而增加负担，使得群组的扩展变得更加简单和高效。
Zoom 的成功之处：会议链接
Zoom 的崛起是一个引人入胜的故事，它在疫情初期就取代了 Skype，而如果我们去查看那些预测 Skype 用户增长的统计数据，会发现许多网站都认为 Skype 的用户数量可以一直稳步增长到今年 —— 事实是，Zoom 的出现让这些预测都化为了泡影。至少在美国，除了 Zoom 以外，几乎每个视频会议平台基本上都逐渐衰落了，而 Zoom 则呈现爆发式增长。
那么，Zoom 的创新之处在哪里？这里有一个插曲：当时的英国首相鲍里斯·约翰逊发了一条广为人知的推文，宣布他在 Zoom 上将举行世界上首次“数字化内阁会议”。不幸的是，当他展示会议截图时，无意中泄露了自己的会议链接（Meeting Link）。当时 Zoom 还没有默认的安全控制，所以理论上任何人都可以通过输入那个会议链接加入英国政府的内阁会议。
这个事故背后，其实隐藏着一个重要细节，且它恰恰揭示了 Zoom 成功的真正原因。
iPod 的创新之处不在于听音乐，WhatsApp 的创新之处不在于聊天，所以 Zoom 的创新也不在于视频通话本身。视频通话技术可以追溯到 1960 年代，而后来的 Skype 也在视频通话这方面做得很好了。此外，Zoom 并没有在设备上实现视频通话的技术创新，因为早在 1994 年，世界上首款商用网络摄像头 QuickCam 就已经很便宜了（当时售价 100 美元）。虽然 Zoom 确实有很好的视频质量，但它的核心创新也不是视频编码技术，像 H.264 这样的视频编解码器（用于高效压缩数字视频的标准）早已存在多年。
相反，Zoom 的创新在于它巧妙的“一键会议”应用场景。在 Zoom 之前，如果你使用 Skype 想邀请一群人开会，会遇到两个麻烦。首先，你需要注册应用程序，而且所有参会者也必须注册。这意味着每个加入会议的人都必须是 Skype 用户，并且拥有一个账户。其次，发起通话时，你必须逐个将所有参与者添加到通话中。
显然，对于大型会议来说，这非常不便。诚然，Skype 确实有一个群组功能，使这个过程稍微简化了一些。但它远不如 Zoom 的“一键会议”应用场景那么便捷。Zoom 的创意是，当你创建会议时，它会生成一个会议链接，你只需跟和别人分享这个链接，然后任何人都可以通过这个链接加入会议。这看似是个微小的创新，但实际上影响巨大。
我认为这正是 Zoom 成功的关键。纵观其他视频会议平台的成功案例，没有一个能真正与 Zoom 相提并论。而 Zoom 也并非首创者。事实上，几年前就有一家名为 Join.me 的公司在其产品 Log Me In 中率先提出了会议链接的概念。Zoom 借鉴并完善了这个创意。这个创意如此成功，以至于随后被其他所有竞争对手采用。特别是 Skype，在 2020 年 4 月才开始使用会议链接功能。但到那时，Zoom 已经拥有 3 亿用户，Skype 早被甩的远远落后了。这个创意之后还影响了其他平台，例如，Microsoft Teams 在几年后也采用了会议链接的概念。
从场景（Scenario）到概念（Concept）
应用场景定义了产品，是关于如何使用产品的生动描述。
它既是一种社交协议（规定了用户如何互动），同时也是一种 API（定义了技术层面的交互）。它揭示了产品将如何满足用户需求，代表了一种典型但并非唯一的使用方式。这种以应用场景为中心的产品思考方式不同于传统的用例方法或多场景产品规划。相反，它强调通过单一的核心应用场景来捕捉产品的设计理念。
现在，我想提出一个更具争议的观点：创新几乎从来不会真正使全新的事物成为可能。仔细想想。回顾你所知道的所有创新发明，问问自己，“它们真的让我能做任何全新的事情吗？” 事实上，几乎所有时候，创新所做的是让你更容易完成你已经在做的事情，它是用一个新的应用场景来替代一个存在不便之处的旧应用场景。
现在我想将“场景”扩展到我称之为“概念”的想法上。以 Zoom 为例，它的核心应用是提供会议链接服务，但除此之外，它还支持多种场景，比如在聊天会话中，用户可以在聊天窗口发送文本消息。这些不同的场景交织并存，相互穿插，而每个场景都体现了我所说的“概念”（Concept），即一种独立的功能单元。
概念是单个软件、一类软件以及各类软件的特征。概念可以让开发者比较软件，注意其必要的功能以及知道如何有效地使用这些功能。
因此，你可以将 Zoom 理解为由这些概念构建而成，包括会议链接、视频频道（VideoChannel）等。其中一些概念是创新性的，如会议链接；有些是我们非常熟悉的，如在线聊天；还有一些是通用性的概念，几乎在每个应用程序中都能见到，例如用户身份验证，这是最典型的通用性概念之一。
这些概念通过“交互+同步”的方式融合在一起。在使用 Zoom 时，你不需要特意开启聊天功能；事实上，当你加入或启动会议时，就已经自然而然地进入了聊天模式。这种自然过渡的方式就是概念如何巧妙地结合在一起的体现。
因此，我们可以将应用程序视为概念的集合，并将其简化为最核心的部分。例如，对于 Zoom 来说，基本的概念可能是会议链接和视频会议。对于像 Calendly 这样的日程安排软件，核心概念可能是自助预约和通知。而对于 iPod 来说，则是歌曲管理、音乐商店以及文件同步的概念。这些概念实际上混合在了我所描述的各种场景中，并且可以容易地分解为三个独立的场景，进而理解为三个独立的概念。
当我们设计概念时，我们不仅仅是在考虑场景。例如，对于我提到的聊天概念，设计这种概念首先要明确它的目的，而聊天概念的目的可能是为了在群组中分享简短的消息。一个概念的目的应该是有说服力、以需求为中心、具体和可评估的。概念的目的很少能用比喻解释清楚。
接下来，就可以定义场景，或者说定义一个操作原则（operational principle），这一术语源自哲学家迈克尔·波兰尼的思想。操作原则用于展示如何通过操作实现目的，这是理解概念的关键。对于聊天概念来说，场景定义可以是：当两个用户加入聊天后，如果其中一个用户发布消息，另一个用户就能阅读它。
但是，我们可以进一步具体化这些规则，因为概念本质上是一个可以通过 API 来定义的服务。比方说，列出一系列动作。这些动作实际上是出现在场景中的行为，可以被视为 API 的组成部分。接着，我们可以思考支持这些动作所需的状态。
例如，对于聊天概念，状态可能包括聊天中的消息集合、每条消息的具体内容、消息发布时间、用户何时加入聊天等。实际上，当你深入研究概念的细节时，你会经常发现一些原本在场景中并未显现出来的重要设计问题。在这个例子中，很多聊天概念的工作方式实际上存在一个显著的设计缺陷，那就是用户通常只能查看他们在加入聊天之后发布的消息。
在 Zoom 中，这就是一个不小的困扰，因为它意味着如果有人在会议开始时发布了一条聊天消息，比如会议议程，那么任何晚一分钟加入的人就无法看到这条消息。这对于那些想要获取会议初始信息的迟到者来说是非常不方便的。
如何运用概念？
我们现在可以问另一个问题：有多少概念能使一个应用程序与众不同？就像我描述的那些应用程序，有些我认为实际上只有一个关键概念。以 Zoom 为例，我认为它的核心就是会议链接这个概念。而对于 WhatsApp 来说，它的核心实际上是群聊的概念。
在另一个极端，有些应用程序真正引入了一整套复杂的概念。我认为最能代表这类应用的是你可能称之为生产力应用（productivity apps）的那些软件。想想像 Photoshop（Adobe 公司开发的图像处理软件）这样的应用，以及所有遵循 QuarkXPress（一款专业的桌面排版软件）模式的桌面出版应用，现在还包括像 Adobe InDesign（Adobe 公司的专业排版软件）这样的应用。
这些应用有一套非常精细的概念集合，说实话，这些概念相当难以学习。以 Photoshop 为例，它不仅仅是像素数组的概念，还有图层、蒙版和通道这些关键概念。正是这些概念实际上使得 Photoshop 能够击败如此多的竞争对手。
概念的组合为创造性设计提供了机会，即使其中的每个概念都是通用性概念。概念不像程序那样，可以用较大的包含较小的。相反，每个概念对用户来说都是平等的，软件或系统就是一组串联运行的概念组合。
但有趣的是，还有一些应用程序实际上没有引入任何新的概念。比如 Gmail（谷歌的电子邮件服务）。Gmail 基本上只是结合了我们已经知道的两个通用性概念，即电子邮件和搜索。又或者是 Arc 浏览器，它做了一件非常有趣的事情，将浏览器中的标签概念与书签概念巧妙地结合在一起。
当你心中有这样的概念时，你可以会从一个不同的角度来思考设计和推理可用性。让我们以 Zoom 为例。Zoom 有一个表情反应按钮，如果点击按钮，你会看到如下图 4 这样的界面。
图 4 Zoom 的表情反应界面
长久以来，Zoom 用户界面基本的底层功能是一直不变的。例如，用户一直可以点击“鼓掌”按钮，为演讲者喝彩；点击“对”和“错”的按钮，表示赞同或反对；然后还有两个按钮，用于示意演讲者放慢或加快说话速度；右侧的“咖啡杯”按钮，则可以表示你想喝杯咖啡缓缓；或者是界面下方的“举手”按钮，点击之后可以像现实的会议一样举手示意。
有趣的是，点击这些按钮的反馈效果却有所不同。例如，点击“爱心”按钮，冒出来的爱心表情会在 10 秒后自动消失 —— 这可能是 Zoom 设计中的一个遗憾之处。奇怪的是，如果我们点击“举手”按钮，出现的表情并不会在 10 秒后消失，而是一直停留在界面上。经常使用 Zoom 的人都知道，人们经常会忘记放下举起的手，这导致了各种混乱。
此外，顶部的这些按钮其实是互斥的，这意味着你不能在“鼓掌”的同时发送“爱心”，这似乎不太合理。更奇怪的是，点击按钮的反馈效果也是互斥的。这意味着如果你先点击“赞同”按钮，再要求演讲者放慢或加快速度，最后去“喝一杯咖啡”，后点击的按钮往往会取消前一个按钮的效果。更奇怪的是，有些按钮会被计数，你点击之后屏幕上会显示“xN”，代表点击了 N 次，而有些按钮则不会。
因此，Zoom 的界面存在很多不一致的设计。如果我们想解决这些不一致的问题，并思考如何以更系统的方式设计 Zoom，可以尝试识别其底层概念，并将它们分离成更健壮、更简单、更引人注目的概念。我可能会将其 Zoom 的底层概念分解为以下四种：
1. 反应概念：这本质上就像发送一个小的情感反应。那些使用 Slack 的人会对此很熟悉。
2. 投票概念：当有人提出一个问题，我们用赞同或反对来回答。
3. 反馈概念：你可以告诉演讲者加快或放慢速度。
4. 在线状态概念：将咖啡杯（表示我离开）按钮和举手按钮整合在一起。
如果让我重新设计这些功能，可能会这样做：在屏幕左下角放置一个单选按钮，让用户可以选择几种状态之一。
最基础的状态，适用于打开麦克风交流的情况：“正在发言”。
“正在观看和聆听”。当用户选择这种状态之后，可以保持视听，但会自动静音终端音频。
“离开”。选择这个状态时，让软件直接静音。
在用户点击“举手”按钮时，它将表示用户正在请求发言，所以需要先将用户静音。
只要演讲者反馈了点击“举手”按钮的用户，该用户举手状态将消失，并进入“正在发言”状态。
因此，我相信有可能围绕一个更连贯的在线状态概念，对所有这些不同的动作进行很好的重新设计。同样，我认为反馈按钮可以被组织成一个单独的概念，其用户界面控件甚至可能不需要总是显示，除非演讲者决定他们想接收反馈。这就是使用概念来思考应用程序用户体验的想法。
用概念驱动编程
如今，我们甚至可以运用概念设计的思维进行编程。2023 年有一份关于 GitHub Copilot（AI 编程辅助工具）的报告指出，当前大约一半的代码是由使用 Copilot 的开发者自动生成的。至少在 Python 基准测试上，大模型编码似乎变得非常出色，在许多简单函数上达到了约 92% 的准确率。
但关键是，这些数字都是针对单个函数的，是一种自动补全形式的代码生成——即要求大模型推导出一个单一的函数。当你考虑整个应用程序时，情况就大不相同了。GitHub 的首席执行官 Thomas Dohmke 就说过：“开发者的关键技能在于，‘我需要细化到什么程度才能用 AI 自动生成代码？’”
我认为，是时候重新思考软件的结构来解决这个问题了。
举例来说，Hacker News（一个著名的科技新闻聚合网站）和许多应用程序一样，它完全由熟悉的功能组成：点赞、评论、发帖、板块还有“声望值”（karma）系统。
不同的网站或论坛对于这个“声望值”有不同的叫法和用途，比如在 Reddit 里这就是一个可以通过良好行为积累的积分点数，而在某些资源网站中可以设置“声望值”的门槛让资源更难被下载。而 Hacker News 的用户声望值只要达到一定水平，就可以对帖子进行点踩（downvote）。
所以重点在于，Hacker News 并没有创造性的变化，却带来了一些创造性的变化。这就是 Margaret Boden 在她的一篇著名论文中所称的“组合性创造力”（Combinatorial Creativity），即将熟悉的元素以新的方式组合在一起。
对于 Hacker News 来说，它是标准概念的一些变体。例如，一个帖子只能包含标题、ID 作为链接，或者一个问题，但不能同时拥有两者。又如，评论在两小时后不能被编辑，两周后就不能对帖子进行评论。这些聪明的小规则确保了网站的时效性和新鲜度。然后是特有的声望值规则，例如说，用户需要 501 点声望值才能踩一条评论，或者 30 点才能标记一个评论。
在我看来，这其实是构建 Web 应用程序的新型框架（如图 5 所示）。
图 5 构建 Web 应用程序的新型框架
每个概念都将是一个小型后端堆栈，包含了概念的行为。这些都是构成应用场景的用户操作的程序。然后是一个数据库来支持概念的状态。
关键点是，所有这些概念之间没有依赖关系，因为概念是完全独立的，并且以独立的方式定义。这真的是概念中的大想法。概念之间的连接只发生在路由中，HTTP 端点通过我称之为行为同步的方式连接到概念。这恰好对应于我展示的不同概念的应用场景之间的这些链接。
有了这个想法之后，实际上还可以用它生成代码（如图 6 所示）。
图 6 概念驱动代码
关键在于，我们将采用提示词（Prompt），为每个概念生成代码，完全独立于其他每个概念。这意味着我们不必担心随着应用程序变大而增长的上下文。但每个概念都可以独立实现。然后要做的是，为路由编写一个提示，将再次独立地为每个路由生成路由代码。
当然，正如我先前提到的，路由需要做的是调用概念的行为。所以还需要使用大模型从生成的代码中提取每个概念的 API。然后路由将使用这些概念 API 来合成路由代码 —— 最后，记得对前端也故技重施一遍，把它包装起来，进行部署。
代码生成将成为可以交给机器完成的工作
总结来说，我第一个想法是创新简化应用场景。例如，在群聊的概念中，场景的简化体现在发送消息的人不必添加所有收件人。如果我们回顾软件领域的所有创新，你会发现几乎所有的创新都涉及这种应用场景的简化。
其次，虽然我们经常从用户界面的角度思考，但软件设计实际上是从功能开始的，而概念帮助我们构建它。比如说 Zoom，我认为会议链接的概念对 Zoom 的本质和成功真的至关重要。
再比如说网络，我认为 URL 的概念可能比任何其他概念更能解释它的成功。我相信 Tim Berners-Lee（万维网的发明者）也认为 URL 比其他任何概念都重要。
最后，我想强调三个要点：
第一，模块化是关键，正是因为概念是完全独立的，我才能够独立地讨论这些概念。正是因为它们是独立的，我们才能理解应用程序，
第二，提取出熟悉的概念。许多概念是通用的，在我们进行的代码生成中，根路由和同步是需要定制的部分。当你进行概念设计时，一个重大创新是它允许你将熟悉的部分与真正新颖的地方分开。
第三，告别敏捷开发。多年来，很多人一直相信代码就是王道，规范其实并不重要，前期的大规模设计是个坏主意。但我认为，既然大模型真的很擅长生成代码，那人类的工作将更多地集中在编写提示、进行设计和塑造概念等方面。代码生成将成为可以交给机器完成的工作。
大模型刷新一切，让我们有着诸多的迷茫，AI 这股热潮究竟会推着我们走向何方？面对时不时一夜变天，焦虑感油然而生，开发者怎么能够更快、更系统地拥抱大模型？《新程序员 007》以「大模型时代，开发者的成长指南」为核心，希望拨开层层迷雾，让开发者定下心地看到及拥抱未来。
读过本书的开发者这样感慨道：“让我惊喜的是，中国还有这种高质量、贴近开发者的杂志，我感到非常激动。最吸引我的是里面有很多人对 AI 的看法和经验和一些采访的内容，这些内容既真实又有价值。”
能学习到新知识、产生共鸣，解答久困于心的困惑，这是《新程序员》的核心价值。欢迎扫描下方二维码订阅纸书和电子书。
221
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
