Claude Code加Draw Things本地配图实战：Mac上零成本自动出图完全指南

摘要：写技术博客最磨人的往往不是写代码、理逻辑，而是配图——找图、抠尺寸、怕侵权，一篇文章光配图就能耗掉小半天。这篇讲的方案，是把Claude Code和Mac上的Draw Things用MCP协议接起来：Draw Things负责在你本机离线生成图片，Claude Code负责理解你要什么、调它出图，整条链路完全本地、不联网、零生成成本。你只要一句“给这篇文章配一张深蓝科技风的封面、再来两张正文插图”，它就把活干完。文章会拆清这套三层架构怎么搭、三步装好环境、这套MCP给了Claude哪几件生图工具、提示词怎么写才出好图、它比Midjourney这类云服务到底强在哪，以及一个做SEO的人绝不会跳过的环节——图生出来之后，压成WebP、配好alt、做好OG图，才算真正对得起这篇文章的流量。

为什么说“配图”才是写技术博客最磨人的一环？

写过技术长文的人都有体会：真正卡时间的，常常不是把技术讲清楚，而是配图。一篇文章动辄要一张封面加两三张插图，你得去图库翻、去搜索引擎找，找到风格对的还得担心版权，尺寸不对要裁，色调不统一要调，来来回回，写文一小时、配图四十分钟是常态。更别说免费图库里那些被用烂了的素材，放上去一股廉价感，跟你辛苦写的干货完全不配。

这就是为什么“让AI自动配图”是个真需求，而不是噱头。但市面上的主流方案——Midjourney、DALL·E这些，要么按月订阅、要么按张计费，还得把你的创意和数据传到别人的服务器上。对一个高频产出的内容团队，这既是持续的成本，也是隐隐的隐私顾虑。保哥一直做内容和SEO，深知配图这道工序的隐性成本有多高，所以当“完全本地、零成本、还能批量”的方案出现时，是真值得认真讲一讲。

把配图这件事的成本再拆细一点你会更有体感。一篇文章的配图，表面看是“找几张图”，实际包含搜图、筛选、确认版权、下载、裁剪尺寸、统一色调、压缩体积、写alt这一长串动作，每一步都要切换工具、消耗注意力。注意力的切换成本最隐蔽也最伤——你刚把一段技术逻辑理顺，转头去翻图库，再回来思路已经断了。一套能把“配图”这整条尾巴自动接掉的方案，省的不只是那四十分钟的操作时间，更是保住了你写作时最宝贵的连续专注。这也是为什么更应该把它当成一个“写作流程的解放”，而不仅仅是“省了张图钱”。

顺带提一个被很多人忽视的角度：配图的质量和一致性，本身也是E-E-A-T信号的一部分。Google越来越看重内容的专业度和用心程度，一篇满是廉价图库素材、风格东拼西凑的文章，传递的信号是“随手凑的”；而通篇配图风格统一、贴合主题、清晰专业，传递的是“认真做的”。读者也一样，视觉的用心会无声地抬高他们对内容专业度的信任。所以本地AI配图省的是成本，但它真正的回报，是让你有能力低成本地把每篇文章的视觉都做到位——这件事过去只有预算充足的团队才做得起，现在小团队也够得着了。

Claude Code加Draw Things这套本地方案是怎么搭起来的？

先把架构讲清楚，你才知道每一块在干嘛。这套方案是三层结构，像一条流水线。

最上层是Claude Code，扮演大脑：它理解你的自然语言指令，决定要生成什么图、用什么参数。最底层是Draw Things，扮演画师：它是一款macOS（也支持iOS、iPadOS）上的原生应用，能把Stable Diffusion这类模型跑在你本机的芯片上，在本地离线生成图片。Draw Things官方主打的就是“完全在设备上离线运行以保护隐私”，有免费版可直接用。问题是，Claude Code和Draw Things本来语言不通，中间需要一个翻译——这就是中间层mcp-drawthings，一个开源的MCP服务，把Claude Code发来的指令翻译成Draw Things能听懂的HTTP请求。

串起来就是：你对Claude Code说人话，Claude Code通过mcp-drawthings这个MCP桥接，把请求转发给本机7860端口上的Draw Things，Draw Things算完图、把结果回传。整条链路跑在你自己电脑上，一个字节都不出本机。这套设计的精髓，是用MCP这个开放协议，把“会聊天的AI”和“会生图的本地引擎”焊在了一起——而MCP正是Claude Code能接万物的那套通用接口，搞懂它你就能依葫芦画瓢接入更多本地工具。

为什么要专门有mcp-drawthings这个中间层，不能让Claude Code直接连Draw Things？因为两者的“语言”不一样。Draw Things对外暴露的是一套HTTP接口（兼容Stable Diffusion那套API风格），而Claude Code理解的是MCP工具调用。中间这个桥接层做的就是翻译：把Claude发起的MCP工具调用，转成Draw Things能识别的HTTP请求，再把返回的图片结果按MCP的格式回传。这种“用一个轻量适配器把现有工具包装成MCP服务”的模式，是MCP生态里最常见的玩法——大量本地工具、数据库、API都是靠这样一层薄薄的桥接接进Claude Code的。理解了这个套路，你看任何一个MCP服务都会觉得亲切，无非是“某个工具＋一层MCP翻译”。如果你想把更多本地工具接进来，配置方法上可以参照Claude Code的MCP安装与配置实操，原理是相通的。

三步配好环境，到底难不难？

不难，核心就三步：开Draw Things的API、把MCP接上、验证连通。

第一步，装好Draw Things（App Store免费下），打开它的API Server。在应用设置里找到API Server选项启用，它会在本机127.0.0.1:7860上起一个本地服务，这是Claude Code待会要连的入口。第二步，用一条命令把MCP服务挂到Claude Code上：

claude mcp add drawthings -- npx -y mcp-drawthings

这条命令的写法值得说一句：--这个双横杠是分隔符，它前面是给Claude Code的参数（服务名drawthings），后面是真正要执行的命令（用npx拉起mcp-drawthings）。这个分隔符漏了，命令就会解析错乱，是新手最常见的坑。Claude Code的MCP官方文档里把--的作用和各种作用域讲得很细，配置出问题时回去对一遍准没错。第三步，验证。可以直接用curl探一下Draw Things的接口：

curl http://127.0.0.1:7860/sdapi/v1/options

返回一串JSON配置，就说明API活了。再在Claude Code里让它检查MCP连接状态，两头都通，环境就齐了。整个过程，Node.js需要18以上的版本，这是mcp-drawthings运行的基础，报“command not found”多半是Node太老或没装。

配置存在哪也值得知道，排查问题时用得上。用claude mcp add加的本地服务，配置写在你用户目录的~/.claude.json里，按项目隔离。想确认装没装上、连没连通，可以用claude mcp list看所有已配置的服务和状态，用claude mcp get drawthings看这一个的详情。哪天不想要了，claude mcp remove drawthings一条命令卸掉。这些管理命令配合前面的连通性验证，基本覆盖了从装、查、用到卸的全流程，遇到“好像没生效”的情况，先用list和get看一眼当前状态，往往一眼就知道问题出在哪——是没加上、还是Draw Things那头没起来。把这套排查动作记熟，比每次出问题就重装一遍高效得多。

这套MCP给了Claude哪几件生图工具？

挂上mcp-drawthings后，Claude Code就多了几件能直接调用的工具，搞懂它们你才知道能让它干什么。

核心是四件。check_status查Draw Things在不在线，干活前先确认引擎就绪。get_config拿当前配置，比如现在加载的是哪个模型。generate_image是主力——文生图，给它一段提示词，它生成图片。transform_image是图生图，喂它一张已有图加提示词，它在原图基础上重绘，常用来统一风格或微调。

generate_image的参数决定了出图质量，值得记几个关键的：prompt是图像描述（必填），negative_prompt是你不想要的元素（比如文字、水印），width和height是尺寸，steps是采样步数（越多越精细也越慢），cfg_scale控制对提示词的贴合程度，seed是随机种子（固定它能复现同一张图），model指定用哪个模型，output_path是保存路径。好消息是你不用手填这些——你用自然语言把要求说清楚，Claude Code会替你翻译成合适的参数。这正是它比直接调API顺手的地方：你管表达意图，它管调参。

check_status和get_config这两个看着不起眼的工具，实战里其实很关键。批量生成前先check_status确认引擎在线，能避免“跑了一半发现Draw Things没开、白等一场”的尴尬；get_config让Claude先看清当前加载的是哪个模型、什么配置，它才能据此决定要不要切模型、用什么参数。这种“干活前先探一探环境”的习惯，是让自动化流程稳定的关键——人会下意识地先看一眼工具状态，AI也需要这两件工具替它“看一眼”。理解了这点，你在让Claude批量生图时，就会主动提醒它先确认状态，整条流程的成功率会明显提高，少很多莫名其妙的失败。

一条指令同时产出文章和配图，工作流长什么样？

把工具串起来用，才见威力。一个典型的“写文加配图”一条龙是这样跑的。

你对Claude Code说：“帮我写一篇讲MCP的技术文，存成index.md，再给它配一张深蓝科技风封面和两张正文插图，封面1200×630，全部存到文章目录。”它会先check_status确认Draw Things在线，get_config看当前模型，然后一边把文章写出来，一边并行调用generate_image生成封面和插图，最后把markdown和图片一起放进你指定的目录。原本要在写作工具和绘图工具之间反复横跳的活，被压成了一句指令。

这种“内容和配图同源产出”的好处，不只是省时间，更是风格一致。同一次对话里生成的几张图，色调、构图、视觉语言天然统一，不会像东拼西凑的图库素材那样各说各话。如果你想让一个系列文章的视觉保持一致，还能用transform_image拿一张定好风格的基准图去“带”出后续的图，把品牌视觉锁死。这套打法跟用合适的MCP服务把外部能力接进Claude Code的整体思路是一致的：让AI不止会说，还会动手调用真实工具完成闭环。

再往前一步，这套流程能做到真正的批量化。设想你有一个产品清单，想给每个产品配一张统一风格的场景图——你完全可以让Claude Code读取清单，逐个产品按同一套提示词模板（只替换产品名和卖点）调用generate_image，把几十上百张风格一致的图一次性生成、自动按产品命名存好。这种活手工做是噩梦，用代码驱动却是它的舒适区：内容靠数据填、风格靠模板锁、生成靠循环跑。把生图嵌进这种批处理流程，你才算把本地AI配图的规模优势真正吃透——它最大的价值从来不是“生成一张好图”，而是“稳定地生成一百张风格统一的好图”。这一点，是任何点开网页一张张生成的云服务都很难比的。

提示词到底怎么写，AI才肯生出能用的图？

同样一个模型，提示词写得好不好，出图质量天差地别。这里有套能直接抄的公式。

一个靠谱的图像提示词，大致是“主题描述＋风格＋色调＋构图＋技术关键词”的叠加。比如要一张AI编程主题的科技插图，可以这么写：

A futuristic tech illustration about AI programming automation,
dark background with blue and purple gradient, neural network patterns,
clean modern style, no text

negative: text, watermark, blurry, low quality, deformed

拆开看：主题是“AI编程自动化的未来科技插图”，风格是“干净的现代风”，色调是“深色背景加蓝紫渐变”，元素是“神经网络纹理”，再用no text明确不要文字。负面提示词里把“文字、水印、模糊、低质、畸形”这些常见瑕疵排掉。技术博客配图有个反复要强调的点：务必在负面提示词里排除文字，因为AI生成的“文字”几乎全是乱码，留在图里特别廉价。

负面提示词这块多数人写得太随意，其实它和正面提示词同样重要。正面提示词告诉模型“要什么”，负面提示词告诉它“别给什么”，两边一夹，出图才稳。除了文字水印，常用的负面词还有：blurry（模糊）、low quality（低质）、deformed（畸形，画人画手尤其要加）、extra limbs（多余肢体）、oversaturated（过饱和）。你可以攒一套自己常用的负面词模板，每次生成都带上，能挡掉大部分翻车。需要提醒的是，负面提示词不是越多越好——堆太多反而会干扰模型，挑那几个跟你这张图最相关的瑕疵排掉就够了。把正负提示词当成一对协作的工具来用，而不是只顾着写正面那半句，是出图质量上一个台阶的分水岭。这也是Claude Code能帮上忙的地方：你说清楚要什么、不要什么，它替你组织成规范的正负提示词。

模型的选择也讲究。要科技感、速度快，用Flux.1 Schnell，几步就能出图；要写实质感，用Juggernaut XL这类；要插画风，DreamShaper XL更合适；只是快速试构图，SD 1.5够用。不同模型对步数和cfg_scale的最佳值不一样，这些Claude Code大多能帮你拿捏，但你心里有个谱，提需求时就能更准。

提示词还有几个进阶技巧值得记。一是权重：很多模型支持给某个词加权重，让它在画面里更突出，比如想强调蓝紫色调就把它的权重提一点。二是构图词：加上诸如“居中构图”“留白”“俯视视角”这类描述，能让出图更符合版面需求，而不是每次都靠运气。三是风格锚定：如果你已经有一套确定的视觉风格，把那几个最能定调的关键词固定下来当模板，每次生成都带上，整站视觉就稳了。四是迭代而非一步到位：第一版别指望完美，先用低步数快速出几张看大方向，选中一个再固定种子、提高步数精修。这套“先广撒网、再聚焦精修”的节奏，比闷头调一张图高效得多，也正是Claude Code擅长配合的——你让它一次生成几个变体，挑一个再让它在那个基础上继续调。

不同模型到底怎么选，各自擅长什么？

很多人卡在选模型上，要么一直用默认的、出图总差口气，要么被一堆模型名字绕晕。其实记住几个主力、按场景对号入座就够了。

Flux.1 Schnell是“快”字当头的代表，schnell在德语里就是“快”的意思，它专为少步数快速出图优化，三五步就能给一张质量不错的图，特别适合技术博客那种要量、要科技感、又不想等的场景。SDXL系列是通用主力，分辨率高、画面扎实，是“不知道用啥就先用它”的稳妥选择。Juggernaut XL是SDXL的写实强化版，要照片级真实质感——产品图、人物、场景写实——它表现突出。DreamShaper XL偏艺术和插画，要那种有设计感、不那么写实的风格，它更对路。SD 1.5是老将，速度快、资源占用小、社区模型和LoRA最丰富，快速试构图或在低配机器上跑很合适。

选模型有个朴素的原则：先想清楚你要的是“真实照片感”还是“插画设计感”，是“要快”还是“要精”，两个维度一交叉，对应的模型基本就定了。步数和cfg_scale这些参数，不同模型甜区不同——Flux.1 Schnell几步就够、步数堆多反而没意义，SDXL系列则需要二十步上下才够精细。这些细节Claude Code大多能替你拿捏，但你心里有这张地图，提需求时就能直接说“用Flux出个科技封面”，而不是含糊地说“画张图”，沟通效率高得多。模型不是越新越好、越大越好，合不合适才是关键。

图生图transform_image能玩出哪些花样？

前面四件工具里，transform_image（图生图）最容易被忽略，但它恰恰是把AI配图从“碰运气”变成“可控生产”的关键一环。文生图是从一段文字凭空造图，结果有随机性；图生图是给它一张已有图当底子，让它在这个基础上重绘，确定性高得多。

它有个核心参数叫denoising_strength（重绘强度），决定了改动幅度：0.1到0.3是轻微调整，基本保留原图只动细节；0.4到0.6是中等变换，构图还在但风格明显变了；0.7到1.0是大幅重绘，原图只剩个大概轮廓。理解这个参数，你就能精确控制“改多少”。

实际能玩的花样不少。最有价值的是统一系列视觉风格：你先精心做一张定调的基准图，然后用图生图、配低重绘强度，把后续每张图都往这个风格上“带”，整个系列的色调、质感就锁死了，这对品牌视觉一致性是杀手锏。其次是截图美化：把朴素的产品截图喂进去，加一点风格化重绘，让它更有设计感再上站。还有风格迁移：把一张构图满意但风格不对的图，用图生图换成你要的画风。把文生图和图生图组合起来用——文生图定内容、图生图控风格，你对AI配图的掌控力会上一个台阶，不再是“生成一堆碰运气挑一张”，而是“想要什么就稳定地拿到什么”。

为什么非要“本地”，它比Midjourney强在哪？

有人会问，云端的Midjourney、DALL·E那么成熟，何必折腾本地？这背后是四笔账，对内容团队尤其是出海团队，每一笔都不轻。

第一笔是成本。Claude Code加Draw Things本地生成，单张图的边际成本是零；Midjourney月费十几到几十美元，DALL·E按张计费，高频产出累积下来不是小数。第二笔是隐私和数据合规。云服务要把你的提示词、有时还有参考图传到对方服务器，对在意商业机密、在意数据不出境的团队，本地方案“一个字节不出本机”是实打实的安全感——做外贸的都知道，数据合规这根弦越来越紧。第三笔是速度和稳定。本地生成不排队、不受网络波动影响，一张512图在M系列芯片上几秒出货，批量跑也不怕被限流。第四笔是无限制，没有每月配额、没有内容审查的额外摩擦。

当然本地方案也有代价：吃你本机的算力，老机器或没独显的会慢；模型要自己下载管理，初次配置比点开网页费点事。所以保哥的判断是看用量——偶尔配几张图，云服务点开即用更省心；但凡你是高频、批量、长期产出，又在意成本和数据安全，本地方案这条路越走越香，前期那点配置成本摊下来几乎可以忽略。

这里再补一句对硬件的实在话。Draw Things跑得快不快，主要看你Mac的芯片。M系列芯片生成一张512尺寸的图，从M1的八秒上下，到M4的两秒左右，越新越快；用SDXL这种大模型或拉高分辨率，时间会成倍涨。如果你是Intel芯片的老款Mac，体验会明显打折，这种情况要么认了慢、要么考虑把重活交给前面说的云渲染或干脆用云服务。所以选不选本地，硬件是个绕不开的前提：手里是台还算新的Apple Silicon机器，这套方案如鱼得水；机器太老，硬上反而别扭。把这点想在前面，免得配置半天发现机器扛不动，白忙一场。

图生成完就完事了吗？配图的SEO收尾不能省

这一节是很多教程不会讲、但保哥必须强调的：图生出来只是半成品，对一个要吃自然流量的站点，后面的SEO收尾才决定这张图值不值钱。

第一件事是压成WebP。AI生成的PNG往往体积很大，直接上站会拖慢加载、伤Core Web Vitals。用cwebp或Python的PIL把它转成WebP并压到合理质量，体积能砍掉一大截，加载快了排名和体验都受益：

cwebp -q 85 -resize 1200 630 cover.png -o cover.webp

第二件事是尺寸规范。封面图统一到适合社交分享的比例（比如1200×630），正文配图按版面定好宽高，别让浏览器去缩放。第三件事是alt文字，这是图片SEO的命门——给每张图写一句准确描述图片内容、自然带上关键词的alt，既帮搜索引擎理解图片，也是无障碍访问的基本盘，关于这块的完整打法可以看原创配图怎么把自然流量做起来的拆解。第四件事是OG图，文章被分享到社媒时显示的那张预览图，尺寸和清晰度直接影响点击率，值得专门生成和优化，具体可参考OG社交分享图的尺寸与动态生成。

把这套收尾接到生成流程后面，你会发现Claude Code能一并包圆——让它生成图之后顺手转WebP、写好alt、产出OG图，一条龙下来，产出的不是一张孤零零的图，而是一张为SEO准备好的、即插即用的配图。这才是把AI配图真正用出价值的姿势。

展开说说alt这块，因为它是最被低估、又最影响图片搜索流量的环节。alt文字不是给它随便塞个关键词就完事，好的alt是用一句自然的话准确描述图片画面，顺带把这篇文章的核心词带进去，既让搜索引擎和读屏软件理解图片，又不显得堆砌。比如一张讲MCP架构的示意图，alt写“Claude Code通过mcp-drawthings桥接调用Draw Things生成图片的三层架构示意”，就比干巴巴一个“架构图”强太多。一个站点几百篇文章、上千张图，如果alt都认真写，积累出的图片搜索流量相当可观——这正是图片SEO里投入产出比很高、却常被忽略的一块。让Claude Code在生成图时顺手按图片内容生成准确的alt，等于把这件容易偷懒的事自动做对了。从这个角度看，本地AI配图和图片SEO其实是天作之合：一个负责高效产出，一个负责让产出被搜到。

做外贸独立站，这套配图流能落到哪些真实场景？

讲点能直接抄的。第一个是批量产品场景图。独立站上新一批SKU，需要统一风格的场景配图或氛围图，用本地方案批量生成，风格锁死、成本归零，比一张张找图或外包快太多。第二个是博客和落地页插图。高频更新的内容站，每篇文章的配图都靠它本地产出，告别图库的廉价感和版权焦虑。

第三个是系列视觉的一致性。一个专题、一个系列的所有图，用transform_image带着同一套风格走，整站视觉语言统一，这对品牌感的积累很关键。保哥合作过的一个做户外装备独立站的小团队，就用这套把博客配图的产出从“每篇愁半天找图”变成“写完顺手就有”，配图风格还前所未有地统一——读者未必说得出哪里好，但那种“整站很用心”的观感是实打实拉停留时长的。

第四个是本地化素材的快速试做。出海做不同市场，配图的审美和文化偏好不一样，想快速试几版不同风格看哪个对当地胃口，本地方案零成本、随便试，比每试一版都掏云服务的钱爽快得多。试错成本被压到零，你才敢多试，而多试往往才能撞出真正对的那一版。

这几个场景的共性，是“量大、要风格统一、又在意成本和数据安全”。这正好是本地AI配图方案的甜区。把配图这道一直拖后腿的工序工程化、自动化，对人手紧、预算紧的出海团队，省下的是真金白银和大把时间。配置一次，长期复用，这笔账怎么算都划算。最后给个落地建议：别想着一步到位搭完美流水线，先从“给下一篇文章配图”这一个具体动作开始，把环境装好、跑通一次，亲手感受一遍它的快和省，再慢慢把批量、风格统一、SEO收尾这些一层层加上去。工具的价值是用出来的，先动手跑通最小闭环，比研究一堆参数都管用。

常见问题解答

这套方案是完全免费的吗？

本地生成这条链路是免费的。Draw Things有免费版可直接用，本地离线生图零成本；mcp-drawthings是开源的；Claude Code按你的订阅算。相比Midjourney月费十几到几十美元、DALL·E按张计费，高频产出省下的成本很可观。Draw Things也有付费的云计算版，但本地生成用不到它。

Draw Things的API连不上怎么办？

按三点排查：一是确认Draw Things应用已打开、设置里的API Server已启用；二是确认它跑在本机7860端口；三是用curl访问127.0.0.1:7860的接口看是否返回JSON。三点都对MCP还连不上，重启一次Claude Code让它重新建立连接，多数问题能解决。

claude mcp add命令里的双横杠是干嘛的？

双横杠是分隔符，前面是给Claude Code的参数（如服务名drawthings），后面是真正要执行的命令（npx拉起mcp-drawthings）。漏了它命令会解析错乱，是新手最常见的坑。所有参数选项要放在服务名之前，双横杠之后才是启动MCP服务的命令。

生成的图带乱码文字，怎么避免？

在负面提示词里明确排除文字，写上text、watermark这些。AI生成的“文字”几乎都是乱码，留在配图里特别廉价。技术博客配图建议一律用no text加负面词双重排除，需要文字另用设计工具叠上去，别指望模型把字写对。

本地生成图片速度慢，怎么提速？

几招：选轻量快速的模型如Flux.1 Schnell，几步就能出图；适当降低分辨率和采样步数出草稿，定稿再高清；关掉占用GPU的其他应用。速度也吃硬件，M系列芯片越新越快，老机器或无独显的会明显慢一些，量大可考虑升级设备。

AI配图生成后，为SEO还要做哪些处理？

四步收尾：用cwebp或PIL把PNG转成WebP压缩体积，避免拖慢加载；统一封面和插图尺寸别让浏览器缩放；给每张图写准确自然带关键词的alt文字；为文章专门生成优化好的OG分享图。这套做完，图片才真正对得起文章的流量，Claude Code能帮你把这些一并包圆。