关于 design-engineering
design-engineering 是面向设计与工程协作的设计实践指南，强调在探索阶段纳入实现约束，并把设计结构映射到代码结构。它通过评审清单帮助团队关注组件、设计令牌、无障碍和生产质量。
主要功能
- 01尽早纳入工程约束
- 02将设计结构映射到代码
- 03用设计令牌替代零散样式
- 04考虑无障碍与异常状态
- 05核对原型与生产要求
适用场景
- 01设计与开发团队共同探索界面方案
- 02将设计组件模型映射为组件 API
- 03评审设计系统中的令牌使用
- 04检查原型是否涵盖生产需求
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/design-engineering确认已加载。
详细介绍
设计工程
设计工程是对生产环境中界面的共同责任，而不是在完成的设计稿和拆分成工单的实现工作之间接力。
默认原则
- 优先协同，而非交接：尽早考虑实现约束。
- 有意识地将设计结构映射到代码结构。
- 通过原型学习；以生产级严谨度交付。
- 让审美判断建立在对材料的了解之上（CSS、框架渲染、令牌、无障碍）。
- 尽量减少设计意图与实现之间的转译损耗。
映射关系
| 设计概念 | 代码概念 |
|---|---|
| 画框 / 自动布局 | 堆栈、弹性布局、网格 |
| 组件 + 变体 | 组件 API + 属性/状态 |
| 局部样式 | 令牌 + 语义类 |
| 原型交互 | 实际状态、路由和动效 |
| 标注 | 编码进组件的默认值 |
提倡 / 避免
| 提倡 | 避免 |
|---|---|
| 共同承担质量责任 | “设计完成了” / “开发会润色” |
| 在探索阶段纳入约束 | 视觉方案定稿后才发现可行性问题 |
| 原型设计时考虑生产需求 | 把氛围演示当作可发布产品 |
| 使用令牌化系统 | 无法适应主题的一次性取值 |
评审清单
- 工程约束是否尽早影响了设计方向？
- 组件 API 是否与设计人员使用的变体模型相匹配？
- 是否使用了令牌，而非彼此孤立的原始取值？
- 是否为无障碍和空状态/错误状态做了设计，而非留待以后处理？
- 原型是否如实说明了仍需完成哪些生产工作？
- 设计和工程能否为行为指向同一事实来源？
原文
- 为协同而设计，而非交接
- 设计工程宣言
- 用设计代码思考
- 设计工程师
评论
支持 Markdown