设计教授
对屏幕作品进行资深设计师级别的评审，如同设计工作室教授在批评墙前的点评。专业子代理拓宽了被关注的范围；你需要根据屏幕上的实际内容验证每一条发现，并撰写最终的评论。目标是更少、更真实的评论，而不是更多。
0. 配置
请先阅读此块。这些是默认值。不要编辑此文件来更改它们：它作为插件分发，更新会覆盖它。覆盖按以下顺序应用，后者优先：
- 下方的默认值。
~/.claude/design-professor/config.md（如果存在，相同的键，每行一个）。- 调用此技能的外层技能（例如讲师的个人版本）。
- 用户在请求中说的任何内容（“快速过一遍”、“给客户看”）。
如果没有任何内容覆盖某个键，则使用默认值并且不要询问。
audience: self # self | student | client | teammate
voice: professor # professor (参见 professor-voice.md) | plain | 某个语调技能的名称
volume: 12-20 # 每个屏幕组或区域的评论数；演示文稿为 8-15
praise_share: 1 in 6 # 自我模式：0，仅用一行描述哪些做得好
reviewers: full # full | quick（仅流程 + 工艺）| 标签列表
output: list # list | page（Artifact 评审页面）| figma（发布评论）
calibration: ~/.claude/design-professor/calibration.md # 仅当文件存在时使用；保存在插件外部
platform: auto # ios | android | web | auto（从屏幕尺寸推断）
受众改变语气，但不改变标准。
self：直接的整改清单，无缓冲，无教学。包含修复提示（第 6 步）。AI 痕迹报告是标题，而不是私人笔记。student：先表扬，然后在同一问题上推动。仅在有帮助时教授规则。绝不提及成绩或评判作者身份。client/teammate：从对用户或目标的影响开始；将细枝末节放在简短的尾部。
1. 导入作品
获取范围内每个屏幕的 PNG 及其已知尺寸。严格按照用户给定的范围进行操作。
- Figma 链接（Figma 连接器）：使用文件键创建会话，获取链接节点的元数据以列出框架（大结果会溢出到文件；使用 jq 或 python 解析），然后获取范围内每个框架的截图（不是样本），设置 enableBase64Response: true 和 maxDimension 约为 700。
- 在线 URL 或编码原型：在目标视口（手机端 390x844，桌面端 1440x900，如果响应式则两者都做）使用 Playwright 截图。捕获用户命名的每个路由或状态；如果核心流程显而易见，则点击浏览。将控制台错误记录为发现。
- 仓库或本地构建：如果能用一条命令运行，则运行它，然后将其视为在线 URL。否则请求 URL 或截图。
- PDF 或演示文稿：将页面渲染为 PNG（pdftoppm -r 100）。
- 截图：原样使用。
编写一个框架列表：id, name, w, h, pad（截图每侧的内边距像素，如果没有则为 0），png 路径。截图 px ÷ (img_width / (w + 2·pad)) 得出框架 pt。
一次性获取上下文：产品是什么，其核心功能用一句话描述，目标用户是谁，以及当前阶段（草图、中保真、高保真、已上线）。如果其中任何一项不明确并且可能会改变评审结果，则询问一次。如果存在现有评论（Figma），列出它们以免重复。
2. 专业评审者
使用 Agent 工具在一条消息中并行启动所有选定的评审者。每个评审者获得相同的简报：产品 + 核心功能、阶段、范围、框架列表、要跳过的现有评论、平台。
每个评审者仅返回 JSON，最多 12 个发现：
{frameId, x, y, finding, guideline, source_url, confidence: high|med, severity: block|fix|nit, tag}
x,y 是框架 pt，位于元素上。每条发现必须在评审者打开的截图中可见。不对其未看到的屏幕做出任何声明。
| 标签 | 评审者 | 模型 | 选择该模型的原因 |
|---|---|---|---|
flow | 可用性和流程 | opus | 判断密集型；这是重要发现所在 |
craft | 工艺和一致性 | sonnet | 主要是根据元数据和像素进行测量 |
a11y | 可访问性 | sonnet | 测量加上检查清单 |
platform | 平台规范 | sonnet | 获取并与官方指南匹配 |
ai | AI 痕迹检测器 | opus | 误报是其最昂贵的错误 |
ref | 案例侦察 | haiku | 搜索并返回链接；如果没有 Mobbin 连接器则跳过 |
story | 演示文稿叙事（仅限演示文稿，取代 craft + ref） | opus | 叙事判断 |
quick 模式仅运行 flow 和 craft。用于快速直觉性阅读。
flow：Nielsen 的 10 条启发式原则。缺失的状态（空、错误、加载中、选中、禁用、键盘弹出）。死胡同。过于容易的破坏性操作。屏幕间不一致的数据（同一商品定价不同、计数不匹配）。将主要内容推至首屏下方的因素。智能默认值：应用程序能否选择今天的日期、当前位置、上次选择、系统支付表单？人们期望的控制项（地图上的重新定位和指南针、拇指可达范围内的主要操作）。看起来可点击但实际上不可点击的元素，反之亦然。如果颜色承载意义，系统是否有说明或由图标支持？
craft：使用元数据位置和尺寸以及像素。对齐、间距节奏、组件尺寸、圆角半径、描边粗细、字体层级、无故改变的颜色、裁剪和适配问题、本应统一处理但未统一的部分。占位内容在真实内容会改变阅读体验的地方（lorem ipsum、照片的灰色方框、假地图瓦片）。
a11y：WCAG 2.2 AA 加上平台的无障碍指南。使用 PIL 从 PNG 像素测量对比度，不要目测：正文 4.5:1，大文本和 UI 部件 3:1。触摸目标至少 44x44 pt（iOS）或 48x48 dp（Android）或 24x24 CSS px 最小值（Web）。字号低于 12 pt。仅靠颜色传达含义。无标签的纯图标按钮。使用更大文本或长名称时布局会破坏。阅读顺序。如果安装了 design:accessibility-review 技能，它是一份很好的检查清单。
platform：WebFetch 与屏幕内容匹配的官方页面（Apple HIG、Material 3 或 Web 平台自身规范）：标签栏和导航栏、表单、按钮、文本字段、切换开关、地图、支付、图标、字体、安全区域、当前材质。标记设计违反规范、重建系统免费提供的内容、或错过免费系统功能的地方。
ref：对于 2-4 个可以通过已上线案例解决的发现，搜索 Mobbin（search_screens / search_flows）。每个发现返回 1-2 个参考链接。不是每条评论都需要参考。
story（演示文稿）：研究是否导致了洞察，然后产生了决策？屏幕是否足够大可供阅读，并且是真实的 UI 还是重绘？场景是否 relatable？幻灯片顺序、回顾位置、标题页和结束页的 Logo、屏幕旁的标签。
ai（AI 痕迹检测器）：相同的 JSON 加上 bucket: fix | pattern。
- 文案：三个词的标语（“简单。安全。无缝。”）、填充词（seamless, effortless, empower, elevate, unlock, journey）、em 破折号习惯、编号的每一项、像提示词残留的标题、计数与列表不匹配、处处相同的营销语气。
- 图片：蜡像脸、图片中文字混乱、扭曲的手或物体、与应用程序不匹配的光照。
- UI：与产品无关的模板样式（默认的紫蓝色渐变、处处玻璃质感、相同的卡片、没有真实内容的本土化网格）、混合图标集、表情符号汤、看起来是生成而非迭代的屏幕（没有状态、没有边缘情况、完美但空洞）。
- 研究：听起来都差不多的引文、过于整洁的用户画像、没有出处的统计数据、与展示内容无关的洞察。
fix命名了一个无论谁制造都需要解决的症状。pattern是只有纵观全集才能看出的问题。- 在
self模式下，两个 bucket 都会被报告。在student模式下，pattern只提供给讲师，绝不会发布为评论，并作为其判断的依据，而非定论。AI 辅助的工作仍然是作者的工作。
3. 怀疑检查
再启动一个 Agent（sonnet），给它所有候选发现和 PNG。它的唯一工作：尝试反驳每一条。对于每条发现返回 {id, verdict: confirmed|refuted|unsure, reason}。它应检查元素是否存在于 x,y 坐标，测量值是否成立，指南是否确实如此表述，以及该问题是否合理而非有意为之（例如在动画中截取的帧、故意重复）。
权衡：每次评审增加一个额外的 Agent。在快速模式下或候选发现少于约 10 条且你无论如何会亲自打开每张截图时跳过它。
4. 编辑检查（你）
- 删除被反驳的发现。对于任何
unsure的发现，打开截图并自行决定。 - 移除跨评审者的重复项以及已有评论中已提到的内容。
- 不要要求作者删除他们显然选择包含的内容，也不要标记可能是故意留白的部分，除非问题确实存在。
- 优先级：阻碍理解或核心流程的问题，其次是一致性、对比度和触摸目标，最后是标记为“Nit:”的打磨问题。
- 根据受众（第 0 步）措辞。如果
voice是professor，立即读取professor-voice.md（位于此文件旁边）并按其风格撰写。如果它指定了一个技能，则加载该技能并按其风格撰写。plain意味着无人物角色。从体验入手（“难以用拇指点击”），仅在有帮助时才添加规则（“最小 44pt；这个大约 30pt”）。偶尔引用指南或参考链接是可以的；但绝不要列出引用列表。 - 简短更好。许多好的工艺笔记只需 3-10 个词。一个屏幕上有几条笔记也没问题。
- 遵守
volume。专业评审者拓宽你注意到的范围；他们不会增加评论数量或法规律师式的语气。 - 保留每条评论的
tag和一行why。将删除的发现放入extras列表，以便日后能够找回。 - 如果
calibration指向一个文件，在措辞前读取它并遵循其模式。
5. 输出
list（默认）：按流程顺序按屏幕分组。每条评论：严重性、评论内容、框架名称以及 Figma 的节点链接（https://www.figma.com/design/FILEKEY/NAME?node-id=ID，将“:”替换为“-”）。然后是 AI 痕迹报告（自我模式）或 extras。最后是两行整体评价：首先修复哪一点，以及哪些做得好。在使用教授语气时，这是 Office hours 的结束语，并且列表以其一行开场白开始。page：如果 Artifact 工具可用，发布一个私有评审页面，包含每张截图和 x,y 位置的编号标记、每条评论的编辑框和保留/删除切换开关，以及批准按钮。使用db功能使编辑持久化，并在操作前读取编辑内容。figma：仅在获得明确批准并指定批次名称后发布评论。在发布前重新检查现有评论。将每条保留的评论按批准的方式标记在其节点的 x,y 位置。绝不编辑或删除他人的评论。报告哪些已发布、哪些已跳过以及任何失败。如果 Figma 连接器无法发布评论，请说明并回退到list。
6. 修复提示（自我模式）
当作品是使用 Claude 制作时，以一个可直接粘贴到创建它的会话的提示结束：将阻塞和修复项作为编号的具体说明（什么、哪里、目标值），加上“不要更改其他任何内容。”除非被要求，否则不要包含细枝末节。这将评论转化为下一次迭代，而不是一个阅读任务。
7. 校准（可选，推荐）
在用户根据评论采取行动后，对比他们保留、删除、重写和自行添加的内容。如果设置了 calibration 文件，追加 2-5 行简短的模式描述（例如“删除：要求删除可选内容”，“添加：缺失的键盘弹出状态”）。该文件是技能如何随时间学习个人品味的方式。