基于AppBuilder工作流构建儿童睡前故事生成器

1. 哄睡这个场景，为什么值得单独做一个应用

去年冬天我连续两周被同一件事折磨：孩子九点半上床，十点半还在睁着眼睛问"然后呢"。我试过直接打开通用对话工具让他自己讲，结果出来的东西要么三句话结束、要么主角打到宇宙尽头，越听越精神。那一刻我才意识到，儿童睡前故事生成器这种听起来"调个API就能做"的东西，真正的难点根本不在生成，而在"生成什么才叫睡前故事"。这篇东西我打算把从零到能上线的那套做法完整摊开讲，基于百度智能云千帆AppBuilder这个平台来落地，因为它把模型调用、提示词调试、知识库、工作流编排、发布渠道这些东西收在了一个界面里，对一个人做小应用来说，省掉的胶水代码是实实在在的。如果你是想快速验证一个AI原生想法的独立开发者，或者是想给自己家孩子做个小工具的家长型选手，甚至是想理解"平台化AI应用开发"到底怎么落地的技术同学，下面这些内容应该都能直接拿走用。

先说清楚这个应用到底是个什么形态：用户输入孩子名字、年龄、今晚想要的元素（比如小狐狸、月亮、不想睡觉的小恐龙），应用输出一篇长度可控、情节平缓、结尾收敛、没有惊吓元素的故事，最好还能直接朗读。它不是内容平台，不是故事库检索，而是一个参数化生成器——同一晚可以生成十个不同版本，第二晚还能接着昨天的角色讲下去。这个"可延续性"是通用对话工具给不了的，也是我觉得值得单独做成应用的核心理由。

我见过不少人做这个方向的第一反应是：直接写个脚本调模型接口，前端套个输入框，半小时搞定。真跑起来你会发现，光"半小时搞定"的那个版本，你自己都不想给自家孩子用。问题不在于模型不够聪明，而在于你没有任何地方去沉淀"什么是好睡前故事"这件事的规则。规则写在代码的字符串里，改一次要重新部署一次；换个年龄段的策略，得改代码分支；想看看哪版提示词更好，只能靠手动复制粘贴对比。这些琐碎的摩擦累积起来，才是一个想法从"能跑"到"敢用"之间真实存在的距离。

1.1 通用对话和睡前故事之间隔着三层东西

第一层是长度确定性。家长要的是"讲完刚好困"，不是"讲到一半没词了"或者"讲得停下来喝水"。通用工具对长度的控制是概率性的，你说"讲个五分钟的故事"，它给你三百字，你还得自己圆场。第二层是情绪曲线。睡前故事的情绪应该是一条缓慢下滑的曲线，冲突要小、解决要快、结尾要收在安全的地方；而模型被大量冒险故事训练过，天然倾向于制造高潮，越到后面越紧张，这跟哄睡目标是反着来的。第三层是可复现的稳定性。孩子有个特点，喜欢同一个角色反复出现，今天小狐狸叫豆豆，明天还得叫豆豆，性格还得一样。通用对话每次开新会话就是一张白纸，你得每次把设定重新贴一遍，还经常记串。

这三层东西，恰好对应平台化开发里三个不同的能力：长度控制对应工作流和工具调用，情绪曲线对应提示词工程的约束设计，角色一致性对应知识库和会话变量。这也是我选择在AppBuilder上做而不是手搓脚本的原因——它把这三件事分别有对应的位置去放，而不是全塞进一个巨大的提示词字符串里。

1.2 我把纯接口方案推翻的两个具体原因

第一次尝试我用的是最朴素的方案：一个Python脚本，一次HTTP请求，一个前端页面。跑到第三天我就放弃了，原因很具体。第一个原因是调试成本。我想对比"要求控制在800字"和"要求分四段每段200字"哪个更稳定，纯代码方案里我得改字符串、重启服务、手动输入同一批测试用例、肉眼比对。在AppBuilder的调试界面里，我可以把两版指令并存，同一批问题连着跑，输出并排看。这个差异在前期验证阶段是决定性的，因为你至少要试二十版提示词才能摸到边界。

第二个原因是发布形态。脚本方案要给我老婆用，得部署、得让她记住一个网址、得处理手机上输入框被键盘顶飞的问题。平台的发布渠道里直接能出H5页面和可分享的访问入口，我做完当天就发家庭群里了，晚上就用上了。这个"当天可用"的正反馈，对个人项目能不能活过第一周影响巨大——我见过太多自己的项目死在那三天的部署折腾里。

2. 把"哄睡"拆成一组能配的参数

动手配应用之前，我花了大概两个晚上做了一件看起来很笨的事：把"好的睡前故事"拆成可以写进配置的维度。这件事的价值在后面调优阶段反复体现——每次出现badcase，我都能定位到是哪个维度没约束住，而不是笼统地觉得"AI讲得不好"。下面这套拆法是我自己摸出来的，不一定是最优解，但确实好用。

2.1 年龄不是标签，是四组具体参数

"给5岁孩子讲"这句话对模型来说信息量极低。我把它翻译成四组可执行的参数：句子长度、词汇难度、情节复杂度和角色数量。三到四岁，句子控制在十五字以内，多用叠词和拟声词，情节只有"出发—遇到小困难—解决—回家"四步，角色不超过两个，因为超过两个孩子就跟不上了。五到六岁可以加一点点小悬念，比如"门后面传来一个声音"，但必须在两句话内揭晓且是好东西。七到八岁开始能接受简单因果链和一点点幽默反转，角色可以到三个。这个分层不是拍脑袋，是我连着两周记录孩子听到哪个位置开始走神得出的，每个年龄段我自己试了大概十个故事。

年龄段	目标字数	单句字数	情节步数	角色上限	允许的悬念强度
3-4岁	500-700	≤15字	4步	2个	无，直接叙述
5-6岁	700-900	≤20字	5步	2-3个	轻微，两句内揭晓
7-8岁	900-1200	≤25字	6步	3个	中等，允许一个小转折
9岁以上	1200-1500	≤30字	6-7步	4个	允许幽默式反转

这张表后来被我直接做成了知识库里的一个文档，模型每次生成前会检索对应年龄段的段落。效果比在提示词里写一大段"要根据年龄调整"好得多，因为表格这种结构对模型来说更容易被"照做"而不是"理解后自由发挥"。

2.2 时长换算：从"几分钟"到"多少个字"

家长说的是"讲五分钟"，模型需要的是字数。中文朗读的语速，正常说话大概每分钟240字，但哄睡场景要放慢，实际朗读速度我测下来在每分钟170到200字之间，取中位数185。所以五分钟对应大约900字，八分钟对应1500字。我一开始没做这个换算，直接让模型"讲一个五分钟的故事"，结果十次里有六次给出三四百字，读起来两分钟就完了，孩子在黑暗里问"还有吗"，前功尽弃。

这里有个反直觉的点：字数要求要比目标略高一点。因为生成出来的文本里会包含对话、拟声词、段落分隔，实际朗读时有停顿，最终时长会比纯字数换算略长。我现在的做法是目标字数上浮10%，比如要五分钟就要求950到1000字，实测读出来差不多五分半，正好。

2.3 睡前故事的四条硬约束

这四条是我踩了坑之后总结的，每条都对应一个具体的翻车场景。

低唤醒：不出现"突然""猛地""大喊""尖叫""爆炸""追逐"这类词。我最早没限制这个，有一次生成的故事里主角"突然听到一声巨响"，孩子当场坐起来问是什么声音，那一晚白讲。现在这条写进了提示词的反面清单，同时在知识库里放了一份"替换词表"，把"突然"换成"慢慢地"，"大喊"换成"轻轻地说"。

无强冲突：不出现反派、不出现"危险""逃跑了""被抓住了"。睡前故事可以有"小困难"，比如小兔子找不到回家的路，但解决方式必须是有人帮忙或者自己想明白，不能是打斗、躲藏、逃脱。这条约束最容易被模型违背，因为它学到的故事范式里几乎都有对抗。

正向收尾：结尾必须落在"安全、温暖、困了"三个词附近，不能落在"明天还要继续冒险"。我要求最后一段必须包含角色回到床上或者被窝、灯光变暗、闭上眼睛这类具体画面，而不是抽象的"他们幸福地生活着"。

可重复角色：主角名字和性格要能在多轮里保持一致。这个靠会话变量和知识库里的角色卡来解决，后面会讲具体怎么配。

提醒一句：这四条约束不要写在提示词最后，要写在最前面并且单独成段。我试过放在末尾，模型遵循率明显下降，尤其是长度吃紧的时候，它会优先砍掉后面的要求。

3. 在AppBuilder里把整个流程搭起来

平台上的应用类型有好几种，我一开始有点懵，试了两个之后确定了路线：用**工作流（Workflow）**做主干，而不是纯对话型应用。原因很直接——我需要"先生成、再校验、不合格就重写"这种带分支的逻辑，纯对话型应用只能一次性输出，长度不对就只能重新问一遍。工作流里可以把"生成"和"校验"拆成两个节点，中间加一个条件判断，字数不够就回到生成节点再跑一次，这个机制把我的长度达标率从六成多拉到了九成以上。

3.1 节点怎么切：三个核心节点加一个兜底

我的工作流主干是四段：参数归一化 → 故事生成 → 合规与长度校验 → 输出格式化。第一段负责把用户输入的零散信息（"我家娃五岁，喜欢恐龙，今天不想睡"）整理成结构化参数（年龄5、元素恐龙、情绪状态兴奋、目标时长5分钟）。这一步看着多余，其实很关键，因为用户输入永远是脏的，直接喂给生成节点会让模型分心去理解需求。

第二段是核心生成节点，挂载大模型，注入提示词模板、知识库检索结果和会话变量。第三段是校验节点，我用的是一个轻量模型加一段判断指令，让它输出"通过"或者"不通过+原因"。第四段做格式整理，把故事正文、标题、朗读提示分开，方便前端渲染。兜底逻辑是：校验连续两次不通过，就走一个"降级生成"，把温度调低、约束词加粗、字数区间放宽，保证用户不会拿到空结果。

这个结构听起来比"一个大提示词搞定"复杂，但实际搭建在界面上就是拖四个方块连三条线，我第一版搭完用了不到四十分钟。真正的成本在于调每个节点的指令，那才是后面几节要讲的重点。

3.2 人设和指令要分开写，别混成一坨

我最初把所有要求塞进"人设"那一栏，写了一大段"你是一位温柔的儿童故事作家，擅长……"。后来发现这样写有两个问题：人设部分模型会当成风格参考，指令部分模型会当成硬性规则，混在一起它就分不清哪些是可以灵活发挥的、哪些是绝对不能碰的。我现在的做法是：人设只写三句话，交代身份、语气和立场；所有可执行的规则全部挪到指令区，并且用编号列表。

人设现在长这样："你是一位有十年幼儿园睡前 reading 经验的讲述者，说话慢，喜欢用具体的画面而不是形容词，你相信孩子听不懂复杂的情节，但能听懂具体的声音和触感。"三句话，没有任何数字要求。指令区才是硬货：年龄段对应的字数区间、四步情节结构、四条硬约束、反面词清单、输出格式。这样拆开之后，模型的表现明显稳定，因为风格和规则各归各位。

3.3 开场引导和变量：让家长少打一半的字

这个细节我特别想讲，因为它决定了应用是"能用"还是"好用"。家长晚上九点半躺在床上，是不会愿意打"请帮我生成一个适合五岁儿童的睡前故事，主题是小恐龙"这种完整句子的。我的做法是用变量加上开场白里的引导按钮。

变量我设了四个：child_name（孩子名字，用来把主角叫成孩子的名字，这个小心机效果极好，孩子听到自己名字出现在故事里会立刻安静下来）、age（年龄）、theme（今晚的元素）、duration（时长）。开场白里放三到四个推荐问题，比如"给我家娃讲个5分钟的小狐狸故事"、"接着昨天的小恐龙讲"、"今晚想要一个关于月亮的故事"。用户点一下就能触发，不用打字。

child_name这个变量还有个用法：我会要求模型在故事里让主角"和{child_name}一样大的小朋友"出现一次，或者在结尾说"这个故事，是送给{child_name}的"。实测下来，这一句话的哄睡效果抵得上一百字的描写。变量为空的时候要有兜底逻辑，我用的是"如果未提供名字，不要编造名字，直接用角色称呼"，早期没做这个兜底，模型会自己编一个名字，家长看了莫名其妙。

3.4 知识库不是用来存故事的，是用来存"骨架"的

很多人搭这类应用第一反应是往知识库塞几百个童话故事，让模型模仿。我试过，效果不好——模型会开始抄，而且抄的还是那些有反派有冲突的经典故事，跟我的四条约束打架。后来我换了思路，知识库里只放四类文档：年龄段参数表、情节骨架模板（比如"找东西—找不到—有人帮忙—找到—回家睡觉"这十几种）、词汇替换表、角色性格卡。总量不到二十页，检索命中率反而高。

角色性格卡是我最满意的一块。我给常见角色（小狐狸、小兔子、小熊、小恐龙）各写了一张卡，包含名字、三个性格关键词、一句口头禅、一个最喜欢的食物、一个害怕的东西（必须是无害的，比如"怕黑但是有小夜灯"）。用户说"接着昨天的小恐龙讲"，工作流会去知识库检索这张卡，把性格和口头禅注入生成节点，角色就不会漂移了。这个机制比在提示词里写"保持角色一致"有效十倍，因为后者是要求，前者是给料。

3.5 校验节点怎么写才不会变成橡皮图章

校验节点最容易写成摆设。我第一版写的是"请判断这个故事是否适合睡前"，结果它十次有九次说通过，因为"适合"太模糊。第二版我改成四个可勾选的硬指标，每个都要给出证据：字数是否在区间内（给出实际字数）、是否出现反面词（列出命中的词）、结尾是否包含指定画面（引用最后一句）、主角名字是否与输入一致。要求它"先引用再判断"之后，准确率明显上来了，因为它没法糊弄——要引用就得真的去读。

这个节点的模型我不建议用太强的，用小一点的模型反而更好，因为它的任务是机械比对，强模型容易"理解"过度然后放过问题。温度设成0，输出限定成固定格式，方便后面做字符串判断。

4. 指令的实际写法：一份可以直接抄的骨架

写到这儿该上干货了。下面这套指令结构是我改了十几版之后稳定下来的，直接贴进指令区就能用，需要改的只有年龄段那块的数字。它的核心思路是把提示词当成一份需求文档来写，而不是当成一段咒语。

4.1 四段式骨架：任务、参数、结构、禁令

第一段只写任务，一句话："根据给定参数，生成一篇用于睡前朗读的中文故事。"不带任何形容词修饰，因为形容词会污染后面的规则。第二段是参数占位，把变量和你归一化后的内容以键值对形式列出来，模型对键值对的遵循度明显高于散落在句子里的信息。第三段是结构说明，明确告诉它分几段、每段干什么、结尾必须落在哪里。第四段是禁令清单，用"不得""禁止""避免"开头，逐条列出。

段落顺序不能乱。我试过把禁令放前面，结果模型把大量注意力放在"不要写什么"上，写出来的东西干巴巴没有画面感。现在的顺序是任务—参数—结构—禁令—示例，示例放最后，起一个"照着这个感觉写"的锚定作用。示例不要给完整的，给开头三句和结尾两句就够，给全了它就开始抄。

4.2 反面清单比正面要求管用

这一点是反复验证过的。你说"要写得温暖"，模型的理解跟你不一样；你说"不得出现打斗、追赶、巨响、黑暗中的未知声音、角色哭泣超过一次"，它就清楚多了。我的反面清单现在有三组：

• 情绪类：不得出现突然、猛地、尖叫、大喊、惊恐、危险、逃跑、抓住、救命
• 结构类：不得出现反派角色、不得有未解决的悬念、不得在结尾提出新问题、不得出现"欲知后事"
• 表达类：不得使用超过两行的长句、不得连续三段没有对话或拟声词、不得使用成语超过两个（孩子听不懂）

第三组里的"不得连续三段没有对话"，是我发现孩子注意力最容易在纯描写段落流失之后加的。加上之后，生成的故事里对话比例明显上升，朗读时的节奏也好了很多。

4.3 输出格式要和前端渲染对齐

如果你的前端要把标题、正文、朗读提示分开显示，那就必须在指令里规定输出格式，而且要用最简单的那种。我最早让它输出JSON，结果模型经常在JSON外面加一句"好的，这是您要的故事"，前端直接解析失败。后来我改成用固定标记分段：

【标题】 【正文】 【结束语】

每个标记单独一行，正文内部不允许出现这三个标记。这个格式对模型来说几乎没有出错空间，前端用字符串切分就能处理。定好格式之后，我在校验节点里加了一条"检查是否包含全部三个标记"，把它当成硬性通过条件，一次就把格式错误率压到接近零。

一个容易忽略的点：结束语不要让它自由发挥。我规定结束语只能是"故事讲完了，闭上眼睛，明天我们接着讲{角色名}的新故事"这一类固定句式，长度不超过三十字。之前让它自由写结束语，经常出现"故事告诉我们一个道理……"这种说教，孩子一听就清醒了。

5. 调优实录：几个让我返工的坏例子

应用能跑起来只是起点，真正花时间的是调优。这一节我把印象最深的四个问题连排查过程一起写出来，因为我觉得排查思路比结论更有用。

5.1 故事总是"卡在开头"：长度失控的完整排查链路

现象是：要求九百字，实际输出普遍在四百到六百字之间，偶尔还会超到一千四。我一开始以为是模型能力问题，换了个更大的模型，没用。然后我怀疑是温度太高导致发散，调到0.3，长度确实稳了一点但故事变得干瘪。接着我做了一件对的事：把同一批十个输入各跑三次，把输出字数记下来做成表。

记录之后问题就清楚了：短的那些，全部是"主题词太具体"的输入，比如"讲一个小兔子找胡萝卜的故事"，模型觉得目标达成了就收尾；长的那些，全部是"主题词很抽象"的输入，比如"讲一个关于友情的故事"，模型不知道该往哪收，就一直铺。也就是说，长度失控的根因不在长度要求，而在情节结构没有被固定。

修复方案是两步。第一步，在参数归一化节点里加一条规则：把用户给的主题词强制映射到知识库里的某个情节骨架，映射不上就用默认骨架"出发—遇到小困难—有人帮忙—解决—回家—睡觉"。第二步，在生成指令里把骨架的每一步都标上大致字数，比如"出发200字、困难250字、帮忙300字、解决150字、回家睡觉100字"。加了字数分配之后，长度达标率直接从六成多到了九成。

顺带说一个意外收获：分步给字数之后，故事的结构感明显变强了，不再是想到哪写到哪。孩子听到"回家"那一段会主动躺平，因为他知道要结束了，这个预期本身就是哄睡的一部分。

5.2 角色名字在第三段突然变了

这个badcase特别典型。故事开头叫"豆豆"，讲到一半变成"小豆"，结尾成了"豆豆熊"。查下来是两个原因叠加：一是知识库里的角色卡被检索到了，但只检索到片段，名字字段没进去；二是多轮对话里模型把用户之前提到的"小熊"和"豆豆"混在了一起。

修复做了三件事。第一，角色卡改成结构化格式，第一行就是角色名：豆豆，检索时优先命中这一行。第二，在生成指令里加一条硬规则："全文角色名必须与参数中的character_name完全一致，不得使用昵称、简称、组合称呼。"第三，在输出之后加一个轻量检查：统计character_name在正文中出现的次数，以及是否有相近但不一致的词。这个检查用字符串处理就能做，不需要模型。

第三条检查后来救了我很多次。因为名字漂移这种问题，人眼读一遍不一定发现，但机器一比对就出来了。

5.3 结尾突然开始讲道理

有段时间生成的故事结尾总是"这个故事告诉我们，要勇敢面对困难"。孩子听完睁眼问我"什么叫面对困难"。这个问题的根源在于模型的训练偏好——它被大量"有教育意义"的儿童内容训练过，天然觉得故事要有寓意。禁令里写"不得说教"没用，因为它不觉得自己在说教。

真正有效的做法是规定结尾的具体画面，而不是禁止某种表达。我把结尾要求改成："最后一百字必须包含以下画面中的至少两个：角色躺下、盖好被子、灯光变暗、闭上眼睛、呼吸变慢、窗外安静。不得出现任何总结性语句、不得出现'这个故事告诉我们'、不得出现道理、启示、明白、懂得这类词。"改成描述画面之后，说教基本消失了，因为模型有了具体的落点，不需要靠总结来收尾。

我还把这几个画面词做成了一个短语列表放进知识库，检索命中之后模型的用词会更统一。现在故事结尾基本是"豆豆钻进被窝，把被子拉到下巴，灯灭了，窗外的月亮也慢慢躲到云后面去了"，这个收尾我很满意。

5.4 恐怖元素漏网的两个隐蔽入口

我原以为把"鬼""怪物""黑暗"这些词拉黑就够了，结果漏了两次。第一次是"影子"——故事里写"墙上的影子动了一下"，本意是想写温馨的，但孩子对影子的反应很直接。第二次是"迷路"——故事里小兔子在森林里找不到妈妈，虽然最后找到了，但中间那段孩子明显紧张了。

这两次让我明白，恐怖感不是靠关键词能筛干净的，它藏在情境里。现在的做法是双保险：一是反面词清单里加了"影子、迷路、找不到、一个人、黑漆漆、奇怪的声音、门后面"这些情境词；二是在校验节点里加了一个专门的判断项，指令写成"判断这个故事中是否存在让四岁以下儿童产生不安的情境，如果有，引用原文并说明"。要求它引用原文这一点很关键，它逼着校验模型真的去读，而不是凭感觉说没问题。

6. 从自用 Demo 到能给别人用，中间还差什么

自己家用和发给朋友用，是两个难度。自用的时候你能容忍它偶尔抽风，别人用一次抽风就不会再用第二次。这一节讲讲发布前后我补的东西。

6.1 三种发布形态，我选了最土的那个

平台提供的发布方式里，我主要用了两种：一种是可分享的网页入口，一种是API接口。网页入口适合直接给家里人用，打开就能用，不需要装任何东西。API接口留着做后续扩展，比如接到智能音箱上，或者做成一个小程序。

我最初特别想做成小程序，觉得那样"像个产品"，后来想明白了：这个应用的使用场景是晚上九点半、灯已经关了、家长躺着、只想点两下。在这个场景下，打开一个网页比打开小程序少两步操作，而少这两步就是胜负手。所以我把网页入口的开场白设计得极其简单，三个大按钮，点完直接出故事，中间不跳任何页面。

API那条线我是这么用的：把生成接口接到一个本地的朗读工具上，生成完自动读出声音。这个组合的体验比"看故事"好得多，因为哄睡场景本来就不该有屏幕光。这个思路也可以反过来用在别的地方——生成类应用的价值往往不在内容本身，而在内容怎么被消费。

6.2 成本这块得算清楚，不然跑两天就心疼

我做过一次粗略估算。一个五分钟的故事，输入侧大概是提示词加知识库检索结果，一千二百 token 左右；输出侧九百到一千字，中文大概一千五百 token。一次生成加上一次校验，合计三千 token 上下。如果校验不通过要重写，最坏情况翻倍。

这个量级意味着什么？意味着如果只是自己家一天用一个故事，成本可以忽略不计。但如果做成公开可用的东西，一天几百次调用，就需要考虑两件事：一是把校验节点换成更小的模型，它的任务是比对不是创作，没必要用大模型；二是做结果复用，同一组参数（同年龄、同主题、同骨架）生成的故事，在二十四小时内可以缓存，不同用户拿到同一个故事其实没什么问题，睡前故事本来就不追求唯一性。我加了缓存之后，重复参数的请求成本直接降到接近零。

还有一个省钱细节：知识库检索不要每次全量召回。我一开始设置召回五条，后来发现只需要两条——年龄参数表和角色卡，情节骨架在参数归一化阶段就已经确定了，不需要再检索。召回数量从五降到二，输入侧的 token 少了一大截。

6.3 上线后我盯的三个数

第一个是首次生成达标率，也就是不做重写、一次就通过校验的比例。这个数反映的是提示词和知识库的质量，我现在稳定在九成左右，低于八成就说明最近改的东西有问题。第二个是平均生成耗时，超过十秒用户就会觉得卡，我的目标是八秒以内，靠的是把校验模型换小、把召回数量降下来。第三个是追问率，就是生成完之后用户又输入"再讲一个"或者"太短了"的比例，这个数最能反映真实体验，"太短了"多说明字数下限还要往上调。

这三个数我每周看一次，比看任何主观评价都管用。特别是追问率，用户的抱怨往往只有一个字"短"，但你把它统计出来，就知道问题出在参数还是出在生成。

7. 几个踩过才知道的细节

最后这部分是零碎的，但每条都是真金白银换来的。

开场白里的推荐问题不要超过四个。我一开始放了六个，想着覆盖更多场景，结果用户反而不点了，选择过载。三个是最舒服的数量，分别对应"新故事""接着讲""换个主题"。

多轮对话的记忆要手动管。平台默认会带上下文，但睡前故事这个场景里，上下文带多了会污染——比如用户上一轮说"太吵了"，模型下一轮可能就写一个安静的故事，逻辑上没错但没必要。我的做法是在每轮生成时只显式注入角色卡和上一轮的故事梗概（五十字以内），其余上下文让它自然衰减。

给孩子的名字做一次转义处理。用户输入的名字里可能有生僻字、可能有叠字、可能有英文。我在参数归一化节点里加了一条：名字长度超过四个字就只取前两个字，包含非中文字符就退回默认称呼。这条是为了防止生成出来的故事里突然蹦出一个奇怪的名字。

测试用例要攒着。我建了一个文档，把每次遇到的badcase输入原样记下来，现在有三十多条。每次改提示词，先跑这三十条，看看有没有回归。这个习惯让我避免了好几次"修好一个搞坏三个"的情况。

别在深夜改提示词。这条听起来像玩笑，但真的很重要。哄睡场景的评判标准极其主观，你晚上十一点改的东西，第二天早上看往往觉得莫名其妙。我现在的规矩是白天改、晚上验，两个时间段的判断差异大得惊人。

给孩子用的东西，宁可短一点也不要冒风险。我现在的策略是：只要校验节点有任何一条不通过，哪怕只是"可能有点紧张"，也直接重写，不做人工判断。多花一次调用的成本，换一个晚上安心，这笔账怎么算都划算。

这套东西到现在跑了三个多月，从最开始我自己家一个用户，到现在亲戚朋友加起来十来个家庭在用。中间改过七八版提示词，工作流结构倒是没怎么动，说明当初把"生成"和"校验"拆开的决定是对的。如果你也想做一个类似的生成器，我建议先把年龄段参数表和情节骨架这两份文档写出来——这两份东西写清楚了，剩下的基本就是在界面上连线的事。