Skill - 把风格写成规格：拆解 ian-xiaohei-illustrations 中文配图 Skill

一个只有九次提交、六个 Markdown 文件的仓库，两个半月拿到 9.4k Star。它没有代码，却比大多数带代码的项目更像工程。

一、配图是内容生产链上最难自动化的一段

写一篇技术长文，从选题、拉资料到成稿，能交给 AI 分担的比例已经相当高。真正卡住的环节反而是配图。

大概每个尝试过的人都跑过同一个循环：文章里刚写完一句「信任不是喊出来的，是一块证据一块证据铺过去的」，转身去找图像模型要一张配图，拿回来的是蓝紫渐变背景、两只握在一起的手、几个发光节点和若干枚齿轮。风格不对，换提示词；风格勉强对了，画面却和那句判断没有任何关系；好不容易两者都对上，生成第二张,线条粗细、色调、角色比例又全变了。

配图之所以难自动化，不是因为模型画不好，而是因为这个动作同时压着三条互相拉扯的约束：

• 语义约束：图必须对应文章里某一个具体的判断，而不是话题的泛泛联想。
• 一致性约束：一篇文章内部、乃至整个专栏的所有图，要看起来出自同一支笔。
• 克制约束：图要少、元素要稀、留白要多，读者一秒能看懂。

通用图像模型在第一条上勉强及格，在第二条上表现很差，在第三条上几乎是反着来的。原因不难理解——训练语料里被标注为「优秀插画」的样本，绝大多数是信息密度高、装饰性强、配色饱满的商业稿。你要的极简白底手绘草图，在它的先验分布里是长尾。

ian-xiaohei-illustrations值得拆解的地方，不在于画风本身有多讨喜，而在于它把上面三条约束翻译成了一份 AI agent 能逐条执行、并且能自我验收的规格。整个仓库没有一行可执行代码，全是 Markdown，但它的组织方式比很多带代码的项目更接近软件工程。

几个客观数据：MIT 协议，2026 年 5 月底上线，九次提交，9.4k Star、1.1k Fork。作者 Ian（GitHubhelloianneo）是产品设计师，同时在做一人公司实践。

二、它是什么，以及它明确拒绝做什么

这是一个Codex Skill——一份能被 Codex、Claude Code 这类 coding agent 加载的能力配置，用途是指导 agent 为中文文章、博客、Notion 页面和方法论内容生成正文配图。

默认视觉 IP 叫「小黑」：黑色实心、白点眼、细腿、空表情的小角色。定位写得很直白——小黑不是吉祥物，不是贴纸，不是站在角落里的装饰物，而是正在认真参与系统运转的荒诞工作者。

一句话概括它的目标：让 AI 不只是「配一张图」，而是把文章里的一个关键认知动作画出来。

真正体现工程素养的，是它同时写清楚了自己不做什么：

输出契约同样明确。默认产出 16:9 横版正文配图、一篇文章 4–8 张的 shot list、每张图的主题与结构说明，以及最终 PNG，落到工作区的assets/<article-slug>-illustrations/。默认不产出 PPTX、PDF、Keynote、SVG、HTML、Canvas 可编辑图、商业海报和大段文字型信息图。

这份「不适合」清单的价值被严重低估了。绝大多数 prompt 项目只写能力上界，从不写下界，结果就是用户拿它去干它干不了的事，然后判定「AI 不行」。把边界写进 README，等价于给一个库写清楚它的适用场景和已知限制——是接口文档的一部分，不是营销文案的减分项。

#三、从 Prompt 到 Skill：三层跃迁

把这个项目理解成「一段很长的提示词」会错过它真正的价值。Prompt 和 Skill 之间隔着三层结构性差异。

第一层：从一次性输入变成可寻址的能力。

Skill 的入口是SKILL.md，头部是一段 YAML frontmatter：

---name:ian-xiaohei-illustrationsdescription:生成 Ian 风格的中文正文配图。用于用户要求为中文文章、帖子、博客、Notion 文档、 工作流文档、方法论、流程、结构、状态、隐喻或观点生成"怪诞""小黑""手绘""正文配图" "文章插图""配图建议""shot list""去标题/改图"等任务；默认使用小黑 IP、纯白手绘、 少量红橙蓝批注、简洁清爽但天马行空的视觉风格。---

注意description的写法。它不是给人看的简介，而是给模型看的路由信号。Agent 在决定要不要加载这个 skill 时，唯一的依据就是这段文字。所以作者往里面塞满了触发词：怪诞、小黑、手绘、正文配图、文章插图、配图建议、shot list、去标题、改图。这本质上是一次检索优化——把用户可能说出口的每种表达方式提前铺进索引里。

配套的agents/openai.yaml更进一步：

interface:display_name:"Ian 小黑配图"short_description:"为中文文章生成怪诞清爽、有小黑IP的正文配图资产"default_prompt:"Use $ian-xiaohei-illustrations to 为这篇中文文章设计并生成几张小黑怪诞正文配图。"policy:allow_implicit_invocation:true

allow_implicit_invocation: true意味着用户不必显式写Use $ian-xiaohei-illustrations，agent 判断相关就能自主唤起。召回率上去了，误触发的风险也上去了——而唯一的闸门，还是那段 description 写得够不够准。写 skill 的人如果只把 description 当摆设，要么永远唤不起来，要么在不相干的对话里乱插一脚。

第二层：从单文件变成分层结构。

仓库的实际布局是这样：

. ├── README.md # GitHub 分享文档，不进 skill ├── LICENSE / NOTICE.md ├── examples/ │ ├── images/ # 8 张风格校准样例 │ └── prompts.md └── ian-xiaohei-illustrations/ ← 真正要安装的是这个子目录 ├── SKILL.md # 入口，约 100 行 ├── agents/openai.yaml ├── assets/examples/ └── references/ ├── style-dna.md # 风格 DNA、颜色、禁忌 ├── xiaohei-ip.md # IP 形象、性格、动作库 ├── composition-patterns.md # 结构类型、原创隐喻、反复刻 ├── prompt-template.md # 单张生图提示词模板 └── qa-checklist.md # 生成后检查与迭代

根目录的 README、LICENSE 和 examples 是给 GitHub 访客看的，不进 agent 上下文；需要拷进~/.codex/skills/的只有那个同名子目录。这个区分本身就是一次刻意的上下文治理。

第三层：从「一次说完」变成渐进式披露。

SKILL.md里有一句关键指令：「按任务需要读取，不要一次塞满上下文。」

入口文件一百行出头，五份 reference 加起来三百行左右。如果全量灌进去，光风格规范就要吃掉几千 token，而其中大部分在任何单次任务里都用不上——用户只要一份 shot list 的时候，prompt-template.md和qa-checklist.md完全是噪音。

这就是 Agent Skills 规范里 progressive disclosure 的落地形态：入口薄，细节按需加载。类比到工程实践，SKILL.md是头文件，references/是实现文件，agent 按调用路径决定链接哪些符号。

这一点对写自己 skill 的人尤其重要。上下文窗口再大也不是免费的——无关信息不只是浪费预算，还会稀释注意力，让模型在一堆规则里抓错重点。把 skill 拆成「一个薄入口 + 若干个职责单一的参考文件」，是目前最稳的组织方式。

四、style-dna.md：把审美变成可判定的条件

审美是最难写进规格的东西，因为它天然模糊。这份风格 DNA 的处理办法是：只要能量化的，一律给数字；不能量化的，用排除法收敛。

先看正向的「必须」部分，几乎每条都带可核对的判据：

• 16:9 横版。
• 纯白背景：不要米色、暖灰、纸张纹理、渐变、阴影、噪点、复古纸感。
• 黑色手绘线稿为主：细线、轻微抖动、不机械、不矢量、不厚重描边。
• 大量留白：主体占画面约 40%–60%，至少 35% 空白，最好有一整块安静区域。
• 少量中文手写批注：最多 5–8 处，每处尽量 2–8 个字。
• 一张图只讲一个核心动作、结构、状态或隐喻。
• 结构要自然表达，不要在图上写结构类型名称。

「主体占 40%–60%」「至少 35% 留白」「标注 5–8 处、每处 2–8 字」——这些数字的意义不在于图像模型能精确遵守（它做不到），而在于给出了可被检查的近似目标。人和 agent 在复检时，可以对着这几个数字给出「过 / 不过」的判断，而不是陷入「我觉得有点满」的主观拉扯。审美一旦有了阈值，返工就有了方向。

更值得学的是颜色部分。四种颜色被赋予了固定语义：

并且补了一句：蓝色不是每张都必须用，颜色要克制，宁可少不要多。

这就是一套彻头彻尾的语义化设计令牌。它和前端里--color-danger/--color-primary的思路完全同构：颜色不再由「这里配什么好看」决定，而是由「这个元素承担什么职责」决定。好处是跨图一致性——读者看过三张图之后，会无意识地学会「橙色箭头 = 主流程」，第四张图的理解成本随之下降。这种跨图的语义积累，是单张图再精美也换不来的。

然后是「绝对不要」的十三条：不要商业插画、不要 PPT 信息图、不要正式流程图、不要课程课件、不要可爱卡通海报、不要儿童插画、不要复杂架构图、不要精致扁平插画、不要科技感 UI、不要真实 App 截图、不要复杂背景渐变阴影纹理、不要把每个节点都解释清楚、不要在左上角写「Workflow 流程图 / 系统架构图 / 常见坑 / 路线图」这类类型标题。

正向七条，负向十三条。否定项接近正面项的两倍——这个比例不是作者话多，而是由生成模型的行为特征决定的。

扩散模型对「插画」这个词的默认响应，是训练分布里的众数：Behance 风格的扁平商业插画，饱和配色、圆润造型、装饰性图形。你想要的是分布长尾上的那种粗糙白底草图。正向描述只能把采样点往目标方向推一点，真正把它从众数里拽出来的，是一串明确的排除项。风格的定义，很大程度上是排除的艺术。

最后那条「不要在左上角写类型标题」尤其精准。图像模型见过海量信息图，其中绝大多数左上角都有一个标题栏，于是它会条件反射地补一个上去——哪怕你从没要求。这类模型惯性必须被显式压制，否则每张图都要手动修一遍。能写出这条规则，说明作者是真的生成过几百张图、被同一个问题烦够了才总结出来的。

五、xiaohei-ip.md：一致性，与一条可证伪的判据

视觉 IP 的价值在于跨内容的复利。读者第一次看到小黑没什么感觉，第五次看到会觉得眼熟，第二十次看到就能在信息流里一眼认出是谁写的。要吃到这份复利，前提是每一张图里的小黑都得是同一个小黑。

形象定义被拆成了可组合的原子特征：黑色实心小怪物、白色圆点眼睛、细腿偶尔有细胳膊、轮廓略微不规则有手绘感、表情空呆冷静认真。身体形态则留了弹性——圆柱、黑豆、黑盒、漏斗、影子、洞口、机器内部的黑块都行。

这个「固定核心特征 + 可变形态」的设计很聪明。完全锁死形态，图像模型在复杂构图里必然做不到，最后就是规则形同虚设；只锁核心识别特征（黑实心 + 白点眼 + 细腿 + 空表情），既保住了辨识度，又给构图留了自由度。

性格描述同样具体：很认真但做的事有点荒诞，像一个低调的系统操作员，冷幽默不卖萌，有点笨拙但不蠢。这几句不是文学修辞，它们直接翻译成了提示词里的deadpan、blank serious expression、not cute、not mascot——每一个形容词都在压制模型把角色画成吉祥物的倾向。

还准备了一个动作库，直接可选：搬运素材、拉线汇聚信息源、卡在断点里、在机器里操作「判断」杆、变成筛选漏斗、切开「素材鱼」、盖章承接话术、牵着承接路径、举警告牌看坑、从洞里伸手但接不住内容、搬砖搭桥开门分拣记录。

真正的点睛之笔在最后：

如果去掉小黑，图的核心隐喻还能完全成立，说明小黑太装饰了；要重写提示词，让小黑成为动作主体。

这是整个 skill 里最像工程的一句话。它把「小黑不能只是装饰」这个模糊的美学要求，变成了一个可执行的反事实测试：

assert remove(小黑, 图) == 隐喻不成立

模糊的规则等于没有规则，因为它无法判定，也就无法驱动返工。「去掉主体后论证是否还成立」这个模式的适用面远超配图——写文章可以问「删掉这一段，结论是否还成立」，做架构可以问「拿掉这个中间层，链路是否还通」。任何一条写进规格的定性要求，都应该配一个能让它失败的测试。

六、composition-patterns.md：结构类型库与反复刻规则

这份文件解决两个问题：图该怎么搭，以及怎么保证每次都是新的。

八种结构类型

先给了一个可枚举的选择集，每种都标注了适用场景和画法：

并且明确要求：选一种就好，不要混太多。

把开放式创作收敛成八选一，是很实际的做法。让模型自由发挥构图，方差极大；给一个有限选择集，输出立刻可控，同时八种类型基本覆盖了技术写作里所有需要图解的场景。这和给 LLM 做结构化输出约束是同一个道理——限制自由度，往往是提升质量最便宜的手段。

三步隐喻生成法

结构类型定了骨架，隐喻决定这张图有没有记忆点。这里给了一个可复用的三步流程：