你的 AI 工具箱——无状态 API 脚本和 AI Agent 怎么配合

这是「AI 之路进阶升级指南」第四周 Day 12 的骨干教程。你需要先完成 Day 8、Day 10 和 Day 11。

Day 11 结尾我留了句话：下一步，怎么把这些动作自动化。

今天回答这个问题。API 和自主执行型 AI（AI Agent）怎么配合，和我以前拆流程、做系统设计和开发的任务，属于同一性质的问题。刚好最近我在做一个 AI 生成绘本的项目，我觉得很有代表性，这篇就把绘本项目的流程和任务设计思路拆解开来，演示给大家看。

先把术语说清楚。自主执行型 AI 和 AI Agent，说的是同一个东西：有上下文、有状态感知，记得前面说过的话，边做边调整方向。它由无状态的大模型 API 驱动：每次调用都是单轮请求，用完即走。状态由 Agent 自己维护。后面文章里两个词我会混着用，指向同一个概念。

先说说那个项目。孩子学英语高频词（Dolch）遇到瓶颈，我想找配套绘本带他读。翻遍了市面上的资料，全是闪卡和练习册，硬是找不到一套合适的故事绘本。

既然没有，那就自己做。可我又不会画画，只能请 AI 帮忙。Dolch 一共 220 个词、5 个等级，全做完是 220 个词配套的绘本。

PP 级是 Pre-Primer，英语启蒙第一级。我先拿它练手：40 个词，10 本，71 页。主角是 Sam 小猫、Pip 小鸟和 Ben 大狗。每本 6-8 页，每页一句简单英文，配一张水彩插画。10 本加起来 71 页、71 张图，一张张手工生成，我到现在还在画。

光排词表就是个大工程：高频词得循序渐进。哪个故事放哪些词，光这 40 个词的编排我就得忙一个月，更别说照着词编故事了。这活天生适合向 AI 许愿。

愿望是许了，一动手就发现不对。全丢给 AI，又贵又慢，一个故事能折腾半天。

我停下来重新想：这活到底包含哪些事？拆开一看，至少有六件：排词表、定故事和角色、打磨文本、写图片提示词、生成图片、校对。这六件事，各有各的干法。怎么配，正是今天要讲的。

成品不是重点。重点是底层逻辑：为什么这件事能批量做，批量做的时候，哪一步该交给谁。

先分清楚：什么活交给谁

判断标准就一条：

这件事能不能定下来？ 提示词、流程、输出格式都能定死：写成脚本，调 API 跑，做一次和做一百次一样。定不下来的，交给自主执行型 AI。探索、试错、临场判断是它的活。它的职责不是替你执行，而是把任务变成能定下来的东西：脚本、提示词、表格。

绘本项目里的分工是这样的：

• 写故事文本和插画提示词：一次性的探索判断。每个故事要设计情节、嵌入词汇、控制句型，还要按角色视觉指南写每页的插画提示词，交给自主执行型 AI。
• 生成 71 张插图：同一个动作重复 71 次，提示词都已经写好，不需要任何判断，交给 API 脚本，一张一张排着队跑。
• 验收：词汇够不够、页数对不对、图画得怎么样，人加 AI 一起查。

记住这条分界线：写提示词是判断活，跑提示词是体力活。判断活做一次，体力活交给脚本。 这就是组合的核心。

批量绘本流水线：五步

先看全景，再进细节：

设计约束先行 → AI 生成结构化表格 → 脚本解析 Markdown → API 批量生成/下载图片 → 规则 + 人工验收

每一步的产出是下一步的输入，中间断在哪一步，后面全停。

第一步：设计约束先行

动手写第一个故事之前，先把约束定死。PP 级的约束围绕两件事：词汇怎么分配，文本长什么样。

词汇分配。整个 PP 级只有 40 个高频词，分到 10 本里。每篇 4-5 个新词，最后一篇 PP10 收尾只引 3 个，后一篇必须复现前一篇的词。分配表在写故事前就定好了：

文本约束：每页 1-2 句、每句 3-5 词、整篇 30-60 词，只用简单句型（比如 I can see... 这种 S + can + V）。角色视觉指南：Sam 是橙色虎斑小猫、白胸脯、绿眼睛；Pip 是蓝色小山雀；Ben 是棕色大狗。每页的插画提示词都必须遵守。

硬指标：新词在故事里至少出现 3 次，复现词至少 1 次，每篇页数固定。

这些就是 Day 10 讲的 Constraints。先写下来，后面每一步都有验收依据。

第二步：AI 生成结构化内容

让自主执行型 AI 按约束生成故事。每个故事落成一张四列表格：

一页一行。四列分别是：页数、画面描述（中文，人看的）、故事文字（英文，绘本正文）、插画提示词（英文，喂给图片 API）。

这一步是整个流程最关键的设计决策：AI 的输出不是一段话，而是一张结构化表格。

第三步：脚本解析表格

表格写好后，剩下的全是体力活。一个 Python 脚本读这个 Markdown：按故事标题（# PP01、# PP02……）拆成 10 个部分，再按 | 拆列，每页得到一条插画提示词：

import re

def parse_pages(md_path):
    text = open(md_path).read()
    pages = []
    # 按故事标题切分
    for part in re.split(r'\n(?=# PP\d+)', text):
        name = re.search(r'^# (PP\d+)', part, re.M)
        if not name:
            continue
        # 定位表格区域（此处假设表头固定为 "| 页 |"，生产环境可用 r'\|\s*页\s*\|' 做更容错的正则匹配）
        table = part[part.find('| 页 |'):]
        for line in table.split('\n'):
            cells = [c.strip() for c in line.strip('|').split('|')]
            if len(cells) < 4 or not cells[0].isdigit():
                continue
            pages.append({
                'story': name.group(1),
                'page': int(cells[0]),
                'prompt': '|'.join(cells[3:]).strip()  # 第 4 列起，含全局约束（画风、主角外观）
            })
    return pages

核心就两件事：正则切分故事、按竖线拆列。表格格式是固定的，脚本就敢假设"第 1 列是页数、第 4 列是提示词"。

注意：表格里的第 4 列不是随手的描述，是全局约束拼好的 Prompt：画风、主角外观、场景规则都在里面。提示词写得太简陋，脚本跑得再顺，出来的图也会崩。第二步的质量直接决定第四步的产出。

第四步：API 生成图片

有了提示词列表，调用图片 API。每张图把提示词写进临时文件，调一次接口，从返回的 JSON 里取图片 URL。拿到就下载保存。

这个接口是同步的：调一次，等它把图生成完返回 URL，再调下一张。71 张图排着队跑完，小半个钟头，人不用守着。手工一张一张点的话，光等待就是大半天。

第五步：验收和修正

生成完不等于完事。检查清单：

• 词汇统计：每个新词出现 ≥3 次了吗？写个脚本数一遍，比人眼快
• 页数词数：每篇符合设计文档的硬指标吗？
• 图片完整性：71 张都下载成功了吗？失败的重新生成
• 审计：每次 API 调用记录到日志（时间、提示词、响应、图片 URL、文件大小），出了问题能追溯

画坏了的图（角色比例不对、画面模糊），挑出来一起重新生成，不用整批重跑。这就是把流程定下来的好处：重跑只是再调一次 API，成本几乎为零。要是每次都让自主执行型 AI 从头跑一遍流程，token 就浪费在重复的工作上了。

中间产物即协议

整个流水线能跑通，靠的是那张四列表格。

表格是人和 AI 的约定，也是所有脚本的输入协议。脚本不认识"故事"，只认识"第几页、什么提示词"。AI 生成的内容必须落到这个格式，脚本才能处理。

两个好处：

改一处，处处变。 想给 PP01 加一个新词？改表格里对应行的故事文字，重新生成图片、重新统计词汇，其余 9 个故事完全不受影响。

验收有据可依。 表格本身就是验收清单：页数对不对，数行数；词汇够不够，统计单元格。

Day 10 说 GCO 的输出要明确。在项目层面，明确的输出就是这张表。格式定得越清楚，下游脚本越好写。

把脚本变成工具

流水线跑通后，脚本还停留在"跑一次改一次代码"的阶段：输入路径写死、模型名写死、输出目录写死。换个故事集就得改代码。

两个改造，让它变成可复用工具：

命令行参数。用 argparse 把关键选项变成参数：

import argparse

parser = argparse.ArgumentParser(description="批量生成绘本插图")
parser.add_argument("--input", required=True, help="故事 Markdown 路径")
parser.add_argument("--output", default="static/images", help="图片输出目录")
parser.add_argument("--story", help="只生成某篇，如 pp01")
parser.add_argument("--pages", help="只生成指定页，如 3,5")
args = parser.parse_args()
print(f"正在处理 {args.input}...")

之后跑批：

python batch_generate.py --input pp-storybook-complete.md

# pp01 第 3、5 页画坏了，挑出来一起重新生成
python batch_generate.py --input pp-storybook-complete.md --story pp01 --pages 3,5

脚本和工具的差别：脚本是给自己一次用的，工具是能反复用、能换输入、能分享的。

改造成本就两步：把流程里会变的部分（输入路径、输出目录、哪本书、哪几页）提取成变量，再写成 argparse。这活交给 AI 做很方便，几分钟的事。工具写好后，以后这类任务都能直接复用，光省下的时间和 token 就很值了。

配置文件。API Key、默认模型、图片尺寸这类不常变的选项放进 config 文件，脚本启动时读取。改配置，不动代码。

常见问题

“我不会写脚本怎么办？”

让自主执行型 AI 写。你用 Day 10 的 GCO 描述清楚流程，写出来用 Day 11 的方法验收一遍，脚本就归你了。这个项目的生成脚本就是这么来的：我描述流程，AI 写代码，我检查它写得对不对。

“API 贵还是订阅贵？”

不是看哪个贵，是看分工。

自主执行型 AI 的产出是脚本：根据任务想清楚流程，把提示词写好。脚本写出来，生成图片就成了确定的任务。不用再判断，直接调 API 跑。

顺带说一句：订阅本质上也是 API，只是计费方式不同。TOS 没有明确禁止的话，自己本地使用，订阅一样能驱动你自己的脚本和自主执行型 AI。所以真正的分界不是按量还是订阅，而是任务能不能定下来：能定下来的走程序化调用，定不下来的交给自主执行型 AI 判断。

绘本项目每加一本新书，AI 写新脚本，图片照样由脚本调 API 生成。重复执行的部分永远走程序化调用，根据任务写脚本只需要做一次。

“会不会太复杂？”

拆开就两个动作：AI 生成结构化内容，脚本批量执行。复杂的是设计约束那部分，而那部分只做一次。

今日收获

• 能按"能不能定下来"给任务分工
• 理解批量流水线的五步：约束 → 生成 → 解析 → 执行 → 验收
• 明白"中间产物即协议"：格式定清楚，下游脚本就好写
• 会给脚本加命令行参数，从"改代码"到"改参数"

下一篇 Day 13 练习，把这条流水线亲手跑一遍：用 API 批量生成一批内容，再让自主执行型 AI 审核筛选。两个工具接力干活，体会一次就知道。

这是「AI 之路进阶升级指南」第四周 Day 12 的骨干教程。上篇是 Day 11 输出质量检查，下篇是 Day 13 组合实战。