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