1. 为什么配图和排版值得单独聊

baoyu-skills 这个开源仓库里收了不少好用的 AI 技能模板，维护者把上百个高频任务整理成了直接能用的"岗位说明书"。上一轮我把整体体验过了一遍，这篇单独把技术文章最躲不开的两件事拎出来：配图和排版。说白了，配图不是随便丢一张封面进去，排版也不是段落之间敲几个空行，这两件事在发布环节里隐形消耗的时间，远比大多数人想象得多。

先聊配图。技术文章里的图，尤其是架构图、流程图、时序图，承担的是"读者理解的第一入口"这个角色。很多人读技术帖，第一眼扫的是标题和结构，第二眼就是图。图要是画得乱、层次不清，读者会在心里直接给文章降级；图要是清晰直观，即使文字表达一般，整体观感也能往上拉一大截。所以别把配图当成锦上添花的装饰，它其实是内容是否"可读"的硬指标。

1.1 配图不是"配"图，而是理解入口

我给自己发过的文章做过一次粗略统计，一篇架构类文章，手绘架构图平均要花二十分钟到半小时，碰上需要反复改模块名、改连线关系，一小时搭进去也不稀奇。流程图稍微好一点，但一旦涉及跨层调用、回退分支，连线绕来绕去，改到后面连自己都不想看第二眼。这种成本放在"写文章已经很累"的前提下，往往是压垮更新频率的最后一根稻草。

AI 介入之后，瓶颈从"画图"转移到了"描述"。你不需要会构图、会配色、会调对齐，只需要把系统模块、依赖关系、层次关系说清楚，模型就可以直接生成一个可编辑的矢量图。这里的关键在于，图一旦生成，是要能放进文章里直接用的，而不是一张"看起来像那么回事但放大全是错误"的示意图。所以我在配图相关 Skill 里习惯把输出格式和校验规则都写死，宁可在生成阶段多花十秒钟描述，也不要拿回来再看十分钟的错误。

除此之外，配图还要考虑"改版"这件事。手绘图最怕改，用 AI 生成就不一样，你只需要改描述文字，让模型重新画。改一个模块名、调一对连线关系，成本被压得非常低，这种优势在成稿后的反复修改阶段尤其明显。后面你会看到，我在完整流程里使用的配图操作，几乎全部是"微调指令"而不是"重新生成"，这能省下大量的无效输出。

1.2 排版是被低估的隐性工作

再说排版。很多人觉得排版就是把文章分分段、加加粗，实际上一篇文章从写完到能发布，中间要处理的琐碎事项相当多：标题层级是否一致、代码块有没有标明语言、长段落是否需要拆分、提示性内容要不要和正文区分、表格在不同平台会不会错位。这些工作不产生新内容，但每一项都在消耗注意力。

一篇文章三千字，如果原始稿是一大坨文字直接丢进平台，阅读体验是灾难性的。移动端阅读讲究短段落、清晰层级、视觉锚点，这个道理大家都懂，但真到整理的时候，人很容易犯懒，一懒就不想按时更新。我自己以前写公众号和文集的时候，排版这步经常拖到发布前最后一刻，然后草草收场，发完又后悔。

baoyu-skills 在这个场景里提供的不是某个魔法咒语，而是一整套被反复打磨过的工作流。把这些 Skill 接入自己的写作流程之后，"写完就发"到"整理后再发"的阻力会小很多，更新意愿也会跟着上来。接下来我会把 Skill 的原理、配图 Skill 和排版 Skill 各自的拆解、以及一条完整的实操流程都过一遍。

2. Skill 到底是什么，以及配图相关的选择

2.1 一份好 Skill 的本质是岗位说明书

先把基础概念说透。所谓 Skill，本质是一段高度结构化的系统提示词，它把某类任务的执行细节全部写清楚：担任什么角色、按照什么流程做、产出什么格式、避免什么操作。它和随口说一句"帮我写篇文章"的区别，就是让实习生自由发挥和给他一张 SOP 的区别。实习生拿到 SOP，就算经验欠缺，也能按步骤交出接近预期的结果；没有 SOP，全凭悟性，结果就完全是开盲盒。

我见过不少人对提示词工程的理解停留在"多夸两句模型就能干得更好"，这是误区。真正稳定有效的提示词，核心是约束而非夸奖。角色定位解决的是语气和立场问题，流程设计解决的是步骤遗漏问题，输出格式解决的是返工问题，禁止事项解决的是翻车问题。baoyu-skills 的价值，就是把这一类约束提前写好、验证过，变成可以直接复用的资产。

这个仓库最吸引我的地方，是它不教你"怎么和 AI 聊天"，它直接给你一堆"开箱即用"的成品。很多 Skill 明显是作者自己在真实写作、编程、运营里反复打磨过的，里面藏着大量只有踩过坑才知道写的细节，比如"禁止外部图片资源""中文文字不低于 12 号""不得增删技术结论"。这些细节就是一张岗位说明书里最关键的经验沉淀。

2.2 配图型 Skill 有哪些选择

配图 Skill 的选型，核心看三件事：图文发布介质、后续修改频率、系列文章的视觉一致性。我按使用场景做了一个简单的划分。

技术类文章，我强烈建议优先选择矢量图方向而不是纯图片方向。原因有两条：第一，矢量图上的文字是真文字，可以直接搜索、复制，也清晰可读；第二，改版成本极低，模块名一改，重新生成一次就行。纯图片方式虽然视觉冲击力更强，但中文字在图像模型里翻车概率不低，改起来也麻烦。

如果你的平台对配图格式没有强制要求，那架构图这类内容用矢量图方案几乎是唯一解。封面图和概念图这种对艺术感要求更高的东西，才值得交给图像生成模型去折腾，而且最好遵循"图内不带文字"原则，文字放到排版环节再加，避免模型把中文字画成乱码。

2.3 一个可以直接套用的架构图 Skill

下面这份 Skill 模板，是典型的"配图型"Skill，我按照自己在实际写作里的习惯整理过，你直接复制到对话里就能用。

# 技能：技术架构图设计师 ## 角色 你是一位拥有十年经验的系统架构可视化专家，擅长把复杂系统结构转化为清晰、美观的矢量架构图。 ## 工作流程 1. 理解用户描述的模块、依赖和数据流向。 2. 先用文字输出分层结构清单，等待用户确认，再输出图片。 3. 图形使用 SVG 格式输出，方便直接嵌入文章或文档。 ## 输出规则 - 布局：自顶向下分层排列，同层节点水平居中，边界留白不低于 40。 - 配色：默认使用蓝色系与灰色系渐变，同层保持同一色系。 - 文字：节点文字使用中文，字号不低于 12，禁止文字重叠。 - 连线：仅保留关键依赖与调用关系，使用实线箭头，不穿过文字。 - 尺寸：宽度 800 或 900，高度自适应。 ## 禁止事项 - 禁止引用外部图片或字体资源。 - 禁止在图中添加营销文案。 - 禁止只输出图片描述而不输出代码。

注意这里两个细节：一是"先文字确认再出图"，避免用户没想清楚结构就白画一次；二是明确禁止"只输出描述"，这是对话式模型最常犯的毛病，它可能觉得自己描述得很清楚，但你要的是能直接用的代码。

实际调用时，我只需要给出需求。比如：

帮我画一个数据处理管线的架构图，分四层：采集、清洗、计算、输出。 采集层有日志采集和指标采集，输出层有实时报表和离线报表。

模型会先返回一个分层结构清单：

采集层：日志采集、指标采集 清洗层：规则清洗、格式标准化 计算层：实时计算引擎、批处理引擎 输出层：实时报表、离线报表

确认无误后，它再输出一段 SVG 代码。拿回来之后，直接嵌入文章或者转成图片文件，一条龙就结束了。整个过程大概三到五分钟，比手动画图快一个量级。后面我会专门用一节说配图阶段常见的翻车问题和修图指令，这里先按住不表。

3. 排版 Skill 的核心拆解

3.1 排版 Skill 里的关键规则

排版 Skill 和配图 Skill 的关注点完全不同。配图 Skill 解决"视觉结构"的问题，排版 Skill 解决"阅读节奏"的问题。下面这份模板参考了 baoyu-skills 里和文章排版相关的整理思路，我加了注释方便理解每一句的作用。

# 技能：技术文章排版顾问 ## 角色 你是资深技术内容编辑，负责把原始文稿整理为适合技术社区发布的 Markdown。 ## 处理规则 1. 内容保真：不得增删技术结论、代码、参数和命令。 2. 标题体系：为二级、三级标题添加数字编号，格式如 "## 1. 背景"、"### 1.1 现状"。 3. 段落节奏：每段控制在四至六行，段间用空行分隔。 4. 提示信息：重要提醒使用引用块，如 "> 提示" 或 "> 注意"。 5. 代码块：必须标注语言类型。 6. 并列项超过三项且有比较性质时，优先转为表格。 7. 禁止套话：不得在开头添加"本文介绍了"，结尾添加"综上所述"等模板化表述。 ## 输出要求 直接输出整理后的完整文章，不附带修改说明。

这里每条规则背后都有原因。内容保真这条最重要，因为 AI 普遍有"润色强迫症"，看到不流畅的句子就忍不住改，技术文章一旦被改了参数或者改了结论，比丑更致命。标题编号是为了让层级关系一眼可见，也方便读者在心里建立大纲。段落拆分是因为移动端阅读的视线停留时间很短，大段文字很容易劝退。引用块则是给文章制造"视觉锚点"，让重要的注意事项跳出来，而不是淹没在正文里。

3.2 不同发布平台的适配差异

排版规则不能一套走天下，还要看平台。目前技术文章常见去处大致分三类：第一类是支持原生 Markdown 的技术社区，文章直接粘贴渲染即可；第二类是封闭型自媒体平台，对 Markdown 支持有限，需要转换成内联样式 HTML；第三类是自己搭的博客，自由度最高。

对于第二类平台，一个技巧是让排版 Skill 额外输出一段带内联样式的 HTML 片段，用来替换普通的引用块或提示框。比如：

<blockquote style="border-left:4px solid #2563EB;background:#F8FAFC;padding:12px 16px;color:#334155;margin:16px 0;"> 注意：这段提示使用了内联样式，在部分平台可以保留区块背景色。 </blockquote>

这样做的好处是，即使平台不认 Markdown 的引用语法，这段 HTML 也能保持原有的视觉层级。代价是样式代码会混在正文里，所以我的做法是：先让排版 Skill 输出一份干净 Markdown，发布到技术社区用；再让它输出一份带关键 HTML 的版本，发布到封闭平台用。两个版本分开跑，谁也别迁就谁。

3.3 排版 Skill 跟内容生成 Skill 的配合

排版 Skill 单独用效果最好，但它不排斥和其他 Skill 配合。我的习惯是分两轮走：第一轮先用内容生成类的 Skill 把稿子从"思路片段"扩成"成稿"，第二轮再用排版 Skill 收尾。两轮分开而不是合并，原因很简单——内容生成需要发散，排版需要收敛，一个任务里同时要求发散和收敛，模型很容易两头摇摆，最后既写不出新观点，也排不出干净的版式。

另外一个很多人忽略的用法：排版 Skill 不只能处理自己写的稿子。别人发来一段思路、一篇文档、甚至一份访谈记录，你也可以把它丢给排版 Skill 做结构化整理。发布效率提升的不仅是自产文章，还有所有需要对外输出的文字。我在团队里带新人时，经常鼓励他们把会议纪要、设计文档先过一遍排版 Skill，再拿给我看，结构质量立刻提升一个档次。

4. 一篇文章的完整实操流程：从初稿到发布

光讲原理不过瘾，我把一个真实的处理流程完整走一遍。假设现在要发布的文章主题是"某跨平台系统的模块化改造记录"，初稿大概是这么个状态：

我们这个系统原来是单体，后来拆成模块。拆完以后发现构建很慢，每次发布要十几分钟。模块之间依赖有点乱，改一个地方要重新构建好多个模块。我们后来加了缓存、做了依赖梳理，又把构建任务改成并行，时间压到了三分钟以内。

坦白讲，这稿子信息密度够，但直接发出去，读者不一定能快速抓住重点，标题、结构、图、排版通通欠着。下面我用三个环节把这篇文章从"干稿"推到"可发布"。

4.1 第一轮：内容修订

先把这段干稿丢给内容修订类的 Skill，让它补充上下文、梳理逻辑、补足读者的前置问题。你可以给它一个明确的指令：

请把这篇文章扩展成一篇完整的实战记录，目标读者是有一年经验以上的工程团队。需要补充：模块划分的依据、依赖梳理时发现的问题、缓存方案的具体做法、并行构建的效果数据。保留技术细节的严谨性，不要写空话。

这一轮跑完之后，稿子会从一个段落变成三四个小节的成稿，每节有标题、有背景、有过程、有结论。我特别提醒一点：内容修订阶段不要在提示词里带上"写得生动一点""增加文采"这类要求，技术文章的核心是准确和清晰，文采是加分项，但不值得为了文采牺牲信息密度。

4.2 第二轮：配图生成与校验

配图用的是前面那份架构图 Skill。我给它描述一个结构：改造前是单体架构，改造后是模块化架构，构建链路从串行变成并行。为了说清楚前后变化，最好出两张图：一张改造前的单体结构，一张改造后的模块化结构。

实际生成过程里，第一版 SVG 很可能有问题，比如节点文字被截断、连线交叉在标题上，这些都很正常。我的做法是先别急着重画整张图，而是针对问题点单独下指令：

第三层和第二层之间的连线交叉了，第四层节点文字太长被截断。请保持现有结构不变，重新调整第三层节点间距，并把第四层节点文字缩短为两个字。

这种"结构不变、局部调整"的指令，比"重新画一张"更省资源，而且改出来的效果更接近你想要的那版。等两张图都稳定了，再让模型输出两次完整 SVG，分别保存。校验这步我建议认真做，因为 SVG 在模型输出里偶尔会出现标签未闭合、宽高被写死导致变形的情况。把代码丢进浏览器直接打开，扫一眼布局是否合理、文字是否重叠，基本就能发现问题。

4.3 第三轮：排版输出

内容修订完、配图到位后，进入排版环节。把整篇稿子丢给排版 Skill，它会在几分钟内输出一份带标题编号、段落拆分、代码块标注、表格整理的 Markdown。以下是处理后中间一节的示意：

## 3. 模块化改造的关键步骤 ### 3.1 模块边界划分 划分边界时，我们按业务域而非技术栈切分。基础组件、业务组件、应用层各自独立成模块，避免出现跨模块的循环依赖。 > 注意：边界划分阶段最容易踩的坑是"过度拆分"。模块粒度太细，后面每次构建的开销反而会变大。

看到这段结构你就明白，排版 Skill 真正赚到的时间，是在那些重复性很强的体力活上：标题编号、段落拆分、提示块转引用。这些事情不难，但每一件单独拎出来都要花十几秒，累计起来就是十分钟。更关键的是，AI 干这些活不会烦躁，不会因为改了五遍标题编号就手抖，稳定性和耐心都比人强。

4.4 时间账：原来多久，现在多久

我把自己之前的操作和用了 Skill 之后的操作做了一个对比，大致数据如下。

总时长从接近两小时压缩到四十分钟上下。节省出来的时间，我基本都花在校验和打磨细节上，而不是消耗在踩重复的坑里。我觉得这才是工具带来的真正增量——不是让你更快发布，而是让你有富余时间去把那些"再加点分"的细节做完。

5. 常见问题与排查技巧实录

用了这套流程几个月，我踩过的坑不少，整理几个最有代表性的，方便你少走弯路。

5.1 配图环节的典型翻车现场

第一个高频问题：模型输出了"图片描述"而不是"图片代码"。它可能写了一段话："这是一个分四层的架构图，第一层是..."，然后就没有然后了。这种问题通常是因为对话历史里缺少明确的格式约束，或是 Skill 里的"禁止只输出描述"被后续对话带偏。处理方式很简单，补一句"请直接输出可渲染的代码，不要任何文字解释"，一般能拉回来。

第二个问题是中文乱码。有些模型输出 SVG 时，会尝试调用外部字体资源，一旦目标环境无法访问，中文全部变成方框。对策是在 Skill 里约束"禁止引用外部字体资源，文字颜色与背景色保持足够对比度"，同时在拿回来渲染后，肉眼扫一遍中文显示是否正常。

第三个问题是整体风格不稳定。今天生成的架构图是蓝色系，下星期同一套系统生成的却是绿色系，放在一个系列文章里特别奇怪。我的解法是在 Skill 里建一个"风格记忆卡"，把主色、辅色、节点形状、圆角大小、留白值写成固定字段，每次生成前先让模型读这一段。这种做法对我这种有连载需求的人特别管用。

5.2 排版环节的典型翻车现场

排版阶段最容易翻的车是内容被改。明明要求"内容保真"，模型还是会在段落衔接处自由发挥，甚至补一段结论，这在技术文章里是致命的。遇到这种情况，第一反应不是改提示词，而是先做版本对比，把改动的地方逐条看一遍。从根上防，只能两条腿走路：一是 Skill 里写死"禁止增删内容"，二是在流程上留一道"人工全文比对"的作业。

另一个常见问题是排版用力过猛。整篇文章到处都是加粗、引用、表格，读者进了页面跟进了装修现场一样，反而没法聚焦重点。我的调试方式是给排版 Skill 增加量化约束："引用块全文不超过三个，加粗只用于第一次出现的核心术语，表格只用于超过三项的比较"。有了数量上限，AI 的"表现欲"就被框住了。

表格错位的问题也要提一下。移动端读取宽表格很容易横向溢出，表格超过五列基本必翻车。排版的时候我会主动要求模型"超过五列的比较改为分点描述"，宁可多写两句，也不要一个长表格毁掉移动端体验。这条经验是我在几次被读者反馈"表格在手机上根本没法看"之后总结出来的。

5.3 一套通用的排查思路

遇到问题先别急着重跑，按下面这个顺序排查，效率会高很多。先确认输出形态，是不是要求的代码格式、文件格式；再拆约束，角色、工作流、输出规则、禁止事项四类约束逐项检查，看是哪一条被漏了或者被历史对话覆盖了；最后小步快跑，一次只改一个约束，不要同时调三个参数，否则你根本不知道是谁生效了。

我后来养成了一个习惯：每次改完 Skill，顺手存一个带日期的新版本。跑出满意效果的那一版，就固定下来当主版本；效果变差的版本，能追溯问题。这套方法不复杂，但真的能帮你慢慢打磨出属于自己的一套技能库。从另一个角度看，这也算是在给自己做"提示词版本管理"，和写代码的习惯是一脉相承的。

6. 我自己的几点使用心得

6.1 把 Skill 当成骨架，而不是定论

第一点心得，Skill 是起点不是终点。baoyu-skills 里的模板能用，但不可能完全贴合你的写作习惯和平台场景。我的做法是拿它当骨架，用自己的实际文章去试，发现问题就改，改了再沉淀回自己的收藏夹。持续迭代半年之后，你手里的 Skill 会比最初版好用得多，甚至会在里面看到很多自己独有的表达习惯和排版偏好。

我举一个具体例子：我自己写文章喜欢在每节末尾留一句"传接话"，把读者引到下一节，这种风格在通用模板里是没有的。后来我在排版 Skill 里加了一条"每节结尾保留一句自然过渡，禁止使用'接下来我们看看'这类机械表述"，版式立刻就有了个人味道。这类微调是别人没法替你做的。

6.2 人工把关人这笔账，不能省

第二点心得，流程再顺也要留一位"人工把关人"。AI 能把一篇稿件从 60 分推到 90 分，但剩下的 10 分在于判断力：这里的架构图有没有歪、这个结论表达是否准确、这个引用块是不是放错了位置。我自己的流程里，最后一公里永远是人工阅读，这既是质量红线，也省得未来花更多时间返工。

也要诚实说一句，Skill 不是万能的。它擅长的是把"确定性的格式化工作"做快做好，但在内容层面的原创洞察、情感共鸣上，能力仍然有限。所以我的定位一直是：让 AI 做那些重复的、确定性的、消耗精力的事，把省下来的精力留给真正需要判断力和创造力的部分。

如果你也经常为技术文章的头图、架构图、排版发愁，我建议你先把这套流程复制过去，用一篇文章从头到尾完整跑一遍。跑通之后你可能会发现，发布这件事，可以比想象中从容得多。