AI 绘画卡在“找姿势”？这个中文图库 4 天拿了 4,500+ star

feasibility.

497人浏览 · 2026-11-02 20:00:00

feasibility. · 2026-11-02 20:00:00 发布

部分数据截至 2026-11-01 凌晨：Star 4,559 / Fork 1,154（GitHub）

一、先看现象

10 月 27 日，GitHub 上多了一个新的仓库：anhao/ai-pose-gallery-zh。

它做的事情听起来没什么意思：把日本画师ギア（@giaaibusi）发布的三套 AI 绘画参考图库（姿势、服装、人像）从日文翻译成中文，镜像到本地，做成一个静态网页。没有训练模型，没有生成算法，甚至没有后端——零依赖的单页应用，托管在 Cloudflare 上。

趋势站 rising.dev 留住了它第一天的样子：10 月 27 日 23:15（UTC），8 次提交，316 颗星。

AI 姿势参考库主界面

四天之后，GitHub API 的读数是 4,559 颗星、1,154 个 fork。这是 API 的瞬时值，第三方追踪站的快照有滞后，packages.md 还留存着它 10 月 29 日之前"HTML、2,357 星"的旧记录。

四天大的项目证明不了什么宏大叙事，但当切片看，它值得写。

二、四天里，它迭代了三轮

看这个仓库的 commit 历史。

时间	Commit	内容
10-27 12:24	`ab6e0bc`	初始化：1439 条姿势记录完整汉化，零依赖单页画廊
10-29 12:51	`ec5aa4c`	新增 `skills/` 下 5 个 Agent 技能（Co-Authored-By: Claude Opus 5.5）
10-31 01:13	`8e88282`	升级三合一 AI 角色参考与合成工作台 (v2.0)
10-31 09:29	`74b2a0b`	新增原生 ComfyUI 插件（`custom_nodes`，三合一可视化选图器）
10-31 11:35	`6cf667e`	README 同步 v2 截图与数据

从 v2.0 到 ComfyUI 插件再到 README 更新，前后不到十二小时。你在搜索引擎缓存或第三方站看到的"零依赖静态画廊"，是 10 月 29 日之前的主分支状态。

"爆火 → 升级"这个顺序很关键：先用静态画廊验证有没有人要看，再一轮轮往上加功能。star 数是市场投票，作者接住了票——人们要的从来不只是图，而是以图为起点的整条生产线，作者正在往这个方向试探。

作者四天改了 README 八次，仓库标题和描述字段却还写着"零依赖静态画廊"。门牌没换，房子翻修了三遍。

AI 角色合成台

手机端界面

三、它是什么：一座 8,690 张图的参考仓库

按 README v2.0（commit 8e88282）的自述：

图库	体系划分	记录数	图片数
姿势库	全身标准 (365) / 全身性感 (399) / 上半身 (400) / 双人 (275)	1,439	2,878
服装库	春夏秋冬 / 内衣睡衣 / 泳装 / 礼服等共 8 类	1,407	2,814
人像库	正脸参考 (893) / 造型氛围 (606)，按发长与 51 种细分发型组织	1,499	2,998
合计	三大库全中文索引	4,345	8,690

所有元数据被完整翻译为中文：动作体系、姿势分类、服装款式、51 种细分发型，支持按体系、动作分类、视角（正面/斜前/侧面/背面/俯视）筛选，一键下载原图。

它解决的痛点很具体：做 AI 人物图时，"找到一个合适的姿势并准确描述它"是整条链路里最容易卡住的一环。提示词能写清"一个穿红裙子的女孩"，但写不清"胯部侧顶、背部后仰的 S 形站姿"。三个独立的日文参考站能长期存在、汉化镜像能在四天内拿到四千多颗星，这就是关注度的直接证据。

四、解剖：四个接口，成熟度不同

这个仓库有四个接口，但成熟度并不相同，值得分层看。

图库是数据资产本身：8,690 张高清图、全中文元数据、检索筛选下载一应俱全，多数访客用到的应该就是它。

Web 合成台是给人操作的一层：核心是"3+N 配方"——人像定脸、服装定穿搭、姿势定动作，叠加任意附加参考图；直连 Gemini、GPT Image、阿里百炼 Qwen、字节火山方舟 Doubao 与本地 ComfyUI 共 5 条生图通道。这部分我依据的是 README 的功能描述，没有逐一实测。

ComfyUI 插件（commit 74b2a0b）是给工作流的一层。本仓库的 comfyui_plugin/ 目录下有完整的节点代码（nodes.py 13.7 KB，可直接查看），git clone 到 custom_nodes 后画布上多出 4 个节点（姿势 / 服装 / 人像 / 三合一配方），内置可视化选图器。插件之外，社区里也有第三方开发者基于这个图库做的外挂节点包——这个图库已经有人在它外围补工具了。

Agent Skills（commit ec5aa4c）是给 AI 的一层：skills/ 目录下 5 个 SKILL.md，装到 Claude Code 里，Agent 就能按"姿势名 + 视角"检索白模图。它成立的前提是 Agent 生图成为常规工作流，这个前提本身还在形成中。

同一批数据，以四种方式被使用：人浏览、人操作、工作流调用、智能体调用。

五、从 ControlNet 到多图参考：不是替代，是叠加

AI 绘画处理姿势，今天有两条路线。一条是 ControlNet 系（OpenPose、Depth、Canny）：把姿势当作控制信号，提取骨架、接入控制网络、调权重。另一条是 多图参考：新一代图像模型原生支持一次吃多张参考图，这张给脸、那张给衣服、另一张定动作。

后者取代前者的说法不成立。ControlNet 在严格构图、精确空间关系的场景里仍然不可替代——多图参考给出的是"语境"，不是"约束"；它能告诉模型"参照这个姿势"，但不能保证骨骼关节的位置分毫不差。两条路线是叠加关系：需要精确控制时走 ControlNet，需要语义融合时喂参考图。

"喂参考"作为标准能力，依据在模型侧：字节跳动 Seedream 4.0 的技术报告（arXiv:2509.20427）把多图参考（multi-image reference）列为模型原生能力——火山引擎和 Google 的图像 API 同样把参考图作为一等输入参数。这个变化对使用者的意义很直接：以前你要提取骨架、调 ControlNet 的权重和预处理器；现在你把三张参考图拖进对话框就行。这个仓库做的不是发明，而是给新标准能力补齐前端和数据。

六、三个绕不过去的问题

版权的锚并不稳。 MIT 只覆盖 src/、comfyui_plugin/、scripts/ 这些代码，所有图片与原始数据的著作权归原作者ギア所有。README 的态度是清楚的——"仅为汉化学习与前端工程实践存档，不对图片主张任何权利"。但态度清楚不等于版权稳定：原站如果关闭或改变授权，这个四千多星的仓库会失去锚点。"搬运 + 汉化"模式的可持续性，从第一天起就存在问号。

内容分级不能省。 图库目前只支持女生形象，而且包含成人向姿势与性感穿搭分类。

"参考数据是基础设施"这个说法有一个内在矛盾。 基础设施意味着开放、可及、权属清晰、供应稳定；而这批数据权利集中在个人创作者手里，供应依赖原站的存续。与此同时，关注它的规模已经按基础设施的量级在涨：四千多颗星、一千一百余个 fork、多家第三方追踪站持续收录。供给还是"个人存档"的形态——这个错位是这类项目内生的张力。

七、实测

在线版

使用百炼出现bug：[Qwen] Failed to download image URL after retries. [Qwen] 重复尝试后仍无法下载该图片的 URL。

用火山方舟也出现bug：[Doubao] 请求中指定的`sequential_image_generation`参数无效：当前模型不支持该参数。请求编号：

笔者猜测是项目没跟上百炼和火山方舟的api参数，在线版只能等作者修复，而本地部署的话是可以自行修复。

本地部署

执行git clone https://github.com/anhao/ai-pose-gallery-zh.git克隆项目，然后执行cd ai-pose-gallery-zh进入项目，并执行pnpm install（需提前安装pnpm）安装依赖项，最后执行pnpm dev启动。

但是在使用过程出现bug，这里让ai直接修复，详情见附录的本地部署问题修复记录。

结语

回看这个仓库的四天：零依赖静态站验证了有人要看，四千多颗星确认了市场，功能在一周内从画廊翻成了图库、合成台、插件和技能包。

模型已经会画画了，难的是让它画你脑子里那张。这个仓库把"找参考"这件最烦的事变成了逛图库——这大概就是它四天拿到四千颗星的原因。

附录：

主要事实与来源对照

事实	来源
首日 316 星（10-27 23:15 UTC）	rising.dev 趋势存档
Star 4,559（11-01 00:01）	GitHub
迭代时间线与各 commit 内容	仓库 commit 历史：`ab6e0bc`、`ec5aa4c`、`8e88282`、`74b2a0b`、`6cf667e`
内置 ComfyUI 插件代码	comfyui_plugin/ 目录
第三方快照滞后（"HTML、2,357 星"）	packages.md 存档页
三库 4,345 条 / 8,690 张、5 条 API 通道	README v2.0（commit `8e88282`）及 skills/ 目录
Seedream 4.0 原生多图参考	arXiv:2509.20427
`reference_images` 为一等 API 参数	火山引擎官方文档
Gemini 图像接口单请求多图输入	Google AI 开发者论坛示例
MIT 不覆盖图片、著作权归原作者	仓库 README「内容提示与版权致谢」

内容提示：图库包含部分成人向姿势与性感服装参考，仅供艺术创作与前端技术学习使用，未成年人请勿访问。图片著作权归原作者ギア所有，MIT 协议仅覆盖代码部分。

链接

github仓库：https://github.com/anhao/ai-pose-gallery-zh

在线体验：https://ai-pose-gallery.anhao.app/

本地部署问题修复记录（仅供参考）

在本地跑通合成台的火山方舟（Doubao）链路时，遇到两个报错，根因和修法记录如下。项目是 Vite + React 19 + TS 工程，用 pnpm dev 起本地服务；不能用纯静态服务器直接伺服源码目录，否则 .tsx 会被原样发给浏览器，页面空白。

问题一：sequential_image_generation 参数不兼容

现象：doubao-seedream-5-0-pro 报 The parameter 'sequential_image_generation' ... not supported by the current model。

根因：src/services/aiGenerator.ts 的火山方舟协议段无条件把该字段写进请求体，值还是字符串 'disabled'。模型只要看到这个 key 就拒绝，不管值是什么。

修法：先建 body 对象，仅当 doubaoParams.sequentialImageGeneration === 'auto' 时才附加该字段；默认 'disabled' 不发送。

问题二：参考图 URL 拼错，报“image 格式不支持”

现象：The parameter 'image' ... the image format is not supported by the API。

根因链：toPublicHttpsUrl() 的本地开发分支按源站原始目录结构拼 URL，但本仓库镜像是重命名过的——人像源站是 img/full/X.png，本地是 img/portrait/X.webp，代码少了 full/；服装源站没有 costume/ 子目录，本地有，代码多了 costume/；姿势恰好正确。拼错的 URL 落到 Cloudflare Pages 的 SPA HTML 回退页（HTTP 200，但 Content-Type 是 text/html），方舟拉到的不是图片，于是报格式不支持。

修法：本地开发统一映射到中文站镜像 https://ai-pose-gallery.anhao.app/{本地相对路径}，路径与本地目录 1:1 对应。已实测 img/portrait、thumbs/portrait、img/costume、thumbs/costume、img/*.png、thumbs/*.jpg 六种路径形态，Content-Type 均为真实图片。

几条实测结论

方舟支持 webp 参考图，报错与 webp 格式无关。
方舟支持 base64 data URL；项目已有 imagePassMode: 'base64' 开关和 srcToPngDataUrl() 可用。
该账号下 doubao-seedream-5-0、-lite、4-5、4-0、seededit-3-0 均返回 404；实际可用的是 doubao-seedream-5-0-pro-260628，项目下拉里没有，需用“自定义模型 ID / Endpoint”填入。
关闭“安全体验模式”前会遇到 429 SetLimitExceeded，关闭后正常。
本地镜像 webp 与源站原图分辨率一致，webp 只是换了编码，画质够用。

遗留改进

srcToPngDataUrl() 目前输出 PNG，webp→PNG 会带来 base64 膨胀；改成 JPEG 可以显著减小请求体。
镜像映射的代价是本地开发依赖线上镜像站，且本地更新图片后送出的是线上版本（“所见非所送”）；需要严格一致时切 imagePassMode: 'base64'。
可以自行把 doubao-seedream-5-0-pro-260628 加入火山方舟模型下拉。