redesign

重新设计

当产品已经存在，并且需要更出色的布局、视觉系统和交互体验时，使用此命令。

默认实现方式

重新设计时默认使用 Tailwind CSS。

• 除非用户明确要求使用其他样式系统，否则所有视觉更新都使用 Tailwind 工具类。
• 保留现有框架和运行时；在可行的情况下，默认将样式设计转向 Tailwind。

UI 库访问

允许使用的参考库：

• UIverse
• FlyonUI（https://flyonui.com/）
• daisyUI

规则：

• 将库作为加速工具，而非整页模板
• 重构并调整库组件，使其符合产品语义和品牌方向
• 避免反复使用任何单一库中的常见模板样式
• 当重复使用组件的风险较高时，搭配自创组件

Pretext 集成

重新设计现有 UI 时，如果存在文本溢出风险或换行不稳定的问题，应使用 @chenglou/pretext 规划文本布局，再确定最终的间距和字号比例。

• 按需安装：npm install @chenglou/pretext
• 使用 prepare() + layout()，在目标宽度下验证关键文本块（主视觉区、卡片、CTA 行、导航标签）。
• 根据测量结果选择更稳妥的宽度限制，减少不同断点下的溢出回归。
• 如果重新设计依赖精准的行距节奏，则使用 prepareWithSegments() + walkLineRanges() 对比不同方案，选出效果最佳的组合。
• 如果项目是纯静态 HTML/CDN，或没有 JS 构建步骤，则跳过 Pretext 集成，改用响应式 CSS 约束处理换行。
• 悄然完成此操作；除非用户要求，否则不要添加面向用户的“关于 Pretext 的说明”等注意事项。

扩展反重复要求（必需）

重新设计不能只是对标准模板进行表面美化。

规则：

1. 在确定设计方向前，针对不同组件和交互类型，先构建一组丰富的候选方案。
2. 用不同类型的组件系列替换重复的卡片结构（数据卡片、叙事区块、对比行、证明信息条、实用工具面板等）。
3. 如果当前 UI 区块较为通用，每次实质性重新设计至少自创 2 个新组件。
4. 如果用户要求动效，至少自创 1 种新动画模式，并将其与用户反馈或视觉层级关联起来。
5. 如果变化仅限于颜色、圆角或字体，则应否决该方案。

重新设计多样性指标（必需）

对于实质性重新设计，必须满足：

1. 页面上至少有 6 种实质不同的区块结构
2. 至少有 3 个以非卡片形式呈现的主要内容模块
3. 至少有 2 个针对该产品场景自创的新组件
4. 任何一种旧版模式所占的区块不得超过 25%

如果重新设计仍然与原布局骨架相似，则应在最终定稿前进一步调整结构。

防止重新设计呈现 AI 模板感的检查（必需）

如果重新设计看起来像“模板换皮”，则应予以否决。

失败情况：

1. 原布局几乎完全不变，只更换了颜色和字体
2. 用重复的常见卡片替换重复的常见卡片
3. 区块节奏不变，只做了细微的表面调整
4. 动效仅限于基础淡入，没有交互逻辑

重新设计的最低标准：

1. 至少有 3 个全新的结构模块，取代通用的旧版区块
2. 至少有 2 个针对该产品场景量身打造的组件
3. 至少有 1 种原 UI 中没有的独特交互模式

组件自创规则

为重新设计自创组件时：

1. 根据产品语义（工作流、信任信号、转化步骤）设计，而不只是追求视觉新颖
2. 明确组件状态和响应式行为
3. 确保 Tailwind 类的组合方式易于维护
4. 仅在有助于提升理解效率或反馈速度时添加动效

核心目标

在不破坏用户流程的前提下，将现有界面改造成更清晰、质量更高、设计意图更明确的界面。

工作方法

1. 先审查当前 UI：

• 找出层级问题、间距不一致、构图薄弱和套路化设计
• 发现交互痛点和缺失的反馈状态
• 列出必须保持稳定的内容（流程、核心信息架构、关键文案、业务限制）

2. 确定重新设计的方向：

• 选择鲜明的视觉理念和布局类型
• 强化字体排印、区块节奏和对比度
• 提升组件一致性和响应式表现

3. 安全实施：

• 除非明确要求更改，否则保留现有功能和导航逻辑
• 避免表单、状态和无障碍方面出现回归
• 仅在有助于提升清晰度和反馈时运用动效，而非单纯装饰

4. 验证质量：

• 检查桌面端和移动端的表现
• 如果添加了动画，检查减少动态效果的设置是否生效
• 确认重新设计确实带来了实质性改进，而非只是风格有所不同

约束

• 不要采用套路化的“安全 SaaS”默认设计。
• 不要无故移除关键信息架构。
• 不要为了视觉新颖而牺牲易用性。
• 确保性能适合目标使用场景。