给一个新网站起名字，通常比给它找个合适的头像容易。名字定了，域名买了，页面也能打开了，左上角却还挂着模板自带的图标。随手找一张插画，大图挺好看，缩进浏览器标签后只剩几块颜色；让绘图工具直接画 Logo，又容易得到带文字、带底座、带复杂光影的展示图。
IP as Logo 提供了一个更窄的办法：围绕简单的角色形象建立一套生成约束，让主体更接近可以反复使用的吉祥物。它适合个人工具、独立产品和内容网站做第一轮视觉探索。真正值得花时间的部分，是从候选图里留下一个形象，再把它整理成网站需要的文件。
项目有两个入口。GitHub 仓库提供 Skill，官网 Logo 库提供现成图片。如果只是想给小项目找个头像，可以先逛图库；如果希望角色与自己的产品有关，再走 Skill 这条路。
先弄清安装的是什么
Skill 可以理解为交给智能体的一份工作说明。它告诉智能体接到这类任务时该了解哪些背景、怎样提出方向、如何约束图片，但它本身不是绘图模型，也不是一套需要部署在 VPS 上的服务。
这个仓库的核心文件是 SKILL.md，此外有 README、许可证和示例素材。没有一套可以启动的 Logo 生成后台，也不需要为安装它准备数据库、Redis 或 Docker Compose。按照 Agent Skills 格式规范，技能目录至少要有包含元信息和说明正文的 SKILL.md，脚本、参考资料与素材目录则属于可选内容。
这一区别直接影响准备工作。已有支持 Skill 的智能体，只解决了“在哪里读取说明”的问题；还要有能被它调用的图片生成工具，才能真正出图。账号能聊天、终端里能执行命令，都不等于当前环境已具备绘图能力。生成图片的费用、次数和分辨率，也由所用服务决定。
如果你没有这些条件，不必先折腾一遍安装。浏览图库、下载候选素材、做尺寸比较，同样可以把网站图标这件事推进下去。
项目展示图。观察重点是角色的轮廓与识别特征，而不是把整张展示墙当成网站图标。
两条使用路线，先选简单的一条
图库适合需求还没有那么明确的阶段。你可以先寻找几种大致符合站点气质的角色，比较它们在浅色、深色页面中的感觉。看到喜欢的图，记录页面地址与原始文件，不要只存一张浏览器截图。截图可能把页面圆角、按钮或缩略图压缩一并带进来，后续很难分清哪些属于原始素材。
官网当前展示了可免费下载和商业使用的说明。对准备长期使用的素材，最好同时保留下载时的说明与地址；需要建立正式品牌时，还应另行核查名称和图形是否与已有标识冲突。图库可下载，并不说明某张图只会被你一个人使用。
Skill 路线则适合已经知道“网站做什么、给谁用、希望呈现什么感觉”的项目。例如，一个记录自托管软件部署方法的网站，可以把需求写成“让人愿意打开、看得清、安静、不像游戏角色”，再讨论具体形象。不要一上来就把猫、机器人、云朵、书本全部塞到同一张图里。
两条路线也可以衔接。先从图库理解自己喜欢哪种比例与表情，再用原创方向补足产品关联。参考应落在设计特征上，例如“大色块、短轮廓、眼睛间距较宽”，不要要求照搬某一个现成角色。
安装命令与作用范围
项目给出的安装命令是：
npx skills@latest add s1dashu/ip-as-logo-skill
运行这条命令需要本机能使用 Node.js 的 npx，并能访问相关下载地址。安装器会识别仓库中的 Skill，并让你选择目标智能体。这里的 @latest 表示获取当时发布的最新版安装器；它不是这个 Logo 项目自身的版本号。
希望在多个项目里使用，可以采用个人范围安装：
npx skills@latest add s1dashu/ip-as-logo-skill --global
项目范围与个人范围怎么选？如果这套视觉工作只属于一个代码仓库，放在项目范围更容易与同事一起维护；如果经常给不同的小项目做角色，个人范围更顺手。选择范围时也要看目标智能体的支持方式，不要把某个工具的目录路径当成所有工具都通用的规则。
Skills CLI 文档还提供了列出技能、指定智能体和查看已安装内容等操作。首次使用保留交互选择即可，没有必要为了省几次回车直接给所有智能体安装所有内容。
安装后，先确认目标工具能发现 ip-as-logo。有的工具会在启动时读取技能，有的会按任务加载；具体刷新方式以该工具文档为准。不要因为当前会话没有使用它，就连续往不同目录复制好几份。重复安装往往让后面的更新与排查更难。
第一条需求，写清产品比堆风格词有用
“高级、简约、可爱、科技感、国际化”很容易写在同一句话里，但它们未必能同时指导一个明确形象。更有用的是说明产品与使用位置。
下面是一份适合教程网站的需求示例，可以改成自己的情况：
我要为一个中文自托管教程网站做吉祥物。
读者主要是个人站长，内容包括 Docker、数据库和网站维护。
希望形象安静、友好，浏览器标签里也能认出。
先给我三个不同方向，并说明各自与网站内容的关系。
不要把网站名称画进图片，不要服务器机柜、霓虹光和复杂背景。
这一轮先讨论方向，不生成图片。
这份要求没有提前决定动物种类，留下了合理的探索空间；同时限定了读者、气质、应用位置和不需要的元素。智能体提出方向后，才有东西可选。
如果你已经知道要一本书，就直接说“保留书本作为主体”。不必因为示例里动物多，就勉强改成某种动物。工具的默认偏好不能替代站点本身的判断。书页也不必写满文字，封面与翻开的轮廓足够表达阅读，过多细节只会在小尺寸里消失。
方向讨论阶段应当回答一个问题：去掉说明后，这个形象还像不像你的产品？如果每一个方向都只能靠一句长解释成立，就继续缩小范围。一个收藏工具用口袋或容器作为提示，比给普通小熊挂满文件夹更直接。
候选图怎么比较，别被第一眼的光影带走
项目把复杂度控制、主体轮廓和角落构图写进了生成要求。实际使用时，不必把每个约束背下来，更值得检查的是三件事：主体能否单独被认出，缩小后特征是否保留，颜色能否与页面共处。
让候选图放在相同尺寸、相同背景附近再比较。某张图片如果因为画得更大而显得更有冲击力，先统一显示面积；某张图片因为背景特别亮而显得抢眼，先问这个背景是否适合网站。
可以把第一轮比较压缩到以下几个问题：
- 在 32 像素左右，还能分辨是什么角色吗？
- 角色的主要特征有没有被裁掉，左右方向是否适合实际位置？
- 去掉小装饰之后，它还保留自己的样子吗？
- 与站名并排时，谁更容易先被看到？
- 放到正文旁边，会不会抢走阅读注意力？
32 像素在这里是一个观察尺寸，并不是保证所有浏览器都按这个尺寸显示。还应当在更小的标签位置看一眼。大图里的嘴角、眼睛高光和细线，到了那时可能已经不能表达任何信息。
项目说明不会自动淘汰或重试生成结果，所以不要把拿到的每一张图都视为已经检查合格的交付稿。选图与最终整理仍需要人来做。
从项目展示图截取的局部。把几张角色放在一起，更容易看出轮廓、面部位置与背景颜色的区别。
修改时只解决一个问题
发现问题后，最容易走偏的做法是重新发一段比原来更长的要求：“要更高级、更立体、更扁平、更可爱，同时保持原样。”要求越冲突，越难判断下一张图究竟改好了什么。
假设选中的角色整体已经合适，只是耳朵在小尺寸里不清楚，可以这样提反馈：
保留当前角色、姿态和两块主体颜色。
这一轮只改耳朵：让两只耳朵的外轮廓更容易辨认，减少内部细节。
不要新增帽子、文字、阴影或其他装饰。
如果问题是“看起来太像玩具”，则要求减少材质感、让色块更平稳，而不是顺手再换动物和背景。对于图像服务能否稳定保持角色，应以它实际提供的编辑或参考图能力为准，Skill 本身不会让每次独立生成都变成同一个角色。
保留原始候选和修改结果，使用简单的编号，例如 fox-a1、fox-a1-ear-v2。每次挑选写一句理由，下一次回来就不用重新猜“最终版到底是哪一张”。
图片选好了，还没变成一套网站文件
网站至少有三类使用位置：页面中的可见标识、浏览器标签图标，以及移动设备上的入口图标。它们可能使用同一个角色，但不应该毫无区分地引用同一张大图。
页面标识要考虑与站名的间距、背景和显示尺寸。浏览器标签要看很小的轮廓。移动入口可能有平台裁切，过于贴边的角色需要另做留白。社交分享封面则通常是横向画面，适合把角色与文章标题组合，不必把方形图简单拉宽。
一份便于管理的文件组织可以是：
brand/
source/mascot-original.png
web/site-mark.png
web/favicon-32.png
web/favicon-64.png
mobile/app-icon-192.png
mobile/app-icon-512.png
notes.md
这是素材整理示例，不是项目下载后会自动生成的目录。源文件保留原始尺寸，网站用的副本按位置导出。PNG、WebP 都是位图格式；修改扩展名不会得到真正的矢量文件。需要 SVG 时，应另做矢量重绘与轮廓整理。
普通 HTML 页面可以这样声明图标，路径应换成已经上传到自己网站的文件：
<link rel="icon" type="image/png" sizes="32x32" href="/brand/favicon-32.png">
<link rel="icon" type="image/png" sizes="64x64" href="/brand/favicon-64.png">
MDN 对 rel="icon" 的说明介绍了浏览器如何参考格式和尺寸选择图片。框架项目若有自己的图标约定，应使用对应约定，避免页面里出现相互冲突的声明。
常见卡点，按发生位置处理
命令执行失败与图片生成失败是两类问题。前者先看 Node.js、网络与目标安装范围，后者先看当前智能体能否调用图像工具。不要把“没有输出图片”直接理解为需要再次安装技能。
如果工具没有识别到 Skill，先确认安装时选中了正在使用的智能体，以及本次会话是否能读取那个范围。当前项目的安装不一定对另一个项目生效，个人安装也不代表所有工具都采用同一发现方式。按工具文档查看技能列表，比到处复制文件更可靠。
如果能提出方向却不能生成，说明理解需求与绘图调用之间可能还有缺口。让工具说明自己可用的图片能力，缺少能力时先补齐；不要接受只有文字描述、却被说成“图片已经生成”的结果。
如果拿到的是多张图拼成一张展示板，要求交付独立文件。展示板适合比较，不适合作为六份原始素材。即便可以手动截取，也可能损失分辨率和边缘。独立候选更便于保留编号与后续修改。
还有一种情况：主体看起来清楚，但始终靠强烈的立体材质吸引人。这时回到最初的用途，小尺寸标识需要的是轮廓，减少材质与装饰比继续增加光影更有帮助。若实际希望做一张产品海报，那应另开一个任务，不要与 Logo 定稿混在一起。
为第一轮设一个明确终点
第一轮可以只交付一张比较记录和一份选中的原图。记录里写明哪些方向被排除、为什么保留这一张、下一步只需要解决什么。暂时没有满意候选，也应明确问题在哪，再决定是否继续生成。
文件收齐后，先做导航与头像两个位置。它们能暴露主要问题，工作量又比较可控。等角色确定，再补手机入口和分享封面，这比一开始要求所有尺寸全部完成更容易避免返工。
不要把“还有可能更好”当成持续生成的理由。只要小尺寸清楚、页面协调、文件来源明确，第一版就可以进入使用阶段。后来需要修改时，带着具体问题回来，原有判断才会继续起作用。
上线前看一遍真实页面
最后的检查不用做成复杂工程。打开首页、文章页与手机页面，看看左上角的角色是否清楚、是否挤压站名；再打开多个标签页，确认自己的网站能被找到。把网页背景切到深色时，也应检查边缘是否混在一起。
搜索结果中的图标还有单独的要求。Google 的 favicon 文档要求图形为方形，首页和图片可抓取，图标地址保持稳定；配置符合要求也不保证立即显示。不要把搜索结果暂时没更新，当成必须再次重画 Logo 的理由。
上线后保存原始素材、最终选图、使用位置与下载说明。这些资料比多留几十张没有编号的候选图更有价值。几个月后要做新的封面或手机入口，你才能沿用同一个形象。
IP as Logo 适合解决“还没有明确视觉方向”的阶段。先把需求说清、留下一个经得住缩小的角色，再把文件与页面配置做好，网站左上角才会从临时占位变成真正可以长期使用的标识。