你有没有过这种时候。稿子明明写完了，一想到还要往 CSDN、掘金、博客园、知乎各发一遍，手指头就悬在发送键上不想按下去。

我有，而且持续了两年。我是狗哥，javadog.net 是我自己的博客。后来真扛不住了，给自己造了三个 Skill，串成一条流水线。今天聊聊它们分别干了啥，坑又踩在哪儿。

前言

🍊 缘由

压着我的第一件，是排版。同一篇稿子要伺候五个平台，CSDN 吃搜索意图和教程完整性，掘金看工程深度和能不能复现，公众号得有强开头还得照顾手机端，博客园认原创推理和证据。改到第三遍的时候人已经麻了，后面两遍基本是在敷衍自己。

第二件是 AI 写的稿，味儿太冲。冲在「首先、其次、总而言之」的模板腔，也冲在张口就来的 benchmark 和真假难辨的「我实测过」。发出去评论区一眼看穿，比不写还丢人。

第三件，图片。纯粹的老大难，本地截图和 AI 生成的配图，路径全是 ../images/xxx.png，一发到线上就全裂，封面还得按每个平台的尺寸重做四张。

这三件事，我全用 Skill 解决了。

🎯 主要目标

这篇文章带你走完一条我自己在跑的线，从初稿到能直接粘贴发布。

• 一篇稿子怎么自动适配五个平台，顺手把 AI 味压下去
• 四张封面加四张底图怎么一次出齐，中文标题一个字不错
• 本地图片怎么批量上图床，路径全自动换掉，源文件一个字不动

👽人话解释
Skill 这东西，就像你给厨房接好的一套固定管线。洗菜、切菜、下锅，管子铺好了，你只管往里扔食材。每顿饭都重新摆一遍刀和砧板，那不叫做饭，那叫行为艺术。

正文

🍪 三个 Skill，一条流水线

1. polish-technical-blog，我的主编

三个里最核心的一个。它把「打磨一篇技术文章」这种很主观的事，拆成了能跑、能打分的流程。

评分表是这么回事，100 分制，9 个维度。技术准确性 20 分，完整性 15 分，实用价值 15 分，结构和可读性 15 分，原创性和作者声音 10 分，可视化表达 10 分，标题和正文匹不匹配 5 分，搜索可发现性 5 分，平台发布规范 5 分。

有分数，改稿才有方向。以前全凭感觉，改来改去也不知道改好没改好。

它会去 AI 味，专门揪那些伪造的「我亲手跑过」、没法证伪的精确数字、套模板的过渡句。

碰到高风险结论还要做事实核查，按「官方文档 → API 文档 → release notes → 设计提案 → 源码和测试 → 可复现实验」这个顺序一路查下去，查不实的就标成推测，不许混进正文当结论。

最后是平台适配，每个平台一套侧重点，收尾跑一遍 check_markdown.py 和 verify_assets.py，把 Markdown 语法和图片引用统统校验一遍。

不过说实话，这套东西里最值钱的不是流程，是我在 SKILL.md 里写死的那几条硬规矩。

• 永不把编造的经历、benchmark、日志当成真实体验写进文章
• 永不把规划中的功能说成已上线
• 永不伪造产品截图，复现不出来就画张示意图，还得明确标注
• 截图里的密钥、token、个人数据、内网域名，先打码

👽人话解释
写在 prompt 里的要求像便利贴，写完一忙就不知道贴哪儿了。写进 SKILL.md 的 Hard Rules 是把规矩刻在墙上，每天进门都得看一眼，跑不掉。

2. create-blog-cover-set，一次出全套封面

一篇文章要四张封面，尺寸各不一样。

这个 Skill 一次生成 4 张封面，外加 4 张无字底图。

这里有个坑我踩得挺实在。最开始图省事，让生图模型把中文字一起画了，结果十个里九个是乱码，要么缺笔画，要么多一坨。后来改成 AI 只出「无字底图」，吉祥物、背景、留白，别的都不管。标题、副标题、角标这些中文字，全交给 Python 的 PIL，加载本地的 simhei 字体，算好坐标画上去。

这么一来文字永远不会错。附带的好处是我没想到的，同一张底图换个标题就能给下一篇文章用，等于白嫖自己。

核心脚本 compose_cover.py 就干这点事，裁切、排版、画字、导出。

3. upload-markdown-images-to-upyun，图片托管

图片托管这块，我图床用的是又拍云，域名 img.javadog.net。

这个 Skill 干的是扫出 Markdown 里所有本地图片引用，批量上传到又拍云对象存储，然后把文中的本地路径全换成公网 URL。默认输出一份 xxx-upyun.md，源文件一个字不动。

上传前先做冲突检测，远端已经有同名文件的会拦下来让你确认。传完再做 MD5 和文件大小校验，全过了才算成功。

签名是在 PowerShell 里用 HMAC-SHA1 现算的，凭据只从环境变量读，不在对话里硬编码。

有个小细节我觉得挺重要，脚本支持 -PlanOnly，先干跑一遍，把要传哪些图、传到哪个 URL 全列出来给你看。确认没问题了再真传。批量操作这东西，怕的就是「我以为传的是这几张」。

🍊 真实成果，一篇文怎么被这条线跑通的

拿我最近写的《掘金 AI 用量统计》举例。

初稿丢给 polish-technical-blog，它给我打了分，列了扣分点，还挑出三个最值得改的地方。

我照着改，重点删掉两处编造的实测数据，还有一堆套话过渡句。然后跑 create-blog-cover-set，四张封面四张底图，横幅、方卡、博客封面一次到位。

配图交给 upload-markdown-images-to-upyun 传上图床，产出一份 -upyun.md。

最后拿着这份图床版，往 CSDN、掘金、博客园、公众号一粘，图片全在，封面不用另做。

搁以前，光是改五个平台的排版加做封面加传图，一整晚就没了。现在跑一遍流水线，剩下的活儿就是复制粘贴。

🎯 几条踩出来的经验

有几个我觉得值得单拎出来说。

中文字别交给模型，交给代码。 PIL 加本地字体，确定性百分之百，还不要钱。让生图模型写中文这事儿，我翻车翻到怀疑人生。

图片先裁剪再降质，顺序反了会又糊又大。我给自己卡的上限是 1MB。

批量脚本一定要有预览模式。就是前面说的 -PlanOnly，这玩意救过我好几回。

「AI 味」这词儿挺玄的，交给感觉基本没救。拆成九个能打分的小项之后，改稿就知道该动哪儿了。

还有一条我自己最在意，红线得写进 Hard Rules，别写在 prompt 里。

总结

🍪 最后说点感受

我拿 AI 写文章那会儿，每次开新对话都要重新交代一遍，别编数据、别套模板、注意配图、注意封面。交代一遍自己还忘一半。现在这些全躺在三个文件里，触发就执行，规则丢不了。

最值钱的还是那些硬规矩和评分标准。条条框框背后是我的审美，也是我的底线，现在它们替我盯着每一次产出。说实话这套东西也谈不上完美，够用，但远没到能撒手不管的程度。

如果你手上也有件每周都要重复、步骤还特别多的事，真别再用 prompt 硬怼了。花点时间把它做成一个 Skill，做完你会回来谢我的 🍊

🍈猜你想问

如何与狗哥联系进行探讨？

关注公众号【JavaDog程序狗】，回复【入群】或【加入】，一起聊技术、聊踩坑。