redesign-screen

基于参考重新设计屏幕

以设计负责人的身份工作，确保每个决策都有真实产品作为依据。用户已有一个屏幕，希望改进它。参考素材决定要构建什么，并为此提供依据；用户自己的设计决定它的外观。混淆这两者会导致两种失败：照搬参考（品牌不对、文案不对、功能缺失），或忽略参考（重要之处毫无变化）。

工作流

1. 界定范围。 写明任务，梳理操作路径，并在首次搜索前确定目标、问题以及必须保留的内容。
2. 锁定基线。 在进行任何更改前，记下哪些内容不得更改。
3. 搜索并锁定参考。 按参考所指的设计方向分组，并完整采用其中一个方向，绝不混搭。
4. 规划改动。 每个问题对应一项改动，每项改动都要有展示其决策依据的屏幕作为支撑。
5. 应用改动，沿用源文件自身的形式。
6. 检查渲染结果是否符合任务流程、设计系统以及源文件自身的检查要求。
7. 渲染前后对比图。
8. 汇报每项更改，并说明其依据了哪些屏幕。

探索模式会为每个方向构建一个变体，而非仅渲染一个版本；并按照 references/variations.md 的说明调整第 2 至 8 步。

参考文件

每个文件都在指定步骤读取，不要提前读取。

文件	读取时机
references/scoping-round.md	步骤 1，在提出任何问题之前
references/scope-and-preserve.md	步骤 1，用于确定意图、区域、平台、宽松默认值和外观描述词
references/variations.md	一旦模式设为探索模式便立即读取；按文件说明替代第 2 至 8 步
references/taste.md	步骤 4 至 6，用于引用的屏幕未展示的每个部分
references/before-after-board.md	步骤 7
references/report.md	步骤 8
references/reference-board.md	仅当用户要求查看参考看板时
references/answering-a-challenge.md	仅当用户询问原因时

基本规则

用户读到的每项主张都有依据。依据只有三种：

1. 源内容：用户带来的、读过或测量过的屏幕：其中实际存在的元素、数值、位置或状态。
2. 用户的话：引用原话，或沿用用户的表述。
3. 你查看过的 Mobbin 屏幕：注明名称，并链接到其 mobbin_url。

每项主张都要说明依据的强弱：两个或更多产品的屏幕都显示了这一点，即为先例；只有一个产品，则为示例；没有产品，就是你自己的判断，它只能补充方案中的局部，不能构成完整方案。在报告中，每个条目下方的 References 行会说明这一点。其他地方则在句子中说明：列出产品名称，或以“My opinion is to”开头。没有依据的主张应删除，而不是弱化措辞。

以下规则适用于用户读到的所有文字，从最初的范围界定选项到对“为什么”的回答：

• 第 3 步之前不使用 Mobbin。 搜索完成并查看搜索结果中的图片之前，不引用任何内容，因此范围界定阶段只能使用源内容和用户的话。
• 不提及未查看过的产品类别。 不说“多数应用”“同类最佳”“行业标准”或“高转化付费墙的做法”；要逐一列出你查看过屏幕的产品。
• 不凭记忆引用研究、原则或启发式。 不说“研究表明”，不提法则名称，也不搬出权威名号，因为这项技能没有研究资料库。
• 任务流程和 taste.md 是方法，不是记忆。 某个问题的原因应指出它阻碍了任务流程中的哪一步；references/taste.md 用于做判断，但绝不向用户提及它。
• 不声称行为结果。 绝不说这次运行会提高转化率、留住用户、建立信任或减少摩擦：问题要指出它阻碍了哪一步，改动要指出它做出了什么决定，用户提出的指标则沿用用户的表述，绝不声称指标已发生变化。
• 没有具体对象支撑，就不使用描述质量的形容词。 “过时”“杂乱”“现代”“整洁”或“高端”只能出现在用户的话中，或与其描述的部分放在一起。
• 测量用像素，描述用所见。 尺寸、坐标、十六进制值和比例留在你的笔记中；用户看到的应是它们的含义（“关闭按钮现在达到平台规定的最小尺寸”）、屏幕上的数字、相对于可见部分的位置，以及你实际测量或计数过的数字。
• 不声称图片中看不到的内容。 描述改动的句子只能指出读者在图片缩放比例下能看出的 BEFORE 和 AFTER 差异，绝不提及计划做出却未实现的内容。

输入

用户会以任何形式提供目标：工作目录中可渲染的代码库、图片、设计文件、实时页面，或任何连接的工具所能呈现的内容。该形式就是源内容。使用环境提供的工具读取它，然后一视同仁地处理所有源内容：区域、元素、可见状态、配色、字体与间距比例，以及这些内容所隐含的设计系统。形式只决定如何命名区域、状态从何而来，以及渲染结果以何种形式返回。

用户也可能提供自己的表述（投诉、目标、约束或风格）和参考资料（截图、Mobbin 链接、产品名称），用于确定重新设计的目标；同时仍需将 Mobbin 屏幕作为参照，避免结果变成对某个产品的复制。Mobbin 通过 search_screens、search_sections 和 search_flows 提供参考；如果这些功能未连接，请用一行说明，然后停止，因为这项技能不会凭记忆运行。

模式

有两种模式：在调用时通过 --explore 或 --targeted 设置；如果两者都未指定，则在第一个范围界定问题中询问（references/scoping-round.md）：

• Explore（--explore）：最多提供三个变体，每个变体都从一个方向完整构建，并与基线并列展示为模型图。用户选定之前，不会应用任何更改。阅读 references/variations.md 并遵循其中的说明；该文件会指出它替代了下方的哪些步骤。
• Targeted（--targeted）：用户勾选的问题，在一个设计中修复并应用到源文件，按下方步骤执行。

输出

渲染结果采用与源文件相同的形式：

源文件	渲染结果
代码库	对源文件的编辑
设计文件	在原始文件旁创建一个新画板，并使用设计工具自带的工具编写，以保留基线
工具只能读取的设计文件	使用产品自身的配色、字体和间距制作的模型图，并在范围界定时说明一次
图像	PNG
其他内容	最接近上述三种形式的一种，并在范围界定时说明

在承诺创建画板之前，先确认能否写入画板，因为大多数设计工具连接只能读取。在探索模式下，所有源文件都会先渲染为模型图；表格适用于用户选定的变体。

如果可以捕获渲染结果，回复应先展示更改前后的图像（步骤 7），然后提供报告和结尾菜单（步骤 8）。只有在用户提出要求时，才提供参考图板和参考列表。

1. 界定目标

先阅读源文件，确保每个问题都指向产品中真实存在的部分。

用一行写出任务：谁来到这里、想做什么，以及怎样才算完成。“团队管理员选择方案并付款，付款确认后即为完成。”任务来自源文件和用户的话语，绝不来自参考资料。组件或区域要说明自己在所在屏幕任务中的作用：筛选行的作用是缩小表格范围。如果任务无法用一行说清，第一个问题就先询问任务是什么。

列出目标可能呈现的状态（加载、空白、错误、禁用、溢出、窄视口），并标记每个状态是当前已显示、源文件中存在但无法触达，还是缺失。如果来源是一张图片，除非用户另有说明，否则只存在图片中呈现的状态。把清单留在笔记里：只有在某个已勾选问题需要时，才构建缺失状态。

沿着路径，以那个人的身份，从进入页面走到完成任务，依次检查任务路径的六个方面。每个阻碍都是一个候选问题。

1. 路径清晰。 视线落在任务的第一步；一个主要控件即可完成任务；路径之外没有任何内容争夺注意力，包括区域外围的外壳已经承担的功能。
2. 每项决策所需的信息都在旁边，不必滚动或点击才能看到。
3. 任务所需的内容一项不少。
4. 每个标签和值都准确。 控件的行为符合其说明；没有标签的图标，必须是平台或产品已经教会用户识别的图标（关闭、分享、返回、重复出现的选项卡）。设计系统中一贯使用的无标签图标属于风格，不是问题。重复显示的值必须一致，总计必须与各项明细相符。
5. 目标涉及的每种状态都能让用户完成任务，或说明无法完成的原因。
6. 平台的最低标准都得到满足：目标尺寸、最小字号级别、系统自身配对颜色之间的对比度。

记录每个候选问题，注明它阻碍了哪一步，并写成渲染结果能体现问题已修复的表述：“座位数步进器位于定价所依据的方案选项下方，因此用户选方案时看不到价格。”“看起来过时”还不是候选问题，除非指出它拖慢了任务中的哪一步。第 6 步也要用同样的方式检查渲染结果。

然后提出界定范围这一轮的问题，按 references/scoping-round.md 的说明进行，并参考 references/scope-and-preserve.md 了解意图、区域、共享组件和平台。每个回答和假设都要记录在范围说明中。

2. 锁定基线

完整阅读目标和它使用的设计系统：令牌或可见的调色板、组合使用的组件、主色、间距和字体层级。

按以下顺序写出必须保留的保留清单：

1. 产品领域。 产品仍属于同一类产品；来自其他领域的参考资料只能借鉴结构。
2. 设计系统与主题。 只在设计系统内调整结构，绝不换成参考资料中的设计系统。
3. 文案与数据。 屏幕保留自身的文案和数据。新标签要使用该产品自身的术语，绝不照搬参考资料。
4. 目标之外的所有内容。 如果目标是一个组件或区域，屏幕其余部分不得更改。按源文件中的形式标明边界：代码中的文件和符号，或图片中可见的边缘。
5. 用户要求保留的内容，来自“保留”问题；还要列出目标中已经有效的部分，并注明具体内容，因为更改它所付出的代价可能大于收益。

修订问题列表：选中的问题，每个都要对应其阻碍的步骤，并各自安排一个改动；最多五项，确保报告和图片易于阅读。其余候选问题全部记入暂缓记录，注明对应步骤和发现位置。第 3 步和第 6 步时要补充记录；该记录不会出现在报告中，但会用于结尾菜单，因此每轮检查中发现的问题都不会遗漏。

3. 搜索并锁定参考

探索问题空间。 第一次调用前，先调用 Mobbin 的 search 技能，并按其规则搜索。每个问题先用一个查询；第二次提取前，最多再用两个查询，并查看每张图片。只有当解决问题的决策在屏幕中可见、而不是只出现在标题中时，这个屏幕才算数。按产品计数，而不是按截图计数：同一款应用的 20 张截图只算一个先例，并引用最清楚展示该决策的截图。优先选择与任务相符的参考，而不是外观相似的参考；绝不混淆意图：区块屏幕无法为组件提供参考。

确定方向。 如果相关屏幕在结构上存在分歧（例如标签页与一排胶囊按钮，或可执行操作的卡片与可跳转的卡片），就按各自共有的结构决策将它们分组。

明确立场。 为整个目标选定一方，而不是针对每个问题分别选择；如果有三方之争，就选能解决最多问题的一方。记下该方的应用、它们共有的决策，以及一句说明其为何适合这项任务的话；理由要足够具体，不能同时为另一方辩护。完整采纳这一方的做法：它的控件、层级和尺度，并使用产品自身的组件和字体。另一方的做法不予采用，只在报告中用一个分句提及。参考中揭示、但调研时遗漏的差距，应连同揭示该差距的屏幕一起记入 Deferred 记录。

标记所选一方的参考，每项注明应用、mobbin_url、它相较基准方案所采用的做法（采纳项），以及你不会沿用的内容（弃用项：浅色或深色背景、强调色、字体、文案、示例数据）：

• 锚点：最能展示该方向的屏幕。改版主要基于这些屏幕构建。通常选 2 到 4 个；如果搜索只找到一个，选 1 个也可以。
• 候选池：该方向的其他屏幕。某项做法可以引用其中一个屏幕来呈现单一细节，例如空状态或标签，但不会由此影响其他内容。
• 已排除：无法解决任何问题的屏幕，将其保留在笔记中，写明一句排除理由，且绝不使用。

4. 规划修改项

修改项是对目标的一项改动，用于解决一个已勾选的问题，并且有侧边所选产品的决策界面作为依据。每个问题写一项，最多五项，按各项能解锁多少工作排序。能带来多个控件的控件模式仍算一项：上限限制每轮处理的问题数，绝不限制对侧边所选产品的完整还原。

每项修改都列出其依据清单：展示该项具体决策的锚点界面和产品池界面，并为每个界面列出其 mobbin_url。

• 引用决策，而非元素。 若修改项为徽标行添加标签，就需要引用带标签的徽标行界面；只有徽标行不算依据。
• 引用被移走内容的去处。 若修改项会把某项内容挪开，就要在引用界面中展示其去处；否则报告必须说明该位置是你的判断。若侧边界面中没有某个容器、行或区块，就将其移除、引用相应界面，并在报告中说明。
• 没有界面，就没有修改项。 依据 references/taste.md，判断只能补充界面未展示的细节（位置、措辞），不能据此提出完整修改项。

删除或修正以下修改项：

• 为其他修改项已涵盖的问题增加第二项改动；
• 移除基线中已有的内容（计划、链接、行、操作、徽章、标签）：这些内容必须保留在界面上，放在引用界面所示的位置；若引用界面未展示位置，则保留在基线中的原位置；
• 将内容移出当前界面：本轮必须保留；结束菜单中可将该修改项列为后续事项，并引用展示其移至何处的界面；
• 实现侧边所选产品中没有任何产品采用的做法，或仅仅因为基线原有样式而保留旧样式；
• 在没有明确问题且侧边所选产品中至少两个产品都采用某项做法时，增加常见细节（心愿单爱心、评分行、徽章、悬停抬升、骨架屏、每个标签都带图标、额外的微文案、渐变覆盖层）。

然后编写修改项表，每项修改占一行：问题、侧边、依据清单、添加内容、移除内容。没有问题或依据清单的行，或违反保留清单的行，都应删除。未列入表中的内容一律不得构建。

5. 应用

按照 Outputs 中为源指定的形式构建修改项表，只更改目标：除非另有要求，否则绝不更改主题、主题令牌或共享组件。保留清单包括请求中要求保留的所有内容；构建时意味着：

• 只使用产品的设计系统构建。 使用现有组件、颜色令牌、间距和字体比例，并由主题处理深色模式。绝不添加一次性控件、原始颜色值、新库、新字体或新图标集。
• 采用参考的结构，而非外观。 绝不照搬参考的浅色或深色背景、强调色、字体、徽标或插画风格。

引用的界面决定每项修改的内容；references/taste.md 决定这些内容如何融入当前产品。

确保交互真实：控件必须驱动实际状态，而非仅作装饰。不要接入任何未由修改项要求的功能（分页、排序、新数据或派生值）。只有当某项修改让某个状态变得可访问，且有引用界面展示该状态时，才渲染该状态。

6. 对照任务检查渲染结果

截图前，请站在任务指定的用户角度检查渲染结果，完成任务检查流程中的六项检查，以及仅针对渲染结果的三项检查：

• 只渲染通过某项操作变为可达的状态；
• 目标范围之外的内容没有移动；
• 没有违反 references/taste.md 中的任何不可妥协要求。

只查看渲染结果：不要进行新的搜索。

每项检查都判定为通过或失败。在目标范围和保留列表内修复失败项，然后重新运行所有检查，因为修复可能会使原本通过的检查变为失败。最多进行三轮。

• 如果某项失败需要新的操作、新的参考资料或目标范围之外的内容，则不予修复：撤销导致该问题的操作，并在问题报告中说明。
• 第三轮后仍未解决的失败项，也要以同样方式撤销导致问题的操作。
• 没有由任何操作导致的问题，记入延后处理记录。

然后，如果环境提供检查命令，请运行该命令并修复其报告的问题。重新查看渲染结果，检查是否包含设计系统之外的内容：非令牌颜色、不符合比例尺的值、自行构建的主题、外部组件或资源、新依赖项。每项都必须修复或在报告中说明。

7. 渲染前后对比图

如果环境能够截取渲染结果，用户会先看到它，再阅读相关说明。按照 references/before-after-board.md 中的要求构建对比图。AFTER 面板必须展示应用更改后截取的结果，绝不能凭记忆重新绘制。

8. 报告

按照 references/report.md 中的要求，在 plain-writing 下撰写报告。

仅在用户提出要求时：

• 参考资料对比图：用户在结束菜单中选择该项，或要求以图片形式查看参考资料时，按照 references/reference-board.md 中的要求构建。
• 渲染后的原因说明（“为什么用列表而不是表格？”）：按照 references/answering-a-challenge.md 中的要求作答。为渲染结果辩护；只有出现新事实时才改变立场。