1. 这个开源库到底在解决什么问题
做 AI 视觉创作的人大概都有过这种体验：某天调出一组特别满意的提示词，出图效果惊艳，赶紧截图存到相册里。过两周想复用，翻遍手机相册和聊天记录，只找到一张缩略图，参数全丢了。再后来学乖了，开始用笔记软件记，但记着记着就乱了——这个提示词是给 Midjourney 用的还是给 Stable Diffusion 用的？那个风格参考图放在哪个文件夹？换了台电脑，环境又得重搭一遍。
我前后折腾了差不多一年半，攒下来的图片超过一千张，提示词笔记散落在四五个地方。直到有次帮朋友做一组产品概念图，明明记得之前出过类似风格，硬是找了两个小时没找到，最后重新试了一下午。那次之后我下定决心，把所有东西整理成一个结构化的开源库。
这个库现在包含三个核心部分：上千张经过筛选的参考图片、30 条完整的案例记录、10 个可以直接复用的 Skills。它不是那种“收集了 5000 个提示词”的合集包，而是一套有组织、有分类、有上下文的方法论沉淀。每条案例记录都包含原始需求、迭代过程、最终参数和踩坑备注；每个 Skill 都封装了一类特定任务的完整工作流，从输入到输出有明确的定义。
适合谁来参考？如果你是刚接触 AI 视觉创作的新手，可以把它当作一本“带图例的菜谱”，照着案例一步步做就能出效果；如果你已经有一定经验，Skills 部分可能更有价值，它把零散的操作固化成了可复用的模块，能帮你把工作流标准化。哪怕你只是好奇 AI 视觉创作到底怎么回事，翻翻那 30 条案例记录也能有个直观感受。
2. 整体架构设计与分类逻辑
2.1 为什么选择“图片+案例+Skills”三层结构
一开始我只想整理提示词，但很快发现纯文本的提示词库有个致命问题：脱离具体模型和参数，提示词就是一堆没有意义的词。同一个提示词在 Flux 和 SDXL 上出来的效果可能天差地别，步数、CFG、采样器不同，结果也完全不一样。所以图片必须作为锚点存在，它记录了“这个提示词在这个配置下实际长什么样”。
但光有图片也不够。一张好看的图背后往往经历了多次迭代，第一次出的图构图好但光影不对，第二次调了光影但风格跑偏了，第三次才达到满意效果。如果只放最终成品，别人根本不知道中间发生了什么。所以案例记录要保留迭代过程，把“怎么从 A 走到 B”讲清楚。
Skills 则是更高一层的抽象。当你做了足够多案例之后，会发现某些任务类型反复出现，比如“把草图变成写实渲染”“给产品图换背景并保持光影一致”“生成一组风格统一的角色设定”。这些任务有固定的流程和参数范围，完全可以封装成独立的模块。三层结构从具体到抽象，从素材到方法再到工具，形成了一个完整的闭环。
2.2 分类维度的选择与取舍
分类这件事我改了至少五版。最初按模型分——Midjourney 一类、SD 一类、Flux 一类。但很快发现不行，因为同一个需求可以用不同模型实现，按模型分会导致内容割裂。后来试过按风格分——写实、插画、3D、像素风。这个方案用了两个月，问题在于风格边界太模糊，一张图可能同时具备写实和插画特征，归类时非常纠结。
最终确定的分类维度是任务类型，具体分为六类：角色与人物、场景与环境、产品与商业、风格化转换、文字与排版、实验性探索。这个分类的好处是每个案例都有明确的任务目标，检索时直接按“我要做什么”来找，而不是按“这是什么风格”来猜。比如你要做一张产品海报，直接进“产品与商业”分类，里面所有案例都是围绕产品展示、商业修图、广告构图展开的。
每个分类下的案例记录遵循统一模板：需求描述、初始提示词、首轮出图问题分析、迭代调整记录、最终参数、可复用要点。这个模板是经过反复打磨的，早期版本没有“首轮出图问题分析”这一项，后来发现这一步恰恰是最有价值的——它记录了“什么不行”以及“为什么不行”，比单纯记录“什么行”更有参考意义。
2.3 图片筛选标准与元数据管理
上千张图片不是随便存的。每张进入库里的图都要过三道筛选：技术合格（无明显畸变、崩坏、伪影）、风格典型（能代表某一类提示词或参数配置的典型效果）、可复现（参数记录完整，换台机器也能出类似结果）。三道筛下来，淘汰率大概在 60% 左右，也就是说每存 10 张图，背后至少有 25 张被删掉了。
元数据管理用的是最笨但最可靠的方法：文件名即索引。每张图的命名格式是“分类编号-案例编号-迭代序号-模型标识”，比如C03-012-04-flux表示产品商业类第 12 个案例的第 4 次迭代，使用 Flux 模型生成。配套的 Markdown 文件里记录完整参数和备注。这样做的好处是不依赖任何数据库或专用软件，用文件管理器就能检索，迁移和备份也极其简单。
提示：不要用中文文件名，跨平台同步时容易出编码问题。分类编号用字母加数字的组合，比如 C 代表 Character，S 代表 Scene，P 代表 Product，这样在文件列表里排序时天然按类别聚拢。
3. 30 条案例记录的完整拆解
3.1 案例记录的标准模板与字段说明
每条案例记录都是一个独立的 Markdown 文件，包含以下字段：
| 字段名 | 说明 | 是否必填 |
|---|---|---|
| 案例编号 | 分类字母+三位数字，如 C012 | 是 |
| 任务类型 | 从六个分类中选择 | 是 |
| 原始需求 | 一句话描述要做什么 | 是 |
| 初始提示词 | 第一版尝试的完整提示词 | 是 |
| 首轮问题 | 第一版出图的具体问题 | 是 |
| 迭代记录 | 每次调整的内容和效果变化 | 是 |
| 最终参数 | 模型、步数、CFG、采样器、种子等 | 是 |
| 可复用要点 | 从这个案例中提炼的通用经验 | 是 |
| 参考图 | 关联的图片文件名 | 否 |
这个模板看起来简单，但每个字段都有讲究。“原始需求”必须用自然语言写，不能用专业术语堆砌，因为它的作用是让你日后能通过搜索日常用语找到这个案例。“首轮问题”要具体到“左手手指数量不对”这种程度，不能写“手部有问题”这种模糊描述。
3.2 从需求到出图的完整迭代实录
拿一个具体案例来说。需求是“生成一张咖啡店老板在吧台后擦拭杯子的写实照片，暖色调，有生活气息”。初始提示词写的是：
a coffee shop owner wiping a cup behind the counter, warm tone, lifestyle photography, realistic首轮出图问题很明显：人物面部模糊、杯子形状扭曲、背景里出现了不存在的第二个人。分析原因，主要是提示词太笼统，模型不知道“coffee shop owner”应该长什么样，也不知道“wiping a cup”的具体动作细节。
第二轮调整，加入了外貌描述和动作细节：
a middle-aged man with short brown hair and a beard, wearing a dark green apron, wiping a white ceramic cup with a cloth, behind a wooden counter, warm afternoon light from window, coffee shop interior, lifestyle photography, realistic, 50mm lens这一版人物清晰了，但光影方向不对，窗户光从左边来，但人物脸上的高光在右边。第三轮加入光影控制词：
... warm afternoon light from window on the left side, soft shadow on the right side of face ...同时把采样器从 Euler 换成 DPM++ 2M Karras，步数从 20 提到 30。最终出图达到了可用状态。整个迭代过程记录在案，包括每次调整后的问题变化和参数修改。
3.3 案例之间的交叉引用与知识网络
30 条案例不是孤立的。每条案例的“可复用要点”字段会引用其他相关案例。比如咖啡店老板这个案例的要点里写了：“光影方向控制方法参见 P008 产品布光案例；人物面部细节增强技巧参见 C003 角色特写案例。”这样就形成了一个知识网络，读者可以从一个案例跳到另一个案例，逐步深入。
我还维护了一个索引文件，按“问题类型”而不是“任务类型”重新组织所有案例。比如“手部崩坏”这个问题在 C001、C005、C012 三个案例中都出现过，索引文件会把它们列在一起，方便针对性查阅。这个索引是手动维护的，每新增一个案例就更新一次，虽然费时但非常值得。
注意：不要试图用自动化工具生成索引，因为“问题类型”的判断需要人的理解。比如“手指数量不对”和“手指关节角度不自然”是两类问题，但机器可能归为一类。手动维护虽然慢，但准确度高得多。
4. 10 个可复用 Skills 的设计与实现
4.1 Skill 的封装标准与接口定义
一个 Skill 要满足三个条件才能进入库中：有明确的输入输出、在至少 5 个不同案例中被验证有效、参数范围有清晰的边界。比如“草图转写实渲染”这个 Skill，输入是一张草图图片和风格描述，输出是写实渲染图，参数范围包括重绘幅度 0.45-0.65、ControlNet 权重 0.8-1.0、采样步数 25-35。
每个 Skill 的文档结构是：功能描述、适用场景、输入要求、参数配置表、操作步骤、输出示例、边界条件、常见问题。参数配置表里会列出每个参数的建议范围、极端值和调整效果。比如重绘幅度低于 0.4 时草图痕迹过重，高于 0.7 时原始构图丢失，0.5 左右是平衡点。
4.2 核心 Skill 拆解：草图转写实渲染
这个 Skill 是我用得最多的一个。完整流程分四步：
第一步，草图预处理。把草图转成黑白线稿，对比度拉到最高，去掉所有灰色过渡。这一步很多人会忽略，但实测下来，干净的线稿能让 ControlNet 的识别准确率提升至少 30%。用任何图像编辑软件都能做，阈值调整到线条清晰、背景纯白即可。
第二步，ControlNet 配置。用 Lineart 或 Canny 模型，权重设在 0.85-0.95 之间。权重太低草图约束不够，出来的图跟草图没关系；权重太高画面会显得僵硬，像描图。预处理器分辨率要和输出分辨率匹配，比如输出 1024x1024，预处理器也设 1024。
第三步，提示词编写。提示词分三部分：主体描述、风格描述、质量描述。主体描述要具体到材质和光照，比如“matte ceramic surface, soft diffused lighting”而不是“nice material”。风格描述用艺术家名字或流派名称，但不要堆砌超过三个，否则风格会混乱。
第四步，迭代调整。第一轮出图后重点看三个地方：整体构图是否与草图一致、材质表现是否符合预期、光影逻辑是否合理。每次只调一个参数，调完记录效果变化。通常 3-5 轮能达到满意效果。
4.3 Skill 之间的组合与编排
单个 Skill 解决单一问题，但实际任务往往需要多个 Skill 串联。比如“生成一组风格统一的角色设定图”这个任务，需要用到“角色一致性控制”Skill、“风格锁定”Skill 和“批量生成与筛选”Skill。我在库中记录了这些组合方案，命名为“工作流配方”。
一个典型配方是“产品图换背景并保持光影一致”：先用“主体抠图”Skill 分离产品，再用“背景生成”Skill 创建新背景，最后用“光影匹配”Skill 调整产品光照使其与新背景融合。每个 Skill 的输出是下一个 Skill 的输入，形成流水线。配方文档里会标注每个环节的耗时和常见失败点，比如光影匹配环节最容易出现“产品像贴上去的”问题，解决方案是加入环境光反射和接触阴影。
提示：Skill 组合时要注意参数传递。比如“主体抠图”输出的蒙版边缘羽化值会直接影响“光影匹配”的效果，羽化太小边缘生硬，太大细节丢失。建议羽化值设在 2-4 像素之间，根据输出分辨率等比调整。
5. 实操中踩过的坑与排查技巧
5.1 提示词写了但模型不执行的典型原因
最常见的问题是“提示词里写了但出图完全没有体现”。比如写了“red dress”，出来的是蓝色裙子。排查思路按优先级排列：
第一，检查提示词权重。有些模型对靠前的词权重更高，如果把“red dress”放在第 20 个词的位置，很可能被忽略。把它移到前五个词的位置试试。
第二，检查负面提示词冲突。如果负面提示词里有“blue”或者“cold color”，可能会压制红色表现。把负面提示词精简到只保留必要的质量排除项。
第三，检查模型本身的能力边界。有些模型对颜色属性的绑定能力弱，尤其是当颜色词和物体词距离较远时。这时候需要把“red dress”写成一个整体概念，比如“a dress that is red”或者用括号强调“((red dress))”。
第四，检查 CFG 值。CFG 太低（低于 5）时模型对提示词的遵循度下降，太高（高于 15）时画面容易过饱和和崩坏。7-11 之间是比较稳妥的范围。
5.2 画面崩坏与结构错误的修复路径
手部崩坏、肢体扭曲、物体融合是 AI 视觉创作的老大难问题。我的修复路径分三步：
第一步，局部重绘。用 Inpainting 功能只重绘问题区域，提示词里加入详细的手部描述，比如“five fingers, natural hand pose, relaxed”。重绘幅度设在 0.5-0.7 之间，太低没变化，太高会改变周围区域。
第二步，ControlNet 辅助。如果局部重绘多次仍不理想，用 OpenPose 或 Depth 模型给手部一个明确的结构约束。找一张手部姿势正确的参考图，提取姿态骨架，然后重新生成。
第三步，后期修复。如果前两步都搞不定，把图导入图像编辑软件手动修复。这不是认输，而是效率选择。有时候手动修 5 分钟比调参数调两小时更划算。
5.3 常见问题速查表
| 问题现象 | 可能原因 | 排查顺序 | 解决方案 |
|---|---|---|---|
| 出图与提示词无关 | 提示词权重低/CFG 太低/模型不匹配 | 1.调词序 2.调 CFG 3.换模型 | 核心词前置，CFG 设 7-9 |
| 画面过饱和/崩坏 | CFG 太高/步数太少 | 1.降 CFG 2.加步数 | CFG 降到 7，步数加到 25+ |
| 人物面部模糊 | 分辨率不足/面部修复未开 | 1.开面部修复 2.提高分辨率 | 用 ADetailer 或类似工具 |
| 风格不统一 | 提示词风格词冲突/种子不同 | 1.精简风格词 2.固定种子 | 风格词不超过 3 个，固定种子 |
| 光影方向错误 | 光影描述不明确/无方向词 | 1.加方向词 2.加阴影描述 | 明确写“light from left/right” |
| 手部结构错误 | 模型能力限制/无结构约束 | 1.局部重绘 2.ControlNet | 用 OpenPose 约束手部 |
5.4 参数调整的边际效应与停止时机
调参这件事有个规律：前 20% 的调整带来 80% 的效果提升，后 80% 的调整只带来 20% 的提升。很多人陷入“再调一下可能更好”的循环，结果花了大量时间但效果提升微乎其微。
我的经验是设定明确的停止条件。比如：连续三次调整后效果没有明显改善，就停止；单张图调参时间超过 15 分钟，就接受当前结果或换方案；如果问题需要超过三个 Skill 组合才能解决，考虑这个需求是否值得继续。这些停止条件帮我节省了大量时间，也避免了“调参调到怀疑人生”的情况。
注意：停止调参不等于放弃质量。如果当前结果离可用标准差很远，应该回到需求层面重新思考——是不是提示词方向就错了？是不是应该换一个模型或方法？有时候推倒重来比修补更快。
6. 开源库的维护与扩展思路
6.1 文件组织与版本管理
库的目录结构保持扁平，最多两层。根目录下按分类建文件夹，每个文件夹里直接放图片和对应的 Markdown 文件，不再嵌套子文件夹。这样做的好处是路径短，在命令行和脚本里操作方便。版本管理用 Git，每次新增案例或修改 Skill 都提交一次，commit message 写清楚改了什么。
图片文件用 Git LFS 管理，避免仓库体积膨胀。Markdown 文件直接进 Git，方便 diff 和追溯。每季度做一次清理，把重复的、质量下降的、被更好案例替代的内容删掉。开源库的价值在于质量而非数量，一千张精选图比一万张杂乱图有用得多。
6.2 社区贡献与质量控制
库开放了贡献通道，但设置了明确的门槛。贡献者需要提交完整的案例记录，包括原始需求、迭代过程和最终参数，缺一不可。提交后我会跑一遍复现流程，确认参数能出类似效果才合并。这个流程虽然慢，但保证了库的整体质量。
质量控制的关键是可复现性。同一个案例，换一个人、换一台机器，按照记录的操作能出 80% 相似的结果，才算合格。如果只有原作者能复现，那这个案例就没有参考价值。所以每条案例记录里都尽量写清楚硬件环境、软件版本和随机种子，减少不确定性。
6.3 后续扩展方向与迭代计划
接下来打算做三件事。第一，增加视频生成相关的案例和 Skill，现在视频模型越来越成熟，但系统化的方法记录还很少。第二，建立提示词片段的模块化库，把常用的描述词按功能分类，比如“光影类”“材质类”“构图类”，写提示词时直接拼装，提高效率。第三，做一套自动化测试工具，输入案例参数后自动跑图并对比相似度，帮助贡献者自查。
这些扩展都围绕一个核心原则：降低复现门槛，提高方法可迁移性。AI 视觉创作的工具和模型更新很快，但底层的方法论和排查思路是相对稳定的。把稳定的部分沉淀下来，变化的部分保持开放，这个库才能持续有价值。
我个人在实际操作中的体会是，整理和记录这件事本身就在提升创作能力。当你被迫把“感觉这样更好”转化为“因为 A 所以调 B 得到 C”，你对整个流程的理解会深刻得多。这个库最大的受益者其实是我自己，它逼着我从“凭感觉调参”变成“有逻辑地解决问题”。如果你也在做类似的事情，建议从今天开始记录，哪怕只记一条，三个月后回头看会感谢自己。
