同一篇文章可以有正文配图、解释结构的信息图和可交互的 HTML 页面，但三种产物的阅读距离、信息密度和验收方式并不相同。本文把文章观点拆成视觉任务，说明何时用示例图、何时用信息图，以及如何用真实内容检查页面是否仍然可读和可维护。文中只讨论可复现的步骤，不把单次结果扩展成产品承诺；每个结论都标注前提、证据和无法覆盖的边界。读者可以先完成最小验证，再按自己的版本、权限和数据补充实验。
写完一篇文章以后，很多人的视觉工作流是这样的。
打开一个生图工具，输入文章标题，得到一张看起来挺热闹的图。然后再让模型做一张信息图，图里塞上六个观点、十行文字和三个箭头。最后把原文复制到一个网页模板里，字号小一点，颜色多一点，算是完成了“内容包装”。
问题是，这三种东西其实不是一回事。
正文插图是为了让读者在某个段落停一下，理解一个判断或隐喻；信息图是为了把分类、流程、比较或数据压缩到一个画面里；HTML 页面则是为了让一堆内容可以浏览、筛选、展开，甚至直接作为本地交付物分享出去。
这篇介绍三个项目，正好对应三类输出：
它们都能让文章变得更好看，但“更好看”不是共同的产品定义。先把产物边界分清楚，效果才不会变成一锅视觉调料。
一、先区分三种输出
可以用一个很简单的问题判断工具：读者此刻需要的是解释、总结，还是操作？
需要解释，用正文插图
例如文章写到“一个团队把所有工作都交给一个超级 Agent，最后没人知道它为什么改了这个文件”。这句话适合画成一个具体的认知隐喻，让读者看见“黑盒”和“失去控制”的关系。
这类图不需要把整篇文章再抄一遍。它只需要把一个动作、一个状态或一个结构画清楚。
需要总结，用信息图或卡片
例如一篇教程要总结“安装、配置、测试、上线”四步，或一篇测评要比较价格、模型、上下文和团队权限。读者需要的是扫描和对照，信息图比一幅抽象插画更合适。
需要浏览，用 HTML 页面
例如一份 CSV 数据、一组研究笔记、一篇长教程或一份旅行记录。读者可能需要目录、筛选、时间线、地图、展开详情和更大的画布。这时 HTML 不只是“把 Markdown 换了一个皮肤”，而是一种更丰富的交付格式。
这三个问题如果不先分开，最容易出现的结果就是，正文插图画成 PPT，信息图写成小论文，HTML 页面又只是把长文塞进一个白色容器。
二、ian-xiaohei-illustrations，给正文画一个认知动作
项目地址：helloianneo/ian-xiaohei-illustrations
这是一个面向 Codex 的 Skill，用来给中文文章、博客、Notion 文档和方法论内容生成正文配图。它的视觉目标很明确：16:9 横版、纯白背景、黑色手绘线稿、少量红橙蓝中文批注，以及一个叫“小黑”的黑色实心角色。
小黑不是贴在角落里的吉祥物。
仓库要求小黑参与文章里的核心动作。它可以在系统里搬运信息、被流程卡住、拿着放大镜检查证据，也可以站在两个选择之间犹豫。画面应该让读者看懂文章里的一个判断，而不是仅仅看到一个可爱的角色。
它适合做什么
- 把抽象观点变成一个有记忆点的隐喻。
- 把流程中的关键转折画出来。
- 给长文章的几个认知锚点增加视觉停顿。
- 把“前后对比、角色状态、方法分层、地图路线”画成轻量解释图。
默认工作流会先从文章中提炼适合视觉化的段落，再输出一份 shot list。默认一篇文章生成 4 到 8 个镜头方案，每张图只表达一个核心动作，最终输出 PNG，放在类似下面的目录：
安装和调用
仓库 README 提供了克隆和复制到 Codex Skills 目录的方式：
Windows 上可以直接把仓库里的子目录复制到 Codex 的 skills 目录。关键是复制 ian-xiaohei-illustrations/ 这个真正包含 SKILL.md 的子目录，不要只复制仓库根目录的 README。
安装后这样调用比较合适：
这段话特意把“先出 shot list”说在前面。直接让模型生成 8 张图，往往得到 8 个看起来不同、实际上都在重复标题的画面。
它不适合做什么
这个 Skill 默认不输出 PPTX、PDF、SVG、HTML，也不负责商业海报、品牌 KV 或完整课程页。它也不应该把一大段正文缩小到画布里，假装那是一张插图。
图片里的中文文字越短越稳定。生成后还要检查错字、风格漂移、留白和小黑是否真的承担了动作。AI 图像模型把“流程”画成一张看起来像流程图的东西，不代表它正确表达了文章结构。
三、baoyu-skills，按需安装的视觉工具箱
项目地址：JimLiu/baoyu-skills
如果说小黑是一个非常明确的视觉风格，baoyu-skills 更像一个内容生产工具箱。当前仓库包含 20 多个 Skill，覆盖内容整理、图片生成、信息图、文章插图、封面、Markdown 转换和公众号发布。
它的第一条使用原则不是“全部安装”，而是按需安装。仓库 README 明确提醒，批量安装会给每一次 Agent 对话增加上下文负担。
快速安装入口是：
如果你只服务公众号文章，一个较小的组合通常是：
不需要为了公众号发布单独安装 baoyu-markdown-to-html，仓库说明中写明 baoyu-post-to-wechat 已经包含 Markdown 到公众号可用 HTML 的转换流程。只有你想单独把草稿转换成结构化 Markdown 或 HTML 时，再安装对应工具。
1. baoyu-cover-image，负责封面，不负责正文解释
封面 Skill 有类型、配色、渲染、文字和氛围五个维度，也提供了多种预设。可以这样调用：
需要控制比例时，明确告诉它平台：
公众号头图、文章内插图和小红书首图的安全区域不同。封面标题要短，不能把文章摘要原封不动铺满画面。需要纯视觉、不带标题时，可以使用仓库支持的 --no-title。
2. baoyu-article-illustrator，负责结构辅助
文章插图 Skill 会读取文章结构，判断哪些位置需要视觉辅助，再根据类型、风格和色板生成图片。例如：
它和小黑 Skill 的差异在于视觉语言不同。小黑强调一张图讲一个怪诞但成立的认知隐喻；宝玉工具箱更像一个可以选择插图类型、风格和色板的通用生产工具。两者可以都安装，但同一篇文章不要让它们无规则地混用，否则整篇文章会像多个设计团队临时拼在一起。
3. baoyu-infographic，负责信息密度
信息图 Skill 支持多种布局和视觉风格，能根据内容推荐组合，也可以指定布局：
它适合金字塔、漏斗、比较、流程、分层和统计关系。信息图不是把正文缩小，而是先做信息删减。一个画面如果需要读者放大 300% 才能看完，说明内容没有经过视觉分组。
4. baoyu-markdown-to-html 和 baoyu-post-to-wechat
如果你只想得到一个样式化 HTML，可以调用：
如果目标是公众号发布流程，可以使用：
但“生成发布稿”和“自动发布”是两件事。公众号凭证需要按用户级或项目级放在 .env 中，仓库明确提醒不要提交到 Git。正式提交前还要人工检查标题、摘要、外链、图片版权、折行和平台后台的实际效果。
四、html-anything，不是 Markdown 换皮
项目地址：clockless-org/html-anything
html-anything 的目标是把合适的内容变成经过浏览器检查的单文件 HTML。它支持的输入不只有 Markdown，还包括 PDF、DOCX、CSV、JSON、日志、仓库、聊天导出、收藏、GPX 和各种服务导出文件。
README 当前描述了 60 个来源 Prompt、17 套具体风格系统和 11 个示例。它把输入路由到几类稳定场景：教学页面、文件与工作数据、对话分析、个人数据与地点。
你不需要先告诉它“请写 HTML”。更自然的请求是：
或者：
它的价值在于，Agent 会根据输入选择场景和风格，而不是让用户先背一套前端组件名称。生成页面通常是静态、本地优先的单文件产物，可以直接打开，也可以放到支持静态 HTML 的服务器上。
输入和输出要分开验收
一个 HTML 文件生成出来，不代表它能用。至少要检查：
- 文件能否直接在浏览器打开。
- 目录、折叠、筛选和交互是否真的工作。
- 长标题、代码块、表格和移动端宽度是否溢出。
- 页面引用的图片和字体是否存在。
- 页面是否把原始私人数据嵌进了客户端。
README 特别提醒，生成的 HTML 可能在浏览器端嵌入私有来源数据，输出文件应当和原始导出一样敏感。涉及医疗、法律、税务、会计、移民、保险和投资的页面，只能用于组织和复核，不应该被包装成专业意见。
五、三种工具放在一条内容链路里
假设你写了一篇“企业如何治理多模型 API 成本”的文章，可以按下面的顺序处理。
第一步，先写清楚文章本身
正文必须先有观点、证据和读者目标。视觉工具不能替你解决文章逻辑，也不应该在正文还没有定稿时批量生成 20 张图。
第二步，小黑选认知锚点
从文章里挑出“统一入口、项目 Key、预算告警、失败回退”几个关键转折，让小黑 Skill 先生成 shot list。例如一张图画“所有业务都把 Key 写在同一个配置文件里，最后谁都不敢改”，另一张图画“网关把不同项目的调用分流并记录成本”。
每张图只负责一个理解动作。
第三步，宝玉工具箱补封面和信息图
封面只传达文章主题，信息图才负责表达四层治理结构。两者共用一套主色、字体和关键词，但不必使用同一个构图。
如果你还要发小红书，可以调用 baoyu-xhs-images 把文章拆成 1 到 10 张卡片，根据内容选择 flow、comparison 或 dense 布局。卡片是阅读载体，不是把公众号正文一张张截图。
第四步，html-anything 做可浏览版本
把研究表格、费用样例、配置清单和文章正文交给 html-anything，生成一个有目录、筛选和展开详情的本地页面。这个页面面向需要反复查阅的人，不能把同一份材料粗暴复制给所有平台。
六、三者的选择表
| 需求 | 推荐项目 | 典型产物 | 最容易犯的错误 |
|---|---|---|---|
| 让读者理解一个隐喻或判断 | ian-xiaohei-illustrations | 16:9 PNG 正文插图 | 把插图做成信息图或 PPT |
| 生成封面、卡片、信息图 | baoyu-skills | 图片、SVG、公众号 HTML | 一次性安装全部 Skill，风格混用 |
| 把长内容或数据变成可浏览页面 | html-anything | 单文件 HTML | 只换颜色，不增加目录、筛选或交互 |
从产物类型也能看出它们的责任不同。PNG 主要检查画面和文字；信息图要检查信息层级和准确性；HTML 还要检查交互、响应式、数据隐私和资源路径。
七、企业级 API 接入怎么安排
这些 Skill 都可能调用模型或图像模型。企业不要让每个创作者把生产 Key 直接放在本地脚本里，建议把模型请求统一经过企业 API 网关或 上游 API 这类多模型 API 接入层，再做项目级管理。
可以拆成三组：
每组配置自己的 Key 权限、模型白名单、每日预算和失败告警。记录项目、模型、耗时、错误类型、调用量和费用；不要把原始文章、客户数据、图片原文件和 API Key 原文写进普通日志。
如果要把生成结果接入 CMS 或公众号发布系统，发布动作应当单独设置权限。让 Agent 生成 output.html 不等于允许它访问生产后台，更不等于允许它自动发布未审核内容。
八、许可证和素材安全
Ian 项目 README 标注 MIT；baoyu-skills 默认采用 MIT，第三方代码和素材按各自说明处理；html-anything 使用 MIT-0。最终使用时以仓库当前 LICENSE 文件为准。
图像和页面里的素材仍然要单独核对。用户图片优先并不代表用户拥有所有人的肖像和场景权利；网络素材需要记录来源、许可证和下载时间；AI 生成的图片也不能自动获得品牌、人物和字体的商业授权。
html-anything 生成的是本地优先页面，里面可能嵌入 CSV、聊天记录或浏览历史。分享前要先看 HTML 源码和附件目录，确认没有把个人手机号、订单、坐标、Cookie 或内部链接一起发出去。
九、验收清单
正文插图验收
- 每张图只表达一个认知锚点。
- 小黑参与了核心动作，而不是只站在画面边角。
- 16:9、白底、留白和线稿风格一致。
- 中文标注没有错字，图片没有额外标题和重复说明。
- PNG 文件放在文章资产目录，命名和引用清楚。
信息图和封面验收
- 封面只保留必要标题和视觉焦点。
- 信息图的数字、分类、箭头和图例与正文一致。
- 小红书、公众号和其他平台的比例分别检查。
- 第三方图片、字体和素材有来源记录。
- 不同 Skill 的色板、字号和视觉语言没有互相打架。
HTML 页面验收
- 单文件能直接打开，资源路径没有失效。
- 浏览器中检查过溢出、折行、代码块、表格和移动端宽度。
- 交互按钮、筛选、目录和折叠内容真实可用。
- 页面没有把敏感数据暴露到不该访问的位置。
- 需要专业判断的内容标注为资料组织或复核页面。
API 和发布验收
- 上游 API 或企业网关的 Key 按项目和环境分组。
- 生成、渲染、审核、发布权限彼此分开。
- 日志能追踪模型、耗时、错误和费用，但不保存明文密钥。
- 文章、图片、HTML 在发布前都经过人工抽查。
总结
一篇文章可以有很多视觉版本，但不应该让每个版本承担同一件事：
真正省时间的地方，不是让 Agent 一次生成更多图片，而是让每个产物都对应一个明确的阅读动作。
结论
本文给出了问题定位、配置或创作流程的可执行路径。实际结果仍取决于当前版本、权限和运行环境，提交前应按官方文档复核可变字段，并保留失败证据和回滚边界。
