AI 辅助 UI 治理：从项目级治理到十类专项场景

AI 已经可以修改 CSS、补齐组件状态、调整响应式布局，也可以按照设计规范重做一个页面。真正困难的部分不在“能不能改”，而在于：它是否理解项目现状，是否只改了被授权的范围，以及改完之后有没有证据证明结果更好。

我把这类工作称为 UI 治理。它不是把所有页面改成同一种样式，而是把功能结构、视觉规则、组件行为、多设备与主题呈现、生命周期放进一套可以持续判断、分批执行和回归验证的流程里。

对于从 UI 设计师转型为 AI 设计师的人来说，你不再只负责视觉稿，而是借助 AI 完成从问题诊断、方案制定、执行修改到验收回归的全过程。你需要把设计判断转化成 AI 能执行的计划。

本文的使用方式很简单：问题明确时，选择专项场景 → 复制提示词发给 AI → 确认 AI 给出的方案 → 发执行指令让 AI 改 → 按问题类型验证结果；问题不明确或影响范围较大时，直接使用项目级治理提示词，让 AI 制定整体治理计划，再按计划执行。AI 负责扫描、整理和执行，人负责确认问题、授权范围与最终结果。

轻量使用三原则：

1. 重复工作交给 AI：让 AI 扫描代码、整理问题和运行检查；问题是否成立、修改范围是否合理，由你确认。
2. 证据跟着问题走：视觉、响应式和主题问题看截图；信息架构和交互问题在浏览器中完成代表性任务；逻辑改动运行相关测试。所有修改都要检查代码 diff。
3. 代码扫描只提供线索：扫描结果可以定位候选问题，但不能单独证明页面体验、用户任务或交互状态已经正确。

适用说明：本文方法主要面向已有项目的 UI 治理。对于新项目，可以优先使用场景 7（主题与 Token 适配）、场景 5（组件规范治理）和场景 10（规范、文档与版本治理）。如果你面对一个完全陌生、问题较多或影响范围较大的项目，直接做项目级治理；它是一个完整的总场景，十类专项场景按治理计划需要调用，不是必须先选的入口。

一、UI 治理的五个维度

同一句“页面看起来不清楚”，可能对应不同层次的问题。先判断问题发生在哪个维度，后面的治理方案才不会互相污染。

组件 API 指组件对外暴露的接口，包括 Props（属性）、回调函数（如 onClick、onChange）和插槽内容。在本文中，所有“API”均指组件接口，不是网络请求接口。

UI 治理关注以下五个维度：

1. 功能布局与信息架构：功能如何分组，页面层级是否清楚，主要任务能否被找到，操作路径是否过长或重复。
2. 视觉规则：颜色、排版、间距、对齐、圆角和布局密度是否有可复用的语义。
3. 组件与交互：按钮、表单、弹窗等组件的语义、组件 API、状态和反馈是否一致。
4. 多设备与主题呈现：响应式适配、主题切换、品牌换肤和高对比度模式是否正确呈现。
5. 生命周期：规范、组件、图片和图标如何发布、迁移、弃用和删除。

具体问题按下面的索引进入第二节的治理场景：

• 功能结构与信息层级——功能分组混乱、主次不清、入口难找、任务路径复杂 → 场景 1。
• 视觉与排版——布局对齐、字号、行高、间距、密度和层级表达不统一 → 场景 3。
• 交互状态与内容反馈——点击、加载、成功、失败、重试、空数据、焦点和键盘状态缺失 → 场景 2。
• 组件语义与使用规范——组件层级、组件 API、复用方式、状态覆盖和可访问性问题 → 场景 5。
• 样式规则与代码重复——硬编码、重复颜色、字号、间距和缺少语义变量 → 场景 6。
• 响应式与视口——挤压、遮挡、横向滚动、异常换行和布局坍塌 → 场景 4。
• 主题、Token 与对比度——深色主题、品牌换肤、高对比度和变量映射 → 场景 7。
• 设计系统与规范漂移——页面、组件与 Figma、品牌规范或目标系统不一致 → 场景 8。
• 资产与组件生命周期——图标、图片、旧组件、废弃组件 API、迁移和下线条件 → 场景 9。
• 规范与版本生命周期——设计稿与代码漂移、文档采用率、版本影响和弃用规则 → 场景 10。

一个问题可以有一个主要场景和一个关联场景，但要先判断主要问题。比如“组件层级”如果指语义、组件 API 或组件嵌套，进入场景 5；如果指遮挡和前后关系，进入场景 3。已有视觉基本不变、目标只是消除重复样式时进入场景 6；接入或调整主题变量时进入场景 7。具体资源与调用点的迁移进入场景 9；制度、文档、版本窗口和弃用政策进入场景 10。项目级治理是一个完整的总场景，负责项目级现状评估、优先级判断、治理计划、执行和验收；十类专项场景是其中可按需调用的工作包，不要求每次先选一个场景，也不要把所有问题同时安排修复。

二、项目级治理与十类专项场景

项目级治理用于建立项目现状、整体优先级和治理计划；十类专项场景用于处理明确的问题。项目级与十类专项提示词都可以独立复制使用，并假设你已经在 AI 工具的计划模式中；如果没有，请在提示词开头加上“请先进入计划模式”。

直接复制即可：每段提示词默认作用于当前项目，不需要填写方括号占位符。你已经提供的页面、问题、截图或设计规范会成为优先依据；缺少材料时由 AI 说明，不需要预先补齐模板。

项目级治理：制定整体治理计划

适用于接手陌生项目、问题太多太杂，或者想建立一份 UI 健康度基线。AI 会先了解项目、判断问题和安排治理顺序，再形成一份可以直接执行的整体计划。

对当前项目做一次项目级 UI 治理规划。
先了解主要页面、核心流程、现有 UI 规则和运行方式，再从功能布局、视觉规则、组件与交互、多设备与主题、生命周期五个维度识别问题。
按用户影响、影响范围、发生频率和修改风险排序，输出问题清单、治理优先级、建议修改范围、执行顺序和验证方式。
区分已经证实的问题和仍需验证的判断；缺少材料时说明依据和假设。
本轮制定整体计划，不修改文件。

产出：一份可以连续执行的项目级治理计划。确认一次后，使用第三节的执行提示词完成计划内工作，不需要逐阶段确认。

场景 1：功能布局与信息架构治理

适用于功能分组混乱、主次不清、入口难找、页面层级过深和任务路径复杂。

检查当前项目的功能布局与信息架构。
结合实际页面和代码，梳理核心用户任务、当前路径、功能分组和信息层级。
给出确认的问题、调整方案、修改范围和验证方式；证据不足的判断标为待验证。
本轮制定治理计划，不修改文件。

产出：任务路径和结构治理计划。

场景 2：交互体验治理

适用于点击反馈、加载、成功、失败、重试、撤销、焦点和键盘状态缺失。

检查当前项目的交互体验。
结合实际操作和代码，检查点击反馈、加载、成功、失败、重试、撤销、焦点和键盘操作。
给出状态缺口、补全方案、影响范围和验证方式；无法复现的状态标为待验证。
本轮制定治理计划，不修改文件。

产出：状态矩阵和交互补全计划。

场景 3：视觉与排版治理

适用于颜色、字号、行高、间距、对齐、层级、密度和布局表现不统一或难以扫描。

审计当前项目的视觉与排版。
结合实际页面和项目已有的截图或设计规范，检查颜色、字号、行高、间距、对齐、层级和密度。
给出确认的问题、合理例外、修改范围和验证方式；缺少依据的判断标为待验证。
本轮制定治理计划，不修改文件。

产出：视觉问题清单和治理计划。

场景 4：响应式适配治理

适用于指定视口下的挤压、遮挡、溢出、异常换行和布局坍塌。

检查当前项目在主要视口和边界视口下的响应式表现。
结合实际页面和代码，定位挤压、遮挡、横向滚动、异常换行和布局坍塌的根因。
不要用隐藏内容代替修复。
给出修复方案、修改范围和验证方式；无法实际验证的判断单独说明。
本轮制定治理计划，不修改文件。

产出：响应式问题清单和治理计划。

场景 5：组件规范治理

适用于组件语义、组件 API、复用方式、状态覆盖、可访问性基础和废弃引用混乱。

审计当前项目的组件使用规范。
结合实际页面和代码，检查控件语义、组件 API、状态覆盖、复用方式、键盘操作、可访问性和废弃引用。
给出确认的问题、合理例外、影响范围、治理方案和验证方式；无法实际验证的判断单独说明。
本轮制定治理计划，不修改文件。

产出：组件健康报告和治理计划。

场景 6：样式规则与代码重复治理

适用于重复颜色、字号、间距和样式规则过多，但希望尽量保持现有视觉结果。

整理当前项目中重复的颜色、字号、间距和样式规则。
目标是提取有语义的变量，尽量保持现有视觉结果，不引入外部设计系统。
结合实际页面和代码，给出现有值到语义变量的映射、修改范围和验证方式。
本轮制定治理计划，不修改文件。

产出：变量映射和样式治理计划。

场景 7：主题与 Token 适配治理

适用于接入外部 Token，或建立浅色、深色、品牌和高对比度主题。

为当前项目制定主题与 Token 适配计划。
使用项目已有或用户提供的 Token、设计规范和主题机制，检查代表性页面、图表、图片和弹窗的主题表现。
给出变量映射、覆盖方式、对比度风险、修改范围和验证方式；缺少的材料或未验证的页面单独说明。
本轮制定治理计划，不修改文件。

产出：Token 映射和主题治理计划。

场景 8：设计系统对齐治理

适用于页面和基础组件需要对齐已经确认的品牌规范、Figma 或目标设计系统。

检查当前项目与已有设计规范的差异。
以项目内的设计文件、Figma 链接、品牌规范或用户提供的目标设计系统为依据。
结合实际页面和代码，区分规范差异、实现问题、合理例外和业务变体。
给出差异清单、修改范围、需要保留的业务组件 API 和验证方式；缺少的规范或版本信息单独说明。
本轮制定治理计划，不修改文件。

产出：规范差异清单和对齐计划。

场景 9：资产与废弃组件/组件 API 迁移治理

适用于图标、图片、旧组件和废弃组件 API 的替换、迁移和清理。

检查当前项目中需要迁移的图标、图片、旧组件和废弃组件 API。
建立新旧资源或 Props/组件 API 对照表，识别无法一对一映射的调用点。
给出迁移范围、执行顺序、验证方式、回滚方式和旧版本删除条件；目标资源或版本不明确时说明缺口。
本轮制定迁移计划，不修改文件。

产出：新旧映射表和迁移计划。

场景 10：规范、文档与版本治理

适用于设计稿与代码逐渐漂移、组件文档与代码引用不一致、版本升级影响不清。

检查当前项目的规范、文档与版本治理。
对比项目现有的设计文件、代码、组件文档和版本记录，列出设计漂移、文档缺口、废弃引用和受影响页面。
给出问题优先级、文档补齐方案、迁移窗口和旧版本删除条件；缺少的版本或使用数据单独说明。
本轮制定治理计划，不修改文件。

产出：漂移清单和版本治理计划。

“定点热修复”不再单独作为问题场景，而是以上任何场景都可以采用的执行范围：局部修复、试点迁移或分批推广。

三、执行与验收

执行提示词

计划确认后，直接让 AI 连续执行。是否分批由 AI 根据修改范围、依赖关系和风险自行判断，不预设阶段数量，也不要求每完成一个阶段都等待确认。

按已确认的计划连续执行，完成全部计划内工作，不需要逐阶段等待确认。
遇到超出计划范围、可能改变业务逻辑或无法安全判断的情况再停止说明。
完成后自动运行相关检查，并汇报改动、验证结果、未验证项和剩余风险。

这条提示词用于计划确认后的同一段对话，AI 会沿用已经确认的范围和验证方式，自行完成计划内的常规判断与执行。

AI 自检

AI 在交付前负责运行相关检查，并根据问题提供任务结果、页面截图或版本差异，同时明确哪些内容没有验证。构建或测试通过只能证明对应检查通过，不能直接证明体验没有问题。

人工确认

你不需要重复 AI 的全部检查，只确认三个问题：

• 原问题是否已经解决。
• 是否引入了新的视觉、交互或功能问题。
• 修改是否超出确认过的范围。

AI 可以准备证据，但最终是否可接受仍由你判断。

三条边界不能跳过：没有项目事实，不能宣布问题成立；Token 映射不能代替真实页面验收；迁移必须核对语义、状态和回滚条件，不能做简单查找替换。

AI 只有在超出计划范围、可能改变业务逻辑、缺少关键材料或无法安全判断时才需要停止说明。普通实现细节和计划内调整应自行处理，不要频繁请求确认。

按需记录

只有本次任务产生了会重复使用的项目规则、合理例外或验收路径，才需要记录。优先写入项目已有文档，不默认新建治理文件，也不记录一次性排查过程。

检查项目现有的规则、决策、变更和组件文档。
判断本次任务是否产生了可复用的规则、合理例外或验收路径。
只有存在明确复用价值时，按项目原有格式提出追加内容和建议位置；不要默认创建新文件，不要记录一次性细节。
本轮只输出记录建议，不修改文件。

结语

AI 能减少扫描、整理和重复修改的时间，但 UI 治理真正要解决的是判断过程：问题从哪里来，准备改到哪里，怎样确认方案有效，怎样证明结果没有变坏。

作为 AI 设计师，你的核心能力不是让 AI 获得更大的修改权限，而是把设计判断转化成可复制的计划，选择项目级或专项治理方式，再用真实页面和用户操作确认结果。最终判断权始终在你自己手里。