应用大陆的旧日残垣：从按钮城市说起
应用大陆的旧日残垣：从按钮城市说起
周四晚上九点四十七分，小拓的手机屏幕亮着外卖 App 的首页，他已经在这个页面停留了整整三分钟。
不是因为选择困难症。是因为他根本没找到"下单"这个按钮应该藏在哪。
事情是这样的：他在玩《原神》打到一半肚子饿了，想点一份黄焖鸡米饭。他点开外卖 App，进入首页，看到一堆商家推荐。他点进一家评分 4.8 的店，看到菜品图。他想点一份黄焖鸡米饭加一份米饭——但屏幕上要先选"规格"：大份、中份、加辣、微辣、四人套餐、单人套餐。他选了单人套餐，又弹出一个"是否需要加购饮料和配菜"的弹窗，他点了"跳过"，又弹出一个"领取新人大礼包"的弹窗，他点右上角关闭，关闭按钮藏在三个并排小图标的中间，最小的那一个。他终于看到了"黄焖鸡米饭 28 元"这一行，又发现还要选"堂食/到店自取/外卖配送"，他选了外卖配送，然后要填地址、选地址簿、选默认地址、确认地址、选送达时间——立即送达还是预约？他选了立即，又弹出一个"是否需要餐具"的勾选框。
三十四分钟后，黄焖鸡米饭到了。
小拓关掉游戏，看着茶几上孤零零的外卖盒，第一次产生了一个奇怪的问题："我只是想吃一份黄焖鸡米饭，为什么我必须做二十九个决定？"
更奇怪的是，这件事他每天都做。每天打开手机、点开微信、点开抖音、点开淘宝、点开 QQ，他都在做类似的事：点按钮、选菜单、填表单、看弹窗、滑卡片。一套非常熟悉、非常自然、但又非常让人疲惫的流程。他从来没想过这件事是"正常的"，就像鱼从来没想过水是湿的一样。
直到今晚，他第一次把头从水里抬起来，看见了水。
---
一、按钮城市：人类用了三十年的设计遗产
小拓的外卖历险不是个别现象。这是一个三十年来被反复制造出来的体验类别。要理解它，我们得先回到 1984 年。
1984 年 1 月 24 日，苹果公司在旧金山召开股东大会，向世界展示了一台叫做 Macintosh 的电脑。这台机器看起来像一台小电视连着一个键盘加一个鼠标——当时大多数电脑都是黑屏白字，命令行输入。Macintosh 干了件前所未有的事：它在屏幕上画了一堆"小图片"，每个小图片代表一个"东西"：硬盘是一个小机器图标，垃圾桶是一个真正的垃圾桶图标，文件夹是一个黄色的纸袋图标。用户用一个叫"鼠标"的东西点这些图片，电脑就会做相应的事。
这个设计后来有了一个学名：图形用户界面，缩写叫 GUI（Graphical User Interface）。
GUI 的革命性在于：它把电脑从"懂命令行的人的工具"变成了"任何人都能用的机器"。我妈以前根本不会用电脑，但她会用鼠标点"开始"按钮，再点"我的电脑"。这就是 GUI 的伟大胜利。
但 GUI 的代价也埋在这里。它的核心规则是：屏幕上画一堆小东西，每个小东西代表一个命令，你点哪个，电脑就执行哪个。
这些"小东西"有一个更通俗的名字——按钮。
一个按钮长这样：它有一个固定的形状（矩形或圆角矩形），上面写着几行字，告诉你它会干什么。你用手指或鼠标点它，它就会触发某件事。按钮不会思考，不会听你说话，不会猜你想要什么。它只会坐在那里，等你点它。
三十年来，所有的电脑界面、所有的手机界面、所有的智能手表界面、智能电视界面、车载屏幕界面，本质上都是这个规则的延伸——按钮 + 菜单 + 表单 + 弹窗。这套设计哲学统治了整个应用大陆，几乎没有任何一个角落能逃出它的手掌心。
为什么它会统治三十年？因为它解决了一个核心问题：让一台复杂的机器可以被不会编程的人使用。 你不需要懂代码、不需要懂二进制，你只需要"看"和"点"。这是一个了不起的工程成就。
但问题也在这里：三十年了，我们人类也变了啊。
1984 年的时候，普通人第一次接触电脑，能打开 Word 打几个字就已经心满意足。按钮设计正好——把电脑最常用的几十个功能画成几十个按钮，用户慢慢找，慢慢点，没问题。
但 2024 年的情况完全不同。一个普通高中生每天面对的应用数量是 1984 年的几百倍，每个应用的功能数量也是当年的几十倍。手机屏幕上塞满了 App，每个 App 内部又塞满了按钮、菜单、表单、弹窗。一台小小的设备，承载了一个几乎无限复杂的数字世界。
这时候，GUI 这套"按钮城市"的设计哲学，开始遇到它的极限。
什么叫"按钮城市"？你可以这样想象：整个应用界面就像一座巨大的城市。城市里有很多建筑，每栋建筑代表一个功能。每个建筑都有门，门上写着名字。街道上有很多指示牌，指引你走到哪里。城市里还有红绿灯、斑马线、单行道、过街天桥。所有这些"建筑"和"道路"，都是设计者提前在城市规划阶段就修好的。
你要去任何一个地方，都必须沿着现有的街道走。没有路的地方你进不去，没有门的建筑你打不开，没有指示牌的地方你会迷路。
外卖 App 就是一座典型的按钮城市。它有"首页"这条主街，主街两边排列着"商家卡片"这些建筑。点进一家店，是一条支路，支路两边排列着"菜品"建筑。每个菜品都有"规格选择"这个门，"加购弹窗"是支路上的一个奇怪的小摊，"支付"是这条路的终点——一个叫"提交订单"的建筑。
你必须一栋一栋走、一道门一道门敲、一个按钮一个按钮点。任何一步走错了、漏了，城市都不会把你送到你想去的地方。
这就是小拓点一份黄焖鸡米饭要做二十九个决定的原因——不是因为他笨，而是因为这座城市的设计者预设了二十九个决定。每个决定背后都对应一个按钮、一个菜单或一个弹窗。
小拓在第一章要解决的核心问题，其实是这个：在 AI 大模型出现之前，我们人类使用的应用，为什么都长成"按钮+菜单"的样子？这种设计遗产是怎么形成的？它有什么代价？它为什么在大模型时代开始显得力不从心？
---
二、应用是一种"预设路径"机器：用户必须按照设计者的脚本来操作
理解了"按钮城市"这个隐喻之后，我们再往里走一层。
按钮城市的本质是什么？是预设路径。
什么意思？意思是：应用的所有功能，都已经被设计者提前画好了一条"唯一正确的路"。 用户想要完成一件事，必须沿着这条路一步步走。走错了、走漏了、跳了一步，系统都不知道该怎么办。
这跟我们人类的真实思维是不一样的。
小拓点外卖的真实思维路径是这样的：
> 我想吃黄焖鸡米饭 → 我常去的那家店 → 老样子，辣一点 → 直接送到家里 → 用我的会员券
总共五个意图，五个核心决策，意图到意图之间是跳跃的、非线性的、有省略的。
但外卖 App 强制他走的路径是这样的：
> 打开 App → 看首页推荐 → 选商家 → 看菜单 → 选菜品 → 选规格（必选）→ 选辣度（必选）→ 选套餐或单点 → 选加购（可跳）→ 选配送方式（必选）→ 填地址（必选）→ 选送达时间（必选）→ 选餐具（必选）→ 选支付方式（必选）→ 选优惠券（可选）→ 确认订单 → 提交 → 支付
总共十七步强制操作，加上若干可选步骤。其中至少有六步对"老顾客点老样子"这个场景来说毫无意义——他每次都点同样的东西，同样的地址，但系统每次都要让他做一遍同样的决定。
这就是"预设路径"和"用户真实意图"之间的自由度差距。
我们可以用一张流程图把这两种路径并排放在一起，看清楚差距在哪里：
```mermaid flowchart TD A[用户意图: 老样子] --> A1[黄焖鸡米饭 辣] A1 --> A2[送到家] A2 --> A3[用会员券] A1 -.理想路径: 1步.-> Z[下单成功]
B[打开App] --> C[首页推荐] C --> D[选商家] D --> E[选菜品] E --> F[选规格] F --> G[选辣度] G --> H[选套餐] H --> I{加购弹窗} I -->|跳过| J[选配送方式] J --> K[填地址] K --> L[选送达时间] L --> M[选餐具] M --> N[选支付] N --> O[选优惠券] O --> P[确认订单] P --> Q[提交支付] Q -.预设路径: 17步.-> Z[下单成功] ```
小拓实际想要的，是左上角那条三步到终点的路径。但外卖 App 只给他右下角那条十七步的路径。中间所有步骤，都是系统强迫他做的"问卷调查"。
为什么会这样？因为设计者无法预知每个用户的真实意图。
设计者是这样推理的："用户可能有的人喜欢加饮料，有的人不要，所以我必须问。用户有的人要筷子，有的人不要，所以我必须问。用户有的人用支付宝，有的人用微信，所以我必须问。"
这个推理在逻辑上是合理的——它要照顾"所有可能的人"。但代价是，每个具体的用户，都必须回答所有这些"可能的问题"，哪怕他的答案在 99% 的情况下都一样。
这就像一个老师上课前，把所有学生可能不懂的知识点全部讲一遍——虽然讲得都对，但每个具体的学生都要听完一堆对自己无用的内容。
预设路径的第二个代价，是"路径偏差"。 一旦用户的真实意图和设计者预设的路径不一致，就会出现两种结果：要么用户被强制改回设计者的路径（"请填写完整必填项"），要么用户放弃任务（"算了不点了"）。在任何一个 App 里，你都能看到大量"放弃"的用户——他们打开 App，看了看，关掉了，没下单。
预设路径的第三个代价，是"路径遗忘"。 设计者在设计路径时，会假设用户记得每一个步骤背后的逻辑。但实际上，用户经常忘。忘填地址、忘选时间、忘确认规格——然后就出错，错了就要重来。
按钮城市里，没有"老顾客"这个概念。每个用户走进城市，都必须从主街开始，一步步重新走一遍，没有 VIP 通道，没有记忆能力。
这是 GUI 三十年来的根本局限。 不是设计者不够努力，而是这种设计哲学本身的天花板就在这里。它假设"用户是一张白纸，每次操作都是独立的"。它不知道"你是谁、你过去做过什么、你现在大概想要什么"。它只能把所有的可能性都摆在桌面上，让你自己挑、自己填、自己点。
这套设计哲学有一个专门的术语，叫确定性界面。意思是：界面在每一个时刻，只有一个确定的状态、有限的几个确定的选择。用户必须从这些确定的选择里挑，挑完才能进入下一个确定的状态。
确定性界面在功能数量少的时候是好用的——比如 1984 年的 Macintosh，桌面上一共就那么几个图标，每个图标点开是确定的事。但当功能数量爆炸、应用数量爆炸、用户场景爆炸之后，确定性界面就开始变得笨重、繁琐、让人疲惫。
小拓点一份外卖花三十四分钟，做了二十九个决定。这种体验不是 bug，是 feature——是设计哲学的必然结果。
---
三、为什么通用界面会卡住所有人：新旧用户、专家与小白的体验折损
按钮城市还有另一个隐藏的代价：它试图对所有人都好用，结果对所有人都不是最好用。
我们用一个具体的例子来说明。
打开你妈妈手机上的微信，再打开你自己手机上的微信。长得一模一样，对吧？同一个微信，同一个版本，但你和你妈的使用方式天差地别。
你妈的微信里可能有：
- 几十个亲戚群、家庭群、同学群
- 一堆没读过的公众号文章（她不知道在哪关掉推送）
- 一堆不知道怎么清理的缓存
- 偶尔想用"健康码"小程序，但每次都找不到入口
你的微信里可能有：
- 十几个游戏开黑群、二次元群、追星群
- 一堆表情包收藏
- 自己设计的头像、状态、拍一拍文案
- 一堆你根本不看但懒得清空的服务通知
同一个界面，要同时服务两种截然不同的用户。 这是怎么做到的？答案是：把所有功能都堆上去，让每个人自己去找自己需要的那部分。
结果就是：
- 你妈用微信，找"健康码"要找 30 秒，因为她不知道"小程序"在哪里
- 你用微信，被"附近"直播、"购物"、"游戏"一堆她根本不知道的功能骚扰，但你也不知道怎么完全关掉
一个通用界面，就是这样一个东西：它把所有人都装进来，然后每个人都在一堆跟自己无关的按钮里翻找自己需要的那几个。
这种设计哲学有一个名字：通用化设计。它假设"界面是给所有人用的，所以设计者必须把所有功能都暴露给所有人"。
通用化设计的代价是体验折损——任何一个具体的用户，都只能用到界面 10% 的功能，但必须承受 100% 的视觉噪音和 100% 的认知负担。
我们再看另一个更明显的例子：QQ 和微信。
QQ 和微信都是腾讯的产品，按钮城市的设计哲学上，它们几乎一模一样。但它们的界面风格是不一样的——QQ 更"花哨"，有各种钻、会员、气泡、主题；微信更"克制"，几乎是白底黑字，没有花里胡哨的东西。
为什么？因为它们的用户群不一样。
QQ 的核心用户是十几二十岁的年轻人，他们喜欢装饰、喜欢个性化、喜欢表达"我是特别的"。所以 QQ 把"个性化设置"做成了一个非常庞大的菜单体系，主题、气泡、字体、背景、头像挂件……多达上百种。
微信的核心用户是全年龄段，从小孩到老人都有。老人看不懂花里胡哨的东西，商务人士嫌界面太幼稚。所以微信做了相反的选择——它把所有"花哨"的东西都砍掉，只保留最基础的功能：聊天、朋友圈、支付、小程序。
两种截然相反的设计哲学，对应两种截然不同的用户群。 但即使这样，它们都还是按钮城市——都是一堆按钮、菜单、表单、弹窗。只是按钮的多少、菜单的层级、表单的复杂度不同。
如果我们再看看 TikTok（抖音海外版），会发现它的设计哲学又不一样。它几乎没有菜单、没有表单、没有层级。它的核心界面就一个：上下滑动的视频流。用户几乎不需要做任何"决定"，只需要"上下滑"。喜欢就看完，不喜欢就滑走。
TikTok 是按钮城市里的一个"极端样本"——它把按钮城市的设计哲学推到了极致：所有按钮都隐藏起来，用户唯一能做的就是"滑"。这背后的逻辑是：用户的真实意图是"我想看好玩的东西"，而不是"我想从菜单里挑一个分类"。 所以它把分类、选择、决策都"代劳"了——算法帮你选好，你只需要滑。
这种"代劳式界面"是按钮城市的一种进化，但它也有代价——你失去了主动权。算法帮你选，但算法不一定知道你想看什么。你被困在算法的"信息茧房"里，看到的世界越来越窄。
把 QQ、微信、TikTok 放在一起对比，你会发现一个非常有意思的事实：
- QQ：把按钮全部暴露，让用户自己挑——代价是认知负担重
- 微信：把按钮大部分隐藏，只保留核心——代价是高级用户觉得功能不够用
- TikTok：把按钮几乎全部隐藏，让算法代替用户决策——代价是用户失去主动权
没有一种按钮城市的设计，能让所有人都满意。 它们都在做不同的"折损选择"。
这就是按钮城市的根本悖论：它假设所有用户都一样，但它服务的用户都不同。 为了在"所有人都能用"和"具体用户能用好"之间取得平衡，它只能做出妥协——做一个"对所有人都勉强能用，但对任何人都不是最好用"的界面。
小拓想问的"为什么所有应用都长一个样"，其实答案是：因为它们都基于同一个三十年前的设计哲学，这个哲学的天花板就在那里。 不是设计师偷懒，而是这个工具本身能做的事就这么多。
---
四、信息架构的三座大山：导航、表单、状态机
按钮城市的设计者其实也很辛苦。他们要在"把所有功能塞进去"和"让用户能找到"之间走钢丝。为了走好这根钢丝，他们发明了三类专门的结构——导航、表单、状态机。
这三类结构是按钮城市里最常见、也最折磨人的东西。我们一个一个来看。
4.1 导航：让用户知道"我在哪、能去哪"
任何一个稍大一点的应用，都有一个导航系统。
导航的功能是回答两个问题："我当前在哪里？"和"我能去哪里？"。
最常见的导航是底部 Tab 栏——微信底部的"聊天、通讯录、发现、我"，淘宝底部的"首页、消息、购物、我的"，抖音底部的"首页、朋友、+、消息、我"。四个或五个 Tab，把整个应用的主要功能切分成几大块。
但 Tab 栏有个明显的局限：最多只能放 5 个 Tab，再多屏幕就放不下了。如果应用有 10 个、20 个核心功能，怎么办？
于是就有了二级导航——汉堡菜单（左上角三条横线）、侧边抽屉、顶部 Tab 滚动条。"更多"按钮就是这个意思——我把最重要的 5 个放在底部，剩下的藏在汉堡菜单里。
但汉堡菜单的代价是：用户根本不会主动去翻汉堡菜单。 大量研究表明，汉堡菜单的点击率只有 15% 左右，也就是说 85% 的用户根本不知道、也不想去看那个藏起来的菜单。
更复杂的应用有三级导航——比如电商 App 里，"首页" → "女装" → "上衣" → "T恤" → 具体某件商品。这是一个四级路径，用户要点击四次才能到达目的地。
每多一层导航，用户就多一次"迷路"的可能。小拓妈妈为什么找不到"健康码"？因为健康码藏在"我" → "服务" → "生活服务" → "健康码"这个四级路径里，她记不住。
导航的设计本质，是在"信息扁平化"和"信息分类"之间做妥协。 太扁平了，所有东西挤在一个屏幕里，杂乱无章；太分类了，用户要找东西要点四五下，麻烦。
4.2 表单：让用户告诉系统"我要什么"
如果说导航是"找路"，那表单就是"填表"。
表单是按钮城市里最让人崩溃的结构之一。它把用户当成一个"填表人"——系统问问题，用户回答。
外卖 App 的"规格选择"是表单，"地址填写"是表单，"支付方式选择"是表单，"优惠券领取"也是表单。基本上，任何"你想要什么"的问题，都被翻译成了表单。
表单有几个让人崩溃的特征：
第一，必填项。 系统会用红色星号标记"必填"，告诉你"这一项必须填，否则不能继续"。这看起来合理，但用户体验极差——它假设用户知道这一项是什么、愿意填这一项、有时间填这一项。
第二，校验逻辑。 填错格式会被打回。比如手机号必须是 11 位数字、密码必须包含大小写字母和数字、地址必须精确到门牌号。这些校验在技术上是为了数据质量，但在用户视角就是"我填得挺对的，你为啥不让我过？"。
第三，跨步骤依赖。 前一步的选项会影响后一步的表单内容。比如选了"外卖配送"就要填地址，选了"到店自取"就不用填地址。这种"动态表单"在逻辑上是合理的，但用户经常在第 3 步发现"诶，我刚才第 1 步选错了，但现在改不了了，要从头来"。
表单还有一个更深层的问题：它把"用户的真实需求"翻译成了"系统能理解的字段"。 这个翻译过程是有损的。比如你想点"一份能吃饱的黄焖鸡"，但系统只让你选"大份/中份/小份"。你的真实意图是"够不够吃"，但系统强迫你把它翻译成"份量大小"。
每一次翻译，都是一次自由度的折损。 系统不会读心术，它只能用"字段"来代表你的需求。所以你必须把它能理解的字段都填一遍，不管那个字段对你的具体场景有没有意义。