# 如何做好一个 AI 女友

一眼假,输在节奏

接入方转来一张截图。用户问了一句敏感话题,我们的 AI 女友回了六条气泡:"哈哈"、"怎么突然问这个呀~我对政治不太懂"、"也不怎么关注这些。"、"比如今天有什么安排?"、"你聊点别的呗"、"😅"。总共约 50 个字,零间隔,同一瞬间糊满屏幕,不像聊天,像批处理输出。

三层毛病叠在一张截图里

拆开看,这 50 个字叠了三层毛病。最扎眼的是节奏:下游拿到的 delay 字段全是 0,六条消息同时上屏。切法也不对。拆气泡本意是学真人把一句话分几条发,可切分逻辑按标点走,每个逗号句号都切一刀,一段普通回复被剁成六截,连那个 😅 都单独占一条。剩下是内容:同一个"我不懂政治"换着说法讲了三遍,再硬凹一个"今天有什么安排"的反问试图转移话题,三句道歉挤在一起,信息量等于一句。内容的账记在 prompt 头上,后面有专门一章去算;当场让用户出戏的,是前两层。

delay 怎么定

真人被问到不想答的话题,会先停顿几秒,对方看到的是"正在输入",然后一条一条地来。我们照这个样子修:给回调里的每条消息带一个 delay 字段,下游按这个数值把气泡逐条错开上屏。剩下的问题就一个:每条该填多少。

首条恒为 0。用户发完消息到第一条回复之间,模型生成本来就要耗时间,这段空白已经替我们演完了"她在想"。

后续每条按内容长度模拟打字:基础 500ms,每个字加 55ms,结果夹在 600 到 2600ms 之间。再加正负 15% 的随机抖动,不然每条间隔机械地等长,同样露馅。图片单独按 1800ms 算,翻相册挑照片,总比打字慢一拍。

套上这组参数,开头那六条气泡就有了模样:"哈哈"一闪就出,长句要多敲一阵,😅 又是轻轻一下。内容一个字没改,批处理的感觉就散了大半。

上限也要管。单条封顶 4000ms,整条回复累计压在 16000ms 以内:下游协议里有一条 20000ms 的截断线,超线的 delay 会被夹回线内,前面按字数排好的间隔集体缩水变形。

难的不是做快,是做慢

做这个产品之前,我们以为难点在把 AI 做快。做起来才发现反了,难的是把它做"慢"得像人。我们甚至写了故意的首响延迟:陌生人阶段的第一条回复,随机等 4.5 到 10 秒才发出去。刚认识的人不会守着屏幕等你,回消息快慢不定;每条都秒回,等于把"随时在线待命"写在脸上,反倒假了。慢多少、什么时候慢,没有标准答案,只能对着真人聊天的样子一点点拧。

往后三层毛病各有各的修法,但道理是同一个:做一个不露馅的 AI 陪聊,拼的不是模型,是工程细节。

贵的模型反而更假

做 AI 陪聊,大多数人的第一反应是接市面上最强的模型。我们一开始也这么想,后来发现钱、性格、内容边界,三样都对不上。

先说钱。拉一次主聊调用看:input 1112k token,output 只有 36250。输入重、输出轻,每轮都在重发几乎不变的 system prompt 和历史消息。我们的主力模型在 input $0.09/1M token 这一档,前沿助手模型比它贵一到两个数量级。这个差价不是花在"更聪明的回复"上,是烧在那一万多 token 的重复输入上。

再说性格。前沿模型被训练成"有帮助的助手",这层训练痕迹在陪聊场景里全是负资产:客服腔、道歉、免责声明,还有那句经典的"作为 AI 我不能"。放在办公助手里这些是安全带,放在角色扮演里,每一条都是出戏点。用户不需要她会写代码,需要她别在聊到一半突然变成客服。

边界问题最没得商量。这个品类有成人向内容,而成人向对话在助手模型上大量触发拒答。前两个问题还能靠 prompt 压一压,这个压不住:拒答本身就是最大的出戏,比任何客服腔都致命。

三个月换了三次

第一代用国产 mimo 系,走官方渠道直连;中间试过 minimax;2026 年 6 月全量切到 deepseek-v4-flash,25 个人设一次切完,切之前把回滚 SQL 存好了。

促成最后这次切换的,是老模型上积压的一批客诉:AI 味的重复、聊着聊着跑题。这批问题在 prompt 层怎么调都调不动。实测下来结论是模型驱动的,不是 prompt 驱动的:同样的 prompt 换个模型,一批调不动的问题一次消掉。修 prompt 是逐条抠,换模型是整批解决,前提是你得先判断对问题在哪一层。

这个判断很容易做反。切完 deepseek 之后,有个人设疯狂提"课金",我们第一反应又是模型的锅。追下去一看,是运营写的人设 override 明确要求"拜金",模型只是照办。所以别急着下结论:回复不对劲,先翻 prompt 和人设配置,确认那里没这么要求,再去怀疑模型。冤枉模型的成本是白换一次,冤枉 prompt 的成本是永远调不好。

两条便宜的杠杆

选好主力模型之后,还有两笔钱可以省,都不需要牺牲质量。

一条来自会话分布。拉线上数据,84.5% 的会话只有 1 轮就结束了。前 5 轮的对话历史短、上下文浅,便宜的快模型效果足够;从第 6 轮起再切到主力模型。落到代码上就是一行轮数阈值配置,降本 30% 到 50%。

另一条在质检调用上。我们每条回复出口都要过一遍小模型审计,它查什么、怎么兜底,人味那章细讲,这里只看调用形状:输入 650 来 token,输出只有 2 个 token 的判定。这种重输入、轻输出、只要一个"过或不过"的调用,用 flash 级模型,便宜到可以全量跑,不用抽查。

网关这一层

模型定了,还有一个选择:直连官方,还是走聚合层网关。我们用了网关:一把 key 接十几家托管同一个模型的供应商,不用逐家签约,还能按 order 钉住想要的供应商。但这个方便有代价:你在系统里引入了"供应商路由"这个新的故障域,请求实际落在哪家、缓存还认不认,都多了一层变数。后面讲缓存优化的那章,一半的坑都是从这一层冒出来的。

Prompt 是分层的,教训也是

我们的 system prompt 拼完有一万三千多 token,但它从来不是一整篇文本,而是一层层套起来的。最里层是代码硬编码的红线:身份声明、输出过滤、反注入,任何租户都改不掉,想改只能改代码。中间是租户级的"通用行为层",一大块 13,449 字符的文本,管说话风格、拒答方式、消息怎么分段,所有人设共用这一块。到了最外面才轮到每个人设自己的描述,只有四五百字符。人设旁边还挂一块结构化的"硬事实":年龄、城市、家庭这类数字型事实单独列出来,不埋在散文里。再往后是动态块,按当前状态现拼进去:时间、关系阶段、场景、对话记忆。

值得写下来的是踩在每一层上的四个教训。

91% 都是约束,新指令沉了底

有一阵我们想让某些人设放开一点,往 prompt 里加指令,模型行为纹丝不动。后来统计了一下才明白:整个 prompt 一万三千多 token 里,约束类内容占了 91%。新加的一句"放开",泡在满篇的"不许"里,等于没说。

改法是把约束按等级重构:档位数字本身不喂给模型,由代码按档翻译成具体指令再拼进 prompt,模型看到的是明确写出来的行为描述,不是要它自己琢磨的暗号。这个教训落在通用行为层:文本堆到这个量级,翻译的活得交给代码。

例句会被整句照抄

prompt 里写过字面例句,本意是"照这个感觉说"。模型把它们当成了答案,一字不差地复读,真实用户几天就发现了:"她怎么老说同一句?"

例句后来全换掉了,改成抽象的类别描述和句式形状,让模型自己填词。示范给到"形状"这一层就该停手,再具体一步,模型就照抄。

一字不差的固定句,先 grep 代码再怀疑模型

有一段安全代码,用正则匹配回复,命中就把整句替换成硬编码文案。真实流量里 5~8% 是误杀:用户上一句聊得好好的,下一句突然蹦出一条前言不搭后语的固定句。看着像模型抽风,其实那句话是代码换上去的。

排查这类问题,我们攒出一条经验:凡是"一字不差的固定句"反复出现,先去代码里 grep 硬编码,查完了再怀疑模型。模型输出带随机性,同一个意思每次措辞都会飘;能一个标点都不差地重复出现,多半出自代码。后来修掉这处误杀,5~8% 降到了 0。这层教训在最里层:红线代码自己也会犯错。

硬事实会变成话题黑洞

给某个人设写了具体的职业和爱喝的饮品。模型把这些事实当成了可用素材,没话说就聊它,用户天天听她提同一种饮料。

硬事实还是要给,人设不能空心,但要配一条"话题饱和"约束:同一类 persona 事实,近期聊过就不许再主动提。

人味是攒出来的

人味不是在 prompt 里写一句"请像真人一样聊天"就能长出来的。做了三个月,我们攒下来的是一堆不起眼的小机制,每个只管一小段体验。

她得知道现在几点

模型自己没有时钟。不告诉它,它的世界里就没有"现在"。所以我们往 prompt 里注入三样东西:当前时间、上一条消息的时间、两者隔了多久。有了这三行,用户早上回来,她知道昨晚聊到几点、中间隔了一整夜,开口第一句才接得上。

这里踩过一个 bug。有次把"上一条消息时间"错写成了当前时间,间隔永远算出来是零,AI 于是永远认为用户刚发完消息:你隔了一夜回来,她接话的口气像你刚说完上一句。这种错不抛异常,代码照常跑,坏的只是聊出来的感觉。

关系不能一上来就腻

先说翻车现场:模型有一次把"我们还在陌生人阶段"原样吐给了用户。这句话是我们喂给它的内部状态,不是台词。用户看到,戏一下就穿了。

这个标签来自我们的关系阶段机。陌生、认识、熟、亲近,四档,只按聊天轮数推进,不看聊天内容,每一档对应一套措辞和亲密度。只数轮数听着糙,但它守住了一件事:刚认识的第一句不会腻腻歪歪。修法是在 prompt 里加硬禁令:标签永远不许出现在回复里,亲疏只准用语气表达。喂给模型的内部状态,要默认它总有一天会被原样吐出来。

话要短

正常人聊天不会一口气发 100 字小作文,所以回复出口有一道长度闸:中文超 100 字触发,越南语超 200 字。越南语的线画得高,不是它话多,是同样的意思,它的词就是更长。

触发之后分两步。第一步让一个小模型压短。压短不是重新生成,指令里内嵌原稿,要求只保留最重要的一个点;第二步兜底,压不动就按句子边界截断。截断是代码干的:模型偶尔会无视你的字数要求,代码不会。

每条回复过一遍审计员

时间、阶段、长度各管一段,出口处还有一道总闸:每条回复发出去之前,都要过一个我们叫"审计员"的小模型。输入是这条回复加上人设的硬事实,输出只有两个 token 的判定,查三样东西:有没有出戏、有没有泄漏 prompt、有没有事实错乱。命中就重写一次,重写还不行,走兜底。

每条都过一遍质检,账在选型那章算过:flash 级模型便宜到可以每条都跑。抽查省下的那点钱,抵不上漏放一条穿帮回复的代价。

沉默这条机制后来整个反转了

我们本来有个 [NO_REPLY] 机制:模型这一轮输出这个标记,系统就不下发回复。设计初衷是用户刷屏时 AI 可以不回,像真人一样冷处理,真人本来就不会对你发的每一条都有反应。

后来接的是按消息计费的场景,用户每发一条都花钱,这条机制立刻站不住:沉默等于用户付了钱没有回声,客诉直接从这里来。规则从此只剩一条:任何情况都必须回。

无论如何都要回消息

我们有个报错群。拉了三天的数据,一共 50 条告警:运行时 CPU 超限被强制重置 20 次,存储实例漂移 6 次,上游模型接口失败 8 次,剩下是各类质量告警。在群里看是四类问题,四套技术原因,落到用户那边是同一条路径:消息发出去了,回复永远等不到。同步接口直接 500;异步链路发一条 error 回调,用户端什么都不显示,连个报错气泡都没有;最刁的是生成跑到一半整个实例被杀,连错误处理代码都没机会执行。

所以修的方向不是先把四类错误一个个根治,而是保证不管哪一类先炸,用户都能等到一句回复。

兜底要一层压一层

修法是分层兜底,一层压一层,最底下那层不许依赖 LLM。出错先从预置语料池随机挑一句,带查重,避免连续两次挑到同一句,兜底句本来就短,连着两次一模一样比不回还假。池子空了,让模型现场生成一句轻量的话题转移。模型也挂了,就从按语言分组的静态短句池里随机出一条,"嗯?你刚说什么,再说一遍呗"这种。最底层必须是静态的:兜底要接住的场景里就有"上游模型接口失败",这时候再调一次模型,等于把命押在刚出事的那条链路上。

最后这层之前有一版实现:30% 回一个问号,70% 干脆沉默。后来排查"AI 不回复"的客诉,一条条翻下来,源头就是那 70% 的沉默。这个分支全部改掉,换成上面几层能兜出来的短句。

连错误处理都死了怎么办

生成中途实例被杀是最难缠的场景:实例整个没了,错误处理代码跟着一起死,try-catch 写得再全也没用。我们靠租约解决。任务开始时标记"生成中",带一个租期。实例复活后扫一遍,发现有任务的租约过期了,说明上一次死在半路。这时不重新生成,重跑意味着重复计费和重复记录,改成兜一条短句发出去。用户多等了一会,但等到了回复。

两个具体的坑

队头阻塞那次教训不小。异步回调按序号严格保序投递,结果一条永远投不出去的回调卡在队头,后面的消息全部积压,整条会话冻结了 3.7 小时。严格保序有个隐含前提:每一条都投得出去。前提一破,保序就从保体验变成了陪着一起死。修法是放弃绝对保序:队头重试到上限就放行,后面的乱序投出去,由上游按序号重排。

另一个坑埋在查重逻辑里,就是语料池那个"避免连挑同一句"。判断兜底语料有没有重复,我们用了最长公共子串,O(n²),没设长度上限。平时相安无事,一条异常的超长回复进来,单实例 30 秒的 CPU 预算直接被打穿,实例被平台强制重置。这个坑还长在兜底自己身上:负责让用户等到回复的查重,反过来把实例弄死了。修法朴素:字符串算法在生产环境里要给输入设上限,别信"输入不会那么长"。

兜底上线那天有个巧合。部署完一分钟,我们跑冒烟测试,恰好撞上代码更新导致实例重置的瞬态错误。放在以前,这一下就是个 500;那天返回的是一句自然的兜底短句。兜底自己验证了自己。

先算账,再动刀

拉了一周的账单:$29.69,5.17 亿 token,6.3 万次请求。摊到一条用户消息上,全链路成本约 $0.0008。99.9% 的钱花在一个主力模型上。

再往下拆一层。主聊调用的形状,选型那章看过:输入一万多 token,输出最多两三百。成本 95% 以上在 input,而 input 里八成是 system prompt 和历史消息——每轮都在花钱重发同一堆几乎不变的文本。

大模型厂商为这种场景提供了 prompt 缓存:逐字前缀匹配,命中的部分按约 1/5 计价。这条规则没有任何弹性,前缀里任何一个字符变了,后面全部作废。我们照着这个规则去查自己的 prompt,查出四个缓存杀手。

四个缓存杀手

最凶的一个是时间块。它精确到分钟,还带一句"距上条消息 37 秒",每次调用必变,偏偏排在几千 token 的静态内容前面,一变全灭。改法是时间只保留到小时,间隔改成分桶:模型不需要知道用户离开了 37 秒还是 42 秒,它只需要知道"刚刚"和"隔了一夜"的区别。

关系阶段块里写着字面的轮数计数,每轮变一次。轮数推进关系阶段是内部逻辑,模型只关心现在处于哪一档,改成按十位分桶就稳了。

第三个藏得深:上下文压缩没有滞回。窗口满了按显著性删中间的消息,窗口一满每轮都重删,删的位置每轮不同,深聊会话的历史前缀每轮都不一样。深聊会话恰恰是历史最长、input 最贵的那批调用,缓存对它们永久失效。改成一次多砍一批,砍完攒十几轮不动。

还有一条纯排序问题:时间、场景这些动态块排在静态内容前面,把本来能缓存的大头挡在了失效线后面。全部挪到 prompt 末尾。

四条改完,业务语义一个字没动,纯粹是给缓存让路。

9 秒,还是 9%

供应商那边也有一笔账。同一个模型有十几家供应商托管,价格和速度差得离谱:最便宜那家 22 tokens/s,全场倒数,一条 200 token 的回复要生成 9 秒;第二梯队 70 tokens/s,只贵 9%。让用户对着"正在输入"干等 9 秒,还是多花 9%,不用犹豫,我们拍板速度优先。这个决定还有一层当时没太在意的收益:前缀缓存是按供应商隔离的,主供应商越稳定,切换越少,命中率越高。

账算完,大部分刀不用动

算到这里,我们撞上一个反直觉的结论:这个盘子一个月 $127,砍掉一半也只省 $60,任何带质量回归风险的优化都是负 ROI。工程师看见 13k token 的 system prompt 会手痒,但为了省几十美元去动一个已经调稳的 prompt,回归测试的人力都不止这个数。

所以两个看起来最值得干的大动作,我们都否了:压缩那 13k 的 system prompt,不做;审计调用改采样,也不做。最后只留下缓存那四条,因为它们对输出零影响。

四件套设计完,准备上线。当时我们觉得这件事已经收尾了。

命中率 61% 到 91%,中间隔着三个反转

四件套对输出零影响,上线就该看到命中率往上走。实际的曲线比这难看得多,中间拐了三个弯。

反转一:上线第一天,数字纹丝不动

四件套发上去,当天盯 dashboard,命中率还在 61% 到 77% 的老区间里晃。第一反应是优化没生效,prompt 结构白改了。

真相跟四件套没关系。同一次发布还捆了另一个改动:按速度优先换了主供应商。前缀缓存是按供应商隔离的,你在 A 家攒的缓存,B 家一个字节都看不见。切供应商等于整个缓存全量冷启动,prompt 优化攒出来的收益被冷启动对冲得一干二净。

这次留下两条规矩。第一条,provider 变更和 prompt 改动永远分开发布,绑在一起就没法归因。第二条,单小时快照不能下结论:切换后第一个小时,配置里排第一优先的供应商只拿到 4.3% 的流量,我们差点断定"路由配置不生效";拉满 22 小时窗口再看,它实际拿了 56%。按小时波动是常态,至少看 24 小时再说话。

反转二:标价最低那家,算完最贵

冷启动熬过去,下一个问题是选哪家供应商。聚合层的供应商详情页有一张 Effective Pricing 表,按 30 天全网实测给出同一个模型在各家的实际缓存命中率,差距大得吓人:最好的 81.4%,最差的 11.3%。

表面标价最低的那家,input $0.09/1M,全网实测命中率只有 21%。套进公式一算,它反而是最贵的之一。公式很短:

有效单位成本 = 命中率 × 缓存读价 + (1 − 命中率) × 输入价

选供应商用这个算,别看标价。标价只管公式的后半截,命中率高的供应商,大部分流量走的是前半截那个便宜得多的缓存读价。

命中率为什么差这么多,得看各家把缓存存在哪。有一家是隐式缓存 5 分钟,每次命中自动续期,文档里写得明白。多数托管商不公开 TTL,缓存放在 GPU 显存里做 LRU,忙时几分钟就被挤掉。唯一的长时效是模型官方源,硬盘缓存,能撑几小时到几天。陪聊流量的特点恰好是"用户隔一夜回来续聊",长 TTL 正好接住这批调用,托管商那种 5 分钟级的缓存救不了。

这一段还有个暗坑。手动钉供应商 order 之后,聚合层的 sticky routing 会被关掉,就是自动把同一会话钉到同一家供应商保缓存的那个机制。文档里只有一行小字,实测踩到才读懂。

反转三:切到官方源,流量为零

按公式算完,官方源是最优解:全网命中 81.4%,缓存读价只有输入价的 2%,比第二名便宜 10 倍。配置改完上线,盯着看板等命中率起飞。

官方源流量为零。请求全部落到第二顺位,重试次数还都是 1,不是失败后重试,是路由层压根没把它当候选。

排查半天,问题在账号的隐私设置:默认屏蔽"可能拿请求数据训练的付费端点",官方源在这个名单里。这不是配置写错,是一个真实的 tradeoff:用户对话数据可能被拿去训练,换成本降四成。这种开关不该由工程师排障时顺手打开,得拉决策者拍板。

顺手记一条排障经验:新加的供应商流量为零,先查账号级的过滤,隐私设置、屏蔽列表这类,查完了再怀疑配置写错。

最后的战报

命中率日线:切换前 61% 到 67%,切完第一天 80.8%,然后 87.2%、86.5%,峰值 91.1%。单位成本从 $0.068/M prompt token 降到 $0.026/M,降 62%;按消息算,每千条从 $0.324 降到 $0.164,降 49%。

最后一件事是归因。支出 = 消息量 × 单条成本,两个因子要分开量,不然回答不了"账单降了,是优化的功劳还是流量变了"。我们真实撞上过这个问题:账单断崖那一周,拆开一看,89% 是流量因素,优化真正贡献的是那 49% 的单价降幅。不拆开,这次汇报会把流量下滑记成自己的功劳,下次流量回来、账单涨了,还得反过来解释"优化怎么失效了"。

几条排障的土规矩

三个月下来还攒了几条不成文的排障规矩,每条背后都有一次白忙活。

报错卡要带会话 ID

CPU 超限这类平台级错误,默认告警里只有租户和路径。你知道炸了,不知道是哪条会话炸的。我们给错误处理加了一层:抛错时把 conversation_id 和用户消息预览一起带上。加完第一周,就靠它锁定了三条"活体样本"会话,画像是同一个:单会话连续爆,之后自愈,典型的瞬态问题。

先查再断言

我们翻过两次车,栽在同一个地方:信了过期的记忆,没查实时状态。一次以为"改动还没发布",实际早发出去了;一次以为"bug 还没修",实际当天就修完了。两次都在错误的前提上白排查半天。之后立了规矩:判断部署状态,唯一依据是部署记录。记忆会过期,文档写的是"当时打算怎样",只有部署记录说的是"现在到底是什么"。

单次冒烟不下结论

回归套件 48 个用例,同一份代码连跑两遍,成绩差个 ±3 是常态,纯噪音。只跑一次就宣布"回归了"或者"修好了",等于拿一次掷硬币的结果写报告。现在的规矩:回归结论至少跑 5 次;成绩贴着及格线的,跑 10 次。多跑几遍花不了多少钱,下错结论返工才贵。

上游 500 和空回复分开数

上游模型出问题,监控上容易混成一笔账,其实是两种病。一种是接口真报错,finish_reason=error;另一种是模型正常结束、内容却是空的,finish_reason=stop 加空 content。前者该报警该重试,照常处理。后者有自己的脾气:供应商切换窗口里会短暂走高,过两天自己回落。我们吃过这个亏之后,把两个指标拆开数,并且约定:切换供应商后的头两天,空回复涨了先别急着修"新 bug",大概率是切换本身的震荡,等它自愈,不自愈再动手。

回头看这三个月:模型换了三次,供应商一个月里换了两次,prompt 也一直在改。换来换去,换不掉的是这套习惯:动刀之前先算账,发布之后盯着数据验证,出了问题带着会话 ID 去查,查之前先核对部署状态。

这门生意里,模型是采购来的,人设文案也出自运营之手。工程师真正交付的,是上面这些看不见的细节。