1 概览

• 自 3 月起本频道持续追踪 huangwb8/skills，从 v2.10.0 一路走到 v4.1.1，本次衔接 v4.1.1，聚焦两周内的新版本 v4.1.2
• v4.1.2 上线全新技能 auto-draw-plot，让技能库第一次拥有"画图"能力：AI 自动生成、评估、迭代优化科研图表
• auto-draw-plot 内置 general / roadmap / schematic 三种模式，支持多轮 image-to-image 微调，可在 gpt-image-2、Nano Banana、Gemini 等多个出图 provider 间切换
• 发版后作者立即在主干上把它迭代到 v0.2.9，把异步出图、原生尺寸保真、工作区路径声明、超时时长等容易翻车的细节逐个收紧
• 配合 parallel-vibe 的并行留痕与隐藏工作区设计，整条出图链路做到了"可监督、可追溯"

2 前言

自 3 月上旬本频道第一次报道 huangwb8/skills 以来，这条版本叙事线我们已经持续追踪了三个多月。把时间线拉直了看，它的演进脉络其实很清晰：v2.x 时代主要是技能数量的扩张和安装机制的反复打磨；v3.0.0 引入 bensz-collect-bugs，让"发现问题—记录—反馈"第一次形成质量闭环；v4.0.0 用一个纯 Python 安装器统一了全平台体验，并给子代理立下了安全规矩；v4.0.1 到 v4.0.4 让 awesome-code 经历了一次从"脚本替 AI 做决策"到"AI 自主规划"的架构级重构，auto-test-code 也顺势上线；紧接着的 v4.1.0 和 v4.1.1，则把 BAC 贡献追踪从可选项扶正为默认基础设施，又补上了大家期待已久的 --skill 精准安装参数。上次发文停在 5 月末的 v4.1.1，距今正好两周。

这两周里，仓库其实只发了一个新版本 v4.1.2（2026-06-05），版本号看着是个小小的 Patch，但它的分量远比数字来得重——skills 第一次越过了"管理和辅助"的边界，长出了一项真正"创作型"的能力：auto-draw-plot，一个 AI 驱动的科研图表绘制技能。更有意思的是，作者发版之后并没有就此停手，而是紧接着在主干上把它迭代到了 v0.2.9，把出图链路里几个最容易翻车的细节逐个收紧。这次咱们就重点聊聊这个新技能，以及它落地之后那波快速修补。

3 v4.1.2：auto-draw-plot，skills 第一次长出"画图"能力

如果你一直在用 skills 这套生态，应该会有个直观感受：它过去几乎所有的能力都围绕"让 AI 把活干得更规矩"展开——安装更省心、贡献可追溯、代码能自测、文档能自审。但 auto-draw-plot 不一样，它是第一个让 AI 真正去"生产"一个可视化产物的技能。简单说，你用一句话描述需求，它负责把这张图从无到有地画出来，画完不满意还能自己改。从 v4.1.2 新增的 19 个文件、近 2900 行代码就能看出来，这是一个完整的技能包（SKILL.md + 一打脚本 + 参考文档 + 配置），而不是给某个现有技能打的补丁。

3.1 三种模式：先想清楚你要画的是哪一类图

auto-draw-plot 没有一上来就标榜"万能出图"，而是先把常见的科研绘图需求归成了三种模式，让 AI 在动手之前先对齐意图。general 是默认的通用模式，适合大多数示意图；roadmap 面向技术路线图、流程图这类强调"路径与阶段"的图；schematic 则专门给原理图、机制图、架构图用。这个分类其实挺关键——不同类型的图，prompt 的拼装口径、默认画布和评估标准都不一样，先把意图分清楚，AI 后面才不容易把一张原理图画成流程图的样子。后续如果要加新类型，作者也留好了扩展口，统一在 config.yaml 里以预设的方式扩展，不必动主流程。

3.2 多轮 image-to-image：像和 AI 一起改稿

最让我觉得"对味"的，是它的多轮优化机制。第一轮 AI 会基于你的需求出一张初稿，从第二轮起，它不会推倒重来，而是把上一轮的 output.png 作为第一张参考图传回去，配合上一轮评估里标记的 must_fix 和 prompt_patch，让模型在原图基础上做 image-to-image 微调。这个逻辑非常贴近真实场景里"和设计师改稿"的过程——你指着某处说"这里线条太粗、那个箭头方向反了"，对方在你原图上改，而不是每次都重画一张让你重新辨认。默认最多迭代 3 轮，直到 AI 自己判断满意或者轮数用完为止，每一轮的 prompt、模型参数、参考图策略和评估结果都会留痕，事后能复盘。

3.3 多 provider 与 parallel-vibe：底层选了"稳"而不是"炫"

底层出图，auto-draw-plot 没有把鸡蛋放在一个篮子里，而是接入了 gpt-image-2、Nano Banana、Gemini 等多个图像生成 provider，默认 auto 模式会按优先级挑一个当前可用的来用。但这里有个我很欣赏的克制设计：一旦你点名了某个 provider，它就老老实实只用这一个，出错了停下来报原因，绝不自作主张偷偷切到另一个模型；只有你明确说"失败可以换模型"时，它才会启用 fallback。这种"默认不越界"的态度，在 AI 出图这种成本和不确定性都比较高的场景下，能帮你省下不少冤枉钱和意外状况。另外，每一轮出图前它都会基于 parallel-vibe 生成并行计划并强制留痕，意味着规划过程是可追溯的，而不是 AI 脑子里一笔糊涂账。

3.4 工作区与可监督性：每一步都留痕

auto-draw-plot 把所有中间产物都关进了一个隐藏工作区 .draw-plot/run-<时间戳>/ 里，不打扰你的项目主目录。每一轮都有自己的子目录，prompt、parallel 计划、output.png、评估结果一应俱全，run 级别还有汇总的 meta 文件可供追溯。更体贴的是，AI 在正式开始出图之前，必须先用一条可见消息把本次 .draw-plot 工作区的绝对路径告诉你，方便你随时进去盯进度、看证据。这种"主动交代工作区位置"的细节，说明作者是真的在考虑"人和 AI 协作出图"时的监督需求，而不只是把图画完交差。

4 发版即迭代：v0.2.9 把出图链路收紧了一圈

auto-draw-plot 在 v4.1.2 里刚上线，但作者显然自己也立刻用了起来，因为发版后没多久，主干上就出现了一个 v0.2.9 的更新，把初版里几个容易出问题的点挨个修了一遍。这一波改动没有单独发 Release，但已经合进了 main 分支，几条 commit 都很能说明实际使用中踩到的坑。

第一条，也是分量最重的一条：gpt-image-2 的默认提交方式被改成了 Sub2API 的异步图片任务接口（image job endpoint）。以前同步出图，遇到 429 限流或者 5xx 服务端错误时容易卡住或失败；现在默认走异步任务，排队、轮询、下载都由脚本兜着，而且明确规定 429/5xx 不再退回同步接口——异步链路在排队和高分辨率场景下天然更稳。相应的，图片生成的请求超时也从 180 秒一口气拉到了 1800 秒，专门适配那些高分辨率或者需要排队的长任务。

第二条改的是"图到底长什么样"的呈现方式。初版默认会把出图结果做插值放大、贴到一个伪 4K 画布上，听起来高大上，但实际容易糊或者比例失真。v0.2.9 把这个默认行为取消了，改成直接保留 provider 返回的原生 PNG，只有你显式加 --postprocess-resize 时才会启用后处理。说白了就是"先保真，再谈美化"，对科研图来说，清晰和准确比好看的尺寸重要得多。

第三条是可监督性的进一步强化：新增了启动前 .draw-plot 绝对路径的声明规则，确保 AI 在检查 API、初始化工作区之前就先把工作区位置告诉你，而不是事后塞进某个 manifest 文件里。同时每一轮图片都新增了 requested_provider_size、native_size、output_size 三组尺寸元数据记录，让你能清楚区分"我请求的尺寸""模型原生给的尺寸"和"最终输出的尺寸"，排查比例问题时不再两眼一抹黑。

这一波 v0.2.9 的快速迭代，其实很能说明一个开源项目的健康度：不是发完版就丢，而是自己先用、先踩坑、先修。对正在观望要不要上手 auto-draw-plot 的小伙伴来说，这反而是个挺积极的信号 (～￣▽￣)～

5 小结

v4.1.2 是 huangwb8/skills 一个相当有标志性的版本：它用 auto-draw-plot 这一个技能，把整个技能库的能力边界从"管理和辅助 AI 干活"推进到了"让 AI 直接创作可视化产物"。模式化的需求理解、多轮 image-to-image 微调、多 provider 选择，再加上 parallel-vibe 的并行留痕，让它不只是"能出图"，而是"出图过程可控、可追溯、可监督"。而发版后立即跟进的 v0.2.9，又把异步出图、原生尺寸保真、工作区路径声明这些实战中容易翻车的细节逐个压实，透着一股"自己先用透再交给用户"的踏实劲儿。如果你最近正好需要让 AI 帮忙画科研示意图、路线图或原理图，这个新技能值得一试。

项目地址：https://github.com/huangwb8/skills