clarify

技能：clarify

在着手设计之前，先了解用户的需求。

大模型通常会自行假设，而不是主动提问——即使信息不足，模型也往往会直接继续，而不先询问。本技能充当设计工作流中的澄清环节：对设计请求中不明确的部分进行分类，并生成有针对性的问题，在开始任何视觉或结构工作之前解决这些问题。

${CLAUDE_SKILL_DIR}/references/adaptive-questioning.md 中的 adaptive-questioning.md 是一份共享参考资料：计划流程中的澄清关卡也会链接到它（设计生命周期检查点会用它来切换模式）。

你的输出是一段对话：提出澄清问题、展示差异示例、复述用户的需求。与用户共同探索，边想边说，而不是盘问。

---

对不明确之处进行分类

信息缺口并不都一样。先判断类型，才能确定该问什么问题。

问题类型

意图问题 — 无法从请求中推断出真正的设计目标。

• 目标模糊：“让它看起来更好”／“让它更现代”／“让它更吸睛”（怎样才算更好？面向谁？希望采用什么方向？）
• 间接意图：“你能看看这个颜色合不合适吗？”（通常实际意思是“请帮我调整配色系统”）
• 上下文无关：用户在设计过程中提出了无关的视觉问题

前提问题 — 请求中的某个假设有误或无法确定。

• 缺少品牌背景：“符合我们的品牌风格”，但未提供 DESIGN.md、风格指南或参考资料
• 产物状态错误：项目中不存在 DESIGN.md，却要求“更新现有的设计令牌”
• 能力不匹配：要求输出当前上下文无法提供的视觉产物（例如，当前只能提供 HTML，却要求“导出为 Figma”）

参数问题 — 缺少必要的设计细节，或细节之间存在冲突。

• 缺少定位：“设计一个落地页”（品牌还是产品定位？营销页面还是 SaaS 工具？）
• 缺少受众／设备：“让它适配不同屏幕”（主要断点是什么？优先适配手机还是桌面？）
• 缺少氛围／个性：“简洁、专业”（是极简冷峻？还是温暖亲切？或是编辑感强、风格鲜明？）
• 存在矛盾：“保持简单，但把所有内容都展示出来”

表达问题 — 用词导致设计无法得出唯一的解读。

• 词义模糊：“清理一下 UI”（减少信息密度？简化配色？收紧间距？还是全部都做？）
• 范围模糊：“提升无障碍体验”（只关注 WCAG AA 对比度？还包括减少动态效果？键盘导航？还是三者都要？）
• 指代模糊：“更新那个组件”（是哪个组件？用于什么场景？）

模糊方向

确定信息缺口后，再判断它属于哪个方向——这将决定提问方式：

方向	信号	澄清方式
语义模糊	设计术语有多种合理含义	消除歧义：“你指的是 X 还是 Y？”
范围过宽	意图明确，但涉及多个方面	明确重点：“你目前最关注哪方面？”
范围过窄	相对于可能的设计目标，请求的细节过于具体	抽象提问：“你希望实现的整体目标是什么？”

针对设计任务

设计请求出现歧义，主要有以下三种情况：

• 缺少目标：没有说明 为什么，只说了 做什么（例如“添加一个主视觉区块”，但没有说明目的或受众）
• 缺少前提：未说明设计约束（品牌颜色、目标设备、语气、无障碍等级）
• 术语含糊：使用模糊的设计用语，而非精确表述（例如“现代”与“极简＋编辑感”、“专业”与“克制的产品定位”）

设计要求之间的不一致很容易被忽略。请明确检查请求中的各部分是否相互冲突（例如，“大胆鲜艳”与“平静可信”就指向相反的方向）。

---

生成问题

围绕假设思考

不要从“我该问什么？”开始，而要从“有哪些合理的设计方向？”开始。然后找出能排除最多方向的问题。

1. 针对请求，提出 2–4 种相互竞争的设计解读
2. 找出它们之间的区别——分歧轴
3. 围绕这个轴提问

示例：

• 请求：“重新设计仪表板”
• 解读 A：减少视觉干扰——删减卡片、收紧间距、采用中性色调
• 解读 B：建立品牌形象——引入强调色、字体风格和个性
• 解读 C：提升易用性——重新梳理层级、突出关键操作、减轻认知负担
• 分歧轴：这是视觉／品牌问题、清晰度／易用性问题，还是信息密度问题？
• 问题：“你对当前仪表板最不满意的是什么——感觉不像品牌、难以阅读，还是内容太多让人应接不暇？”

针对分歧轴提一个问题，胜过问三个关于视觉细节的问题。

选择能最大化信息增益的问题

在可能的问题中，选择那个能最大程度减少不同解读之间不确定性的问题。如果问题 A 能让你的假设各占 50%，而问题 B 会让它们呈 90／10 的比例，就问 A——无论答案是什么，它都能提供更多信息。

目标是在 3–5 轮内达成共识。超过这个范围后，收益会迅速递减。

具体胜过抽象

尽可能展示不同解读会带来什么结果，而不是提出抽象问题：

• 较弱：“你想要什么样的视觉调性？”
• 较强：“如果你指的是编辑风格——高对比度、紧凑间距、表现力强的字体——配色就会偏向深色中性色。如果你指的是亲和风格——圆润的形态、温暖的色彩、宽松的间距——方向则会相反。哪种方向更接近你的想法？”

展示不同的设计方向。让用户根据具体描述做选择，而不是根据抽象标签。

五种澄清策略

根据问题类型选择合适的做法：

策略	适用情况	示例
询问参数	缺少具体设计细节	“主要面向哪种设备——手机还是桌面端？”
消除歧义	存在多个有效的设计方向	“你说的‘现代’，是指极简／扁平，还是大胆／富有表现力？”
提出备选方案	品牌限制使请求无法按原样实现	“未找到 DESIGN.md。我们可以先建立设计 DNA，或者先以线框模式继续，之后再添加设计令牌。”
确认风险	设计决策影响重大且难以撤销	“锁定 DESIGN.md 就意味着确定设计令牌系统。要继续，还是先调整配色？”
报告阻碍	确实缺少设计前提	“未提供品牌参考。核心的 design 模式会建立设计 DNA——要先运行它吗？”

---

问题质量

属性

每个问题都应通过以下检查：

属性	检查标准
聚焦	只针对一个信息缺口——不包含多个问题
可回答	用户可以根据已有认知作答
有区分度	答案能实质性地缩小设计方向的范围
不带诱导性	不预设答案
与任务相关	直接推动当前设计工作
有建设性	推动形成已确认的需求说明，而不只是收集信息

注意用户投入

估算每个问题需要用户投入多少精力：

投入程度	示例	策略
低	“优先面向手机还是桌面端？”	可以直接问——用户已有答案
中	“情感基调更偏品牌还是产品？”	只有在会实质改变设计方向时才问
高	“你当前设计系统的设计令牌是如何命名的？”	不要问——自己检查 DESIGN.md／代码库

原则：询问意图、目标和品牌背景（用户掌握的信息）。技术和结构细节由自己查明。

---

管理对话

跟踪意图状态

随着对话推进，维护两个心理集合：

• 已确认（+）：用户认可的设计方向、约束和目标
• 已排除（−）：用户拒绝的方向，或与已确认信息相矛盾的方向

根据剩余设计方向与已确认事项的契合程度，以及与已排除事项的冲突程度进行评分。随着每轮对话推进，可选范围自然会逐渐缩小。

将决策拆开

按顺序考虑三个不同的问题：

1. 我该澄清吗？ — 是否存在会影响设计方向的实质性歧义？
2. 该如何澄清？ — 应采用哪种问题类型和策略？
3. 该怎么措辞？ — 具体要问什么问题，如何组织表达？

不要把这些问题混为一谈。决定澄清后，立刻抛出想到的第一个问题，就跳过了确定目标的步骤。

短路规则

• 如果需求说明清晰，且没有相互竞争的设计方向，就直接开始。
• 如果询问与不询问都能得到同样好的设计结果，就不要问。结果不分高下时，优先采取行动。
• 如果用户表示“直接做吧”或“怎么合适怎么来”，切换到确认模式，而不是保持沉默——说明你的设计假设，让用户有机会提出异议。有关模式切换流程和真正低风险情况的例外，请参阅 adaptive-questioning.md。

---

反模式

上次审阅：2026-07

模式	问题	应对方式
未经确认就开始	默认直接执行的偏向——选错设计方向代价很高	先单独进行检测
询问实现细节	“使用哪个 CSS 框架？”不是设计问题	自行判断；询问品牌、受众或目标
连珠炮式提问	感觉像填写需求表，而非协作	每轮最多问 1–3 个问题
询问本可从 DESIGN.md 读取的信息	浪费用户时间	先阅读 DESIGN.md，再询问其中未涵盖的内容
对清晰的需求过度提问	延误工作，损害信任	需求清晰时，直接开始
提问过于抽象	用户难以推断视觉方向	展示不同的设计方向
引导式提问	影响回答，掩盖真实意图	使用开放式问题，或提供平衡的选项
只问一轮就结束	复杂的设计需求需要反复迭代	继续沟通，直到方向趋于一致
结果相同仍提问	造成不必要的阻碍	结果不分高下时，优先直接行动

---

避免重复说明

此技能用于处理设计需求歧义——那些导致无法明确要做什么设计的信息缺口。它不会替代核心 design-for-ai 技能的意图检测（要运行哪种模式：设计、表面、字体、颜色、审查、增强、润色）。如果用户的请求已明确属于设计模式，但设计需求本身尚不充分，就调用澄清流程。如果请求所属模式不明确，则由核心技能进行路由。

---

流程

之后	下一步
歧义已解决，需求已确认	返回调用命令，并提供目标、受众、品牌、约束和语气
设计过程中出现新的歧义	重新进入澄清流程