设计师

AI 赋能设计师与创意从业者的使用案例。

1. AI 品牌资产一致性审计员

将品牌合规审计周期从 3 周压缩至 4 小时，自动捕获 97% 以上的违规问题。

痛点与解决方案

痛点：品牌不一致是隐性的营收流失

拥有分散团队、多产品线和外包代理商的大型企业，长期面临品牌一致性问题。Logo 出现在错误的颜色背景上，各地区排版风格偏移，产品与营销之间的按钮样式分裂。每一处偏差单独看似乎微不足道——但复合性的不一致在规模化后会系统性侵蚀品牌信任度。研究显示，消费者需要5-7次品牌曝光才能建立认知；每次素材不一致都会重置这个计数器。

审核流程本身就是核心瓶颈。典型的企业品牌审核意味着一两名设计师需要手动检查数百份素材——Figma 文件、营销 PDF、社交媒体模板、方案演示、落地页和邮件序列。每季度这样的审查需要2-4周，而设计团队根本抽不出这个时间。大多数审计被推迟、草草了事，或直接跳过。等到违规被发现时，往往已经传播给了数百万用户。

问题随规模扩大而加剧。当营销、产品、销售和各地区团队的50多名干系人都在产出素材时，靠 Slack 随手提醒和 PDF 版视觉规范来执行标准，在结构上根本不可能奏效。随着品牌演进，规范手册本身也会过期，而既没有机制来同步变更，也没有系统在更新后检查合规状态。

COCO如何解决

COCO 的 AI 品牌素材一致性审计师，将品牌治理从被动的人工流程转变为自动化的持续合规系统。

品牌标准摄取：COCO 读取完整的品牌规则体系：
- 主色、辅色、点缀色的色值（HEX/RGB/CMYK/Pantone）
- 排版层级（字体家族、字重、字号、行高比例）
- Logo 使用规范（最小尺寸、安全空间、禁止背景、禁止改动类型）
- 间距与栅格系统规格
- 语调风格指南与禁用词汇
- 图片风格参数（摄影、插画、图标系统）
素材库扫描分析：给定一批素材（图片、PDF、截图、Figma 导出），COCO：
- 提取每个主要元素的色值
- 识别使用的字体并与已批准字体列表比对
- 检查 Logo 位置、尺寸及周边安全空间
- 检测未授权改动（拉伸 Logo、重新着色品牌标志）
- 标记偏离栅格规格的版式模式
违规分级与严重性评分：COCO 不只是标注，还会优先排序：
- 严重：Logo 误用、主视觉元素使用非品牌色、使用未批准字体家族
- 重要：按钮样式不一致、标题层级错误、间距违规
- 轻微：细微色值偏移（在容差范围内但存在趋势）、排版字号不一致
- 每条违规包含截图坐标、规则引用和修正建议
自动化审计报告生成：COCO 输出结构化合规报告：
- 附整体合规评分（0-100）的执行摘要
- 按素材逐一列出违规数量（按严重程度）
- 最常见违规类型热力图
- 与上次审计的对比趋势
- 按商业影响优先级排序的修复清单（面向用户 > 内部使用）
规范手册缺口检测：COCO 识别规范手册本身模糊或不完整的地方：
- 应用不一致的规则（说明指引本身不清晰）
- 现有规范未覆盖的新场景（深色模式、移动端优先、联合品牌）
- 造成跨团队解读分歧的规则冲突
- 输出一份推荐补充的规范手册条目列表
持续合规监控：在规模化场景下，COCO 实现持续治理：
- 对指定素材文件夹执行自动周度或月度审计
- 新上传的素材在进入生产环境前，若含违规自动预警
- 品牌变更传播：规范更新时，自动识别所有需要刷新的素材
- 按团队和素材类别显示合规趋势的 Dashboard

量化结果与受益角色

可量化的成果

审计周期：从3周人工审核缩短至4小时自动扫描（减少95%）
品牌合规评分：从基准61%提升至实施2个季度后89%
违规检出率：人工审计检出34%的违规；COCO 检出97%+
设计师时间释放：每季度节省28-40小时的审计工作，重新投入创意产出
修复响应时间：平均违规修复从12天缩短至2天（优先级排序效果）

受益人群

品牌设计师：告别繁琐的人工审计循环，专注创意工作而非充当合规警察
创意总监：获得客观的合规数据，支撑品牌治理决策和跨团队问责谈话
营销运营经理：在不造成素材审批瓶颈的前提下，对外包代理商和各地区团队执行规范
CMO 和品牌高管：将品牌合规度作为可量化的 KPI，与营销活动效果和市场认知指标并列追踪

💡 实用提示词

提示词1：完整品牌合规审计

请对以下素材进行品牌规范审计，并输出结构化合规报告。

品牌规范摘要：
- 主色：[色值，如 #0052CC]
- 辅色：[列出色值]
- 主字体：[字体名称]，可用字重：[列出字重]
- 辅字体：[字体名称]，用于 [使用场景]
- Logo 安全空间：任何尺寸下四周最小 [X]px
- 禁止：拉伸 Logo、将 Logo 放置于 [颜色/图案]、使用未批准色彩变体

待审计素材：[粘贴截图描述或素材清单]

对每项素材，请报告：
1. 整体合规评分（0-100）
2. 发现的违规（严重/重要/轻微），注明具体元素和违反的规则
3. 每条违规的修复建议
4. 按优先级排序的修复顺序

以结构化表格形式输出，末尾附总结段落。

提示词2：新素材上线前审查

请在此素材上线前进行审查。我们的品牌规范如下：
[粘贴相关品牌规则]

素材描述/截图：[描述或粘贴素材详情]

检查内容：
1. 色彩合规（精确 HEX 匹配或在 ±5% 可接受容差范围内）
2. 排版：字体家族、字重及字号层级是否正确
3. Logo 使用：变体是否正确、最小尺寸是否满足、安全空间是否保留
4. 间距：是否符合 [X]px 栅格系统
5. 语调风格：标题和文案是否符合品牌语调指南

返回：通过 / 轻微修改后通过 / 需要修改，并附具体问题说明。

提示词3：规范手册缺口分析

我在审查品牌规范手册，想识别其中的缺口。以下是我们团队常遇到的使用场景：

[列出10-15个场景，例如：]
- 深色模式 UI 组件
- 与 [合作方] 的联合品牌物料
- 社交媒体竖版故事格式（9:16）
- 邮件签名模板
- 展会展台视觉物料

请对照我们现有规范手册审查上述场景：
[粘贴或概述规范手册相关章节]

对每个场景：
1. 是否已覆盖？（是 / 部分覆盖 / 未覆盖）
2. 若部分覆盖，模糊点在哪里？
3. 若未覆盖，建议添加什么规则？
4. 应用于此场景时，现有规则之间是否存在冲突？

以优先级排序输出规范手册补充/修订建议清单。

提示词4：季度合规趋势报告

请基于以下审计数据，生成季度品牌合规执行摘要：

Q[N] 审计数据：
- 审计素材数量：[数量]
- 合规评分：[X]%（与 Q[N-1] 相比：[涨/跌 Y]%）
- 严重违规：[数量]（[列出前3类违规类型]）
- 重要违规：[数量]（[列出前3类]）
- 轻微违规：[数量]
- 违规最多的团队：[列出]
- 进步最大的团队：[团队名称]（提升 [X]%）

请撰写一页执行摘要：
1. 以核心指标和趋势方向作为开篇
2. 识别造成违规的2-3个根本原因（系统性，非个人性）
3. 点出1-2个亮点，强化正向行为
4. 为 Q[N+1] 给出3条具体行动建议，附责任人和截止时间
5. 以 Q[N+1] 目标分数预测作为结尾

语气：客观、建设性、不带指责。读者：CMO 和设计副总裁。

提示词5：外包代理商品牌合规要求简报

请为外包代理商制作一份品牌合规要求简报，用于 [活动名称/项目] 的素材制作。

我们的品牌规范（摘要）：
[粘贴核心规则]

代理商需产出：[列出交付物，如10张社交媒体 Banner、3个落地页、1套邮件序列]

请生成包含以下内容的简报：
1. 不可违反的规则（违规将要求完全返工）
2. 推荐做法（强烈建议但有一定灵活性）
3. 常见错误清单（基于历史违规总结）
4. 审批流程：审查内容、顺序、响应时限
5. 文件交付规格（格式、分辨率、命名规范、分层源文件）

请确保内容清晰、实用、易于扫描——代理商 PM 和设计师可直接按此执行。

2. AI 设计系统组件审计员

将设计系统偏移检测从季度人工审查转变为持续自动化监控——在组件违规上线前捕获 94% 的问题。

痛点与解决方案

痛点：设计系统熵增是产品一致性的隐形杀手

设计系统的构建成本高昂，维护成本更高。一套成熟的设计系统可能定义了 200+ 组件，并附带严格的使用规则——按钮变体、间距令牌、语义色值、图标尺寸、排版比例。但设计系统一经发布，熵增就开始了：工程师硬编码一次性覆盖值，设计师分离组件后本地修改，产品团队为某次发布创建"临时"变体却从未回收。两个季度后，规范系统与实际部署之间的差距就变成了鸿沟。

代价不仅仅是美观。不一致的组件意味着不一致的行为——一个主按钮在三个产品区域看起来不同，会训练用户不信任界面交互模式。可访问性也会下降，因为被覆盖的组件跳过了规范版本中内置的无障碍色彩对比和焦点状态。每个自定义变体都增加维护债务：当设计系统团队发布更新时，分离的实例不会继承变更。团队花在灭火式修复偏移上的时间，比演进系统本身还多。

人工审计无法扩展。一个 3-5 人的设计系统团队不可能监控数十个产品界面上的数百个页面。他们依赖工程师和设计师自我报告偏差——但这种情况很少发生。季度"组件健康检查"只能捕获最明显的违规，且已是在它们上线生产环境数周之后。

COCO如何解决

COCO 的 AI 设计系统组件审计员，将设计系统治理从周期性人工检查转变为持续自动化的合规执行。

组件规格摄取：COCO 读取完整的设计系统定义：
- 组件分类体系（原子、分子、有机体）及命名规范
- 每个组件的属性规格（尺寸变体、色彩令牌、内边距值、圆角半径）
- 使用规则与约束（每个组件应该和不应该使用的场景）
- 组合规则（哪些组件可以嵌套在哪些组件内）
- 已废弃组件及其批准的替代方案
实现扫描与匹配：COCO 分析生产页面或 Figma 文件，对照规范系统：
- 识别给定页面上的每个组件实例
- 将每个实例与最接近的规范组件定义进行匹配
- 检测属性偏差（错误色彩令牌、非标准内边距、缺少状态变体）
- 标记完全分离或未被系统识别的组件
- 映射组件使用模式，识别非官方变体已在何处出现
偏移分级与影响评估：COCO 按严重性和影响范围分类每项偏差：
- 严重：组件行为与规范版本不同（交互损坏、缺少无障碍状态）
- 高：面向用户的界面视觉偏差（错误令牌、自定义覆盖值）
- 中：内部工具偏差或轻微属性不匹配
- 低：在可接受容差阈值内的外观偏移
- 每条违规包含具体属性、期望值、实际值和页面位置
自动化合规仪表板：COCO 生成设计系统的动态健康报告：
- 按产品区域计算的整体采用率评分（使用规范组件的页面百分比）
- 组件级别合规率（哪些组件偏移最严重）
- 趋势分析，显示偏移随时间加速或减速
- 违规最多的团队或产品界面，附具体示例
- 修复当前偏移积压所需的工程工时估算
变体合理化建议：COCO 识别整合非官方变体的机会：
- 聚类相似的自定义组件，推荐统一为新的规范变体
- 检测多个团队出现相同覆盖的模式（提示系统缺少该功能）
- 基于实际使用模式（而非理论需求）提出设计系统补充建议
- 根据当前使用数据计算新变体的采纳概率
合并前合规门控：COCO 实现左移质量保障：
- 在交付前审查 Figma 设计，标记非系统组件
- 检查 Pull Request 中硬编码的样式值（应使用设计令牌）
- 在设计评审中提供实时反馈和内联违规标注
- 为每次发布生成合规证书，附通过/未通过状态和例外清单

量化结果与受益角色

可量化的成果

偏移检测速度：从季度人工审计到实时警报的持续监控（周期缩减100%）
组件合规率：从基准58%提升至部署3个月内91%
未授权变体数量：从 340+ 自定义覆盖减少到全产品界面不到45个
设计系统团队效率：合规监管耗时减少60%，重新投入系统演进和新组件开发
可访问性回归率：由于规范组件强制执行，组件级无障碍违规下降78%

受益人群

设计系统工程师：从被动修复偏移转向主动系统演进，以数据驱动的证据优先排列新组件开发
产品设计师：偏离系统时立即获得反馈，减少返工周期，加速设计到交付的时间线
前端工程师：获得明确的组件使用指南，消除歧义，减少代码评审中关于样式决策的争论
设计副总裁/产品负责人：可量化的设计一致性指标，与产品KPI并列报告，证明设计系统投入的ROI

💡 实用提示词

提示词1：完整设计系统合规审计

请对以下页面进行设计系统合规审计，对照所有定义的组件规格出具合规报告。

设计系统规格：
- 组件库：[名称，如"Meridian Design System v3.2"]
- 主按钮：[色彩令牌]、[圆角半径]、[内边距]、[字重]、[最小高度]
- 次按钮：[规格]
- 输入框：[默认、聚焦、错误、禁用状态规格]
- 卡片组件：[内边距、阴影、圆角、标题排版规格]
- 间距比例：[4px, 8px, 12px, 16px, 24px, 32px, 48px, 64px]
- 色彩令牌：[列出语义令牌——如 $color-action-primary = #0052CC]

待审计页面：[粘贴截图或描述页面]

对每个页面，报告：
1. 发现的组件实例总数
2. 规范匹配数 vs. 分离/自定义实例数
3. 属性级违规（组件、属性、期望值、实际值）
4. 严重性分级（严重/高/中/低）
5. 每条违规的修复建议

以按严重性分组的结构化表格输出，附每个页面的合规评分（0-100）。

提示词2：设计令牌使用验证

请审查以下代码片段或样式表，识别其中应使用设计令牌却被硬编码的值。

我们的设计令牌集：
- 色彩：[列出令牌名和值，如 $color-text-primary: #1A1A2E]
- 间距：[列出令牌名和值]
- 排版：[列出字号、行高、字重的令牌名]
- 阴影：[列出阴影层级令牌]
- 圆角：[列出圆角令牌]

待审查代码：
[粘贴 CSS/SCSS/styled-components/Tailwind 类名]

对每条违规：
1. 行号和文件
2. 发现的硬编码值
3. 应使用的正确设计令牌
4. 风险级别（高 = 面向用户、中 = 内部使用、低 = 边缘情况）

同时标记令牌使用不正确的情况（如将背景色令牌用于文字颜色）。

提示词3：自定义组件变体分析

我们在代码库中发现了 [N] 个不匹配规范设计系统的自定义组件变体。请帮助我们合理化处理。

发现的自定义变体：
[列出每个变体的：名称/描述、使用位置、与最近规范组件的差异]

系统中的规范组件：
[列出相关规范组件及其定义的变体]

对每个自定义变体，建议以下操作之一：
1. 整合：映射到现有规范变体（说明哪个以及需要哪些微调）
2. 提升：作为新的官方变体加入设计系统（基于使用频率和场景有效性论证）
3. 废弃：移除并替换为规范替代方案（提供迁移路径）
4. 例外：作为合理的一次性保留（说明为何无法纳入系统）

输出按影响排序（实例最多的优先）的迁移计划，附每项的工时估算。

提示词4：设计系统采纳报告

请根据以下数据，为管理层生成月度设计系统采纳报告。

指标：
- 审计页面总数：[数量]
- 整体合规评分：[X]%（上月：[Y]%）
- 按类别的组件采纳率：
  - 按钮：[X]% 合规
  - 表单：[X]% 合规
  - 导航：[X]% 合规
  - 卡片/容器：[X]% 合规
  - 排版：[X]% 合规
- 自定义覆盖数量：[数量]（趋势：增/减 [Z]%）
- 合规率最高的团队：[列出]
- 合规率最低的团队：[列出]
- 本月新增的系统组件：[列出]

请撰写一页报告：
1. 以合规趋势及其驱动因素作为开篇
2. 突出2个亮点（表现改善的团队或产品区域）
3. 识别2个关注点并分析根本原因
4. 为下月提出3条具体行动建议，附责任人
5. 包含"设计系统健康度评分"（综合指标）

语气：数据驱动、协作性强、聚焦赋能而非管控。读者：设计副总裁、工程负责人。

提示词5：交付前设计审查清单

请在工程交付前审查此设计文件，验证是否符合设计系统标准。

设计系统要求：
- 所有交互元素必须使用 [组件库名] 的规范组件
- 间距必须遵循 [X]px 基准网格
- 色彩必须引用语义令牌（规格中不允许原始 HEX 值）
- 排版必须使用定义的字体比例（不允许自定义字号）
- 所有状态必须指定：默认、悬停、聚焦、激活、禁用、错误（适用时）
- 响应式行为必须为以下断点提供文档：[列出断点]

待审查设计：[粘贴或描述设计]

检查并报告：
1. 组件覆盖率：多少比例的 UI 元素映射到规范组件？
2. 缺失状态：哪些交互元素缺少必需的状态定义？
3. 间距违规：间距在哪里偏离了网格？
4. 令牌合规：是否有应使用令牌的原始值？
5. 交付就绪度评分：已就绪 / 需轻微修复 / 未就绪

提供设计师可在交付前用于修复问题的检查清单。

3. AI 响应式设计QA引擎

将响应式设计QA从 2 天人工测试压缩至 35 分钟自动扫描——跨所有断点检出 96% 的布局破损问题。

痛点与解决方案

痛点：响应式破损无声上线，直接蚕食转化率

响应式设计已不是可选项——全球超过 60% 的网页流量来自移动设备，用户通过 320px 手机屏幕到 3840px 超宽显示器的各种设备接触产品。然而响应式 QA 仍然是产品开发中最繁琐、最易出错的环节之一。一个页面在 5 个主要断点、3 种方向下需要 15+ 次人工检查。一个 40 页的产品意味着每次发布要进行 600+ 次视觉检查。没有团队能做到这么全面。

结果是可预见的：布局问题直接上线生产环境。文字在小屏上溢出容器，平板视口出现水平滚动条，导航菜单在尴尬的中间断点与内容重叠，移动端触控目标缩小到不可用的尺寸，主视觉图片拉伸或裁切不当。这些不是边缘情况——而是响应式网页开发的日常现实。每个破损的布局都在侵蚀用户信任并直接影响转化率；研究显示 57% 的用户不会推荐移动端体验糟糕的企业。

测试瓶颈是结构性的。人工响应式 QA 要求设计师或 QA 工程师调整浏览器窗口（或使用设备模拟器），逐元素目视扫描，用截图和标注记录问题，然后提工单。这在认知上令人精疲力竭，容易遗漏，且不可能在每次发布时保持一致。自动化视觉回归工具有助于像素级比对，但无法识别语义问题——它们无法判断一个布局虽然"技术上在渲染"但功能已经破损（例如按钮可见但在移动端被推到屏幕外）。

COCO如何解决

COCO 的 AI 响应式设计 QA 引擎在每个断点自动化布局验证，结合视觉分析与语义理解，捕获人工和传统自动化工具都会遗漏的问题。

断点配置与设备矩阵：COCO 摄取产品的响应式策略：
- 定义的断点（如 320px、480px、768px、1024px、1280px、1440px、1920px）
- 目标设备配置文件（视口尺寸、像素比、安全区域）
- 方向规则（每个断点的纵向、横向或两者）
- 组件级响应式行为规则（如导航在768px以下折叠为汉堡菜单）
- 必须在每个断点保持功能的关键用户流程
自动化多断点渲染与分析：对每个页面或组件，COCO：
- 在每个定义断点同时渲染布局
- 识别文本溢出、截断和内容裁切问题
- 检测不应存在水平滚动的视口是否出现水平滚动
- 检查触控目标尺寸是否达到最低无障碍标准（48x48px）
- 验证图片在各断点的缩放、宽高比和美术指导
- 标记元素因 z-index 层叠导致的错误重叠
语义级布局验证：超越像素级检查，COCO 理解布局意图：
- 验证内容层级在各断点保持一致（H1 始终在 H2 之上，CTA 保持突出）
- 检查导航模式的正确转换（桌面导航到移动端汉堡菜单）
- 验证交互元素保持可到达和可操作（不被重叠内容遮挡）
- 确认布局从多栏回流到单栏时阅读顺序合理
- 检测"僵尸状态"——元素在渲染但功能上不可访问
跨版本回归检测：COCO 将当前响应式行为与历史基线对比：
- 在每个断点追踪版本间的布局变化
- 区分有意的重新设计与意外的回归
- 高亮代码变更引入的新破损（CSS 特异性冲突、容器查询副作用）
- 维护每页响应式健康评分的历史时间线
- 根据 CSS 变更为每个 Pull Request 生成"响应式风险评分"
问题优先排序与开发者就绪报告：COCO 输出可执行的结果：
- 按视口流量份额排序（热门断点的破损排名更高）
- 每个问题包含前后截图对比、受影响断点和 CSS 元素选择器
- 附带具体 CSS 属性和值的修复建议
- 按根本原因分组（一个 CSS 问题可能在多个断点引发破损）
- 工时估算（快速修复 vs. 需要布局重构）
持续响应式监控：对生产环境，COCO 实现持续守护：
- 对关键用户流程的定期周度响应式扫描
- 新部署引入响应式回归时自动告警
- 性能感知扫描，标记在移动端引发布局偏移（CLS）飙升的布局
- 与分析数据集成，将响应式问题与转化率下降相关联
- 全产品界面响应式健康趋势仪表板

量化结果与受益角色

可量化的成果

QA 周期时间：从 2 天人工响应式测试到 35 分钟自动扫描（减少97%）
破损检出率：人工 QA 捕获 41% 的响应式问题；COCO 捕获 96%，包括微妙的中间断点故障
移动端转化影响：COCO 驱动的响应式修复在 6 周内将移动端转化率提升 12-18%
生产事故：部署持续监控后，响应式相关支持工单减少 73%
开发者效率：修复响应式问题的平均时间从 4 小时缩短至 45 分钟（精准根因定位效果）

受益人群

UI/UX 设计师：验证响应式设计忠实转化为实现，无需花数小时手动检查每个断点
前端工程师：收到包含 CSS 选择器和修复建议的具体可执行问题报告，而非模糊的"移动端看起来有问题"工单
QA 工程师：消除手动测试中最繁琐的部分，专注需要人类判断力的行为和交互测试
产品经理：有量化的响应式健康指标支撑，可以自信地发布在所有设备上正常运行的产品

💡 实用提示词

提示词1：完整响应式布局审计

请对以下页面/组件在所有定义断点上进行响应式设计审计。

测试断点：
- 移动端：320px, 375px, 414px（纵向和横向）
- 平板端：768px, 1024px（纵向和横向）
- 桌面端：1280px, 1440px, 1920px

页面/组件：[描述或粘贴桌面宽度下的截图]

预期响应式行为：
- 导航：[描述每个断点的预期行为，如"768px 以下显示汉堡菜单"]
- 栅格：[描述列数变化，如"4列 → 2列 → 1列"]
- 图片：[描述缩放行为]
- 排版：[描述流式字体缩放（如有）]

对每个断点，报告：
1. 布局状态：通过 / 警告 / 失败
2. 发现的问题及严重性（严重/重要/轻微）
3. 具体元素、CSS 属性、期望行为 vs. 实际行为
4. 问题位置的截图标注
5. 修复建议（CSS 属性 + 值）

提供汇总表格和整体响应式健康评分（0-100）。

提示词2：移动优先转化流程检查

请对以下关键用户流程进行移动端可用性审计，识别可能影响转化的问题。

流程：[描述流程，如"落地页 → 产品页 → 加入购物车 → 结账 → 确认"]
目标设备：[如 iPhone 14 Pro, 393x852px, 3x 像素比]

对流程中的每一步，检查：
1. 触控目标：所有交互元素 ≥ 48x48px 点击区域
2. 内容可见性：关键内容不在首屏以下或被重叠元素遮挡
3. 表单可用性：输入框尺寸合适、键盘类型匹配输入类型、标签可见
4. CTA 突出性：主操作按钮在首次加载时无需滚动即可见
5. 加载布局：页面加载期间无明显布局偏移（CLS < 0.1）
6. 滚动行为：无意外水平滚动、纵向滚动流畅

以优先级列表报告问题：
- 对转化的影响（高/中/低）
- 具体元素及问题描述
- 修复建议
- 工时估算（快速修复/中等/需重新设计）

提示词3：响应式回归分析

请对比一个页面的两个版本在响应式行为上的差异，识别回归。

上一版本（基线）：[描述或粘贴各关键断点的截图]
当前版本（新版）：[描述或粘贴各关键断点的截图]

对比断点：[列出断点]

对每个断点：
1. 布局是否有变化？（是/否）
2. 如有变化，是有意的（重新设计）还是意外的（回归）？
3. 回归详情：什么破损了，在哪里，可能原因
4. 严重性：严重（功能丢失）/ 重要（视觉破损）/ 轻微（外观瑕疵）

输出回归报告：
- 每个断点发现的回归总数
- 根因分析（哪些 CSS 变更可能导致了回归）
- 优先级修复清单
- 总修复工时估算

提示词4：中间断点压力测试

请在非标准视口宽度测试此布局，找出"断点间隙"中的故障。

定义的标准断点：[列出，如 768px, 1024px, 1280px]

测试以下中间宽度：800px, 850px, 900px, 950px, 1000px, 1050px, 1100px, 1150px, 1200px, 1250px

页面/组件：[描述]

对每个中间宽度，报告：
1. 布局是否稳定？（是/否/部分）
2. 什么破损：文字溢出、图片变形、元素重叠、间距塌陷
3. 问题是由缺少断点还是流式尺寸错误引起的？
4. 修复建议：在 [X]px 添加断点，或改用流式尺寸（clamp/min/max）

识别断点之间最需要关注的"死区"。

提示词5：响应式组件库验证

请审计我们的组件库是否已具备响应式就绪状态。每个组件应在所有断点正确工作，无需页面级覆盖。

待测组件：
[列出组件，如：]
- 顶部导航栏
- 主视觉区域（Hero Section）
- 卡片网格（2列、3列、4列变体）
- 数据表格
- 模态弹窗/对话框
- 页脚

对每个组件：
1. 是否仅凭自身样式即可处理所有断点？（是/否/部分）
2. 在哪些断点破损或需要外部覆盖？
3. 是否使用了响应式最佳实践？（流式宽度、min/max 约束、容器查询）
4. 移动端无障碍：触控目标、可读文字、可操作控件
5. 性能：视口变化时是否引起布局偏移？

为每个组件评级：响应式就绪 / 需改进 / 不支持响应式
提供非就绪组件的优先级修复计划。

4. AI 设计稿-代码还原度验证器

将设计稿-代码差异解决从5 天的反复沟通压缩至2 小时自动对比——首次实现即达到 98% 的像素级还原度。

痛点与解决方案

痛点：设计出来的不是最终被开发出来的

从设计到工程的交付是产品开发中视觉质量损失最大的单一环节。跨产品组织的研究显示，首次实现与设计的还原度仅为 60-75%。间距差了几个像素，色值是近似而非精确，字重有微妙差异，圆角不匹配，阴影偏重或偏轻。每个单独的差异都很小，但综合效果是产品感觉"不对"——不够精致、不够可信、不如设计意图那般高端。

根本原因是沟通断层加上工作流摩擦。设计师在 Figma 中指定精确值（8px 内边距、#1A1A2E 色值、600 字重、4px 圆角），但经过设计规格、组件库、CSS 框架和响应式适配的层层传递，偏移不可避免。工程师凭视觉感受而非测量来判断间距，色彩令牌的 hex 值可能与设计文件略有不同，响应式调整覆盖了精心指定的桌面端布局。没有系统性方法将实现的 UI 与原始设计对比，差异就悄无声息地积累。

审查流程本身就是坏的。设计师通过在标签页间切换来对比实现截图和 Figma 文件，眯着眼找差异。这对微妙偏差不可靠——人眼会适应并归纳小差异。由此产生的"设计 QA"循环是提"卡片组件间距好像不对"这样的工单，工程师再花 30 分钟试图理解问题。每个组件三轮反复，一次发布 20 个组件，累计数天的效率损失——结果还是不完美。

COCO如何解决

COCO 的 AI 设计稿-代码还原度验证器自动化设计文件与实现 UI 的对比，捕获每一处到亚像素级别的差异，并生成开发者可直接执行的修复指令。

设计源文件摄取：COCO 以完全保真度捕获设计意图：
- 解析 Figma/Sketch 设计文件，提取精确规格（色彩、间距、排版、效果）
- 捕获组件层级和自动布局规则
- 记录响应式变体和断点特定设计
- 提取设计令牌并映射到期望的 CSS/代码值
- 处理复杂规格，包括渐变、混合模式和组合效果
- 保留 z-order、透明度和图层信息
实现截取与归一化：COCO 截图已构建的界面并准备对比：
- 以与设计完全匹配的视口尺寸渲染已实现的页面
- 捕获每个可见元素的计算 CSS 值（不仅是样式表中写的）
- 考虑浏览器渲染差异（反锯齿、亚像素渲染、字体平滑）
- 归一化设计师不需关心的平台特定渲染伪影
- 在设计中有规格时，捕获交互状态（悬停、聚焦、激活）
多层级对比引擎：COCO 从多个维度对比设计与实现：
- 像素叠加：精确视觉差异，高亮设计与实现之间每个不同的像素
- 属性对比：逐元素比较间距、色彩、排版、边框、阴影和效果
- 布局分析：元素间的对齐、分布和相对定位
- 排版审计：每个文本元素的字体家族、字重、字号、行高、字间距和文字颜色
- 响应式还原度：在每个断点重复对比，使用断点特定设计
智能差异分级：并非所有差异都同等重要——COCO 优先排序：
- 严重：色彩错误、字体家族错误、缺少元素、布局结构破损
- 重要：间距偏差 >4px、字重错误、圆角不正确、阴影不匹配
- 轻微：1-2px 间距偏移、亚像素渲染差异、平台特定反锯齿
- 可接受：在定义容差阈值内的差异（如 ±1px 间距、±2% 色值）
- 上下文感知：同样的 4px 间距误差在主视觉区域比在页脚更为严重
开发者就绪的修复指令：COCO 生成精确、可执行的修复方案：
- 需修改的精确 CSS 属性，附当前值和目标值
- 每处差异的元素选择器（类名、data 属性或 DOM 路径）
- 按组件分组，开发者可一次修复一个文件中的所有问题
- 修复前后的视觉预览对比
- 为常用框架自动生成代码片段（React、Vue、Tailwind、CSS Modules）
持续还原度监控：COCO 防止回归并追踪改善：
- 修复后验证扫描，确认所有问题已解决
- 版本间还原度追踪，显示设计到代码的质量是在改善还是退化
- 与 CI/CD 流水线集成，在合并前标记还原度回归
- 设计系统中每个组件的还原度评分（高亮持续偏移的组件）
- 展示还原度跨产品版本演进的历史对比

量化结果与受益角色

可量化的成果

设计 QA 周期时间：从设计师-工程师 5 天的反复沟通缩短至2 小时自动对比和修复生成（减少95%）
首次实现还原度：采用 COCO 验证器后，实现准确度从 68% 提升至98% 像素级匹配
设计 QA 工单：从每次发布 45 个减少到需人工设计师审查的不到 5 个
工程返工工时：每冲刺节省 32 小时，此前用于"让实现匹配设计"的反复迭代
视觉一致性评分：跨产品视觉一致性从 71% 提升至 95%（通过自动化还原度扫描测量）

受益人群

产品设计师：确信设计被忠实实现，无需花数天做视觉 QA 和提像素级工单
前端工程师：获得明确无歧义的修复指令和精确 CSS 值，而非需要揣摩的"看起来不太对"反馈
设计系统团队：获得哪些组件持续偏移的数据，从而改进交付文档和组件规格
产品经理：更快的发布周期和更高的视觉质量，无需扩大 QA 团队或增加设计审查瓶颈

💡 实用提示词

提示词1：完整设计稿-代码还原度对比

请将此实现的 UI 与原始设计对比，输出还原度报告。

原始设计规格：
- 背景色：[色值]
- 主文本：[字体家族]、[字重]、[字号]/[行高]、[颜色]
- 次文本：[规格]
- 主按钮：[背景色]、[文字色]、[内边距]、[圆角]、[字体规格]
- 卡片组件：[内边距]、[背景色]、[边框]、[阴影]、[圆角]
- 元素间距：[指定关键间距值]
- 布局：[描述栅格/弹性布局和对齐方式]

实现截图：[粘贴或描述已构建的内容]

对每个元素，对比：
1. 色彩：设计值 vs. 实现值（ΔE > 2 时标记）
2. 间距：设计值 vs. 实现值（px，差异 > 2px 时标记）
3. 排版：所有属性（家族、字重、字号、行高、字间距、颜色）
4. 边框和阴影：精确属性对比
5. 布局：对齐、分布、排序

输出差异表格：元素 | 属性 | 设计值 | 实际值 | 差异 | 严重性
附整体还原度评分（0-100）和优先级修复清单。

提示词2：组件级还原度深度分析

对单个组件的所有状态和变体进行详细还原度对比。

组件：[名称，如"主按钮"]

每个变体的设计规格：
- 默认：[所有 CSS 属性]
- 悬停：[变更的属性]
- 聚焦：[变更的属性]
- 激活：[变更的属性]
- 禁用：[变更的属性]
- 加载中：[变更的属性，含动画规格]
- 尺寸变体：小 [规格]，中 [规格]，大 [规格]

实现：[描述或粘贴每个状态/变体的截图]

对每个变体和状态：
1. 视觉匹配度评分（0-100）
2. 逐属性对比表格
3. 过渡/动画时序对比（如适用）
4. 标记实现中缺失的状态

输出组件还原度卡片，附每个变体的通过/未通过及整体组件健康评分。

提示词3：响应式还原度多断点检查

请将此设计的实现在所有响应式断点上与原始设计规格对比。

每个断点的设计规格：
- 移动端（375px）：[描述布局、间距、排版变化]
- 平板端（768px）：[描述]
- 桌面端（1280px）：[描述]
- 宽屏（1440px）：[描述]

每个断点的实现截图：[粘贴或描述]

对每个断点，对比：
1. 布局结构（列数、元素顺序、显示/隐藏规则）
2. 排版缩放（字号是否匹配断点特定规格？）
3. 间距适配（外边距/内边距是否匹配断点特定规格？）
4. 图片行为（尺寸、裁切、宽高比）
5. 组件行为（导航是否正确折叠？卡片是否正确回流？）

输出逐断点还原度矩阵，识别偏移最严重的断点。

提示词4：设计令牌映射验证

请验证实现的 CSS 值是否正确映射到我们的设计令牌。

已定义的设计令牌：
[粘贴令牌列表，如：]
- $color-primary: #0052CC
- $color-text-primary: #1A1A2E
- $color-text-secondary: #667085
- $spacing-sm: 8px
- $spacing-md: 16px
- $spacing-lg: 24px
- $font-size-body: 16px
- $font-size-heading-1: 32px
- $border-radius-md: 8px

代码中观察到的实际 CSS 值：
[粘贴或描述实际值]

检查：
1. 每个实现值是否正确引用了对应的令牌？
2. 是否有应使用令牌却被硬编码的值？
3. 是否有令牌被用在错误的上下文中（如间距令牌用于字号）？
4. 是否有值不映射到任何现有令牌（令牌体系缺口）？

输出令牌映射验证表格和不匹配列表。

提示词5：发布还原度签核报告

请为此次发布生成设计还原度签核报告。

发布：[版本/名称]
范围内的页面/组件：[列出所有待发布的页面和组件]

对每个页面/组件，我将提供：
- 设计链接：[Figma URL 或描述]
- 实现：[预发布 URL 或截图]

生成签核报告，包含：
1. 整体发布还原度评分（0-100）
2. 每页还原度评分
3. 发布前必须修复的严重差异（如有）
4. 本次发布可接受的轻微差异（附追踪工单编号）
5. 与上次发布还原度评分的对比（改善还是下降？）
6. 建议：批准 / 有条件批准（列出条件） / 阻断（列出阻断项）

格式化为设计团队签核——此报告将附于发布说明中。

5. AI界面模式库策展人

将图案库维护工作从每月40小时压缩至6小时——确保95%的图案在各产品团队中得到采纳。

痛点与解决方案

痛点：没有人真正使用的图案库

设计系统的成败，在很大程度上取决于图案库的质量，但大多数组织都难以让库保持更新和可发现性。典型的企业级图案库一开始阵容强大——核心团队会整理50至80种 UI 图案，附带清晰的使用指南、代码片段和 Figma 组件。然而半年之后，现实就开始偏离初衷：产品团队找不到合适的图案，不知道某个图案是否存在，或者发现文档版本无法处理他们的边界情况，于是自行构建定制变体。一项针对200多个组织的设计系统成熟度调查发现，图案采纳率平均仅在40%至55%之间——这意味着几乎一半的 UI 实现完全绕过了官方库。

维护瓶颈是结构性的，而非主观意愿的问题。图案馆员需要持续监控各产品团队的构建成果，识别应晋升为图案的重复 UI 方案，审计现有图案的相关性，为新图案编写附使用指南和代码示例的文档，并废弃过时内容。这项工作要求对所有团队都有深度了解——图案团队需要掌握每个产品小组正在设计和构建的内容。现实中，图案更新最多每季度发生一次，这意味着库总是比实际产品需求落后3到6个月。

可发现性是问题的另一半。即便合适的图案存在，设计师和工程师也往往找不到它。图案库动辄膨胀到200多个条目，命名不统一、分类重叠、搜索返回结果泛滥。一名设计师在寻找"带图片、标题和操作按钮的卡片"时，可能根本意识不到库里把它叫做"媒体对象"或"内容块"。结果是：各团队重复发明已有图案，造成视觉不一致和工程重复劳动，每个迭代周期都在加剧这种积累。

COCO如何解决

跨产品图案发现：COCO 持续扫描各产品设计和代码库，识别正在使用的 UI 图案：
- 跨所有产品团队的 Figma 文件，检测重复出现的组件结构
- 分析前端代码库中未使用库组件的重复 UI 实现
- 识别"图案漂移"——各团队以相似方式修改官方图案（说明存在缺口）
- 统计每种检测到的图案变体的使用频率和使用场景
- 每周生成报告，列出候选晋升图案
智能图案分类与标签：COCO 让设计师能快速找到所需内容：
- 为每个图案自动生成多个搜索别名（card、tile、content-block、media-object 均指向同一图案）
- 按使用场景（电商、仪表板、引导、设置）而非纯视觉分类进行标注
- 创建图案关联图谱（此卡片图案常与此列表图案搭配使用）
- 维护同义词词典，从失败的搜索中学习，持续提升可发现性
- 为每个图案标注复杂度等级，便于设计师判断是否需要工程支持
自动化图案文档生成：COCO 自动生成并维护完整的图案文档：
- 通过分析图案在各产品中的成功部署方式，提炼使用指南
- 对比正确实现与常见误用，生成"正确/错误"示例
- 记录所有支持的变体、状态和响应式行为，附视觉示例
- 编写无障碍规格，包括 ARIA 属性、键盘行为和屏幕阅读器预期
- 通过同步实际组件库代码仓库，保持代码片段始终最新
缺口分析与推荐引擎：COCO 主动识别库中的缺失内容：
- 当3个以上团队构建相似的自定义组件时自动检测，将其推荐为共享图案
- 分析竞品和行业 UI 图案，识别覆盖缺口
- 当多个图案重叠服务于相似目的时，推荐图案合并
- 按预计采纳率和实现工时排列新图案开发优先级
- 基于现有最佳实现，生成附初步规格的图案提案
采纳追踪与引导：COCO 以不强制的方式推动图案采纳：
- 通过精细化仪表板，衡量各团队和产品的图案采纳率
- 识别可用库图案替换自定义实现的具体实例
- 在设计评审中生成上下文建议，链接到相关现有图案
- 追踪采纳率低的图案，并诊断原因（过于僵化、缺少变体、难以发现）
- 生成月度采纳报告，呈现趋势并表彰进步的团队
图案全生命周期管理：COCO 管理从提案到废弃的完整生命周期：
- 追踪图案成熟度阶段（草稿、测试版、稳定版、废弃），附自动晋升标准
- 监控使用趋势，标记接近淘汰的图案（3个月内采纳率持续下降）
- 废弃图案时自动生成迁移指南，将旧图案映射到新的替代方案
- 归档废弃图案并保留完整历史，供使用旧代码库的团队参考
- 在 Figma 组件、代码库和文档之间同步版本管理

量化结果与受益角色

可量化成果

图案采纳率：COCO 部署两个季度后，各团队平均采纳率从42%提升至91%
库维护工时：从每月40小时人工维护降至每月6小时审核与审批
图案发现时间：设计师在90秒内找到相关图案，过去平均需要12分钟（提速87%）
重复组件创建次数：每季度从15个自定义副本降至2个以下，节省约120个工程工时
图案库新鲜度：新图案在识别后1周内完成文档，过去需要3个月

受益角色

设计系统团队：从繁琐的分类和文档工作转向战略性的图案规划和质量把关
产品设计师：即时找到合适图案，并确信它能覆盖自己的使用场景，无需再创建自定义组件
前端工程师：每个图案有且仅有一种标准实现和清晰规格，消除"该用哪个版本"的困惑
设计总监：可量化的图案采纳数据，用于证明设计系统 ROI 并支持持续投入

💡 实用提示词

提示词1：图案审计与缺口分析

请审计我们当前的 UI 图案库，对照实际产品使用情况找出缺口。

当前图案库清单：
[列出所有图案，如：Button、Card、Modal、Dropdown、Table、Form Field、Navigation Bar、Tabs、Accordion、Toast Notification 等]

各产品及核心页面：
- [产品A]：[列出主要页面/流程，如 dashboard、settings、onboarding、checkout]
- [产品B]：[列出]
- [产品C]：[列出]

对每个产品页面，请识别：
1. 哪些库图案被正确使用
2. 哪些库图案被修改后使用（描述改动内容）
3. 哪些自定义组件不对应任何库图案
4. 在2个以上产品中重复出现的自定义组件（候选新图案）

输出：
- 图案覆盖矩阵（产品 × 图案）
- 缺口列表：应该存在但尚未建立的图案
- 整合机会：可合并的重叠图案
- 下一步优先新增的5个图案推荐

提示词2：图案文档生成器

请为即将加入我们库的新 UI 图案生成完整文档。

图案名称：[如 "Data Card"]
描述：[简述它是什么以及何时使用]
参考现有实现：[描述2-3个跨产品的现有使用案例]

请生成包含以下内容的文档：
1. 图案概述：是什么、何时使用、何时不用
2. 结构图说明：标注每个部分（header、body、footer、action area、metadata 等）
3. 变体：[列出预期变体——如 compact、expanded、with-image、without-image]
4. 状态：默认、悬停、选中、禁用、加载中、错误、空状态
5. 内容指南：每个文本区域的最小/最大字符数、图片宽高比
6. 响应式行为：图案在移动端、平板、桌面断点的适配方式
7. 无障碍：ARIA 角色、键盘交互、屏幕阅读器行为
8. 正确/错误示例：3个正确用法和3个常见误用及说明

输出为可直接发布的设计系统文档页格式。

提示词3：图案命名规范与分类审查

请审查我们图案库的命名规范和分类体系，找出可发现性问题。

当前图案名称与分类：
[按当前分类列出所有图案，如：]
- 导航：Navbar、Sidebar、Breadcrumbs、Tabs、Pagination
- 数据展示：Table、Card、List、Stat Block、Chart Container
- 输入：Text Field、Select、Checkbox、Radio、Toggle、Date Picker
- 反馈：Toast、Alert、Modal、Dialog、Progress Bar
- 布局：Grid、Container、Divider、Spacer

设计师常用的搜索词（来自搜索日志或调研）：
[如 "popup"、"dropdown menu"、"notification"、"loading spinner"、"hero section"]

请分析：
1. 哪些搜索词未匹配任何图案名称？建议添加别名。
2. 是否有图案名称存在歧义？（如 "Card" 含义过泛）
3. 当前分类是否直观？换一种分组是否更利于浏览？
4. 建议一套优化可发现性的修订分类体系，附别名方案
5. 识别需要子分类的图案（如 Card → Data Card、Media Card、Profile Card）

输出推荐的命名规范与分类体系重构方案。

6. AI色彩无障碍优化器

在2小时内将品牌调色板转化为符合 WCAG AAA 标准的无障碍色彩体系——在保持94%感知品牌相似度的同时实现全面无障碍合规。

痛点与解决方案

痛点：美丽的品牌将数百万用户拒之门外

色彩无障碍是品牌认同与包容性设计的碰撞地带——而这种碰撞往往并不美好。营销团队耗费数月精心打磨品牌调色板，赋予每种颜色精确的情感联想：那抹既"温暖又现代"的珊瑚色，那个既"可信又亲切"的特定海军蓝。然后无障碍审计到来，宣告60%精心挑选的颜色未能通过 WCAG 对比度要求。白底珊瑚色的对比度仅为2.8:1（需达4.5:1）。品牌渐变上的浅蓝色根本无法阅读。那些看似优雅的微妙灰色文字，对15%的用户而言几乎不可见。

典型的应对方式，是品牌团队与无障碍团队之间一场痛苦的拉锯战，最终两败俱伤。品牌经理抗拒更改标志性颜色，无障碍专家坚持合规。妥协的结果往往是一套与原始品牌意图相去甚远的"数字调色板"，或者更糟——一纸豁免，让产品继续留在不可访问的状态。设计师夹在中间，花数天时间手动测试颜色组合、计算对比度、提出被双方轮番否决的替代方案。一套典型的品牌调色板有15到20种颜色、数百种组合，排列空间之大难以穷举。

挑战在深色模式、高对比度模式和色盲模拟下进一步倍增。在白底能通过 WCAG 的颜色对，在深色背景下可能失败。对大多数用户清晰可辨的绿-红区分，对8%患有色觉障碍的男性却形同无色。组织需要的不是一套无障碍调色板，而是跨模式和场景的无障碍调色板体系——而靠人工流程根本无法在规模化场景下维持这一体系与品牌的同步。

COCO如何解决

品牌色彩 DNA 提取：COCO 在感知层面分析品牌调色板，保留其独特性：
- 将所有品牌色转换为感知色彩空间（OKLCH、CIELAB），进行基于人类视觉的精准分析
- 识别定义品牌身份的核心感知属性（色相角度、彩度范围、明度关系）
- 根据色彩心理学研究和品牌指南，映射每种颜色的情感联想
- 判断哪些色彩属性对合规而言是本质的（色相）、哪些是可调整的（明度、彩度）
- 创建"品牌色彩指纹"，作为优化的约束边界
穷举组合测试：COCO 针对无障碍标准测试所有可能的颜色组合：
- 生成产品中使用的前景/背景颜色组合完整矩阵
- 逐一对照 WCAG 2.1 AA（文本4.5:1、大号文本3:1、非文本3:1）和 AAA（7:1、4.5:1）阈值测试
- 同步对三种色觉障碍类型（红色盲、绿色盲、蓝色盲）进行模拟测试
- 同时针对亮色模式、深色模式和高对比度模式进行测试
- 标记仅依靠颜色传达含义的颜色对（色觉障碍不安全的图案）
感知感知色彩调整：COCO 基于人类感知模型（而非单纯数学运算）优化颜色：
- 在 OKLCH 空间中调整明度和彩度，以最小感知偏移达到目标对比度
- 精确保持色相角度——这是品牌色彩身份中最易被识别的维度
- 使用最小可察差（JND）计算确保调整幅度尽可能小
- 生成多个候选调整方案，按与原始颜色的感知相似度排列
- 验证调整后的颜色保持预期关系（主色比辅色深，等等）
系统化调色板生成：COCO 产出完整、统一的无障碍色彩体系，而非零散修补：
- 生成所有组合均通过 WCAG AA 最低要求的完整亮色模式调色板
- 生成保持相同品牌感和色彩关系的匹配深色模式调色板
- 创建供需要最高可读性用户使用的高对比度模式变体
- 生成在所有模式下均可访问的语义色令牌（成功、警告、错误、信息）
- 确保所有生成的调色板内部一致（各模式间无颜色冲突）
色盲安全性验证：COCO 确保调色板适用于所有色觉类型：
- 在红色盲、绿色盲和蓝色盲视觉模型下模拟整套调色板
- 验证所有功能性颜色区分（错误 vs. 成功，激活 vs. 未激活）保持可辨识
- 在无法避免仅依赖颜色区分的场景下，添加辅助指示器（图标、纹理、标签）
- 测试数据可视化调色板在所有色觉类型下的可区分性
- 为图表、图形和状态指示器生成色盲安全备选调色板
活性文档与令牌导出：COCO 交付可直接实施的输出：
- 将无障碍调色板导出为所有主流格式的设计令牌（CSS 变量、Tailwind 配置、Figma 变量、iOS/Android）
- 生成可视化对比图，呈现原始品牌色与无障碍替代色及偏差值
- 生成颜色使用指南，指定哪些组合被批准、哪些被禁止
- 创建 CI/CD 流水线可运行的自动化测试，防止未来出现无障碍回归
- 维护变更日志，让品牌团队清晰了解改了什么、为什么改

量化结果与受益角色

可量化成果

调色板优化周期：从3-4周人工迭代压缩至2小时以内完成完整无障碍色彩体系
WCAG 合规率：颜色组合从38%通过率提升至100% AA 合规（92% AAA 合规）
品牌相似度评分：无障碍调色板与原始品牌色保持94%感知相似度（以 OKLCH 色差值衡量）
色盲安全性：功能性颜色区分通过所有3种色觉障碍类型的可辨识测试（此前仅通过2种）
无障碍相关支持工单：色彩对比度投诉从每月23个减少至不足2个（减少91%）

受益角色

产品设计师：获得真正具有品牌感的无障碍色彩体系——不再需要在美感与合规之间二选一
品牌经理：有数据支撑地确信数字无障碍不会稀释品牌认同，感知差异极小
前端工程师：以偏好格式交付的即用型令牌，附清晰的使用规则——不再猜测该在哪里用哪个颜色
无障碍负责人：自动化验证确保颜色合规跨版本持续维持，手动审计负担降低80%

💡 实用提示词

提示词1：品牌调色板无障碍审计

请对此品牌调色板进行 WCAG 2.1 无障碍合规审计，覆盖所有预期使用组合。

品牌调色板：
- 主色：[HEX]
- 辅色：[HEX]
- 强调色：[HEX]
- 背景色（亮色模式）：[HEX]
- 背景色（深色模式）：[HEX]
- 表面色（卡片、模态框）：[HEX]
- 主文字色：[HEX]
- 次文字色：[HEX]
- 成功色：[HEX]
- 警告色：[HEX]
- 错误色：[HEX]
- 信息色：[HEX]

测试以下组合：
1. 所有文字色在所有背景色上（正文文字：4.5:1，大号文字：3:1）
2. 交互元素色在所有背景上（非文本元素：3:1）
3. 状态色（成功/警告/错误/信息）在所有背景上
4. 焦点指示器颜色在所有背景上

对每个组合，提供：
- 对比度（计算值）
- WCAG AA：通过/未通过
- WCAG AAA：通过/未通过
- 如未通过：通过所需的最小明度调整量

输出合规矩阵和需要关注的失败项摘要。

提示词2：无障碍颜色替代方案生成

请为以下失败的颜色组合生成无障碍替代方案，同时保持最大品牌相似度。

失败的组合：
- [前景色 HEX] 在 [背景色 HEX] 上——当前对比度：[X:1]，需达到：[4.5:1 或 3:1]
- [前景色 HEX] 在 [背景色 HEX] 上——当前对比度：[X:1]，需达到：[目标值]
- [重复列出所有失败组合]

品牌约束：
- 色相必须保持在原始值 ±[5-15] 度以内
- 以下颜色已锁定，不可更改：[列出不可动的颜色]
- 调整偏好：调整 [前景/背景/两者皆可]

对每个失败组合，生成：
1. 推荐修复方案：调整后的颜色 HEX 值及达到的对比度
2. 与原始颜色的感知差异（OKLCH 色差值 delta E）
3. 外观差异描述（改了多少？视觉变化大吗？）
4. 若第一方案视觉差异过大，提供备选方案
5. 新值的 CSS 自定义属性声明

输出调整前后的调色板对比表格。

提示词3：深色模式调色板推导

请基于我们的亮色模式品牌调色板，生成对应的无障碍深色模式调色板。

亮色模式调色板：
- 背景色：[HEX]
- 表面色（卡片、模态框）：[HEX]
- 主文字色：[HEX]
- 次文字色：[HEX]
- 品牌主色：[HEX]
- 品牌辅色：[HEX]
- 强调色：[HEX]
- 边框/分割线：[HEX]
- 成功/警告/错误/信息：[各 HEX]

深色模式要求：
1. 所有文字在深色背景上必须满足 WCAG AA 对比度
2. 品牌色应可识别，但需针对深色背景调整（通常更亮/更饱和）
3. 层次感应通过表面色明度传达（而非阴影）
4. 状态色必须保持可区分性和无障碍性
5. 整体氛围应符合品牌个性（请指定：[如"温暖亲切"或"冷静专业"]）

输出：
- 深色模式令牌映射（亮色值 → 深色值）
- 所有文字/背景组合的对比度
- 语义色调整说明（如何修改成功绿、错误红等）
- 表面层级色阶（从基础到最高层的5个级别）
- 与亮色模式的并排对比，用于品牌一致性审查

7. AI设计冲刺促进器

将5天设计冲刺压缩至2天——生成通常需要完整引导团队才能产出的研究综合、草图方案和测试协议。

痛点与解决方案

痛点：耗尽一整周却依然偏离目标的设计冲刺

谷歌风险投资的设计冲刺模型承诺快速验证：五天内从问题定义到经用户测试的原型。但现实中，设计冲刺既昂贵、协调复杂，执行质量也参差不齐。一次标准冲刺需要5到7人腾出整整一周的日程——这相当于200多个人时的机会成本。加上准备工作（引导人员2到3天准备）、测试招募（提前1到2周）以及冲刺后文档整理（再需2到3天），一次设计冲刺的真实成本可能超过5万美元的人工成本。

引导质量的差异是左右结果最关键的因素，超越其他所有变量。一位经验丰富的冲刺引导人知道如何综合模糊的研究结论、引导发散性草图环节、推动团队向可测试假设收敛，并构建能回答正确问题的原型。但大多数组织并没有认证的冲刺引导人，只能依赖读过那本书却从未实际操盘的设计师或产品经理。结果：产出的原型测试的是错误的假设，"我们怎么可能"（HMW）问题太宽泛或太狭窄，故事板无法转化为可测试的流程。

输出质量问题不止于引导。冲刺草图往往粗糙到让室外人无从解读。决策取决于薪资最高者的意见，而非结构化评估标准。本应为冲刺奠定用户现实基础的研究综合，往往只是仓促浏览手边现有数据的30分钟回顾。团队带着激情离开冲刺，却拿着经不起推敲的产出物——测试的是表面偏好而非核心假设，所谓的学习也难以转化为产品决策。

COCO如何解决

冲刺前研究综合：COCO 准备全面的知识基础，让冲刺从有备而来开始：
- 整合和综合所有可用的用户研究（访谈、问卷、分析数据、支持工单、NPS 评论）
- 按频率、严重程度和商业影响为前5大用户问题排名
- 绘制含痛点、流失率和情感弧线的当前用户旅程
- 从真实用户语录和行为数据中提炼"我们怎么可能"问题
- 生成5位以上竞品如何应对同一问题领域的竞品分析
结构化问题框定：COCO 确保冲刺以正确的范围瞄准正确的问题：
- 基于研究综合生成长期目标和冲刺问题
- 创建标注关键时刻的用户旅程地图，聚焦冲刺焦点
- 生成按重要性和不确定性分类的假设地图
- 起草多个问题框架，供团队选择最具创造力的角度
- 从异步收集的利益相关方输入中整理"专家访谈"摘要
AI 辅助创意发散与草图：COCO 用广度和多样性增强发散思维阶段：
- 生成跨设计范式的20多种解决方案概念（移动端、桌面、对话式、空间交互）
- 搜索其他行业的类比解决方案，提供闪电演示参考
- 为每个解决方向创建附带标注理由的低保真线框概念
- 确保创意发散覆盖完整的解决方案空间——而非仅停留在最显而易见的初始想法
- 为每个有潜力的方向生成"疯狂8格"变体，突破创意边界
决策框架与收敛支持：COCO 以结构化评估取代主观争论：
- 基于冲刺目标、可行性和用户影响创建加权评分矩阵
- 通过统计投票并识别共识与分歧，辅助点票分析
- 从选定概念生成故事板叙述，附清晰的用户流程步骤
- 通过呈现竞争方案的权衡分析来化解"决策者"冲突
- 记录决策理由，让团队日后可以回溯为何选择了某个方向
快速原型规格生成：COCO 在数小时内将故事板转化为可构建的原型规格：
- 将选定的故事板转化为逐屏交互流程，附内容填充
- 为原型中每个屏幕生成真实的示例数据和文案
- 指定交互模式、过渡动画和微交互，让原型有真实感
- 创建展示所有路径、分支和决策点的可点击流程图
- 生成测试脚本，将每个原型屏幕与其验证的假设相对应
用户测试协议与分析：COCO 准备严谨的测试材料并综合测试结果：
- 生成含任务设计、追问探针和时间估算的有主持可用性测试脚本
- 创建目标用户画像的筛选标准和招募话术
- 设计用于测试会话中记录员的结构化观察模板
- 将测试会话笔记综合为基于规律的发现，附严重性评级
- 生成含已验证/已推翻假设和下一步建议的冲刺结果报告

量化结果与受益角色

可量化成果

冲刺时长：从5个整天压缩至2个专注天，产出质量对等
准备时间：引导人员准备时间从3天降至4小时（AI 生成研究综合和材料）
解决方案广度：创意阶段生成3倍以上的不同概念（60+个 vs 通常的20个），得益于 AI 增强的发散思维
假设准确率：在 COCO 支持下进行的冲刺假设验证率达78%，vs 行业平均52%——更好的问题框架带来更好的原型
冲刺后文档：从2-3天手动整理压缩至当天交付完整的冲刺结果报告

受益角色

产品设计师：将创意精力集中于评估和精炼，而非靠人力堆砌数量，AI 负责创意发散的广度
产品经理：在2天内获得经过验证、文档完备的产品方向，而非让整个团队承诺完整的一周
用户研究员：符合研究标准的严谨测试协议和综合框架，即使在没有专职研究员的情况下开展冲刺
工程负责人：含文档化权衡分析的清晰原型规格，直接转化为技术规划

💡 实用提示词

提示词1：冲刺前研究综合

请将我们的现有研究综合为设计冲刺简报文档。

研究输入：
- 用户访谈：[摘要或粘贴 X 次访谈的关键语录]
- 问卷数据：[关键发现，如"72%的用户反映在 X 方面遇到困难"]
- 分析数据：[关键指标，如"引导流程第3步流失率40%"]
- 支持工单：[主要投诉类别及频率]
- NPS 评论：[粘贴代表性评论]

冲刺聚焦领域：[如"新用户引导体验"]

请输出：
1. 前5大用户问题（按频率、严重程度、商业影响排名）
2. 含痛点标注的当前用户旅程地图
3. 从研究中提炼的10个"我们怎么可能"问题（具体、可行、不宜过宽）
4. 支撑每个 HMW 的真实用户语录
5. 竞品应对方式：[竞品1]、[竞品2]、[竞品3] 如何解决此问题
6. 推荐的冲刺长期目标和3个冲刺问题

输出格式适合在30分钟内完成的冲刺简报演示。

提示词2：解决方案创意发散与闪电演示

请为我们的设计冲刺挑战生成广泛的解决方案概念。

冲刺挑战：我们怎么可能 [具体的 HMW 问题]？
目标用户：[用户画像描述]
关键约束：[技术、商业、时间限制]
现有方案：[描述当前解决方案]

请生成：
1. 跨以下范式的20种不同解决方案概念：
   - 传统 Web/移动端 UI（5个）
   - 对话式/聊天（3个）
   - 主动推送（3个）
   - 简化/减法设计（3个）
   - 游戏化/参与感（3个）
   - 颠覆性重构（3个）

2. 对每个概念，提供：
   - 一句话描述
   - 背后的核心洞察或原则
   - 粗略草图描述（主屏幕上会展示什么）
   - 最接近的现实世界类比（闪电演示参考）

3. 闪电演示参考：找出其他行业中出色解决类似问题的5个案例
   - [行业]：[产品] 通过 [方式] 解决了 [类似问题]

输出格式适合引导式创意会议——这些概念应激发灵感，而非规定方向。

提示词3：冲刺故事板生成器

请将我们选定的解决方案概念转化为详细的冲刺故事板。

选定概念：[描述所选解决方向]
用户入口：[用户如何到达——如"邮件通知"、"应用首页"、"谷歌搜索"]
核心流程：[描述主要的理想路径]
关键时刻：[最重要的待测试交互]

请生成一个8-12帧的故事板，对每帧提供：
1. 帧编号和标题
2. 场景描述：用户看到什么（屏幕内容、关键元素）
3. 用户操作：用户做了什么
4. 系统响应：操作后发生了什么
5. 用户情绪/想法：用户在想什么或感受如何
6. 文案/内容：屏幕上会显示的真实文字
7. 备注：任何假设或决策点

同时生成：
- 与特定帧对应的测试假设（"如果用户在不困惑的情况下完成第5-7帧，假设得到验证"）
- 流程分支点的2条替代路径
- 帧与帧之间的过渡说明

8. AI用户流程线框图生成器

在3小时内生成完整的用户流程线框图，而非3天——产出涵盖一致交互模式和边界情况的40多个屏幕。

痛点与解决方案

痛点：线框图瓶颈拖延每一个项目

线框图是产品需求与视觉设计之间的桥梁，却长期处于资源不足的状态。一套针对中等复杂度产品流程（账户创建、引导、核心任务完成）的典型功能线框图，在包含理想路径、错误状态、空状态、加载状态和边界情况后，需要30到50个屏幕。以每个屏幕45到90分钟的深度线框设计时间（含信息架构决策、交互模式选择、内容层级和响应式考量），一套完整的功能线框包需要设计师集中工作3到5天。

这一瓶颈在整个产品开发时间线上层层传导。没有线框图，工程无法评估复杂度；没有知道版式结构，内容策略人员无法撰写文案；没有看到流程，利益相关方无法就范围达成共识。设计评审因线框图未就绪而推迟，视觉设计随之后推，开发随之后推，发布日期随之后移。在敏捷组织中，这意味着第 N+2 个迭代的线框图应在第 N 个迭代完成——但设计师通常还在做第 N+1 个迭代的线框图。

时间压力下质量也受损。当设计师为了解锁下游团队而赶做线框图时，边界情况往往被跳过。空状态被标注为"待补充"。错误流程只有一个通用屏幕，而非情境化的错误处理。响应式行为被隐含暗示，而非明确指定。结果是：工程师在开发中遇到未规格化的场景，要么自行做设计决策（造成不一致），要么提问题阻塞数小时甚至数天。一项分析发现，35%的工程"阻塞"工单可追溯到不完整或模糊的线框图。

COCO如何解决

需求到流程转化：COCO 在线框图开始之前，将产品需求转化为结构化用户流程：
- 将产品需求文档、用户故事和验收标准解析为离散的交互步骤
- 生成流程图，展示所有路径——理想路径、错误路径、替代路径和边界情况
- 通过检测无指定行为的流程分支，识别缺失的需求
- 将每个流程步骤映射到设计系统中合适的 UI 模式
- 生成流程完整度评分，标明已覆盖的场景百分比
智能线框图生成：COCO 基于用户流程和设计系统生成布局精准的线框图：
- 生成具有正确信息层级、间距和组件排布的屏幕级线框图
- 跨相似屏幕类型应用一致的交互模式（所有列表视图使用相同模式，所有表单遵循相同结构）
- 使用反映真实内容长度和复杂度的真实占位内容
- 以正确的设备框（移动端、平板、桌面）呈现线框图
- 注释说明每个主要布局决策的设计理由
边界情况与状态枚举：COCO 系统性地为组件或页面可能处于的每种状态生成屏幕：
- 为每个依赖数据的视图生成附适当消息和 CTA 的空状态线框图
- 生成展示骨架屏、渐进加载和加载指示器位置的加载状态线框图
- 为网络失败、校验错误、权限错误和超时场景创建错误状态线框图
- 设计首次用户与回访用户的差异化体验（当体验不同时）
- 记录边界条件（最大条目数、最少内容、溢出文字、极端数据场景）
响应式适配规格：COCO 展示每个线框图如何跨断点适配：
- 为每个屏幕生成移动端、平板和桌面线框图变体
- 指定布局变化（列数折叠、组件堆叠、导航转变）
- 说明内容优先级变化（小屏上什么被隐藏、折叠或重排）
- 标注移动端场景下触控目标的尺寸调整
- 记录滚动行为和依赖视口的交互（吸顶头部、底部抽屉）
交互注释层：COCO 添加工程师需要但设计师常常省略的丰富行为注释：
- 记录每个交互元素的点击/触摸行为（导航、状态变化、模态触发、API 调用）
- 指定屏幕间过渡动画（滑动、淡入淡出、展开、模态覆盖）
- 说明键盘导航顺序和焦点管理（用于无障碍）
- 描述适用的拖拽、滑动、长按和手势交互
- 将表单校验规则映射到每个输入字段（必填、格式、最小/最大值、依赖关系）
一致性审计与迭代：COCO 在设计师审查前先行审查自身输出，标记问题：
- 对照设计系统模式检查所有线框图，标记偏差
- 验证导航一致性（返回按钮行为、面包屑准确性、选项卡状态）
- 确保相似屏幕类型的内容层级一致
- 验证所有流程路径完整——无死路或缺失过渡
- 生成审查清单，让设计师能高效验证并审批每个屏幕

量化结果与受益角色

可量化成果

线框图生产时间：从每个功能流程3-5天压缩至3小时完成完整线框图集（减少90%）
屏幕覆盖率：平均线框图包从15个屏幕（仅理想路径）扩展至42个屏幕（含所有状态和边界情况）
工程阻塞工单：线框图相关的"需要设计澄清"工单从每迭代18个降至3个（减少83%）
设计系统合规率：线框图使用正确设计系统模式的比例达97%，手工线框图仅74%
响应式完整度：所有线框图均包含移动端、平板和桌面变体——过去仅**30%**的线框图包含响应式规格

受益角色

产品设计师：将时间投入创造性解题和用户研究，而非重复的屏幕生产——线框图作为精炼的起点
前端工程师：获得每个屏幕状态和交互的完整规格——不再猜测空状态该如何呈现或错误该如何处理
产品经理：从需求到可审查的线框图周期更短，加快对齐速度并保持迭代按计划推进
QA工程师：完整的线框图集作为测试用例文档——线框图规格中的每个状态都成为一个测试场景

💡 实用提示词

提示词1：需求到线框图流程

请将以下产品需求转化为完整的用户流程和线框图规格。

功能：[功能名称，如"团队成员邀请与引导"]
用户故事：
- 作为 [角色]，我希望 [行动]，以便 [价值]
- [更多用户故事]

验收标准：
[粘贴每个用户故事的验收标准]

可用的设计系统组件：[列出可用组件——如 form fields、buttons、modals、tables、cards、navigation 等]
平台：[响应式 Web / iOS 原生 / Android 原生]

请生成：
1. 文字版用户流程图，展示所有路径：
   - 理想路径（编号步骤）
   - 错误路径（从每个可能出错的步骤分支）
   - 替代路径（如用户已有账户、用户中途取消）
   - 边界情况（数据为空、上限触达、权限问题）

2. 屏幕清单：列出所需的每个独立屏幕，包含：
   - 屏幕 ID 和名称
   - 对应哪些流程步骤
   - 屏幕上的关键组件
   - 状态：默认、加载中、空状态、错误、成功

3. 对每个屏幕，提供线框图规格：
   - 布局描述（头部、正文各区块、底部/CTA 位置）
   - 组件规格（使用哪些设计系统组件，含属性/内容）
   - 内容层级（最突出的是什么、次要的是什么、第三层次的是什么）
   - 交互说明（每个交互元素点击/触摸后发生什么）

提示词2：边界情况与状态矩阵生成器

请为此功能生成完整的状态矩阵，并为每种状态提供线框图规格。

功能页面：
- [屏幕1名称]：[默认/理想状态描述]
- [屏幕2名称]：[描述]
- [屏幕3名称]：[描述]
- [屏幕4名称]：[描述]

对每个屏幕，请为以下状态生成线框图规格：
1. **默认/有数据**：有典型数据时的正常状态
2. **空状态**：尚无数据——该显示什么消息、插画和 CTA？
3. **加载状态**：数据正在获取——骨架屏、加载指示器还是渐进加载？
4. **错误状态**：网络或服务器错误——显示什么消息和重试操作？
5. **部分数据**：部分加载成功，部分失败——如何处理混合状态？
6. **首次访问**：用户从未见过此屏幕——是否需要引导覆盖层或提示？
7. **容量上限**：数据量最大时（如列表500条）——分页、虚拟滚动还是截断？
8. **权限受限**：用户无访问权限——看到什么？

对每种状态，指定：
- 视觉描述（哪些元素可见/隐藏）
- 文案（消息、CTA、提示的精确文字）
- 行为（用户在此状态下可以做什么）
- 过渡（用户如何进入和离开此状态）

提示词3：响应式线框图规格

请为此屏幕在所有断点上生成响应式线框图规格。

屏幕：[名称和桌面布局描述]
屏幕上的组件：
- [组件1：描述和当前桌面布局]
- [组件2：描述]
- [组件3：描述]
- [以此类推]

需要设计的断点：
- 桌面（1280px+）：[这是主要设计——描述当前布局]
- 平板横屏（1024px）：[有特殊要求吗？]
- 平板竖屏（768px）：[有特殊要求吗？]
- 移动端（375px）：[有特殊要求吗？]

对每个断点，请指定：
1. 布局变化：什么内容会回流、堆叠或改变栅格列数
2. 导航变化：导航是否折叠为汉堡菜单？何时折叠？
3. 内容优先级：什么被隐藏、截断或移入"显示更多"
4. 组件适配：每个组件如何变形（表格→卡片列表，横向标签→下拉菜单等）
5. 触控目标：哪些元素需要加大尺寸以适应触控（最小44x44px）
6. 滚动行为：吸顶元素、底部抽屉、下拉刷新
7. 交互变化：悬停状态→长按，工具提示→底部抽屉，等等

输出一份开发人员无需猜测即可实现的规格文档。

9. AI设计交付文档构建器

将设计交付文档时间从每功能8小时压缩至45分钟——生成像素级精准的规格文档，消除90%的工程师后续追问。

痛点与解决方案

痛点：交付文档制造的问题比它解决的还多

设计交付是产品开发中摩擦最大的环节。设计师在 Figma 中完成精心打磨的设计后，必须将这份视觉产物转化为工程师可以无歧义实现的规格文档。这意味着要记录每一个间距值、色彩令牌、排版规格、交互行为、动画时序、响应式规则、边界情况和状态变体。对于中等复杂度的功能，这项文档工作需要6到10小时的繁琐细致作业，大多数设计师感觉这是对灵魂的消耗。

交付文档的质量直接决定实现质量，而大多数交付文档都不够充分。一项针对150个产品团队的研究发现，工程师在实现过程中平均每个组件会提出4.2个澄清问题——涉及交互细节、响应式行为、边界情况和状态管理，而这些在设计师看来都是"显而易见"的，只是没有写出来。每个问题都产生一次通信往返：工程师提问、等待设计师回复（往往需要数小时），再按回答实现——而回答可能并不完全传达设计师的意图。每个组件三轮反复，一次发布20到30个组件，累计每个发布周期就会产生100多次澄清沟通——结果依然不完美。

问题的本质是两种思维模型之间的翻译断层。设计师以视觉构成、空间关系和用户意图思考；工程师以 DOM 结构、状态机和数据流思考。设计师可能描述下拉菜单为"点击后展开显示选项"，而工程师需要知道：是点击还是悬停触发？最大高度超出后是否滚动？选项超出视口怎么处理？键盘导航如何工作？动画时序和缓动是什么？下拉菜单在模态框内时怎么处理？这些不是边界情况，而是实现需求——而设计在视觉上并不呈现这些。

COCO如何解决

自动化设计文件解析：COCO 直接从设计文件提取全面规格：
- 通过 API 读取 Figma 文件的所有图层、组和组件，完整提取属性
- 捕获所有可测量属性：尺寸、间距（内边距、外边距、间隔）、颜色、排版、边框、阴影、透明度和混合模式
- 检测自动布局规则、约束和 Figma 中指定的响应式调整行为
- 将设计组件映射到对应的设计系统组件，使用令牌名称（而非原始值）
- 识别使用原始值而非令牌的实例，标记供设计师审查
交互规格生成：COCO 记录设计无法直观展示的所有行为细节：
- 为所有交互元素生成状态文档：默认、悬停、聚焦、激活、禁用、加载中、错误、成功
- 指定状态间过渡动画，含时长、缓动曲线和受影响属性
- 记录点击/触摸行为链（点击后发生什么→加载什么→下一个状态是什么）
- 创建反馈动画的微交互规格（按钮按压、开关切换、骨架加载）
- 映射键盘交互（Tab 顺序、Enter/Space 行为、Escape 关闭、方向键导航）
响应式行为文档：COCO 指定设计在每个断点的适配方式：
- 生成所有定义断点的并排对比规格，展示精确布局变化
- 记录容器查询和组件级响应式规则（不仅是视口断点）
- 指定元素在每个断点的隐藏、重排、调整大小或改变样式
- 说明滚动行为变化（固定头部变为可滚动，底部抽屉替代模态框）
- 包含每个断点的精确值：列数、间槽宽度、最大宽度和组件尺寸变化
组件 API 规格：COCO 将设计变体转化为开发友好的组件接口：
- 为每个组件生成属性表（属性名、类型、默认值、必填/可选、说明）
- 将设计变体映射到组件属性（size: "small" | "medium" | "large"）
- 记录插槽/子内容规格及内容约束
- 指定条件渲染规则（仅当属性 Y 为真时显示元素 X）
- 创建展示组件嵌套和交互方式的组件组合图
内容与数据规格：COCO 记录设计师常常遗漏的内容要求：
- 基于设计空间约束，为每个文本元素指定字符限制
- 区分动态内容（来自 API）和静态内容（硬编码），并附示例 API 响应结构
- 记录溢出场景的截断行为（省略号、行数限制、"显示更多"）
- 提供覆盖最小、典型和最大内容长度的真实测试数据集
- 说明本地化注意事项（文本扩展系数、RTL 布局要求、可翻译与不可翻译字符串）
开发就绪的交付包：COCO 以完整、结构化的文档交付：
- 生成含目录、组件索引和交叉引用注释的单页规格文档
- 包含针对复杂交互模式的框架代码片段（React、Vue、Swift、Kotlin）
- 生成高亮新增、变更或废弃内容的视觉差异对比（与上一版本）
- 基于规格创建 QA 检查清单——每个记录的行为都成为一个测试用例
- 添加"已知决策"章节，记录特定设计选择的原因（供未来维护者参考）

量化结果与受益角色

可量化成果

每功能文档时间：从8小时手动规格撰写降至45分钟 AI 生成规格审查和审批（减少91%）
工程师澄清问题数：每组件从4.2个降至0.4个——实现歧义减少90%
实现准确度：工程师使用 COCO 生成规格后，首次实现保真度从72%提升至96%
交付到代码周期：从5天（含来回沟通）缩短至1.5天完成完整功能实现
规格覆盖率：每功能记录的边界情况和状态从60%提升至98%，与未规格化行为相关的生产 Bug 报告减少85%

受益角色

产品设计师：每功能节省6-8小时繁琐文档工作，将时间重新投入研究和创意探索
前端工程师：获得含精确值、交互细节和代码提示的明确规格——减少猜测和返工
QA工程师：从设计规格自动生成的测试清单，确保质量保障中不遗漏任何内容
设计经理：跨团队交付质量一致，不受个别设计师文档习惯的影响

💡 实用提示词

提示词1：完整组件交付规格

请为此组件生成完整的交付规格。

组件：[名称，如"通知横幅"]
使用的设计系统令牌：[列出相关令牌——颜色、间距、排版]

设计描述：
- 布局：[描述结构——如"全宽水平栏，含图标、消息文字、操作链接和关闭按钮"]
- 变体：[列出——如 info、success、warning、error]
- 状态：[列出——如 default、dismissing（动画中）、dismissed]

请生成：
1. **属性规格表**：
   | 属性 | 值 | 令牌 |
   涵盖：尺寸、内边距、外边距、间隔、边框、圆角、背景色、文字色、图标尺寸、阴影

2. **变体规格**：每个变体有哪些变化（颜色、图标、ARIA 角色）

3. **交互规格**：
   - 关闭行为（点击 X、[X]秒后自动关闭、移动端滑动）
   - 操作链接行为
   - 动画：入场（向下滑入？淡入？），出场（向上滑出？淡出？）
   - 所有动画的时长和缓动

4. **响应式行为**：组件在移动端（<768px）的适配

5. **无障碍规格**：
   - ARIA 角色和属性
   - 焦点管理
   - 屏幕阅读器播报行为
   - 键盘关闭

6. **内容规格**：
   - 消息最大字符数
   - 截断行为
   - 操作链接文字限制

7. **代码提示**（展示组件 API 的 React 伪代码）

提示词2：多屏幕功能交付包

请为此多屏幕功能生成完整的交付包。

功能：[名称，如"用户设置页重设计"]
页面：
1. [屏幕名称]：[简述该屏幕的目的和主要内容]
2. [屏幕名称]：[描述]
3. [屏幕名称]：[描述]
4. [屏幕名称]：[描述]

设计系统：[名称和版本]
框架：[React/Vue/SwiftUI 等]
断点：[列出断点及其像素值]

对每个屏幕，请生成：
1. 布局规格（栅格、区块、含精确坐标/间距的组件摆放）
2. 组件清单（屏幕上使用的每个组件，含变体和状态）
3. 数据需求（每个区块需要的 API 数据，附示例响应）
4. 交互地图（每个可点击元素及其作用）
5. 状态变体（每个依赖数据区块的加载中、空状态、错误、有数据状态）
6. 屏幕过渡（用户如何到达和离开，附动画规格）

同时生成：
- 跨屏幕一致性检查清单（共用模式、导航行为、返回按钮行为）
- 新引入组件的完整属性表
- QA 测试清单（文档中每个交互和状态对应一个测试用例）

提示词3：交互与动画规格

请以开发就绪的细节，记录此功能的所有交互和动画。

功能：[名称]
关键交互：
- [交互1：如"拖拽重排列表中的项目"]
- [交互2：如"移动端下拉刷新"]
- [交互3：如"Shift+点击多选"]
- [交互4：如"双击内联编辑"]

对每个交互，请指定：
1. **触发**：什么用户操作启动交互（点击、悬停、拖拽、键盘、手势）
2. **视觉反馈**：用户立即看到什么（光标变化、高亮、幽灵元素）
3. **交互过程**：用户执行操作时发生什么（拖拽预览、进度指示）
4. **完成**：操作完成时发生什么（成功动画、状态变化、通知）
5. **取消**：用户如何中止交互（Escape 键、点击外部、拖放到无效区域）
6. **错误情况**：操作失败时发生什么（错误提示、还原动画、重试选项）

动画规格：
- 动画属性：[如 transform、opacity、height]
- 时长：[毫秒]
- 缓动：[CSS 缓动函数或 cubic-bezier 值]
- 延迟：[毫秒，如有]
- 错列：[列表动画时各项之间的毫秒间隔]

请包含使用 [CSS/Framer Motion/GSAP——指定偏好] 的复杂动画代码片段。

10. AI图标集一致性检查器

在30分钟以内审计500+图标的图标库——捕获人工审查中遗漏的98%的视觉不一致性，涵盖线条粗细、视觉尺寸和网格对齐。

痛点与解决方案

痛点：看起来像12个不同人设计的图标集

图标一致性是设计系统维护中最难的方面之一——失败时也是最显而易见的。成熟产品的图标库通常包含200到600个图标，由多位设计师在数月乃至数年间共同贡献。每位设计师带来略微不同的风格偏好：一人偏好1.5px描边，另一人用2px；一人圆角取2px，另一人取1px；一人填充色用80%透明度，另一人用100%。这些细微差别单独审查图标时几乎不可见，但当图标并排出现在导航栏或工具栏时，却会触目惊心地暴露出来。

图标一致性的审查流程极为繁琐且不可靠。设计师需要打开每个图标，检查属性，与风格规范对比，并标记偏差。对一个400图标的库，这需要2到3个工作日的集中检查——即便是专注的审查者也会漏掉20%到30%的问题，因为人眼对细微差异会形成适应和归纳。那些"差不多够用"的图标通过了审查，但积累起来会营造一种粗心大意的整体印象。用户可能无法明确指出每个不一致的地方，但可用性研究持续显示，图标不一致会降低产品的感知质量，并增加导航中的认知负荷。

当组织使用来自多个来源的图标时，问题会进一步加剧——自定义图标、开源图标集、以及来自并购或第三方集成的继承图标各自遵循不同的网格系统、视觉尺寸规范和风格语言。将它们合并成统一的库，需要繁琐的人工标准化工作，而很少有团队能为此投入足够的时间。结果是一套混搭的图标集：购物车图标和用户图标的视觉重量不一致，箭头相对其他符号显得过大，描边图标和填充图标在同一界面中并排时显得格格不入。

COCO如何解决

自动化属性提取：COCO 在向量级别分析库中的每个图标：
- 解析 SVG 文件，提取所有路径数据、描边宽度、填充颜色、透明度值和变换属性
- 测量每个图标在 viewBox 内的实际视觉边界（而不仅是 viewBox 尺寸）
- 检测每个图标内部及跨整个库的描边粗细变化
- 识别所有圆角元素上的圆角半径值并检查一致性
- 统计库中使用的所有颜色，检测意外的颜色变异
网格与对齐验证：COCO 检查每个图标是否遵循定义的网格系统：
- 验证每个图标是否落在定义的关键线形状内（圆形、方形、竖矩形、横矩形）
- 测量视觉居中——不是数学居中——考虑视觉重量分布
- 检查目标渲染尺寸（16px、20px、24px、32px）下的像素对齐，确保清晰渲染
- 检测溢出安全区域或未充分利用网格面积的图标
- 验证图标内容与 viewBox 边缘之间的内边距一致
视觉重量平衡分析：COCO 确保图标在形状不同时仍呈现相同的视觉重量：
- 计算每个图标在目标渲染尺寸下的墨水密度（填充像素与总面积的比率）
- 跨图标类别比较视觉重量——简单箭头不应比复杂的设置齿轮感觉更重
- 识别视觉上相对库中位数偏小或偏大的图标
- 建议缩放调整幅度（增大/减小百分比），以实现平衡的视觉重量
- 按视觉重量级别对图标分组，标记每组中的异常值
风格规则执行：COCO 根据团队定义的风格规范验证每个图标：
- 检查描边宽度一致性（如：所有图标在24px时应使用恰好1.5px描边）
- 验证描边端点和连接样式（圆角、方形、斜角）与规范匹配
- 确保填充规则（evenodd vs. nonzero）和透明度值符合约定
- 检查线条端点是否遵循定义的终端样式（平齐、圆角、延伸）
- 验证图标复杂度是否合适——标记对该集合来说过于细密或过于简单的图标
跨来源标准化：COCO 识别并解决来自不同来源的图标间的不一致：
- 按检测到的来源风格（不同描边粗细、网格尺寸或设计语言）对图标分组
- 生成标准化映射，说明每个来源组需要哪些调整
- 为每个图标生成具体的变换指令（缩放 X%、将描边调整为 Y px、对齐偏移 Z px）
- 在设计师审批前，预览标准化版本与原始版本的对比
- 批量处理已批准的标准化，自动更新 SVG 文件
持续库健康监控：COCO 在库增长过程中防止未来出现不一致：
- 在每个新图标提交被添加之前，验证其是否符合完整的库风格规范
- 生成跨维度（重量、对齐、风格、颜色）的库健康报告和一致性评分
- 随时间追踪一致性趋势——每次更新后库是否更加或不那么一致？
- 当一系列新增图标逐渐偏移库风格时触发"漂移预警"
- 生成附优先级修复建议的季度图标审计报告

量化结果与受益角色

可量化成果

审计时间：500+图标的完整库审计从3天人工检查压缩至28分钟自动分析
不一致性检出率：COCO 检出98%的视觉不一致性，vs 人工专家审查的70-75%
描边粗细方差：经 COCO 引导修复后，全库描边粗细标准差从 ±0.4px 降至 ±0.05px
新图标拒绝率：提交前验证在合并前捕获不一致性，合并后修复从新图标提交的35%降至3%
视觉重量方差：标准化后，全库光学尺寸偏差从18%变异系数降至4%

受益角色

图标设计师：获得关于一致性问题的清晰、客观反馈，而非主观评价——明确知道要修什么以及为什么
设计系统团队：图标库的自动质量门控，无需人工审查每次提交即可维持标准
产品设计师：确信从库中选取的任何图标都能与其他任何图标保持视觉一致，消除每次使用前的逐一检查
品牌经理：有量化保证图标库跨贡献者和来源维持品牌质量标准

💡 实用提示词

提示词1：完整图标库一致性审计

请对此图标库进行全面的视觉一致性审计，覆盖所有定义的风格参数。

图标库详情：
- 图标总数：[数量]
- 目标网格尺寸：[如 24x24px]
- 定义的描边宽度：[如 1.5px]
- 描边端点：[round/square/butt]
- 描边连接：[round/miter/bevel]
- 圆角半径：[如适用，如 2px]
- 安全区域内边距：[如四周各 2px]
- 风格：[描边/填充/双色调]

图标分类及预期图标：
- 导航：[列出——如 home、search、menu、back、forward、close]
- 操作：[列出——如 edit、delete、copy、share、download、upload]
- 对象：[列出——如 file、folder、image、video、link、calendar]
- 状态：[列出——如 check、warning、error、info、lock、unlock]
- 社交：[列出——如 heart、comment、bookmark、star、share]

对每个图标，请检查：
1. 描边宽度：是否符合规范？（测量实际描边，而非仅检查属性值）
2. 网格对齐：是否在 viewBox 内居中？是否对齐目标尺寸下的像素网格？
3. 安全区域：内容是否在定义的内边距范围内？
4. 视觉重量：墨水密度是否在库中位数的可接受范围内？
5. 风格属性：端点、连接、圆角半径、填充规则是否符合规范？
6. 颜色：是否只使用了定义的调色板颜色（或 currentColor）？

输出：每个图标的一致性评分卡、全库统计数据和优先级修复清单。

提示词2：新图标提交验证

请在将此新图标加入库之前，验证其是否符合我们的图标库风格指南。

新图标：[名称/描述]
SVG 代码或描述：[粘贴 SVG 或描述图标]

库风格指南：
- 网格：[如 24x24px，内边距 2px = 有效区域 20x20px]
- 描边：[粗细、端点、连接规格]
- 圆角半径：[规格]
- 视觉尺寸：[关键线形状及尺寸——如"圆形：直径20px，方形：18x18px，竖矩形：16x20px"]
- 复杂度：[如"每个图标最多30个锚点"]
- 颜色：[如"单色，使用 currentColor，描边风格不使用填充"]

请验证：
1. 描边粗细是否完全匹配？（测量所有路径）
2. 是否正确居中——视觉居中，而非数学居中？
3. 是否适配其形态的正确关键线形状？
4. 视觉重量是否与库中同等复杂度的图标一致？
5. 所有风格属性（端点、连接、圆角、颜色）是否正确？
6. 是否在目标渲染尺寸下对齐像素网格？
7. SVG 代码是否干净？（无多余组、变换或元数据）

输出：通过/未通过，每个未通过项附具体问题和修复说明。

提示词3：图标标准化计划

请生成标准化计划，将来自多个来源的图标统一为一致的库。

来源A：[描述——如"自定义图标，24px网格，2px描边，圆角端点"]
- 来自此来源的图标：[列表或数量]

来源B：[描述——如"Feather 图标，24px网格，2px描边，圆角端点，圆角连接"]
- 来自此来源的图标：[列表或数量]

来源C：[描述——如"Material 图标，24px网格，填充风格，不同视觉尺寸"]
- 来自此来源的图标：[列表或数量]

目标规范：[定义所有图标应遵循的统一风格]

对每个来源，请分析：
1. 与目标规范有哪些差异？（描边、网格、风格、重量）
2. 需要哪些变换？（缩放、描边调整、风格变更）
3. 哪些图标可以自动标准化，哪些需要手动重绘？
4. 工作量估算：快速修复（SVG变换）/ 中等（路径编辑）/ 完全重绘

输出：
- 标准化优先级矩阵（最显眼/最常用的图标优先）
- 可自动化修复的批量变换规则
- 无法自动标准化图标的手动重绘清单
- 用于QA审查的改造前后对比描述
- 设计师工时估算

11. AI设计评审与反馈综合器

在20分钟内将15位以上利益相关方的反馈综合为可操作的设计方向——化解此前让项目陷入僵局数周的矛盾意见。

痛点与解决方案

痛点：被千种矛盾意见慢慢消磨

设计评审是优秀设计慢慢死去的地方。典型的设计评审周期涉及来自产品经理、工程负责人、市场、高管、客户成功和其他设计师的反馈——通常是10到20人，分布在多轮评审会议中。每位利益相关方都有合理但不同的优先级：PM 想要展示更多功能，工程师担心实现复杂度，市场想要更大胆的品牌表达，高管想要"更有冲击力"，无障碍负责人标记合规问题。设计师收到40到80条独立反馈，其中许多相互矛盾。

综合的负担完全落在设计师身上：他们需要解析主观语言、调和冲突、提取可执行方向，并以某种方式产出一版能让相互竞争的利益相关方都满意的修改设计。这在认知上是设计工作中最艰难的任务之一——比创意工作本身更难。反馈散落在各处：Figma 评论、Slack 消息、邮件线程、会议录音和走廊里的口头交流。"让它感觉更高端"这样的一条反馈需要解读：是更多留白？换一种排版？更深的颜色？细腻的动效？设计师的解读可能与利益相关方的意图不符，由此引发又一轮评审。

政治维度让情况更糟。当营销副总裁说"这需要更多品牌感"，而产品副总裁说"减少品牌元素，聚焦内容"，设计师面临的是一个伪装成设计决策的政治选择。没有结构化的方式将这些冲突显性化并通过明确的权衡讨论解决，设计师要么试图面面俱到（结果是妥协的设计），要么暗中选边站（冒着政治风险）。项目在评审僵局中停滞数周，设计师不断在矛盾的反馈之间来回迭代。

COCO如何解决

多来源反馈收集与标准化：COCO 将所有渠道的反馈汇聚到统一视图：
- 接收来自 Figma 评论、Slack 讨论、邮件、会议记录和直接消息的反馈
- 将主观语言标准化为具体设计属性（"让它更有冲击力"→"提高视觉对比度和颜色饱和度"）
- 以利益相关方的角色、职级和专业领域为每条反馈打标签
- 对多个评审者提出的相同反馈进行去重（5人说了同样的事=1个问题，而非5个）
- 为反馈加上时间戳并排序，追踪意见如何跨轮次演变
冲突检测与映射：COCO 主动暴露矛盾，而非任其发酵：
- 识别直接冲突的反馈对（利益相关方A想要更多功能，利益相关方B想要更少）
- 在优先级-影响矩阵上映射每个冲突，呈现哪些权衡最关键
- 生成"张力图"，展示作用于关键设计决策上的对立力量
- 评估哪些冲突是真实的（真正的权衡）vs 表面的（对相同请求的不同表述）
- 生成供决策者聚焦讨论的冲突解决议程
主题分析与优先级排序：COCO 将反馈分组为排名的可执行主题：
- 按主题（布局、排版、颜色、内容、交互、信息架构）聚类反馈
- 基于提出该主题的利益相关方数量、职级和与产品目标的一致性，计算主题紧迫度
- 区分"必须处理"的反馈（来自决策者、无障碍要求、阻塞项）和"锦上添花"
- 识别与用户研究发现一致的反馈 vs 纯粹的利益相关方意见
- 生成优先级行动清单：能解决80%利益相关方关切的前10项修改
可执行修改计划：COCO 将综合后的反馈转化为具体的设计修改方案：
- 为每个优先主题生成具体的设计变更（不是模糊的方向，而是具体的调整）
- 将每个提议的变更与其对应的反馈来源映射（让利益相关方看到他们的意见被听到了）
- 为每项变更估算修改工时（快速 CSS 调整 vs 重大布局重构）
- 将修改分阶段——先处理关键反馈，再迭代次要内容
- 创建描述每项提议变更影响的改造前后预览
利益相关方沟通生成器：COCO 起草设计师讨厌写的回复和摘要：
- 生成反馈摘要邮件，说明听到了什么以及将采取什么行动
- 为不会被纳入的反馈起草外交化的回复，附理由说明
- 创建"已做决策"文档，供组织记忆参考（某个权衡为何以特定方式解决）
- 为每位利益相关方生成单独摘要，突出其领域反馈的处理情况
- 生成设计评审演示备注，将修改内容框架为对具体反馈的回应
评审周期分析：COCO 追踪反馈规律，改进设计评审流程本身：
- 衡量评审周期效率：达成共识需要多少轮、哪些利益相关方需要最多次迭代
- 识别指示系统性问题的循环反馈规律（如果导航反馈每次评审都出现，导航方案需要重新思考）
- 追踪反馈跟进情况：第N轮的反馈是否真的在第N+1轮得到处理？
- 生成"评审健康度"仪表板，呈现每个项目达成对齐的平均时间
- 基于已完成评审周期的分析推荐流程改进建议

量化结果与受益角色

可量化成果

反馈综合时间：从6-8小时人工解析压缩至20分钟 AI 辅助综合和行动规划
达成审批的评审轮次：从平均4.2轮降至2.1轮——冲突更快浮现和解决
项目停滞时间：设计评审导致的项目延误从平均12天降至3天（减少75%）
利益相关方满意度：评审后调查显示**89%**的利益相关方感到"被倾听"（从54%提升），因为反馈被明确映射到行动
冲突解决率：使用 COCO 冲突分析在单次专项会议中解决92%的矛盾反馈，vs 无结构综合时的40%

受益角色

产品设计师：将最消耗精力的工作转变为结构化、可管理的流程——花时间在设计上，而非解码反馈
产品经理：清晰了解矛盾的利益相关方优先级，以明确的权衡讨论取代被动的设计迭代
设计总监：评审周期效率和循环反馈规律的数据，用于改进团队流程和利益相关方管理
所有评审者：确信他们的反馈被捕获、分类和处理——或有清晰理由被明确降优先级

💡 实用提示词

提示词1：多利益相关方反馈综合

请将此次设计评审的所有反馈综合为优先级行动计划。

评审中的设计：[功能/页面名称]
评审轮次：[如 第2轮]

收到的反馈：
- [利益相关方姓名, 职位]："[原话或摘要反馈]"
- [利益相关方姓名, 职位]："[反馈]"
- [利益相关方姓名, 职位]："[反馈]"
- [以此类推，直至所有反馈]

此功能的产品目标：[列出前3个目标]
用户研究洞察：[列出应影响设计决策的关键发现]

请输出：
1. **反馈主题**：将所有反馈分组为5-8个主题，注明每个主题涉及的利益相关方人数
2. **冲突图**：识别任何矛盾的反馈对，描述其张力
3. **优先级行动清单**：按利益相关方共识+与产品目标一致性排名的前10项修改
4. **停车场**：本轮不处理的反馈，附理由说明
5. **推荐下一步**：下次评审前需要进行的具体设计修改

输出格式适合15分钟团队对齐讨论。

提示词2：主观反馈转译器

请将以下主观/模糊的反馈评论转化为具体、可操作的设计方向。

反馈评论：
1. "[模糊评论——如'需要感觉更高端']" ——来自 [职位]
2. "[如'页面感觉很乱']" ——来自 [职位]
3. "[如'能不能更现代一点？']" ——来自 [职位]
4. "[如'感觉不像我们的品牌']" ——来自 [职位]
5. "[如'流程感觉令人困惑']" ——来自 [职位]
6. "[如'需要更强的视觉层级']" ——来自 [职位]

当前设计背景：[简述当前设计——颜色、排版、布局方式]
品牌指南：[简述品牌属性和风格]

对每条评论，请提供：
1. **解读**：利益相关方在设计语言上可能指的是什么
2. **可能的根因**：2-3个可能引发这种反应的具体设计元素
3. **具体行动**：3项可解决该反馈的具体、可衡量的修改
   （如"将标题字重从500调整为700"而非"让它更粗"）
4. **验证问题**：一个向利益相关方确认解读的问题
5. **风险**：对此反馈过度修正可能导致什么问题

输出为设计师在修改过程中可参考的解读指南。

提示词3：矛盾反馈解决框架

请分析以下冲突的反馈，并提出解决框架。

冲突：
1. 冲突A：
   - [利益相关方1, 职位]："[立场——如'在首页展示所有功能以减少点击']"
   - [利益相关方2, 职位]："[对立立场——如'简化界面，减少可见选项']"

2. 冲突B：
   - [利益相关方3, 职位]："[立场]"
   - [利益相关方4, 职位]："[对立立场]"

产品优先级：[按序列出——如 1. 用户留存 2. 转化率 3. 品牌认知]
可用的用户数据：[任何相关的分析或研究数据]

对每个冲突，请提供：
1. **冲突性质**：这是真实的权衡、误解还是范围问题？
2. **用户视角**：用户数据/研究对哪个方向更有利？
3. **妥协方案**：2种能部分满足双方的设计方案
4. **推荐解决方向**：选择哪个方向，附与产品优先级挂钩的明确理由
5. **沟通方式**：如何向反馈未被优先采纳的利益相关方表述
6. **验证计划**：如何测试所选方向以确认这是正确的决策

输出为决策会议使用的冲突解决简报。

12. AI Figma组件使用分析器

在1小时以内分析200多个 Figma 文件的组件使用情况——识别浪费30%设计系统投入的孤立组件、脱离实例和采纳缺口。

痛点与解决方案

痛点：没有人完整采纳的设计系统

设计系统代表着巨大的投入——通常需要2到4个全职设计师和工程师维护组件库、文档网站和治理流程。然而大多数组织没有可靠的方式衡量这一投入是否在产生回报。核心问题——"各团队是否真的在使用我们的设计系统组件？"——出奇地难以回答。Figma 的原生分析提供的洞察有限，而当一个设计组织每季度产出数百个文件时，对单个文件的人工审计几乎不可能完成。

采纳缺口以三种昂贵的方式显现。第一，脱离实例：设计师从库组件开始，然后将其脱离以进行修改，切断了与事实来源的连接。脱离后，这些实例将不再接收组件改进时的更新，形成不断增长的维护负担。第二，自定义重建：设计师从零开始构建功能上与库组件重复的组件——要么因为他们不知道库组件存在，要么认为它太死板无法满足使用场景。第三，废弃组件：库中包含没有任何团队使用的组件——增加维护成本和浏览库时的认知负担。据估计，这三个问题在典型的企业设计组织中浪费了25%到35%的设计系统 ROI。

数据问题超越了简单的采纳计数。设计系统团队需要了解采纳缺口存在的原因。是因为结账流程有特殊需求，所以按钮组件在所有地方都被使用，唯独在结账流程中没有？是因为缺少某个配置选项，模态框组件频繁被脱离？是因为新卡片组件被某些团队采纳，但其他团队没有——是因为认知问题、文件迁移滞后，还是确实不适用？没有这些诊断数据，设计系统团队无法有效地安排改进优先级。他们花精力升级没人想要的组件，却忽视了大家都在绕过的那些。

COCO如何解决

自动化跨文件组件扫描：COCO 分析组织中的每个 Figma 文件，构建全面的使用图谱：
- 连接到 Figma API，枚举所有团队项目、文件和页面
- 识别所有文件中每个库组件的每个实例，包括嵌套实例
- 通过对照已知组件特征比较图层结构，检测脱离实例
- 通过识别结构上与库组件匹配但未链接的分组/框架，发现自定义重建
- 1小时内处理200多个文件，采用增量扫描（仅重新扫描上次分析后有修改的文件）
使用情况分析仪表板：COCO 生成设计系统团队真正需要的可行指标：
- 每个组件按团队、项目和文件细分的使用数量
- 每个组件的采纳率：（已使用实例数）/（应该使用的机会数）
- 脱离率：初次放置后被脱离的实例百分比
- 版本分布：每个组件哪个版本使用最多（表明迁移完成度）
- 趋势数据：过去3/6/12个月采纳率是否在提升或下降
脱离分析与根因识别：COCO 诊断设计师为何脱离组件：
- 对比脱离实例与源组件，识别修改了什么
- 将修改聚类为类别（颜色覆盖、布局变更、内容结构、添加元素、删除元素）
- 识别组件被脱离最常见的前5个原因——这是库改进最高优先级的方向
- 将脱离率与组件灵活性映射（变体选项越少的组件，脱离率越高）
- 生成具体的功能需求："为卡片组件添加'紧凑'尺寸变体将防止73%的脱离行为"
孤立组件与冗余检测：COCO 识别组件库中的浪费：
- 标记所有文件中零实例的库组件（孤立组件）——废弃候选
- 识别可整合的近重复组件（如 CardSmall 和 CompactCard 功能相同）
- 检测仅被单个团队使用的组件——它们应该是团队级而非库级？
- 查找未被应用任何地方的 Figma 样式（颜色、文字样式、效果）
- 计算孤立组件的维护成本（设计师花时间更新没人使用的组件）
团队级采纳报告：COCO 按团队细分采纳情况，使治理更具针对性：
- 每个团队的采纳评分卡，呈现整体组件使用率和趋势
- 识别哪些团队是"重度用户"，哪些需要采纳支持
- 检测仍在使用废弃组件的团队，生成迁移提醒
- 突出显示团队特有的组件需求（X团队一直在脱离表格组件，因为他们需要可排序的列）
- 生成"采纳引导"——当设计师创建与库组件相匹配的自定义组件时，触发上下文建议
影响衡量与 ROI 报告：COCO 量化设计系统的价值，为持续投入提供依据：
- 计算每月通过组件复用节省的时间（实例数 × 从零构建的预计时间）
- 衡量一致性改善：产品 UI 中使用标准化组件的百分比
- 追踪 Bug 减少：使用库组件的团队是否在提交更少的视觉 QA 缺陷？
- 估算脱离实例和自定义重建造成的技术债务成本
- 生成将设计系统投入与生产力和质量指标挂钩的高管友好型 ROI 报告

量化结果与受益角色

可量化成果

组件审计时间：从2周人工文件审查压缩至1小时以内跨200多个文件的自动扫描
脱离实例发现率：识别100%的脱离实例，vs 通过人工抽查仅知晓约15-20%
孤立组件缩减：识别零使用组件后，库从340个组件精简至280个（减少18%），降低维护负担
精准改进 ROI：针对前5个最高脱离率组件的改进，将采纳率从62%提升至一个季度内88%
设计系统时间节省：验证组件复用每月为整个组织节省420个设计师工时——这一指标此前无法计算

受益角色

设计系统团队：基于实际使用数据而非猜测或最响亮的需求，以数据驱动的方式安排组件改进优先级
产品设计师：基于真实使用规律演进的更合用组件，减少脱离和定制的需求
设计领导层：量化的 ROI 指标，用于捍卫设计系统投入并将资源分配到最高影响的改进
工程团队：随着设计系统采纳率提升，一次性组件实现减少，降低前端维护负担

💡 实用提示词

提示词1：组件使用清单

请为我们的设计系统生成全面的组件使用报告。

设计系统库：[名称，如"Acme Design System v3.2"]
组件类别：
- 原子：[列出——如 Button、Input、Checkbox、Radio、Toggle、Select]
- 布局：[列出——如 Card、Modal、Drawer、Accordion、Tabs、Table]
- 导航：[列出——如 Navbar、Sidebar、Breadcrumbs、Pagination、Stepper]
- 反馈：[列出——如 Toast、Alert、Badge、Progress、Skeleton、Spinner]
- 数据：[列出——如 Avatar、Tag、Tooltip、Popover、Chart]

使用库的团队/项目：
- [A团队]：[列出主要 Figma 项目/文件]
- [B团队]：[列出]
- [C团队]：[列出]
- [D团队]：[列出]

对每个组件，我需要：
1. 所有文件中的实例总数
2. 按团队细分的实例数
3. 最常用的变体（如"Button：primary、medium 占实例总数的60%"）
4. 最少使用的变体（废弃候选？）
5. 脱离实例数（如已知）
6. 组件最后一次被放入新设计的时间（近期性）

输出为使用矩阵表格，并突出显示：使用最多的前10个、使用最少的前10个，以及脱离率高的组件。

提示词2：脱离根因分析

请分析设计师为何脱离这些组件，并推荐库改进方向。

脱离率高的组件：
1. [组件名]：脱离率 [X]%
   - 脱离后的已知修改：[描述设计师通常会修改什么——如"在标签左侧添加图标"、"将布局从纵向改为横向"]

2. [组件名]：脱离率 [X]%
   - 已知修改：[描述]

3. [组件名]：脱离率 [X]%
   - 已知修改：[描述]

每个组件的当前 API：
- [组件1]：变体：[列出]。属性：[列出]。插槽：[列出]
- [组件2]：变体：[列出]。属性：[列出]。插槽：[列出]
- [组件3]：变体：[列出]。属性：[列出]。插槽：[列出]

请分析：
1. 哪些功能或变体可以防止每种常见的脱离原因？
2. 按（可防止的脱离次数）×（实现工时）排列改进优先级
3. 是否有任何脱离实际上是有效的一次性用例，不应该纳入库中？
4. 如果实施最高优先级的推荐方案，预计采纳率提升幅度
5. 为优先级最高的改进起草组件增强提案

输出为脱离分析报告，附具体的、有范围的组件改进提案。

提示词3：设计系统 ROI 报告

请为利益相关方演示生成设计系统 ROI 报告。

设计系统投入：
- 团队规模：[X]名设计师 + [Y]名工程师专职负责设计系统
- 年度成本：$[金额]（含薪资、工具、基础设施）
- 统计时段：[如过去12个月]

使用指标：
- 所有产品中的组件实例总数：[数量]
- 使用设计系统的团队：[数量] / [总团队数]
- 平均组件采纳率：[X]%
- 库中组件数量：[数量]

计算假设：
- 从零构建一个组件的平均时间：[如 4小时设计 + 8小时工程]
- 使用库组件的平均时间：[如 15分钟]
- 平均时薪（含社保）：$[金额]
- 自定义组件与库组件的 Bug 率：[如 自定义高3倍]

请计算并呈现：
1. **节省的时间**：复用库组件 vs 自定义构建所节省的工时
2. **节省的成本**：节省时间的美元价值
3. **质量影响**：通过使用经过测试的库组件预估防止的 Bug 数量
4. **一致性评分**：使用标准化组件的产品 UI 百分比
5. **ROI 比率**：（交付价值）/（投入）——以 X:1 表示
6. **回本周期**：设计系统投入何时实现收支平衡？

输出格式为第1页展示关键指标、后续页展示支撑细节的高管演示文稿。

13. AI深色模式设计转换器

将亮色模式设计转化为生产就绪的深色模式，4小时完成原本需要3周的工作——处理100多个屏幕的语义颜色映射、层次感调整和图片处理。

痛点与解决方案

痛点：深色模式不是"把颜色反转"那么简单

深色模式已从可选功能变为用户期望——82%的智能手机用户表示至少有时会使用深色模式。然而，正确实现深色模式是产品开发中最被低估的设计任务之一。将深色模式当作简单颜色反转来处理的团队很快会发现，反转后的亮色模式设计是一场不可用、难看且无法通过无障碍标准的灾难。纯白文字在纯黑背景上的高对比度会引起眼睛疲劳。阴影在深色表面上变得不可见。透明背景的图片会出现难看的白色光晕。在白色背景上显得鲜艳的品牌色，在深灰背景上显得刺眼。

正确的深色模式设计需要从语义层面重新审视整个色彩体系。表面层次感——在亮色模式中通过阴影传达——在深色模式中必须转变为通过表面色明度来传达（较高层次的表面更亮）。文字层级需要重新校准，因为在白色背景上产生可读主次文字的同等透明度差异，在深色背景上会失效。品牌色需要降低饱和度或调整明度，以避免在深色表面上产生振动效果。状态颜色（错误用红色，成功用绿色）需要不同的值，以在不压倒界面的前提下保持可识别性。每项调整都与其他调整相互影响，构成一个复杂的优化问题。

工作量之大才是真正令人头疼的地方。典型的 SaaS 产品有80到150个独特屏幕。每个屏幕都需要深色模式处理，每次处理涉及数十个独立的颜色决策。一名设计师全职工作每天能处理5到8个屏幕——完整的深色模式转化需要2到4周。乘以响应式变体、组件状态和边界情况，深色模式很容易变成一个季度级的项目。大多数团队选择走捷径，推出视觉问题明显的深色模式：卡片融入背景、有色表面上文字难以阅读、图片在深色背景下看起来不对——结果是一个质量欠佳的体验。

COCO如何解决

语义色彩体系分析：COCO 在转换之前，将亮色模式设计映射到语义色彩结构：
- 分析整个亮色模式设计，识别所有独特颜色及其语义角色（背景、表面、文字、边框、品牌、状态）
- 将每种颜色映射到其功能目的，而非视觉值（这不是"白色"——而是"background-primary"）
- 识别必须保留的颜色关系（主文字始终在其背景上有 X 对比度）
- 检测应为令牌却被硬编码的颜色，并标记用于令牌化
- 创建完整的语义颜色清单，附亮色模式值，准备好进行深色模式映射
智能深色模式调色板生成：COCO 基于成熟的感知科学生成深色模式颜色：
- 使用 Material Design 3 层次原则（非纯黑色——#121212 基础色）转换背景体系
- 通过降低饱和度和提高明度，防止品牌色在深色背景上产生振动效果
- 重新校准文字颜色，在深色表面上保持相同的表观层级（主要/次要/禁用）
- 修改状态颜色（错误、警告、成功、信息），在深色背景上保持正确的识别度和足够的对比度
- 生成完整的深色模式调色板，将每种颜色从其亮色模式语义等价物映射过来
表面层次感重设计：COCO 将层次感体系从阴影驱动转变为明度驱动：
- 将每个亮色模式层次级别（阴影深度）映射到深色模式的表面明度级别
- 创建5到8个层次等级，表面颜色经过精确校准（每级比下一级稍亮）
- 确保边框和分割线在深色表面上可见（通常需要调整不透明度和颜色）
- 调整覆盖层颜色（模态背景、抽屉遮罩），在深色背景上实现适当的遮暗效果
- 验证层次感的视觉清晰度——用户能一眼区分各表面层次
图片与媒体处理：COCO 处理破坏大多数深色模式实现的视觉资产：
- 识别需要深色兼容处理的透明背景图片（添加深色背景或调整透明度）
- 建议摄影图片的降暗值，防止亮图压倒深色界面
- 为深色背景调整插画颜色（亮色插画在深色背景上需要反色或重新着色）
- 处理 Logo 变体——检测主 Logo 在深色背景上不可见的情况，标记需要替代版本
- 为可通过编程适配的图片提供 CSS/filter 建议，对需要新资产的图片单独说明
组件级深色模式规格：COCO 为设计系统中每个组件生成深色模式规格：
- 为每个组件产出包含所有状态精确颜色值的深色模式变体规格
- 处理复杂组件：带交替行的数据表格、多系列图表、含校验状态的表单字段
- 指定在深色背景上可见的焦点指示器（亮色模式的蓝色焦点环在深色背景上常常消失）
- 记录提供可见反馈而不产生刺目对比变化的悬停和激活状态颜色
- 创建组件迁移清单，说明每个组件需要哪些深色模式支持改动
跨屏幕验证与一致性：COCO 整体验证深色模式转换的效果：
- 以深色模式渲染每个屏幕并运行自动对比度检查（对照 WCAG 标准）
- 识别深色模式转换造成布局问题的屏幕（依赖阴影进行分隔的元素）
- 检查深色模式体验跨所有屏幕的一致性——相同的表面层级、相同的文字颜色
- 验证亮色和深色模式之间的过渡不会产生颜色闪烁效果
- 生成附每个屏幕通过/未通过状态和优先级修复清单的深色模式 QA 报告

量化结果与受益角色

可量化成果

转化周期：120个屏幕的完整深色模式设计从3周压缩至4小时 AI 生成转化加设计师审查
WCAG 合规率：深色模式设计首次即达到100% AA 对比度合规（手工完成时通常仅65%）
用户满意度：深色模式用户满意度评分达4.6/5（vs 仓促实现的深色模式行业平均3.8/5）
资产返工：图片和插画深色模式兼容性问题被提前发现，上线后紧急修复从25个降至2个
令牌覆盖率：深色模式转化推动令牌化率从71%提升至99%，提升整体设计系统成熟度

受益角色

产品设计师：跳过数周繁琐的颜色选取工作，专注于审查和精炼 AI 生成的深色模式设计
前端工程师：完整的基于令牌的深色模式规格，可作为主题切换而非逐组件覆盖来实现
产品经理：将深色模式作为标准功能推出，不需要占用路线图多周的设计绕路
终端用户：体验精心设计的深色模式，而非造成眼睛疲劳和可读性问题的仓促反色版本

💡 实用提示词

提示词1：亮色到深色模式色彩体系转换

请将我们的亮色模式色彩体系转化为完整的深色模式调色板。

亮色模式颜色（语义化）：
- 背景主色：[HEX]
- 背景次色：[HEX]
- 表面色（卡片、模态框）：[HEX]
- 悬浮表面（下拉、弹出框）：[HEX]
- 主文字色：[HEX]
- 次文字色：[HEX]
- 禁用文字色：[HEX]
- 品牌主色：[HEX]
- 品牌辅色：[HEX]
- 默认边框：[HEX]
- 强调边框：[HEX]
- 成功色：[HEX]
- 警告色：[HEX]
- 错误色：[HEX]
- 信息色：[HEX]

亮色模式的表面层级（通过阴影传达）：
- 第0级：无阴影（平面）
- 第1级：[阴影规格]
- 第2级：[阴影规格]
- 第3级：[阴影规格]
- 第4级：[阴影规格]

对每种亮色模式颜色，请生成：
1. 深色模式等价值，附 HEX 值
2. 调整依据（为何选择这个具体值）
3. 文字颜色在各自背景上的对比度（必须通过 WCAG AA）
4. 感知关系保留检查（视觉层级是否得到维护？）

同时生成：
- 深色模式层级色阶（每个级别的表面颜色，取代阴影）
- 深色模式的覆盖层/遮罩颜色
- 深色模式的焦点指示器颜色
- 深色模式的选中/高亮颜色

输出为令牌映射表格：令牌名 | 亮色值 | 深色值 | 备注

提示词2：组件深色模式规格

请为此组件的所有状态生成深色模式规格。

组件：[名称，如"数据表格"]
亮色模式规格：
- 背景色：[HEX]
- 表头背景：[HEX]
- 行背景（偶数行）：[HEX]
- 行背景（奇数行）：[HEX]
- 行悬停：[HEX]
- 行选中：[HEX]
- 边框颜色：[HEX]
- 主文字色：[HEX]
- 次文字色：[HEX]
- 排序图标：[HEX]
- 分页文字：[HEX]
- 分页激活状态：[HEX]

需转换的状态：
- 默认、悬停、选中、禁用、加载中（骨架屏）、错误、空状态

对每种深色模式状态：
1. 每个颜色值附 HEX
2. 对比度验证（文字在背景上）
3. 任何非颜色变更的需要（如从实线边框改为细微边框，去除阴影）
4. 交互反馈可见性检查（深色背景上的悬停状态是否足够显眼？）

同时解决：
- 深色模式下是否需要边框？（亮色模式可能没有边框，但深色模式需要）
- 骨架加载状态如何适配？（光泽动画的方向、颜色）
- 排序指示器和图标是否可见？

输出为供工程实现的深色模式组件规格表。

提示词3：深色模式无障碍验证

请验证此深色模式设计是否满足无障碍要求。

深色模式颜色规格：
[粘贴您的深色模式颜色令牌——背景、表面、文字颜色、交互颜色、状态颜色]

待验证的屏幕描述：
1. [屏幕名称]：[描述关键元素及其颜色——如"含品牌主色背景的头部、白色文字、含表面背景的搜索框"]
2. [屏幕名称]：[描述]
3. [屏幕名称]：[描述]

对每个屏幕，请验证：
1. **文字对比度**：所有文字满足 WCAG AA（4.5:1 正常文字，3:1 大号文字）——计算每个组合
2. **非文本对比度**：所有交互元素（按钮、输入框、图标）对相邻颜色的对比度 ≥ 3:1
3. **焦点指示器**：在深色背景上是否可见？（很多亮色模式焦点环在深色背景上会消失）
4. **选中状态**：用户能否区分选中和未选中项？
5. **禁用状态**：禁用元素是否可识别为禁用，同时仍保持可读性？
6. **仅颜色传达信息的情况**：是否有信息仅靠颜色传达？（在深色背景下颜色感知发生变化，这一问题更为关键）

输出：每个屏幕每个标准的通过/未通过无障碍验证矩阵，附具体失败项的修复说明。

14. AI微交互原型生成器

在90分钟内生成生产就绪的微交互规格——含完整的时序曲线、状态过渡和代码片段，而原来需要2周才能完成原型和文档。

痛点与解决方案

痛点：因为没时间写规格，微交互总是被砍掉

微交互是产品从"还行"到"令人愉悦"的差距所在。开关切换时的细腻弹跳、任务完成时令人满足的对勾动效、保持空间感的手风琴展开——这些反馈与打磨的瞬间对感知产品质量的影响远超其比重。尼尔森诺曼集团的研究表明，恰当的动效设计可将感知等待时间缩短40%，并增强用户对操作已被响应的信心。然而在大多数产品团队中，微交互是紧张排期下最先被牺牲的内容。

规格问题是根本原因。设计一个微交互，设计师需要定义：触发事件、初始状态、过渡属性、时长、缓动曲线、中间关键帧（如有）、最终状态和边界情况（动画中途再次触发时怎么处理？）。向工程师传达这些更难。静态设计稿无法展示动效；视频原型展示了效果，但工程师仍需逆向工程时序、缓动和状态逻辑；Principle 或 Framer 等原型工具能演示交互，但工程师依然需要反推参数。设计师意图到工程实现之间，单个微交互平均经历3到5轮来回迭代，而一个功能可能需要10到20个微交互。

大多数设计师跳过详细规格，给工程师模糊的方向："这里加个漂亮的过渡"或"让它顺滑地滑入"。工程师为了加速交付，会实现最简单的动效（300ms ease-in-out 改变透明度）或完全不加动效。结果：产品的动效杂乱无章、千篇一律，既未能让用户愉悦，也未能强化界面的空间模型。真正投入打磨微交互的团队通常有专职动效设计师——这是90%的产品组织无法承担的奢侈配置。

COCO如何解决

交互模式识别：COCO 基于交互设计原则识别微交互应该出现的位置：
- 分析产品用户流程，识别所有受益于动效反馈的状态过渡
- 将触发器分类：用户行为（点击、悬停、拖拽）、系统事件（数据加载、发生错误）或状态变化（切换、导航）
- 将每个触发器映射到合适的动效模式：入场、出场、过渡、反馈、加载或庆祝
- 按用户影响排列优先级：高频操作获得精致动效，低频操作使用简单过渡
- 生成交互审计报告，呈现当前有哪些动效、缺少哪些、哪些不一致
动效规格生成：COCO 产出精确、可实施的动画规格：
- 定义每个参数：动画属性（transform、opacity、height、color）、时长（毫秒）、延迟（毫秒）、缓动（cubic-bezier 值）
- 为复杂动画生成关键帧分解，附基于百分比的关键时间点
- 指定弹性物理参数（刚度、阻尼、质量），实现自然感的动效
- 记录状态机逻辑：动画被中断时发生什么（反向、完成还是取消）
- 创建时序图，展示多个动画属性如何协调（错列、顺序、并行）
缓动曲线库：COCO 根据交互场景应用合适的缓动曲线：
- 将每种交互类型映射到正确的缓动范式：入场用 ease-out，出场用 ease-in，过渡用 ease-in-out
- 提供针对特定交互调优的精确 cubic-bezier 值（而非对所有场景使用通用 ease-in-out）
- 为应有物理感的交互生成自定义弹性曲线（下拉刷新、滑动关闭、吸附到网格）
- 确保产品中缓动曲线的一致性——所有入场动画使用同一族曲线
- 记录缓动选择的理由，让未来的设计师理解每条曲线的选用原因
多状态过渡映射：COCO 处理多个状态和动画交互的复杂交互流程：
- 为有3个以上状态的组件创建状态过渡图（按钮：默认→悬停→按下→加载中→成功）
- 为每对相连状态指定动画（不只是前进方向——还有反向、跳过和中断）
- 定义编排规则：当容器动画时，子元素以什么顺序动？
- 处理响应式动效：指定动画在不同设备上的适配（减少运动偏好、低性能设备）
- 记录手势驱动的动画，附基于物理的参数（速度阈值、减速率、吸附点）
代码就绪的实现片段：COCO 为每个微交互生成框架特定的代码：
- 产出用于简单状态动画的 CSS animation/transition 代码
- 为复杂交互生成 Framer Motion (React)、Vue Transition 或 SwiftUI 动画代码
- 创建需要高于 CSS 精度的动画的 Lottie 兼容规格
- 包含无障碍考量：每个动画附 prefers-reduced-motion 媒体查询降级方案
- 提供性能说明：哪些动画使用 GPU 合成（transform、opacity），哪些是 CPU 密集型（height、width）
动效系统文档：COCO 为设计系统创建全面的动效语言：
- 定义产品的动效设计原则（如"动效是功能性的，而非装饰性的；快速响应而非缓慢戏剧化"）
- 创建时长比例尺：微型（100ms）、小（200ms）、中（300ms）、大（500ms）附使用场景
- 记录标准缓动曲线，附名称和使用场景（标准、减速、加速、突变）
- 生成动效组件库规格：工程师无需设计师指导即可应用的可复用动效模式
- 生成设计评审中的动效审计检查清单（每个状态过渡是否有适当的动效？）

量化结果与受益角色

可量化成果

微交互规格时间：从2周原型制作和文档工作压缩至90分钟 AI 生成规格和代码片段
实现准确度：首次动效实现与规格匹配度95%（vs 工程师按模糊"让它顺滑"指令实现时的40%）
动效一致性：产品级动效一致性评分从34%（随机、临时动效）提升至91%（系统化动效语言）
动画性能：100%的 COCO 规格动画使用 GPU 合成属性，消除了每次发布平均8个的卡顿动效报告
减少运动合规率：所有指定动画包含 prefers-reduced-motion 降级方案，实现100%动效无障碍（vs 无 COCO 时的12%）

受益角色

产品设计师：无需动效设计专业知识或耗时的原型工具，即可规格化精致的微交互
前端工程师：含精确参数的即用型动画代码，消除时序和缓动的猜测与迭代
设计系统团队：记录完备的动效语言，确保所有产品团队的一致性，无需逐一审查每个动画
对动效敏感的用户：每个动画都附带减少运动替代方案，使产品对启用减少运动设置的35%用户完全无障碍

💡 实用提示词

提示词1：组件微交互规格

请为此组件生成完整的微交互规格。

组件：[如"开关切换"]
状态：[列出——如 关闭、开启、禁用-关闭、禁用-开启、加载中]
触发器：[如"点击/触摸开关或其标签"]

当前行为：[描述——如"即时状态切换，无动效"]
期望感受：[如"干脆、令人满足，像实体开关"]

请生成以下规格：
1. **关闭→开启过渡**：
   - 动画属性（滑块位置、轨道颜色、图标如有）
   - 每个属性的时长和缓动
   - 多步骤时的关键帧分解

2. **开启→关闭过渡**：
   - 相同结构（可与关闭→开启不同）

3. **悬停状态**：
   - 悬停时变化什么（缩放、阴影、高亮环）
   - 时长和缓动

4. **按压状态**：
   - 按压/激活时变化什么（滑块压缩、缩放缩小）
   - 时长和缓动

5. **禁用状态过渡**：
   - 进入禁用状态（如何变灰/变暗）
   - 离开禁用状态（如何恢复）

6. **加载状态**（如适用）：
   - 加载指示器动画（旋转、脉冲、光泽）
   - 从加载→成功/失败的过渡

7. **减少运动降级方案**：
   - 启用 prefers-reduced-motion 时发生什么？

请包含：
- 每个过渡的 CSS/Framer Motion 代码片段
- Cubic-bezier 值或弹性参数
- 展示属性协调的时序图

提示词2：页面过渡编排

请设计以下两个页面/视图之间过渡的动效编排。

来源页面：[描述当前页面——关键元素和布局]
目标页面：[描述目标页面——关键元素和布局]
触发器：[如"用户点击列表项查看详情"]
导航模式：[如"前进钻取"、"横向标签切换"、"模态覆盖"]

请编排：
1. **退场动画**（当前页面）：
   - 哪些元素退出以及以什么顺序？
   - 每个元素的时长和缓动
   - 运动方向（淡出、向左滑动、缩小）

2. **共享元素过渡**（如有）：
   - [如"列表项的缩略图扩展为详情页的主视觉图"]
   - 起始位置/尺寸 → 结束位置/尺寸
   - 时长和缓动
   - 周围内容如何腾出空间？

3. **入场动画**（新页面）：
   - 哪些元素进入以及以什么顺序？
   - 元素间的错列时序（如每项间隔50ms）
   - 每个元素的时长和缓动

4. **反向过渡**（返回时）：
   - 是精确反向，还是不同？
   - 有何区别？

5. **中断处理**：
   - 过渡完成前用户再次导航怎么办？
   - 过渡中途用户按返回怎么办？

请包含：
- 展示所有元素在时间轴上的时序图
- 总过渡时长
- 框架代码：[React/Vue/CSS——指定偏好]
- 减少运动降级（通常：即时切换，无动效）

提示词3：动效设计系统文档

请为我们的产品创建一套标准化动效的动效设计系统文档。

产品个性：[描述——如"专业但亲切，高效但不冷漠"]
当前动效状态：[描述——如"不一致，部分 CSS 过渡，无体系"]
目标平台：[Web、iOS、Android]

请生成完整的动效系统文档：

1. **动效原则**（3-5条）：
   - [如"目的性：每个动画服务于功能目标"]
   - [写出符合产品个性的原则]

2. **时长比例尺**：
   - 定义4-5个时长令牌，附名称、值（毫秒）和适用场景
   - [如"即时：100ms——悬停等微反馈"]

3. **缓动曲线**：
   - 定义4-5个命名缓动曲线，附 cubic-bezier 值和使用场景
   - [如"高效：cubic-bezier(0.2, 0, 0.38, 0.9)——标准过渡"]

4. **动效模式**：
   - 入场：元素如何出现（方向、缩放、透明度）
   - 出场：元素如何消失
   - 过渡：元素如何在状态间变化
   - 强调：如何吸引对某个元素的注意
   - 加载：标准加载和骨架屏模式

5. **编排规则**：
   - 列表项间的错列时序
   - 父先子还是子先父？
   - 屏幕上同时动效的最大数量

6. **无障碍**：
   - prefers-reduced-motion 策略
   - 什么减少（装饰性动效） vs 什么保留（功能性状态变化）

7. **实现参考**：
   - 所有时长和缓动令牌的 CSS 自定义属性
   - 可复用的动效工具类
   - 框架特定的辅助工具

格式化为设计系统文档页。

15. AI设计令牌管理器

自动化管理Figma、代码和文档之间的设计令牌全生命周期——将令牌漂移事件从每季度35次降至不足2次，同时将令牌管理工时减少85%。

痛点与解决方案

痛点：设计令牌在每个平台上持续失去同步

设计令牌是设计系统的原子单位——用于确保设计文件与代码之间一致性的命名值（颜色、间距、排版、阴影、圆角）。理论上，令牌创造了单一事实来源。实践中，大多数组织在3到5个独立位置维护令牌，这些位置会逐渐产生分歧：Figma 变量、CSS 自定义属性、Tailwind 配置、iOS 颜色资产、Android 资源文件和文档网站。每个位置都有自己的格式、更新流程和维护人员。当设计团队将主蓝色从 #0052CC 更新为 #0055D4 时，这一变更需要同步到每个平台——而这很少能同步且正确地完成。

同步问题因组织复杂性而加剧。典型的令牌系统有200到500个令牌，按2到3层层级组织（基础令牌、语义令牌、组件令牌）。修改单个基础令牌可能级联影响数十个语义令牌和数百个组件级应用。手动追踪这些级联效应容易出错：设计师在 Figma 中更改 --color-blue-600，前端工程师更新 CSS 变量，但移动端团队直到三周后 QA 发现差异才得到通知。每个发布周期5到10次令牌变更，同步工作量就成为显著的工程税。

文档是长期被忽视的第三支柱。即便 Figma 和代码保持同步，设计系统文档网站通常也会展示陈旧的令牌值、错误的使用示例或遗漏的新令牌。设计师在构建新页面时参考文档，如果文档显示 --spacing-lg 是24px，而实际上两个月前已更新为28px，那么基于这些文档创建的每个新设计从一开始就是错误的。文档缺口侵蚀了对设计系统的信任——团队因被误导过而停止查阅文档，进一步加速了分歧。

COCO如何解决

集中化令牌注册表：COCO 建立所有令牌的单一事实来源，并进行自动化分发：
- 维护包含每个令牌名称、值、描述、类别和使用指南的规范令牌数据库
- 对所有令牌变更进行版本控制，附完整审计追踪（谁在何时改了什么、为什么改）
- 支持完整的令牌层级：基础（原始值）→ 语义（目的导向）→ 组件（具体使用）
- 管理平台特定的令牌转换（Web 用 HEX，iOS 用 UIColor，Android 用 @ColorRes）
- 生成唯一令牌 ID，跨所有平台追踪相同的令牌，无论命名格式差异如何
跨平台同步引擎：COCO 无需任何人工干预即可保持每个平台的同步：
- 同时将令牌更新推送到 Figma 变量、CSS 自定义属性、Tailwind 配置、Swift/Kotlin 文件和 JSON 配置
- 通过对照规范注册表比较每个平台的当前值，检测平台特定的漂移
- 当令牌变更时在代码仓库中生成 Pull Request，附清晰的差异对比和回滚说明
- 通过 API 更新 Figma 库变量，并向所有用户触发库发布通知
- 每日运行漂移检测扫描，向设计系统团队告警任何未经授权的平台级覆盖
级联影响分析：COCO 在令牌变更上线前，完整映射其波纹效应：
- 当基础令牌被修改时，追踪所有下游依赖项（基础→语义→组件→使用位置）
- 生成视觉影响报告，呈现受变更影响的所有屏幕、组件和状态
- 在生产前识别破坏性变更（间距令牌增大导致布局溢出）
- 提供安全/不安全变更分类：重命名令牌是破坏性的，调整其值通常是安全的
- 对高影响变更推荐分阶段推出方案，附每个团队的具体迁移步骤
令牌命名与治理：COCO 执行命名规范，防止令牌膨胀：
- 根据已建立的命名规范（如类别-属性-变体-状态）验证新令牌名称
- 检测重复令牌（不同名称、相同或相近值）并推荐整合
- 标记过于具体（应泛化）或过于通用（名称未传达目的）的令牌
- 执行层级纪律：防止语义令牌引用其他语义令牌（必须引用基础令牌）
- 生成季度令牌健康报告：总数量、增长率、使用频率和清理建议
自动化文档生成：COCO 使令牌文档保持完美的时效性：
- 自动生成包含当前值、视觉色样和使用示例的可浏览令牌目录
- 令牌变更后数分钟内更新文档——文档永不过时
- 生成平台特定的使用指南（如何在 CSS、React、Swift、Kotlin 中引用每个令牌）
- 为每次令牌变更生成改变前后的视觉对比，让设计师能验证影响
- 当令牌被重命名、废弃或重构时自动创建迁移指南
令牌使用分析：COCO 追踪令牌的实际使用方式，为设计系统决策提供信息：
- 统计跨所有代码库的每个令牌引用次数，识别使用最多和最少的令牌
- 检测代码中应该使用令牌却被硬编码的值（如 CSS 中出现 #0052CC 但未引用令牌）
- 识别代码中从未被使用的令牌（孤立令牌）——废弃候选
- 随时间追踪令牌采纳：令牌化是否在增加，还是开发者仍在硬编码？
- 衡量"令牌覆盖率"——已令牌化的设计值 vs 硬编码的百分比

量化结果与受益角色

可量化成果

令牌漂移事件：跨平台差异从每季度35次降至不足2次（减少94%）
令牌更新传播时间：从2-3周才能触达所有平台缩短至4小时以内完成全面同步
令牌管理工时：从每周20小时的手动同步、审计和文档工作降至每周3小时的审查和审批（减少85%）
代码中的令牌覆盖率：硬编码值替换为令牌，覆盖率从64%提升至96%（跨所有代码库）
文档时效性：令牌文档始终保持最新（任何变更后4小时内），vs 之前平均滞后6周

受益角色

设计系统团队：通过单一界面管理令牌，而非手动更新5个以上平台——专注于策略而非同步
产品设计师：确信 Figma 中的令牌值与代码中的实现完全一致——不再有"设计中看起来不一样"的对话
前端工程师：包含平台特定使用示例的清晰、最新令牌参考——不再猜测使用哪个令牌或发现陈旧文档
移动端工程师：iOS 和 Android 令牌值自动生成并与 Web 保持同步，消除了历史上造成跨平台视觉不一致的延迟

💡 实用提示词

提示词1：令牌系统架构设计

请为我们的产品设计完整的设计令牌架构。

当前状态：
- 设计工具：[Figma/Sketch]
- 前端框架：[React/Vue/Angular]
- CSS 方案：[CSS 变量/Tailwind/CSS Modules/Styled Components]
- 移动端：[iOS Swift/Android Kotlin/React Native/Flutter]
- 当前令牌数量：[大致数量]
- 当前管理方式：[如"手动，Figma 样式 + 硬编码 CSS"]

请设计3层令牌结构：

1. **基础令牌（第1层）**：原始值
   - 颜色调色板：定义完整的颜色比例尺（[品牌色]50-900，中性50-900，语义色）
   - 间距比例尺：[4px基础？8px基础？]
   - 排版比例尺：字号、字重、行高、字间距
   - 圆角比例尺
   - 阴影/层次感比例尺
   - 断点
   - Z-index 比例尺

2. **语义令牌（第2层）**：目的导向，引用第1层
   - 表面颜色（背景、表面、悬浮表面、覆盖层）
   - 文字颜色（主要、次要、禁用、反色、链接）
   - 边框颜色（默认、强调、焦点、错误）
   - 交互颜色（悬停、激活、选中、禁用）
   - 间距（组件内边距、区块间距、页面边距）
   - 排版（heading-1 到 heading-6、正文、说明、标签、上划线）

3. **组件令牌（第3层）**：引用第2层的具体组件
   - [列出5-10个关键组件及其令牌需求]

请包含：
- 命名规范和示例
- 深色模式策略（哪一层处理切换？）
- 平台导出格式
- 治理规则（谁可以创建、修改、废弃令牌？）

提示词2：令牌审计与清理

请审计我们当前的设计令牌并推荐清理操作。

当前令牌清单：
[粘贴令牌列表或描述结构，如：]
- 颜色：[X]个令牌（列出任何已知问题令牌）
- 间距：[X]个令牌
- 排版：[X]个令牌
- 阴影：[X]个令牌
- 圆角：[X]个令牌
- 其他：[描述]

已知问题：
- [如"多个相似灰色令牌：gray-100、gray-light、background-subtle、surface-secondary"]
- [如"部分间距令牌跳值：有4、8、16、32，但没有12或24"]
- [如"排版令牌混合了仅字号令牌和复合令牌"]

请分析：
1. **重复项**：值相同或相近但名称不同的令牌 → 整合推荐
2. **缺口**：团队正在硬编码的缺失令牌值（如无12px间距令牌，工程师就用原始12px）
3. **孤立令牌**：未在任何地方使用的令牌 → 废弃候选
4. **命名不一致**：不符合命名规范的令牌
5. **层级违规**：引用其他语义令牌的语义令牌（应引用基础令牌）
6. **未使用的比例尺步骤**：没有语义令牌引用的基础比例尺值

输出：
- 令牌清理操作清单，附优先级
- 填补缺口的推荐新增令牌
- 整合/重命名令牌的迁移计划
- 工时估算和建议的分阶段推进方式

提示词3：令牌变更影响分析

请在我们实施以下提议的令牌变更前，分析其影响。

提议的变更：
1. [令牌名]：[当前值] → [新值]。原因：[为什么]
2. [令牌名]：[当前值] → [新值]。原因：[为什么]
3. [令牌名]：重命名，从 [旧名] 到 [新名]。原因：[为什么]
4. [令牌名]：废弃（用 [替代品] 替换）。原因：[为什么]
5. [令牌名]：新令牌，值：[值]。原因：[为什么]

令牌层级（用于级联分析）：
[粘贴或描述哪些语义令牌引用哪些基础令牌]

使用这些令牌的组件：
[列出已知的组件使用情况，或描述一般使用模式]

对每项变更，请分析：
1. **级联图**：哪些下游令牌和组件受影响？
2. **视觉影响**：什么会看起来不同？（描述具体的 UI 变化）
3. **破坏风险**：是否有布局会破坏、文字溢出或对比度失败？
4. **迁移工作量**：需要哪些代码/设计文件变更？
5. **回滚计划**：如果上线后发现问题，如何回滚？

输出：每项变更的影响评估报告，附继续/不继续的推荐意见和分阶段实施计划。

16. AI视觉回归测试引擎

在部署前捕获100%的非预期视觉变化——在50多个页面-组件组合中将生产环境中的视觉 Bug 从每次发布22个降至零。

痛点与解决方案

痛点：视觉 Bug 穿越代码审查和 QA 悄悄上线

视觉回归——UI 元素外观的非预期变化——是最常见且最令人沮丧的生产 Bug 类别之一。一次 CSS 重构修复了某页面按钮的内边距，却破坏了另一页面的卡片布局。依赖包更新悄然改变了字体渲染。一个新功能的样式泄漏到相邻组件。这些回归通过了代码审查，因为代码变更看起来正确；通过了功能 QA，因为功能仍然有效；只有当有人查看那个特定的页面、视口、浏览器和数据状态组合时才变得可见——而这种组合有数百种，人工视觉 QA 在统计上必然会遗漏一些。

生产环境中的视觉回归成本与其技术上的微不足道不成比例。一个错位的按钮或重叠的文本元素需要与严重安全补丁相同的部署流程来修复：问题识别、工单创建、设计审查、代码修复、代码审查、QA、预发布验证和生产部署。每个视觉 Bug 修复会带来4到8小时的流程开销，无论实际解决它的5分钟 CSS 变更如何。以平均每个发布周期15到25个视觉回归，组织每月花费100多个工程工时在视觉 Bug 修复上——如果能在提交前捕获问题，这些时间本可节省。

现有的视觉回归工具（Percy、Chromatic、BackstopJS）有所帮助，但存在采用和维护挑战。它们需要大量设置：每个组件状态、视口尺寸和数据变体的截图基线。随着产品演进，基线必须更新——区分"需要新基线的有意变更"与"需要修复的意外回归"需要人工判断。团队频繁禁用产生过多误报的测试，侵蚀覆盖率。工具开销意味着大多数团队只覆盖最关键的页面，而非整个产品面，60%到80%的 UI 没有视觉回归保护。

COCO如何解决

智能基线管理：COCO 维护随产品演进的视觉基线，而非与变更对抗：
- 自动为设计系统中的每个页面、组件、状态和视口组合捕获截图基线
- 使用感知哈希而非逐像素比较——不受跨环境的亚像素渲染差异影响
- 将变更分类为有意的（关联到设计工单或令牌更新）vs 无意的（无对应设计变更）
- 当变更被确认为有意时自动更新基线，无需人工维护即可保持覆盖率
- 维护基线版本历史，任何基线都可以回滚（如果已批准的变更后来被重新考虑）
全面覆盖生成：COCO 确保测试每个视觉状态，而非仅是理想路径：
- 在每个定义断点（移动端、平板、桌面、宽屏）为每个页面生成测试配置
- 创建数据变体：每个依赖数据视图的空状态、单条目、多条目、长文本、错误状态
- 测试所有组件状态：跨组件库的默认、悬停、聚焦、激活、禁用、加载中、错误
- 通过生成确定性测试数据处理动态内容，产出可重复的截图
- 随代码库增长自动发现新页面和组件，防止覆盖率缺口
感知差异分析：COCO 区分有意义的视觉变化与渲染噪音：
- 应用反锯齿容差，忽略跨环境的亚像素渲染差异
- 除像素差异外还使用结构相似性（SSIM）比较进行布局级回归检测
- 将相关差异分组（页面上所有文字移位=字体变更，而非100个独立问题）
- 计算感知影响分数：主要 CTA 上的2px偏移比页脚链接上的2px偏移更重要
- 过滤已知的可接受差异（日期/时间戳、随机头像颜色、动画元素）
根因识别：COCO 不只标记问题——还追踪到导致问题的代码变更：
- 通过每次提交的差异截图比较，将视觉变更与具体提交相关联
- 识别引入回归的确切 CSS 规则变更、组件更新或依赖包升级
- 检测级联回归（影响20个页面的全局样式变更可追溯到一次 CSS 修改）
- 提供具体的文件、行号和导致视觉差异的属性变更
- 建议修复方案：定向 CSS 覆盖以保留原始外观，或如果变更是有意的则更新基线
CI/CD 集成与门控：COCO 在部署流水线中充当自动化设计质量门：
- 在每个 Pull Request 合并前运行视觉比较，将结果作为 PR 评论发布
- 检测到严重视觉回归时阻止部署（可配置严重程度阈值）
- 在 PR 中提供视觉差异图库，展示每个检测到变更的前后截图
- 支持人工审批工作流：设计师可以批准被标记的变更并更新基线
- 标准比较集的运行时间不超过5分钟（50个页面 × 3个断点 = 150张截图）
趋势分析与预防：COCO 识别视觉回归中的规律，从结构上预防它们：
- 按组件、页面和团队追踪视觉回归频率，识别脆弱区域
- 识别与高回归率相关的 CSS 架构模式（深度嵌套选择器、!important 覆盖、全局样式）
- 推荐降低回归风险的 CSS 架构改进（更具体的选择器、CSS Modules、作用域样式）
- 监控趋势数据：回归率是在增加还是减少？
- 生成每周视觉质量报告，呈现回归率、修复时间和覆盖率指标

量化结果与受益角色

可量化成果

到达生产的视觉 Bug：从每发布周期22个降至零——100%的视觉回归在部署前被捕获
视觉 QA 工时：手动截图比较从每发布16小时降至45分钟 AI 标记审查
误报率：智能感知比较实现**低于3%**的误报率（vs 像素差异工具的25-40%），保持开发者信任
回归修复时间：从检测到修复的平均时间从3天（生产环境）缩短至15分钟（合并前），因为开发者在上下文新鲜时立即修复
覆盖广度：视觉回归测试覆盖了**100%**的产品页面在3个断点，vs 手动维护截图测试时的20%覆盖率

受益角色

前端工程师：确信 CSS 变更不会破坏其他页面——无惧视觉副作用地部署
产品设计师：保证他们的设计在生产中保持像素完美，消除看到自己的工作被代码变更破坏的反复沮丧
QA工程师：自动化视觉测试取代了 QA 中最繁琐的部分（手动截图比较），解放时间用于功能性和探索性测试
发布经理：清晰的质量信号——没有视觉回归意味着少了一类值得担心的发布阻塞问题

💡 实用提示词

提示词1：视觉回归测试配置

请为我们的产品生成完整的视觉回归测试配置。

产品页面：
- [页面1]：[URL路径、描述、关键组件]
- [页面2]：[URL路径、描述]
- [页面3]：[URL路径、描述]
- [继续列出所有页面]

测试断点：
- 移动端：[375px]
- 平板：[768px]
- 桌面：[1280px]
- 宽屏：[1440px]

需捕获的组件状态：
- 交互组件：[列出——如 buttons、forms、dropdowns、modals、tooltips]
- 数据状态：[列出——如 empty、loading、error、populated with typical data、populated with max data]

请生成包含以下内容的测试配置：
1. 截图矩阵：页面 × 断点 × 状态 = 所需截图总数
2. 每种数据状态的测试数据固定集（确定性，非随机）
3. 每个页面的等待条件（截图前等待什么——如图片加载完成、动画停止）
4. 排除区域：比较时需遮蔽的元素（时间戳、头像、动画元素）
5. 阈值设置：每个页面可接受的像素差异（核心页面更严格，内部工具宽松）
6. 分组：哪些测试在每次 PR 时运行 vs 每晚 vs 发布前

输出为 [Percy/Chromatic/BackstopJS——指定工具] 的配置文件（JSON/YAML）。

提示词2：视觉差异分析与分类

请分析此次回归测试运行的视觉差异并对每项进行分类。

测试运行结果：
[对每个被标记的差异，描述：]
1. 页面：[页面名称/URL]
2. 断点：[视口尺寸]
3. 差异描述：[视觉上什么改变了——如"按钮内边距增加了4px"、"卡片阴影更深"、"文字颜色从#333变为#1A1A2E"]
4. 受影响区域：[页面的组件/区块]
5. 像素差异百分比：[如 2.3%]

此 PR/发布中的最近代码变更：
- [变更1：描述代码变更——如"将按钮组件内边距从12px更新为16px"]
- [变更2：描述]
- [变更3：描述]

对每个视觉差异，请分类：
1. **有意的**：已记录的设计/代码变更的预期结果 → 更新基线
2. **回归**：非预期的副作用 → 合并前需要修复
3. **噪音**：渲染伪影、时序问题或可接受的偏移 → 加入忽略列表
4. **待调查**：无法从现有信息判断 → 需要人工审查

对于回归项，请提供：
- 最可能的导致代码变更
- 建议的修复方案（具体的 CSS/代码变更）
- 严重程度：严重（布局损坏）/ 重要（用户可见）/ 轻微（细微，低流量区域）

输出为给 PR 审查者的分类报告。

提示词3：视觉质量报告（给利益相关方）

请为此发布周期生成视觉质量报告。

发布：[版本/名称]
时段：[开始日期——结束日期]

数据：
- 运行的视觉回归测试：[数量]
- 合并前检测到的回归：[数量]
- 到达预发布的回归：[数量]
- 到达生产的回归：[数量]
- 从检测到修复的平均时间：[小时/天]
- 误报率：[百分比]

与上次发布的对比：
- 上次检测到的回归：[数量]
- 上次生产环境中的回归：[数量]

请生成包含以下内容的报告：
1. **执行摘要**：视觉质量趋势——改善、稳定还是下降？
2. **关键指标仪表板**：捕获的回归、修复时间、覆盖率
3. **最主要的回归原因**：哪类代码变更导致了最多回归？
4. **脆弱区域**：哪些页面/组件发生了最多回归？
5. **流程有效性**：视觉回归测试是否足够早地捕获问题？
6. **建议**：改善下次发布视觉质量的具体行动
7. **覆盖率更新**：当前覆盖率 vs 目标，本周期新增的测试

格式适合团队回顾演示——数据驱动、可执行、10分钟内可呈现完毕。

17. AI字体搭配顾问

在15分钟内生成专业和谐的字体搭配方案——用数据驱动的推荐取代数周的试错，将可读性评分提升28%。

痛点与解决方案

痛点：字体搭配靠直觉和运气

字体排版占网页设计的95%——它是内容触达用户的主要媒介。然而，选择能和谐共存的字体是设计过程中最主观、最耗时的决策之一。仅 Google Fonts 就提供1500多种字体家族，产生数百万种可能的搭配组合。设计学校教授一些原则（衬线配无衬线、匹配 x 字高、对比字重），但这些规则不足以应对数字产品排版的微妙现实。两种字体可能遵循每条搭配规则，却因为个性、节奏或比例上的冲突，在一起看起来仍然不对——这种感觉很真实，却难以言说。

大多数设计师采用的试错方法效率惊人地低下。设计师在找到感觉正确的搭配之前，可能测试15到30种组合——每次测试都需要在多个尺寸下渲染，检查可读性，验证面向国际受众的字符集完整性，以及评估情感基调。对于品牌焕新或新产品发布，字体探索可能耗费1到2周。而结果仍然不确定：选定的搭配在设计师的设计稿中可能看起来完美，但在真实阅读场景下表现欠佳——长篇内容、数据密集的仪表板、移动端界面或低分辨率显示器。

错误的字体选择下游成本巨大，因为它已嵌入到每个地方。如果搭配效果不佳，团队在实现后才意识到，更改字体意味着在 Figma 中更新每个文字样式，在代码库中更新每个 CSS 声明，以及更新每一件营销材料。项目中途的字体更改可能耗费数周的返工时间。这一现实意味着团队通常坚持平庸的字体选择，而非冒着破坏的风险去更改，导致产品功能上没问题，却无法传达预期的品牌个性或阅读体验。

COCO如何解决

情境字体分析：COCO 在推荐字体之前，理解项目的具体需求：
- 分析产品的内容类型（长篇阅读、数据密集的仪表板、营销网站、移动端应用），确定排版要求
- 根据品牌属性（轻松vs严肃、现代vs传统、技术vs亲切）过滤字体个性
- 评估技术要求：语言支持（拉丁文、西里尔文、CJK、阿拉伯文）、可变字体可用性、Web 性能预算
- 审视现有品牌资产，识别新搭配应补充的排版基因
- 考虑竞争格局：竞品使用什么字体，这个产品如何差异化？
算法化搭配生成：COCO 基于客观的排版属性生成搭配方案，而非仅凭审美直觉：
- 分析字体指标（x 字高比率、大写字母高度、升/降部长度、笔画对比、宽度）寻找和谐的结构匹配
- 应用成熟的搭配策略：互补对比（衬线+无衬线）、超家族匹配、历史时期对齐
- 通过比较字符宽度分布评估节奏兼容性——节奏相似的字体放在一起感觉统一
- 生成按和谐分（结构兼容性、对比平衡和个性匹配的综合指标）排名的20到30个候选搭配
- 包含设计师可能通过浏览难以发现的非常规搭配，附为何有效的说明
可读性优化：COCO 确保搭配在真实阅读场景（而非字体样本展示）中表现良好：
- 在所有预期尺寸下测试搭配（标题：24-48px，正文：14-18px，说明：11-13px，数据：12-14px）
- 基于排版研究评估阅读速度和理解度指标（最佳 x 字高比、行长、字间距）
- 检查段落密度：在预期列宽下每行容纳多少字符（最佳：45-75个字符）
- 评估用于说明、标签和数据表格的字体在小尺寸下的清晰度
- 跨操作系统验证屏幕渲染质量（Windows ClearType、macOS 抗锯齿、移动端渲染）
比例尺与层级规格：COCO 生成完整的排版比例尺，而非仅仅是字体搭配：
- 基于基础字号和阅读场景创建模块化比例尺（大三度、纯四度、增四度）
- 为每个字体分配角色：标题用哪种字体、正文用哪种、说明用哪种、UI 标签用哪种
- 指定层级中的字重使用：哪些字重创造清晰的层级而不过度使用
- 生成每个尺寸的行高值，确保一致的竖向节律
- 记录每个尺寸的字间距调整（标题通常需要更紧的间距，小号文字需要更松的间距）
性能与技术验证：COCO 验证美观的搭配同样在实际使用中可行：
- 计算所选搭配的总字体包体积（KB），含所有需要的字重和字符集
- 推荐字体子集策略，最小化下载体积（Latin-extended vs 完整字符集）
- 评估可变字体可用性（一个可变字体文件可替代多个静态字重文件）
- 测试字体加载行为：FOIT（不可见文字闪烁）或 FOUT（无样式文字闪烁）期间页面看起来如何？
- 基于内容类型生成 font-display 策略推荐（swap、optional、fallback）
演示就绪的搭配交付物：COCO 生成设计师可以直接向利益相关方展示的字体搭配提案：
- 生成呈现所有层级搭配效果的并排样本渲染描述
- 创建将搭配应用于真实内容（文章、仪表板、表单、营销页）的设计稿描述
- 记录搭配理由：这些字体为何和谐（结构和谐、个性匹配、可读性数据）
- 包含2个备选搭配作为退路，附对比分析
- 生成供实现的 CSS 和 Figma 文字样式规格

量化结果与受益角色

可量化成果

字体选择时间：从1-2周探索压缩至15分钟数据驱动推荐加备选方案
可读性提升：通过 COCO 选择的搭配比设计师凭感觉选择的方案可读性评分高28%（以应用于排版渲染的 Flesch-Kincaid 可读性指数衡量）
字体包优化：通过智能子集化和可变字体推荐，平均 Web 字体下载从280KB降至95KB（减少66%）
利益相关方审批率：首次展示的字体搭配82%获批（vs 没有数据支撑理由时的35%），减少修改轮次
上线后字体变更：上线后字体变更接近零（vs 23%的项目在实现后需要字体调整）

受益角色

产品设计师：跳过数周主观的字体浏览，展示有数据支撑的推荐方案，获批更快
品牌设计师：客观的排版分析补充创意直觉，确保搭配在功能上和美学上同样有效
前端工程师：含精确字重、子集和展示策略的性能优化字体加载规格——不再调试字体加载问题
内容策略师：针对其内容类型（长篇阅读、数据表格、营销文案）优化的字体，确保最需要的地方可读性最佳

💡 实用提示词

提示词1：字体搭配推荐

请根据我们的具体需求推荐字体搭配方案。

项目类型：[如"带营销网站的 B2B SaaS 仪表板"]
品牌个性：[如"专业但亲切、现代、可信赖"]
内容类型：
- 主要：[如"数据密集的表格和图表，占界面的60%"]
- 次要：[如"简短营销文案，20%"]
- 第三：[如"长篇帮助文档，20%"]

技术要求：
- 需要的语言：[如"英语、德语、法语、日语"]
- 字体性能预算：[如"< 100KB 总量"]
- 偏好可变字体？[是/否]
- 现有品牌字体（如有）：[名称，或"无——从零开始"]

设计感觉：
- 我们欣赏的参考产品：[列出2-3个字体搭配你喜欢的产品]
- 需要避免的风格：[如"不要太活泼，不要装饰性衬线"]

请生成：
1. **首选推荐**：标题字体 + 正文字体搭配
   - 两者和谐的原因（结构和个性分析）
   - 预期尺寸下的可读性评估
   - 所需语言的字符集覆盖
   - 推荐字重的总文件大小
   - 使用规格：哪种字体用于哪种目的

2. **备选A**：不同风格方向
3. **备选B**：经济实惠/更好性能的选项

对每个搭配，提供：字体名称、推荐字重、主要尺寸下的样本渲染。

提示词2：排版比例尺生成器

请为我们的产品生成完整的排版比例尺。

正文字体：[名称，如 "Inter"]
标题字体：[名称，如 "Fraunces" 或 "与正文相同"]
基础字号：[如 16px]
比例尺偏好：[如 "大三度 (1.250)" 或 "请推荐"]

内容场景：
- 营销页面：[描述——如"主视觉标题、副标题、正文段落、CTA"]
- 应用 UI：[描述——如"页面标题、区块标题、正文、标签、说明、数据单元"]
- 文档：[描述——如"H1-H4层级、正文段落、代码块、提示框"]

请生成完整比例尺：
1. **尺寸比例尺**：从最小（说明/标签）到最大（主视觉标题）的每一步
   - px 和 rem 的尺寸
   - 每步的字体家族和字重
   - 每步的行高（相对值，如 1.5）
   - 每步的字间距调整
   - 每步的最大行长推荐（以字符数）

2. **响应式调整**：比例尺在移动端断点的适配
   - 哪些尺寸需要缩小，缩小多少？
   - 小屏幕上是否有字重变化？

3. **竖向节律**：基础单位及文字元素间距如何保持节律

4. **文字样式定义**：供 Figma 和 CSS 使用的命名样式
   - [如 display-xl、heading-lg、heading-md、heading-sm、body-lg、body-md、body-sm、caption、label、overline]
   - 每个含：字体家族、字重、字号、行高、字间距、大小写变换（如有）

输出为规格表格和 CSS 自定义属性。

提示词3：字体无障碍审查

请审查我们的字体选择是否符合无障碍合规要求和阅读舒适度。

当前排版配置：
- 正文字体：[名称]，字号：[px]，字重：[值]，行高：[值]，颜色：[HEX] 在 [背景HEX] 上
- 标题字体：[名称]，各级尺寸：[列出]，字重：[列出]
- 说明/标签字体：[名称]，字号：[px]，字重：[值]
- 等宽字体（代码）：[名称]，字号：[px]

布局：
- 最大内容宽度：[px]
- 典型行长：[约字符数]
- 段落间距：[px 或 em]

请审查：
1. **WCAG 合规**：
   - 所有文字/背景组合的对比度
   - 正文最小字号是否 ≥ 16px？
   - 文字能否放大到200%而不丢失内容？

2. **可读性**：
   - 行长：正文是否在45-75字符以内？
   - 行高：正文是否在1.4-1.6之间？
   - 段落间距：是否足以区分段落？
   - 字间距：是否适合字体和尺寸？

3. **认知无障碍**：
   - 标题层级是否清晰？（各层级尺寸/字重对比是否足够）
   - 链接能否不仅靠颜色与正文区分？
   - 主次文字之间的对比度是否足够？

4. **阅读障碍友好性考量**：
   - 字体的字符区分度是否清晰（Il1、O0、bdpq）？
   - 字体是否过于窄或压缩，不利于舒适阅读？

输出：无障碍评分卡，附每个发现问题的具体修复建议。

18. AI设计作品集评审助手

在 10 分钟内完成专业级作品集点评 —— 帮助设计师将作品集呈现质量提升 65%，面试邀约率翻倍。

痛点与解决方案

痛点：高质量的作品集反馈稀缺、昂贵、不公平

设计作品集是设计师职业生涯中最重要的资产，但大多数人能得到的反馈却极为匮乏。传统上，要获得有价值的作品集点评，需要认识资深设计师、招聘经理或能参加作品集评审活动 —— 这些资源稀缺、分布不均，往往被地理位置和人脉圈所垄断。初级设计师和转行者最需要反馈，却最难得到。设计培训机构虽有一些评审，但毕业生普遍反映，收到的建议流于表面（"要更有故事感"），缺乏具体可执行的指导。

这件事的后果相当严重。招聘经理平均只花 3-4 分钟浏览一份作品集，就会决定是否进入下一轮。在这短短的时间里，作品集必须传递清晰信号：这位设计师能识别真实问题、提出有思考深度的解决方案、交付精良的结果，并能清晰阐述自己的设计过程。一份掩盖成果、以过程代替结论、缺乏数据支撑或叙事结构混乱的作品集，会直接被淘汰 —— 无论实际设计工作有多出色。最讽刺的是：许多有才华的设计师反而作品集平庸，因为"如何呈现设计"本身就是一项独立技能，而这在教育中几乎从未被系统教授。

自我审视往往无效，因为设计师太贴近自己的作品了。他们默认读者与自己有相同的背景认知，把还在脑子里的上下文省略掉；习惯按时间线叙述"我怎么做的"，而不是从结果倒推"为什么这很重要"。没有模拟招聘官视角的外部审视，设计师根本无法发现哪里让人困惑、哪里有遗漏、哪里在削弱叙事。这个反馈鸿沟会自我强化：有人脉的人得到更好的反馈、做出更好的作品集、找到更好的工作、进一步扩大人脉 —— 而同等才华但缺乏资源的人却原地踏步。

COCO 如何解决

第一印象分析：COCO 模拟招聘官的真实体验方式 —— 从最初的 3 分钟出发评估作品集：
- 评估首页：能否在 3 秒内让人明白"你是谁、做什么、最强的作品是哪个"
- 审查每个案例的前 30 秒：开头是否能用一个清晰的问题 + 结果吸引人继续看
- 检查信息层级：最重要的内容（成果、角色、影响力）是否在视觉上足够突出
- 识别认知负担问题：文字过多、导航不清晰、行动引导被埋没、项目选择令人费解
- 输出"3 分钟浏览路径"，还原时间有限的评审者会看到什么、形成什么印象
案例叙事结构评估：COCO 对照成熟的作品集叙事框架，逐一分析每个案例：
- 检查关键要素是否完整：问题背景、用户洞察、设计过程、关键决策、最终方案、可量化成果
- 评估比重是否失衡：是否 80% 在讲过程、只有 20% 讲结果（这是最常见的错误）
- 审查叙事弧度：是否有"提出问题 → 解决问题"的张力，还是漫无目的地展开
- 指出缺乏具体性的表述："提升了用户体验" vs. "将任务完成时间从 4 分钟缩短至 90 秒"
- 标记常见反模式：展示每一个迭代稿、堆砌无关的研究细节、把最终设计埋在最后
量化影响力评估：COCO 精准识别哪些案例缺少招聘官最看重的数据支撑：
- 标记没有可衡量成果的案例（这是作品集最普遍的硬伤）
- 根据项目类型建议合适的指标方向（转化率、任务时长、错误率、NPS、商业价值）
- 指出缺乏依据的陈述（"用户非常喜欢" —— 根据什么数据？）
- 推荐数据的视觉呈现方式，以最大化冲击力（前后对比、变化量标注）
- 协助将定性结果转化为可量化的表达
视觉呈现评审：COCO 评估作品集本身的设计质量：
- 字排版：是否易读？层级是否清晰？案例文字是否易于快速浏览？
- 版式布局：视觉结构是否引导读者视线流动，配合叙事节奏？
- 图片质量：效果图是否清晰，尺寸合适，有无放入合适的设备或场景中展示？
- 响应式表现：移动端呈现如何（超过 30% 的作品集查看来自手机）？
- 各案例之间的视觉一致性：布局风格、字体、调性是否统一？
目标岗位定向校准：COCO 根据目标职级和方向，给出有针对性的反馈：
- 评估作品集是否展示了与目标级别相符的能力（初级：工艺与过程；高级：战略与影响；Lead：团队与系统思维）
- 识别相对目标岗位常见 JD 的能力缺口（例如高级产品设计师需要展示设计系统思维）
- 建议调整项目呈现角度：同一个项目，面向不同方向可以强调完全不同的维度
- 对比不同类型公司（初创 vs. 大厂、产品 vs. 代理商）通常看重的信号
- 给出保留、删除或调整哪些项目的具体建议
可执行的修改计划：COCO 生成具体、按优先级排列的改进方案：
- 按"对求职结果的影响程度"和"所需投入"对所有反馈排序
- 提供薄弱案例段落的改写示例（不只是建议，而是直接示范改写后的效果）
- 建议结构重组方案，附推荐的案例模板
- 指出最强和最弱的各一个案例，并分别给出具体指导
- 制定 1 周修改计划，按天拆解重点，提升修改效率

量化结果与受益角色

量化结果

评审时长：全面的作品集点评在 10 分钟内完成，而等待资深设计师反馈通常需要 2-4 周
作品集质量提升：按照 COCO 建议修改后，作品集呈现评分提升 65%（由招聘经理小组评定）
面试邀约率：经过 COCO 辅助修改后，设计师报告面试邀约率 提升 2 倍（平均从 12% 涨至 26%）
修改效率：平均作品集修改周期从 3 周无方向的反复打磨，缩短至 5 天有针对性的改进
数据覆盖率：COCO 标记缺失指标并建议补充后，包含可量化成果的案例比例从 30% 提升至 90%

受益角色

求职中的设计师：无需依赖资深导师或付费咨询，即可获得专业级反馈，打破职场资源不平等
初级设计师：获得具体可执行的指导，学会如何最有力地呈现有限经验，而不是泛泛的"多加几个项目"
转行设计师：系统性框架帮助重新诠释非设计背景，提供适合转行者的作品集结构指导
招聘经理：候选人作品集质量普遍提升，意味着更少时间浪费在不匹配的面试上，更快筛选出优质候选人

💡 实用提示词

提示词 1：全面作品集评审

请对我的设计作品集进行全面评审。

作品集链接或描述：[URL 或描述各页面/版块内容]
案例数量：[X] 个
目标岗位：[例如 "B2B SaaS 公司的高级产品设计师"]
工作年限：[X 年]

各案例简介：
1. [项目名]：[1-2 句话概述，你的角色，核心成果]
2. [项目名]：[概述]
3. [项目名]：[概述]
4. [项目名]：[概述]

请从我目标类型公司的招聘经理视角进行评审，重点评估：

1. **第一印象（0-30 秒）**：招聘经理最先看到什么？是否有吸引力？
2. **导航与结构**：能否快速找到所需信息？案例选择是否清晰？
3. **每个案例的质量**：
   - 开头是否吸引人继续阅读？
   - 问题是否清晰呈现并有业务背景？
   - 过程展示的详略是否得当？
   - 关键设计决策是否突出且有理有据？
   - 成果是否用具体数据量化？
   - 叙事是否有吸引力、节奏是否合适？
4. **缺失信号**：一份高级/Lead 级别的作品集还需要哪些这份没有的东西？
5. **视觉呈现**：作品集本身设计如何？
6. **关于我/简介版块**：是否传递了正确的职业身份？

输出：各维度评分（1-10）、前 5 大亮点、前 5 大改进点，以及按优先级排列的行动计划。

提示词 2：案例叙事强化

帮我优化这个作品集案例的叙事。

当前案例结构：
- 标题：[项目名]
- 概述：[粘贴现有概述段落]
- 问题：[粘贴现有问题描述]
- 过程：[粘贴现有过程版块概要，或描述包含的内容]
- 方案：[粘贴现有方案描述]
- 结果：[粘贴现有结果版块]

我在这个项目中的角色：[描述你实际做了什么]
团队构成：[其他参与者]
项目周期：[历时多久]
可用的成果数据：[你掌握的数据或定性信息]

请帮我强化这个案例：
1. **改写开头段落**：用 2 句话吸引读者（先说成果，再给背景）
2. **打磨问题陈述**：让它更具体、有数据支撑、有感染力
3. **精简过程版块**：哪些内容可以删，哪些需要突出（关键决策和转折点）
4. **提升方案呈现**：如何诠释设计决策，而不只是堆砌截图
5. **强化结果版块**：用现有数据最大化呈现影响力，并建议可补充的指标
6. **补充缺失要素**：招聘经理需要看到而这个案例目前没有的内容

请直接输出改写后的各版块内容（不只是建议 —— 给我看改好的样子）。

提示词 3：面向目标岗位的作品集选题策略

帮我规划哪些项目该纳入作品集，以及如何针对目标岗位进行包装呈现。

目标岗位：[例如 "金融科技公司高级产品设计师，B-D 轮"]
我的背景：[简要职业概述 —— 年限、行业、公司类型]

可选项目清单：
1. [项目名]：[简述，你的角色，成果，公司/背景]
2. [项目名]：[简述]
3. [项目名]：[简述]
4. [项目名]：[简述]
5. [项目名]：[简述]
6. [项目名]：[简述]
7. [项目名]：[简述]

限制条件：[例如 "项目 3 有 NDA 不能展示"，"项目 5 是个人项目而非正式工作"]

请给出建议：
1. **项目筛选**：选哪 3-4 个，排什么顺序，理由是什么？
2. **包装角度**：每个入选项目，针对目标岗位应该强调哪个维度？
   （例如："面向金融科技：重点呈现你处理数据复杂性和合规约束的经验"）
3. **需要排除的项目**：哪些不选，原因是什么？
4. **能力覆盖度**：这套选择能否展示目标岗位所需的全部能力？如有缺口，如何弥补？
5. **差异化优势**：这份作品集相比其他同岗位候选人，亮点在哪里？
6. **补充内容**：是否需要加入"个人项目"版块、文章写作或其他材料？

输出作品集选题策略文档，包含每个项目入选理由和呈现建议。

19. AI多平台资产导出器

在 30 分钟内同步导出 7+ 平台所需的设计资产 —— 替代原本需要 2 个工作日的手动流程，并消除导致 40% 资产类 bug 的平台规格错误。

痛点与解决方案

痛点：资产导出是一份没人想做的全职工作

现代数字产品必须在不断扩展的平台矩阵中正确呈现：Web（标准与视网膜屏）、iOS（1x/2x/3x）、Android（mdpi/hdpi/xhdpi/xxhdpi/xxxhdpi）、macOS、Windows、邮件客户端、社交媒体、印刷品，以及可穿戴设备、车载屏幕等新兴平台。每个平台对文件格式、分辨率、色彩空间、命名规范和目录结构都有各自的要求。一个需要跨平台使用的图标，可能需要导出 15 个以上的变体。拥有 100 个图标、50 个插图、20 张营销图的产品，面对的导出矩阵是成千上万个独立文件。

这个过程枯燥、容易出错，而且长期处于低优先级。设计师在 Figma 里逐个配置导出设置，再手动检查每个文件是否符合规格：尺寸对不对、格式对不对、色彩描述文件对不对、命名规范对不对。一次完整的资产更新可能需要 1-3 天。这类工作的重复性极强，出错几乎不可避免：iOS 3x 图标导出成了 2x 尺寸、Android 资产放错了密度目录、Web 图片存成了 PNG 而非 WebP、SVG 嵌入了字体导致部分浏览器崩溃。这些问题要么在开发阶段作为 bug 被发现，要么直接带到了生产环境。

更深层的组织症结在于：资产导出既不属于设计工作，也不属于工程工作 —— 它是一项落在两个团队之间的运营性任务，没有人真正负责。设计师认为"设计完成"就算交付了；工程师期望拿到"随时可用"的资产。这个导出步骤是个无人买单的差事，通常由某个人在 Sprint 末尾赶时间时勉强完成。每当需要更新资产（品牌色变了、图标改版了、新增了一个平台），整套导出流程就得从头来一遍。没有自动化，大多数团队维护的资产库都是半新不旧的：有些平台用的是最新版，有些还是旧版本 —— 这种视觉不一致会悄悄侵蚀精心构建的设计系统。

COCO 如何解决

平台感知的导出配置：COCO 内置了所有主流目标平台的最新规格：
- 预配置导出方案：Web（SVG、PNG @1x/2x、WebP）、iOS（PDF 矢量图、PNG @1x/2x/3x）、Android（矢量 drawable、各密度 PNG）、macOS、Windows、邮件和社交媒体
- 自动为每个平台应用正确的色彩空间（Web 用 sRGB、iOS 支持 Display P3、印刷用 CMYK）
- 自动按平台处理命名规范（Web 用 kebab-case、iOS 用 camelCase、Android 用 snake_case）
- 生成每个平台对应的目录结构（Android 的 drawable-mdpi/、drawable-hdpi/，iOS 的 Assets.xcassets）
- 持续跟踪平台规格变更（例如 Android 新增密度档位时自动同步）
智能格式选择：COCO 为每个资产和平台选择最优文件格式：
- 分析每个资产的特性：矢量 vs. 位图、是否有透明通道、色彩复杂度、是否有动效
- Web 可缩放图标和插图优先选用 SVG（同时生成 PNG 备选，用于不支持 SVG 的邮件客户端）
- Web 照片优先选用 WebP + PNG 降级方案（同等质量下比 JPEG 小 40-50%）
- iOS 使用 PDF 矢量图，Android 使用 vector drawable XML —— 尽可能实现分辨率无关
- 根据资产类型选择有损或无损压缩（Logo 始终无损；摄影类图片有损并设定质量阈值）
自动化质量校验：COCO 在交付前验证每一个导出文件：
- 检查尺寸是否完全符合每个平台的精确规格（例如 iOS App Icon 必须精确为 1024x1024）
- 校验文件大小是否在合理范围内（移动端单图超过 100KB 时触发警告）
- 验证 SVG 是否干净：无内嵌位图、无外部字体依赖、无多余元数据
- 确认 PNG 透明通道处理正确（无白底蒙版残留）
- 对导出结果与设计源文件做视觉比对，捕捉导出过程中的损坏或渲染异常
批量处理与智能差分：COCO 只导出发生变化的资产，大幅缩短增量更新耗时：
- 对所有已导出资产维护哈希记录，精准检测哪些源文件自上次导出后有改动
- 只重新导出真正有变化的资产
- 检测设计 Token 变更（色值调整、间距变化）会影响所有资产，并触发全量重导
- 支持按类别选择性导出（仅图标、仅插图、仅营销图）
- 生成变更清单，清晰呈现本次导出中新增、更新和删除的内容
资产优化流水线：COCO 对每个平台应用针对性优化，在不损失质量的前提下最小化文件体积：
- SVG 优化：去除元数据、合并路径、简化坐标、删除隐藏元素（等效于 SVGO）
- PNG 优化：在可行处减少色彩深度、去除冗余数据块、使用最优压缩（等效于 TinyPNG）
- WebP 优化：针对每个资产调整质量参数，在目标文件大小下实现最高视觉质量
- 适当场景下生成雪碧图（Web 用 CSS Sprites，游戏用纹理图集）
- 大图使用渐进式 JPEG，实现边加载边显示低质量预览
分发与工程集成：COCO 将资产直接送达工程师需要的地方：
- 通过 Pull Request 将导出结果推送至代码仓库，附带视觉差异供评审
- 上传至 CDN 或资产管理系统，附带缓存破坏用的版本哈希
- 更新包管理器（Web 图标库的 npm 包、iOS 的 CocoaPods/SPM、Android 的 Maven）
- 生成资产清单文件，让工程师通过名称而非路径引用资产
- 维护可浏览的资产目录，支持搜索、筛选和按平台单独下载

量化结果与受益角色

量化结果

导出时长：全平台资产导出从 2 天手动工作缩短至 30 分钟内自动完成
资产类 Bug：平台规格错误（尺寸、格式、命名）从每次发布 18 个降至 不足 1 个（减少 95%）
文件体积优化：通过智能格式选择和压缩优化，资产平均体积减少 45%（每屏从 200KB 降至 110KB）
平台同步时效：设计变更后所有平台资产更新到位，从 2-3 周（分批手动更新）压缩至当天（自动同步导出）
设计师时间释放：每个 Sprint 周期原本耗费在资产导出、校验和 bug 修复上的 16 小时，重新回归设计工作

受益角色

产品设计师：告别设计流程中最枯燥的部分 —— 逐平台导出与验证资产 —— 把精力还给创意工作
iOS 工程师：收到尺寸正确、命名规范、格式合适的资产，目录结构完全符合 Xcode 预期
Android 工程师：矢量 drawable 和各密度位图已按正确命名放入对应资源目录，无需手动整理
Web 工程师：收到经过优化的 WebP/SVG/PNG（含降级方案），打包成可直接导入的资产包，附带缓存破坏文件名

💡 实用提示词

提示词 1：多平台导出配置生成

为我们的设计资产跨所有目标平台生成完整的导出配置。

待导出资产：
- 图标：[数量，例如 120 个]，源格式：[Figma 中的 SVG]，使用尺寸：[16、20、24、32px]
- 插图：[数量]，源格式：[Figma 中的矢量/位图]，典型尺寸：[描述]
- App 图标：[列出平台 —— 例如 iOS App Store、Android Play Store、macOS、网站 favicon]
- 营销图片：[数量]，尺寸：[描述常用尺寸和比例]
- Logo：[变体 —— 例如完整 logo、图标、横版、竖版]

目标平台：
- Web：[技术栈 —— 例如 React + Tailwind、静态营销站]
- iOS：[最低 iOS 版本，Swift 或 SwiftUI]
- Android：[最低 API 版本，Kotlin]
- 邮件：[需要支持的邮件客户端]
- 印刷：[是否有印刷需求 —— 名片、展会横幅等]
- 社交媒体：[平台 —— Twitter、LinkedIn、Instagram]

对每种资产类别和每个平台，请明确：
1. 文件格式（SVG、PNG、WebP、PDF、Android vector drawable 等）
2. 所需分辨率/尺寸（1x/2x/3x、密度档位等）
3. 色彩空间（sRGB、Display P3、CMYK）
4. 命名规范（附示例）
5. 目录结构
6. 文件大小/质量优化参数

输出为导出配置文档，呈现为矩阵表格：资产类型 × 平台 = 格式 + 参数设置。

提示词 2：App 图标全平台导出规格

为所有平台生成完整的 App 图标导出规格。

源图标：[描述 —— 形状、主要颜色、是否有透明通道]
品牌色值：[列出图标中使用的 HEX 值]

请为以下平台生成规格：
1. **iOS/iPadOS**：
   - 所有必需尺寸（从 20pt @1x/2x/3x 到 App Store 所需的 1024pt @1x）
   - 格式：PNG，无透明通道，无圆角（系统自动裁切）
   - 色彩空间：sRGB 还是 Display P3？

2. **Android**：
   - 自适应图标层：前景层（108dp）和背景层（108dp）
   - 传统图标尺寸：48dp，从 mdpi 到 xxxhdpi
   - Play Store 图标：512×512 PNG
   - 前景安全区（66dp 居中圆形）

3. **macOS**：
   - 所有必需尺寸（16 到 1024，@1x 和 @2x）
   - 格式和圆角规格

4. **Web**：
   - Favicon：ICO（16×16、32×32）、PNG（192×192、512×512）
   - Apple Touch Icon：180×180
   - manifest.json 图标条目
   - Open Graph / 社交分享图：1200×630

5. **Windows**：
   - 磁贴尺寸：小、中、宽、大

每项请提供：
- 精确像素尺寸
- 文件格式与压缩设置
- 背景处理方式（透明、填色、自适应）
- 命名规范
- 文件放置路径

输出为完整的核查清单，附文件规格说明。

提示词 3：SVG 优化指南

分析并优化这批 SVG 图标导出文件，使其适合 Web 使用。

我们遇到的 SVG 问题：
- [问题 1：例如 "部分图标从 Figma 导出后含有内嵌位图"]
- [问题 2：例如 "文件大小差异悬殊 —— 有些 2KB，有些 45KB"]
- [问题 3：例如 "用 CSS currentColor 改色时图标显示异常"]

当前导出流程：[描述 —— 例如 "从 Figma 直接导出 SVG，无后处理步骤"]
代码中的使用方式：[描述 —— 例如 "React 组件内联 SVG，通过 CSS 控制颜色"]

请生成 SVG 优化指南：
1. **导出设置**：Figma SVG 导出的最优参数
   - 保留/去除：ID、class 名、文字轮廓化、变换展开
   - 图层准备：如何在 Figma 中组织图层，保证 SVG 导出干净

2. **导出后优化**（SVGO 或类似工具）：
   - 需要启用的插件及其配置
   - 需要禁用的插件（哪些会破坏图标）
   - 预期体积压缩比例

3. **动态颜色处理**：
   - 如何让 SVG 支持 CSS currentColor
   - 多色图标的处理方式（哪些部分可以动态变色？）
   - fill 与 stroke 颜色继承

4. **无障碍访问**：
   - 必需的属性（role、aria-label、title）
   - 何时使用 aria-hidden（装饰性图标）

5. **常见问题与修复方案**：
   - 嵌入字体 → 转为轮廓
   - 内嵌位图 → 移除或重绘
   - viewBox 不正确 → 重新计算
   - clip-path 问题 → 简化几何图形
   - stroke-width 不统一 → 标准化处理

输出为面向设计师和开发者的 SVG 优化指南。

20. AI设计工作坊规划助手

借助结构化引导，运行聚焦且高产出的设计工作坊，让团队保持协调并持续推进。

痛点与解决方案

痛点：AI设计工作坊规划助手

设计冲刺是快速解决复杂设计问题最强大的工具之一——但它需要专业的引导、严格的时间管理和结构化的活动，而大多数设计团队很难持续执行这些。没有强力引导，冲刺就会偏离方向：周一的问题定义在周三又被重新打开，草图会议变成无效的辩论，最终原型反映的是声音最大的人而不是最好的想法。

准备工作是另一个重大挑战。一次运行良好的冲刺需要精心设计的日程、预先准备好的模板和画布、量身定制的投票和决策练习，以及在可用时间内可以完成的原型计划。从头开始为每次冲刺组装这一切需要引导者8-12小时的准备工作。许多设计团队运行的冲刺次数远少于理想情况，仅仅是因为开销过高。

冲刺文档也往往很差。冲刺期间产生的丰富思考——用户旅程地图、问题陈述、"我们如何可能"集群、故事板——被不一致地捕获在没人事后整理的照片和便利贴中。六个月后，团队无法重建他们在冲刺期间为什么做了这些决定，宝贵的洞见就此丢失。

COCO如何解决

COCO充当全面的设计冲刺引导助手，减少准备开销、指导冲刺执行，并在整个过程中生成结构化文档：

冲刺规划和准备
- 根据具体问题、团队规模和可用天数生成完整的冲刺日程
- 创建所有冲刺材料：问题陈述模板、HMW问题提示、闪电演示指南、草图模板和投票框架
- 为参与者生成涵盖问题领域和相关研究的冲刺前阅读包
- 根据问题的复杂程度确定正确的冲刺变体（完整5天、3天压缩版、1天聚焦版）
问题框架引导
- 引导团队完成结构化的问题定义活动
- 从客户研究输入生成"我们如何可能"问题集
- 引导亲和力聚类和优先级投票以缩小范围
- 在第1天结束时生成简洁、可测试的冲刺问题
构思和草图支持
- 通过从类似行业中提取相关解决方案来提供闪电演示灵感
- 生成结构化的草图提示，帮助团队克服空白页面障碍
- 以结构化批评框架引导"疯狂8"和解决方案草图评审
- 帮助团队以清晰的决策理由汇聚到单一故事板方向
原型规划
- 将原型范围限定在可用时间内可以实现而不牺牲可测试性的范围
- 生成原型构建日的分工计划
- 识别哪些屏幕或流程对测试冲刺问题至关重要，哪些可以简化
- 创建确保测试能生成可操作数据的原型脚本
用户测试准备
- 撰写与冲刺问题对齐的完整访谈指南
- 为参与者招募生成筛选标准和招募说明
- 为在后排观察的冲刺团队创建观察记录模板
- 制作从五个用户会话中高效提取模式的综合框架
冲刺文档和回顾
- 将所有冲刺产出综合成结构化的冲刺报告
- 记录解释在每个阶段为何做出关键选择的决策日志
- 识别用户测试中的关键洞见，附置信度评级
- 生成回顾议程并生成冲刺学习文档供未来参考

效果与受益者

可量化成果

冲刺准备时间减少70% 完整的材料生成消除了每次冲刺需要8-12小时引导者准备工作的情况
冲刺输出质量提升40% 结构化引导活动确保团队产生更多样化的想法，并汇聚到更好的解决方案
每季度完成的冲刺次数增加3倍 减少的准备开销使针对以前会经过更慢设计评审流程的问题运行冲刺变得切实可行
冲刺文档质量提升60% 自动化综合生成全面的冲刺报告，保留机构知识而不是将其留在未整理的照片中
达到可测试原型的时间缩短35% 更好的原型范围界定和分工使团队能够在冲刺时间线内构建和测试，而不会超出范围

谁会受益

首席设计师和设计经理：无需成为专业冲刺教练即可引导高质量冲刺，并在团队引导能力之外运行更多冲刺
产品经理：通过结构化练习更快地达成冲刺决策，防止通常会减慢设计研讨会速度的开放式辩论
跨职能冲刺参与者：通过精心准备的冲刺材料和结构化引导指导更有效地参与，而不是非结构化的自由形式讨论
设计研究团队：获得更好框架的用户测试问题和综合框架，使冲刺测试会话更富有成效和洞见

💡 实用提示词

提示词1：冲刺规划和日程生成

为以下问题创建完整的设计冲刺计划。

冲刺背景：
- 要解决的问题：[描述设计或产品问题——要具体]
- 冲刺格式：[5天/3天/1天]
- 团队构成：[列出角色——例如产品经理、2名设计师、工程师、客户成功代表]
- 决策者：[谁在冲刺中拥有最终决策权？]
- 可用设施：[线下/远程/混合，可用工具——Miro、FigJam等]
- 关键约束：[例如"原型必须在没有工程师参与的情况下可测试"]

用户背景：
- 目标用户：[描述主要用户角色]
- 已有的关键用户研究：[总结相关发现]
- 需要解决的主要用户痛点：[列出3-5个]

冲刺问题（草稿）：[您的工作冲刺问题，或"帮我定义它"]

生成：
1. 按日划分的日程，附时间盒活动和负责人
2. 冲刺问题完善（如需要）
3. 准备清单：每位参与者在冲刺开始前应做什么
4. 材料清单：所需的模板、用品和工具设置
5. 基于描述的用户痛点的HMW问题入门集

提示词2：第3天决策和故事板引导

引导我们设计冲刺的第3天决策和故事板阶段。

冲刺背景：
- 冲刺问题：[您的冲刺问题]
- 用户角色：[描述]

制作的解决方案草图（第2天产出）：
- [参与者]的草图1：[描述概念——主要想法、关键屏幕或流程]
- [参与者]的草图2：[描述]
- [参与者]的草图3：[描述]
- [参与者]的草图4：[描述]
[继续列出所有草图]

点投票结果：
- 草图1：[N票，哪些方面获得最多投票]
- 草图2：[N票，哪些方面获得最多投票]
[继续]

需要解决的冲突：
- [冲突1：例如"两个草图对核心用户操作有不兼容的方法"]
- [冲突2：例如"团队在简单方案和功能丰富方案之间分歧"]

引导：
1. 艺术博物馆审查摘要——跨草图出现了什么规律？
2. 快速批评发现——每个草图的主要优势，用2句话描述
3. 冲突解决建议——如何在竞争方法之间做出决定
4. 故事板建议——将哪个（些）草图合并成获胜概念以及如何合并
5. 故事板大纲——描述要原型化的用户旅程的8-12格故事板

提示词3：冲刺用户测试访谈指南

为以下设计冲刺原型撰写完整的用户测试访谈指南。

冲刺问题：[您的冲刺问题]
原型描述：[描述原型展示的内容——屏幕、流程、关键交互]
用户角色：[描述被测试的目标用户]
招募画像：[描述测试参与者的筛选标准]

测试目标——本次测试最重要的3件事：
1. [目标1：例如"用户是否在前2分钟内理解了核心价值主张？"]
2. [目标2]
3. [目标3]

正在测试的关键假设：
- [假设1：例如"用户无需引导即可自然导航到关键功能"]
- [假设2]

生成：
1. 开场白脚本（2-3分钟）：如何欢迎参与者并设定期望，而不对其产生偏见
2. 热身问题（5分钟）：了解参与者背景和当前行为的问题
3. 任务场景（20-25分钟）：以场景格式撰写的3-4个任务，允许自然探索而不引导
4. 复盘问题（5-10分钟）：浮现整体印象和未满足需求的问题
5. 观察员记录模板：后排团队在每个任务期间应捕获的内容

包含：引导者必须避免的可能偏向回应的话语清单。

21. AI本地化设计顾问

设计在每种语言中都感觉原生的产品——不只是翻译版本。

痛点与解决方案

痛点：AI本地化设计顾问

本地化始终是产品设计中投资最不足的领域之一，直到它演变成危机。设计团队为英语构建界面，然后太晚才发现德语字符串长出40%，阿拉伯语文本从右向左流动并打破每个布局假设，或者日本日期格式使日期选择器逻辑错误。当这些问题被发现时——通常是在工程实现期间或之后——修复它们需要本可以通过本地化感知设计从一开始就避免的返工。

这个问题远不止字符串长度和文字方向。不同文化对信息密度、颜色象征、图标和交互模式有着根本不同的期望。在一种文化中意味着"保存"或"成功"的图标在另一种文化中可能毫无意义或冒犯性。为MM/DD/YYYY设计的日期输入给每个非美国用户制造了摩擦。表单字段格式（地址格式、电话号码、邮政编码）因市场而异，但大多数设计系统将美国格式编码为默认值。

在本地化上工作的设计师也缺乏针对不同区域设置测试其设计的高效工具。手动将字符串翻译到设计文件中、以不同的文字扩展率测试布局，以及检查RTL布局行为既耗时又不一致。没有系统化方法，本地化问题会被晚发现、昂贵地修复，并在后续设计迭代中重新引入。

COCO如何解决

COCO充当本地化设计专家，帮助设计师从一开始就为全球设计，而不是将本地化作为事后的补救措施：

字符串扩展和布局压力测试
- 计算目标语言的文字扩展率（德语+35%、法语+25%等）并将其应用于设计组件
- 在字符串被翻译之前识别将在标准扩展率下出现问题的UI组件
- 为每种组件类型推荐最小列宽、灵活容器模式和截断策略
- 为设计系统生成扩展安全的组件变体
双向（RTL）布局指导
- 审计现有设计的RTL兼容性问题：未镜像图标、硬编码的左对齐布局、非逻辑CSS属性
- 为每个屏幕生成完整的RTL设计规格，包括镜像规则、例外情况和布局调整
- 区分应该镜像的元素（导航、进度指示器）和不应该镜像的元素（复选框、播放/暂停图标）
- 创建用于开发人员交接的LTR/RTL并排模型规格
文化适应建议
- 审查图标、图像和颜色使用在目标市场的文化适当性
- 标记在特定地区具有已知文化歧义或负面联想的符号
- 为标记的设计元素推荐文化适当的替代方案
- 提供市场特定的UX模式指导（例如中国vs.印度vs.德国的首选支付UI模式）
区域特定的表单设计
- 为每个目标市场的姓名、地址、电话号码和邮政编码生成区域正确的字段格式
- 根据区域标准审查设计中的日期、时间和数字格式
- 识别在UI中编码了区域特定假设的表单验证逻辑（电话号码位数、邮政编码格式）
- 推荐渐进式本地化：哪些字段在UI中本地化，哪些在后端处理
本地化就绪组件指南
- 将本地化要求写入设计系统中的组件文档
- 识别哪些组件需要区域特定变体，哪些是区域无关的
- 生成伪本地化测试字符串（在真实翻译可用之前在设计评审中使用）
- 创建设计QA的本地化测试清单
易于翻译的文案设计
- 审查UI文案中难以或昂贵翻译的模式（成语、双关语、文化特定参考、拼接字符串）
- 推荐能够干净翻译成目标语言的简明语言替代方案
- 识别需要为每个区域处理复数形式的动态字符串格式（例如"已选择5个项目"）
- 估算当前文案方法的翻译复杂度和成本影响

效果与受益者

可量化成果

实现后本地化返工减少60% 在设计阶段捕获布局和文化问题消除了字符串集成后昂贵的工程返工
本地化QA周期缩短45% 本地化就绪组件和预测试的扩展布局减少了设计、工程和本地化团队之间的反复往来
每个区域设置的设计工作量减少30% 系统化的本地化指南和可复用的区域特定模式消除了每个新市场进入的冗余设计工作
上线后高严重性文化事件为零 结构化文化审查在产品进入全球市场之前捕获符号和图像问题
国际用户满意度评分提升25% 从一开始就针对本地化设计的产品感觉像原生产品，而不是尴尬的翻译版本

谁会受益

产品设计师：在设计阶段捕获本地化问题，此时修复代价低廉，而不是在实现后代价高昂
本地化和国际化工程师：收到本地化就绪的设计规格，减少处理多区域渲染所需的工程工作
产品经理：更快进入新国际市场，因为设计基础从第一次迭代就处理了全球要求
全球营销团队：收到尊重文化细微差别的产品设计，而不是需要事后市场特定重新设计的设计

💡 实用提示词

提示词1：字符串扩展布局审计

审计以下UI组件在目标区域设置下的字符串扩展失败情况。

目标区域设置：[列出——例如 de-DE、fr-FR、ja-JP、ar-SA、ko-KR]
基础语言：[en-US或其他]

需要审计的组件（描述每个）：
- 组件1：[名称，例如"导航菜单"] — 当前布局：[描述宽度约束、字体大小、行高]
- 组件2：[名称，例如"主要按钮"] — 当前布局：[描述]
- 组件3：[名称，例如"数据表头"] — 当前布局：[描述]
[继续列出所有组件]

当前UI字符串（提供每个组件的EN字符串）：
- [组件1字符串]：[列出]
- [组件2字符串]：[列出]
[继续]

对每个组件和区域设置：
1. 应用扩展率后的估计扩展字符串长度
2. 组件是否会出现问题？（溢出、截断、换行、布局偏移）
3. 具体失败场景描述
4. 推荐修复：灵活容器、多行支持、缩写变体、仅图标备选
5. 优先级（关键/高/中），基于可见度和使用频率

输出为带有组件×区域设置分解的表格审计报告。

提示词2：RTL布局设计规格

为以下屏幕创建RTL布局规格。

需要转换为RTL的屏幕：
- 屏幕1：[名称——例如"主导航侧边栏"] — 描述布局和关键元素
- 屏幕2：[名称——例如"带多步骤进度指示器的表单"] — 描述
- 屏幕3：[名称——例如"带图表的数据仪表盘"] — 描述
[继续]

目标RTL区域设置：[例如 ar-SA、he-IL、fa-IR]

对每个屏幕输出：
1. 镜像规则：哪些元素应该镜像（左右互换），哪些不应该
   - 镜像：导航方向、进度流、文本对齐、图标方向性
   - 不镜像：标志、数学运算符、复选框、圆形进度、媒体控件
2. 字体排版变化：每个RTL区域设置的字体堆栈、阿拉伯文字的行高调整
3. 布局调整：所需的具体间距、对齐和容器变化
4. 图标清单：列出每个图标并指定是否需要镜像变体
5. CSS/设计令牌变化：具体的逻辑属性建议（margin-inline-start vs. margin-left）

输出为带有注释组件说明的开发者就绪RTL设计规格。

提示词3：文化设计审查

对我们产品计划进入[目标市场]的设计进行文化审查。

目标市场：[列出国家及其主要区域设置]
产品类型：[描述——例如 B2B SaaS仪表盘、消费者移动应用、电商平台]

需要审查的设计元素：
1. 颜色使用：[描述当前调色板及其主要用途——主要CTA颜色、错误状态、成功状态、背景]
2. 图标：[描述或列出产品中使用的关键图标——导航图标、状态图标、操作图标]
3. 图像和插图：[描述描绘的人物、物品或场景的风格和内容]
4. 手势和交互：[如果是移动端，列出关键手势——滑动模式、长按等]
5. 术语：[列出任何有文化负载的术语——例如"免费试用"、货币符号、节假日]

对每个元素，针对每个目标市场：
1. 文化兼容性评估（兼容/注意/有问题）
2. 如果标记（注意或有问题），具体关注点
3. 推荐的替代方案或适配
4. 严重程度（表面性vs.冒犯性vs.法律问题）

还提供：
- 上线前需要做的前3项最高优先级文化适配
- 我们应该采用的任何市场特定UX惯例（例如中国的微信式导航、当地支付UI规范）

22. AI交互模式库构建助手

构建整个团队实际使用的有活力、一致的交互模式库。

痛点与解决方案

痛点：AI交互模式库构建助手

大多数组织的设计系统在视觉组件方面做得不错——按钮、字体排印、颜色、表单元素——但在交互模式方面却不足。当数据部分时加载状态应如何表现？当过滤器返回无结果时vs.用户还没有数据时，正确的空状态模式是什么？内联编辑应如何确认或丢弃更改？这些行为问题在整个产品中得到的答案不一致，因为没有权威的模式库，每个设计师都根据自己的判断做决定。

结果是一个视觉上一致但行为上不一致的产品。用户在产品的不同部分遇到不同的类似操作反馈模式、不同的错误消息样式、不同的撤销操作方式，以及不同的加载指示器。这种行为不一致会降低用户信心并增加支持量，但在专注于视觉保真度的组件级设计评审中却是不可见的。

记录交互模式需要不同于记录视觉组件的技能集。交互本质上是时间性和条件性的——它们需要跨多个状态、多个边界情况和多个设备上下文指定行为。编写这份文档很费力，随着产品的演进保持其更新更难。大多数设计团队发现交互文档开始时质量不错，但在几个月内就变得过时。

COCO如何解决

COCO通过提供结构化的模式文档、识别空白，并生成团队发现最难编写的规格内容，帮助设计团队构建全面、可维护的交互模式库：

交互审计和清单
- 通过分析组件库、设计文件和产品描述，对整个产品中的所有现有交互模式进行分类
- 识别相同交互类型在产品不同部分以不同方式处理的地方
- 按类型对模式进行分类：反馈模式、导航模式、数据录入模式、错误恢复模式、空状态模式
- 生成模式不一致的热力图，优先考虑哪些区域首先需要标准化
模式文档生成
- 生成覆盖所有必需规格维度的结构化模式文档
- 跨完整状态机指定行为：默认、悬停、聚焦、激活、禁用、加载、成功、错误、空
- 记录每个交互的时间、动画曲线和过渡持续时间
- 为条件行为创建决策树（"如果用户离线"，"如果数据加载超过3秒"）
边界情况规格
- 系统化识别设计师通常忽略的每个交互模式的边界情况
- 指定网络故障状态、部分数据可用性、权限边界情况和并发用户操作的行为
- 记录异步操作的竞态条件处理（如果用户在第一个操作完成之前触发第二个操作会怎样？）
- 与正面规格并排创建负面案例库——不应该发生什么
跨平台适配指南
- 针对Web、iOS和Android平台惯例调整每个交互模式
- 识别哪些模式应该是平台特定的，哪些可以跨平台统一
- 记录每个平台所需的具体实施差异
- 生成平台适当的动画规格（Material Motion vs. iOS人机界面指南）
模式决策理由文档
- 捕获每个模式决策背后的设计理由，防止"我们为什么这样做？"的问题
- 将模式与激发它们的可用性原则和研究相联系
- 记录被考虑但被拒绝的替代方案及其理由
- 创建追踪模式随时间如何演变以及为什么演变的更新日志
模式治理和贡献流程
- 设计提议、审查和批准新交互模式的工作流
- 创建评估提议的模式是否应添加到库中的评估标准
- 建立废弃过时模式的流程，不破坏现有实施
- 生成显示产品整体采用率和一致性的模式健康仪表盘

效果与受益者

可量化成果

交互设计决策时间减少50% 设计师查阅模式库而不是从头解决已解决的问题，大幅减少每个功能的设计时间
设计评审轮次减少35% 一致的交互模式意味着对以前在评审前未被注意到的行为不一致的修改请求减少
交互相关缺陷减少40% 全面的边界情况规格防止工程师用不一致的实施填补"未定义行为"空白
测量的可用性评分提升30% 跨产品的行为一致性减少用户困惑并提高任务完成率
模式文档工作量减少60% AI生成的规格内容将记录每个新模式所需的时间从数小时减少到数分钟

谁会受益

产品设计师：使用全面的模式库进行更快的工作，将创意精力花在新颖问题上而不是重新解决已建立的模式
前端工程师：收到精确、完整的交互规格，消除实施过程中设计师和工程师之间的歧义和反复往来
设计系统维护者：保持交互文档的准确性和最新状态，而不需要让文档在创建后几个月内就变得过时的手动工作
QA工程师：根据包含边界情况的完整规格测试交互，而不是在测试执行期间对预期行为做出判断

💡 实用提示词

提示词1：交互模式文档模板

为以下UI模式生成完整的交互模式文档。

模式：[模式名称——例如"内联编辑"、"乐观UI更新"、"带错误恢复的无限滚动"]
模式类别：[反馈/导航/数据录入/错误恢复/空状态/选择/等]
产品背景：[描述此模式在您产品中出现的位置]

模式触发器：[什么用户操作或系统事件启动此模式？]
模式目标：[用户试图完成什么？]
成功标准：[用户如何知道交互成功了？]

对于此模式，记录：
1. 完整状态机：
   - 默认/静止状态：[描述外观和行为]
   - 悬停状态：[描述]
   - 聚焦/激活状态：[描述]
   - 进行中/加载状态：[描述——时间、指示器类型]
   - 成功状态：[描述——确认、时间、过渡回默认]
   - 错误状态：[描述——消息、恢复选项]
   - 禁用状态：[描述——何时以及如何]
   - 空/无值状态：[如适用则描述]

2. 时间和动画规格：
   - 每个状态变化的过渡持续时间
   - 缓动曲线
   - 任何顺序或分阶段动画

3. 需要规格的边界情况：
   - 如果操作超过3秒会怎样？
   - 如果操作过程中网络连接断开会怎样？
   - 如果用户在操作完成前离开会怎样？
   - 如果同一操作被快速触发两次会怎样？

4. 无障碍要求：
   - 状态过渡期间的焦点管理
   - 每个状态的ARIA属性和实时区域公告
   - 键盘交互规格

5. 正反案例：2-3个正确实施和2-3个常见错误需要避免

输出为适合设计系统的完整模式规格文档。

提示词2：空状态模式审计和标准化

审计我们的空状态模式，并创建标准化的空状态系统。

当前空状态清单：
描述您的产品目前如何处理以下每种空状态场景：
- 新用户还没有数据：[描述当前处理方式]
- 搜索或过滤无结果：[描述当前处理方式]
- 错误阻止了数据加载：[描述当前处理方式]
- 用户有数据但当前视图/过滤器没有匹配项：[描述当前处理方式]
- 用户尚未激活的功能：[描述当前处理方式]
- 用户删除或归档的内容：[描述当前处理方式]

观察到的不一致性：
[描述您注意到的任何不一致——不同的视觉样式、不同的文案语气、不同的CTA方式]

产品背景：
- 产品类型：[B2B SaaS / 消费者应用 / 等]
- 主要情感背景：[专业/活泼/中性]
- 插图风格：[您是否使用插图？描述风格]

设计标准化的空状态系统：
1. 空状态分类：对每种场景类型进行分类，并定义每种类型的适用时机
2. 组件结构：每个空状态必须包含的元素（图标/插图、标题、正文、CTA）
3. 每种空状态类型的视觉层次规格
4. 按场景类型的文案语气指南（错误语气vs.入职语气vs.过滤无结果语气）
5. CTA策略：何时显示一个CTA、两个CTA或不显示CTA——以及每种类型适合什么操作
6. 插图/图标指南：何时使用每种资产类型以及它们应该传达什么

输出为每种空状态类型附示例模板的设计系统规格。

提示词3：加载状态模式规格

为我们的产品创建全面的加载状态模式规格。

产品背景：
- 产品类型：[描述——例如数据密集型分析仪表盘、电商产品目录、SaaS基于表单的工作流]
- 典型数据加载时间：[快速<500ms/中等500ms-2s/慢速2s+——描述哪些场景属于哪个类别]
- 主要用户任务：[列出加载状态出现的3-5个最重要用户任务]

当前加载状态方法：[描述您目前做什么——加载图标、骨架屏、渐进式加载、乐观UI，还是不一致的混合]

对于以下每种加载场景，指定适当的模式：
1. 初始页面/视图加载（全屏）
2. 部分内容刷新（页面的一个部分更新）
3. 操作反馈（用户点击触发后端操作的按钮）
4. 无限滚动/分页加载
5. 后台同步（无用户操作的数据更新）
6. 慢速加载（>3秒——何时显示进度指示器vs.只是等待？）

对每个场景指定：
1. 模式建议：骨架屏/加载图标/进度条/乐观更新/闪光效果/无
2. 时间阈值：在什么持续时间下每种加载状态出现？
3. 内容优先级：如果部分数据加载，什么应该首先显示？
4. 动画规格：加载动画的样式、速度和类型
5. 取消行为：用户可以取消吗？如何取消？
6. 错误过渡：如果加载失败，加载状态如何过渡到错误状态？

还指定：加载状态在移动端应如何不同表现（数据连接更慢、屏幕更小）。

23. AI设计系统文档生成器

根据设计系统 Token 和组件规范生成全面的组件文档、使用指南和可做/不可做示例——让文档与设计系统保持同步。

痛点与 COCO 解决方案

痛点：设计系统文档总是过时且缺乏维护

设计系统创造组织效能——当组件文档完善时，团队构建速度更快、更一致。但文档往往是设计系统维护中最被忽视的部分。随着组件演进，文档滞后。数月前编写的使用指南不反映当前最佳实践。拥有 50+ 个组件的设计系统需要数百小时的文档工作，而每次组件更新时都必须重复部分工作。

COCO 的解决方案

组件文档生成：COCO 根据设计 Token 规范、属性定义和视觉示例为每个组件生成结构化文档。
使用指南撰写：COCO 根据组件用途和设计系统模式，编写清晰的"适用"和"不适用"场景说明。
无障碍文档：COCO 记录每个组件的 WCAG 合规细节、键盘导航模式和屏幕阅读器行为。
代码示例生成：COCO 在主要实现框架中生成展示常见用例的代码示例。
变更日志起草：提供规范变更后，COCO 生成组件变更日志条目，维护一致的文档历史。

预期成果与影响

文档覆盖率：团队在一个季度内从 30–40% 的组件覆盖率 提升至 90%+
文档时间：借助 AI 生成的初稿，单个组件文档时间从 3–5 小时降至 45–90 分钟
文档新鲜度：AI 辅助更新确保 95%+ 的组件变更都有更新的变更日志和使用说明
开发者采用率：完善文档的设计系统显示工程团队的组件采用率 提高 40%
设计评审减少：清晰的使用指南减少开发中组件误用，将设计评审周期削减 25–35%

推荐提示词

提示词 1：组件文档页面生成器

请为以下设计系统组件生成完整的文档页面。

组件名称：[例如按钮、弹窗、数据表格、表单字段]
组件用途：[描述该组件的作用及主要用例]
可用变体：[列出变体和尺寸]
状态：[列出状态——默认、悬停、激活、禁用、加载中、焦点]
属性/配置选项：[列出主要属性、类型和描述]
使用的设计 Token：[列出相关 Token]

生成包含以下内容的文档页面：
1. 概述（1–2 句描述组件及其主要用途）
2. 适用场景/不适用场景（各 3–4 条）
3. 变体指南（每个变体的描述和用例）
4. 无障碍注意事项（WCAG 合规、键盘导航、ARIA 属性）
5. 使用示例（2–3 个展示正确用法的标注示例）
6. 常见错误（2–3 个可做/不可做对比）
7. 相关组件（常与该组件搭配使用的组件）

提示词 2：UX 研究综合报告生成器

请综合以下用户研究访谈数据并生成发现报告。

研究名称：[名称]
研究问题：[列出 2–4 个主要研究问题]
参与者人数：[N 人]
访谈形式：[主持/非主持，面对面/远程，时长]

访谈数据：[粘贴访谈记录、观察记录或按参与者整理的关键引用]

生成研究综合报告，包含：
1. 高管摘要（3–5 条要点，回答主要研究问题）
2. 关键主题（5–7 个主题，含频次统计、支持引用和严重程度）
3. 参与者心理模型摘要
4. 关键痛点（按优先级排列，附代表性引用）
5. 积极信号（哪些方面做得好）
6. 设计建议（每个主要发现的可行建议）
7. 后续研究问题（研究揭示的需进一步调查的空白）

24. AI 用户体验研究综合引擎

处理用户研究访谈记录、可用性测试录像和问卷回复，提炼主题、优先排序发现，并生成研究报告。

痛点与 COCO 解决方案

痛点：用户研究洞察堆积在电子表格和访谈记录中，无人处理

用户体验研究能产生宝贵的洞察——但从原始数据收集到可行发现之间的综合过程，是决定研究能否影响产品决策的瓶颈所在。对一项标准可用性研究（5–8 名参与者，60 分钟访谈）进行手动亲和力映射和主题分析，需要 12–20 小时的分析工作。大多数设计团队负担不起这样的产出效率，因此研究频率低于产品路线图的需求，或跳过综合环节，以直觉解读原始观察代替。

COCO 的解决方案

访谈记录分析：COCO 处理访谈记录，按参与者提取观察结论、引用语句和行为规律。
主题综合：COCO 将跨参与者的观察归类成主题，识别每个规律的出现频率和严重程度。
可用性严重程度评分：COCO 根据出现频率和对任务完成的影响，对每项发现按严重程度（严重/高/中/低）进行评级。
洞察报告生成：COCO 生成结构化研究报告，包含高管摘要、优先级排序的发现、代表性引用和设计建议。
用户画像与旅程地图输入：COCO 从研究数据中提取适合用户画像和旅程地图开发的心智模型、动机和痛点。

预期成果与影响

研究综合时间：5 名参与者研究的完整主题分析从 12–20 小时降至 3–5 小时
发现覆盖率：AI 辅助综合比人工快速综合多发现 35% 的观察结论，这些内容往往在手动处理中被过滤掉
洞察报告交付时间：报告在研究完成后 1–2 天内 交付给利益相关者，而手动综合需要 1–2 周
研究对产品决策的影响力：综合速度更快的团队研究成果影响产品决策的比例 提高 50%
利益相关者参与度：清晰、优先排序的报告使非 UX 利益相关者对研究的参与度 提高 40%

推荐提示词

提示词 1：用户访谈综合报告生成器

请综合以下用户研究访谈数据并生成发现报告。

研究名称：[名称]
研究问题：[列出 2–4 个主要研究问题]
参与者人数：[N 人]
访谈形式：[主持/非主持，面对面/远程，时长]

访谈数据：
[粘贴访谈记录、观察记录或按参与者整理的关键引用]

生成研究综合报告，包含：
1. 高管摘要（3–5 条要点，回答主要研究问题）
2. 关键主题（5–7 个主题，含频次统计、支持引用和严重程度）
3. 参与者心理模型摘要
4. 关键痛点（按优先级排列，附代表性引用）
5. 积极信号（哪些方面做得好）
6. 设计建议（每个主要发现的可行建议）
7. 后续研究问题

提示词 2：可用性测试发现优先级排序

请分析以下可用性测试观察记录，并为设计团队对发现进行优先级排序。

测试的产品/功能：[描述]
测试任务：[列出参与者被要求完成的任务]
参与者人数：[N]
各任务完成率：[列出]

按任务整理的观察记录：
[粘贴每个任务和参与者的原始观察、错误记录和出声思维记录]

生成：
1. 优先级发现表：发现描述、频次（N 名参与者中的数量）、严重程度、受影响任务
2. 需立即解决的关键路径问题（上线前必须修复）
3. 前 3 个可用性问题的根本原因分析
4. 快速改进项：低投入高影响的设计变更
5. 针对每个严重和高严重程度发现的建议设计变更

提示词 3：问卷回复主题提取器

请从以下问卷回复中提取主题并生成量化摘要。

问卷目的：[描述问卷的测量目标]
分析的问题：[待分析的具体开放文本问题]
回复数量：[N 条回复]

原始回复：
[粘贴开放文本回复——至少具有代表性的 20–30 条样本]

分析：
1. 前 5–7 个主题，含频次统计
2. 每个主题的情感分布（正面/中性/负面）
3. 每个主题的代表性引用（1–2 条原文引用）
4. 意外发现
5. 可行洞察：前几个主题所暗示的决策方向
6. 交叉分析建议：哪些人口统计变量可能解释主题差异

25. AI 设计评审反馈综合器

汇总来自多位评审者的设计反馈，识别相互矛盾的意见，提炼可执行的修改建议——减少设计评审的混乱，加快迭代速度。

痛点与 COCO 解决方案

痛点：设计评审反馈混乱、矛盾，难以转化为有效行动

设计评审是产品开发流程中不可或缺的环节，但往往也是混乱的根源。不同评审者提供相互矛盾的反馈、偏好化的主观意见与客观的可用性问题混杂在一起，而真正重要的关键洞见又常常被淹没在大量评论中。设计师在评审会议结束后，往往更加困惑而非获得清晰的方向。

管理来自不同渠道的设计反馈本身就是一项工程——Figma 评论、会议笔记、Slack 消息、邮件线程。在没有组织框架的情况下，设计师要么花费大量时间整理反馈（而非推进设计），要么忽略某些反馈（在后期才发现代价）。

COCO 如何解决

多源反馈汇总：COCO 从各渠道汇总设计反馈，统一整理为可操作的列表。
矛盾识别：COCO 标记评审者之间相互矛盾的反馈，并分析潜在的根本不一致。
优先级分层：COCO 根据对用户目标和设计原则的影响，将反馈分为必须解决/应该解决/可以解决三类。
可执行修改建议：COCO 将抽象的主观意见转化为具体的设计问题和待考虑的解决方案。
反馈回应草稿：COCO 帮助起草对评审者的回应，清晰说明每条反馈的处理决策及理由。

成果与受益者

评审后整理时间：AI 辅助的反馈综合将评审后整理时间从 2-4 小时缩短至 30-60 分钟
迭代速度：清晰的优先级减少设计师在评审会后的困惑，加快迭代 25-35%
评审者满意度：有据可查的反馈处理回应增强评审者对其意见被重视的信心
设计质量：系统化的反馈处理减少关键问题在评审流程中被遗漏的概率 40-50%
利益相关者协调：对矛盾意见的透明处理减少了设计方向上的后期分歧

实用提示词

提示词 1：设计评审反馈综合报告

汇总并综合以下设计评审反馈。

设计对象：[描述接受评审的设计——屏幕/流程/组件/品牌物料]
设计阶段：[线框图/视觉稿/高保真原型/已实现界面]
设计目标：[描述这个设计旨在实现什么]

来自各评审者的反馈：
评审者 1（[角色]）：
[粘贴或描述反馈]

评审者 2（[角色]）：
[粘贴或描述反馈]

评审者 3（[角色]）：
[粘贴或描述反馈]

综合内容：
1. 按主题聚类的所有反馈要点（减少重复）
2. 评审者之间的矛盾之处，附分析（为何存在矛盾？是偏好差异还是真正的设计问题？）
3. 按影响分类的优先级：必须解决/应该解决/可以解决
4. 每个必须解决问题的可操作设计方向
5. 需要在下一次评审中请求澄清的问题

提示词 2：设计方向决策框架

帮我在收到矛盾的设计反馈后做出有原则的设计决策。

设计问题：[描述你面临的具体设计决策]
矛盾的反馈：
- 反馈 A（来自[角色]）：[描述]
- 反馈 B（来自[角色]）：[描述]

用户目标：[描述这个设计需要为用户实现什么]
业务目标：[描述业务驱动因素]
设计原则（如有）：[描述相关的设计系统或产品原则]

帮我：
1. 分析每条反馈的底层关切（被表达的观点背后，真正担忧的是什么？）
2. 对照用户目标和设计原则评估每个立场
3. 识别两种反馈都正确或都错误的可能性
4. 建议有原则的决策方向，附带理由
5. 起草面向双方评审者的回应，解释最终决策并展示其意见如何被纳入考量

提示词 3：反馈回应与设计决策文档

为以下设计评审周期创建反馈回应文档。

设计项目：[描述]
评审轮次：[第 N 轮]
收到的主要反馈：[列出主要反馈点]

针对每条反馈的决策：
[描述你决定如何处理每条反馈——接受/修改/拒绝及理由]

创建正式的反馈回应文档，包含：
1. 评审摘要（感谢参与，说明收到了哪些类型的反馈）
2. 反馈处理矩阵（每条反馈 → 决策 → 理由）
3. 下一版本的设计变更说明
4. 需要进一步对齐的未解决问题
5. 下一步计划和下一轮评审的时间安排

语气：专业且协作，清晰展示每条反馈都被认真考虑

设计师 ​

1. AI 品牌资产一致性审计员 ​

2. AI 设计系统组件审计员 ​

3. AI 响应式设计QA引擎 ​

4. AI 设计稿-代码还原度验证器 ​

5. AI界面模式库策展人 ​

6. AI色彩无障碍优化器 ​

7. AI设计冲刺促进器 ​

8. AI用户流程线框图生成器 ​

9. AI设计交付文档构建器 ​

10. AI图标集一致性检查器 ​

11. AI设计评审与反馈综合器 ​

12. AI Figma组件使用分析器 ​

13. AI深色模式设计转换器 ​

14. AI微交互原型生成器 ​

15. AI设计令牌管理器 ​

16. AI视觉回归测试引擎 ​

17. AI字体搭配顾问 ​

18. AI设计作品集评审助手 ​

19. AI多平台资产导出器 ​

20. AI设计工作坊规划助手 ​

21. AI本地化设计顾问 ​

22. AI交互模式库构建助手 ​

23. AI设计系统文档生成器 ​

24. AI 用户体验研究综合引擎 ​

25. AI 设计评审反馈综合器 ​

设计师

1. AI 品牌资产一致性审计员

2. AI 设计系统组件审计员

3. AI 响应式设计QA引擎

4. AI 设计稿-代码还原度验证器

5. AI界面模式库策展人

6. AI色彩无障碍优化器

7. AI设计冲刺促进器

8. AI用户流程线框图生成器

9. AI设计交付文档构建器

10. AI图标集一致性检查器

11. AI设计评审与反馈综合器

12. AI Figma组件使用分析器

13. AI深色模式设计转换器

14. AI微交互原型生成器

15. AI设计令牌管理器

16. AI视觉回归测试引擎

17. AI字体搭配顾问

18. AI设计作品集评审助手

19. AI多平台资产导出器

20. AI设计工作坊规划助手

21. AI本地化设计顾问

22. AI交互模式库构建助手

23. AI设计系统文档生成器

24. AI 用户体验研究综合引擎

25. AI 设计评审反馈综合器