zaihengwen-dev Icon 144px Spec
适用场景
- 用户说“按规范画 icon / 再画一个 icon / 重画 icon / 这个 icon 不符合规范”。
- 用户提供 icon 视觉规范（144px 体系、keyline、描边、圆角、视觉重心）。
- 需要在 Figma 中新增 icon 组件集和颜色变体。
前置要求
- 先加载
figma-useskill，再调用use_figma。 - 默认仅操作
Untitled的◉ Icons(细）画布。 - 未经用户确认，不修改已有命名体系（如
Property 1=xxx-黑/666/...）。 - 若用户未提供其他参考，默认优先参考这个 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/vertical64x84variantPalette：默认黑, 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
- Circle:
- 描边：
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: CENTER2：圆形图形示例，Union约80 x 80；常见约束是CENTER / CENTER3：方形图形示例，Union为72 x 724：圆角路径示例，圆角往往不是简单靠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，最终优先级通常是：
- 整体像一个完整 icon
- 图片语义成立
- 上传动作作为辅助被读到
图片主体 + 右下角动作类 icon 经验
- 对
编辑图片（细）、设为封面（细）、重置图片（细）、把图片发送给朋友（细）这类图标，优先把它们看成同一家族：- 左侧是稳定的图片主体
- 右下角是小型动作位
- 如果用户认可了图片主体，就默认不要再重画图片主体：
- 保留图片框、太阳点、山形的整体关系
- 只修右下角动作
- 不要为了改动作把主体内部留白搞丢
- 右下角动作的优先级不是“自己单独像一个完整 icon”，而是：
- 落在正确的右下角动作位
- 线性、轻量、不抢主体
- 动作语义仍然清楚
- 右下角动作默认应更接近“线性小标记”，而不是一个完整的独立大图标：
- 尽量开口、轻、短
- 不要太厚重
- 不要把动作画成右侧一整坨实心形
- 如果动作是“分享/发送给朋友”：
- 优先使用简化后的右向线性箭头
- 重点保留方向感和动作感
- 不要直接照搬完整的“发送给朋友（细）”主图比例，否则会显得太大、太抢
- 位置判断上，右下角动作要参考同列现有图标的动作区，而不是凭感觉摆放：
- 不能太靠里，避免像贴在图片内容中间
- 不能太靠外，避免像脱离主体
- 要读起来像“图片上的一个附加动作”
- 这类组合 icon 不要做成“左边图片 + 右边另一个 icon”的拼贴效果。
- 若已经有正确的图片主体参考，优先复用现有图片主体路径，再替换右下角动作路径；不要从零重造整张图片。
- 如果为了把线性动作转成最终可用的 filled vector，需要做轮廓转换，必须额外检查：
- 轮廓转换后坐标有没有偏移
- 动作位是否还在右下角
- 转换后是否因为路径平移丢失而导致箭头漂到错误位置
- 对这类图标，交付前必须自检：
- 图片主体是否保持原先被认可的结构
- 右下角动作是否够轻
- 动作位置是否真的在右下角动作位
- 是否出现“动作太大像第二个 icon”
- 是否出现“动作太小导致语义丢失”
锁字母类 icon 经验
- 锁字母类（如
锁A/锁B/锁C/锁D/锁E）优先参考现有锁A（细）、锁B（细）、锁C（细），不要重新发明锁体样式。 - 用户一旦确认某一版锁体是对的，后续新字母默认：
- 直接复用这版锁体
- 只改字母
- 不要顺手再改锁身、锁梁、钥匙孔、整体比例
- 这类 icon 的关键不是“画一个字母贴上去”，而是让字母和锁体保持同系列语言：
- 字母位置沿用同一列基准
- 字母宽高不要把锁体右侧节奏撑坏
- 字母粗细要和锁体视觉重量一致
- 若参考组里的锁体是填充轮廓逻辑，就继续用填充轮廓逻辑，不要混成描边逻辑。
- 若参考组里的字母是轮廓字母（内部有留白），新字母也必须保持轮廓字母，不要误做成实心块。
- 处理带内腔的字母（如
D、P、R、B）时，重点不是“画了内轮廓”，而是内轮廓必须真的把洞扣出来：- 不能只是内外两条路径都填充
- 必须确保复合路径/方向规则正确，让内孔实际挖空
- 处理不带内腔但有多横笔的字母（如
E、F）时：- 先保证左竖笔稳定
- 再看三横/两横的长度节奏
- 不要为了追求字母识别度把右侧撑得过宽
- 新建锁字母时，优先工作流：
- 复制最近一次被用户认可的锁字母组件集作为母版
- 保留全部变体与颜色
- 仅替换字母 vector
- 再做位置微调
- 如果用户说“放到某个 icon 下方/旁边”，不要只改坐标后口头确认，必须同时检查：
- 是否在同一页
- 是否在同一父级上下文
- 是否已经滚动定位并选中
- 对锁字母类 icon，交付前必须自检这几项：
- 锁体有没有被误改
- 字母是不是该空的地方真的空了
- 有没有出现“内外都填充导致看起来还是实心”
- 有没有残留旧字母或多余路径
- 新组件是不是出现在用户当前看的那一页，而不是跑到别页
- 这类任务不要一边猜一边交付；先自检，再告诉用户“好了”。
标准工作流
定位画布
- 切到
◉ Icons(细）页面。 - 在现有内容右侧创建新分组 frame（避免覆盖旧内容）。
- 切到
创建组件结构
- 分组 frame 名：
{iconName}-规范（或用户指定名）。 - 每个变体建立
COMPONENT（144x144）。 - 组合为
COMPONENT_SET，名称使用{iconName}。
- 分组 frame 名：
绘制图形
- 先放 keyline（可隐藏）再画图形。
- 使用 6px inside stroke、round cap/join。
- 根据图形复杂度做必要的重心/缩放调整。
- 默认先观察参考页里相近 icon 的
Union尺寸、inset、是否闭环、是否拆分路径、constraints 后再下笔。 - 不要把
72 x 72理解成所有 icon 的最终图形尺寸；它只是square72keyline 基准。实际Union可按参考 icon 做视觉放缩与留白。 - 如果图标用单一闭环路径会显得“闷”或“挤”，优先尝试拆成多段 open paths。
- 对于房子/设置等带明显转折的图标，优先用路径曲线段做圆角，而不是只依赖
Round Join。 - 在不影响统一性的前提下，能拆路径就不要强行全部闭环。
- 对主页类 icon，先判断是否只需要
roof + body两段即可表达语义，尽量少线条。
生成变体
- 变体命名保持现有规则：
Property 1={iconName}-{颜色或状态}。 - 默认生成：黑/666/999/白/红/禁用-亮/禁用-暗/紫。
- 变体命名保持现有规则：
质量检查
- 图形是否在 keyline 内（考虑 inside stroke）。
- 线宽、端点、圆角是否统一。
- 复杂图标是否说明了缩放策略。
导出前检查（仅当用户要求）
- Outline Stroke
- 清理隐藏层与多余点
返回结果格式
每次执行后返回：
componentSetIdcreatedNodeIdsmutatedNodeIdskeylineTypestrokeSpec（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 给
搜索(细)补齐禁用亮/禁用暗变体。”