AI 相亲 专业屏蔽海王这个方向最容易被人误解成“让 AI 替我谈恋爱”但真正有用的部分远没有那么浪漫。它核心要做的事情是从相亲对象的聊天记录里提取可观察的语言模式暧昧话术是不是模板、承诺是不是被刻意回避、时间线是不是前后矛盾、联系节奏是不是碎片化、是不是同时在维持多条线。把这些原本靠直觉和情绪判断的东西变成结构化数据和风险提示这样才能提前把海王信号摆在桌面上而不是等上头之后再去复盘。我完整跑过一轮用大模型分析相亲聊天记录的小实验最终验证下来AI 能解决的不是“这个人喜不喜欢你”而是“这个人说话和相处模式里有没有值得警惕的坑”。整套流程并不复杂但每一步都有容易翻车的地方数据没清洗干净、提示词设置太激进、模型幻觉、上下文切分不合理都会让结果失真。下面按实际落地顺序拆一遍从准备数据到调通分析再到升级成自动预警工作流。1. 先搞清楚AI 相亲里的“屏蔽海王”到底指什么能力1.1 “海王信号”不是聊得好不好而是聊天模式海王式的人往往不是那种一上来就明显冷淡的对象。恰恰相反很多人前期会表现得很热情、很会接话、很懂情绪价值。真正的问题出在模式上同一套夸奖话术在不同时段重复出现一聊到关系定义就转移话题关于工作地点和家庭情况的描述前后对不上回复时间长期集中在深夜且经常突然消失。人脑处理这些信息很容易被情绪盖住。今天一句“早安”、明天一句“想你了”很容易把零散的违和感压下去。AI 的强项不在感情判断而在于它能把一个月的聊天记录切成时间和话题块反复比对相似表达、时间规律和事实矛盾然后输出一份带证据原文的风险清单。1.2 AI 能做和不能做的边界先说能做的部分。用大模型做一个“聊天记录风险分析器”可以处理这几件事识别话术复用同一个夸赞、段子、关心模板是否在不同时间反复出现。识别承诺回避对方是否在关系定义、见面安排、未来规划上长期使用“顺其自然”“到时候再说”这类模糊表达。识别信息不一致工作、居住地、家庭情况、行程描述是否前后矛盾。识别节奏异常认识几天就出现亲密称呼或者在没有现实基础的情况下频繁表达“命中注定”。识别联络碎片化长期只在深夜回复、每次只回一两句、经常消失几天再若无其事回来。识别资源导向是否过早询问收入、储蓄、礼物价值甚至涉及借钱、投资类话题。不能做的部分同样要划清楚AI 只能基于对话文本做模式推断它做不了背景调查、征信查询、学历核验更不能越权去获取任何个人隐私。相亲中如果需要核实学历、工作、婚史应该在现实中通过正规渠道和当面沟通确认而不是依赖聊天记录分析猜断。所有“海王识别”都只能作为风险提示不能当成事实结论更不能把分析结果公开或用于羞辱对方。1.3 这套方案适合谁不适合谁适合两类人。一类是在相亲软件上认识陌生人想在投入感情之前建立一套筛选机制不想靠“感觉”做决定的人。另一类是已经被套路伤害过意识到自己容易吃情绪价值这一套需要外部工具来冷静判断的人。不适合三种人。第一种是只想听“对方很靠谱”这种安慰的人AI 给不了这种承诺。第二种是希望完全替代线下相处判断的人聊天记录分析只是证据链的一部分。第三种是想用技术去定位、骚扰、攻击对方的人那已经超出了正常自保范围不要在相亲辅助工具里这么用。2. 落地之前先把数据和模型选对2.1 本地模型和 API 模型怎么权衡聊天记录是最典型的敏感数据。选模型前先想清楚数据会去哪里。方案类型优势主要限制适合场景本地部署开源模型数据不出本机隐私性最好需要配置显卡和内存部署成本高对隐私极度敏感电脑配置较好商用 API 模型分析能力更强调用方便数据会上传到服务端需要严格脱敏想快速跑通愿意遵守脱敏规则网页端 AI 助手零配置直接粘贴文本不适合批量处理文本粘贴过长会截断偶尔分析少量对话不想写代码如果只是学习先选 API 方案最省事。如果打算长期跟踪一个相亲对象的聊天记录建议把脱敏做到位或者直接考虑本地模型。我实际测试时的经验是本地小模型在普通配置下也能分析但处理长文本的速度会明显下降只适合几十条记录的小样本API 方案在批量场景更稳但要控制调用量和 credits 消耗不要一开始就全量跑。2.2 最小数据集CSV 结构怎么设计分析前要先把聊天记录整理成结构化数据不能直接拿一坨微信导出文本丢给模型。建议设计成这样sender,timestamp,message_type,content,is_read A,2025-01-05 20:13,text,今天工作忙不忙,1 B,2025-01-05 20:15,text,还好 刚下班,1 A,2025-01-05 20:18,text,这么辛苦 周末请你吃饭吧,0 B,2025-01-05 20:22,text,到时候再看吧,0字段含义sender发送方。这里建议用 A、B 代称不要写真实姓名。timestamp消息时间必须保留到分钟。回复节奏分析靠的就是这个字段。message_type文本、语音、图片、转账、系统消息。不同类型处理方式不同。content文本内容。语音如果可以转文字就转文字表情包可以统一标记为[emoji]。is_read是否已读。这个字段用来判断“看到了但不回”的情况这是海王信号里很关键的线索。这个 CSV 就是分析流程的输入底座。字段越规范后面提示词和统计代码就越简单。2.3 脱敏规则哪些内容必须替换任何要传给外部大模型的数据都必须先脱敏。我一般会做两层处理第一层是字段替换第二层是在分析内容里去除不可逆信息。需要替换的字段包括姓名替换成 A、B、C 这类代号。城市替换成“一线城市”“南方二线城市”这类大范围描述。公司替换成“某互联网公司”“某金融机构”不要保留精确名称。小区、学校、餐饮店名等地理位置替换成“某小区”“某高校”。绝对不能上送的字段包括身份证号、银行卡号、家庭详细地址、人脸照片、语音原文件、工作证件照片。很多人在这一步嫌麻烦觉得“就一个相亲对象没关系”。但在 API 场景里数据一旦发出去你无法控制模型服务端会不会继续用这些数据。合规的底线是能不给就不给给出去前先去掉可识别身份的信息。真要做到严格隐私保护就上本地模型但本地模型成本更高需要你自己权衡。3. 核心实操从聊天记录到结构化分析报告3.1 导出聊天记录时要注意什么先看聊天软件提供了什么导出能力。有的聊天软件电脑端支持把聊天记录导出为文本或通过备份工具迁移有的只能在手机端手动选择消息再复制。无论哪种方式都要注意三件事第一优先保留时间戳。如果导出结果里没有时间后面做回复节奏分析会很麻烦。很多第三方导出工具可以输出带时间的 CSV尽量选这种。第二合并转发消息要单独标记。对方如果转发别人的对话过来里面可能混着其他人的信息分析时要排除否则会干扰判断。第三撤回提示、系统提示、群聊通知都要清理。比如“你撤回了一条消息”这种系统提示分析价值很低直接标记为system类型后续清洗时过滤掉。导出完成后建议把原始文件留存一份带版本号比如raw_20250105.csv然后另存一份clean_20250105.csv给分析流程使用。这样可以随时回查避免清洗时误删有效信息。3.2 数据清洗把原始文本变成对话块清洗这一步不能省。脏数据直接影响分析质量常见的坑有三个CSV 编码问题。微信导出或部分第三方工具默认可能是 GBK 编码Python 读取时容易乱码处理时要带上encodingutf-8-sig或encodinggbk。连续图片消息。模型读不了图片内容但图片本身也有信息。统一替换成[图片]并保留时间戳这样至少能判断对方是否频繁发图、转移话题。语音消息。如果能转文字就转文字不能转就标记为[语音]。不要直接把语音文件塞给模型。清洗之后不要一次性把所有记录丢进去。模型上下文有限长文本也容易“中间夹层注意不到”。我建议按天切块如果某天聊天记录超过 4000 字再按话题边界拆成多个块。每个对话块至少保留 20 条消息太少的话模型很难判断模式会乱猜。3.3 调用大模型逐段分析一段可运行示例下面是一段兼容 OpenAI 接口的 Python 示例核心逻辑是读取清洗好的 CSV按天分组后逐块调用大模型。import csv import json from openai import OpenAI # 以常见的 OpenAI 兼容接口为例具体地址和密钥换成你自己环境里的 client OpenAI( api_keyyour-api-key, base_urlhttps://your-api-endpoint ) SYSTEM_PROMPT 你是一名亲密关系风险分析助手。你的任务是从聊天记录中识别可观察的语言模式并输出 JSON 结果。 不要基于性别、职业、收入做武断判断只能根据聊天文本本身分析。 每条线索必须包含原句引用。没有证据的维度返回 null。 def clean_data(source_path): rows [] with open(source_path, r, encodingutf-8-sig) as f: reader csv.DictReader(f) for row in reader: # 过滤系统消息和撤回提示 if row[message_type] in (system, recall): continue rows.append(row) return rows def group_by_date(rows): groups {} for row in rows: date row[timestamp][:10] groups.setdefault(date, []).append(row) return groups def analyze_block(client, system_prompt, block): text \n.join( f{row[sender]} {row[timestamp]}: {row[content]} for row in block ) resp client.chat.completions.create( modelyour-model-name, temperature0.2, # 如果模型支持可以开启 JSON 输出不支持时靠提示词约束 messages[ {role: system, content: system_prompt}, {role: user, content: f请分析以下聊天记录块\n{text}} ] ) content resp.choices[0].message.content return json.loads(content) rows clean_data(clean_20250105.csv) groups group_by_date(rows) results [] for date, block in groups.items(): if len(block) 20: continue try: result analyze_block(client, SYSTEM_PROMPT, block) result[date] date results.append(result) print(date, 分析完成) except Exception as exc: print(date, 分析失败, exc)这段代码是测试骨架不是生产方案。实际使用时要补上错误重试、输出目录、结果落库和日志。早期不要追求漂亮工程先把一条记录跑通。3.4 汇总维度并生成报告每段对话块会返回一组 JSON 结果格式建议统一成这样{ promise_avoidance: { level: medium, evidence: [到时候再看吧, 顺其自然就好], confidence: 0.7 }, template_reruns: { level: low, evidence: null, confidence: 0.2 }, inconsistency: { level: null, evidence: [], confidence: 0.0 }, rush_rhythm: { level: low, evidence: [好想见你], confidence: 0.3 } }汇总阶段再按维度统计次数和最高置信度。比如一个月记录分成 20 个对话块其中有 12 个块都出现了承诺回避置信度超过 0.6那这条线索就值得重视。如果只有一个块出现一次低置信度提示就先标记为普通待观察不要急着下结论。4. 提示词怎么设计才能识别海王而不是误伤4.1 分析维度先定下来模型才不会乱带节奏提示词最忌一句话“请判断对方是不是海王”。模型没有统一标准也不知道你具体要什么结果会非常不稳定。正确做法是先定义维度。我习惯用六个维度每个维度都给出明确的文字定义和可观察例子承诺回避当对方主动询问关系定义、未来安排或见面计划时是否转移话题、使用模糊表达、长期不给确定答案。话术复用类似夸奖、关心、段子、口头承诺是否在不同日期反复出现且措辞相近。信息不一致对工作、居住地、家庭情况、行程安排等事实的描述是否前后矛盾。节奏异常认识初期是否过快使用非常亲密的称呼或表达明显超出双方熟识程度。碎片式联络是否长期在深夜回复间隔时间混乱经常消失较长时间后若无其事继续。资源导向是否过早谈论收入、资产、礼物、借钱、投资等与经济资源相关的话题。维度定义清楚之后模型的输出才有可比性。后续做统计和预警也是围绕这些维度展开。4.2 一份可直接修改的系统提示词模板你是亲密关系风险分析助手。请根据用户提供的聊天记录输出 JSON 格式分析结果。 分析维度只有以下六个 1. promise_avoidance承诺回避。检测对方是否回避关系定义、见面安排、未来规划。 2. template_reruns话术复用。检测类似的表达是否在多个时间点重复出现。 3. inconsistency信息不一致。检测工作、居住地、家庭、行程等事实描述是否矛盾。 4. rush_rhythm节奏异常。检测亲密称呼、亲密表达是否早于双方熟识程度。 5. fragment_contact碎片式联络。检测回复时间是否集中在深夜、是否频繁长时间失联。 6. resource_asking资源导向。检测是否过早谈论收入、礼物、借钱、投资等话题。 输出要求 - 只输出 JSON不要输出解释不要使用 markdown 代码块。 - 每个维度包含 level、evidence、confidence 三个字段。 - level 只能是 high、medium、low、null 之一。 - evidence 必须是聊天记录里的原句或高度接近的复述。没有证据时 evidence 为空数组level 为 null。 - confidence 是 0 到 1 之间的数字表示你对该线索可观察性的把握不是对对方人品的判定。这段提示词把一个模糊问题转换成了六个可打分维度。模型不会随便编一个“对方是渣男”的结论它只能输出什么维度有哪些证据、置信度多高。这里最关键的是evidence字段它强制模型给结论提供证据支撑能有效降低幻觉。4.3 控制误判的三个关键参数第一个是温度。temperature 建议调低到 0.2 左右。温度太高会让模型输出更“有想象力”分析任务要的是稳定不是创意。第二个是上下文。一个对话块至少要有 20 条消息最好能有完整的一天或一个话题段落。消息太少模型只能从零星几句话里强行推断误判率会明显上升。第三个是系统提示词的中立性。不要在提示词里写“对方可能是海王请找出证据”这会触发模型的确认偏误本来正常的对话也会被解读成问题。系统提示词要保持中立只要求模型输出可观察的证据不预设结论。注意模型输出的“level: high”只代表这一块对话里有明显迹象不代表对方一定是海王。是否核实、怎么处理取决于现实中的进一步接触。5. 结果验证哪些结论能信哪些必须打问号5.1 置信度不等于事实概率模型输出confidence: 0.8很多人会以为这是“80% 概率是海王”。这种理解是错的。这个置信度只是模型对“自己判断是否可观察”的一种内部表达不一定代表真实概率更不代表事实。真正该看的是 evidence。拿到结果后第一步不是分析 confidence而是拿 evidence 逐条去原始聊天记录里搜看这句话是不是真的存在。如果搜不到那就是模型幻觉直接丢弃。如果能找到再判断原句的真实语境是不是被误解了。我一般会写一个小脚本把模型输出的每条 evidence 去原始 CSV 里做模糊匹配匹配不到就自动标记为“疑似幻觉”。这一步是分析结果可靠性的第一道防线。5.2 怎么交叉验证同一份数据单次输出不稳定不代表模型能力不行可能是随机性或提示词边界问题。验证方法有三种抽样复核。从一个月记录里随机抽 10% 的对话块人工阅读后与 AI 结果对比看判断是否一致。重复运行。同一段对话跑两次看两次输出的维度和证据是否基本相同。如果两次天差地别说明模型对这个输入不稳定。换模型交叉。换另一个模型跑同一份数据对比两个模型的结论。重叠度越高越值得参考。这三种方式不用每次都做。第一次搭建流程时做一轮后面如果模型输出稳定可以只保留抽样复核。5.3 一条线索不能定性一组模式才值得关注海王识别最难的地方在于任何单一信号都可能被合理解释。对方回复慢可能是在加班对方不想讨论关系可能是慢热对方夸你好看可能是正常表达。单看任何一条都能找到无害的解释。所以判断标准要放在模式层面。我建议这样设阈值短期观察单个维度出现 1 到 2 次 medium 级线索先记录不处理。重点关注同一维度在 3 个以上对话块里反复出现且 confidence 都超过 0.6。预警至少 3 个维度同时命中或者同一维度持续一周以上反复命中。只有组合模式下才值得把对方纳入“需进一步核实”名单。另外要给“对方本来就忙”留出解释空间。可以先看对方工作日的正常回复节奏再对照异常时段不以一次失联下结论。6. 常见翻车现场和系统化排查顺序6.1 现象所有消息都被标成“疑似海王”出现这种情况八成是提示词问题。系统提示词如果没有明确要求“没有证据就返回 null”模型为了完成任务可能会强行给每个维度打分导致正常对话也被贴上风险标签。先把系统提示词里的输出要求改成“level 可以是 null”“没有证据时 evidence 为空数组”。然后再看置信度分布如果大部分结果都在 0.5 以上说明模型还是给得太宽松可以追加一句“只识别明确重复出现或明显矛盾的模式”。6.2 现象模型死活不说风险另一种极端是模型什么都不敢判断所有 level 都是 null。常见原因是对话块太短模型没有足够的上下文做判断。也有可能是系统提示词里写了太多“不要伤害关系”“不要武断”之类的话模型被带向保守方向。优先检查对话块是否少于 20 条消息。如果数据够但还是不敢判断就删掉提示词里过度保守的字段改成“你能识别的风险迹象请客观输出”。6.3 现象JSON 解析失败或中文乱码JSON 解析失败通常是模型返回了带 markdown 代码块的内容比如{...}Python 直接json.loads会报错。解决方法是先提取代码块内容再去掉首尾的json 和。也可以用正则匹配第一个{到最后一个}之间的内容再解析。中文乱码一般在 CSV 读取阶段就会发生。解决方案就是读取时带上正确的编码参数。如果导出文件是 GBK就用encodinggbk如果是 Excel 另存的 CSV考虑用utf-8-sig。这个细节不用等模型调完才发现清洗阶段就能暴露。6.4 通用排查顺序遇到任何异常结果按下面顺序排查而不是一开始就怀疑模型能力。现象优先排查常见原因处理方式输出全是风险提示词是否中立没有设置“无证据返回 null”增加 null 出口降低打分倾向输出没有风险输入对话块长度上下文太少模型猜不出来把对话块扩到 20 条以上JSON 解析失败模型返回格式被 markdown 代码块包裹提取代码块再解析中文乱码CSV 编码GBK 和 UTF-8 不一致统一用 utf-8-sig 读取evidence 搜不到模型幻觉模型编造证据用模糊匹配过滤丢弃无法命中的证据结果不稳定temperature 参数温度过高调到 0.1 到 0.2 之间这个排查顺序通用性很强。先看现象再看输入然后看提示词最后才怀疑模型能力。很多问题并不是 AI 不行而是数据没洗干净、上下文太短、提示词把模型带偏了。7. 从一次性分析升级成 Agent 工作流7.1 自动日报和风险指数怎么设计如果每天都在和相亲对象聊天手动导数据、跑分析太累也没法持续跟踪。这时候可以把流程封装成一个定时任务每天增量处理新增聊天记录输出一份风险日报。核心是一个风险指数公式。举个例子risk_score 0.3 * 承诺回避命中次数 0.2 * 话术复用命中次数 0.2 * 信息不一致命中次数 0.2 * 碎片联络命中次数 0.1 * 资源导向命中次数这是示例权重实际要根据自己场景调整。阈值也可以分三档0 到 0.3 属于正常波动0.3 到 0.6 属于需要观察0.6 以上触发预警。阈值一开始不要定得太灵敏先跑一周看正常情况下的基线分数再往回调。7.2 白名单和降级机制AI 会形成刻板印象。某个维度出现过几次风险后后面即使对方已经改变模型也可能因为历史记录影响继续贴标签。所以 Agent 里要设计白名单机制。连续 30 天没有新增命中或者已经在现实中见过面、相处正常就可以把该联系人的风险权重整体降级。白名单不是永久身份只影响当前分析展示不会删掉历史数据。7.3 最小 Agent 结构一个能稳定运行的 Agent不一定需要复杂框架。最小结构可以拆成这样定时触发器每天固定时间执行一次增量任务。增量读取只读取上次分析后新增的聊天记录。清洗与分块过滤系统消息按天或话题切块。调用模型分析把每个对话块送给大模型拿回结构化 JSON。结果落库写入本地数据库或 JSON 文件方便回溯。计算风险指数按配置好的权重生成当日分数。预警通知分数超过阈值时发提醒到自己的个人通知渠道。这里面最容易被忽略的是失败重试和幂等。模型接口偶发超时很正常任务要能自动重试并且同一段数据不要因为重跑而重复计入统计。最简单的方式是每次分析时给对话块生成一个datestamp hash作为唯一 ID落库前先查重已经分析过的直接跳过。注意Agent 越自动越要留日志。哪天误判了能回看是哪一天、哪一个对话块、哪条提示词造成了偏差。没有日志的自动化早晚会在关系这件事上给你一个既说不清又难修正的错误判断。最后一轮踩坑经验是不要一上来追求完整 Agent。先把 20 条聊天记录手动跑通确认 CSV 清洗、模型提示词、JSON 解析、evidence 校验这四个环节都稳定再逐步增量化和定时化。相亲筛选这件事慢一点反而更可靠。AI 给出的每条风险线索都当成“需要当面或通过更多证据去核实的问题”而不是“可以直接拉黑的判决书”。这样用工具才是帮忙而不是帮倒忙。