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

一个多月前，我把 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 分成了四个在逻辑上严格区分的层次：

这样拆分的好处是，我不会在一个环节里把所有事情混在一起。很多失败的情感聊天机器人就是因为在“生成回应”这个环节堆了过多要求，结果既要分析、又要安抚、还要讲道理，最后出来一段又长又油腻的废话。分层以后，每层只干一件事，输出自然就克制了。

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: gentle

triggers是触发词，但也只是“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 回调地址，合规省事；另一种是用自己的消息转发小程序，把复制或分享的微信文本转发到本地接口。我为了日常体验，用的是第一种，把公众号后台配好 token，QClaw 侧开一个/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 高频问题排查速查表

5.2 边界原则：只做理解，不做操控

我给这个 Skill 定的边界非常清楚：它只帮助理解，不提供“如何拿捏别人”的建议。如果检测到请求中涉及贬低对方、制造焦虑、诱导对方妥协、冷暴力等倾向，Skill 会直接拒绝。这条规则不是表面工程，我在入口逻辑里做了一个敏感语义评分，分数超标就立刻拦截。

之所以这样设计，是因为我知道，所谓的“恋爱大师”一旦越界，产出的话术就会变成一种操控工具。这对使用者本身也没有好处，长期依赖操控技巧，最后会失去真实沟通的能力。一个合格的辅助技能，应该让用户更有能力表达自己的真实需求和愿望，而不是教他怎么把话说得像钩子。

5.3 复盘：真正有用的不是“答案”，而是“助你停下来想一想”

跑了一个多月，有几次我故意不听 Skill 的建议，按自己原来的方式回复，结果回头印证后，发现还是它的判断更接近对方的处境。但这不意味着我事事都听它的。它最大的作用，其实是每次输出里那句“如果我是对方，我更需要的可能是被接住，而不是被分析”。

这句话让我养成了一个习惯：回复之前，先区分对方是在“求助”还是在“索取关注”。“恋爱大师”看似是在教我怎么说，实际上是在帮我学会怎么听。而“听”这件事，恰恰是很多聊天内耗的解药。

6. 给也得写 Skill 的朋友一点实在建议

如果你也想做类似方向的私人技能，我给你三个建议。

第一个建议：先做分析，再做生成。所有落地场景里，最值得投入时间的地方是“意图识别”和“状态判断”，而不是华丽的回复模板。分析足够准确，哪怕回复只有一句“先别提建议，陪 TA 坐一会儿”，都远比一长串话术管用。

第二个建议：把“选择性采纳”设计成技能的一部分。不要追求让用户完全相信输出结果。我的做法是在每次分析后面都加一句“如果不确定，直接向对方确认”，这句话看着普通，却能大幅降低误判带来的副作用。

第三个建议：注意敏感边界和记忆安全。这类跟聊天数据相关的技能，最好把所有内容都留在本地处理，尽量不要上传到公共的第三方消息队列。QClaw 支持本地化记忆存储，我用得放心，至少微信数据不会因为我的好奇心而绕一大圈传到不相关的地方。

最后一件事，这个 Skill 我会继续维护下去，但现在它的名字已经不再重要。真正让一个技能变得“大师”的，不是话术有多华丽，而是它能不能在你最容易冲动的那个瞬间，帮你多留两秒，多看一眼上下文。能让你在微信聊天里更稳一点的东西，才值得一直用下去。