不是多见世面，而是让判断一次次被现实结算。
--
1979 年，年轻的计算机教授 David Patterson 去 DEC 度过一次休假。
当时，DEC 的 VAX 是一台很成功的小型机。但它有一个让工程师头疼的问题：指令集越来越复杂，芯片内部那层负责“翻译指令”的微代码也越来越庞大，于是 bug 不断出现。
如果把一台计算机想成一间厨房，微代码有点像藏在后厨的一套操作手册。前台的一条指令看起来很简单，后厨却可能要拆成许多动作才能完成。菜单越复杂，手册越厚，出错的地方也越多。
Patterson 当时的第一反应很工程师：既然微代码会出 bug，那就给它设计一套能在现场修补的机制。
这是个合理答案。
至少看上去合理。
后来，这篇论文被拒了。审稿意见让他不得不面对另一个问题：如果一套架构已经复杂到需要不断给自己打补丁，为什么不先问问——它到底该不该这么复杂？
这件事后来把他推向 RISC，也就是“精简指令集计算机”的路线。1980 年，围绕 RISC 的论文开始出现。它不再执着于让处理器理解越来越多、越来越复杂的指令，而是反过来追问：能不能用更少、更规律的基本指令，把真正需要的能力做出来？
这个故事里最重要的，不是 RISC。
而是 Patterson 的转向。
他一开始想的是：怎样更好地修补旧答案。
后来他开始问：为什么我们把这个当成了问题？
这或许就是品味真正开始形成的时刻。
不是你忽然知道了什么是好的。
而是你再也无法把一件不对的事，当成理所当然。
01 一个人开始有品味，通常不是因为他知道得更多
我们经常把品味想成一种知识。
你知道 Unix、Smalltalk、RISC、TCP/IP、关系数据库；你读过一些设计原则；你会说第一性原理、奥卡姆剃刀、End-to-End Principle。
但这些都不自动等于品味。
知识回答的是：
这个世界上，曾经出现过哪些好东西？
品味面对的却是一个没有标准答案的当下：
眼前这件事，哪里不对？
什么值得留下？
什么可以删掉？
什么根本删不掉，只是该换一个人、换一层系统来承担？
哪条路值得继续走？
所以品味不是知识的库存。
它更像一种被压缩后的判断。参见黄仁勋的答案，杨振宁的解法
一个人见过足够多的好系统与坏系统；亲手做过选择；犯过错；看过“看起来极其漂亮”的方案死在真实用户、成本、维护、迁移与故障里。
最后，那些经历不再以一条条规则存放在脑子里。
它们被压缩成一种感觉：
“这里好像不对。”
这感觉看起来像直觉。
其实背后，可能是十年。
但经验也会骗人。
有人经验越多，越能看见新的可能；也有人经验越多，越只会熟练地调用旧答案。前者把经验当作比较对象，后者把经验当作自然规律。
所以，品味的第一道门槛从来不是“经验够不够多”。
而是：
你能不能不把自己已经习惯的东西，当成唯一合理的东西。
02 先被旧世界认真地教育，才有资格怀疑旧世界
很多人把品味理解为反叛。
好像一个真正有品味的人，应该看谁都不顺眼；看见成熟系统就要推倒；看见主流路线就要反着走。
恰恰相反。
真正有价值的怀疑，往往来自对旧世界最深的理解。
Unix 是一个极好的例子。
1968 到 1969 年，Bell Labs 正在逐步退出 Multics 项目。Multics 很宏大：它试图做一个多人共享、可交互、能力极强的计算系统。但它昂贵、复杂，而且迟迟没有交付一个真正可广泛使用的版本。
Ken Thompson、Dennis Ritchie 等人舍不得的，恰恰是 Multics 最好的一部分：让计算机从一台被少数人预约使用的机器，变成一个可以交互、可以共享、可以共同工作的环境。
但 Bell Labs 不愿再为这个宏大梦想持续投入昂贵设备。于是 Thompson 只能在一台少人使用的 PDP-7 上，慢慢做出 Unix 的早期形态。
Unix 的真正启示，从来不是“简单就是好”。
而是：
真正的删减，来自先知道什么绝不能删。
如果你根本不知道交互式计算为何重要，就很容易把它删掉。
如果你不知道一个成熟系统为什么会长出那么多“多余”的部件，也很容易把必要的能力，当成无谓的复杂。
Git 的故事也是如此。
在 Linux 内核早期，协作主要依靠补丁和压缩包传递。2002 年，Linux 社区开始使用 BitKeeper——一个分布式版本控制工具。它让开发者第一次更直观地体验到：每个人都可以拥有完整的本地仓库；大量分支可以并行演进；协作不必永远围绕一个中心仓库排队。
2005 年，Linux 社区与 BitKeeper 公司之间的关系破裂，免费使用权被撤回。
Linus Torvalds 没有回到过去。
他也没有简单复制 BitKeeper。
他是带着自己已经体验过的新结构，去做 Git：速度、简单设计、强大的非线性协作、完整分布式能力，以及服务超大项目的效率。
所以，Git 不是“有人突然想到一个更酷的版本控制工具”。
它更像是：
一个人见过另一种可能之后，再也无法接受旧世界。
这是一种很重要的品味训练。
你用过真正顺手的工具、真正清晰的产品、真正尊重人的组织、真正干净的表达之后，低质量的东西会开始让你不舒服。
不是因为你变挑剔了。
而是因为你的最低标准被提高了。
03 品味不是“我讨厌它”，而是“它有一个解释不了的事实”
低质量的不满意是：
“这个东西真烂。”
“行业全错了。”
“别人都没看明白，只有我清醒。”
这类话很有气势。
但没有价值。
高质量的不满意更像是：
我知道它为什么成功，但这里仍有一个事实，它解释不了。
Patterson 面对 VAX 是这样。
复杂指令集并不是愚蠢，它有自己的历史理由：让一条指令完成更多事，让程序表达得更紧凑，让机器承接更多工作。
但微代码越来越庞大、调试越来越困难，也是事实。
两个事实同时成立。
真正有品味的人，不会急着用一句“复杂就是坏”把矛盾抹平。
他会把矛盾留在那里。
Jev 的故事价值在于，它提出了一个足够尖锐的问题。
TypeSafe 创始人 Diogo Almeida 参与过让语言模型更擅长理解指令、与人对话的研究。他后来提出：模型已经擅长聊天很多年了，但真正安静、可靠、可交给软件直接执行的自动化，到底在哪里？
于是，Jev 试图不再把自然语言生成当作唯一出口，而让模型输出可被程序直接消费、带概率与置信度的结构化判断。TypeSafe 把这条路线称为 RLCD，即“面向校准决策的强化学习”。
它真正问的是：
如果一个系统越来越会讨好人、协助人、解释给人听，为什么人仍然必须守在很多判断环节旁边？
这不是一个模型参数问题。
它是一个任务定义问题。
也是品味最先发生的地方：在别人都默认“事情本来就该这样”的地方，仍然感觉到某种异常。
04 但看见异常，只是品味的一半
另一半更难。
就是：异常出现之后，你把复杂性放到哪里。
很多人刚刚开始形成设计意识时，都会迷恋“简单”。
少一个按钮。
少一层流程。
少一个模块。
少一个概念。
但走得更远之后，你会发现：有些复杂性根本无法删除。
分布式系统仍然会有机器故障。
数据库仍然要处理存储与一致性。
大型协作仍然要面对冲突。
互联网仍然会穿过不一样的网络。
真正重要的问题，不再是：
如何消灭复杂？
而是：
谁最应该承担它？
1970 年，Edgar F. Codd 写下关系数据库模型时，真正颠覆的并不只是“用表存数据”。
在那之前，程序往往必须知道数据在机器内部如何组织，沿着什么路径读取；底层存储结构一变，上层程序也可能要跟着调整。
Codd 提出，未来的大型数据库用户不该被迫理解这些内部表示。存储如何变化，是数据库系统该负责的事；用户与应用程序应主要面对逻辑上的数据关系。
这是一种责任重分配。
不是让数据不再复杂。
而是不再让每个使用数据的人，都为底层复杂买单。
2004 年，Google 提出 MapReduce，也做了类似的事。
程序员只需写两类逻辑：如何把数据拆开处理，如何把中间结果汇总。
而那些真正折磨人的问题——数据怎样切分、任务怎样分派、哪台机器挂了、任务如何重试、机器之间如何通信——交给运行时系统。
MapReduce 没有消灭这些麻烦。
它只是说：
写业务计算逻辑的人，不该每次都重新承担这些麻烦。
Google 的论文讲得很直白：程序自动在大规模机器集群上并行执行，运行时负责分片、调度、故障处理与跨机器通信。
这就是好抽象真正做的事。
不是让世界变简单。
而是让正确的人，只面对属于他的复杂。
TCP/IP 的故事更漂亮。
1970 年代，ARPANET、无线分组网络、卫星网络彼此不同：接口不同、传输特点不同、底层组织也不同。
一个看似自然的答案是：把它们统一成同一种网络。
Bob Kahn 和 Vint Cerf 选择了另一条路。
他们提出的关键原则之一是：每一种独立网络可以保持自己原有的内部结构；为了接入互联网，不需要为此改造它的内部。网络之间通过后来被称为网关、路由器的“黑盒”连接。
1973 年，两人开始形成协议设计；1974 年，相关论文发表；1983 年 1 月 1 日，ARPANET 的主机集体从旧的 NCP 协议切换到 TCP/IP。
互联网没有要求全世界先达成一致，才允许连接。
它只解决了一件事：
不一样的东西，怎样可以互通。
这比“统一所有东西”更难。
也更有品味。
1984 年，Saltzer、Reed 和 Clark 在 End-to-End Principle 的论文中，把类似的判断说得极其准确：系统设计者最重要的工作之一，是选择功能之间合适的边界。有些能力即使被塞到低层，应用程序最终仍得自己检查；那么，把它完整压到低层，可能昂贵、重复，而且依然不够。
所以，成熟的品味不是“把复杂挪走”。
而是：
把判断放在拥有必要信息的那一层。
这句话不仅适用于计算机。
好的编辑知道哪些信息不该丢给读者自己筛。
好的产品经理知道哪些步骤应该由产品承担，而不是让用户记住。
好的管理者知道哪些不确定性该由组织消化，而不是让员工各自扛着。
好的投资者知道哪些波动只是噪声，哪些变化真正改写了结构。
好的品味，本质上是一种高质量的责任分配能力。
05 品味也会失败：不是每一次重划边界都划对了
如果“重新安置复杂性”就是品味，那么所有大胆的新架构都应该成功。
显然不是。
2001 年，Intel 与 HP 推出 Itanium。它基于 EPIC 思路：把“哪些指令可以并行执行”的大量判断，提前交给编译器，而不是像传统处理器那样，更多依靠硬件在运行时动态判断。
这个想法很迷人。
像是让一位编舞师，在演出开始前，就把所有演员的行动安排得井井有条。
但现实是，真正的运行现场会出现缓存延迟、分支变化、内存访问冲突，以及很多编译时根本无法完整预知的信息。
EPIC 的核心特征，正是把挖掘指令级并行性的责任从硬件转移到代码生成器；而这也意味着，编译器必须承担极其困难的预判任务。
Itanium 的意义不在于“它失败了，所以激进架构都不可靠”。
而在于提醒我们：
复杂性不是想放哪里，就能放哪里。
你得先问：这一层，真的拥有做出正确判断所必需的信息吗？
Xanadu 又是另一种失败。
Ted Nelson 在 1960 年代就开始探索超文本，1965 年提出了 “hypertext” 这个词。Xanadu 的愿景比后来的 Web 更宏大：文档互相连接、版本可追溯、引用可保留、作者可获得版权收益，知识可以形成一个持续生长的网络。
它有很多极其超前的洞见。
但它的问题在于，愿景不断膨胀，系统却长期无法变成稳定、可广泛使用、能在真实用户手里接受反馈的产品。1995 年，Wired 将它描述为一段长达三十年的原型、重构与挫败史。
Xanadu 提醒我们：
远见不是品味的充分条件。
如果一种判断不能进入这样的循环：
build → use → fail → revise
它再漂亮，也很难成熟。
品味必须有结算机制。
而现实，就是最严格的结算者。
它会问你：
延迟够不够低？
成本撑不撑得住？
用户会不会用？
迁移能不能完成？
故障来了怎么办？
十年后还有没有人维护？
很多漂亮的判断，都是在这些问题面前才显出真实形状。
06 所以，品味到底怎样练成？
没有一门“品味课”。
也不能靠收藏更多金句。
品味不是被灌进去的。
它更像是在一套足够真实的循环里，慢慢长出来的。
你需要见过真正好的东西。
不是为了模仿它的表面，而是为了建立标尺。你得知道，一个好的产品、系统、组织或作品，究竟好在哪里。
你需要进入真实的系统。
维护一套别人留下的成熟系统，才会明白很多看起来笨重的设计为何仍然活着。
从零做一个东西，才会知道哪些复杂性是后来被自己一点点加上去的。
把一个东西运行很久，才会承认哪些复杂性根本删不掉。
跨一次范式，从后端走向 AI，从研究走向生产，从模型走向系统，从软件走向硬件，才会发现：一个领域里的“自然规律”，在另一个领域里往往只是历史习惯。
你还需要保留一些暂时没有答案的异常。
可以建一个文档，叫《哪里不对》。
每天只记一两条：
为什么这个 AI 功能一定要做成聊天框？
为什么这个错误必须由用户自己发现？
为什么团队要复制三遍数据？
为什么这个流程里，人明明没有提供新信息，却必须点击一次确认？
不急着回答。
最重要的是，别让异常被“这就是行业惯例”轻易抹掉。
然后，定期做一次更难的练习：
现在每一份复杂性，到底是谁在承担？
是用户？
是应用程序？
是模型？
是工程师？
是运营？
是组织？
还是某个永远没有被写进流程的人？
最后，再问一句：
它真的应该在那里吗？
很多昂贵的错误，不是实现错误。
是前提错误。
不是代码写错了。
而是一开始就把一个历史习惯，当成了不可动摇的事实。
07 品味，是不肯被旧答案驯化的能力
我们常把品味说得很轻。
像穿衣好看，选书准确，审美在线。
但更深一点看，品味并不是“知道什么美”。
它是在许多都说得通的可能性里，逐渐知道什么值得留下。
它不是天生的傲慢。
而是在见过足够多可能性之后，仍然愿意进入现实；在约束、失败、代价和后果面前，一次次修正自己的判断；又不因此麻木，不把那些不合理的东西当成“本来如此”。
久而久之，一个人开始知道：
什么是本质；
什么只是历史留下来的样子；
什么复杂性可以删除；
什么复杂性无法删除，却应由另一个人、另一层系统承担。
等这些判断被现实结算过足够多次，我们把它叫作品味。
所以，上一篇文章我这样定义：
感知复杂中的异常，再把复杂放对地方。
而品味真正最难练成的部分，是前半句：
别人已经习惯的复杂，你为什么还会觉得它不对？
>/作者：王零壹，920.org.cn（AI Research Institute）创始人，港大AIBT研究生，前上市公司 CMO。长期研究 AI 产品、Agent 架构与商业增长，并持续观察技术变迁如何重塑人的工作、判断与生活。
*著有《AIGC从0到1》系列丛书、及东方寓言小说《飞将军》；
*善于洞察先机，中文互联网第1个意识到OpenClaw范式价值的人（1月26日）；
关注我，一起AIGC从0到1~
