2.1 目标冲突，人格会污染判断#

主对话的人格要求是：像好朋友、先共情、站用户这边、别像咨询师、别输出报告。

而风险检测的要求正好相反：冷静、中性、严格 JSON、不要安慰、不要道德判断。

如果共用一套提示词，模型会带着“站用户这边”的倾向去判风险。结果要么把正常冲突判成操控，要么因为怕伤害用户而漏报。安全判定被陪伴人格带偏，这是产品上不能接受的。

2.2 输出契约冲突#

主回复是流式自然语言，还要按分隔符切成多个聊天气泡。辅助任务要的是能被代码直接解析的 JSON，例如三态风险结论、命中项 ID、数值 delta。

一个提示词同时要求“自然聊天”和“只输出 JSON”，模型一定会在某一边妥协。实际表现就是：要么回复里冒出 JSON，要么检测结果带一堆解释文字导致解析失败。

2.3 延迟和成本被绑死#

主对话必须尽快出第一个字。意图分类、标题、后续问题这些任务根本不值得用最贵的模型。

如果所有事都塞进主调用，等于每条用户消息都按主模型的成本和时间跑一遍，而且主模型的上下文会被大量与回复无关的指令占满。

2.4 提示词无法独立迭代#

在这个产品里，提示词是运营内容，不是代码常量。今天调风险判定的尺度，明天调人格语气。

如果只有一个大提示词，任何一次微调都可能把主对话改坏，而且没法单独回滚，也无法判断改动到底影响了哪一部分。

2.5 失败代价不同#

主回复失败是用户可见的故障；风险检测失败应该静默降级；记忆抽取失败可以下次再补。

把它们绑在同一次调用里，等于让“低价值、可失败”的任务拥有了拖垮“高价值、不可失败”任务的能力。这是架构上最不能接受的耦合。

4.1 消息先落库，再开流#

用户消息先写入数据库，拿到稳定的消息 ID，前端再用这个 ID 建立 SSE。

这样即使模型调用失败，用户消息不会丢，重试也有稳定锚点。流式回复和消息持久化解耦，是后面所有失败处理的前提：告警卡片、扣费、记忆抽取都要挂在这条消息上。

4.2 意图识别：规则优先，模型兜底#

第一步不是直接调模型，而是先跑正则快路径。像“做测试”“我想测评”“take the test”这种明确表达，直接命中，不产生模型调用。

只有模糊表达才走小模型分类，要求只返回类似 {"intent":"TAKE_RELATIONSHIP_ASSESSMENT"} 或 {"intent":"NONE"} 的结果。模型超时或报错，再退回关键词兜底；还不行就当作没有意图，继续正常聊天。

如果命中意图，主链路直接短路：不生成聊天回复，改为保存一条测评引导消息推给前端。

这一步的价值是：能用规则判的绝不花钱调模型，模型只处理语义模糊的地带。它也是整条链路上唯一一个同步等待的辅助节点，所以超时预算必须卡得很紧，通常配置在两秒多。

4.3 风险检测：并行、异步、与主回复隔离#

在组装主上下文之前，两个风险检测任务已经并行发出去了。

情感操控风险检测的输入是当前会话里所有用户消息，因为操控往往是模式，而不是单句。输出是三态：命中、未命中、证据不足，并附带一句原因和少量关键词。同一个关系画像同一个本地日期只告警一次。

雷点检测的输入是最新一条用户消息，加上用户画像里最多几十个活跃雷点。模型只能从给定的雷点里选一个 ID，不能自己编。

两个任务都在主模型调用期间并行执行，等主回复落库之后才去收集结果。任何一个超时或异常，统一降级成“证据不足”，不打断聊天。

这里有两个容易被忽略的工程细节：

第一，去重不能靠“先查再插”。 每日去重靠的是“关系画像 + 本地日期”的唯一约束。两个标签页同时发消息时，后到的请求会撞唯一约束。系统把这种数据库冲突当成“今天已经告过警”正常返回，而不是当系统错误。如果不处理，日志里会全是假告警，运营也没法判断告警是不是真的坏了。

第二，异步结果不能反过来影响本轮回复。 这是有意的取舍。检测是异步的，主回复已经开始流式输出，结果只能在本轮之后追加告警卡片。如果要求检测影响回复内容，就必须同步阻塞，首字延迟会明显变差。产品上选择了“先回复，再补风险提示”。

4.4 主上下文装配：分层、过滤、预算#

主对话看到的不是“历史消息 + 用户问题”，而是多层拼装：

几个值得讲的细节：

记忆放在人格里，还是单独一条系统消息？ 人格模板里可以保留一个记忆占位符。如果模板写了占位符，记忆会被渲染进人格提示词内部；如果没写，才作为独立系统消息追加。这是提示词层面的选择：记忆放在人格里，模型更愿意把它当“我对这个人的了解”，而不是一条外挂指令。

卡片消息必须过滤掉。 数据库里除了正常对话，还有测评引导、风险卡片、雷点卡片、雷点图片。这些在拼上下文时会被排除。否则模型会把自己系统生成的 UI 卡片当成对话内容，回复就会变得很奇怪。

检索是混合的，不是纯向量。 查询同时走向量表示和词法表示，做混合召回，再按最低分阈值过滤。这样既能处理语义相近，也能兜住关键词精确命中；召不回就当作没有检索结果，不阻塞主流程。

4.5 流式生成与气泡切分#

主模型流式返回。这里有一个很细的坑：系统要求模型用特定分隔符分隔聊天气泡，但流式 chunk 是按字节边界来的，分隔符很可能被切成两半。

所以流式转发时会在尾部保留一小段字符不立即发，等确认不是半个分隔符再放出去。生成结束后再按分隔符切分，最多保留四段；如果模型没有输出分隔符，就整段当一条消息。

这样前端拿到的是一组气泡，而不是一大段文字。这个细节看起来小，但如果不做，用户会偶尔看到被截断的怪字符，或者气泡分错。

4.6 落库、扣费与失败回滚#

回复完整后先落库，再按模型返回的 token 用量扣费。

如果扣费时发现余额不足，会把刚保存的助手消息删掉再抛错。不能让用户看到一条“已经生成但没付费”的消息，也不能让后续上下文里留着一条失败的回复。

4.7 回复后处理#

主回复已经发给用户之后，才去等风险检测的结果。命中就保存告警卡片消息并推送事件；未命中、超时、解析失败都静默结束。

标题生成只在会话标题仍是占位符、且这是第一轮对话时触发。输入是用户第一句和助手第一段回复，要求输出短标题，限制字符数，并去掉引号和结尾标点。失败就保留占位，用户无感。

后置测评引导是另一条业务规则：不是每轮都推，只在满足条件时追加，避免把聊天变成广告位。

4.8 不在关键路径上的节点#

以下能力不在聊天关键路径上：

• 记忆抽取：定时扫描，用户静默几秒后才处理，避免每句话都调模型。用游标记录“上次处理到哪条消息”，只处理增量；写入前还会按消息 ID 去重，防止即时雷点检测和后台抽取重复计数。
• 关系分数更新：对增量用户消息按本地日期分组，逐日做多维度 delta。每个 delta 有上下限，并且不能把总分推出合法区间；格式解析失败会带提示重试一次，仍失败就把这一天标记为已处理并继续，不卡住后面的批次。
• 后续问题：不是主 SSE 的一部分，由前端单独请求；只有助手回复超过一定长度才生成，短回复不浪费调用。
• 关系测评：规则引擎先算分，分数立刻以预览事件推给前端；模型只负责把分数解释成叙述报告，提示词里明确写“规则分数是权威值，不许改分”。报告落库时再让模型润色正文，失败则回退到规则引擎给出的固定文本。

5.1 模型做判断，代码做裁决#

最终结论不交给模型：

• 雷点检测让模型从给定列表里选 ID，代码再校验这个 ID 确实存在、是活跃的、类型匹配。模型编一个 ID 出来会被拒绝。
• 关系分数不是让模型自由给分，而是给当前分、给 delta 上下限，模型只能在这个范围里调。
• 测评分数由规则引擎算，模型只负责解释。提示词里写死“分数是权威值”。
• 意图识别命中后，代码再决定是否真的短路，而不是模型直接控制流程。

一句话：模型负责语义理解，业务口径和边界由代码守住。

5.2 假设模型会不听话#

提示词里写“只输出严格 JSON”，但代码从不假设它真的只输出 JSON：

• 先去掉 Markdown 代码围栏；
• 从文本里截取第一个左花括号到最后一个右花括号；
• 字段缺失、类型不对、枚举值不认识，统一落到“证据不足”或默认值；
• 解析失败不抛到主链路。

这是多调用系统能稳定的前提：每个节点都自带降级路径，而不是指望上游永远正确。模型是一个会犯错的协作者，不是一台确定性函数。

7.1 版本模型#

每个提示词有模板和多个版本，版本状态分为草稿、已发布、已归档。

• 发布新版本时，旧版本自动归档。
• 回滚不是把旧版本直接改回“已发布”，而是复制成一份新草稿再发布。这样历史版本永远不可变，审计链是干净的。
• 保存草稿时会校验：系统提示词和用户提示词不能同时为空、单段长度不能超过上限、扩展字段必须是合法 JSON。
• 发布动作会写审计日志，记录是谁、在什么时候、发布了哪个版本。

这套机制解决的是“提示词谁来改、改坏了怎么退”。如果提示词只写在代码里，运营每次调语气都要发版，这是不现实的。

7.2 运行时读取与缓存#

运行时优先读数据库中的已发布版本，读不到再回退到代码默认值。结果按较短 TTL 缓存在内存里，发布时主动失效。

这样既保证了运营改完能较快生效，又避免每次对话都查库。回退到代码默认值这一点也很重要：数据库里没有模板、或者读取异常时，聊天不能因此不可用。

7.3 环境间同步#

生产环境的提示词可以导出成快照文件，本地开发启动时自动应用到开发库。这个过程不通过管理接口，也不重启服务，而是直接对比快照和本地库，缺的创建、不一致的归档旧版并发布新版、一致的跳过。

应用前支持 dry-run，先看会创建几条、更新几条、跳过几条。另外保留一份候选快照用于实验。评估脚本只读快照，不写数据库、不调管理接口，所以可以放心在本地反复跑。