前面三篇，我讲了生图 API、IP 形象、图文 skill，全是「改造」来的。 很多人问：GitHub 上现成的一大把，直接装不就行了，折腾啥？这一篇把这个问题说透——用两个真实开源 skill 的可行性分析，讲清楚我「不用原生、坚持改造」的判断逻辑。

---

一、两个看起来很美的开源 skill

做配图时，我先调研了两个口碑不错的开源项目：

ian-xiaohei-illustrations（小黑插画）——把文章里的判断、流程、隐喻，变成白底手绘的怪诞插画，主角是个叫「小黑」的卡通角色。风格很有辨识度。

JimLiu/baoyu-skills（宝玉的 skill 集）——里面的 baoyu-article-illustrator 能做信息图、流程图、对比图，baoyu-xhs-images 能做小红书卡片，方法论非常完整。

两个都是好东西。但我分析完，结论是：都不能直接用，只能改造。

二、小黑 skill：思路好，但在我环境跑不通

小黑插画的核心价值是它的「思路」——先理解文章的认知锚点，再把一个判断/流程/隐喻画出来。这套「先出 shot list 再生图」的方法，我很认可。

但它有个致命问题：它是 Codex skill，生图环节调的是 Codex 内置的 image_gen。我主战场是 Claude Code，根本没有这个工具。 原样拷过来，到了「生成图片」那一步直接卡死。

而且它的主角是「小黑」，不是我的形象；风格是白底怪诞，跟我想要的中文手账风也不是一回事。

结论：方法论可抄，机器得换，角色得换，风格得换。

三、宝玉 skill：方法论扎实，但后端也接不上

宝玉的 baoyu-article-illustrator 方法论更完整——Type×Style×Palette 三维、先找配图位、prompt 先落盘，这些都很专业。

但同样的，它的生图后端写的是「Codex imagegen → Cursor GenerateImage → baoyu-image-gen」这条链，全是别人的环境。在 Claude Code 里，这条链一个都用不了。

不过它有个设计救了自己：prompt 必须先落盘成文件，再调后端。 这意味着 prompt 和渲染是解耦的——我可以保留它全部方法论，只把最后渲染那一棒换成我自己的生图 API。

结论：骨架全留，只换引擎。

四、我的判断逻辑：自建、改造、引入，怎么选

经过这几个，我总结出一个三选一的标准，看「和你的绑定程度」：

情况	策略	例子
通用、成熟、跟你环境兼容	直接引入	ui-ux-pro-max、superpowers
方法论好、但后端/角色/风格长在别人环境	改造	小黑、宝玉的配图 skill
和你业务强绑定、市面没有现成的	自建	prd-writer、pm-zentao-task

关键不是「好不好」，是「合不合身」。 小黑和宝玉的 skill 都很优秀，但它们的「优秀」长在了 Codex/Cursor 的土壤里。我的土壤是 Claude Code + 自己的免费生图 API + 自己的 IP 形象 + 自己的中文手账风。土壤不同，再好的苗也得换盆。

五、原生 vs 自建，一张图看懂

三条路径对应三种情况：通用又合身就直接引入，方法好但引擎不合就改造，市面上没有就自建。判断的关键是「合不合身」，不是「好不好」。

改造做完之后，实际跑出来的效果是这样的——一套米色手账风的中文信息图，共享同一个 Q 版形象：

这是用「方法论抄过来、引擎换掉」的改造 skill 真实生成的。原生的宝玉 skill 给不了我这个——不是它不行，是它的引擎长在我用不了的环境里。

六、写在最后

「为什么不用原生的」这个问题，答案从来不是「原生的不好」，而是：

工具的价值，一半在功能，一半在「它长没长在你的工作流里」。 一个再强的 skill，如果调的是你用不了的 API、画的是别人的形象、出的是你不喜欢的风格，那它对你就是零分。

所以我的原则是：不迷信原生，也不重复造轮子。 能直接用的直接引入，方法论好的改造着用，谁都没有的自己沉淀。这套「配图三件套」（生图 API + IP 形象 + 图文 skill），就是这么一件件改出来的。

而这三个 skill 能改出来，前提是它们都遵守了同一个好设计：方法论和实现解耦。这也提醒我，自己写 skill 时，一定要把「会变的部分」和「不变的部分」分开——这是可改造性的来源。

---

如果这篇对你有用，欢迎关注看「AI 工具人 PM 实战」系列更新；你在「自建 vs 引入」上是怎么取舍的，评论聊聊；觉得有用就收藏备用。