synax-design

Synax 产品设计

把用户需求整理成可评审、可实现、能体现 Synax 调性的产品设计稿。设计工作分为两段：先确认交互模型，再表达视觉方案。不要因为需求看起来简单就跳过确认。

触发条件

当用户提到以下内容时使用本 skill：

• 设计稿、交互稿、UI/UX、页面改版、功能设计、流程设计；
• 新建、编辑、管理、配置、切换、删除、添加项目等产品行为；
• 用户对已有方案提出“没有确认交互细节”“不符合直觉”“不像 Synax”“需要图文并茂”等反馈。

如果用户已经明确要求直接修改业务代码，仍先完成本 skill 的交互设计确认；确认完成后才能进入实现阶段。

核心规则

1. 先确认交互，再画界面

在输出最终设计稿前，必须明确并向用户确认：

1. 用户从哪里进入功能，入口是否符合当前任务上下文；
2. 操作作用于什么对象，当前对象与非当前对象如何区分；
3. 主流程的最短路径是什么，完成后用户会到哪里；
4. 添加、编辑、移除、删除、取消、失败、空状态和加载状态分别如何表现；
5. 哪些操作需要确认，哪些操作可以撤销或直接完成；
6. 现有信息架构中应放在哪里，以及为什么不放在另一个看似相关的位置。

一次只推进一个需要用户判断的问题。涉及布局、入口位置、层级关系或状态变化时，用图示帮助判断；纯需求范围或技术约束用文字提问。不要把多个未经确认的交互假设直接包装成成品设计。

如果用户已经在对话中给出明确答案，复用这些答案并只确认仍有歧义的部分。用户明确反对某个方向后，不要再次把它作为默认推荐。

2. 入口必须贴近对象和任务

优先把操作放在用户正在查看或切换的对象上下文中：

• 工作区级操作优先出现在工作区切换器、工作区标题或工作区概览中；
• 项目级操作优先出现在项目列表、项目行或项目上下文菜单中；
• 设置页只承载长期偏好、账号、环境和全局默认值；不要把高频的工作区内容管理塞进设置页；
• 如果操作对象不是全局设置，设计稿必须说明为什么入口不在设置页。

入口命名使用用户能直接理解的动词，例如“管理项目”“添加项目文件夹”“移除项目”。避免把内部实现词汇暴露给用户。

3. 设计稿必须图文并茂

每个中等及以上复杂度的设计稿至少包含：

• 一张主流程图或状态流转图；
• 一张关键界面示意图，展示真实层级、按钮位置、列表结构和空/有内容状态；
• 一段简短说明，解释用户为什么会在这里完成任务。

推荐使用 Mermaid 表达流程、状态机和对象关系；使用内联 SVG 表达界面线框、布局对比、标注和状态矩阵；需要滚动查看多个画板时使用静态 HTML。

视觉稿应服务于评审，不能只画漂亮的静态卡片而隐藏关键交互。

4. HTML 必须是静态文件

涉及 HTML 时，创建一个可直接从文件系统打开的自包含文件：

• 不启动 Vite、Webpack、任何 localhost 服务或文件监听服务；
• 不依赖 fetch、XHR、WebSocket、API 请求、运行时注入或服务端路由；
• CSS、SVG、示意数据和交互脚本优先内联；必须引用资源时只使用同目录的相对路径；
• 页面必须在 file:// 场景下仍能看到核心内容；没有网络时也能完成评审；
• 文件使用 ASCII 小写短横线命名，例如 workspace-management-design.html；
• 交互演示只做本地状态切换、锚点跳转或展开收起，不模拟真实提交，不隐藏设计依据。

静态 HTML 推荐包含：设计前提、设计决策摘要、流程图、关键界面画板、状态对照、交互说明和待确认问题。页面要有明显的视觉层级、足够留白和可读的标注，不要把所有内容压成一张长截图。

5. 保持 Synax 调性

优先使用克制、清晰、工具感强的表达：

• 以内容和工作流为主，避免营销式大标题和装饰性渐变；
• 使用中性浅色底、细边框、低饱和绿色作为强调色，保留良好的深色主题扩展空间；
• 让列表、路径、状态和操作有稳定的对齐关系；
• 主要操作有明确层级，危险操作使用克制但可辨识的警示色；
• 文案短而具体，描述结果和作用，不堆砌产品术语；
• 组件示意应体现键盘可达、焦点、禁用、错误和反馈位置。

不要凭空引入复杂的仪表盘、设置侧栏、步骤向导或多层弹窗。每增加一层容器，都要说明它解决了什么认知问题。

工作流程

第一步：理解上下文

先查看当前项目的相关页面、路由、组件、已有设计稿和项目规则。优先使用现有的工作区切换器、Dialog、Button、Tabs、Field 等模式。记录与本次设计直接相关的事实，不要因为看到旧方案就默认它是正确方向。

第二步：确认交互模型