---
name: lls-dialogue-subtext-reader
license: CC-BY-NC-SA-4.0
description: 分析聊天、会议、反馈或协商中的言外之意、关系信号和未明说诉求。用于用户问“他这句话什么意思”“这段对话哪里不对”“我该怎么回”时；必须区分原话事实、合理推测和未知信息，给出多种解释与低冲突回应，不把推测写成心理诊断或确定事实。
metadata:
  short-description: 分清原话、潜台词与不确定性，再给出稳妥回应
---

<!-- workbuddy-install: published; slug: lls-dialogue-subtext-reader -->
## 在 WorkBuddy 中找到并安装

**Skill slug：`lls-dialogue-subtext-reader`**

在 WorkBuddy 新会话粘贴：

```text
请按 https://skillhub.cn/install/skillhub.md 检查 SkillHub，搜索 `lls-dialogue-subtext-reader`；仅在 slug 完全一致时安装到 `~/.workbuddy/skills/`。安装后读取 `~/.workbuddy/skills/lls-dialogue-subtext-reader/SKILL.md`，核对 name、version 和实际路径，然后新开会话触发该 Skill。
```

也可以打开左侧「技能」→「添加技能 / 查找技能」，搜索 `lls-dialogue-subtext-reader` 后安装；界面文字可能随 WorkBuddy 版本变化。

# 罗老师对话潜台词解读

## 核心目标

帮助用户读懂一段对话，但不替用户“读心”。

最终结果必须同时做到：

1. 看见原话中的客观信号；
2. 给出一到三种可能解释；
3. 标明每种解释的证据和不确定性；
4. 提供能降低误会、保护关系和推进事情的回应。

## 什么时候使用

- 用户贴出聊天记录，询问对方真实意思。
- 用户感觉被敷衍、冒犯、控制或冷落，但说不清原因。
- 用户需要回复领导、同事、客户、伴侣、朋友或家人。
- 用户需要复盘一次谈判、会议、冲突或拒绝。
- 用户想判断一句话更接近提醒、试探、拒绝、催促还是情绪表达。

## 什么时候不使用

- 用户只需要逐字翻译或语法解释。
- 对话涉及即时人身危险，应先帮助用户联系可信任的人或当地紧急支持。
- 用户要求根据几句话给对方下人格障碍、精神疾病或犯罪倾向结论。
- 用户希望利用弱点操控、羞辱、威胁或诱骗对方。

## 开始前需要什么

优先收集以下信息，缺少时也可以先做低置信度分析：

1. 对话原文，尽量保留前后文；
2. 双方关系与角色；
3. 这段对话发生前的事件；
4. 用户真正想解决的问题；
5. 用户希望保持的边界和语气。

不要索取真实姓名、手机号、公司内部账号等无关信息。建议用户把姓名替换为 `A`、`B`。

## 四层解读法

### 第一层：只写看得见的事实

先提取：

- 对方具体用了哪些词；
- 是否回答了用户的问题；
- 是否出现转移话题、模糊时间、附加条件、反问或重复；
- 回复长度、时间和标点是否与平常显著不同；
- 哪些信息在原文中完全没有出现。

这一层禁止出现“他就是”“她一定”“显然想”等确定性判断。

### 第二层：识别互动功能

判断这句话在对话中可能承担什么作用：

- 提供信息；
- 请求行动；
- 表达情绪；
- 维护面子；
- 建立边界；
- 延迟决定；
- 试探态度；
- 委婉拒绝；
- 转移责任；
- 邀请进一步沟通。

同一句话可以同时承担两种功能。

### 第三层：提出竞争性解释

至少给出两种解释，除非证据非常明确。

每种解释使用下面格式：

```text
可能解释：
支持证据：
反向证据：
置信度：低 / 中 / 高
还缺什么信息：
```

优先排列最普通、最不伤害关系的解释，再列风险解释。

### 第四层：设计回应

回应要根据用户目标选择：

| 用户目标 | 推荐策略 |
|---|---|
| 想确认意思 | 复述观察 + 开放式确认 |
| 想推进任务 | 明确事项 + 时间 + 可选方案 |
| 想表达不舒服 | 描述影响 + 提出边界 |
| 想拒绝 | 简短结论 + 必要理由 + 可选替代 |
| 想降温 | 暂停争论 + 确认共同目标 |
| 想保留证据 | 使用事实、时间和书面确认 |

## 标准工作流程

### 步骤一：确定用户要解决什么

先用一句话确认：

```text
你现在更想确认对方的意思，还是想写一条合适的回复？
```

如果用户已经说清楚目标，直接进入分析。

### 步骤二：制作“事实—推测”分栏

输出两栏：

```text
原文事实：
- …

目前只是推测：
- …
```

任何没有原句支撑的判断都放在“推测”栏。

### 步骤三：识别关键转折

标出最多三个关键片段，说明：

- 这句话回应了什么；
- 它回避了什么；
- 它可能改变了双方哪项预期。

### 步骤四：生成多种解释

默认给出：

1. 善意或中性解释；
2. 边界或利益解释；
3. 需要警惕的解释。

风险解释必须有具体语言证据，不能只凭直觉。

### 步骤五：选择最小验证动作

优先设计一句能够验证假设的问题，而不是继续猜。

例如：

```text
“我理解你是希望周三之前先看到初稿，而不是周三直接定稿，对吗？”
```

### 步骤六：给出三档回复

通常提供：

- 温和版；
- 直接版；
- 有边界版。

每版控制在用户可直接复制的长度，并解释适用场景。

## 输出格式

```markdown
## 一句话判断

## 原话中能确认的信号
- …

## 可能的三种解释
### 解释一
- 证据：
- 反证：
- 置信度：

## 最值得确认的问题

## 可直接发送的回复
### 温和版
### 直接版
### 有边界版

## 风险提醒
```

详细模板见 [references/analysis-template.md](references/analysis-template.md)。

## 质量门禁

提交答案前逐项检查：

- [ ] 原文事实与推测已经分开；
- [ ] 至少提供两种竞争性解释；
- [ ] 没有把语气、回复速度或表情单独当成定论；
- [ ] 没有给对方贴疾病、人格或道德标签；
- [ ] 回复符合用户的关系、目标和边界；
- [ ] 提供了一个可以验证假设的具体问题；
- [ ] 引用对话时已经提醒用户隐藏敏感信息。

## 失败处理

- 前后文太少：只给低置信度分析，并说明需要哪一句前文。
- 双方版本冲突：并列呈现，不替任何一方裁决事实。
- 用户情绪很强：先复述感受，再分析语言，不用“你想多了”。
- 出现持续威胁或骚扰：建议保存记录、减少单独接触并寻求可信支持。

## 隐私边界

- 只分析用户主动提供的文字。
- 不要求上传整部手机聊天记录。
- 不保存真实姓名、联系方式、住址、账号或公司秘密。
- 对涉及儿童、医疗、法律或职场处分的对话，明确说明分析只是沟通辅助。

## 使用入口

- [飞书中文教程](https://m2wlgni9k4.feishu.cn/wiki/UXSKwHcCliUPkvkNbn4cNEysnRc)
- [SkillHub 安装页](https://skillhub.cn/skills/lls-dialogue-subtext-reader)
- [GitHub 源码](https://github.com/PhilRobinluo/ai-coevolution-skills/tree/main/skills/lls-dialogue-subtext-reader)
- [GitHub 1.1.1 安装包](https://github.com/PhilRobinluo/ai-coevolution-skills/releases/download/lls-dialogue-subtext-reader-v1.2.0/lls-dialogue-subtext-reader-1.2.0.zip)

如果这个 Skill 帮你节省了时间，欢迎给总仓库点一个 Star；需要版本提醒时，请在 GitHub 订阅 Releases。