v1 翻车记 — Cappy 把 80% 的话说得儿子听不懂

第一个版本跑通之后，我给 8 岁的儿子用了一段时间。结果是 80% 的话他听不懂。

这是一个给大猫 3 级孩子做的英语陪练 app，这个数字意味着完全不能用。接下来花了点时间搞清楚为什么。结论跟我原来的判断不一样，记下来给同行参考。

v1 是怎么设计的

技术栈：字节豆包 Realtime，端到端 STT + LLM + TTS，国内最现成的实时语音方案。

Prompt 防御做得挺齐：

200 词白名单（高频词为主，对应 4 岁母语孩子水平）
句长上限 5 词
时态只允许 present + simple past + can/will
40 个明确禁用词（“never say magnificent / interesting / observe…”）
输出前 self-check checklist
难度档默认 L1（最低档）

按设计，Cappy 的输出应该是 “Look! A big cat!” 这种水平。

真机日志：每一句都炸

启动日志显示 prompt 是完整发送的：

[CappySession] start voice=Dacey level=L1
WORDS: Use ONLY these 200 words: I,you,he,she,it,we,...
RULES: Output only listed words. Hard max 5 words total. 
Prefer 2-4. One short line. Present/simple past/can/will.

200 词白名单、5 词上限、self-check，全都在 prompt 里。

然后是 Cappy 的实际输出：

第 1 轮（儿子：hello, how are you?）

“I’m doing great, thanks! How about you? Anything fun happening today?”

14 个词。thanks / Anything 都不在白名单。

第 2 轮（儿子：嗯）

“Hmm, that sound makes me curious—was today just a chill, low-key kind of day, or is there something on your mind you might want to talk about?”

30 个词。超纲：curious / chill / low-key / something / mind / might。一整句完整的心理咨询师对话。

第 3 轮（儿子：I don't know）

“That’s totally okay! Sometimes days feel like that—no big plans, just kind of floating. Maybe we can chat about something small to liven it up…”

39 个词。跟原来的 prompt 已经没有任何关系。

5 轮对话，每一句都超纲且超长，5 词上限完全没体现。

翻车原因：不是 prompt 写错了

翻 console log 之后才意识到 —— prompt 是完整发出去的。模型收到了 5 词上限、收到了白名单、收到了自检指令，然后选择不遵守。

诊断：豆包 Realtime 这种产品本质是为 温暖陪聊 调过的对话模型。它的训练目标是让用户感到被关心、被理解、有共鸣。这种 alignment 会让它本能地倾向于：

输出更长的回答（= “更有诚意”）
用更丰富的词（= “更聪明”）
多展开多铺垫（= “更贴心”）

我的 prompt 想让它说短话、说简单话，跟训练目标 正面对抗。训练信号比 prompt 信号强很多。模型就装作没看见。

也就是说：prompt engineering 在这类对话型语音模型上有硬天花板，而且天花板比我想得低很多。

再加力 prompt 也越不过去。必须换底层模型。

第二个洞察：读 ≠ 听

即使模型守纪律，还有一层问题没想到。

我儿子阅读水平是大猫 3 级。每天读绘本听音频也练过。我做 v1 时按 “大猫 3 级” 设计的词表。

但 读大猫 3 和 听大猫 3 是两件不同的事：

阅读	听力
有图、有重复、可慢慢看	无图、一遍过、要实时反应
不认识可以猜可以问	错过就过去了
可以停下来回想	节奏由对方控制

中国孩子英语四项（听、说、读、写）差一档是常态。我儿子能读大猫 3，听只能到大猫 1，中间差两档。

也就是说：就算 prompt 完美执行 5 词以内，对他来说仍然太难，因为词汇基准本身就偏高一档。

我从一开始用 “阅读级别” 当 “听力级别” 的代理变量。这是 v1 的根本设计错误。

接下来要做的两件事

两个发现叠加，v1 这条路走死了：

豆包 Realtime 是对话调过的，prompt 改不动它的本性
即使改得动，设计基准也偏高一档

v2 要改两件事：

架构换。豆包只做它的强项 STT + TTS，LLM 这一层换掉，用一个对指令服从度高、没有 “温暖陪聊” alignment 的模型。最终选了 DeepSeek 塞中间。具体怎么做下一篇。

基准降一档。起手默认 L1 —— 200 词、5 词以内、4 岁孩子水平。等真实数据反馈再升档。

几个 takeaway

不是所有 LLM 对 prompt 的服从度都一样。对话调过的语音模型 vs 通用文本 API，在 “守不守规矩” 上差一个数量级。选型时要单独验证。

Prompt engineering 有硬天花板。当 prompt 已经写到 4000 字符上限、加遍所有施压词模型还在我行我素 —— 这时候不是继续加力，是该换架构。

阅读、听力、口语、写作要分开衡量。“我儿子英语很好” 这种笼统判断对产品设计是无用的。每个 skill 都要单独评估。

设计者不是真实用户。我自己跑 demo 时也读过那些长句，但我能听懂，所以没意识到问题。这一类问题必须让真实用户尽早测，越早越好。

下一篇：v2.1 怎么把豆包拆开用、把 DeepSeek 塞中间。