Appearance
模块 2：编码层次
The gap between "I know good when I see it" and "here is how to make it good" is where most taste dies. Encoding is the bridge.
学习目标
完成本模块后，你将：
- 理解品味编码的核心挑战：如何在不丧失品味本身的情况下让品味可传递
- 掌握品味编码的五个层次——直觉、原则、指南、规则、自动化——及其各自的特征与局限
- 分析 Christopher Alexander 的 Pattern Language 如何开创了品味编码的方法论
- 评估 Apple HIG、Material Design、Stripe 设计原则等真实编码案例的层次和效果
- 理解编码的核心悖论：精确度越高，创造力空间越小
一、为什么品味需要编码
品味的传递困境
上一模块讨论了品味领导力——通过一个人（或少数人）的品味判断来维持组织的品味标准。但品味领导力有一个根本局限：它不可扩展。一个人每天能做出的品味判断数量是有限的。当组织规模从 10 人增长到 100 人、1000 人、10000 人时，品味领导者不可能参与每一个决策。
这就是品味编码的必要性所在。编码是把品味判断转化为可被他人理解和执行的外部形式的过程。 编码不是要取代品味判断——而是要让品味判断在没有品味领导者在场时仍然能够发生。
但编码是危险的。品味判断的本质是语境敏感的、整体性的、常常是非言语的——它抵抗被分解为离散的规则。每一次编码都是一次简化，每一次简化都可能丢失品味中最微妙、最有价值的部分。
这就是品味编码的核心悖论：你必须编码品味才能传递它，但编码品味的过程本身可能损害它。
编码的先驱：Christopher Alexander
理解品味编码的最好起点不是设计行业，而是建筑学。Christopher Alexander（1936-2022）在 1977 年出版了 A Pattern Language: Towns, Buildings, Construction，这本书试图做一件前所未有的事：将"什么使一个地方让人感觉好"的品味知识编码为 253 个可重用的模式。
每个模式都有固定的结构：
| 元素 | 功能 | 示例（Pattern #159 "Light on Two Sides"） |
|---|---|---|
| 模式名称 | 给品味判断一个可引用的名字 | "Light on Two Sides of Every Room" |
| 问题陈述 | 描述这个模式要解决什么问题 | "When they have a choice, people will always gravitate to those rooms which have light on two sides" |
| 解决方案 | 具体的建议 | "Locate each room so that it has outdoor space outside it on at least two sides" |
| 图解 | 视觉化的空间关系 | 房间与窗户的位置示意图 |
| 关联模式 | 与其他模式的关系 | 关联 Pattern #107 "Wings of Light"、Pattern #180 "Window Place" |
Alexander 的天才不在于单个模式——很多模式表达的是建筑师早已知道的直觉判断。他的天才在于编码的结构和互联性。253 个模式不是彼此独立的清单——它们通过交叉引用构成了一个网络，从城市规模（Pattern #1 "Independent Regions"）到建筑细节（Pattern #249 "Ornament"），层层递进。
"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice." — Christopher Alexander, A Pattern Language, 1977
这最后一句话是品味编码的核心哲学：好的编码不是规定一个固定答案，而是描述一个可以被无限次不同地实现的原则。
Alexander 对后世的影响是巨大的。Ward Cunningham 和 Kent Beck 在 1987 年将 Pattern Language 的思想引入软件工程，催生了设计模式运动（最终产出了 GoF 的 Design Patterns 一书，1994）。但鲜少有人注意到，Alexander 的品味编码方法论对设计行业的影响同样深远——设计系统（Design Systems）的整个概念框架，本质上是 Pattern Language 在数字产品领域的继承。
Alexander 的遗憾
Alexander 晚年对软件行业对他的"模式语言"的接受方式深感不满。他在 1996 年的 OOPSLA 大会上说：
"I am not so sure that what you are doing with patterns in software is what I was doing with patterns in architecture... The patterns are not just a way of organizing code. They are about making things that are alive."
他认为软件工程师只借用了他的结构（命名的、结构化的、可重用的解决方案模板），却丢失了他的品味内核——他所有模式的目标不是效率或一致性，而是创造让人感到"alive"（有生命力）的环境。
这个批评对品味编码有深刻的启示：编码的形式（模板、规则、系统）容易被复制，编码的精神（品味判断的敏感性和整体性）极难被传递。 这个张力贯穿本模块的全部讨论。
二、品味编码的五个层次
品味可以被编码到不同的精确度和形式化程度。以下是一个从最不正式到最正式的五层模型：
层次一：直觉（Intuition）
特征： 品味判断存在于个人的感知和判断中，没有被外部化。
表现形式： "I'll know it when I see it"、"这个不够好但我说不清为什么"、"再试试"。
优势： 最灵活、最语境敏感——直觉能处理规则无法覆盖的情况。直觉品味判断是整体性的：它同时考虑了所有维度（视觉、功能、情绪、文化），而不是逐条检查清单。
局限： 完全不可传递——只有品味持有者本人能做出判断。不可扩展、不可追溯、不可挑战（因为没有显性的判断依据）。
适用场景： 极早期阶段（只有创始人一个人在做产品决策）；极高层决策（品味领导者做最终裁定时）。
典型案例： Steve Jobs 在 iPhone 开发早期对原型的判断——他不需要解释为什么某个方向是对的，他的直觉判断就是产品方向。
层次二：原则（Principles）
特征： 品味判断被提炼为少数高层次的价值声明，指明方向但不规定细节。
表现形式： "我们追求简洁而非简单"、"功能决定形式"、"用户不需要知道复杂性存在"。
优势： 方向清晰但留有诠释空间。好的原则像指南针——它告诉你北在哪里，但不规定你走哪条路。原则可以被记忆和传播，成为团队的共同语言。
局限： 原则本身可能过于模糊以至于失去指导力。"我们重视简洁"——但什么算简洁？在每个具体决策中，仍然需要判断力来将原则转化为行动。
经典案例：
Dieter Rams 的十条设计原则（约 1970s，正式发表于 1995 年）：
Rams 在 Braun 工作期间提炼出的十条原则（Good design is innovative / Good design makes a product useful / Good design is aesthetic / Good design makes a product understandable / Good design is unobtrusive / Good design is honest / Good design is long-lasting / Good design is thorough down to the last detail / Good design is environmentally friendly / Good design is as little design as possible）至今仍被引用。它们的力量在于：
- 数量适当——十条足够覆盖核心价值，但不多到记不住
- 层次递进——从功能性（useful, understandable）到美学性（aesthetic, unobtrusive）到伦理性（honest, environmentally friendly）
- 可判断性——面对一个设计决策时，你可以逐条对照："这个选择是否让产品更易理解？"
Stripe 的设计原则：
Stripe 的设计团队在内部维护着一组设计原则（部分公开于 Stripe Sessions 演讲和团队成员博客）。其中一条核心原则是 "Be opinionated, then flexible"——先给出一个有立场的默认方案，然后允许自定义。这条原则编码了 Stripe 产品品味的核心：不是提供无立场的工具包，而是提供有品味的默认体验。
层次三：指南（Guidelines）
特征： 品味判断被编码为具体的建议和最佳实践，说明"在特定情况下应该怎么做"，但允许例外。
表现形式： "标题字号应为正文的 1.5-2 倍"、"主操作按钮使用品牌色，次操作使用中性色"、"段落长度不超过 4 行以保持可读性"。
优势： 具体到可以直接指导执行——一个初级设计师读了指南就知道大致方向。比原则更有操作性，比规则更灵活。
局限： 覆盖不完全——指南无法预见所有情况。当指南之间冲突时（"保持简洁" vs "提供足够的信息"），需要更高层次的判断来裁定。
经典案例：
Apple Human Interface Guidelines (HIG)：
Apple HIG 是品味编码最成功的案例之一。从 1987 年第一版（针对 Macintosh）到现在的多平台版本，HIG 持续将 Apple 的交互品味编码为指南。它的有效性在于几个设计选择：
- 以场景而非组件组织——不是"按钮应该怎么做"，而是"当用户需要做一个不可逆的决定时，应该怎么做"
- 解释"为什么"而不只是"怎么做"——每条指南都附带设计原理的解释，让读者理解品味逻辑
- 持续更新——HIG 随着每个新 OS 版本更新，反映了 Apple 的品味演化
但 HIG 也展示了指南层编码的局限：它能告诉你 Apple 风格的交互应该是什么样的，但它不能告诉你何时应该打破这些指南。最好的 iOS App（如 Things 3、Apollo——后者已停止运营但设计影响深远）都在遵循 HIG 的同时做出了有品味的偏离。
层次四：规则（Rules）
特征： 品味判断被编码为明确的、无需判断即可执行的规定——"总是这样做"或"从不这样做"。
表现形式： "所有图标使用 24x24dp 网格"、"主色为 #1A73E8，误差不超过 5%"、"按钮圆角半径为 8px"。
优势： 完全一致性——不同人、不同时间执行的结果相同。可以被自动化检查（lint 工具）。消除了判断负担——执行者不需要做品味决策。
局限： 规则是品味编码中最危险的层次。它假设品味可以被完全形式化——但品味的核心恰恰是在规则无法覆盖的灰色地带做出好的判断。过度依赖规则会导致两种失败：
- 创造力窒息——当一切都被规定，设计师没有空间做出有品味的创新
- 品味异化——遵守所有规则的设计可能仍然缺乏品味，因为品味不只是规则的集合
案例：品牌规范手册
大多数企业品牌规范手册（Brand Guidelines）主要在规则层运作：精确的 logo 使用规范、色彩代码、字体规定、间距要求。这在确保品牌视觉一致性上非常有效——但它不能确保品牌传播具有品味。你可以完全遵守可口可乐的品牌规范手册，做出一个技术上"合规"但品味上平庸的广告。
层次五：自动化（Automation）
特征： 品味判断被编码为代码或工具，自动执行而无需人类干预。
表现形式： 设计 token 系统、Figma 自动布局约束、CSS 变量、代码中的 lint 规则、AI 辅助的设计审查工具。
优势： 完全消除执行偏差——不可能"忘记"或"偷懒"。在规模化场景中极其高效。
局限： 自动化编码只能处理可形式化的品味维度。"间距是否正确"可以自动化，"这个界面是否给人温暖的感觉"不能。自动化还有一个隐性风险：它让品味变得不可见。当品味决策被嵌入代码和工具中，使用者可能完全不知道品味判断正在被执行——也因此无法学习品味判断本身。
案例：Design Tokens
Design Tokens（设计令牌）是当前品味自动化编码的主要形式。一个 token 系统可能包含：
--color-primary: #1A73E8;
--spacing-md: 16px;
--radius-sm: 4px;
--font-body: 'Inter', sans-serif;
--shadow-card: 0 1px 3px rgba(0,0,0,0.12);每一个 token 都是一次品味判断的固化。--shadow-card 的值不是随机的——有人决定了卡片的阴影应该是微妙的（1px 偏移、3px 模糊、12% 透明度），而不是夸张的。这个品味判断现在被自动应用到系统中的每一个卡片组件上。
三、编码的核心悖论：精确度 vs 创造力
品味编码的频谱
五个层次不是简单的"越高越好"——它们构成了一个频谱，每个位置都有特定的权衡：
| 维度 | 直觉 | 原则 | 指南 | 规则 | 自动化 |
|---|---|---|---|---|---|
| 精确度 | 最低 | 低 | 中 | 高 | 最高 |
| 创造力空间 | 最大 | 大 | 中 | 小 | 最小 |
| 一致性 | 依赖个人 | 依赖诠释 | 较高 | 极高 | 完全一致 |
| 可扩展性 | 不可扩展 | 有限 | 较好 | 好 | 最好 |
| 品味传递效果 | 无 | 方向感 | 判断框架 | 执行规范 | 无需传递 |
| 适应新情况 | 最强 | 强 | 中 | 弱 | 最弱 |
核心悖论： 编码越精确，一致性越高但创造力空间越小；编码越模糊，创造力空间越大但一致性越低。没有一个"完美"的编码层次——选择在频谱的哪个位置编码，本身就是一个品味决策。
Material Design vs Apple HIG：两种编码策略
Google 的 Material Design（2014 年发布，由 Matias Duarte 主导）和 Apple 的 Human Interface Guidelines 代表了品味编码频谱上的两个不同位置：
Material Design 偏向"规则"端
Material Design 提供了极其具体的规范——间距使用 8dp 网格、动画使用特定的缓动曲线、海拔（elevation）有精确的阴影规则。它的目标是让任何遵循规范的 App 都能达到一个基准品味水平——即使开发者没有设计背景。
这种编码策略的成功在于它解决了 Android 生态系统的核心问题：数千个没有设计资源的开发者需要一个可直接执行的品味框架。Material Design 的规则化编码使得"还过得去"的 Android App 品质显著提升。
但代价是创造力的压缩。Material Design 最严格的时期（2014-2017），遵循它的 App 看起来都差不多——统一的 floating action button、统一的 toolbar 行为、统一的卡片阴影。品味编码在确保一致性的同时消灭了差异性。
Apple HIG 偏向"指南"端
Apple HIG 的编码更多在指南层：它描述原则和建议，但很少给出像 "8dp grid" 这样的硬性数字规范。它说"navigation should feel natural and predictable"而不是"navigation bar height is exactly 44pt"（尽管 44pt 确实是推荐值，但它更多以"推荐"而非"规定"的形式出现）。
这种编码策略假设执行者有一定的品味判断能力——它不是给你一套规则让你照做，而是给你一个框架让你在其中做出自己的判断。结果是 iOS App 的品味分化更大：最好的（如 Things 3 由 Cultured Code 开发、Halide 由 Lux Optics 开发）远好于平均水平，但最差的也远差于 Material Design 的平均水平。
频谱选择的决定因素
选择在哪个层次编码品味，取决于几个关键因素：
1. 执行者的品味能力
- 执行者品味能力强 → 编码可以偏向原则/指南层，给他们空间
- 执行者品味能力弱 → 编码需要偏向规则/自动化层，确保基准品质
2. 品味一致性的重要性
- 品牌一致性至关重要（如企业品牌应用） → 偏向规则/自动化
- 创新和差异化至关重要（如创意产品） → 偏向原则/指南
3. 组织规模
- 小团队（<20 人） → 直觉 + 原则通常足够
- 中等团队（20-200 人） → 需要指南层编码
- 大型组织（200+ 人） → 需要规则和自动化层编码
4. 变化速度
- 品味标准稳定 → 规则化编码的成本可以被长期使用摊薄
- 品味标准快速演化 → 过度规则化的编码更新成本高昂
四、编码实践：从品味判断到外部化形式
品味编码的工作流程
将一个品味判断编码为可传递的形式，不是一次性的翻译，而是一个迭代过程：
步骤一：识别品味判断
首先需要将隐性的品味判断显性化。这通常发生在品味冲突的时刻——当两个方案都"可以"但一个"更好"时，迫使自己说出"更好"的理由。
实践方法：在设计评审中，当你做出品味判断时，暂停并记录：
- 你做出了什么判断？
- 这个判断基于什么感知维度（视觉平衡、信息层级、情绪调性、文化匹配...）？
- 你能给出反例吗——在什么情况下你会做出相反的判断？
步骤二：测试可迁移性
一个品味判断是否值得编码，取决于它是否可迁移——即它是否在多个不同情境中都有效，而不只是在特定的当前情境中有效。
测试方法：将你的品味判断应用到三个不同的场景中。如果它在至少两个场景中仍然有效，它可能值得编码为原则或指南。如果它只在特定场景中有效，它可能更适合留在直觉层。
步骤三：选择编码层次
根据上一节讨论的四个因素（执行者能力、一致性需求、组织规模、变化速度），决定将品味判断编码到哪个层次。
步骤四：编写并测试
将品味判断转化为选定层次的外部化形式——然后测试：让不知道你原始意图的人阅读你的编码，看他们是否能做出与你一致的品味判断。
如果不一致的发生频率超过 30%，你的编码可能需要降到更精确的层次，或者补充更多的解释和示例。
案例：Stripe 如何编码"清晰"
Stripe 的设计品味中最核心的维度之一是"清晰"（Clarity）。以下是这个品味判断在不同层次的编码方式：
| 层次 | Stripe 的"清晰"编码 |
|---|---|
| 直觉 | Patrick Collison 和 John Collison 审查产品时会直觉性地拒绝"不够清晰"的方案 |
| 原则 | "Clarity over cleverness"——不要为了看起来聪明而牺牲可理解性 |
| 指南 | API 命名指南：使用完整的英文单词而非缩写；端点路径应该自解释（/v1/customers 而非 /v1/cust） |
| 规则 | 文档中代码示例的格式规则：每个示例必须可直接运行、必须展示最常见的用例而非边界情况 |
| 自动化 | API linting 工具自动检查命名一致性、文档完整性 |
注意这个案例中的层次递进：从创始人的直觉品味判断，到团队的品味原则，到具体领域（API 设计）的指南，到可执行的规则，到自动化检查。好的品味编码不是选择一个层次，而是在多个层次上同时编码，形成互补。
五、编码的退化与维护
三种编码退化模式
品味编码不是一劳永逸的——它会随时间退化。理解退化模式有助于预防：
退化模式一：letter over spirit（字面优于精神）
当执行者遵循编码的字面意思但违背了它的品味精神。
例子：Apple HIG 建议使用系统字体以保持一致性。一个 App 在所有地方都使用 San Francisco 字体——但字号选择、行高设置、字重搭配都缺乏层次感。它"遵循了 HIG"，但产出缺乏品味。
原因：通常是因为编码只传递了"做什么"而没有传递"为什么"。当执行者不理解品味逻辑时，他们只能机械地遵守字面规定。
预防：在编码中始终包含品味原理的解释——不只是"怎么做"，而是"为什么这样做体现了我们的品味标准"。
退化模式二：encoding lag（编码滞后）
品味标准已经演化，但编码没有跟上。结果是编码反映的是过去的品味，不是当前的品味。
例子：Material Design 1.0（2014）的设计风格在 2018 年已经显得过时——大面积纯色、浮动操作按钮作为默认交互模式——但大量 App 仍在遵循旧规范，因为更新编码的成本高于继续使用旧编码。直到 Material Design 3（2021，又称 Material You）才做了根本性更新。
原因：编码越正式（规则、自动化层），更新的成本越高。一个 design token 系统的更新可能涉及数百个组件和数千行代码。
预防：在设计编码时就预留更新机制——版本号、变更日志、定期评审周期。
退化模式三：cargo cult encoding（货物崇拜编码）
复制了成功组织的品味编码形式，但没有理解其背后的品味逻辑。
例子：无数公司在 2015 年后模仿 Stripe 的设计风格——渐变色、大量留白、极简文案——但产出看起来只是"像 Stripe"而不是"好"。他们复制了 Stripe 的编码输出，但没有经历 Stripe 的品味思考过程。
原因：这是人类学习的自然倾向——模仿可见的结果比理解不可见的过程容易得多。
预防：在建立自己的品味编码时，始终从自己的品味判断出发，而不是从他人的编码输出出发。你可以参考 Stripe 的编码结构，但内容必须来自你自己的品味。
编码维护的实践
成功的品味编码系统需要持续维护：
定期品味审查（Taste Audit）
每季度（或至少每半年）对品味编码进行审查：
- 编码是否仍然反映当前的品味标准？
- 有哪些新的品味判断尚未被编码？
- 有哪些编码条目已经不再相关或已经过时？
- 执行者在遵循编码时遇到了哪些困难或困惑？
编码变更日志
像管理代码版本一样管理品味编码的版本。每次更新都记录：
- 什么改变了
- 为什么改变
- 这个改变反映了品味标准的什么演化
Material Design 的公开更新日志是一个好的参考——它不只是列出变化，还解释了变化背后的设计理由。
设计系统/API 设计
Stripe 的品味编码层次
问题：Stripe 被广泛认为是 API 设计品味的标杆。分析 Stripe 在 API 设计领域的品味编码：它在哪些维度使用了哪些编码层次？这种编码策略为什么有效？你能识别它的局限吗？
分析：Stripe 的 API 品味编码是一个多层次的成功案例。在原则层：'Clarity over cleverness' 设定了整体方向。在指南层：API 命名约定、错误信息格式、分页设计模式。在规则层：REST 端点的 URL 结构规范、版本号格式。在自动化层：API linting、文档自动生成、示例代码自动测试。这种多层编码的有效性在于：(1) 原则层给予设计者方向感而非束缚；(2) 指南层在最常见的决策点提供具体指导；(3) 规则和自动化层确保一致性，减少低级品味偏差。局限在于：Stripe 的品味编码主要覆盖了'技术优雅'和'清晰度'维度，但在'温暖度'和'人情味'维度的编码较弱——这也是为什么 Stripe 的文档被认为极其清晰但有时'冰冷'。
品味编码层次判断
以下是不同组织的品味编码实例。判断每个实例所处的编码层次，然后查看分析。
样本 A
样本 B
样本 C
样本 D
样本 E
编码策略对比：Material Design vs Apple HIG
Material Design 的规则化策略
Material Design 提供精确的数值规范（8dp 网格、特定的阴影值、定义好的动画曲线）和详尽的组件规格。目标是让没有设计背景的开发者也能产出一致且基准品质以上的界面。代价是高度同质化——遵循 Material Design 的 App 看起来非常相似。
Apple HIG 的指南化策略
Apple HIG 提供原则性的建议和推荐值，但更强调设计理念的理解。目标是让有设计能力的开发者在一致的框架内做出有个性的产品。代价是品质分化——最好的 iOS App 远好于最好的 Material Design App，但最差的也远差于平均水平。
Tailwind CSS 的 Token 化策略
Tailwind CSS（Adam Wathan, 2017）通过预定义的设计 token（颜色阶梯、间距阶梯、字号阶梯）将品味约束嵌入工具层。开发者不需要做像素级决策——他们从预定义的选项中选择。这是一种有限选择集的编码策略：不是告诉你怎么做，而是限制你能做什么。
思考：如果你要为一个 100 人的产品团队选择品味编码策略，你会更倾向于 Material Design 的规则化、Apple HIG 的指南化、还是 Tailwind 的 token 化？你的选择取决于什么因素？
品味编码实践
30-40 minutes选择一个你熟悉的品味维度（视觉设计、写作风格、产品交互、空间氛围...），尝试将你在这个维度上的品味判断编码为五个层次中的至少三个。然后反思：在编码过程中你丢失了什么？你的编码是否足以让一个不了解你品味的人做出与你一致的判断？
建议结构：
品味领域选择~10%
选择一个你有强烈品味偏好的具体领域。越具体越好——不是视觉设计而是数据可视化的配色或产品文案的语气。
直觉/原则层编码~20%
先捕捉你的直觉品味判断——你会说什么来描述你认为好的标准？然后提炼为 2-3 条原则。
指南/规则层编码~30%
将原则转化为具体的指南或规则。尽量给出可执行的建议、示例、反例。
编码损失分析~20%
在编码过程中，你感到哪些品味判断无法被编码？编码后的版本与你的原始品味直觉之间的差距在哪里？
可传递性测试~20%
想象一个完全不了解你品味的人阅读你的编码。他们能做出与你一致的判断吗？你需要补充什么才能缩小差距？
- 选择你真正有品味偏好的领域——如果你对某个维度没有强烈的品味，编码过程会很空洞
- 编码时注意区分品味判断和个人偏好——品味是可以被论证的，偏好只是我喜欢
- 给出具体的正例和反例——抽象的原则如果没有实例锚定就会失去指导力
- 编码损失分析是最重要的部分——诚实面对编码的局限比假装编码完美更有价值
目标：600 字
延伸阅读
必读
Christopher Alexander, A Pattern Language: Towns, Buildings, Construction (1977)
- 不必通读全部 253 个模式——建议选读 10-15 个与你日常环境相关的模式
- 核心价值不在于具体模式，而在于"品味编码"这种方法论本身
- 同时参考 The Timeless Way of Building（1979）以理解 Alexander 的品味哲学
Alla Kholmatova, Design Systems: A Practical Guide to Creating Design Languages (2017)
- 最好的设计系统实践指南之一——从品味编码的角度来读
- 核心章节：Chapter 3 "Design Principles" 和 Chapter 5 "Functional Patterns"
推荐
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software (1994)
- GoF 经典——不是作为编程教材读，而是作为"品味编码如何从建筑学迁移到软件工程"的案例研究
Apple Human Interface Guidelines (持续更新)
- developer.apple.com/design/human-interface-guidelines — 品味指南层编码的最佳参考
Material Design Guidelines (持续更新)
- m3.material.io — 品味规则层编码的最佳参考，与 Apple HIG 对比阅读效果最佳
在线资源
- Design Principles FTW — 收集了数百家公司的设计原则文档，是研究原则层编码的绝佳资源
- Dieter Rams' 10 Principles — Vitsoe 网站上的经典品味原则
本模块要点
- 品味编码是让品味从个人能力变为组织能力的必要步骤——没有编码的品味不可扩展、不可传承
- Alexander 的 Pattern Language 开创了品味编码的方法论——命名的、结构化的、互联的品味知识网络
- 五个编码层次（直觉→原则→指南→规则→自动化）各有权衡——不是越正式越好，而是要根据情境选择合适的层次
- 编码的核心悖论：精确度越高，创造力空间越小——这个悖论无法被"解决"，只能被管理
- 好的品味编码解释"为什么"而不只是"怎么做"——没有品味逻辑的规则会导致 letter over spirit 的退化
- 不同组织需要不同的编码策略——取决于执行者能力、一致性需求、组织规模、变化速度
- 品味编码会退化——字面优于精神、编码滞后、货物崇拜编码是三种常见退化模式
- 多层编码优于单层编码——Stripe 的成功在于同时在原则、指南、规则、自动化四个层次编码
- 编码维护与编码创建同等重要——定期品味审查、变更日志、版本化是必要的维护实践
- 最好的编码留有判断空间——Alexander 说过，好的模式是"可以被无限次不同地实现"的
下一步
品味编码的最成熟形态是设计系统——一整套将品味编码为 token、组件、模式、文档的系统。下一模块深入探讨设计系统的构建：从 Brad Frost 的 Atomic Design 方法论到真实设计系统（Material Design、Apple HIG、Carbon、Primer、Ant Design）的品味比较，从技术架构到治理问题（谁有权修改设计系统？）。如果说本模块回答了"品味能以什么形式被编码"，下一模块回答的是"如何构建一个完整的品味编码系统"。
模块 2 自评
基于你在本模块中的学习和品味编码练习，对自己做一次诚实的评估。
编码层次理解对五层编码模型的理解深度
Alexander 方法论对 Pattern Language 品味编码方法论的理解
编码实践能力将品味判断编码为外部化形式的能力
批判性分析对品味编码案例的批判性分析能力