企业官网建设流程全解析

做这个项目的初衷，其实挺朴素的。晚上给孩子读绘本的时候，翻来覆去就那么几本，孩子记得比我还熟，读到第二页就开始抢答。我就在想，能不能让AI根据孩子的喜好、年龄、甚至当天发生的小事，现场生成一本完全专属的故事书？

WhimKid 就是在这样的场景里长出来的——一个面向儿童的AI故事绘本生成器。输入孩子的名字、年龄、兴趣爱好，或者随便丢一个关键词比如“恐龙”“太空”“会飞的猫”，它就能自动生成一个完整的故事，配上插图、排版，甚至生成语音朗读版本，最后打包成一本像模像样的绘本。你可以在临睡前花三分钟，给孩子变出一本全世界只此一册的书，主角就是孩子自己。这篇文章我会把整个项目的思路、技术选型、实操细节和踩过的坑从头到尾捋一遍，给想做类似方向的朋友一份能直接上手的参考。

1. 为什么做AI儿童故事绘本这件事

1.1 被睡前故事逼出来的需求

有娃的家庭都懂，睡前故事这件事看着温馨，实际上是个不小的负担。市面上的绘本要么贵，要么孩子已经翻烂了，要么内容压根不对胃口。你讲《三只小猪》，孩子说不想听，他要听“奥特曼去月球找恐龙”这种根本不存在于任何出版物的故事。

这时候如果你用通用聊天机器人去生成，确实能编出一段文字，但问题马上就来了：纯文本没有配图，孩子根本坐不住；故事结构经常虎头蛇尾，中间还可能出现不适合儿童的情节；更别说把文字和插画、朗读音频整合成一本书的样子——这一步的工程量，远比“让AI编一段话”大得多。

WhimKid 的思路是把“个性化故事生成”这件事产品化成一条完整的流水线：输入孩子信息，输出一本可阅读、可朗读、可翻阅的电子绘本。核心理念不是用AI替代家长讲故事，而是让AI担任“专属童书编辑”，把家长从“编故事”的苦差里解放出来，把时间留给孩子。

1.2 产品形态与核心价值

我在最初设计时，确定了几条铁律：

• 故事必须个性化：孩子的名字、年龄、喜好要真正进入故事主线，而不是只在开头换个人名。
• 必须有配图：没有图就不是绘本，LLM生成的文字再精彩，也撑不起一本童书。
• 必须适合朗读：儿童绘本是“听”的书，句子不能太长，用词不能太书面化，节奏要像人说话。
• 必须有边界：儿童内容的底线是安全，不能出现暴力、惊吓、不当价值观。

从产品形态上说，WhimKid 不是“AI对话窗口”，而是一个“生成器”。用户填一张简单的表单，拿走一本成书。这种形态比自由对话对家庭用户更友好——家长不需要会提问，不需要懂prompt，拿到手就能给孩子看。

做出来之后我把它发到社区Show HN，收到的反馈中有个观点让我印象很深：这些完全随机、AI生成的故事，对孩子来说反而有一种“私人订制感”。孩子看到自己的名字出现在故事里，会非常兴奋，这种参与感是普通绘本给不了的。

2. 总体架构与关键技术选型

2.1 一条完整的故事生成流水线

整个系统的骨架可以概括为五个环节：

1. 输入解析：把用户填写的表单信息（孩子姓名、年龄、兴趣、故事主题）整理成结构化参数。
2. 故事生成：调用大语言模型，使用专门设计的儿童故事提示词，产出分页故事文本。
3. 分页与扩展：把长文本切分成页面单位，每页文本量控制在适合配图朗读的范围内。
4. 插画生成：对每一页文本调用文生图模型，生成风格统一的儿童绘本插图。
5. 语音合成：对每页文本做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 结构拆分与分页控制

模型输出故事后，我会在代码里做一次校验和后处理。核心逻辑是：

1. 按[PAGE]标记切分文本。
2. 检查页数是否在预设范围内（默认4到8页，可配置）。
3. 对过长的页面做二次拆分，过短的页面尝试合并。
4. 校验每页文本是否有完整的语义单元（不能把一个词从中间断开）。

这里我用了很简单的字符串处理加正则，但关键的一点是：拆页之后要重新跑一遍“语义完整性”检查。比如某一页结尾是“小宇打开”，下一页开头是“了门”——这种愚蠢的错误，中文模型偶尔会犯。我的做法是在拆页之后，把页面内容交给模型做一次“只修正不重写”的润色，顺便检查前后页衔接。

3.3 质量调优参数

文本生成的参数调整，我在不同版本上试过一组实用配置，直接分享给你：

• temperature：0.8-0.9。低于0.7故事容易千篇一律，高于0.95容易逻辑断裂。
• top_p：0.9。配合temperature使用，保证多样性但避免过度发散。
• max_tokens：按页数动态计算，每页约80-120字，8页故事给1200左右。

这里还要提一个独家心得：如果你想生成的故事更有“随机感”和“惊喜感”，可以在提示词里让模型“加入一个随机小物件”，比如一只戴帽子的蜗牛、一把会说话的钥匙。这是用低成本给故事增加不可预测性的技巧，实测效果很好，孩子对这类神秘元素的兴趣远超预期。

4. 实操：插图、语音与成书流程

4.1 插画风格统一是怎么做到的

儿童绘本的插画，最怕的是同一个角色在每一页长得都不一样。我在项目里采用了三层手段解决这个问题：

第一层是“固定风格前缀”。每一页生成图片时，提示词都以同一条风格描述开头，例如：

children's 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页绘本的耗时大致如下：

也就是说，用户从提交表单到拿到一本完整的绘本，大概需要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 角色形象前后不一致

这可以说是整个项目里最头疼的问题。参考图机制解决了大部分，但偶尔还是会翻车。我的排查思路分三步：

1. 先检查参考图本身是否清晰、特征是否鲜明。如果参考图里角色很小，模型很难提取特征。
2. 检查风格前缀是否在每一页保持一致。我遇到过同一本书前半部分水彩、后半部分变成油画的情况，改回统一前缀后问题消失。
3. 最后检查每页提示词里对主角外貌的描述是否完全一致。哪怕只是把“黑色头发”写成了“黑头发”，都可能触发模型理解偏差。

如果这三步都查过了还是有偶发不一致，我建议在生成后加一个“角色一致性校验”步骤，用视觉模型对比每页角色和第一页的相似度，低于阈值的页面自动重新生成。这是最稳妥也最省人工的方案。

6.3 中文命名与多语言适配

中文场景下有个特殊的坑：孩子的中文名字进到模型里，经常会被拆解或者音译得乱七八糟。比如名字里有个生僻字，模型可能直接忽略或者换成同音字。

我的解决办法是，在输入解析阶段就把中文名音译成拼音，并在提示词里显式说明“这个名字不翻译、不变更”。比如“小宇”处理为“Xiao Yu”，同时告诉模型保持原样。对于那些注意力的模型来说，一个拼音名比中文字更容易被稳定复制。

多语言适配方面，英文、中文、日语我都测过，整体方案是语言无关的：提示词模板做多语言维护，TTS换对应语言音色，图片生成不需要额外处理。真正要花心思的是不同语言的分页判断逻辑——日文的字符密度和英文差异很大，要根据语言动态调整每页文本长度上限。

6.4 内容安全与家长审核

儿童产品的安全底线不能碰。我在系统里做了三层安全措施：

• 第一层是提示词层，明确要求模型避免暴力、恐怖、歧视、不当暗示。
• 第二层是输出过滤，在文本生成后跑一次敏感词和违规内容检测，覆盖中英文常见词汇。
• 第三层是流程层，每一本生成的故事都会进入“待确认”队列，家长可以在页面里预览全部文字和插画后再选择是否让孩子阅读。

虽然这增加了人工审核的工作量，但在儿童产品上，这个成本完全值得。我自己的原则是：宁可错杀一千，不能放过一个。

7. 一点个人体会

做到现在，我最大的感受是：AI生成儿童内容这件事，技术难点其实不在“生成”，而在“控制”。你要控制故事结构、控制语言风格、控制角色一致性、控制内容安全——每一层都是在跟模型的不确定性对抗。WhimKid 从第一版能出图，到现在基本稳定地出一本完整的书，中间花在调优和查错上的时间远远超过搭骨架的时间。

最后再分享一个小技巧：给孩子讲AI生成的故事时，我记得引导孩子参与创作，比如让孩子决定恐龙是什么颜色、飞船要飞去哪里。这种“人类在环”的模式，比让AI全自动生成更能激发孩子的想象力和参与感，也让每一本“专属绘本”真正有了亲子共创的温度。如果有朋友想在类似方向做出自己的产品，我强烈建议从这个“半自动共创”的角度切入，你会打开一个完全不同的世界。