EP05 搭好了扩展系统——能力合约让核心不再胖。接下来的问题是：有了扩展架子，它能解决什么真实问题？
第一个答案来自教育工具的前端重构。重构后跑了一次标准审查——安全、后端、前端三个审查者全部 PASS。代码没有 bug，逻辑正确，测试全绿。
我自己打开页面看了一眼，觉得哪里不对但说不出来。截图放大比对之后找到了：新组件用的蓝色和原设计系统的蓝色相差 7 度色相。在小屏上几乎看不出来。但在大屏上，偏移累积，整个界面的调性不统一——像是两个不同的人画的。7 度色相偏移不只是视觉问题——它是品牌一致性（brand consistency）问题。用户可能说不出具体哪里不对，但他们的潜意识会注意到：这个产品的视觉语言不统一，像是拼凑出来的。信任是通过一致性建立的，而一致性的崩塌往往从这种”差一点点”开始。
bg-blue-600 和 bg-blue-700 在代码里差一个数字。在屏幕上差 7 度色相。安全审查者不看 CSS class name 的色号选择，后端审查者不看前端渲染效果，前端审查者看的是组件逻辑和响应式布局——没有人的职责包括”对比渲染结果和设计系统的色值”。
代码审查有一个结构性盲区：审查者读代码，不看渲染结果。
EP01 的 Tailwind 默认样式让产品像管理后台（admin dashboard）的问题，也是我自己看到才修的。EP03 加了怀疑者（skeptic-owner）解决方向盲区，但 skeptic-owner 也不看颜色——它关心的是”方向对不对”，不是”蓝色对不对”。需要一种新的审查能力，而且这个能力不能靠人眼——我不可能每次 commit 都全屏打开所有页面做肉眼比对。
Design Intelligence 的三层架构
Design Intelligence（DI）是 EP05 扩展系统的第一个重型应用。它不是一个通用的”看看设计好不好”的工具——它分三层，每一层解决一类特定的设计审查问题。
第一层：调色板护栏（palette guardrail）。 机械检查，不用大语言模型。
第二层：AI 嗅探器（AI smell detector）。 28 个具体的检测器，每个检查一种设计反模式。
第三层：参考层（reference layer）。 把生成器（generator）的设计知识提取成可查阅的文档。
三层由浅入深：第一层是数数（颜色在不在允许范围内），第二层是模式匹配（这个组合是不是反模式），第三层是知识沉淀（为什么某个设计决策是对的）。
为什么分三层而不是直接用一个大语言模型端到端地”看看设计有没有问题”？因为三类问题的置信度不同。颜色在不在白名单里，答案是确定的，置信度 100%。间距是不是反模式，需要上下文判断，置信度 80-90%。设计决策为什么是对的，涉及审美偏好，置信度更低。把高置信度的检查和低置信度的判断混在一起，只会让整个系统的可信度降到最低那层——这是 S1 就学到的教训：能数数的事别用判断，能用规则的事别用模型。
调色板护栏
设计系统的颜色不是随意选的——从基础调色板（palette）到语义色（semantic）到组件色（component）到动效色（motion），四层令牌（token）层级，每一层都有明确的映射关系。primary-500 是什么颜色、danger 映射到哪个 palette 色值、按钮的 hover 状态偏移多少——这些都是确定的规则。
调色板护栏做的事很简单：扫描项目的所有颜色值，和设计系统注册的色值做比对。如果一个颜色不在 palette 注册的范围内，标记违规。
不用大语言模型判断”这个蓝好不好看”——机械比较就够。这和 S1E07 机械门禁的哲学一脉相承：数数，不做判断。 色值在不在允许范围内是事实问题，不是审美问题。
护栏的有效性取决于设计系统自身的完备度。如果 palette 定义了 200 个色值但实际只用 30 个，白名单太宽松，偏移后的色值可能仍然”合法”。如果定义得太严格，每次新增组件都会触发误报，开发者会开始绕过检查。教育工具的设计系统有 47 个注册色值，覆盖了基础色、语义色和组件色三个层级——粒度刚好，既不会漏过 7 度偏移，也不会误报正常的色值变体。
实现上，DI 在启动钩子阶段扫描项目的 CSS 变量、Tailwind 配置、设计令牌文件，构建出一份”这个项目允许使用哪些颜色”的白名单。审查阶段逐文件检查，发现不在白名单里的色值就报告。前端审查者看不到这一层——他们看的是组件逻辑，不是色值合规。
如果教育工具那次重构时 DI 已经在线，7 度色相偏移会在审查阶段被机械捕获——因为偏移后的色值不在设计系统的 palette 里。这不需要任何智能判断，只需要一张表和一次比对。
28 个 AI 嗅探器
调色板护栏解决了”颜色对不对”，但设计问题不只是颜色。间距不一致、字体层级混乱、对比度不足、动画时长异常、组件密度不均——这些问题没法用机械比对解决，因为它们不是”对不对”的问题，而是”这个组合好不好”的模式识别问题。
DI 的第二层是 28 个具体的 AI 嗅探器，每个检查一种特定的设计反模式（anti-pattern）。不是”用大语言模型看看整体感觉”——是 28 条独立的检查规则，每条有明确的触发条件和修复建议。
几个例子：
对比度检测：文字和背景的对比度是否满足 WCAG（Web 内容无障碍指南）AA 级别（4.5:1）。EP01 的无障碍墙就是这类问题——Apple 风格的 rgba(60,60,67,0.36) 对比度只有 1.7:1。机械工具（axe-core）在半透明叠加时算不准，DI 用视觉语言模型看渲染结果来判断。
间距一致性检测：同一层级的元素之间，间距是否遵循 4 像素栅格（4pt grid）。写代码时很容易一个地方用 p-4 另一个地方用 p-5——差 4px，肉眼不明显，但整体视觉节奏会断。人眼对节奏的敏感度远高于对绝对数值的敏感度——你分不出 12px 和 14px，但你能感到”这里有点不对”。嗅探器要捕获的正是这种模式。
字体层级检测：标题-副标题-正文的字号和行高关系是否保持一致。写代码时开发者倾向于随手写一个 text-xl，而不是去查设计系统定义的标题层级。积累下来，页面上的字号变成随机分布。嗅探器检测的不是单个字号对不对，而是整个页面的字号集合是否形成了合理的递进。
组件密度检测：一个区域内的交互元素是否过于密集。在移动端尤其重要——按钮之间太近会导致误触。
每个嗅探器独立运行，独立报告。一个嗅探器的误判不会影响其他嗅探器的结果。这种设计来自 EP05 熔断器的教训——一个坏的扩展不应该拖死整条流水线，同理，一个不准的嗅探器不应该污染整个设计审查。
参考层：把 generator 的知识变成文档
DI 的前两层解决的是”检查”——发现问题。第三层解决的是一个更深层的问题：设计知识锁死在生成器代码里。
OPC 有一个演示（demo）生成器——generate-demos.py，3766 行。它知道怎么生成好看的演示页面：用什么配色、怎么排版、哪些组件组合在一起效果好。但这些知识全部以 if-else 和模板字符串的形式存在于代码中。
如果换一个编码智能体（coding agent）来生成 demo，它不知道这些规则。它会用自己训练数据里的默认选择——和 EP01 的日历网格是同一个问题。
参考层的做法是：把生成器的隐式知识提取成显式文档，放在 references/ 目录下。文档格式是结构化的：每条设计规则有 what（规则内容）、why（为什么这么做）、example（正确和错误的示例）、enforce（怎么机械检查）。
这不是写设计规范——设计规范描述”应该怎么做”。参考层描述的是”生成器为什么这么做”——它背后的推理过程。当一个新的 coding agent 需要做类似的 demo 生成时，它可以查阅参考层，而不是重新发明那些 3766 行代码里已经沉淀的设计判断。
文档的四字段结构——what/why/example/enforce——不是随意选的。what 和 example 解决”做什么”，大多数设计规范到这里就停了。但 agent 需要的是 why——如果不理解推理过程，它会在稍有不同的场景下做出错误的类比。enforce 字段更关键：它把每条设计规则连接回第一层和第二层的机械检查，形成闭环。一条规则如果没法 enforce，说明它要么太模糊需要拆分，要么太主观不该放在参考层里。enforce 字段是参考层的质量过滤器。
参考层的局限很明显：它只记录了我自己（以及帮我生成 demo 的那个 agent）的设计偏好，不是通用的设计准则。如果另一个人有不同的审美取向，参考层需要重写。这是单人工具的固有约束——工具承载的是一个人的判断标准，不是行业标准。
DI 作为扩展系统的压力测试
DI 是 EP05 扩展系统的第一个重型用户。它同时使用三种钩子：启动钩子扫描设计系统配置、分发钩子注入设计评分标准给审查者、执行钩子跑视觉语言模型做截图比对。跨六个内部模块协作，还依赖外部的 Python 视觉语言模型。
写 DI 的过程暴露了能力合约的第一个边界：当一个扩展足够复杂时，它本身就需要内部模块化。 EP05 的扩展系统解决了核心和领域逻辑的分离，但没有解决领域逻辑内部的复杂度。DI 的 6 个内部模块之间的依赖关系，和 EP05 之前核心代码的意大利面问题是同构的——只是把复杂度从核心推到了扩展里。
解决方案不优雅但有效：DI 内部用文件夹分离模块，模块之间通过明确的函数签名调用，每个模块有独立的测试。不是框架级别的解耦——是工程纪律级别的。对一个人的工具来说，纪律够用的时候不需要架构。
这也暴露了扩展系统设计时的一个假设偏差：EP05 设计能力合约时，假设每个扩展是一个相对独立的功能单元——像一个插件。但 DI 证明真实的领域问题不会这么干净。调色板护栏需要读取设计系统配置（启动钩子的产物），嗅探器需要调色板护栏的白名单作为输入，参考层需要两者的检查结果来决定哪些规则需要更新。三层之间有数据依赖，不是三个独立的插件。扩展系统提供的是”核心和扩展之间”的合约，没有提供”扩展内部模块之间”的合约——这是下一个需要解决的问题，但不是现在。
设计不是纯主观的
这一集的核心发现：设计审查有一部分是可以机械化的。
颜色在不在调色板范围内——事实判断。对比度够不够——数值计算。间距是否一致——模式匹配。字体层级是否混乱——规则检查。这些都不需要审美判断，只需要规则和比对。
这意味着设计审查可以分成两个不相交的集合：有确定性答案的检查项（mechanical check），和需要人类判断的审美项（aesthetic judgment）。DI 处理第一个集合，把人的注意力释放给第二个集合。这和 EP03 的 skeptic-owner 是同一个思路——不是要取代人的判断，而是让机器先过滤掉所有不需要判断的问题，让人只处理真正需要人来决定的东西。审查的瓶颈从来不是”人不够多”，而是”人把有限的注意力花在了不需要人的事情上”。
当然，设计中确实有主观的部分——配色的情绪感、排版的节奏感、整体的调性。DI 不碰这些。调色板护栏和嗅探器解决的是”底线”问题：不一定能保证好看，但能保证不犯确定性的错误。
EP03 加了第十人看方向，EP05 加了扩展系统解耦框架，这一集给了工具一双看设计的眼睛。三次升级，三个不同的盲区——方向、架构、视觉。产品继续暴露短板，短板继续驱动工具进化。
三个审查者读了同一份代码，都说”没问题”。没有一个打开浏览器看一眼。
硅基团队 S2: 在实战中进化工具链 ← S2E05: 每做一个新产品，核心就胖一圈 | S2E07: 看不到过程，就没法信结果 →