设计循环 是做什么的？
一种循环方法，通过测量而非猜测，提升现有界面或相关文案的质量。每轮：以相同方式捕获UI（或文本快照），请新评委根据固定标准评分，根据评分修复问题，然后重复。该模型借鉴了 dream-loop 的评判方法（每轮更换评委、苛刻评分、回归得分更低），并将其应用于UI打磨而非匹配目标图像，同时借鉴了Theo（t3.gg）在 《Agents Sucked At UI (Until Today)》 中提出的爬山式UI设计理念。
该循环之所以有效，是因为三个分离原则。请务必遵守：
- 评委从不实施，实施者从不评判。 编写修复方案的代理会慷慨地给自己打分。
- 每轮评委都是新人。 见过上一轮的评委会锚定在自己之前的判断上。给新评委提供标准、新的捕获结果以及之前的判定（以便评分保持一致并明确指出回归问题），但不提供对话内容。
- 捕获集是固定的。 只有第N轮显示与第0轮相同的界面、状态和主题时，分数才具有可比性。
三种模式
三种模式的循环结构相同；区别在于评委衡量什么。先确定模式，因为它决定了标准、值得提出的问题以及预期的变化程度。
- 专业打磨 — 目标明确，资深产品设计师会检查的内容：一套统一的令牌和界面、更少的字体大小和粗细、一致的间距系统、可读性和对比度、点击目标和光标区域、状态覆盖、浅/深色模式一致性、动效质量。目标是应用自身的最佳状态；不涉及风格偏好。阅读
references/mode-polish.md。 - 艺术指导 — 面向特定视觉效果的主观追求：命名风格（如“图形写实主义”、“霓虹波普搭配ASCII艺术和野兽派动态布局”）、参考集、生成的目标图像、或要匹配的Figma设计。评委评估UI在多大程度上表达了该方向。预期有更大的视觉变化，因此字体、颜色和布局特征都在考虑范围内。阅读
references/mode-art-direction.md。 - 文案优化 — 该循环应用于文字：UI文案（标签、错误提示、空状态、引导页）、文档和产品页面、或独立文本。评委根据清晰度、简洁性、语气、一致性和准确性为指定的读者评分，并辅以读者测试（新的代理冷读文本并说出其理解的操作）。含义保持不变；文字得到改进。阅读
references/mode-writing.md，其中说明了以下每个步骤如何变化（文本代替界面、快照代替捕获、词汇表代替令牌）。
从请求中推断模式（如果明确的话）：如“收紧”、“保持一致”、“凌乱”表示打磨；“让它看起来像”、“更具艺术性”、风格名称、Figma链接表示艺术指导；“文案”、“措辞”、“文档”、“错误消息”、“这篇帖子”表示文案。否则询问用户。用户可能希望同时进行多种模式：先进行艺术指导设定外观，然后进行打磨使其一致，最后对文案进行优化，每种模式都有各自的循环和标准。不要将它们混合到一个标准中，否则评委会在一致性和风格之间权衡，导致分数失去意义。
步骤1：访谈用户
确定模式，然后用AskUserQuestion询问其余问题（两次调用；每次最多可提四个问题）。跳过用户消息已回答的任何问题，并首先提供推荐选项。答案将存入brief文件（步骤3），这是所有子代理都会读取的文件。
- 目标 — 用他们自己的话说，完成后应该改进什么？（“Chrome感觉不一致”、“菜单凌乱”、“感觉卡顿”。）同时询问禁止范围：他们希望自己处理的界面，以及他们能接受多大的改变（收紧 vs. 改样式 vs. 重新设计）。大多数用户想要收紧，而不是重新设计；在每个brief或实施者可能会过度修改时说明这一点。
- 焦点（多选）— 哪些维度最重要；这将设定标准的权重。选项取决于模式，并在其参考文件中列出（打磨：一致性和令牌、排版、间距和布局、可读性、交互和点击目标、动效、性能；艺术指导：所选风格的特征，以及UI的哪些部分应体现该风格；文案：清晰度、简洁性、结构、语气和语调、一致性、有用性、准确性）。在文案模式下，还要询问
references/mode-writing.md中的额外问题（读者和目的、语气样本、固定内容、长度和本地化限制）。 - 基线 — 今天的UI处于什么水平？用户给出十分制分数，或由评委先评分。建议两者都做（如果用户有意见）：他们的分数为评委提供校准依据（如果他们打6分而评委打8分，说明标准太宽松——在第1轮前收紧标准）。
- 停止条件 — 目标分数（例如，每个组和主题≥9/10）、轮数、或先到者。推荐“目标分数，上限N轮”。警告无限循环可能消耗大量token。
- 子代理智能 — 评委和实施者运行的模型和努力程度。提供：最佳可用（最慢、最彻底）、均衡（会话自身的模型和努力）、快速（捕获和机械修复用便宜模型，评判用强模型）。评判是智能投入回报最高的地方；如果用户想节省，首先节省捕获和机械实现。
- 参考 — 他们是否有喜欢或必须匹配的设计？网站、应用、截图、Figma链接、设计系统、或命名指南或技能（平台HIG、设计工程技能）。询问他们喜欢每个的哪些方面（密度、菜单、动效），因为“喜欢这个网站”没有理由会导致全盘复制。在打磨模式下，参考文献是可选的，通常是指南。在艺术指导模式下，循环需要一个目标：风格描述、参考、Figma设计或生成的图像；如果用户没有，主动提供收集或生成（参见“参考和目标”）。
- 交付 — 仅分支、PR（不合并）、和/或他们可以运行的构建。默认：分支 + 未合并的PR。未经要求绝不合并或发布。
将用户提供的所有内容放入 .designloop/references/（步骤3）并在标准中列出，以便每位评委和实施者都基于相同的来源工作。
步骤2：研究项目设置
在编写任何规则之前，了解项目实际如何运行、测试和发布，以便循环遵循用户的习惯而不是强加自己的规则。先观察，后询问：读取仓库和机器能告诉你的信息，仅对仍然不清楚或属于偏好问题的事项进行询问。
寻找以下内容：
- 已写好的指令： CLAUDE.md / AGENTS.md、README和CONTRIBUTING、记忆笔记、以及任何早期的代理规则文件。这些优先于任何推断。
- 应用如何运行以及如何被驱动： package脚本、Makefile、开发版 vs. 生产版构建、以及什么可以捕获它（浏览器/CDP、Playwright、模拟器或设备工具、现有的截图或e2e设置）。如果没有任何东西能自动驱动应用，请说明并询问用户希望如何进行捕获。
- 项目信任的检查： 类型检查、lint、测试、构建、以及它们今天是否通过。
- Git习惯： 默认分支、分支命名、是否已使用工作树、提交信息约定、工作是否通过PR进行。
- 运行可能触及仓库外部的任何内容： 真实账户、付费API或AI后端、消息、生产数据、用户自己的应用配置文件或设备。查明是否有模拟、演示或沙箱模式。
- 设计工具是否已连接： 如果用户提供了Figma链接（或其他设计工具链接），查找可以读取它的连接器或MCP服务器，以及它是否已登录。
- 这里能否生成图像： 检查此会话实际能调用什么，而不是假设。某些框架内置了图像生成功能（Codex有）；在其他框架中，它来自已安装的技能、插件或MCP服务器（Higgsfield或任何其他图像模型）。通过可用的工具和技能查找。如果没有，循环仍然有效；目标图像是可选的。
- 影响并行工作的机器限制： 空闲磁盘空间、已使用的端口、运行的其他代理或开发服务器。
然后通过一次AskUserQuestion调用，仅向用户确认你无法从发现中确定的选择。典型的选择包括：
- 工作位置： 当前分支、新分支、或每个实施者独立的工作树（如果实施者并行运行则需要）。
- 如何测试： 仅开发服务器，还是在完成前也测试生产/打包构建；哪些主题、窗口大小或设备算数。
- 不得接触或消耗的内容： 真实账户和付费服务，以及是否可以为捕获接受模拟模式。
- 同时运行多少： 并行实施者，或一次一个。
在问题中说明你的推断（“我发现X，所以我计划Y”），以便用户能快速纠正。将结果写入RULES.md（下一步），并记录哪些规则来自用户，哪些是你推断的。
步骤3：设置
在源代码树外创建一个工作文件夹，或在仓库中创建一个git忽略的 .designloop/：
.designloop/
BRIEF.md # 访谈答案：目标、范围（包含/排除）、变更容忍度、焦点、停止条件
RUBRIC.md # 来自 references/rubric.md，根据所选焦点加权
RULES.md # 来自步骤2的项目工作规则（参见 references/briefs.md）
references/ # 用户喜欢的内容，以及任何目标图像（见下文）
capture/ # 捕获脚本和界面列表
round-0/ … # 每轮：每个主题的静态图、videos/、index.json、judge-*.md
在生成任何内容之前编写这些文件。子代理从零上下文开始，因此这些文件就是上下文：将brief指向它们，而不是重新输入。
- RUBRIC.md — 从模式参考文件中的标准开始（
references/mode-polish.md或references/mode-art-direction.md），包含来自references/rubric.md的共享标题和评委输出格式。根据用户的焦点调整权重，明确写出IN和OUT范围列表，并定义最高分的含义。 - RULES.md — 步骤2确定的内容：如何运行和驱动应用、在git中的工作位置、要运行的检查、不得接触或消耗的内容、以及如何清理。
references/briefs.md列出了应涵盖的事项。 - 界面列表 — 范围内的每个界面，每个界面附带值得评判的状态（静止、悬停、打开、选中、空、错误、忙碌）以及每个主题。将其分为两组或三组相关的界面，以便每位评委可以仔细查看；一位评委浏览五十张截图只能走马观花。
在开始之前检查项目检查是否通过，以便后续失败责任在于你。
参考和目标
标准说明好的普遍定义；参考文献说明好的具体模样且针对此用户。艺术指导模式总有某种目标。打磨模式可以仅依靠标准运行，以应用自身的最佳界面作为标准。
目标有三种类型，具有不同的权威性。在 references/README.md 中说明每个文件属于哪种类型，因为评委和实施者必须区别对待：
- 规格（用户要求匹配的Figma设计）：权威性。匹配它。
- 参考（用户喜欢的站点、应用、截图）：匹配命名的特征，而非整体。
- 生成的图像：仅作为感觉方向。
用户提供的参考。 将其保存到 .designloop/references/ 中，附带简短的 README.md：对于每个参考，说明它是什么以及用户喜欢它的什么。对于网站或应用，捕获相关部分的截图（如果吸引点在于动效，则截取剪辑），以便评委每轮看到的是相同的内容，而不是重新获取可能变化的页面。将喜好转化为标准中具体、可检查的特征（“行高约28px”、“一种强调色”、“菜单在200ms内淡入”），因为评委可以为一个特征打分，但无法为一个氛围打分。
你收集的参考。 如果用户想要某个方向但没有示例，提出三到四个其界面符合用户目标的知名产品，展示它们，并让用户选择。不要替他们选择。
Figma设计。 如果用户提供了Figma链接，检查此会话中是否有可用的Figma连接器或MCP服务器（步骤2）。如果有，先加载其自身的技能或指令，然后为每个链接的frame提取：渲染的图像，以及其背后的设计数据（变量和样式、排版、间距和自动布局值、颜色、圆角、效果、组件名称、任何动效）。将图像保存为 references/figma-<surface>.png，将值保存为 references/figma-spec.md，映射到应用的界面和状态，并注明文件未涵盖的任何内容（状态、主题、尺寸）。如果没有可用的Figma工具，请用户连接一个或导出frame的图像加上他们关心的值；切勿要求他们粘贴令牌。
询问匹配的字面程度：精确（Figma是规格；任何差异都是缺陷）或指导性（遵循其系统和感觉，在差异处保留应用自身的结构）。对于精确匹配，循环变为收敛：每轮，评委将每个捕获与其相同尺寸的frame进行比较，列出每个可测量的差异（px、颜色、粗细、圆角、间距、缺失或多余的元素），并根据剩余差异的数量及其可见性进行评分。当设计与运行中的应用在用户未要求更改的内容或行为上存在分歧时，标记它而不是静默地遵循其中之一。
你生成的目标图像。 如果图像生成可用（步骤2）且用户需要，制作其UI的“优化版本”作为目标：
- 从真实的应用截图开始（第0轮的捕获，或用户提供的截图），
…
[由于原文被截断，skillMarkdown仅翻译了提供的部分。]