让不同的搜索结果，说同一种设计语言。

问题从多种搜索结果之间出现。

内容、服务和商业结果有不同的信息结构。如果只追求同一种外形，会损失场景特征；完全独立演进，又会让间距、强调与交互反馈逐渐分裂。共生设计语言（无极）关心的是共享基础如何支持差异。

首位结果需要单独的规则合同

首位结果承担更强的主题识别，也会影响搜索框、页面背景与后续内容的关系。原稿分别规定自有内容、商业专营样式、卡片补充及首位缺失的情况。异常与回退属于系统的一部分。

这比“首位做得更醒目”更具体：用户看到的主题表达需要与实际内容归属一致，后续卡片不能因为一个强样式而失去阅读层级。图中每一种条件对应不同的适用边界。

扩展业务时，明确兼容与退化

地点、品牌、纠错与商业结果不拥有同一种内容结构。原稿在首位与非首位分别讨论扩展，让业务既能表达自身信息，也继续使用共同的基础语言。

当内容条件不足以支撑强样式时，回到基础卡片是有意的退化策略。系统应说明为什么退回、保留什么信息，而不是让每条业务临时发明一种空缺处理。

共同语法保留内容性格

明星、演出与实体信息可以有不同的视觉氛围，用户仍应理解标题、摘要、媒体与操作的关系。图例表明系统如何承载差异，不需要让每个结果看起来完全一样。

评审时应同时核对识别性与可读性：首位是否解释了当前查询，后续内容是否能继续浏览，业务入口是否在同一逻辑中表达。原稿展示设计应用，不单独证明某种样式带来收益。

规范如何被继续查找和维护

最终规范按模板、组件与元素组织，而不是只保留一张大画板。新的业务需求可以先判断属于已有模板组合、组件扩展还是新元素，再决定需要哪一层更新。

原图中的数量属于团队当时的盘点。这里用它说明目录与分层，不把数量写成本人的独立产出，也不称为百度目前的规范版本。

设计语言还需要交付治理

多人、多业务共同使用一套规则时，评审时机、责任人和变更通知同样影响结果。可以公开的方法包括需求前置评审、代表性技术验证、明确变更冻结点，以及记录不同实验之间的覆盖关系。

原复盘中的内部事故与具体经营细节不在个站展示。保留的是下一次可执行的协作方法：先核对能力和覆盖，再扩大迁移范围，而不是把规范交付当成落地完成。

设计语言的交付与复盘

可见成果包括基础语言、首位约束、业务兼容、模板退化与规范维护结构。它们让系统如何支持业务变化可以被逐项检查。

系统设计不只是减少组件数量，而是减少没有必要的差异。清楚地定义哪些部分可以变化，才能让统一不成为业务发展的阻力。