技术栈感知设计规则

概述

技术栈感知设计规则是一种将同一设计决策按不同技术栈细化为具体实现模式的知识编码方式：相同的「圆角卡片 hover 效果」在 React、SwiftUI、Flutter、Compose 中有完全不同的惯用写法，统一的视觉规范需要分栈落地。

关键内容

核心动机

设计决策与实现路径的分离带来了跨栈不一致问题：

设计决策：圆角卡片 hover 效果
├── HTML+Tailwind: class="hover:shadow-lg transition-shadow duration-200"
├── React+CSS:     useSpring hook + to={{ boxShadow: '...' }}
├── SwiftUI:       .onHover { } + .animation(.easeInOut)
├── Flutter:       AnimatedContainer + BoxDecoration
└── Jetpack Compose: animateFloatAsState + Card(elevation)

15 个技术栈的典型规则示例

React 栈独有规则： - react-component-state-ui — hover/focus 用 CSS 而非 useState（避免不必要的 re-render） - react-key-prop-lists — 列表 key 必须是稳定唯一值（非 index），影响动画性能 - virtualization-large-lists — > 100 条必须虚拟化（react-window）

Next.js 栈独有规则： - image-component-priority — <Image> 首屏图片加 priority（影响 LCP） - font-optimization-next — 用 next/font 而非直接引 Google Fonts（消除字体加载位移）

SwiftUI 栈独有规则： - system-symbols-preferred — 优先 SF Symbols（系统一致性） - adaptive-colors-system — 用 .primary 等系统自适应色，自动支持 Dark Mode

Flutter 栈独有规则： - sliver-for-scroll — 复杂滚动用 Sliver，非嵌套 SingleChildScrollView - hero-animation-tag — 路由共享元素过渡用 Hero + 唯一 tag

Astro 栈独有规则： - islands-architecture-hydration — 仅对需要交互的组件设置 client:* 指令（client:visible 推荐用于折叠下内容） - view-transitions-api — 内置 <ViewTransitions /> 实现页面间平滑过渡

BM25 搜索引擎的技术选型

UUPM 选择 BM25 而非向量搜索，在 Skill 场景下的务实权衡：

维度	BM25	向量搜索
依赖	纯 Python 标准库	需要模型（几百 MB）
速度	毫秒级	取决于模型大小
离线支持	完全离线	通常需要 API
可解释性	词频匹配，可调试	黑盒
知识库更新	改 CSV 即可	需重新嵌入

关键判断：技术术语（Glassmorphism、Tailwind）BM25 已能精确匹配，「零依赖 + 离线可用 + 可解释」比语义精度更重要。

模板生成 vs 多份副本

18 个平台的代码只需维护一份源（src/ui-ux-pro-max/data/），通过 template.ts 运行时生成平台文件：

维护成本: O(1) 而非 O(n=18)
包体积:   ~564KB（v2.1）而非 ~34MB（多份副本时）

来源

raw/articles/ai-tools/claude-skills/blog-06-stacks-search.md