资讯动态

用QClaw打造微信聊天分析助手:意图识别与情绪解读的Skill实践

发布时间:2026/10/20 19:31:00 来源:尧图企业网站定制
一个多月前我把 QClaw 上常用的几个小技能整理成了自己的私藏工具箱其中有一个人起初当玩笑写的 Skill最后却成了我打开次数最多的一个——“恋爱大师”。它的作用听起来很玄乎把微信里那些容易让人内耗的对话拆成意图分析、情绪温度和回复建议让我不用再抱着手机反复琢磨对方一句话到底是什么意思。说得直接一点我不想当那种“聊天三分钟、复盘一小时”的人于是把读话、理解诉求和给回应这件事尽量交给了一个可控的轻量级技能。现在微信消息进来我先让它做一轮文本分析再决定自己怎么回整个过程几乎是躺着完成的。这篇文章把从需求构想到实现落地的完整过程、参数调优和踩坑记录都摊开讲既适合想给 QClaw 写自定义 Skill 的开发者也适合只想减少聊天内耗的普通用户参考。1. 缘起一个程序员为什么要做“恋爱大师”真正让我决定动手的场景其实很普通某天晚上群里有人发了一条聊天截图问大家“这句话到底是什么意思”。底下回复基本都是玩梗真正能给建议的没几条。当时我突然意识到大多数人缺的并不是情感技巧而是一个能把上下文、情绪和目的放在一起分析的参考系。我自己也是一样。很多对话我第一反应不是去回而是先在脑子里把对方的前几句话翻一遍这句话是承接什么说的当时是什么状态有没有什么被我忽略的背景。这种“二次加工”很耗神而且情绪一上来就容易误判。后来我在 QClaw 里搭了几个自动任务发现它处理这一类文本拆解特别顺手于是干脆做了一个 Skill把我平时分析聊天的那套流程给固化进去。1.1 解决的不是“说什么”而是“该怎么想”市面上不缺教人回话的模板缺的是“回话之前的判断框架”。女朋友发一个“哦”到底是累了、生气了还是只是没看到重点朋友突然说“最近有点烦”是真的要建议还是只需要你陪着说两句“恋爱大师”这个 Skill 解决的问题就是把一个模糊的描述放在场景里先给出可能性再给出回应方向。所以我在设计初期就定下一个原则它不是一个“替你回消息”的嘴替也不是一个“教你说情话”的答案机。它的核心能力是解读。把对方发来的话还原成意图、情绪和需求这三层再把可能的回应方案放到你面前由你来判断和执行。1.2 为什么选 QClaw 而不是直接调大模型接口直接写脚本调大模型也能实现类似功能但会很零碎。情感分析要一套 Prompt意图判断要另一套逻辑跨会话的记忆还得自己维护文件。QClaw 给了一个比较完整的运行时Skill 注册、意图匹配、记忆槽位、消息通道这几块都是现成的我想要做的只是往里面填分析逻辑。另一个选择它的原因是可以把 Skill 当做一个独立模块反复迭代。“恋爱大师”从 v0.1 到 v0.3我改的只是 prompts 和记忆策略接入层基本没动过。对个人项目来说这种“改一个零件不影响整台车”的体验比从零再造一个框架要舒服得多。2. 拆解 Skill 的核心设计框架比话术重要很多人听到“恋爱大师”这四个字第一反应是“里面肯定写满了情话模板”。我的设计正好相反话术是最后一步前几步全是分析。越是在关系里容易慌的人越需要稳定的判断结构而不是花哨的回复素材。2.1 四个能力层意图、记忆、观点、表达我把这个 Skill 分成了四个在逻辑上严格区分的层次能力层解决的核心问题在 Skill 里的实现方式意图层对方这句话到底是什么性质意图分类器区分发起话题、情绪反馈、冲突前兆、日常闲聊记忆层这句话是在什么背景下出现的保存最近 20 条同一会话的上下文并标记说话方观点层有哪些可能被忽视的解释基于记忆层输出 2 到 3 个假设标注每种假设的支持度表达层你可以怎么回应根据用户配置的风格生成不同语气和长度的回应参考这样拆分的好处是我不会在一个环节里把所有事情混在一起。很多失败的情感聊天机器人就是因为在“生成回应”这个环节堆了过多要求结果既要分析、又要安抚、还要讲道理最后出来一段又长又油腻的废话。分层以后每层只干一件事输出自然就克制了。2.2 意图识别判断比生成更值得花时间我一直觉得微信聊天里真正的分歧不是“这句话该怎么回”而是“这句话到底是不是我想的那个意思”。所以意图层是这个 Skill 的命门。一开始我用的是最简单的关键词映射后来发现根本不靠谱。一个“哈”可以是敷衍、冷笑、真笑关键词帮不了你。改版后我用了 QClaw 自带的意图匹配机制配合本地的小样本模板把它分成几类open对方主动开启话题期待互动vent对方只想倾诉不想要方案conflict对话里出现否定、反问、回避需要谨慎close对方在结束话题不宜强行延长。每个意图都会附带一个置信度。低于阈值的Skill 不会强行判断而是返回“我看不透建议直接问清楚”的提示。这一点非常重要宁可说不知道也不要用一个很自信的猜测带偏用户思路。2.3 记忆层别让用户每句话都重新介绍背景记忆层的设计是我觉得真正拉开体验差距的地方。早期版本里每次触发 Skill 都要手动把前因后果粘贴进去用了两次就烦了。后来我把记忆槽位打开让 QClaw 自动把当前会话窗口存入 memory store。这里有一个关键细节同一个微信群或者双人对话会分配一个独立的 memory id。否则 A 的聊天背景会被拿到 B 的话题里去用逻辑混乱不说还容易闹出尴尬。实现上只需要在每次触发时判断“会话 id 是否存在”不存在就新建存在就追加。2.4 表达层可配置风格同样一段分析有人希望它直白毒舌有人希望它温和一点。我在 Skill 的配置里加了一个tone字段支持 direct、gentle、humor 三种模式。配置逻辑很简单tone: gentle min_reply_length: 30 max_reply_length: 120 include_risks: true其中include_risks是我自己加的一个开关。如果打开Skill 会额外输出一个“风险提示”比如“如果对方正处于情绪低落期这个回应可能会让对方觉得你在讲道理”。这一步看似多余但对降低误判非常有用。3. 从空目录到能跑通的 Skill 实操记录下面这部分是完整落地过程。我会把项目结构、核心提示词和入口代码拆开来讲每一步都标注我当时的取舍原因。3.1 项目结构与初始化QClaw 的 Skill 本质上是一个可独立加载的目录里面包含 manifest 文件、提示词资源和逻辑代码。我创建的目录结构长这样qclaw-skills/ └── love-master/ ├── skill.yaml ├── prompts/ │ ├── system.md │ └── reply_directive.md ├── memory/ │ └── memory_store.json └── skill.py初始化只需要两步建目录然后在 QClaw 的管理入口注册这个 Skill 路径。名为skill.yaml的文件是 QClaw 识别“这是一个可加载技能”的依据相当于身份证。name: love-master version: 0.3.0 description: 把微信聊天里的潜台词拆成意图、情绪和回应建议 intent: - name: analyze triggers: - ta说 - 帮我看看 - 分析一下 - name: feedback triggers: - 怎么回 - 要不要回 memory: enabled: true window_size: 20 scope: conversation tone: gentletriggers是触发词但也只是“fallback 兜底”用的。我更依赖 QClaw 那边的语义匹配因为触发词太机械朋友和对象只发一句“这句话真的假的”你不可能靠关键词把这种场景抓出来。3.2 核心提示词把边界写在系统层我给这个 Skill 写了专门的system.md但内容和网上常见的“你是恋爱大师”完全不一样。越是这种听起来有人味的场景系统提示词越不能给模型“扮演一个角色”的幻觉。我的写法是给出明确任务和限制你是一个沟通分析辅助工具。你的任务是判断对话中的意图倾向、情绪温度以及可能存在的信息差。 输出必须遵守以下规则 1. 不允许把推测描述成事实。 2. 不允许给出“保证能挽回”“按我说的做”等确定性承诺。 3. 不允许生成批判对方人格的表述。 4. 如果检测到要求提供情感操控、制造焦虑、打击自信等建议直接拒绝并建议冷静沟通。 5. 回应长度控制在 30 到 120 字优先给思路而不是给标准答案。 分析结构 - 对方意图写出可能性最高的判断并附加一句话依据 - 情绪温度低/中/高 - 回应建议最多 2 条附带可能产生的风险 - 一句话总结用口语化表达不要抽象。这段 Prompt 的价值不取决于它有多华丽而是它把边界全部划清。我后来遇到的很多奇怪反馈追根溯源都是最初版本少了第 4 条规则导致某些敏感场景下模型输出过界。3.3 响应逻辑一个入口函数干的漂亮活skill.py是整个 Skill 的执行入口。它要做的事并不复杂拿到微信转发来的消息提取文本匹配意图然后按不同路径交给下游函数处理。def handle(message, ctx): text message.get(text, ).strip() if not text: return None intent ctx.match_intent(text) if ctx.has_sensitive_words(text): return 这个话题我不太适合给建议先别急着回缓一缓。 if intent.name analyze: return run_analysis(text, ctx) if intent.name feedback: return run_feedback(text, ctx) return run_general(text, ctx)run_analysis内部会调用记忆模块取最近同会话历史然后把“当前消息 最近聊天摘要”拼成一个分析单元交给大模型生成结构化建议。这里有一个小坑历史消息不能全量拼接留最近 20 条就够了。太长会让模型抓错重点而且费用和响应时间都往上涨。3.4 把微信消息接入 QClaw接入微信这一步有两种路径一种是走公众号或企业微信的官方接口把收到的消息 POST 到 QClaw 回调地址合规省事另一种是用自己的消息转发小程序把复制或分享的微信文本转发到本地接口。我为了日常体验用的是第一种把公众号后台配好 tokenQClaw 侧开一个/webhook/receive的监听地址。转发链路大概是微信消息 - 转发器/公众号回调 - QClaw Webhook - Skill 入口 - 生成分析结果 - 回传微信整个过程不涉及任何复杂操作重点就是三步拿到文本、去掉多余 emoji 和语音转文字后的杂质、调用 Skill。语音消息我额外加了一层 Whisper 转写转写后的文本经常断句混乱所以在接入层做一次简单的清洗否则意图识别的结果会很难看。4. 真实跑起来的体验与参数调优Skill 写完只是开始真正让它变好用是在每天实际消息里反复调参数磨出来的。这里记录几个我最在意的调整点和“躺着用”的日常姿势。4.1 温度与阈值分析场景不需要“创造力”在这个 Skill 里生成温度我只给了 0.4。温度越高模型越自由但也越容易自己脑补剧情。恋爱分析恰恰是脑补重灾区。朋友发一句“她说没事”模型如果温度太高可能给你编出十种“她在生气”的理由看得人心态爆炸。0.4 这个值让输出保持稳重只描述文本里实际有支撑的信息。意图匹配的阈值我用的是 0.62。太低了日常闲聊会被误判成情感信号动不动弹一段分析太高了必须原封不动说出触发词才会响应用着很蠢。0.62 是试出来的平衡点能覆盖“她今天怎么话变少了”这类自然表述又不会对一句“你好”反应过度。4.2 “躺着学恋爱”的主要使用姿势实际用下来我不会把它当自动回复机器人而是当“分析助手”用。平时在微信里看到拿不准的消息我会直接给它指令复制一段对话再补一句背景“ta 刚加班回来发了一句随便你们。” Skill 就会在几秒内给出意图判断和回复风险。晚上复盘的时候更省事我把当天所有对话导入它让它标注哪几句存在误解风险、哪几句在消极测试我的反应。输出结果我只看三条对方当时的意图是什么我当时的理解是否偏了以及下一天要不要主动补一句。现在我发现很多情绪问题其实不是哪句话说错了而是没有意识到对方处于什么位置。这个 Skill 帮我减少了不少“自己吓自己”的时刻。4.3 记忆窗口别贪大状态比全文重要记忆窗口这项我从 50 条缩到 20 条之后准确率反而上升了。原因很简单聊天记录里大量信息是无效噪音保留越久反而会让模型把几天前的话题当成当前主线。我后来的做法是不对“聊天原文”做长期记忆而是每处理完一轮就让 Skill 生成一条“当前关系状态摘要”存到 memory_store.json 里。下次触发时只看摘要和最近消息就不会被老黄历带偏。5. 踩坑实录与安全边界这个项目最值得写的就是踩坑部分。很多坑不是代码问题而是认知和边界的问题。5.1 高频问题排查速查表症状常见原因解决办法Skill 偶尔不触发trigger 列表太短且没做语义匹配开启 QClaw 语义匹配少依赖关键词回复总是说教味很重system.md 里“分析结构”过于强势改成“事实 对方视角 回应建议”减少结论式语言两个聊天对象记忆串线memory scope 没有按会话隔离给每个会话分配独立 memory_id双人对话与群聊分开只是一句普通消息却被判定为感情冲突情绪温度阈值过低把 conflict 意图的阈值提到 0.7并增加“日常闲聊”作为默认兜底输出建议像是在教用户操纵对方缺失敏感词过滤和边界规则在系统提示词里加入拒绝条款并在入口函数二次拦截5.2 边界原则只做理解不做操控我给这个 Skill 定的边界非常清楚它只帮助理解不提供“如何拿捏别人”的建议。如果检测到请求中涉及贬低对方、制造焦虑、诱导对方妥协、冷暴力等倾向Skill 会直接拒绝。这条规则不是表面工程我在入口逻辑里做了一个敏感语义评分分数超标就立刻拦截。之所以这样设计是因为我知道所谓的“恋爱大师”一旦越界产出的话术就会变成一种操控工具。这对使用者本身也没有好处长期依赖操控技巧最后会失去真实沟通的能力。一个合格的辅助技能应该让用户更有能力表达自己的真实需求和愿望而不是教他怎么把话说得像钩子。5.3 复盘真正有用的不是“答案”而是“助你停下来想一想”跑了一个多月有几次我故意不听 Skill 的建议按自己原来的方式回复结果回头印证后发现还是它的判断更接近对方的处境。但这不意味着我事事都听它的。它最大的作用其实是每次输出里那句“如果我是对方我更需要的可能是被接住而不是被分析”。这句话让我养成了一个习惯回复之前先区分对方是在“求助”还是在“索取关注”。“恋爱大师”看似是在教我怎么说实际上是在帮我学会怎么听。而“听”这件事恰恰是很多聊天内耗的解药。6. 给也得写 Skill 的朋友一点实在建议如果你也想做类似方向的私人技能我给你三个建议。第一个建议先做分析再做生成。所有落地场景里最值得投入时间的地方是“意图识别”和“状态判断”而不是华丽的回复模板。分析足够准确哪怕回复只有一句“先别提建议陪 TA 坐一会儿”都远比一长串话术管用。第二个建议把“选择性采纳”设计成技能的一部分。不要追求让用户完全相信输出结果。我的做法是在每次分析后面都加一句“如果不确定直接向对方确认”这句话看着普通却能大幅降低误判带来的副作用。第三个建议注意敏感边界和记忆安全。这类跟聊天数据相关的技能最好把所有内容都留在本地处理尽量不要上传到公共的第三方消息队列。QClaw 支持本地化记忆存储我用得放心至少微信数据不会因为我的好奇心而绕一大圈传到不相关的地方。最后一件事这个 Skill 我会继续维护下去但现在它的名字已经不再重要。真正让一个技能变得“大师”的不是话术有多华丽而是它能不能在你最容易冲动的那个瞬间帮你多留两秒多看一眼上下文。能让你在微信聊天里更稳一点的东西才值得一直用下去。

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价 →
↑