taste-skill-swiftui 是做什么的？

模型构建的应用界面看起来像是模型见过的所有应用界面的平均值：一个包含四个标签的 TabView、一个大标题、一个包含多个圆角卡片的 List，每个卡片中有一个带色调方块的 SF Symbol、一个蓝色渐变“开始使用”按钮、一个由三个符号页面组成的引导页、一个带有发光效果的付费墙。其中没有什么不对，但也没有什么是经过深思熟虑的。

此技能通过四种方式用决策代替这些默认值：

脚本处理方向，你从中选择。 当要求设计一种外观时，模型每次都会选择类别默认值。scripts/draw.mjs 从十二个经过研究的方向中抽取三个；你选择最能体现主题创意的一个，然后它会进一步处理字体、调色板、形状、动效和屏幕蓝图。
创意来自主题。 最好的应用是建立在从主题本身（其输出、其对象、其仪式、其印刷品）提取的内容之上，而不是建立在样式之上。
原生优先，自定义有目的。 每个元素都按照阶梯方式（如下所示）进行构建。允许自定义组件，并且在创意需要时鼓励使用，但它们必须承载所有原生行为。
你审视你的作品。 scripts/capture.sh 在设备矩阵上以浅色和深色模式、默认和辅助功能字体大小拍摄应用截图；评审标准评判截图；修复、再审视。

去除装饰只完成了工作的一半。一个失去了色调方块、卡片和渐变但没有任何收获的屏幕是空洞的。另一半是实质内容：更大的字体排版、整片的颜色区域、属于这个主题世界的真实图片或手绘物体、每个屏幕上承载完整的内容，以及用户能做的一件只有这个应用才有的独特功能。

在下面的命令中，<skill> 代表此技能的文件夹。从项目根目录运行它们；工作文件会放到 .taste-skill/ 文件夹中。脚本需要 Node 18+。capture.sh 需要 Xcode 和已启动的模拟器。当 ~/.claude/bin/devlock 存在时，将每次 xcodebuild 和 simctl 的运行都包裹在 devlock run 中（并行构建之前已达到进程限制）。

原生阶梯

仅按照创意要求攀登，并在报告中记录每个第 3 级的组件。

系统组件，系统外观。 NavigationStack、TabView、List、Form、Toggle、Picker、Menu、ContentUnavailableView、带 detents 的 .sheet、ShareLink、Chart、ProgressView。免费获得：Dynamic Type、VoiceOver、Reduce Motion、RTL、Liquid Glass、键盘和指针。对于每个职责是平台职责的控件，都使用这些。
系统组件，已样式化。 相同的组件，你的标记：ButtonStyle、LabelStyle、ToggleStyle、ListRowBackground、scrollContentBackground(.hidden)、tint、fontDesign、fontWidth、containerShape。这是大多数方向的体现之处。
自定义组件。 仅在没有系统组件能够承载创意时使用（例如拨号盘、标尺、票据、舞台、时间轴脊柱）。自定义组件必须附带：通过 @ScaledMetric/Font.custom(relativeTo:) 实现的 Dynamic Type、44×44pt 的最小点击区域、带有标签、值、特征和可调整操作的 accessibilityElement、Reduce Motion 路径、通过 sensoryFeedback 实现的触觉反馈、深色模式、RTL (layoutDirection)、iPad/Mac 上的焦点和指针状态，以及每个状态的预览。一个需要一长串说明的控件应该重新设计，而不是添加说明。

永远不要重建平台已有的内容：不要手绘标签栏、导航栏、开关、警告、表单或键盘附件，除非创意离不开它。永远不要手写模糊面板；Liquid Glass 来自系统栏、工具栏和浮动控件上的系统玻璃 API。

从 Web 到移动端：原始规则的映射

Taste-skill (Web)	此处 (原生)
页面 vs 应用界面	应用几乎总是第二种。首次启动界面、引导页和付费墙是组合式界面（按照运行流程）。列表、设置、表单和详情界面是工作式界面（遵循 `references/screens.md`）。
主视觉区	启动后的第一个界面（或主页标签）。它在三秒内回答“这是什么，我要做什么”，使用大字体或大物体。
标题在任何宽度下最多两行	在 iPhone SE 宽度和 iPad 上使用默认大小的两行，在辅助功能字体大小时换行（从不截断）。
等宽外边距，无拥挤区域	使用系统布局边距（16/20pt）；iPad 和横屏模式使用自己的布局（分屏视图、侧边栏、两列），绝不用居中的手机列。
真实图片最低要求（四张）	每个关键屏幕上有一张真实或手绘的视觉元素。SF Symbols 仅用作功能性图标，从不作为图片使用。
滚动场景	`scrollTransition`、`visualEffect`、`matchedGeometryEffect`、`navigationTransition(.zoom)`、`KeyframeAnimator`、`PhaseAnimator`、`TimelineView`。
动态事物	令人惊叹的时刻：一个只有此应用才有的交互，带有触觉反馈，单手可操作。
在真实浏览器中的 `inspect.mjs`	在模拟器中的 `capture.sh` 加上对 Swift 源码的 `lint.mjs`。
动效最低要求	在首次运行和核心流程中至少有六个有目的的动效时刻；每个动效都有 Reduce Motion 的备选方案。
无毛玻璃效果	没有手写的模糊卡片。系统毛玻璃效果在系统界面元素上是可以的。
无等宽字体	仅在对齐数字时使用 `.monospacedDigit()`。在代码外部绝不要使用 `design: .monospaced`。
无细线	系统绘制的列表分隔线是好的。没有装饰性的 `Divider`，没有 1pt 描边的卡片。
底部 = 精心设计的结尾	长屏幕的最后一行，或流程的结束状态，是经过设计的，而不是留白空间。

运行流程

按顺序执行这些步骤。第 1-5 步需要几分钟，决定了应用是否优秀。

1. 阅读简报和项目

找出真实存在的内容：主题、受众、用户在第一分钟必须完成的一件事、平台和部署目标、现有的设计系统或标记、真实存在的资源（摄影作品、产品照片、插图、素材、图像工具），以及在重新设计中必须保留下来的内容（模型、意图、小组件、购买、本地化）。不要围绕你不拥有的资源进行规划。如果需求模糊，做出决定并用一句话陈述你的理解；只有在缺少的事实会阻碍工作时才提问。

盘点主题：列出八到十二个属于这个客户且不属于任何竞争对手的东西。它的名字及其含义；简报中的数字（分钟、克数、价格、连续记录）；它所面对的约束（每天一次、离线、一次点击）；它的材料和颜色；它的仪式和时间；它所在世界的印刷品（票据、标签、收据、时间表、护照印章）；它的声音；它的物理手势（摇晃、吹气、长按）。第 4 步中的创意来自这个列表。

2. 编写论证

将应用列为一组带有佐证的声明，每个首次运行和核心流程的界面一行：

界面：声明 -> 用户看到或执行的内容作为佐证。

删除任何没有声明的界面。这样你就可以避免常见的启动画面、三个引导页面、权限请求、付费墙、四个标签的标签栏这种千篇一律的序列。只有当引导页能让用户执行一次核心功能时，它才值得存在。

3. 绘制方向

node <skill>/scripts/draw.mjs --kind <kind> --brief "<一行关于主题的描述>" \
  --screens <按照你的论证顺序排列的角色> [--tone <tone>] [--have <assets>] \
  [--keep palette,type] [--platform ios|ipad|watch|mac|vision] --options 3

这会生成三个方向。将每个方向与你的盘点进行对比：哪一个能够承载只有这个客户才有的独特元素？选择那一个，而不是你最熟悉的一个，然后写一行理由。然后生成完整的方案：

node <skill>/scripts/draw.mjs <相同参数，不带 --options> --direction <所选 ID>

--kind：node <skill>/scripts/draw.mjs --list kinds（工具、健康、金融、游戏、儿童、社交、媒体、生产力、生活方式、创意、商业、其他）。
--screens：来自 --list roles 的角色（引导页、首页、详情、创建、结果、设置、付费墙、空状态）。
--tone：安静、大胆、温暖、技术、有趣、奢华、编辑。仅在简报要求时使用。
--have：真实存在的资源：photography、product-photo、illustration、video、3d。如果没有则省略；绘制过程会避免使用依赖这些资源的构图。
--keep palette,type：当品牌或设计系统已经固定了它们时使用。绘制过程仅处理构图、形状和动效；你将系统的值映射到角色上。
--seed <n> 使结果可重复；方案会打印它使用的种子。

对照主题检查调色板。 生成的调色板既是一组颜色比例（一个底色、一个墨水色、一个强调色、可选字段），也是一组颜色。如果它与主题本身的材料冲突，重绘一次，或者保留比例并从主题中提取颜色，并说明这一点。

4. 找到创意

方向是一种构图方式。创意是让应用属于这个主题的东西。在构建之前，从主题本身填充两个空白：

在这个应用中，[属于主题的某样东西] 变成了 [方向要求的载体]。

从以下方面寻找：它的输出（它产生的东西，以材料形式展示）、它的对象（它的形状，以剪影形式）、它的名称（能够承载图片的字母）、它的地点、它的仪式（应用执行的一个序列）、它的手工艺品（票据、标签、收据）、它的反面。

竞争对手测试：将最接近的真实竞争对手放入句子中。如果仍然成立，则创意属于该类别。“简洁现代”不是一个创意。

令人惊叹的时刻（动态事物）。 给应用一个每次使用都不同的交互，基于创意构建：向麦克风吹气，蜡烛摇曳；设置剂量并读取真实的半衰期曲线；折叠手机，磁带播放。它使用真实内容，单手用拇指操作，通过 sensoryFeedback 提供触觉反馈，有 Reduce Motion 路径，并且从不阻塞任务。它是一个单独的功能，不是一个游乐场。它在第 6 步中构建，而不是在最后作为动效添加。

5. 编写文案

在构建视图之前，先编写整个文案副本（纯文本），遵循 references/copy.md，并从第一次提交开始就将每个字符串放入 String Catalog（Localizable.xcstrings）。每个标题在默认大小下最多两行；每个界面一个主要操作，以其功能命名（从不是“开始使用”、后面没有内容的“继续”、“了解更多”）；现在编写空状态、错误和权限文案，而不是以后。证据从不虚构：没有虚假评论、用户数量、奖项或新闻。

6. 构建它，仍然如此

在脑中关闭动效进行构建。工作顺序：

标记。 从方案中提取 Palette/Theme 作为带有浅色和深色变体的资源目录颜色（或 ShapeStyle 标记枚举）、一个 Typography 枚举、一个 Metrics 枚举（间距、圆角、一个形状规则）。所有下游内容仅引用标记。视图中没有 Color(red:)、没有 .font(.system(size: 17))。
第一个界面，完全按照其蓝图描述， 在 SE 宽度、标准、Pro Max 和 iPad 上。在创建其他任何东西之前，先把大的做大，小的做小。
根据其蓝图构建每个界面， 使用此项目的内容。相邻界面不能共享相同的布局。将创意带入每个界面， 包括设置、付费墙和空状态；最常见的失败是有一个独特的首页，后面跟着千篇一律的 Form。
图像内容， 按优先级：项目自身的图像；生成的图像（如果你有图像工具）；来自开放收藏的属于主题世界的真实图片，并记录许可（references/imagery.md）；在代码中绘制（Shape、Canvas、Path），作为调色板中一致扁平图形语言；仅使用字体和颜色。SF Symbols 仅用作功能性图标。
来自第 4 步的令人惊叹的时刻， 放在能证明其声明的界面中。
充实度。 将每个界面视为一张海报：一个主导元素及其承载的内容。一个大部分是空白背景的界面是构建不足的。运行文本使用完整的墨水色，body 或更大。
框架。 统一的边距系统。每个界面都有标题（导航标题或大的显示标题），每个列表部分都有命名它的页眉。
状态和语义。 所有状态：加载中、空状态、错误、离线、权限被拒、成功、已禁用、首次运行、长内容、辅助功能字体大小、RTL。真实的 Button、可见的焦点、标签、仅在标签无法承载信息时使用的 accessibilityHint、VoiceOver 顺序、遵循 Reduce Motion 和 Increase Contrast。
平台基线（来自全局规则）：包含 en-US、en-GB、en-AU、en-CA 和 es-MX 的 String Catalog；仅在积极时刻后，受计数器和安装天数限制，每个版本一次地调用 requestReview；触觉反馈；深色和浅色模式；当应用有核心操作时使用 App Intents。

当你在某个决策后面临细节问题时，阅读 references/type.md、colour.md、layout.md 和 components.md；以下是简短形式的规则。

7. 关卡检查

node <skill>/scripts/lint.mjs <Swift 文件或文件夹>
<skill>/scripts/capture.sh <bundle id> .taste-skill/capture   # 已启动的模拟器

lint.mjs 扫描 Swift 源代码中的禁止模式、固定短语和缺失的基线条件（String Catalog、Reduce Motion、触觉反馈）。capture.sh 在每个已启动的模拟器上以浅色和深色模式、默认和辅助功能字体大小启动安装的应用，并保存截图。修复每个 FAIL；将每个 WARN 视为错误，除非你能用一句话向设计师解释。持续运行直到没有 FAIL。一行可以通过行末注释 // taste-skip 选择退出检查；记录原因。

重新运行，直到没有 FAIL，然后进入评审循环：

# 人工评审：将所有 .taste-skill/capture/*.png 拖到文件中的评审链接处
open .taste-skill/capture/

对于每个界面，检查以下高标准的评审点：

此界面承载了创意吗？ 它是否从主题中提取了有意义的内容？
最大元素是什么？ 它是否最大？它是否承载了该界面的声明？
内容是否真实？ 在浅色和深色模式下，在默认和辅助功能字体大小时，它是否导航到真实数据并看起来很扎实？
工具栏/标签栏是否显示并且可点击？ 每个按钮是否有标签？在辅助功能字体大小时，工具栏是否不拥挤？
是否使用 Liquid Glass？ 确保所有模糊面板使用 .ultraThinMaterial、.thin、.regular、.thick 或 .ultraThick。没有手写模糊滤镜。
此界面是否与其他界面不同？ 它是否使用了项目中其他地方不存在的独特布局或视觉元素？
是否是最佳方向？ 是否选择了最好的一个？

评审总结

如果通过：清理并填写报告（references/report.md）。包含指向 .taste-skill 中生成的工作的链接。

如果未通过：回到第 3 步。

参考

这个文件夹中的 references/ 包含详细的指南：

type.md – 排版规则（大小、粗细、行高、比例）
colour.md – 颜色规则（对比度、比例、辅助功能）
layout.md – 布局规则（边距、间距、网格）
components.md – 组件规则（系统、样式化、自定义）
copy.md – 文案规则（风格、长度、结构）
screens.md – 每个界面角色的蓝图
report.md – 在每个步骤中完成的报告模板
imagery.md – 图像来源和许可跟踪

taste-skill-swiftui