诊断 4 天 — v1 整体不能用，但可以拆开用

接着上一篇的话。

v1 跑通的那一晚，我自测就把它否决了 —— Cappy 回的每一句话都完全是面向成年人的对话，连我自己都觉得听不懂。我加重 prompt 措辞、加 self-check、把白名单全塞进去 —— 都没用，最后撞到豆包 Realtime 的 4000 字符 prompt 上限。

到这里我心里大概知道这条路不能往下了。但接下来花了 4 天才真的想清楚出路在哪。

4 天看起来挺长。一是中间正好赶上周末休假，二是这种”架构层面要不要换”的决策，我自己一个不写代码的产品人没法拍板，得跟 Claude 来回讨论好多轮才敢动手。

我反复看的真机日志

诊断的起点是把所有真机日志摊给 Claude 看 —— 这些是我自测时 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 词以内” 那条已经完全没有任何关系。

每一句都炸。一个 8 岁孩子听到这种话会有什么反应不用想。

第一反应：肯定是 prompt 写得不够狠

这是我熬到那天后半夜的判断。于是疯狂加码 prompt：

把 “Please use only these words” 改成全大写 “STRICT REQUIREMENT: NEVER use any word outside this list”
加 self-check checklist：让 AI 回复前先数自己用了几个词，超过 5 就重写
把所有可调难度参数全压到最低档
白名单、黑名单、示例对话全塞进去

还是超纲。 一字一句都没听。

最后是豆包后台开始报错 —— prompt 字符数到上限了。

我当时第一反应是疑惑：大模型的上下文不是动辄几十万 token 吗？怎么会这么短就到上限？

后来才搞清楚：这个 4000 字符不是模型的 context 上限，是豆包 Realtime 这个产品自己加的系统 prompt 长度限制。底层模型能吃多少 prompt，跟你能传给它多少 prompt，是两件不同的事。

prompt 这条路从工程层就被堵死了。 我已经写到上限了，加不动了。

接下来 4 天 — 跟 Claude 来回讨论

中间穿插周末。我每天跟 Claude 来回好几轮，把日志、prompt、错误信息全摊给它看。

最开始我自己的想法是”换一个更听话的 LLM”。但 Claude 把问题往上抽了一层：

“你用的不是一个干净的 LLM API，是一整个对话产品。豆包 Realtime 把’语音输入 → ASR → LLM → TTS → 语音输出’这一整套打包卖，这个产品被定位成’想跟 AI 自然聊天的成年人’用的 —— 所以它内置的 LLM 被定向训练成温暖、共情、会反问、像心理咨询师的对话风格。”

这个角度我之前没想过。我一直把豆包 Realtime 当成”一个有语音输入输出的 LLM API”，没意识到它整体是被字节按”自然聊天”调过的。

Claude 接着说：

“这不是 LLM 能力不够，是产品方向跟你正面对抗。它的训练目标是让 AI 听起来’自然温暖丰富’，你的 prompt 想让它说短话、说简单话 —— 训练信号比 prompt 信号强，模型本能上就会忽视你。再加上 4000 字符 prompt 上限两边夹击 —— prompt engineering 在这套产品上没有路。”

听完这段我心里基本就死心了。这是产品设计层面的对抗，不是 prompt 写不写得好的问题。

Claude 真正给我的转折点

第 3 天讨论里，Claude 给了我一个完全没想过的方向：

“豆包 Realtime 是端到端打包的没错，但它内部的 ASR、LLM、TTS 应该是三个独立的能力。你能不能只用 ASR 和 TTS，中间塞一个你自己能完全控制 prompt 的 LLM？”

这是这 4 天里最关键的一句话。

我之前对豆包 Realtime 的认知就是”端到端的实时语音 SDK”，从来没想过它内部还能拆。Claude 提了这个方向后，我去翻了下文档确认 —— 是的，ASR 和 TTS 都有独立的 API 入口（豆包 Realtime 本身就支持 ChatTtsText 模式，让客户端自己提供要 TTS 的文本）。整套”实时语音”只是把这三层在云端串起来给了一个”丝滑实时”的体验，但每一层都是可单独调用的。

那如果我只用它的 ASR 和 TTS，自己在中间塞一个 LLM 呢？

豆包的 ASR 准、快、对中英文混读支持得好 —— 留下
豆包的 TTS 自然、多音色（Dacey / Stokie / Tim 这些孩子向的英文音色都有）—— 留下
中间的 LLM 换成我能完全控制 prompt 的另一个模型

接下来跟 Claude 一起列了几个 LLM 候选，最后选了 DeepSeek。理由后面单独一篇展开，简单说：服从度高、中文可访问、便宜、能输出 JSON。

代价：实时性

这个方案不是没成本的。

原来豆包 Realtime 是端到端的，从孩子说完话到 Cappy 开口可能 800ms 左右。拆开之后多了一道网络中转：

原来：豆包内部 → 豆包内部 → 豆包内部   (一气呵成)
现在：豆包 ASR → DeepSeek → 豆包 TTS    (两次外部网络)

实测下来增加几百毫秒，整体延迟到 1.5-2 秒。不是无感的，但能接受 —— 对孩子来说，这相当于真人对话里”想一下再回答”的节奏，反而更像在跟人聊天。

决定

跟 Claude 把这套方案敲定之后，我让它输出一份 v2 工程任务书，下一步交给 Codex 改造架构。

整 4 天的对话浓缩下来，对我影响最大的不是某个具体技术答案，而是 Claude 给我的这个视角：

不要把一个端到端的 SDK 当成不可拆解的整体。 看清它内部的能力边界，挑你需要的那部分用，自己组合。

几个小总结

Prompt engineering 有产品级硬天花板。 我以为只要 prompt 够狠就能改变模型行为 —— 错了。当 prompt 已经写到 4000 字符上限、模型还是按训练目标走 —— 这不是 prompt 不够，是产品方向跟你不一致。这种情况再加力 prompt 是徒劳。

端到端 ≠ 必须端到端用 —— 这是 Claude 教我的。 我作为不写代码的产品人，自己不会想到一个看起来打包的 SDK 内部可以拆。Claude 给的这个角度直接改变了我的工程认知 —— 看起来”一体化”的产品 SDK，它内部往往就是几个能独立调用的能力拼起来的。能拆，就有自由度。

AI 不只是写代码工具，更是架构思考伙伴。 我之前一直把 AI 当成”技术答疑工具” —— 不会用什么 API 就问、报错就贴。但这次 4 天的诊断让我意识到，AI 真正的价值是当架构思考伙伴：我作为不写代码的产品人，没法独立想到”这个端到端 SDK 能不能拆”这种工程级问题，但 Claude 能。我的活是把上下文（日志、prompt、错误信息、约束）喂全、追问、最终拍板。把 AI 当架构师用 —— 这才是它对非工程师产品人最高 ROI 的用法。

架构层面的决策，比代码层面的决策值钱 10 倍。 这 4 天没写一行代码、没出一份新任务书。但走通了”v1 不能用 → 这个产品可以拆 → 自己组合方案”的判断链。事后看，这 4 天是项目里 ROI 最高的几天。

愿意承担”实时性损失一点”换”完全可控的 prompt”。 工程上每个决策都是 trade-off。豆包 Realtime 一气呵成 vs 拆开后多两次网络 —— 损失几百毫秒换”我能写多长 prompt 就写多长”，这笔交易我愿意做。对自用产品来说，可控性 > 极致性能。

下一篇：把 DeepSeek 塞进豆包中间 — 架构怎么改、为什么是 DeepSeek。