摘要

技能文档

---
name: summarization
title: 摘要
category: 办公效率
description: 将文档、文章、对话、代码、技术内容等提炼为简洁准确的摘要。当用户请求「总结」「摘要」「提炼要点」「TL;DR」「概括」「精简」「帮我归纳」「提取关键信息」「写执行摘要」「会议纪要总结」「论文摘要」「更新日志摘要」时触发。不适用于改写、翻译或从零生成内容。
---

# 摘要

将内容提炼为简洁准确的摘要，帮助读者快速获取关键信息并做出决策。

## 技能工作流

### 步骤1：分析上下文

在开始摘要之前，明确以下信息：

1. **内容类型**：商业文档、技术规范、对话记录、研究论文、代码？
2. **目标读者**：管理层、工程师、普通读者？
3. **摘要目的**：辅助决策、了解进展、留档参考、分享传播？
4. **篇幅要求**：未指定时根据内容复杂度调整，而非简单按原文长度等比缩减

### 步骤2：选择摘要方法

根据内容类型选择对应的摘要结构。

#### 执行摘要

适用于商业文档、报告、提案和战略方案。

**结构：**
1. **核心结论**：以关键决策、建议或结论开头
2. **关键指标**：列出 2-4 个最重要的数据（收入、时间线、成本、影响）
3. **主要发现**：3-5 个要点，涵盖核心发现或决策
4. **风险与不确定性**：可能出问题的地方
5. **下一步行动**：谁在什么时间前完成什么

**示例格式：**
```
**建议：** [一句话核心决策]

**关键指标：** [2-4 个数据点]

**发现：**
- [最重要的发现]
- [第二重要]
- [第三]

**风险：** [1-2 个关键风险]

**下一步：** [带负责人和截止日期的行动项]
```

**要点：**
- 使用商业语言，避免技术术语
- 每句话都应帮助读者做出决策
- 如果无法用一句话表述核心结论，说明源材料本身不够清晰——应标注这一点
- 使用具体数字，不用模糊表述（写「收入增长 23%」而非「收入显著增长」）

#### 技术摘要

适用于技术文档、架构设计、RFC、代码评审和技术文档。

**结构：**
1. **目的**：解决什么问题？为什么存在？
2. **方案**：高层级如何工作？
3. **关键决策**：做了哪些技术选择及原因
4. **依赖关系**：依赖什么？被什么依赖？
5. **权衡取舍**：获得了什么，牺牲了什么
6. **局限性**：已知问题、约束或空白
7. **待定事项**：未解决的决策或需进一步工作的领域

**要点：**
- 保持技术精确性——不简化有特定含义的术语
- 包含架构决策及其理由
- 注明 API 契约、数据格式和集成点
- 如源材料讨论了性能特征，应提及
- 标注破坏性变更或迁移需求

#### 研究/学术摘要

适用于研究论文、研究报告、白皮书和分析报告。

**结构：**
1. **研究问题**：调查了什么？
2. **方法论**：如何开展研究？（简要）
3. **主要发现**：3-5 个最重要的结果
4. **意义**：这些发现为什么重要？
5. **局限性**：研究未覆盖或无法证明的内容
6. **启示**：基于这些发现应采取什么行动？

**要点：**
- 区分相关关系与因果关系
- 包含样本量和置信度（如有）
- 注明统计显著性与实际显著性的区别
- 保持细微差别——不过度解读发现
- 标注方法论的显著局限性

#### 对话/会议摘要

适用于会议纪要、聊天记录、邮件往来和讨论。

**结构：**
1. **已做决策**：达成了什么共识（要具体）
2. **行动项**：谁在什么时间前完成什么
3. **关键讨论点**：主要讨论的话题
4. **分歧**：意见不一致的地方及解决方式
5. **待定事项**：仍需决策的内容
6. **暂搁议题**：已提出但推迟讨论的话题

**要点：**
- 将决策和行动项归属到具体人员
- 记录决策的「为什么」，不只是「是什么」
- 注明是达成共识还是强制决策
- 包含截止日期和承诺
- 标注任何未解决或有争议的事项

#### 代码/更新日志摘要

适用于代码差异、PR、发布说明和更新日志。

**结构：**
1. **变更内容**：变更的高层级描述
2. **变更原因**：动机（修复缺陷、新增功能、重构、性能优化）
3. **影响范围**：用户/开发者会注意到什么
4. **破坏性变更**：需要迁移或适配的内容
5. **值得注意的细节**：有趣的实现选择或注意事项

**要点：**
- 以用户影响为先，而非实现细节
- 将相关变更归组
- 区分缺陷修复、功能新增和内部变更
- 突出显示破坏性变更
- 注明是否新增或更新了测试

### 步骤3：遵循核心原则

无论使用哪种方法，以下原则始终适用：

**准确性至上**
- 绝不引入源材料中不存在的信息
- 源材料模糊时应标注，不猜测
- 使用与源材料相同的术语（不用近义词替换导致含义偏移）
- 引用时精确原文；转述时保持原意

**结构很重要**
- 使用项目符号、编号列表和标题便于扫读
- 最重要的信息放在最前面（倒金字塔结构）
- 将相关要点归组
- 全文格式保持一致

**匹配摘要篇幅**
- 2 页备忘录和 200 页报告不应得到同等对待
- 根据内容复杂度调整，而非仅按长度等比缩减
- 50 页的简单主题可能只需 3 个要点
- 5 页的密集技术规范可能需要一整页摘要

**保留定量数据**
- 始终包含源材料中的具体数字、日期和指标
- 写「收入 420 万元，同比增长 23%」而非「收入显著增长」
- 包含日期、截止日期和时间线
- 保留单位和精度

**诚实处理不确定性**
- 源材料不清楚时说「文档对此不明确……」而非猜测
- 信息矛盾时标注矛盾之处
- 关键信息缺失时说明缺少什么
- 区分源材料中的事实陈述、观点和推测

### 步骤4：多文档摘要

同时摘要多个文档时：

1. **先读完所有文档**再开始摘要
2. **识别跨文档的共同主题**
3. **标注文档间的矛盾**并标记
4. **归属信息**到具体文档（来源不同时）
5. **综合而非拼接**——找到贯穿文档的叙事线索

### 步骤5：质量检查

交付摘要前逐项核实：

- [ ] 读者能否仅凭此摘要做出决策？
- [ ] 所有关键数字和日期是否保留？
- [ ] 摘要中是否存在源材料中没有的信息？
- [ ] 原作者是否会认为这是公正的表述？
- [ ] 最重要的信息是否在最前面？
- [ ] 篇幅是否适合内容和读者？

使用说明

# 摘要

将文档、文章、对话、代码等内容提炼为简洁准确的摘要，帮助快速获取关键信息。

## 使用

```text
帮我总结这篇文档的要点
```

```text
给这份技术报告写一个执行摘要
```

```text
提取会议记录中的决策和行动项
```

## 工作原理

根据内容类型自动匹配摘要方法：

- **商业文档** → 执行摘要（结论先行 + 关键指标 + 行动项）
- **技术文档** → 技术摘要（目的 + 方案 + 决策 + 权衡）
- **研究论文** → 学术摘要（问题 + 方法 + 发现 + 意义）
- **会议/对话** → 对话摘要（决策 + 行动项 + 分歧 + 待定事项）
- **代码/日志** → 变更摘要（内容 + 原因 + 影响 + 破坏性变更）

支持单文档和多文档摘要，始终保留定量数据、标注不确定性，确保准确性。

如何安装此技能？

访问技能市场，点击「安装」按钮，按提示将技能包放入 AI 编程助手的 skills 目录即可。