别让深色模式靠补丁：用 AI + Xcode Color Set 管好 iOS 颜色 (2026)

深色模式最容易错在「颜色名字写死」

页面一开始只有一个浅色版本时，把按钮写成蓝色、背景写成白色，似乎没有问题。等用户切到深色外观，返工通常从一处颜色开始，最后扩散到按钮、卡片、分割线、图标和提示文字：同一套代码里到处散落着不同的固定色值。

Apple 把 Color 定义成会适应当前环境的颜色表示；从 Asset Catalog 的颜色集按名称创建颜色时，系统会在渲染时取对应的颜色。1 2

这意味着你可以把「这个颜色用来做什么」写进名字，再为浅色和深色各配一个值。页面代码只引用名字，颜色变化留在 Xcode 的资源里管理。Color Set 不替你做设计，也不会自动证明文字对比度足够；它解决的是颜色分散和外观切换时的重复修改。

先写颜色的用途，再决定色值

不要让 AI 从一串 Color(red:green:blue:) 开始。先拿一个真实页面，列出颜色承担的动作或层级：

使用位置	建议的语义名字	需要保持的含义
主按钮、选中状态	`actionPrimary`	用户可以操作，或当前项目已被选中
页面和卡片底色	`surfacePrimary`	内容所在的主要表面
次要说明文字	`textSecondary`	信息存在，但优先级低于标题和主要内容
错误提示、失败图标	`statusError`	当前状态需要处理，不是普通装饰

这些名字不是 Apple 规定的固定清单，是你给当前产品建立的约定。名字要表达用途，不要写成 blue2、grayDark 或 newColor。同一种颜色如果在一个页面表示「可点击」，在另一个页面表示「已完成」，就不要急着合并；颜色含义不同，后续验收也会不同。

在 Xcode 里建一个可切换的 Color Set

Apple 的 Develop in Swift 教程给出了同一条操作路径：在 Assets 中新建颜色集，配置外观，再让代码通过 Color 引用这个资源。3

用一个颜色先跑通，不要一次重做全 App：

在 Xcode 的 Project navigator 里打开 Assets.xcassets。如果颜色较多，先新建 Colors 文件夹。
点击资源列表底部的加号，选择 Color Set，命名为 actionPrimary。
在右侧检查器的 Appearances 中启用浅色与深色变体。浅色值服务于浅色外观，深色值服务于深色外观；如果某个颜色确实两种外观都应相同，再选择不区分外观的配置。
分别选中两个色板，输入你的产品已经确认过的颜色值。不要让 AI 凭空发明品牌色；没有确定值时，先使用明显的占位色，并把「待定」留在验收记录里。
在一个按钮或标签上替换引用，确认资源名称和代码中的名称完全一致。

SwiftUI 中的最小引用可以是：

Button("保存") {
    save()
}
.foregroundStyle(Color("actionPrimary"))

Apple 的教程也说明，Assets 中命名的颜色集可以通过 Color 引用，和其他资源按名称使用的方式相同。3

让 AI 只替换颜色来源

把颜色规则、资源名称和当前页面代码一起交给 AI，限制它只做局部修改：

请只修改这个 SwiftUI 页面中的颜色来源，不要改变布局、间距、字号、交互、导航和数据逻辑。
先找出页面里表达以下含义的颜色：主操作、页面底色、次要文字、错误状态。把固定颜色替换成这些 Color Set 名称：actionPrimary、surfacePrimary、textSecondary、statusError。如果某个颜色的用途无法判断，列出来，不要擅自合并。
先返回修改计划，再给出最小代码差异。不要新建颜色资源，不要修改 Assets.xcassets 的其他资源，不要把所有颜色都替换成同一个品牌色。最后列出浅色、深色、大字号和增加对比度时需要检查的控件。

如果 AI 直接把所有 Color.blue 换成 Color("actionPrimary")，先停下来。固定蓝色可能同时被用在链接、选中态和装饰上；批量替换会把不同产品语义压成一个颜色。先让 AI 输出「原颜色 - 所在控件 - 产品含义 - 目标 Color Set」四列，再逐项确认。

Apple 的深色模式文档把目标说得很直接：更新颜色、图像和行为，让 App 在深色模式激活时自动适配。4 这里的「自动」只会发生在你已经提供了正确资源和正确引用之后，不是把固定色值放进 Color Set 就万事大吉。

用 Xcode 验收颜色有没有真的换对

颜色管理最容易出现一种假通过：页面切成深色了，但文字、图标或按钮的产品含义已经不清楚。用同一个页面、同一组数据逐项检查：

浅色外观：打开页面，确认主操作、底色、次要文字和错误状态都使用预期颜色；选中态不能和普通文字混在一起。
深色外观：切换到深色模式，确认同一控件的含义没有变化，只是颜色值适应了背景。检查卡片、分割线、占位内容和禁用状态，不要只看首屏按钮。
颜色语义：故意制造一个错误，确认 statusError 仍然只表示错误；再完成一次成功操作，确认成功状态没有误用错误色。颜色应该和文字或图标一起传达状态，不能成为唯一线索。
大字号：把动态字体调大，检查颜色变化没有把文案截断或把按钮挤出屏幕。Color Set 不负责布局，颜色修好后仍要看完整的文字。
增加对比度：打开 Xcode 或设备提供的对比度相关环境，检查主要文字、按钮标签和图标仍能辨认。若一个自定义颜色在这个场景下不可读，回到色值和用途表，不要用阴影或动画掩盖问题。
资源缺失：临时把一个引用名称改错，再让 AI 解释它如何发现和修复；随后恢复正确名称。这个动作能检查你是否知道颜色来自哪个资源，而不是只凭 Preview 中的某个偶然结果判断成功。

Apple 的人机界面指南把颜色描述为传达状态和反馈的界面工具。5 所以验收时不要问「看起来够不够漂亮」，先问「用户能否在两种外观下读出同一个动作和状态」。

PM 今天可以独立完成的清单

选一个真实页面，只处理主操作、页面底色、次要文字和错误状态四类颜色。
为每类颜色写用途型名字，不使用 blue1、grayDark 这类色值型名字。
在 Assets.xcassets 中创建一个 Color Set，并配置浅色与深色变体。
让 AI 只修改当前页面的颜色引用，先输出颜色用途映射，再给代码差异。
在浅色、深色、大字号和增加对比度环境下各看一次。
制造成功和失败两种状态，确认颜色没有把产品语义弄反。

如果今天只做一件事，就选一个最常改色的按钮，把它从固定颜色改成一个有用途名字的 Color Set，并亲手切换一次深色外观。你会马上看见：真正需要 PM 决定的不是「这次用什么蓝」，而是「这个颜色在产品里代表什么」。

别让深色模式靠补丁：用 AI + Xcode Color Set 管好 iOS 颜色