你的下一个应用，未必是程序
一、程序的谢幕与应用的崛起
在我接受电脑启蒙的时候，Windows 98 还是国内装机的主流。对当时的我来说，系统里最有魅力的莫过于「开始」下的「程序」（Programs）菜单。IE 浏览器、Office、画图——「程序」菜单就像一个包罗万象的百宝箱，里面的每个「程序」都是值得探索的宝藏。随着系统升级到 Windows XP，「程序」变成了「所有程序」（All Programs），MSN、Movie Maker 等新花样也加入其中。
「程序」的使命终结于 Windows 8。这代颇为激进的系统不仅取消了开始菜单，代之以磁贴风格的开始屏幕，也用「所有应用」（All apps）取代了「所有程序」。不仅如此，系统各处涉及「程序」的措辞，都被查找替换似地「升级」成了更时髦的「应用」。Windows 8 折戟后，微软在 Windows 10 中有所收敛，把开始菜单等传统设计还给了用户，但「程序」一词却留在了历史中，只在控制面板等残留的旧组件中才能看到了。
从「所有程序」到「所有应用」
留心观察，「应用」取代「程序」之势并不只发生于 Windows 系统中，在其他科技语境以至日常沟通中都是如此。但如果要考究「应用」与「程序」（以及另一个相近概念「软件」）究竟有什么区别，似乎也很难给出一个准确的答案。
不妨先看看词典和百科怎么说。概括而言：
- **程序（program）：**是可以被计算机执行的一系列编码指令。
- **软件（software）：**是计算机系统中的非物理部分，包括程序、库（library）及相关的数据、文档、媒体等。
- **应用（application，常缩写为 app）：**是「应用软件」的简称，指用于执行特定任务的软件，与「系统软件」相区别。
可见，尽管常被混用，三个概念的侧重仍是各有不同的。「软件」强调「非物理」的属性，可以指可执行的代码、也可以指不用于执行的文档等；其中可执行、用于完成实际任务的才是「应用」。另一方面，「程序」强调代码的可执行性，也未必直接面向用户；一个应用可能是由无数个只具有抽象功能的程序模块组成的。
再看辈份，《牛津英语词典》中，三个单词的在计算机领域的最早例句分别见于 1946 年（program）、1959 年（application）和 1960 年（software），相隔不远。就连让人感觉更时髦的缩写「app」也年届不惑。1981 年，就有科技公司雇主在《Computerworld》杂志（已停刊）的招聘版上 刊发广告：「Strong COBOL & fin’l or mfg apps knowl req. [Strong COBOL and financial or manufacturing applications knowledge required.]」1985 年，苹果为其 Lisa 电脑推出了名为 Mac_App_ 的应用程序开发框架。同年，Ashton-Tate 公司一款名为 Framework II 的办公套件中也出现了名为「App」的菜单，其中包含通讯、拼写检查等功能。
「app」的早期踪迹（来源：Google Books）
但最终开启「应用」时代的并不是什么技术因素。使用 Google 的搜索趋势功能 比较「应用」（app）、「程序」（program）和「软件」（software）三个相关单词的搜索频率，就会发现 2008 年以降，「app」的热度就一路走高，而另外两个单词则不断走下坡路。
使用 Google 的搜索趋势功能比较「应用」（app）、「程序」（program）和「软件」（software）
2008 年——这正是苹果应用商店 App Store 上线的年份。正如美国方言协会（American Dialect Society）将「app」评为 2010 年度单词 时所言，「『app』一词已经存在很久，但凭借『There’s an app for that』（苹果早年宣传 App Store 和 iOS 设备的著名广告语——笔者注）背后数百万美元的营销力量，以及一系列手机和电脑操作系统上应用商店的到来，『app』在过去 12 个月中真正爆发了。」
二、新在何处
尽管从「程序」到「应用」的变化很大程度上是商业和市场因素驱动的——简短俏皮的 app（或者本土特色的「挨屁屁」）就是比一本正经的程序更讨喜、更易传播，这也不意味着变化的背后就完全没有实质。就算没有权威来源的界定，我们仍然可以从经验中感受到如今「应用」在功能、开发、分发、定价等方面不同于往日「程序」的新特征。
（一）功能的情境化
在「应用」的词典定义中，最明显的限定语就是「用于执行特定任务」。不过，传统软件的任务其实并没有那么「特定」；它只是一个泛用的工具，在用户手上发挥的实际用途可能远超开发者的预料。Excel 确实是「电子表格」，但本质上只是一张具有排版和计算功能的空白网格，用户可以用来记账、管理库存、安排日程，也可以脑洞大开，用来 下棋、做十字绣。Photoshop 确实是「图片编辑器」，但本质上只是提供了编辑位图像素的功能，至于是用这些像素的排列组合形成照片、绘画还是简历，完全取决于用户自己。
用 Excel 下棋（来源：Pedro Wave for Excel Guys）
相比之下，如今的应用则更加符合「执行特定任务」的定义，从设计之初就确定了面向的任务或场景——无论查天气、购物还是打车——并且前所未有地细分和具体。（微信、支付宝这类具有中国特色的「超级应用」虽然功能庞杂，但实际上可以看作是一系列应用的集合，而每个功能模块仍然是用于完成特定场景下的特定任务的。）如果说在过去，用户不仅要「发现问题」，还要进一步「分析问题」，将其表达为公式、图层等可被程序理解的特定范式，才能借助程序提供的计算能力「解决问题」；那么在当今，用户只需要负责发现问题，分析和解决都由应用承包了。
不仅如此，近年很多应用还倾向于更进一步，与特定的方法甚至「哲学」联系在一起。这种趋势在效率类应用中尤为明显。在回顾自己 2019 年的数字生活时，我曾 提出 各种任务管理工具本质上都是在从不同角度理解和刻画「任务」这一现实对象；选择了一个任务管理应用，也就是选择了一套任务管理方法论。2020 年，类似的现象又出现在笔记应用的新一波热潮中。前有 Notion 将笔记的颗粒度从「文档」分解到「段落」——可交互的「区块」（block）；后有 Roam Research 将「双向链接」的概念从在线百科挪用到笔记领域。原本小众的「卡片盒」（zettelkasten）笔记论，由于与这股笔记原子化、网络化的潮流不谋而合，一时蔚然成风，成为新旧工具争相更新支持的功能。
2020 年风靡一时的 zettelkasten 笔记方法（来源：LessWrong）
值得指出，将方法论融入程序设计的理念，并不是在应用流行后才产生的。早在 1985 年，已故图灵奖获得者彼得·诺尔（Peter Naur）就提出过「将编程视作理论构建」（programming as theory building）的观点。（Naur, Peter. “Programming as theory building.” Microprocessing and microprogramming 15.5 (1985): 253-261.）诺尔提出，编程不只是在「产出程序之类的文本」，而是「编程者就手头事务形成或达成某种洞察或理论的活动」。但在当时，个人计算还未成为主流，诺尔笔下的程序和理论所面向的也是开发编译器、工控软件等行业场景。而如今的应用所面向和试图定义的，是购物清单、习惯养成、知识管理等普罗大众的日常生活事务。
从好处说，应用的情境化使其更容易被用户理解和接受，降低了学习门槛。大而全的传统软件固然灵活，但也容易让初学者感到茫然。我还记得自己刚接触 Photoshop 时面对繁杂的工具栏和菜单不知从何点起的体验，直到用它做了两次海报才算勉强上路。因此在过去，每当被问及学习大型软件的心得，我都会建议从需求出发，在解决实际问题的过程中逐渐熟悉操作。而如今，大多数应用本身就对应着一个具体需求，用户很少会再产生「用它做什么」的疑惑；随着傻瓜化、向导式的界面设计成为主流，需要记忆菜单位置、参数含义的场景也已越来越少。
但另一方面，如果对情境和方法论的强调失当，也会限制应用的受众，错误地引导用户将精力放在无谓的折腾和争论、而非解决实际问题上。例如，去年大红大紫的 Roam Research 虽然不乏亮眼之处，但它不遗余力鼓吹「网状笔记」哲学、不惜用半带贬义的「cult」（宗教崇拜）自居等营销方式也颇受争议。确实，笔记作为一种认知工具，应以快捷和实用为第一考量；即使真要关注逻辑和组织结构，也应是积累了一定数量的素材后再考虑的事。但大多数用户的实际情况是连记笔记的习惯都不曾有，就受那些官方背书的「效率大师」引导，试图「构建知识网络」「浇灌数字花园」，以致出现很多用 Roam 批注 Roam 教程，用 Zettelkasten 管理 Zettelkasten 心得的圆环套圆环场面，可谓当代版的邯郸学步。
不少 Roam Research 教程倡导的「数字花园」模式，如照搬照套反而会耽误效率（来源：Roam Garden）
更何况，合理的应用场景和工作流程并不是靠闭门造车就能准确挖掘的。诺尔之所以将编程的过程视作理论构建，是因为有感于存在一些无法通过代码、文档等文本充分表达的内容：程序的部件和结构特征与现实世界中活动的不同面向是如何对应的；这种对应方式的设计逻辑是什么；当现实需求改变时，如何修改程序以适应变化……显然，这些「不可言传」的程序之「道」，是建立在开发者体认现实工作内容、与用户充分沟通的基础上的；这也是诺尔主张在程序开发中重视人际交流和信任的原因。
反观如今市场，应用开发者与用户有渐行渐远的趋势。驱动他们作出设计决策的，常常不是将现实需求映射为应用设计的「理论构建」，而是自己的想象或市场风向。2020 年，全球居家办公的现实催生了大批办公协作应用，个个宣称自己「重塑」「革命」了在线办公。但稍加观察就会发现，这类应用仿佛是一个模子里刻出来的，仅仅将聊天、文档协作、日程管理等常见组件做成大杂烩，点缀以几个敷衍的「自动化」「AI」功能就粉墨登场，连文案、插画和界面布局都如出一辙。显然，这样的拼凑之作并没有体现对线上办公流程和需求的认真思考，它们所试图推广的「情境」也是缺乏说服力和竞争力的。
Dropbox 在桌面客户端中强行上马、广受批评的「协作」功能（来源：Dropbox）
（二）开发和分发的跨平台化
在传统软件的开发中，跨平台并不是首要考虑。相反，由于软件的运行在过去往往依赖于特定的软硬件条件，它们通常专属于某一平台。这种紧密的绑定关系，又反过来使得平台的身份特征和竞争力在很大程度上被软件生态定义。例如，提起 Windows，人们常常想起那些界面简陋但地位重要的企业级软件；而苹果的「艺术基因」和 Mac 电脑对音频外设的良好支持，则让 OS X 成为创意工作者的首选。
而对于如今的应用，跨平台已经不再是「可选项」或「加分项」，而是越发成为默认特征；「平台独占」反而成为少数了。促成这一变化的是供需两侧的合力。一方面，随着移动设备使用场景的拓宽、一人多设备的普及，用户对跨平台产生了切实和普遍的需求。另一方面，得益于 Electron、Flutter 等开发框架，开发者无需维护多个代码库就能实现跨平台；云计算的流行，使大量计算职能从设备端转移到了服务端，进一步降低了应用对软硬件平台原生机能的依赖。
就在几年前，将网页界面打包成独立应用的做法还常常被讥为「套壳」，但这在近两年已经令人习以为常了。事实上，不少移动和桌面原生应用的开发也已在相当程度上与网页应用别无二致：后端都是由容器、数据库、对象存储等云服务商提供的标准化模块组合而成，前端的界面设计也随着 Swift UI、UWP 等原生框架采纳「声明式」（declarative）布局，与网页设计越发近似和互通。
采用声明式界面语法的 Swift UI（来源：苹果）
跨平台的好处是显而易见的。用户省去了为了个别软件而困守特定平台的麻烦，降低了学习多种操作逻辑的成本；开发者无需增加过多开发成本，就能接触到成倍扩大的用户群体。
但跨平台在带来方便的同时，也剥夺着用户的控制权。运行环境和数据存储迁移到云端后，应用仿佛也变得和云雾一样虚无缥缈：我们无从确保今天上传的资料明天能否访问，本月购买的功能次月能否维持原状，甚至不知道应用下次启动时是会维持熟悉的界面，还是会随着热更新和灰度测试，变成另一个面目全非的海市蜃楼。对信息隐私的担忧，也随着一次次的数据泄漏和滥用事件不断放大。
螳螂捕蝉，黄雀在后。感到失去控制的不仅是用户，还有开发者自己。表面上，跨平台淡化了单个操作系统的重要性，似乎是一种「去中心化」的趋势，但由于要同时跟多个平台的分发渠道（应用商店）和云服务商打交道，开发者的负担和风险反而提高了。常常能看到开发者控诉谷歌、苹果以莫须有的「滥用」「违规」为由单方面中断服务或下架应用，使得他们苦心积累的业务和用户一夜付之东流。与真实世界肆虐的疾病祸不单行，2020 年的数字世界也「多灾多难」，从 Cloudflare（7 月，正则表达式耗尽 CPU 资源）、Amazon AWS（11 月，扩容操作失误）到 Google Cloud Platform（12 月，鉴权系统超过配额），几乎所有主要云服务商都在 2020 年经历了大型故障，Adobe、Spotify 等知名产品都未能幸免，缺少容灾能力的中小开发者更是广受波及。
收获上万点赞的抖机灵推文「我不能用吸尘器了，因为 us-east-1（AWS 的弗吉尼亚数据中心）挂了。」
（三）付费机制的订阅化
如果说情境化、跨平台的趋势整体上还算顺应了大众需求、受到用户肯定的话，另一个大趋势——将应用作为一种「服务」而循环收费——则至今争论不休，总能引发供需双方的对立和情绪化表达。现有应用从买断制转为订阅制，用户反响强烈、怒斥「贪心」的桥段，每个月都在反复上演。在批判订阅制的观点看来，订阅制将「购买」降格为了「租用」，是对于用户权利的剥夺和一种变相涨价的伎俩。
这种观点是不准确的。即使在充满拟物气息的盒装软件时代，用户买到的也远非「所有权」，而仅仅是一项授权（license），即在许可设备（往往限于一台）上安装和运行软件的一个实例的权利；「购买」「销售」等说法仅仅是因为更加方便、为人熟悉才被沿用到软件分发的语境中。(Adobe Sys. Inc. v. One Stop Micro, Inc., 84 F. Supp. 2d 1086, 1091 (N.D. Cal. 2000).) 这也解释了为什么软件许可协议里总要澄清是在「许可，而非出售」（“licensed, not sold”），并且用大写字母和粗体明确排除有关适销性（merchantability）、针对特定目的的适用性（fitness for a particular purpose）和不侵权（noninfringement）的责任——《统一商法典》 和英美普通法下适用于「商品」的卖方保证。（一个典型和当代的例子可见 Office 2019 的许可协议。）
不仅如此，即使用户在授权范围内使用软件，也要受到用途、备份、转让等多方面的限制；尽管没有明文规定使用期限，旧版软件也会逐渐失去安全补丁和新系统支持，从而事实上无法继续使用；技术支持也是软件厂商一大创收来源。
传统的买断制软件也会随着支持结束而事实上不适于继续使用（来源：微软）
可见，软件不是传统意义上的「商品」，而是从来就掺杂着大量「服务」的属性；购买时表面上的「一口价」也不等于软件使用周期中发生的全部成本。
这种服务属性在应用时代更为突出了。上文提及的情境化、跨平台等趋势，正是服务属性的体现：应用不再只是一个帮助用户解决问题的工具，而强调实际解决用户的问题，甚至反客为主，指导用户如何观察和思考问题；实现跨平台所依赖的云端计算资源，必然会产生额外的、周期性成本。「软件即服务」（Software as a Service，SaaS）与其说是一种模式创新，不如说是一种「再发现」——软件本应是、且始终就是一种服务。
因此，并不能简单地把订阅制和「贪婪」或「涨价」划等号。相反，订阅制某种意义上还是一种更「诚实」的定价机制，将原本隐藏在许可协议、升级政策中的额外成本明确地告知了用户——你当然有权不认同，但至少没有被欺骗。
但如果承认应用定价采用订阅制具有合理性，如何解释用户对它的普遍怀疑和反对呢？这种对立情绪的背后，是用户认为订阅支出和回报不成比例的观念。
首先，「订阅制」的名称本身就存在歧义，容易让用户产生不准确的预期。诚然，从词源上看，「订阅」并无商业含义，仅仅是一个「报名支持」的动作——「在 [文件、] 底部（sub-, “under”）写下（scribere, “write”）[名字、]」。作为一种商业模式，它最早指的也是股份、保险的认购，到十六世纪才被用于出版物领域，而且是指为书籍的写作和出版募集资金，反倒更像如今的捐赠和众筹。（参见 Clapp, S. L. (1931). The beginnings of subscription publication in the seventeenth century. Modern Philology, 29(2), 199-224.）
但必须承认，在大众语境下，「订阅」主要还是和「期刊」搭配出现的，以至于人们普遍认为但凡需要订阅的东西，都应该和期刊一样具有定期交付的属性。可应用开发不同于刊物出版，要求月月有新功能是不现实的，从而容易让不明就里的用户感到「有名无实」。这种预期落空的被欺骗感，与管理订阅的心理压力等负面情绪交织在一起，造成了用户对订阅制的抵触。
何况，订阅制只是一个笼统的说法，其具体实施细节已经随着实践探索，有了很多变种和优化。例如，计费机制上，除了按自然年月循环收费，又出现了根据用量或设备数等因素调整费率的模式。升级政策上，因荷兰公司 Skech B.V. 于 2016 年 提出 而得名的 「荷兰模式」（Dutch Model）被广泛效仿。作为一种「无限期使用，有限期升级」的混合模式，它允许用户付费后获得全部现有功能和一定期限（常见为一年）内新增的功能；到期后如不续费，软件使用也不受任何限制，只是升级被冻结、无法获得此后新增的功能。然而，这些新模式在宣传、报道和讨论中仍被习惯性地归为订阅制，用户也因而继续套用着对旧订阅制的刻板印象，经常膝跳反射般地提出反对。
由 Sketch 首倡并被广泛借鉴的混合订阅模式
不过，用户的负面印象也并不都是非理性的；订阅制目前的确没有给用户带来多少切实的好处。应用固然具有天然的服务属性，但那毕竟是隐性的，不足以说服用户克服「软件即商品」的惯性思维。要让他们情愿买单，订阅制应用还需在服务质量、功能迭代和云端整合等方面体现出与价格相称的进步。
但现实是，当下大多数订阅制应用都没能做到这一点。究其原因，用户支付的费用有相当部分消耗在了非效率的因素上。一方面，Microsoft Office、Adobe Creative Cloud 等来自大型开发者的传统软件倚仗垄断地位，把订阅制变成了创收机会，而缺乏改善用户体验的压力和动力。另一方面，中小开发者收到的订阅费用并不都能用于投入开发，而是要用来填平云服务、API 费用等上游成本，进一步为大型科技公司的寻「租」提供了空间。令人尤为遗憾的是，用户由此对订阅制产生的负面印象和抵触情绪，却不公平地在相对弱势的中小开发者身上找到了释放出口。
三、应对之道
可以看出，当今应用体现出的发展趋势并不都如宣传文案里那般光鲜美好，而至少是喜忧参半的。也难怪在 Hacker News 等技术社区上，这样一种带有美化色彩的「黄金时代」常被追忆和赞扬：一家公司十年如一日地提供更新；一套软件买回来可以跨越多次硬件换代而宝刀不老；用户组成紧密社群、积极讨论建言。
尽管令人遗憾，这样的时代是一去不复返的。随着竞争越发激烈，应用市场的迭代和淘汰加快不可避免。极客和科学家不再占据用户群体的多数，那些从事各行各业的普通用户的需求必然是多元、琐碎（甚至「庸俗」）的，其中有能力或兴趣参与反馈甚至贡献代码的更是少之又少。应用只有向情境化、服务化发展才能适应这样的新受众。
趋势或许不能改变，但视角和思路可以改变。既然当下应用越发接近于「服务」而非「商品」，就应带着对待服务的心态去选择、学习和使用应用。
首先，在选择应用时应该抛弃「从一而终」的假定。如果把购买应用看作一锤子买卖，那么理当在事前精打细算、事后物尽其用。但如果是在选购服务，策略就应有所不同：不用过分货比三家，只要满足需求就算物有所值；如果事后发现不合适，也无需纠结残余价值，而是尽快寻找替代方案以及时止损。
反过来说，服务降级甚至「跑路」的风险在付费之前就应该计算在内：从开发者口碑、更新历史和用户群体等方面，对应用的发展潜力作初步判断，回避跟风或投机之作；同时留好后路，尽可能选择格式通用、导出方便的工具，以减少日后的迁移成本。
此外，既然当下应用已经较少能作为通用工具、而更多是作为专用解决方案，我们在学习和使用时也不必过多拘泥于具体的操作步骤，而是更多地观察和借鉴应用反映的工作流和方法论。这样，即使应用本身在一段时间后不复存在，这些非技术层面的东西却是不会消失、持续令人受益的。订阅制的流行在这样的视角下更是种福音，让人只需花费很低成本、甚至分文不出就能「偷师学艺」。
例如，你没有必要接受 HEY email 的高昂定价，也不妨试试看它聚焦待回复邮件、严格筛选来件、「钉」住常用信息等特色功能，然后在传统邮箱中通过过滤规则、旗标等功能变通实现。你可以觉得 Headspace 这类 冥想应用的流行 是硅谷式玄学，但蹭听几个课时、借鉴一些放松呼吸和情绪的技巧，也只是有益无害。
完全可以通过「偷师学艺」的方式借鉴应用的方法论（来源：HEY）
除了用户，开发者同样需要改变思路，更多地从「服务提供者」的视角看待自己的业务。翻阅各路应用宣布转为订阅制的公告，会发现一个奇怪的现象：很多公告不像是在宣传介绍新模式，反倒像在对着一个假想的批判者作辩解和控诉。「我们也嫌订阅制麻烦，但实在是入不敷出」；「我们这其实不算订阅制，因为你花钱买过的功能还是你的」。
考虑到订阅制目前的舆论现状，这种做法当然可以理解。但如果连开发者自己对于转换商业模式都抱有抵触和怀疑，又怎么能期待用户能被说服呢？我更希望看到的，是开发者理直气壮、落落大方地宣布改变付费模式，同时开诚布公地说清列明收费档次、方式和订阅费用的用途。
不过，权利和义务应当对等。在通过订阅制获得合理稳定回报的同时，开发者也应当担起更多服务责任，例如积极与用户互动沟通、了解其实际使用方式和需求；在确定开发计划和销售策略中着眼于持续经营（going concern），而非满足于「捞一笔就走」。当然，也不要抛弃软件在过去普遍具有的「传统美德」，包括留意和优化资源占用、编写详尽的文档和手册、关注数据的通用和便携等。
四、下一个应用，何必是程序？
苹果近年的电视广告中，评价最褒贬不一的可能要数 2017 年一则宣传 iPad 的广告：初中生模样的主演娴熟地操作着 iPad，一路聊天、作画、记笔记、看漫画。片尾，面对邻居「你在用电脑做啥」的好奇发问，她漫不经心地回了句「啥是电脑？」（What’s a computer?）。
「啥是电脑？」（来源：苹果）
这则广告发出后 受到大量嘲讽，最后那句台词尤其被认为是不食人间烟火，令人感到冒犯。苹果后来从官方频道删除了这则广告，但并没有放弃将 iPad 定义为电脑的叙事，还在 2020 年将 iPad Pro 宣传口号定为「你的下一台电脑，何必是电脑」（Your next computer is not a computer）。
如果认为这些广告是在鼓吹「iPad 可以取代电脑」，那苹果的确有夸大和美化之嫌。但苹果的用意也可以从另一个角度理解：不必在意什么是电脑，能帮我们完成工作的就是电脑。
对待应用的定义也当如此。虽然本文一直在试图总结应用与程序的区别，但我深知任何结论都不可避免地有所疏漏；任何例子都可能存在大把反例。如果科技词汇的变迁证明了什么，那就是人们发明和更新概念的进度，追不上技术进步和行业发展的速度。
因此，与其关注应用是什么，不如关注应用能做到什么、是如何做到的、有没有尊重我们的选择和权利。与其关注一个应用是工具还是服务、原生还是「套壳」、买断还是订阅，不如关注它能否满足需求、提高效率、创造价值。
回想初学电脑的情景，「所有程序」菜单让我兴奋之处，不在于「程序」二字，而在于可以探索每一个「程序」的设计和功能。今天，初学者面对的设备、界面和概念都与我当时大相径庭，「程序」到「应用」的变迁也必然还有下一站。但无论这些如何变化，人们从科技的乐趣和可能性中感到的冲击是不变的；「所以兴怀，其致一也」。既然如此，下一个应用，又何必是程序？