# Icon 144px Spec

> 按 144px 图标视觉规范创建或修正 Icons(细) 图标组件集。用于“画一个新 icon”“按规范重画 icon”“修正线宽/重心/keyline”“补齐颜色与禁用态变体”等场景。默认优先参考 Figma 文件中的 icon 页面并与 figma-use 联动执行。

- Skill: `zaihengwen-dev/icon-144px-spec` (Agent Skill)
- Install (CLI): `npx skillmds@latest add zaihengwen-dev/icon-144px-spec`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zaihengwen-dev/icon-144px-spec/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Design & Media
- Author: zaihengwen-dev (https://skillmd.com/u/zaihengwen-dev)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/zaihengwen-dev/icon-144px-spec

---


# Icon 144px Spec

## 适用场景
- 用户说“按规范画 icon / 再画一个 icon / 重画 icon / 这个 icon 不符合规范”。
- 用户提供 icon 视觉规范（144px 体系、keyline、描边、圆角、视觉重心）。
- 需要在 Figma 中新增 icon 组件集和颜色变体。

## 前置要求
1. 先加载 `figma-use` skill，再调用 `use_figma`。
2. 默认仅操作 `Untitled` 的 `◉  Icons(细）` 画布。
3. 未经用户确认，不修改已有命名体系（如 `Property 1=xxx-黑/666/...`）。
4. 若用户未提供其他参考，默认优先参考这个 Figma icon 页面里的现有图标风格与结构：
   - `https://www.figma.com/design/mfiwlGkUkLYSizi0pdyYjp/PAD-%E7%BB%84%E4%BB%B6%E5%BA%93--AI%E8%AF%95%E9%AA%8C%E7%94%B0%EF%BC%89?node-id=3081-461&t=buHHso72cS3RCCLq-1`

## 输入约定
每次执行前尽量确认以下参数（若用户未给，按默认值）：
- `iconName`：例如 `水杯(细）`
- `keylineType`：`circle80` / `square72` / `horizontal84x64` / `vertical64x84`
- `variantPalette`：默认 `黑, 666, 999, 白, 红, 禁用-亮, 禁用-暗, 紫`
- `themeScope`：默认 `Icons(细)`
- `needOutlineStroke`：默认 `false`（仅导出前才 true）

## 硬性规范（必须遵守）
- 画布基准：每个 variant 使用 `144 x 144`。
- Keyline：
  - Circle: `80 x 80`
  - Square: `72 x 72`
  - Horizontal: `84 x 64`
  - Vertical: `64 x 84`
- 描边：`strokeWeight = 6`。
- 描边对齐：`Inside`。
- 端点样式：统一 `Round Cap`。
- 转角样式：统一 `Round Join`。
- 视觉重心：允许沿垂直方向微调 `2-4px`。
- 复杂图标：允许整体缩小 `5%-10%`，但要说明原因。

## 默认参考来源
- 默认参考页：
  - `https://www.figma.com/design/mfiwlGkUkLYSizi0pdyYjp/PAD-%E7%BB%84%E4%BB%B6%E5%BA%93--AI%E8%AF%95%E9%AA%8C%E7%94%B0%EF%BC%89?node-id=3081-461&t=buHHso72cS3RCCLq-1`
- 默认优先学习参考页里现有 icon 的：
  - `Union` 的实际尺寸与 inset
  - 是否闭环 / 是否拆成多段 open paths
  - constraints（如 `CENTER/CENTER`、`SCALE/CENTER`）
  - 圆角是靠 `Round Join` 还是路径本身带曲线段

## 参考页经验规则
- `72 x 72` 只是 `square72` 的 keyline 基准，不是所有 icon 的最终图形尺寸。
- 具体图形尺寸应优先跟随参考 icon 的视觉留白，而不是机械填满 keyline。
- 从用户在 `☉ 字体✅` 页放的示例可归纳：
  - `1`：横向图形示例，`Union` 约 `91.5 x 72`，更偏 `horizontal` 逻辑；常见约束是 `horizontal: SCALE, vertical: CENTER`
  - `2`：圆形图形示例，`Union` 约 `80 x 80`；常见约束是 `CENTER / CENTER`
  - `3`：方形图形示例，`Union` 为 `72 x 72`
  - `4`：圆角路径示例，圆角往往不是简单靠 `Round Join`，而是直接在路径里写入曲线段
- 主页类图标默认优先参考：
  - 方形基准：参考 `3`
  - 圆角处理：参考 `4`

## 核心参考锚点
- 主页类：`主页（细）`
  - `Union` 约 `87.47 x 73.15`
  - inset 约 `x=28.27, y=35.42`
  - 单 `Union`，`pathCount=2`
  - 更接近“宽屋顶 + 收主体 + 路径内曲线圆角”
- 图片类：`图片全屏（细）`
  - `Union` 约 `91.5 x 72`
  - inset 约 `x=30.2, y=36`
  - `strokeAlign=CENTER`
  - 横向留白明显，适合图片/画面类图标
- 上传类：`箭头（向上)（细）`
  - `Union` 约 `48 x 70.12`
  - inset 约 `x=48, y=37`
  - 细长、中心稳定，适合作为“辅助动作”而非主体
- 工具类：`编辑(细)`
  - `Union` 为 `72 x 72`
  - inset `x=36, y=36`
  - `pathCount=2`
  - 方形结构稳定，适合作为工具类控制参考
- 最标准基准：
  - `矩形（细）`：`72 x 72`，`x=36, y=36`，`INSIDE`
  - `圆形（细）`：`80 x 80`，`x=32, y=32`，`CENTER`

## 使用这些锚点的方法
- 在画新 icon 前，先判断它属于哪一类：
  - 主页/房子类 → 优先看 `主页（细）`
  - 图片/画面类 → 优先看 `图片全屏（细）`
  - 上传/方向动作类 → 优先看 `箭头（向上)（细）`
  - 工具类 → 优先看 `编辑(细)`
  - 无明确类别时，再退回 `矩形（细）` / `圆形（细）` 作为几何基准
- 组合类图标（如“上传图片”）要拆主次：
  - 主体参考图片类锚点
  - 辅助动作参考上传类锚点
  - 不能让辅助动作抢掉主体的视觉中心

## 主页类 icon 经验
- 主页/房子类 icon 不要机械塞进一个完整 `72 x 72` 闭环里。
- 更自然的结构通常是：
  - `roof`（屋顶）单独一段 open path，横向可以略宽于主体
  - `body`（主体）单独一段 open path，宽度比屋顶收一点
  - `door` 不是必须；若加了反而显得挤，可以省略
- 视觉上优先追求“上轻下稳”：
  - 屋顶更宽、主体更收
  - 主体略靠下，留出呼吸感
- 圆角优先放在主体底部或关键转折，不需要所有地方平均加圆角。
- 对这类细线 icon，`strokeAlign: CENTER` 往往比 `INSIDE` 更轻、更顺眼；如无特殊限制，优先尝试 `CENTER`。

## 上传图片类 icon 经验
- “上传图片”优先参考“图片”这一列，而不是“上传任务”这一列。
- 语义主次要清楚：
  - 主体是“图片框 / 图片内容”
  - 上传箭头是辅助动作，不要喧宾夺主
- 更合理的构图通常是：
  - 左侧：图片框主体（可拆成开口框 + 太阳点 + 山形）
  - 右侧：上传箭头
- 图片框不要画成完整封闭卡片再往中间硬塞图形；更轻的做法是：
  - 外框可用开口路径或不完整框线
  - 山形与太阳点尽量简化
- 上传箭头宜独立成两段路径（箭头头部 + 竖线），与图片框拉开一点间距。
- 优先保证“图片语义一眼成立”，再考虑上传动作。
- 这类图标通常更适合横向构图，可参考 `horizontal84x64` 的留白逻辑，但最终 still 以参考 icon 的视觉留白为准。
- 初稿可以拆成多段路径来找关系，但最终可用版本往往要**收敛成一个统一的 `Union`**。
- “图片主体”和“上传动作”不能做成明显并列的两坨；更好的结果通常是把上传动作融进整体轮廓节奏里。
- 如果画出来像“左边一个图片 icon + 右边一个箭头 icon”的拼贴，说明还没有收拢到位。
- 对这类组合 icon，最终优先级通常是：
  1. 整体像一个完整 icon
  2. 图片语义成立
  3. 上传动作作为辅助被读到

## 图片主体 + 右下角动作类 icon 经验
- 对 `编辑图片（细）`、`设为封面（细）`、`重置图片（细）`、`把图片发送给朋友（细）` 这类图标，优先把它们看成同一家族：
  - 左侧是稳定的图片主体
  - 右下角是小型动作位
- 如果用户认可了图片主体，就默认**不要再重画图片主体**：
  - 保留图片框、太阳点、山形的整体关系
  - 只修右下角动作
  - 不要为了改动作把主体内部留白搞丢
- 右下角动作的优先级不是“自己单独像一个完整 icon”，而是：
  1. 落在正确的右下角动作位
  2. 线性、轻量、不抢主体
  3. 动作语义仍然清楚
- 右下角动作默认应更接近“线性小标记”，而不是一个完整的独立大图标：
  - 尽量开口、轻、短
  - 不要太厚重
  - 不要把动作画成右侧一整坨实心形
- 如果动作是“分享/发送给朋友”：
  - 优先使用简化后的右向线性箭头
  - 重点保留方向感和动作感
  - 不要直接照搬完整的“发送给朋友（细）”主图比例，否则会显得太大、太抢
- 位置判断上，右下角动作要参考同列现有图标的动作区，而不是凭感觉摆放：
  - 不能太靠里，避免像贴在图片内容中间
  - 不能太靠外，避免像脱离主体
  - 要读起来像“图片上的一个附加动作”
- 这类组合 icon 不要做成“左边图片 + 右边另一个 icon”的拼贴效果。
- 若已经有正确的图片主体参考，优先复用现有图片主体路径，再替换右下角动作路径；不要从零重造整张图片。
- 如果为了把线性动作转成最终可用的 filled vector，需要做轮廓转换，必须额外检查：
  - 轮廓转换后坐标有没有偏移
  - 动作位是否还在右下角
  - 转换后是否因为路径平移丢失而导致箭头漂到错误位置
- 对这类图标，交付前必须自检：
  - 图片主体是否保持原先被认可的结构
  - 右下角动作是否够轻
  - 动作位置是否真的在右下角动作位
  - 是否出现“动作太大像第二个 icon”
  - 是否出现“动作太小导致语义丢失”

## 锁字母类 icon 经验
- 锁字母类（如 `锁A/锁B/锁C/锁D/锁E`）优先参考现有 `锁A（细）`、`锁B（细）`、`锁C（细）`，不要重新发明锁体样式。
- 用户一旦确认某一版锁体是对的，后续新字母默认：
  - 直接复用这版锁体
  - 只改字母
  - 不要顺手再改锁身、锁梁、钥匙孔、整体比例
- 这类 icon 的关键不是“画一个字母贴上去”，而是让字母和锁体保持同系列语言：
  - 字母位置沿用同一列基准
  - 字母宽高不要把锁体右侧节奏撑坏
  - 字母粗细要和锁体视觉重量一致
- 若参考组里的锁体是填充轮廓逻辑，就继续用填充轮廓逻辑，不要混成描边逻辑。
- 若参考组里的字母是轮廓字母（内部有留白），新字母也必须保持轮廓字母，不要误做成实心块。
- 处理带内腔的字母（如 `D`、`P`、`R`、`B`）时，重点不是“画了内轮廓”，而是**内轮廓必须真的把洞扣出来**：
  - 不能只是内外两条路径都填充
  - 必须确保复合路径/方向规则正确，让内孔实际挖空
- 处理不带内腔但有多横笔的字母（如 `E`、`F`）时：
  - 先保证左竖笔稳定
  - 再看三横/两横的长度节奏
  - 不要为了追求字母识别度把右侧撑得过宽
- 新建锁字母时，优先工作流：
  1. 复制最近一次被用户认可的锁字母组件集作为母版
  2. 保留全部变体与颜色
  3. 仅替换字母 vector
  4. 再做位置微调
- 如果用户说“放到某个 icon 下方/旁边”，不要只改坐标后口头确认，必须同时检查：
  - 是否在同一页
  - 是否在同一父级上下文
  - 是否已经滚动定位并选中
- 对锁字母类 icon，交付前必须自检这几项：
  - 锁体有没有被误改
  - 字母是不是该空的地方真的空了
  - 有没有出现“内外都填充导致看起来还是实心”
  - 有没有残留旧字母或多余路径
  - 新组件是不是出现在用户当前看的那一页，而不是跑到别页
- 这类任务不要一边猜一边交付；先自检，再告诉用户“好了”。

## 标准工作流
1. **定位画布**
   - 切到 `◉  Icons(细）` 页面。
   - 在现有内容右侧创建新分组 frame（避免覆盖旧内容）。

2. **创建组件结构**
   - 分组 frame 名：`{iconName}-规范`（或用户指定名）。
   - 每个变体建立 `COMPONENT`（144x144）。
   - 组合为 `COMPONENT_SET`，名称使用 `{iconName}`。

3. **绘制图形**
   - 先放 keyline（可隐藏）再画图形。
   - 使用 6px inside stroke、round cap/join。
   - 根据图形复杂度做必要的重心/缩放调整。
   - 默认先观察参考页里相近 icon 的 `Union` 尺寸、inset、是否闭环、是否拆分路径、constraints 后再下笔。
   - 不要把 `72 x 72` 理解成所有 icon 的最终图形尺寸；它只是 `square72` keyline 基准。实际 `Union` 可按参考 icon 做视觉放缩与留白。
   - 如果图标用单一闭环路径会显得“闷”或“挤”，优先尝试拆成多段 open paths。
   - 对于房子/设置等带明显转折的图标，优先用路径曲线段做圆角，而不是只依赖 `Round Join`。
   - 在不影响统一性的前提下，能拆路径就不要强行全部闭环。
   - 对主页类 icon，先判断是否只需要 `roof + body` 两段即可表达语义，尽量少线条。

4. **生成变体**
   - 变体命名保持现有规则：`Property 1={iconName}-{颜色或状态}`。
   - 默认生成：黑/666/999/白/红/禁用-亮/禁用-暗/紫。

5. **质量检查**
   - 图形是否在 keyline 内（考虑 inside stroke）。
   - 线宽、端点、圆角是否统一。
   - 复杂图标是否说明了缩放策略。

6. **导出前检查（仅当用户要求）**
   - Outline Stroke
   - 清理隐藏层与多余点

## 返回结果格式
每次执行后返回：
- `componentSetId`
- `createdNodeIds`
- `mutatedNodeIds`
- `keylineType`
- `strokeSpec`（6px inside + round cap/join）
- `opticalAdjustment`（是否做 2-4px 微调）
- `scaleAdjustment`（是否做 5%-10% 缩放）

## 常见修正规则
- **图标看起来偏小**：先检查是否误用 24px/96px 逻辑尺寸，改回 144 体系 keyline。
- **图标“掉下去”**：整体上移 2-4px。
- **复杂图标发糊/拥挤**：在 keyline 内整体缩小 5%-10%。
- **跨主题颜色不清晰**：保持变体命名不变，仅替换对应颜色值。

## 示例指令
- “按 icon-144px-spec 画一个 `水杯(细）`，keyline 用 `vertical64x84`。”
- “按 icon-144px-spec 把这个 icon 重画成 6px inside stroke，保留原命名。”
- “按 icon-144px-spec 给 `搜索(细)` 补齐禁用亮/禁用暗变体。”