Tldr This

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

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

何时触发

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

工作流

1. 识别输入类型

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

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

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 字
• 整体产出应远短于原文;不是"换个说法把全文重复一遍"

输出模板

代码文件

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

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

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

PR / diff

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

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

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

长文档 / 文章 / 粘贴文本

**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 字)也能处理,但会说明"原文已较短,直接给出要点"。