# Tldr This

> 把超长的文件 / PR / 文档 / 粘贴文本压成中文 TL;DR + 关键点。当用户说「帮我总结这个/太长了 tldr/简单说一下这个/tldr-this」时触发。

- Skill: `yuaicode/tldr-this` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add yuaicode/tldr-this`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yuaicode/tldr-this/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: YuAICode (https://skillmd.com/u/yuaicode)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/yuaicode/tldr-this

---


# tldr-this — 超长内容中文 TL;DR 压缩

把任意长内容压成"一句话 TL;DR + 3-7 条关键点 + 按类型补充分析",
不用再盯着几千行慢慢读,直接抓主干、看要害。

## 何时触发

- 用户说"帮我总结这个"、"太长了 tldr"、"简单说一下这个"
- 用户输入 `/tldr-this`
- 用户说"这个 PR 改了什么"、"这篇文章说了什么"、"给我看看这个文档的重点"
- 用户粘贴了大段文本/代码/diff,问"能不能简短说明"

## 工作流

### 1. 识别输入类型

根据内容特征判断属于哪类,允许混合(如"PR 描述 + diff"):

| 类型标识 | 判断特征 |
| --- | --- |
| **代码文件** | 含函数/类定义、import 语句、缩进代码块、文件路径 |
| **PR / diff** | `diff --git`、`+++ b/`、`--- a/`、GitHub PR URL、`@@ -N,N @@` |
| **长文档 / 文章** | 有章节标题、段落行文、prose 风格的正文 |
| **粘贴文本** | 邮件、会议纪要、聊天记录、设计方案等无固定格式文本 |
| **URL** | 用户给了一个链接 → 先尝试读取页面内容,再按上面类型处理 |

若无法确定类型,按"粘贴文本"兜底处理,不追问。

### 2. 产出固定结构

#### 所有类型都输出

1. **一句话 TL;DR**:浓缩为一句话,体现核心主旨或结论;不超过 50 字。
2. **关键点**:3-7 条 bullet,每条独立成立,优先级高的在前。
   - 保留关键数字、百分比、时间节点、版本号、API 名称等
   - 不堆细节,每条 bullet 只说一件事

#### 按类型补充分析

- **代码文件**:
  - 它做什么(用一句话描述模块/文件的职责)
  - 主要入口(关键函数/类/exported symbol)
  - 注意点(副作用、并发风险、依赖约束、TODO/FIXME 等)

- **PR / diff**:
  - 改了什么(逻辑变更,不是文件列表)
  - 影响面(哪些模块/接口/数据库/API 受影响)
  - 风险(破坏性变更、兼容性、测试覆盖、需要关注的边界情况)

- **长文档 / 文章 / 粘贴文本**:
  - 核心结论(文档得出的判断或建议)
  - 待办(文中明确提出的 action item、决策点或 open question)

### 3. 控制长度

- TL;DR 不超过 50 字
- 关键点每条不超过 40 字
- 补充分析每项不超过 3 条,每条不超过 40 字
- **整体产出应远短于原文**;不是"换个说法把全文重复一遍"

## 输出模板

### 代码文件

```markdown
**TL;DR**
<一句话,不超过 50 字>

**关键点**
- <点 1>
- <点 2>
- ...（3-7 条）

**代码分析**
- 职责：<这个文件/模块做什么>
- 主要入口：`<FunctionName>` / `<ClassName>` — <一句话说明>
- 注意点：<副作用 / 并发风险 / TODO 等;无则省略>
```

### PR / diff

```markdown
**TL;DR**
<一句话,不超过 50 字>

**关键点**
- <点 1>
- <点 2>
- ...（3-7 条）

**PR 分析**
- 改了什么：<逻辑变更描述>
- 影响面：<受影响的模块/接口/服务>
- 风险：<破坏性变更 / 兼容性 / 测试盲区;无明显风险则说"暂未发现">
```

### 长文档 / 文章 / 粘贴文本

```markdown
**TL;DR**
<一句话,不超过 50 字>

**关键点**
- <点 1>
- <点 2>
- ...（3-7 条）

**文档分析**
- 核心结论：<文档的主要判断或建议>
- 待办 / 开放问题：<action item 或未拍板的事项;无则省略>
```

## 硬规则

1. **忠于原文,不臆造**:关键点和 TL;DR 必须有原文依据,不编造原文没说的结论。
2. **不夸大**:原文说"可能提升性能"不能写成"大幅提升性能"。
3. **读不到的部分如实说明**:若内容被截断、含二进制、URL 无法访问,在对应位置标注 "（内容不可读/截断,仅基于可见部分分析）",不臆造。
4. **保留关键标识**:数字、百分比、版本号、API 名、函数名、专有名词必须原样保留;代码标识符用反引号包裹。
5. **产出中文**:prose 部分用中文;代码标识符、英文专有名词(如 `WebSocket`、`JWT`、`Kubernetes`)保留英文。
6. **可指出矛盾或可疑处**:若原文自相矛盾、数字前后不一致、逻辑跳跃明显,在关键点或补充分析里用"⚠️ 原文存在..."的形式标出;不替原文"修复"矛盾。
7. **不做任何写操作**:只读内容、只产出分析;不修改文件、不执行命令、不推送代码。
8. **URL 处理**:若用户给的是 URL,先尝试用 WebFetch 读取页面内容;若读取失败,告知用户"URL 无法访问,请直接粘贴内容"。

## 边界

- 适用所有文本格式;二进制文件、加密内容无法解读,如实说明。
- 不替代 code review(只给 TL;DR,不逐行审查 bug)——深度审查请用 `/code-review`。
- 不替代需求分析——将讨论转成 spec 请用 `slack-to-spec`。
- 极短内容(< 200 字)也能处理,但会说明"原文已较短,直接给出要点"。