最近一段时间，我一直在给寒柳别苑换背景图。
这件事听起来不像一个很复杂的工程：白天和夜晚各画一张，保持同样的像素风、同样的院落关系，再把它们放进网页里就可以了。
真正开始做以后，问题很快就出现了。
我说“保持原来的风格”，模型可能理解成更明亮的游戏概念图；我说“低机位”，它有时又把镜头拉成俯视地图；我要求只修改右下角的小房间，它可能顺便改掉屋檐、树和院墙。每一张图单独看都不一定难看，但放在同一个网站里，就会明显感觉不是来自同一个世界。
于是我开始做 OhMyStyle↗。
它不是一个新的生图模型，也不是一个把一句 Prompt 变得更长的词库。更准确地说，它想做的是：把“风格”从一句模糊的形容词，整理成一组可以研究、复用、组合和检查的工程对象。
风格不是几个形容词
平时我们描述画面，往往会说：
像素风、电影感、低饱和、暖光、东方庭院。
这些词可以帮助人快速沟通，却还不足以让不同的人或不同的模型稳定地复现画面。它们没有说明：
- 画面究竟使用什么媒介和表面质感；
- 光线从哪里来，阴影应该有多重；
- 镜头是平视、低机位还是俯视；
- 物体边缘是硬切、柔化还是带有颗粒；
- 哪些内容属于稳定的视觉规则，哪些只是某一张参考图里的具体物件。
如果这些东西没有被拆开，所谓“风格一致”就只能靠每次重新碰运气。
OhMyStyle 的第一个想法，就是不要直接把风格写成一段散文，而是给它建立一份结构化档案。
仓库 README 中展示的“高纯度撞色”代表图：主体很简单，但高纯度互补色、背景反底和面积比例之间的关系已经足够清楚。
一个风格包应该说明什么
一个正式的风格包大致会包含这些内容：
style-packages/<category>/<id>/├── package.yaml├── identity.yaml├── visual-signature.yaml├── reproduction.yaml├── relations.yaml├── palette/palette.json├── prompts/base.txt├── prompts/negative.txt├── evaluation.yaml├── references/manifest.csv├── provenance.yaml├── resource.yaml├── examples/├── gallery-16x9.jpg└── README.md / README.en.md这里最重要的不是文件数量，而是它们分别回答了不同的问题。
visual-signature.yaml 描述这个风格稳定的视觉特征，reproduction.yaml 记录怎样把这些特征重新组织到画面里，palette.json 负责色彩角色，evaluation.yaml 则把“看起来对不对”变成一组可以检查的标准。
来源和权利边界也不再被放在文章末尾当作补充说明，而是有自己的 references/manifest.csv 和 provenance.yaml。如果某张参考作品不能直接放入仓库，就只保留来源链接和描述，不把它悄悄打包进来。
这让我觉得它更像一个小型的视觉设计系统，而不是一个图片收藏夹。
主体应该和风格分开
做风格包时，我特别在意一件事：风格描述的是“如何呈现”，而不是“每次画什么”。
所以基础 Prompt 需要保留主体占位符，例如：
Subject: {SUBJECT}Location: {LOCATION}
Use the package's material, lighting, palette, spatial and edge rules.Keep the subject open and replaceable.如果一个叫“某某游戏美术”的包，每次都自动生成同一个角色、同一座桥、同一片森林，那它保存的其实是内容模板，而不是可迁移的视觉规则。
对于寒柳别苑来说，这个区分很实际。我要的是“同一座院子里的书桌、石桌和夜色”，而不是让每一张图都重新生成一座看起来相似但彼此没有物理关系的中式庭院。只有把主体、空间关系和画面语言分开，才有可能继续修改其中一部分而不牵连全部。
一个具体例子：把主体换成女模特
比如使用“高纯度撞色”这个包时，主体可以换成一位女模特。风格包并不需要知道她是谁，也不需要把“女模特”写进自己的固定规则里；它只负责控制高纯度互补色、背景反底、面积比例、干净构图和清晰的材质区分。
仓库“高纯度撞色”风格包中的完整竖版示例；它用于展示人物、服装和背景之间的撞色关系，不是某一幅原作。
同一个包也可以继续换成椅子、产品、建筑或一张网页海报。真正应该保持的是视觉签名，而不是某一种人物、姿势或道具。
从来源研究到可以运行的 Prompt
OhMyStyle 目前按艺术家、摄影师、艺术流派与历史时期、设计学校、工艺与媒介、游戏美术、原创预设等方向组织风格包。主画廊只是入口，真正的工作发生在每个包自己的研究和说明里。
一个新包的流程大致是：
研究来源 ↓提取跨主题稳定的视觉规则 ↓建立风格包与 Prompt ↓生成代表图和测试样例 ↓人工审核与资源校验 ↓进入画廊和注册表这条流程里，“研究来源”并不是为了给生成结果贴一个响亮的名字，而是要确认参考作品来自哪里、权利状态是什么，以及哪些特征真的能从不同作品中反复观察到。
在世艺术家、摄影师和游戏美术尤其需要谨慎。项目只描述可以观察到的非排他性特征，不把生成样例说成原作，也不暗示存在合作或授权关系。
我希望这个项目以后能让“参考某种视觉语言”变得更诚实：可以讨论构图、光线、材质和边缘，但不要把一张具体作品的内容偷换成一个可无限复制的按钮。
风格还可以组合
有些画面本来就不是单一来源：前景可能需要 RPG 像素美术，背景想要某种油画的空气感，光线又希望接近室内摄影。
因此 OhMyStyle 把交叉风格单独拿出来，不把它们伪装成新的独立风格包。目前设计了三种组合方式：
stack：不同包分工负责媒介、光线、色彩、前景或背景；blend：按权重融合不同风格的视觉特征；contrast：让不同区域有意识地承担不同的视觉语言。
这比把一串艺术家名字直接拼进 Prompt 更容易解释。组合关系是显式的，谁负责什么、哪些地方可能冲突，都可以写进文档和评估里。
项目还生成了一个视觉特征索引。它不改变按来源组织的主画廊，而是允许用户反过来按问题寻找风格：柔和自然光、深暗戏剧光、印刷颗粒、像素网格、霓虹城市，或者低多边形与体素等。
这其实更接近我使用风格库时的真实方式。我通常不是先想“我要用哪位艺术家”，而是先想“我需要一种不抢主体的阴天光”或者“我需要一种能保留空间关系的像素场景”。
目前它还不是什么
我不想把 OhMyStyle 写成一个已经解决了生图一致性的问题。
风格包只能提供更清楚的约束，不能让模型突然变得绝对稳定。不同模型对同一组 Prompt 的理解仍然不同，局部编辑也可能破坏原本的几何关系。代表图看起来合格，也不等于所有主体都能通过测试。
另外，仓库里保留了原项目兼容用的 110 个 style.json 预设。它们和新的结构化风格包是两套维护边界，不能把所有旧预设都说成是 OhMyStyle 从零创作的内容。现在主画廊展示的是独立风格包，旧预设则继续承担兼容和迁移的作用。
截至这篇文章写下时，主仓库已经整理了 220 个风格包，并保留了这套兼容目录。数量很大，但数量本身不是项目的核心指标。更重要的是，一个包是否有清楚的来源、主体边界、可复现规则和失败边界。
回到寒柳别苑
我做 OhMyStyle 的直接原因，仍然是那些背景图。
当我说“右下角的小房间改成会客间”时，真正想保留的并不是一张图的像素，而是一个空间：它在院子的右下角，有自己的屋檐、门、桌子和访客簿；白天可以摆茶具，晚上可以放礼物和信件，但它仍然属于同一座寒柳别苑。
这让我意识到，视觉一致性不只是颜色一致，也不只是“像不像某种画风”。它还包括机位、尺度、物理关系、光线逻辑，以及哪些东西应该被保留、哪些东西才允许变化。
OhMyStyle 现在只是一个正在生长的工具库，但它给了我一个更具体的工作方式：先把“我想要什么”拆成可以观察的规则，再让模型去生成；生成以后，不只看单张图片好不好看，还要检查它是否仍然遵守原来的世界。
如果以后这个项目真的能让更多人少写一点模糊的“高级感”，多写一点可验证的构图、光线和材质规则，那它就算完成了它最初的目的。