导读：很多人写 Skill，第一反应是把 Prompt 写得更长、更细、更像咒语。小编看完
ian-xiaohei-illustrations这个项目后，反而更确定一件事：好 Skill 不是提示词仓库，而是 Agent 的工作台设计。
这个项目表面上是在生成“阿魏怪诞正文配图”，但它真正有价值的地方，不只是画风稳定，而是把一个很主观的审美任务拆成了 Agent 可以执行、可以检查、可以迭代的工程流程。
说白了，它不是告诉 AI “画得高级一点”，而是一步步告诉 AI：先读什么、看什么、别看什么、怎么选图、怎么避免复刻、生成后怎么判断失败。
一、先说结论：Skill 不是长 Prompt，而是工作系统
小编以前也见过不少所谓的 Skill，本质上就是一段超长提示词：
你是一个优秀的设计师，请使用高级审美，生成专业、有创意、有冲击力的图片……
这种写法不是完全没用，但问题很明显：它只能提供一种模糊气质，不能控制 Agent 的工作过程。
ian-xiaohei-illustrations 的设计更像一个小型 SOP：
| 模块 | 解决的问题 | 价值 |
|---|---|---|
SKILL.md | 定义什么时候触发、核心定位和工作流 | 让 Agent 先知道自己在干什么 |
style-dna.md | 固定视觉风格和禁忌 | 防止审美漂移 |
awei-ip.md | 固定角色 IP 的职责和边界 | 防止阿魏和小黄点变成装饰物 |
composition-patterns.md | 提供构图类型和原创隐喻方法 | 防止每次都画成 PPT 流程图 |
prompt-template.md | 把策略翻译成生图提示词 | 防止临场自由发挥过头 |
qa-checklist.md | 生成后检查和迭代 | 防止交付劣化但没人发现 |
assets/examples/ | 提供低频风格校准 | 有参考，但不让 Agent 照抄 |
这里小编最喜欢的一点是：它没有把所有知识都塞进一个文件里，而是做了“按需读取”。
这其实很关键。Agent 的上下文不是垃圾桶，什么都塞进去，最后只会互相污染。这个项目把资料拆成几类，让 Agent 在不同阶段读不同材料：要定风格读 DNA，要定角色读 IP，要设计图读构图，要生成图读模板，要验收读 checklist。
一句话判断：好的 Skill，不是把答案写死，而是把 Agent 做事的路线铺出来。
二、当前项目最值得学的 5 个设计优点
2.1 定位非常窄，所以反而稳定
这个项目没有说自己要做“万能插画生成器”，而是把边界钉得很死：
- 中文文章正文配图。
- 16:9 横版。
- 纯白背景。
- 黑色手绘线稿。
- 少量红、橙、蓝中文批注。
- 阿魏或小黄点必须参与核心动作。
- 一张图只讲一个核心结构。
看起来限制很多，但这正是稳定性的来源。
很多 Skill 写不好，就是因为开口太大：既要海报，又要插画，又要流程图，还要品牌 KV，最后 Agent 什么都能做一点，什么都做不稳。
小编更建议大家写技能时先问一句：这个 Skill 到底服务哪一种高频场景？
如果一句话讲不清，Skill 大概率会变成素材堆。
2.2 它没有只定义结果，还定义了失败信号
这个项目的 qa-checklist.md 很有意思，它不只说“好图应该是什么样”，还明确写了失败信号：
- 阿魏或小黄点只是装饰。
- 画面像 PPT。
- 左上角出现“流程图 / 系统架构图”这类标题。
- 文字太多。
- 背景有纸纹、阴影、渐变。
- 和旧案例构图太像。
这个设计非常工程化。
因为 Agent 最大的问题不是不知道什么叫好，而是不知道什么时候应该承认“不够好”。失败信号就是给 Agent 的刹车片。
翻译成软件工程，就是：
| 设计内容 | 工程里的类比 |
|---|---|
| 风格 DNA | 类型定义 |
| Prompt 模板 | 构造函数 |
| 工作流 | 服务编排 |
| QA Checklist | 测试用例 |
| 失败信号 | 断言 |
| 迭代方法 | 修复策略 |
没有 QA 的 Skill，就像没有断言的单测，看起来跑了，实际上不知道对不对。
2.3 它把“审美”拆成了可执行动作
审美最怕抽象词。
比如“高级”“有质感”“有创意”“不要俗”，这些词人类看了都可能各想各的，Agent 更容易乱飞。
这个项目的做法是把审美词拆成具体动作：
主体占画面约 40%-60%
至少 35% 空白
最多 5-8 处中文手写批注
红色只用于重点、问题、提醒或结果
橙色只用于主路径或箭头
蓝色只用于补充说明、反馈或系统状态
不要左上角写类型标题
这些规则不是文学描述，而是可执行约束。
小编觉得这正是 Skill 写作里很重要的能力：把感觉翻译成操作，把偏好翻译成检查项。
你不能只告诉 Agent “别画得像 PPT”，你还要告诉它 PPT 感通常来自哪里：标题、边框、整齐网格、过多箭头、节点太多、大段说明。
这样 Agent 才知道怎么改。
2.4 它保护了原创性，而不是让示例反噬结果
很多 Skill 会放 examples，但 examples 也有副作用。
Agent 很容易看了几个例子后开始复刻，尤其是图像类任务。今天画“信任桥”，明天还是桥；今天画“一鱼多吃”，明天什么主题都切鱼。
这个项目专门写了反复刻规则：
- 示例只用于低频视觉校准。
- 不进入默认生成路径。
- 不要照抄案例构图、物件或标注。
- 同类主题也要换新隐喻。
这点很重要。
示例应该是风格的锚，不应该是创作的牢笼。好的 Skill 要允许 Agent 借鉴密度、留白、颜色、气质，但不能让 Agent 每次都从旧答案里复制一个壳。
小编觉得这里可以沉淀成一个通用原则：
示例负责校准，不负责代替思考。
2.5 它让角色 IP 承担系统职责
阿魏和小黄点这套 IP 不是“放个角色让画面可爱一点”。
项目里反复强调：阿魏或小黄点必须承担核心动作。如果去掉角色，图的核心隐喻还能完全成立，说明角色太装饰了。
这其实是一个很高级的设计判断。
因为很多视觉 IP 最后都会变成贴纸：站在角落、举个牌子、做个表情。看起来有统一角色，实际上没有参与信息表达。
而这个项目要求阿魏和小黄点变成系统操作员：
- 拉线。
- 搬运。
- 分拣。
- 守门。
- 卡在断点里。
- 操作机器。
- 记录反馈。
- 把抽象概念变成一个物理动作。
这样一来，角色就不是装饰，而是信息结构的一部分。
写 Skill 也是一样。一个固定元素如果只是装饰，就会变成噪音；如果它能承担职责，就会变成识别度。
三、这个项目背后的 Skill 写作经验
小编把它总结成 6 条经验，后面我们写任何技能都可以照着检查。
3.1 先写“不要做什么”
很多人写 Skill 喜欢先写能力范围，但小编更建议先写禁区。
这个项目把“不适合做什么”写得很清楚：
- 不做商业插画。
- 不做 PPT 信息图。
- 不做复杂架构图。
- 不做可爱儿童插画。
- 不把大量正文塞进一张图。
能力范围决定 Skill 能去哪，禁区决定 Skill 不会摔到哪。
尤其是生成类任务，禁区越清楚，输出越稳定。
3.2 把工作流写成阶段，而不是写成愿望
一个好 Skill 至少要回答这些问题：
- 输入来了以后，先读什么？
- 读完以后，提炼什么？
- 什么时候只出策略，什么时候直接执行？
- 执行时用什么模板？
- 产出后怎么检查？
- 不合格时怎么修？
- 最后怎么交付？
ian-xiaohei-illustrations 的工作流就是这个思路：
| 阶段 | Agent 要做的事 |
|---|---|
| 消化正文 | 提炼核心观点、转折、流程和视觉锚点 |
| 先出策略 | 输出 shot list，不平均配图 |
| 单张生成 | 每张图只讲一个结构，调用图像模型 |
| 检查迭代 | 按 checklist 找失败信号 |
| 保存交付 | 命名、存路径、说明用途 |
这比“请你根据文章生成配图”稳定太多。
3.3 把主观判断变成小表格
Skill 里最难写的是主观判断。
比如“哪里值得配图”，这件事如果不拆开，Agent 就会平均分配：每隔几段配一张，看似勤快，实际没用。
这个项目用了“认知锚点”这个概念：
- 核心判断。
- 两个断点。
- 输入输出闭环。
- 分流。
- 前后对比。
- 承接路径。
- 常见坑。
- 角色状态变化。
这就把“凭感觉挑段落”变成了“按认知功能挑段落”。
小编建议以后写 Skill，也尽量发明这种中间层概念。它不一定是代码，但它像领域模型一样重要。
3.4 模板要留变量，不要锁死答案
prompt-template.md 做得比较克制。
它没有直接给一堆最终 Prompt，而是留了几个变量：
Theme:
{正文配图主题}
Structure type:
{结构类型}
Core idea:
{这张图要表达的核心意思}
Composition:
{阿魏或小黄点在哪里、正在做什么、主要物件是什么、信息如何流动}
这个设计很好。
模板锁住的是结构，不是答案。Agent 仍然要根据当前文章重新判断主题、结构、核心意思和构图。
如果模板把答案写死，Skill 会稳定，但会僵；如果模板什么都不管，Skill 会自由，但会飘。这里的平衡点就是：固定骨架，开放内容。
3.5 示例要降权，Checklist 要升权
小编看这个项目时，一个很强的感受是：它对 examples 很警惕，对 checklist 很信任。
这其实很符合 Agent 工程的长期维护逻辑。
示例太强，Agent 会模仿；检查太弱，Agent 会自嗨。
所以更好的结构是：
少量示例：校准风格
明确规则：约束方向
强 checklist：判断质量
具体迭代法：修正偏差
这也是为什么这个项目不建议默认打开 assets/examples/。示例放在那里，但不让它主导生成路径。
3.6 交付规则也要写进 Skill
很多 Skill 前面写得很认真，最后交付时又散了。
这个项目连保存路径、命名方式、交付说明都写了：
assets/<article-slug>-illustrations/
01-topic-name.png
02-topic-name.png
这类规则看起来不起眼，但对真实工作很重要。
因为 Skill 不是一次性的 Prompt，它要进入工作流。文件怎么放、怎么命名、是否覆盖、交付时说什么，这些都决定用户能不能继续用。
四、如果我们要写自己的 Skill，应该怎么参考这套经验
小编建议以后写 Skill，可以按这个骨架来：
# Skill 名称
## 核心定位
一句话说明：服务谁、解决什么任务、不解决什么任务。
## 先读这些参考
- references/domain.md：领域概念。
- references/style.md：风格和语气。
- references/workflow.md：执行流程。
- references/templates.md：输出模板。
- references/qa-checklist.md：验收标准。
## 工作流
### 1. 读取输入
说明 Agent 要提炼哪些信息。
### 2. 产出策略
说明什么时候先给方案，什么时候直接执行。
### 3. 执行任务
说明使用哪些工具、模板、约束。
### 4. 检查与迭代
列出失败信号和修复方法。
### 5. 交付
说明文件路径、命名、最终回复口径。
## 安全规则
说明不能做什么、什么时候必须问用户确认。
但只套格式还不够。真正要学的是背后的设计方法。
| 写 Skill 时的问题 | 可以参考当前项目的做法 |
|---|---|
| 任务太大 | 缩成一个具体高频场景 |
| 输出不稳定 | 写清楚风格 DNA 和禁区 |
| Agent 不知道怎么开始 | 写阶段化工作流 |
| Agent 只会套模板 | 增加“当前输入提炼”步骤 |
| 结果像旧案例 | 写反复刻规则 |
| 质量难判断 | 写 QA checklist 和失败信号 |
| 交付混乱 | 写保存路径、命名、回复格式 |
小编自己的经验是，Skill 最好不要从“我要让 AI 做什么”开始写，而要从“一个熟练的人类会怎么做这件事”开始写。
人类会先看材料，会判断重点，会知道什么时候别做，会看出哪里俗，会返工，会保存文件，会告诉用户哪张最稳。
Skill 要写的就是这些。
五、最容易踩的坑：把 Skill 写成咒语，而不是系统
如果我们照着这个项目继续写技能，最该避免 4 个坑。
5.1 只写审美词，不写可执行规则
不要只写：
做得高级、有质感、有创意。
要写成：
主体占画面 40%-60%，保留大块留白，最多 5 个短标签，不使用渐变和阴影。
5.2 只写结果，不写过程
不要只写“输出一篇好文章”。
要写清楚：
- 怎么读输入。
- 怎么选结构。
- 怎么处理缺失信息。
- 怎么检查 AI 味。
- 怎么交付 Markdown。
5.3 只给示例，不给边界
示例越多，越要写反复刻规则。
否则 Agent 会把示例当答案，把风格当模板，把模板当命令。
5.4 只写成功样子，不写失败样子
失败样子必须写。
因为 Agent 很需要明确的“不像这个”。有时候一句“不要像 PPT”，不如写清楚：
- 不要左上角大标题。
- 不要整齐网格。
- 不要密集箭头。
- 不要节点说明书。
- 不要把结构类型写在图上。
这样才真的能改。
六、最后：好 Skill 是把经验变成可复用的判断
小编看完这个项目，最大的收获不是“原来阿魏正文配图可以这么写 Prompt”。
真正的收获是：一个好 Skill，要把创作者脑子里的隐性经验，拆成 Agent 可以执行的判断链。
这里面有定位，有禁区，有阶段，有模板，有检查，有迭代，也有交付规则。
它不是把 Agent 当成许愿机，而是把 Agent 当成一个需要工作台的新同事。你不给它工具、流程、验收标准，只让它“发挥一下”，它当然会漂。
以后我们写技能，也可以照这个方向走：
- 先把场景缩窄。
- 再把好坏标准写清。
- 把人类专家的动作拆成步骤。
- 把主观偏好翻译成可检查规则。
- 把示例降权，把 QA 升权。
- 最后把交付路径也标准化。
总结：Skill 的本质，不是提示词写得多厉害，而是把一次成功经验，沉淀成下一次还能稳定复用的工作系统。