用代码调用 AI 生图，一个人也能自动化

2026-09-09 AI生图,代码自动化,接口调用,内容流水线

我那批 20 张涂色线稿如果靠手动一张张下载，光是改文件名和归档就够我忙一下午，所以第二天我就把它接进了脚本。下面就把用代码调用 AI 生图的方案怎么做这件事拆开讲。

用代码调用 AI 生图，关键不是选哪家接口，而是把"提交任务、拿结果、落盘归档、失败重试"这四件事写成一段能重复跑的代码。 下面是我实际用的顺序。

用代码调用 AI 生图的方案怎么做，先想清楚哪些事该自动化

不是所有出图都值得写代码。一次性、张数少、需要反复调提示词的图，手工跑更快。

值得自动化的场景有三个特征：提示词已经定稿、张数多、需要重复跑（比如每周固定出一批封面）。

我第一版脚本就是在一批图需要重跑三次之后才写的，那时候才明确知道哪些参数该固化。

第一步：把提示词做成模板，参数从外面传

不要把提示词硬编码在调用代码里。我的做法是模板里留几个占位符——主体、风格、比例、数量——跑的时候从清单文件读。

这样换一批图只需要改清单，代码一行不动。这一步做好，后面所有改动都变便宜。

第二步：一次提交，异步等结果

生图接口基本都不是瞬间返回的。常见的是先提交拿到任务标识，再轮询查状态，或者把结果回调到你的地址。

我踩过的坑是用同步思路写代码，一个请求卡在那里等图，一批跑下来要盯着不敢关窗口。

正确做法是把"提交"和"取回"拆成两个阶段，中间存一个任务记录。这样中途断了也能续跑，不用从头再来。

第三步：落盘和归档按用途走

拿到图之后立刻做的事：改成一个有意义的名字、放进对应的文章或项目目录、在记录里写上生成日期和提示词。

我一开始按时间戳命名，一周之后自己都认不出哪张是干什么的。文件名要带用途，不要带时间。

第四步：失败重试和限流，这步别省

批量跑一定会遇到失败：网络抖动、额度用尽、内容被拦截、返回格式异常。

我的处理是三件事：失败的任务单独记下来、设一个有限次数的重试、遇到限流就退避等待再继续。

另外额度、计费方式、并发限制这些每家都不一样，以服务商官方文档当天公布的口径为准，别照着别人的教程硬套。

容易卡住的两个点

第一个是密钥管理。 别把密钥写在代码里提交到仓库，用环境变量或者本地配置文件，并且把配置文件加进忽略列表。

第二个是别把脚本写成一次性。 我第一次写的版本里什么参数都是写死的，第二次要用的时候等于重写。现在我的脚本跑法固定是"喂一份清单、吐一个目录"，谁都能接手。

成本这件事怎么控

自动化之后最容易失控的是用量。手工出图你会有感觉，脚本跑起来是没有感觉的，一晚上可能就把额度跑完了。

我的做法是清单里写死数量上限，脚本按清单跑，不按循环跑。

另外每次跑完把实际用量记一行，隔一段时间回头看一次。不用精确核算，但要知道量级，不然等到账单出来才发现不对就晚了。

具体的计费规则和免费额度各家不同，以服务商官方口径为准，我只管好自己这边的阀门。

值不值得写这个脚本

回到"用代码调用 AI 生图的方案怎么做"，判断标准其实很简单：这件事你会不会做第二次。

只做一次的任务，写脚本的时间一定超过手工做的时间。我的 20 张线稿那批，如果只做一次，手工更快。

但它后来被我重跑了三次，每次都是改几个参数。到第二次的时候脚本就已经回本了。

所以我现在写脚本的门槛是"预期会重复三次以上"。低于这个数，先手工做，等第三次的时候再动手写。

常见问题

Q：用代码调用 AI 生图，需要专门的框架吗？

A：不需要。一段普通的脚本就够了，核心是把提交任务、轮询结果、下载落盘、失败重试这四段拆开写清楚，比引入框架更可控。

Q：批量调用会不会容易被限流？

A：会，尤其是并发跑太多的时候。做法是控制并发数、失败后退避重试，具体限制以服务商官方文档为准，别硬冲。

Q：生成出来的图怎么和文章对应上？

A：靠归档规则，不靠记忆。一份清单记录文章和图的对应关系，图按用途命名并放进对应目录，跑第二次的时候直接覆盖同名文件就行。