Claude学术期刊风格设计

当设计规范变成“形容词”

接手一个多团队共建的产品时，最常见的问题不是没有设计系统，而是规范写在文档里，落地时变成一堆模糊的形容词。工程师打开设计稿，看到“稍微紧凑一点”“要有呼吸感”“这个按钮再重点”，最后各端实现出来五花八门。更糟的是，规范文档本身没有约束力，新组件随业务增长而膨胀，旧组件没人敢动，无障碍要求往往只在评审时提一嘴。

@user_fccf428b/claude-design-blueprint 要解决的就是这个问题：把设计系统的写法变成一份可执行、可评审、可验收的指南，而不是一段读起来正确的描述。

它如何工作

这个技能不是给你一套现成的 UI 组件库，而是教 Claude 按工程化的方式生成设计系统规范。它的输出直接面向工程师和设计师，因此结构非常具体：

• 先定义意图：动笔前必须用一句话复述设计目标，避免规则与初衷脱节
• 令牌先行：颜色、字体、间距等先落成 #141413、12/14/16/20/24/32 这类明确的 token，而不是“深色文字”“紧凑间距”
• 组件拆解：每个组件要写解剖结构、变体、状态（default、hover、focus-visible、disabled、loading、error）和响应式行为
• 无障碍可测：每条无障碍要求必须能落地验证，不能只写“注意对比度”
• 反模式清单：明确列出禁止的实现，并给出对应的替代方案
• QA 清单：最终输出一份可以在 code review 中直接勾选的检查表

它自身的品牌风格也很有辨识度：学术期刊印刷质感，暖石色背景（#FAF9F6）、近黑石板色主文字（#141413）、唯一的 clay 色强调色，硬边对比、零阴影、纯平按钮，连主 CTA 都只有“平顶圆底”这一处不对称弧线。强调靠排版和下划线，绝不靠颜色或发光。

适用边界

这套规范适合新建或重构的设计系统，尤其是需要强一致性、强可访问性约束的产品界面。如果只是快速做个 landing page，这套流程会显得太重；如果你的团队已经有很好的组件库和自动化测试，它可以作为设计语言的补充参考。

几个注意点：

• 技能本身不生成组件代码，它生成的是指南，落地仍需要工程师按规范实现
• 令牌和组件规则必须结合你实际的设计工具和主题系统适配，不能直接把 #FAF9F6 搬进一个用 CSS 变量管理的主题里
• 无障碍要求遵循 WCAG 2.2 AA，但这不能替代真实的用户测试
• 规范里的 must 是硬约束，should 是推荐，评审时要区分对待

最终交付物是一份可以直接放进设计仓库、可以在 MR 里逐条勾选的设计系统文档，而不是一段看起来专业的自然语言。