做这个项目的初衷其实挺朴素的。晚上给孩子读绘本的时候翻来覆去就那么几本孩子记得比我还熟读到第二页就开始抢答。我就在想能不能让AI根据孩子的喜好、年龄、甚至当天发生的小事现场生成一本完全专属的故事书WhimKid 就是在这样的场景里长出来的——一个面向儿童的AI故事绘本生成器。输入孩子的名字、年龄、兴趣爱好或者随便丢一个关键词比如“恐龙”“太空”“会飞的猫”它就能自动生成一个完整的故事配上插图、排版甚至生成语音朗读版本最后打包成一本像模像样的绘本。你可以在临睡前花三分钟给孩子变出一本全世界只此一册的书主角就是孩子自己。这篇文章我会把整个项目的思路、技术选型、实操细节和踩过的坑从头到尾捋一遍给想做类似方向的朋友一份能直接上手的参考。1. 为什么做AI儿童故事绘本这件事1.1 被睡前故事逼出来的需求有娃的家庭都懂睡前故事这件事看着温馨实际上是个不小的负担。市面上的绘本要么贵要么孩子已经翻烂了要么内容压根不对胃口。你讲《三只小猪》孩子说不想听他要听“奥特曼去月球找恐龙”这种根本不存在于任何出版物的故事。这时候如果你用通用聊天机器人去生成确实能编出一段文字但问题马上就来了纯文本没有配图孩子根本坐不住故事结构经常虎头蛇尾中间还可能出现不适合儿童的情节更别说把文字和插画、朗读音频整合成一本书的样子——这一步的工程量远比“让AI编一段话”大得多。WhimKid 的思路是把“个性化故事生成”这件事产品化成一条完整的流水线输入孩子信息输出一本可阅读、可朗读、可翻阅的电子绘本。核心理念不是用AI替代家长讲故事而是让AI担任“专属童书编辑”把家长从“编故事”的苦差里解放出来把时间留给孩子。1.2 产品形态与核心价值我在最初设计时确定了几条铁律故事必须个性化孩子的名字、年龄、喜好要真正进入故事主线而不是只在开头换个人名。必须有配图没有图就不是绘本LLM生成的文字再精彩也撑不起一本童书。必须适合朗读儿童绘本是“听”的书句子不能太长用词不能太书面化节奏要像人说话。必须有边界儿童内容的底线是安全不能出现暴力、惊吓、不当价值观。从产品形态上说WhimKid 不是“AI对话窗口”而是一个“生成器”。用户填一张简单的表单拿走一本成书。这种形态比自由对话对家庭用户更友好——家长不需要会提问不需要懂prompt拿到手就能给孩子看。做出来之后我把它发到社区Show HN收到的反馈中有个观点让我印象很深这些完全随机、AI生成的故事对孩子来说反而有一种“私人订制感”。孩子看到自己的名字出现在故事里会非常兴奋这种参与感是普通绘本给不了的。2. 总体架构与关键技术选型2.1 一条完整的故事生成流水线整个系统的骨架可以概括为五个环节输入解析把用户填写的表单信息孩子姓名、年龄、兴趣、故事主题整理成结构化参数。故事生成调用大语言模型使用专门设计的儿童故事提示词产出分页故事文本。分页与扩展把长文本切分成页面单位每页文本量控制在适合配图朗读的范围内。插画生成对每一页文本调用文生图模型生成风格统一的儿童绘本插图。语音合成对每页文本做TTS生成朗读音频。最后把文字、插图、音频统一组装成可交互的电子绘本我采用了网页 PDF导出双输出。这个结构看起来简单实际开发中每个环节都有大量工程细节。尤其要注意的是故事生成和插图生成两个环节是强耦合的——你生成的故事文本如果没有留出“画面感”后面插图环节就会非常被动。所以我在故事生成阶段就强制要求模型按分页输出每页文本要自带场景描述这算是我踩过几次坑之后总结出的关键设计。2.2 模型选型开源还是调API做这个项目时我同时测了开源模型和商业API两条路线结论是这个场景下商业API比开源模型省心得多。故事文本生成我选的是通用的大语言模型API。原因很直接儿童故事需要较强的指令跟随能力和创造力的平衡开源小模型在“严格按照分页格式输出”和“保持完整故事结构”两件事上即使经过微调效果也明显逊于头部商业模型。而文本生成在整条流水线里只是成本最低的一环没必要在这里省。插图生成则是跑了本地开源的Stable Diffusion系列模型用LoRA和ControlNet做风格控制。这里选开源的原因正好反过来——文生图商业API按张数计费一本8页的绘本配图成本高而且儿童绘本有强烈的风格一致性要求本地部署的好处是可以固定角色特征、统一画风这在后续调优时特别重要。语音合成我试过几种方案最终用了边缘TTS这类免费的方案效果完全够用。中文朗读对韵律要求高实测边缘TTS的中文声音自然度在儿童故事场景是可接受的成本几乎为零。2.3 为什么不直接让AI画一整本绘本有人可能会问现在有模型能直接生成“一个完整的绘本页面”或者“连续多格漫画”为什么不整本交给AI我的实测感受是当前文生图模型对这种“多页连贯叙事”的支持还停留在实验阶段。生成单张图很漂亮但一旦要求“前一张的小熊在下一页要穿同一件红衣服、坐在同一个窗前”模型很容易翻车。与其赌一个不稳定的大生成不如把流程拆细LLM负责叙事文生图只负责单页画面角色一致性靠提示词与参考图机制来保证。这也是我推荐给想做同类产品的人的一条经验别贪大把每个环节拆到最小可控单元再去逐个调优稳定性的提升是肉眼可见的。3. 实操文本生成环节的工程细节3.1 提示词模板设计故事文本质量直接决定整本书的质量而提示词就是这里的“剧本”。我最终打磨出一套分层次的提示词模板几个要点如下角色设定要具体不要只写“孩子的名字叫小宇”要写“小宇是一个5岁男孩喜欢恐龙胆子有点小但好奇心很强”。结构要求要明确规定“开头引入-中间遇到小挑战-结尾解决并获得成长”的三段式。语言风格要可朗读要求“句子短多用对话避免成语和复杂词汇”。分页格式要硬性约束要求“按页面输出每页末尾标记[PAGE]”。一个可复用的精简模板是这样你是一位儿童绘本作家。请根据以下信息创作一个睡前故事 - 主角{name}{age}岁{gender}喜欢{interests} - 主题{theme} - 字数600-800字 - 结构分成4页每页3-4句话 - 要求口语化、适合大声朗读、有画面感、结尾有积极寓意 - 输出格式每页文字后紧跟 [PAGE] 标记这个模板看起来简单实际测试里我发现一个容易被忽略的坑如果你不显式规定“每页3-4句话”模型会写出长短极不均匀的段落有的页码只有一句话有的页码能写一段论文后面配图时画面构图完全没法统一。所以分页的字数约束一定要写死在提示词里。3.2 结构拆分与分页控制模型输出故事后我会在代码里做一次校验和后处理。核心逻辑是按[PAGE]标记切分文本。检查页数是否在预设范围内默认4到8页可配置。对过长的页面做二次拆分过短的页面尝试合并。校验每页文本是否有完整的语义单元不能把一个词从中间断开。这里我用了很简单的字符串处理加正则但关键的一点是拆页之后要重新跑一遍“语义完整性”检查。比如某一页结尾是“小宇打开”下一页开头是“了门”——这种愚蠢的错误中文模型偶尔会犯。我的做法是在拆页之后把页面内容交给模型做一次“只修正不重写”的润色顺便检查前后页衔接。3.3 质量调优参数文本生成的参数调整我在不同版本上试过一组实用配置直接分享给你temperature0.8-0.9。低于0.7故事容易千篇一律高于0.95容易逻辑断裂。top_p0.9。配合temperature使用保证多样性但避免过度发散。max_tokens按页数动态计算每页约80-120字8页故事给1200左右。这里还要提一个独家心得如果你想生成的故事更有“随机感”和“惊喜感”可以在提示词里让模型“加入一个随机小物件”比如一只戴帽子的蜗牛、一把会说话的钥匙。这是用低成本给故事增加不可预测性的技巧实测效果很好孩子对这类神秘元素的兴趣远超预期。4. 实操插图、语音与成书流程4.1 插画风格统一是怎么做到的儿童绘本的插画最怕的是同一个角色在每一页长得都不一样。我在项目里采用了三层手段解决这个问题第一层是“固定风格前缀”。每一页生成图片时提示词都以同一条风格描述开头例如childrens book illustration, soft watercolor style, warm pastel colors, gentle lighting, storybook art这种做法能保证整本书的色调、媒介、光影接近但不足以保证角色一致所以还需要第二层。第二层是“角色描述固化”。主角的外貌特征会在每一条图片提示词里固定重复比如“a little boy with black hair, wearing a red dinosaur t-shirt”。原理很简单模型每次生成都看到同样的角色描述生成的角色就更可能保持一致。第三层是“参考图机制”。我用图像生成API的参考图功能把第一页生成的主角形象作为后续每页的参考输入。这是最有效的一层也是真正解决问题的一层。三层叠加之后主角形象的一致性从“偶尔翻车”提升到“基本稳定”同一本书里能明显认出同一个人物。4.2 TTS朗读的实现文本生成完成后朗读功能用TTS实现。流程是每页文本按句子切分逐句生成音频再拼接成整页的音频文件。这里有两个值得分享的细节。一个是切分时不要只看句号还要处理问号、叹号和省略号否则拼接处会出现诡异的停顿。另一个是在音频之间插入80-150毫秒的静音模拟真人翻页和换气的节奏听觉感受会自然很多。实测下来边缘TTS在中英文故事上都能提供多种音色选择。给低龄孩子朗读建议选女声或童声语速调慢10%音调可以略微提高孩子更容易接受。4.3 组装输出格式整个项目对外输出的是一套可交互的电子绘本页面我选择了Web页面展示核心格式是标准HTML的翻页书组件每页包含三部分插图、文本、朗读按钮。同时导出PDF版本方便家长打印成纸质书或者存档。组装阶段的数据结构我也直接给你参考{ title: 小宇和会飞的恐龙, author: WhimKid, pages: [ { text: 今晚小宇要睡觉了。他抱着恐龙玩具闭上了眼睛。, image: https://.../page_0.png, audio: https://.../page_0.mp3 }, { text: 突然窗外传来一阵奇怪的声音……, image: https://.../page_1.png, audio: https://.../page_1.mp3 } ] }前端拿到这个JSON就能渲染成带翻页动画的电子书。生成PDF时我直接对渲染好的HTML页面做打印导出保持排版一致性文字不会被截断在页面中间——这个坑是用分页CSS强制break-inside: avoid解决的。5. 实测记录、成本控制与性能调优5.1 端到端实测数据我拿一台普通的开发机用API加本地生图的方式跑完整流程实测一本8页绘本的耗时大致如下环节耗时故事生成LLM8-12秒插画生成8页本地GPU40-90秒TTS音频8页15-25秒组装与导出PDF约5秒总计约70-130秒也就是说用户从提交表单到拿到一本完整的绘本大概需要1-2分钟。在Web应用场景下这个速度完全可以通过异步任务队列来承接用户提交后先去喝杯水回来看结果就行。5.2 成本估算与缓存策略成本这块我按单本8页绘本估算过文本生成成本API按token计费单本大约1000-1500 token成本极低约合人民币几分钱。插画成本如果完全走商业API按张计费8张图是主要开销本地部署后主要是电费。TTS成本免费方案不考虑。整体算下来一本绘本的边际成本可以压到1元以内这意味着这个产品就算免费开放给用户使用运营压力也不大。成本优化上我有一个比较重要的经验缓存。把用户输入的关键参数主题主角性格作为缓存键已经生成过的故事直接复用。给同一个孩子生成“恐龙”主题的故事第二次点击就能秒出结果体验提升非常明显。更进一步我还做了“片段级缓存”把故事里常用的场景描写、开场白、结尾寓意句分别缓存拼装时随机组合这样既省成本又能保证每次生成的文本不完全一样。5.3 流式输出体验对Web用户来说等待1-2分钟是不可接受的。我最初的解决方案是让用户在提交后看到一个“生成中”的动画页面但体验比较煎熬。后来我改成了流式输出文本生成部分用接口的流式能力用户能看到故事像打字机一样逐字出现插图部分则是逐页渲染、逐页显示。这种“边生成边展示”的策略让用户感知到的等待时间缩短了非常多。实际测试中用户看到第一页的文字和配图出现时就已经开始期待后面的内容了。我在实践中把这个体验总结为生成型产品不要憋大招把进度切成小惊喜用户的耐心会成倍增加。6. 常见问题与排查实录6.1 故事“AI味”太重怎么办最早生成的故事拿到手读两遍就觉得不对味——用词太工整、句子结构太对称、转折不够自然一看就是AI写的。后来我加了两个修复提示词里明确写上“模仿一位有十年经验的童书作家的口吻”。故事完成后增加一轮“去AI味润色”要求模型把过于工整的句子改写成更口语化、更随意、允许带一点小毛病的表达。金句还是要有的但金句密度太高就成了流水线产品。儿童故事里偶尔一句“结果他忘了带伞恐龙也忘了带伞”这种笨拙又可爱的台词才更接近真实童书的味道。6.2 角色形象前后不一致这可以说是整个项目里最头疼的问题。参考图机制解决了大部分但偶尔还是会翻车。我的排查思路分三步先检查参考图本身是否清晰、特征是否鲜明。如果参考图里角色很小模型很难提取特征。检查风格前缀是否在每一页保持一致。我遇到过同一本书前半部分水彩、后半部分变成油画的情况改回统一前缀后问题消失。最后检查每页提示词里对主角外貌的描述是否完全一致。哪怕只是把“黑色头发”写成了“黑头发”都可能触发模型理解偏差。如果这三步都查过了还是有偶发不一致我建议在生成后加一个“角色一致性校验”步骤用视觉模型对比每页角色和第一页的相似度低于阈值的页面自动重新生成。这是最稳妥也最省人工的方案。6.3 中文命名与多语言适配中文场景下有个特殊的坑孩子的中文名字进到模型里经常会被拆解或者音译得乱七八糟。比如名字里有个生僻字模型可能直接忽略或者换成同音字。我的解决办法是在输入解析阶段就把中文名音译成拼音并在提示词里显式说明“这个名字不翻译、不变更”。比如“小宇”处理为“Xiao Yu”同时告诉模型保持原样。对于那些注意力的模型来说一个拼音名比中文字更容易被稳定复制。多语言适配方面英文、中文、日语我都测过整体方案是语言无关的提示词模板做多语言维护TTS换对应语言音色图片生成不需要额外处理。真正要花心思的是不同语言的分页判断逻辑——日文的字符密度和英文差异很大要根据语言动态调整每页文本长度上限。6.4 内容安全与家长审核儿童产品的安全底线不能碰。我在系统里做了三层安全措施第一层是提示词层明确要求模型避免暴力、恐怖、歧视、不当暗示。第二层是输出过滤在文本生成后跑一次敏感词和违规内容检测覆盖中英文常见词汇。第三层是流程层每一本生成的故事都会进入“待确认”队列家长可以在页面里预览全部文字和插画后再选择是否让孩子阅读。虽然这增加了人工审核的工作量但在儿童产品上这个成本完全值得。我自己的原则是宁可错杀一千不能放过一个。7. 一点个人体会做到现在我最大的感受是AI生成儿童内容这件事技术难点其实不在“生成”而在“控制”。你要控制故事结构、控制语言风格、控制角色一致性、控制内容安全——每一层都是在跟模型的不确定性对抗。WhimKid 从第一版能出图到现在基本稳定地出一本完整的书中间花在调优和查错上的时间远远超过搭骨架的时间。最后再分享一个小技巧给孩子讲AI生成的故事时我记得引导孩子参与创作比如让孩子决定恐龙是什么颜色、飞船要飞去哪里。这种“人类在环”的模式比让AI全自动生成更能激发孩子的想象力和参与感也让每一本“专属绘本”真正有了亲子共创的温度。如果有朋友想在类似方向做出自己的产品我强烈建议从这个“半自动共创”的角度切入你会打开一个完全不同的世界。