设计师技能专题：用 Product Design、Impeccable 和 Better Icons 完成一次界面审计与交付

很多设计师把 AI 当成“帮我画几个界面”的工具，最后得到的是一堆看似好看、却无法交付的图：没有问题证据、没有状态说明、没有图标来源，更没有开发验收条件。

更实用的用法，是把 AI 当作一位受约束的设计协作者：先理解现有页面，再提出可比较的方向，然后按设计系统检查实现，最后把图标、状态和验收条件交给开发。本文不教你凭空生成 UI，而是带你完成一项真实且可复用的设计任务：把一个已有页面整理成一份可执行的界面优化交付包。

你最终会得到四样东西：

• 一份基于截图、页面地址或现有设计稿的界面审计记录；
• 三个有边界的方案方向，而不是一堆随机图；
• 一张图标“保留 / 替换 / 新增”映射表，带来源与许可检查点；
• 一份开发和 AI Agent 都能执行的修改说明、验收清单与停止条件。

本文服务 UI/UX、交互、视觉和产品设计师。你可以在 Windows、macOS 或 Linux 上的 Codex/同类 Agent 环境中使用；具体技能是否可用，以你当前会话显示的 SKILL.md 为准。

示例中的页面名称、路径和数字只是任务模板，不是已执行的项目结果。请替换成你自己的公开页面、已获授权的截图或脱敏设计稿；不要把示例提示词当成对任何网站的自动改版授权。

设计师最常用的四项能力，不是四个“画图按钮”

技能获取与安装

点击链接可进入官方源码或插件获取页。不要为了跑通示例擅自全局安装、执行 npx 下载或批量把外部 SVG 写入项目。

它们的顺序很重要：先判断问题，再探索方向，再审实现，最后确定图标资产。 如果一开始就搜索图标或生成界面，往往会把一个流程问题包装成视觉问题。

本次任务：把“结算页太乱”变成可交付的设计任务

先不要把任务写成“把结算页做高级一点”。使用下面这份输入卡。它既适用于电商结算、SaaS 设置页、后台表单，也适用于 App 的关键任务页。

页面：/checkout（替换为你的 URL、Figma frame 或截图文件）
目标用户：首次下单的移动端用户
用户任务：确认商品、选择地址和支付方式、提交订单
业务目标：提高完成订单的比例；不增加营销干扰
已有材料：当前桌面和移动端截图、设计系统链接、现有图标清单
硬约束：保留订单金额、地址、支付、提交四类信息；不改品牌色；不增加新依赖
交付范围：问题清单、一个被选中的方案说明、图标映射、开发验收清单
不在范围：直接上线、修改后端支付逻辑、虚构用户测试结果

验收方法： 让项目负责人确认“目标用户、关键任务、不能动的约束和不在范围”四项。缺少任何一项时，不进入生成方案。

第一步：用 Product Design Audit 把截图变成证据

product-design:audit 适合审查现有产品流程。它要求先取得当次真实截图，再把发现绑定到具体步骤或截图；它不是“看一眼后给审美点评”。

你要准备什么

• 至少一张目标状态的真实截图；涉及流程时，每一步一张；
• 访问路径，例如“首页 → 商品详情 → 结算”；
• 你已确认的设计系统或品牌约束；
• 一个明确用户任务，例如“完成支付”，而不是“提升体验”。

可复制提示词

请使用 product-design:audit 审计以下产品任务，不要修改代码或重画页面。

目标用户：首次下单的移动端用户。
任务路径：商品详情 → 结算页 → 提交订单。
证据：我提供的当前截图/URL；只使用本轮实际取得的截图作为证据。
硬约束：保留订单金额、地址、支付、提交订单四类信息；不新增营销模块。

请按每个步骤输出：
1. 用户此刻要完成什么；
2. 截图中可确认的优点；
3. P0/P1/P2 问题（位置、影响、依据）；
4. 可从截图观察到的无障碍风险；
5. 不能从截图判断、必须另测的项目；
6. 最小修改建议和验收方法。

禁止：凭空补造页面、把视觉偏好写成 P1、宣称完整无障碍合规、修改任何文件。

你应该拿到什么

好的输出会说清楚“地址入口在提交按钮之后，用户可能先点提交才发现缺信息”，而不是“布局不够合理”。每个问题都应同时具备：位置、影响、证据、建议和验收方法。

验收与停止条件

• 每个关键步骤有截图或明确的证据缺口；
• P0/P1/P2 数量有理由，不把所有问题都标高优先级；
• 可访问性部分明确“截图可见风险”和“待测项目”；
• 若没有真实截图、无法访问页面，停止审计并要求补材料，不用 AI 生成假截图代替。

第二步：用 Product Design Ideate 探索方向，但不把它当交付

当审计已经指出核心问题，才使用 product-design:ideate。它的用途是给你三种真正不同的信息层级、布局或交互模型，并在生成后等待人来选择；它不应该直接替你定稿，更不能生成带伪文字的“产品截图”冒充已实现页面。

先把 brief 写完整

要探索的对象：移动端结算页的信息层级。
已证实问题：地址和支付选择在长页面中不够突出；提交前缺少总价确认。
必须保留：地址、商品摘要、支付方式、总价、提交订单。
设计系统：沿用现有字体、颜色、圆角、按钮和图标规范。
方向差异要求：三个方向必须在信息层级或交互模型上不同，不能只换配色。
禁区：不新增优惠弹窗、倒计时、会员售卖或虚构评价。

可复制提示词

请使用 product-design:ideate 为以下 brief 生成三个独立方向。

[粘贴上面的完整 brief]

每个方向先用文字说明：
- 用户从上到下先看到什么；
- 地址/支付/总价如何被确认；
- 为什么它解决已证实问题；
- 哪些现有设计 token 必须保留；
- 它的风险和不适用场景。

如需生成视觉参考：只把它作为“方向草图”，不要写入真实品牌文案、订单号、价格或成功状态；等待我选择方向后，再进入交付说明。

选择时问三个问题

1. 它是否缩短了关键任务，而不是仅仅更炫？
2. 它是否保留了已有设计系统，而不是换了一个品牌？
3. 开发是否能从说明判断默认、选中、禁用、错误和加载状态？

只有其中一个方向被选择后，才写高保真设计稿或开发说明。没有选择，就不要把三张探索图拼成“最终方案”。

第三步：用 Impeccable 把视觉要求落到实现质量

impeccable 不是单一检查器，而是一组面向 UI 的命令。它覆盖 audit、adapt、typeset、layout、clarify、harden、polish 等方向。真实使用前，它会要求读取当前项目上下文、设计系统和产品 register；如果环境提示缺少 PRODUCT.md，应先停下来解释缺口，不能偷偷创建长期规则文件或假装上下文完整。

最常见的设计师用法是先做实现审计，再把具体问题交给开发处理。

可复制提示词：实现前质量审计

请在当前项目中使用 impeccable audit <目标页面或组件>。

先读取当前设计系统、token 和目标组件；不要重做品牌。
请检查五个维度：
- 可访问性：语义、标签、焦点、键盘路径、图片替代文本、颜色对比；
- 响应式：360px/390px/768px/桌面宽度、横向溢出、触控面积、文字放大；
- 主题：是否遵循 token、浅色和暗色状态是否可读；
- 性能：图片、动画、布局抖动和不必要渲染；
- UI 反模式：嵌套卡片、泛滥阴影、渐变文字、无意义动效和不一致控件。

输出 P0-P3 问题表：位置、影响、证据、建议、推荐的 impeccable 后续命令。
不要修改文件；没有证据的项写“待验证”。

设计师真正要看什么

• 不是分数，而是证据。 例如“按钮只有 38px 高且是主要触控操作”比“响应式 2/4”更能进入开发排期。
• 不是只看静态图。 重点确认 hover、focus、active、disabled、loading、error 这些状态是否齐全。
• 不是强制重构。 能用 impeccable adapt 修复移动端溢出时，不要顺手换框架、换字体或新建设计系统。

验收方法

开发修改后，重新运行同一审计，并在规定视口检查：页面无横向滚动；主要触控目标符合团队门槛；键盘焦点可见；浅色/暗色文本可读；没有因动效而隐藏内容。没有实际复测，就只能写“修复待验证”。

第四步：用 Better Icons 做“可追溯”的图标决定

better-icons 通过 Iconify 搜索和获取 SVG。它提供的是候选资产，不是自动替换权。设计师需要先写清图标语义、现有风格、尺寸、描边、颜色继承和许可要求。

搜索命令

better-icons search "payment card" --prefix lucide --limit 10 --json
better-icons search "location pin" --prefix lucide --limit 10 --json
better-icons get lucide:credit-card --color currentColor --size 24 --json

如果你的环境没有 better-icons 命令，先向项目负责人确认是否允许安装；不要擅自执行 npm install -g、npx 下载或把网络搜索结果当成本地资源。

可复制提示词

请使用 better-icons 为以下 UI 图标建立候选映射，不要直接写入项目文件。

现有图标规范：24×24 viewBox、2px 线性描边、圆角端点、currentColor；禁用实心 emoji 和混合图标风格。
需要的语义：地址、信用卡支付、订单确认、错误提示。

对每个语义输出：
1. 推荐 Iconify 图标 ID（最多 2 个候选）；
2. 为什么语义匹配；
3. 与现有描边/填充风格是否一致；
4. 获取命令；
5. 来源库与许可需要人工复核的事项；
6. “保留现有图标”是否比替换更合理。

禁止：下载到项目、批量替换、忽略现有图标系统、把品牌 Logo 当通用功能图标。

图标映射表应该长这样

把“保留”写进表里，往往比把每个位置都塞进新图标更专业。

最终交付：一份可以交给开发或 AI Agent 的任务块

完成四个步骤后，不要只交 Figma 链接。把下面任务块连同截图、设计稿和图标映射一起交付。

任务：优化 [页面/组件名称] 的关键任务路径，不重做品牌。

用户任务：[例如首次下单并提交订单]
已证实问题：[粘贴 audit 的 P1/P2，保留截图编号]
已选方向：[方向名称与选择原因]
必须保留：[信息、业务规则、现有 token、组件]
图标决策：[粘贴“保留/新增/替换”映射与来源]

实施边界：
- 不修改后端业务、文案事实、价格、支付逻辑或路由；
- 不安装新依赖、下载图标或替换图标库，除非先获得确认；
- 不生成伪造 UI、订单数据、测试截图或成功日志；
- 不做无关重构。

必须交付：
1. 默认、hover、focus、active、disabled、loading、error 状态说明；
2. 360px、390px、768px、桌面视口的响应式行为；
3. 修改的组件/样式清单；
4. 实际运行过的验证命令、退出码和截图；
5. 未执行项目的明确清单。

验收：
- 用户能在一个连续路径中完成 [任务]；
- P1 问题逐项关闭或说明未关闭原因；
- 页面无横向溢出，关键操作可键盘到达且焦点可见；
- 图标来源、语义、尺寸、颜色继承和许可记录完整。

停止条件：范围外需求、新依赖、品牌重做、真实用户数据或无法访问的页面出现时，先停下并请求确认。

最常见的四个失败方式

1. 先让 AI 出三张漂亮图。 没有页面目标和截图证据，方向探索只会放大主观偏好。
2. 把探索图当最终设计。 product-design:ideate 的输出是供人选择的方向；状态、断点、边界和文案事实仍需补齐。
3. 图标库一键替换。 风格混乱、许可不明、旧图标语义被破坏，是比“图标不够新”更大的风险。
4. 只交视觉稿，不交验证。 只要没有视口、状态、焦点和验收条件，开发就会被迫猜测。

交付前检查

• [ ] 每个高优问题都能指向截图、页面状态或代码证据。
• [ ] 已选方向说明了用户任务与取舍，不是“更好看”。
• [ ] 图标表包含保留项、候选来源和许可复核点。
• [ ] 提示词不授权 AI 擅自安装依赖、改业务逻辑或下载资源。
• [ ] 运行过的内容和未运行的内容严格分开写。
• [ ] 读者只拿到本文和自己的材料，也知道该给 Agent 什么输入、如何验收、何时停止。

一位设计师真正需要的，不是让 AI 替自己“出图”，而是让 AI 帮自己把判断、证据、选择和交付连接起来。这样做出的设计，才既能讲清楚，也能落得下去。