用途
clarify 是一个设计工作流中的澄清技能，目标是在提交任何视觉或结构设计工作之前，先弄清用户真正需要什么。它解决的问题是：LLM 在信息缺失时习惯性假设而非提问，导致设计方向错误，而设计方向错误代价高昂。该技能充当设计流程的“澄清器”，对设计请求中不明确的部分进行分类，并生成有针对性的问题，在开展视觉或结构工作之前加以解决。
主要能力
缺口分类
并非所有缺口都一样，分类决定该问什么问题：
意图缺陷（Intention faults）——真实设计目标无法从请求中恢复。包括：目标含糊，如“让它更好看”“更现代”“更出彩”；意图间接，如“你能看看这个颜色行不行吗”，往往意味着“请修复色彩系统”；上下文无关，用户在设计过程中插入不相关的视觉顾虑。
前提缺陷（Premise faults）——请求中的某个假设错误或无法解决。包括：缺少品牌上下文，如“匹配我们的品牌”但未提供 DESIGN.md、风格指南或参考； artefact 状态错误，如“更新现有 tokens”但项目中不存在 DESIGN.md；能力不匹配，要求当前上下文无法提供的视觉输出。
参数缺陷（Parameter faults）——必需的设计细节缺失或冲突。包括：缺少 register，如“设计一个落地页”（品牌还是产品？营销还是 SaaS 工具？）；缺少受众/设备，如“做成响应式”；缺少情绪/个性，如“干净专业”（极简冷峻还是温暖亲和？）；矛盾，如“保持简洁但展示所有内容”。
表达缺陷（Expression faults）——语言妨碍了唯一的设计解读。包括：词汇歧义，如“清理 UI”；范围歧义，如“让它更可访问”（仅 WCAG AA 对比度？动效敏感？键盘导航？）；指代歧义，如“更新那个组件”（哪个？在什么上下文？）。
歧义方向判断
识别缺口后，判断它朝哪个方向拉扯，从而塑造提问方式：语义（设计术语有多种合理含义）→ 消歧：“你是指 X 还是 Y？”；过宽（意图清晰但范围横跨多个支柱）→ 具体化：“当下哪个顾虑最重要？”；过窄（请求对可能的设计目标来说异常具体）→ 泛化：“你想要的更广泛结果是什么？”
设计任务的三个具体歧义来源
缺少目标：只有“是什么”没有“为什么”，如“加一个 hero 区域”但无目的或受众说明；缺少前提：设计约束未说明（品牌色、目标设备、语气、可访问性层级）；术语歧义：在需要精确词汇处使用含糊设计词（“现代”对“极简+编辑风”，“专业”对“产品 register 克制”）。设计需求之间的不一致容易被忽略，需要显式检查请求各部分是否冲突。
用假设生成问题
不要从“我该问什么”开始，而从“有哪些合理的设计方向”开始，再找出其答案能排除最多方向的那些问题。具体做法：生成 2 至 4 种竞争性设计解读；识别区分它们的轴线；针对该轴线提问。针对分歧轴的一个问题胜过关于视觉细节的三个问题。
信息增益选择
在可能的问题中，选择能最大程度减少不确定性、覆盖最多解读的那个。若问题 A 把假设按 50/50 分割，问题 B 按 90/10 分割，则问 A。目标是在 3 至 5 轮内收敛，超过后收益急剧递减。
具体优于抽象
尽量向用户展示不同解读会产生什么，而不是问抽象问题。例如不说“你想要什么样的视觉基调？”，而说“如果你指编辑风——高对比、紧凑间距、表现型字体——调色板偏向深中性色。如果你指亲和——圆润形态、温暖色彩、开放间距——则走向另一边。哪个方向更接近？”
使用方式
五种澄清策略
按缺陷类型选择：请求参数（缺少具体设计细节）；消歧（存在多个有效设计方向）；提出替代方案（品牌约束使请求按原样无法实现）；确认风险（高风险、难以撤销的设计决定）；报告阻塞（设计前提确实缺失）。
问题质量检查
每个问题应通过：聚焦（只针对一个缺口，不复合）、可回答（用户凭已知信息可答）、有区分度（答案能实质性缩小设计方向）、非诱导（不预设答案）、任务相关、建设性（朝着确认的 brief 推进，而非仅收集数据）。
用户成本意识
低工作量问题（如手机优先还是桌面优先）可自由问；中工作量问题仅在实质性改变方向时问；高工作量问题（如你当前设计系统的 token 命名是什么）不要问，自己查 DESIGN.md / 代码库。原则：问意图、目标和品牌上下文（用户的知识），自己弄清技术和结构细节。
对话管理
跟踪意图状态：维护两个心理集合——已确认（用户验证过的方向、约束、目标）和已排除（用户拒绝或与已确认信息冲突的方向）。用与已确认项的一致性和与已排除项的冲突给剩余设计方向打分。分离三个决定：是否应澄清？哪种澄清？如何措辞？
短路规则
若 brief 清晰且无竞争性设计方向，直接推进；若提问与不提问会产生同等好的设计结果，不提问，平局时偏向行动；若用户表示“直接做”或“怎么都行”，切换到确认模式，陈述你的设计假设供用户反对，而非沉默。
适用场景
适用于请求处于设计模式清晰、但设计 brief 本身描述不足的情况。它不替代核心 design-for-ai 技能的意图检测（运行哪种模式：design、surface、fonts、color、audit、enhance、polish）。若请求模式不明，由核心技能路由。歧义解决、brief 确认后，返回调用命令，附带 goal/audience/brand/constraints/register；若设计工作中出现新歧义，重新进入 clarify 循环。
限制
该技能只处理设计 brief 歧义，不能替代核心技能的意图检测。它依赖用户在对话中提供意图、目标和品牌上下文。每轮问题建议 1 至 3 个，目标 3 至 5 轮内收敛。