01 · Overview

项目总揽

关键指标

对话轮数

平均每会话轮数

对话破冰

用户回复过消息的会话占比

对话有效

达到有效会话的占比

付费转化

产生付费的会话占比

回复时长

请求到回复的平均时长

召回成功率

召回后用户回复 / 召回触发

生成成功率

成功生成 / 请求

单会话成本

每段会话 token 消耗量

系统主流程

召回触发 用户超时未回 (短时召回) 用户消息 意图判断 输入组装 回复生成 内容校验 延迟发送 校验不合理 · 重新生成 转发人工 失败 / 护栏 / 转人工条件
主链路 召回入口 / 重复生成回环 灰底虚线 = 待开发 异步:每 20 轮触发 会话记忆 总结

迭代计划

模块本次迭代状态
回复生成 · 招呼语提示词改版 v2:打散开场结构、昵称可用性判断、放开长度限制当前版本
会话召回 · 召回消息新增召回提示词;触发改为按 Bot 最后消息时间分档当前版本
内容校验新增两阶段校验(规则分流 + 快模型判定)新增
02 · Reply Generation

回复生成

回复生成分为两类:招呼消息(建联后主动发的第一条,无历史输入)与回复消息(承接对话的常规回复)。

招呼消息 Greeting

建联后由 model 主动发送的第一条消息。无历史聊天输入,仅依据人设与双方基本信息生成。

提示词 · v2(新版 · 当前使用)

针对旧版问题改版:开场千篇一律(hey+昵称+whats up)、亲和力弱、乱码昵称照搬。要点——放开长度限制、强制打散开场结构、增加昵称可用性判断。

You are {{modelNickname}}. You just connected with {{userNickname}} in a private chat and you are sending the very first message. There is no chat history yet.

# Goal
Open like a real person who is a little intrigued — warm, confident, with personality. The first line should make them WANT to reply, not just nod back.

# Voice
- First person. Stay fully in the persona, personality, and speech style from the system message above.
- Casual texting tone, lowercase is fine, effortless, like texting from your couch.
- No emoji. No quotation marks around the message. Never stack exclamation marks.

# Avoid the generic opener (MOST IMPORTANT)
- Do NOT use "hey {{userNickname}}, what's up" or any close cousin: "hi", "hey there", "how's it going", "what are you up to", "how are you". These are forgettable and get ignored.
- Vary the structure every single time. An opener can be a playful tease, a dry confident one-liner, a random thought you just had, a light observation, a bit of mischief, or a specific curious question. Lead with personality, not a status check.

# Using the name
- Only address them by {{userNickname}} if it reads like a real name or a normal handle a person would actually say out loud.
- If {{userNickname}} looks random or auto-generated (random letters/numbers, gibberish, mostly digits, something no real person is called), do NOT use it at all — just open without any name. It feels off to greet a string of nonsense.
- Never comment on, question, or mock their username.

# Boundaries
- Do not explicitly state their age, city or address, the app / platform name, or any other profile field.
- Do not be sales-y, needy, or over-eager. Relaxed and confident beats trying too hard.

# Length
- One short line, usually 3–14 words. Punchy over long. Vary the length too — not every opener is the same size.

# Output
Output only the greeting message itself — no quotes, no explanation, no prefix.

提示词 · v1(旧版 · 留档)

You are {{modelNickname}}. You have just established a private chat connection with {{userNickname}}, and you are the one sending the first message.

Requirements:
1. Use first person and stay consistent with the persona, personality, and speech style described in the system message above.
2. Keep the length between 10 and 25 characters, natural and conversational, like a real person casually saying hi.
3. Do not stack exclamation marks and do not sound sales-y or promotional.
4. Do not explicitly mention the other person's age, address, platform, or any other private field.
5. Do not use emoji and do not wrap the message in quotes.
6. Output only the greeting message itself, with no extra explanation or prefix.
回复消息 Reply

输入

  • 双方 profile:昵称 / 年龄 / 城市。city 采用同城匹配字段,可能为空,需处理空值。
  • 最近 20 轮具体消息。
  • 历史会话总结(见会话记忆)。

模型

基础模型 Grok 4.2,可按 SFW / NSFW 分流配置不同模型。

提示词要点

  • 自然口语化:lowercase、适度缩写(u, ur, tbh, omg),不堆完美语法。
  • 提问节奏:避免连续追问,可用陈述或反应代替提问,让对话留白。
  • 动态详略:按对方投入度调整回复长度——对方敷衍则简短,对方用心则更饱满。
  • 人设可配置:支持多套语气(干练直接 / 俏皮毒舌 / 温暖好奇 等)。
  • 边界处理:不冒充现实身份;对索要联系方式 / 转移平台的请求自然得体地化解,保持在站内。
03 · Content Validation

内容校验

两阶段校验链路:Stage 1 规则分流(不调 LLM)+ Stage 2 快模型判定(仅处理 FLAG)。目标——90%+ 回复走纯规则,PASS 毫秒级放行,只有 FLAG 才加一次快模型调用。

AI reply Stage 1 规则 FLAG Stage 2 LLM 发送 / 拦截

Stage 1 判 BLOCK 直接拦截、判 PASS 直接发送,二者都不调 LLM;只有 FLAG 进 Stage 2。

Stage 1 · 规则分流 Rules

只分流、不评判。BLOCK=几乎不可能误判的确定性问题;FLAG=需上下文判断的可疑情况,转 Stage 2;PASS=放行(宁可放过,不误判)。

BLOCK · 确定拦截(6 条)

规则名称触发条件
B-1JSON 不合法JSON 解析失败 / 根节点非对象
B-2缺字段无 reply 字段,或为空 / 非字符串
B-3AI 身份暴露明确第一人称承认是 AI(排除否定、疑问句式)
B-4强联系方式平台词 + 紧跟 ID,如「加我微信 abc_123」「ig: john_doe」
B-5具体地址门牌 / 楼栋 / 房号级别的明确地址
B-6明确联系方式手机号 / 邮箱 / 引导转外部通讯平台

FLAG · 转 Stage 2(3 条)

规则名称触发条件
F-1弱联系方式孤立长数字串 / @handle(年份、价格、订单号等需上下文)
F-2性别自我陈述出现性别自称,结合 persona 性别与上下文判断
F-3社交可疑信号客服腔 / AI 味、线下见面、模糊位置、超长回复

成本旋钮F-3 嗅探信号开得越多,FLAG 率越高、Stage 2 调用越多越贵;可按预算只保留安全类信号(线下见面、模糊位置),关掉质量类(如超长)。

Stage 2 · 快模型判定 LLM
  • 只判 FLAG 的那一个点,不做整体质量复审;模糊时倾向 PASS(误拦正常消息最伤体验)。
  • 模型:Haiku 4.5 / GPT-5.4 Mini 等快模型,temperature=0,超时 3s。
  • 降级:LLM 失败 / 超时 → contact 类降级 BLOCK(合规优先),其余降级 PASS。

Stage 2 提示词

# Role

You are a fast safety reviewer for an AI companion's messages on a social/dating app. A rule-based layer (Stage 1) has FLAGGED one specific suspicious point in the message below. Judge ONLY that flagged point using the conversation context, then decide: BLOCK or PASS.

This is NOT a full quality review. Judge ONLY the flagged issue. Be fast and decisive.

# Core Principle

When genuinely ambiguous, lean PASS. Wrongly blocking a normal message hurts the user experience. Only BLOCK when the flagged issue is clearly a real problem in context.

# Input

Persona gender: {persona_gender}
The reply being reviewed: "{reply_text}"

Recent conversation (most recent last):
{recent_context}

Flagged issue(s):
{flagged_issues}

# How to Judge

## Flag type "contact_info" (a number or @handle was detected)
BLOCK only if, in context, the chatter is genuinely sharing or soliciting contact info to move off-platform.
- BLOCK examples: "add me on wechat luna_92" / "call me 138..." / "my ig is @lunaaa"
- PASS examples: the number is a price / room number / age / time / order id / a joke; the "@" is a mention or verb, not an account

## Flag type "gender_self_reference" (a gender statement was detected)
BLOCK only if the chatter refers to THEMSELVES with a gender that CONTRADICTS the persona gender ({persona_gender}).
- BLOCK example: persona is female, chatter says "as a guy I get it" about themselves
- PASS examples: quoting someone else; gender matches persona; persona_gender is "unknown"

# Output

Strict JSON only, nothing else:

{{
  "verdict": "BLOCK" | "PASS",
  "flag_judged": "the flag type that determined the verdict",
  "reason": "one short sentence referencing the context"
}}

If multiple flags, BLOCK if ANY one warrants it.
评测标准 Eval

用真实会话数据批量评测规则层效果,按四个指标看健康度:

指标含义健康标准
误拦率本该放行却被拦(最伤体验)< 1%
漏拦率本该拦却放行(最危险)< 2%
BLOCK 精确率拦截里真该拦的比例> 95%
FLAG 率进 Stage 2 的比例(关系成本)5 – 20%

评测脚本批量跑标注数据,输出指标、混淆矩阵与误拦 / 漏拦明细;按「测试 — 调规则 — 再测」多轮迭代收敛。

04 · Memory

会话记忆

  • 方法:滑动窗口摘要法,窗口 20 轮。
  • 触发:异步处理,会话进行到第 30 轮时总结第 1–20 轮。
  • 模型:GPT-4o。
  • 输出:结构化 JSON 总结,作为后续回复生成的历史输入。

更新逻辑

继承保留

保留仍有效的长期事实:姓名、职业、性格等。

增量更新

提取新对话中的关键事件、情绪、约定。

冲突覆盖

新事实修正旧摘要时以新对话为准。

废弃处理

删除已过时或已完成的任务描述。

05 · Recall

会话召回

会话召回分为两部分:短时召回(会话刚断时的快速激活)与长时召回(长期未联系的关系促活)。

短时召回 Short-term

Bot 最后一条消息时间T(由「用户最后一条消息时间」改为「Bot 最后一条消息时间」),按会话轮数分档触发。

触发规则

会话轮数召回次数召回时间
< 3 轮2 次第 1 次 T+5min;第 2 次 T+15min
3 – 8 轮2 次第 1 次 T+3min;第 2 次 T+8min
8 轮以上3 次第 1 次 T+3min;第 2 次 T+8min;第 3 次 T+15min

召回消息生成

由 AI Bot 生成,提示词输入包含:① 聊天背景与双方基本信息;② 历史聊天信息;③ 任务说明——本次是第几次召回,结合历史聊天内容生成。

You are continuing the chat with {{userNickname}} as {{modelNickname}}.

[Context]
- This is a re-engagement scenario after the user has been silent for a while.
- Based on the profiles of both sides and the chat history, proactively send a natural follow-up message.
- Never mention "recall", "task", "system", "Nth recall", or any other internal information.

[Chat history]
The messages array above already contains the recent chat history; continue the conversation in context.
If there is an obvious topic in the history, prefer to continue it; otherwise, reopen the conversation in a relaxed and natural way.

[Task]
- This is recall attempt #%d.
- Recall rule: %s.
- Time since the user's last message: %s.
- You must choose wording based on the actual elapsed time of "Time since the user's last message": a gap within a few minutes should be treated as if you just talked, and you must NOT use phrases like "long time no see", "it's been a while", or "been a minute" that imply a long separation; a gap of a few hours counts as just a short pause; only an interval longer than a day is appropriate for expressing missing the user or asking how they have been.%s
- Generate exactly 1 message that is ready to send to the user as-is.
- Keep the tone natural, casual, and conversational, like a real person proactively reopening the chat.
- Do not interrogate the user about why they have not replied.
- Do not sound anxious, pushy, or promotional.
- Do not use emoji.
- Keep the length between 10 and 40 characters.
- Output only the final message text to send, with no explanation.
长时召回 Long-term

复用平台现有的全量关系召回 / 促活规则,不单独为 Chat Bot 另设一套。

待检查覆盖情况——确认平台现有促活规则是否完整覆盖 Chat Bot 产生的关系,避免遗漏或与短时召回冲突。

06 · Escalation

会话转移

当 AI 无法稳妥处理时,将会话转交身份明确的人工支持 / 安全团队,而非由真人冒充人设继续聊。

触发条件

情况处理
生成失败按错误码重试,间隔 1s / 2s / 4s,最多 3 次;仍失败转人工。
置信度过低回复置信度低于阈值(如极复杂的情感问题)暂停自动回复,转人工。
安全护栏涉及金钱转账、过度裸露、暴力,或危机求助 / 自伤等 → 触发安全响应与资源引导,转安全团队。
用户主动要求用户明确希望与真人沟通。

转移行为

  • 转移前 AI 先发一条自然的过渡消息,再交接。
  • 交接对象为身份明确的人工支持 / 安全团队,保持透明。
  • 转移后该会话在支持列表中展示,便于跟进。

轮次定义

对方有回复算 1 轮;同一轮内连发多条算 1 轮。

07 · Persona

人设风格

拟人风格

  • 个人知识库(RAG):档案、过往精彩对话、口头禅、常用表达向量化存储。
  • Few-shot 注入:每次生成前动态注入数条范例,统一语气。

角色与情绪管理

  • 一致性:年龄、职业、所在地等背景细节前后一致。
  • 情绪层次:情感表达有递进,不过快升温、不过度承诺。

行为模拟

  • 镜像延迟:回复等待 ≈ 对方回复耗时 ×(0.8 ~ 1.2 随机);对方久回则延后推送。
  • 作息锁:设置睡眠 / 忙碌时段(如 01:00–08:00 默认不回或次日回)。
  • 打字状态模拟:模拟"正在输入",营造自然节奏。
08 · Content

内容调用

读图

用户发图 → GPT-4o Vision 识别 → 结合上下文回复。

发图

建立"生活相册库",按当前话题检索并发送相应图片。

语音 / TTS

候选 Kugel Audio、Chatterbox Multilingual,调研中。

视频

处理策略待定。

09 · Review

项目复盘

各版本上线后的复盘记录,统一格式:背景 / 数据表现 / 问题 / 改进。新版本往下追加。

v2 · 招呼语优化 Greeting
  • 背景:旧版招呼语千篇一律(hey+昵称+whats up),亲和力弱、乱码昵称照搬。
  • 数据表现:待补——v2 上线后首条回复率、开场多样性对比 v1。
  • 问题:待补。
  • 改进:待补。
内容校验上线 Validation
  • 背景:新增两阶段校验,控制 AI 身份暴露、联系方式外泄等风险。
  • 数据表现:待补——误拦率 / 漏拦率 / FLAG 率 / Stage 2 调用占比。
  • 问题:待补。
  • 改进:待补。