# Article Outline

> 在正式撰写任何文章、教程、指南、报告或博客之前，用来先构思一份结构化大纲。当用户要求"写一篇文章/教程/指南/博客"、"帮我写一个说明文档"，或明确说"先列个大纲"、"先构思一下"时，都应主动使用本skill先产出大纲，经用户确认后再进入正文写作。即使用户没有显式提到"大纲"两个字，只要任务是产出一篇面向读者阅读的完整文章/文档，也应该先触发本skill构思结构，而不是直接开始写正文。

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

---


# 简介

在动笔写正文之前，先产出一份结构化大纲，让用户确认方向、受众和内容框架无误后，再进行正式写作。这样可以避免写了很长内容之后才发现方向不对。

## 什么时候用

- 用户要求写文章、博客、教程、指南、白皮书、深度解析等长文时
- 内容会被别人阅读、需要清晰的信息组织时（不是内部草稿、聊天式回答）
- 用户明确说"先构思大纲""先列个提纲"时

不需要用于：简短的问答、代码片段说明、内部笔记性质的总结。

## 工作流程

### 第一步：了解读者与目标（如信息不足，先问）

在动笔构思大纲前，尽量确认以下几点（如果用户已经在需求里说清楚了，就不用再问）：

- 这篇文章是写给谁看的？（新手 / 有一定基础 / 专家）
- 读者读完希望获得什么结果？（学会一个技能、理解一个概念、做出一个决策）
- 大概篇幅/深度？（快速入门 5 分钟读完，还是深度指南 30 分钟）

如果用户的需求已经足够具体，直接给出合理假设，不必逐一发问。

### 第二步：产出大纲

大纲应包含以下"文章开篇元信息"模块，根据文章类型灵活取舍，不是每篇都要全部具备：

1. **标题**：清晰、信息量大，避免空洞的名词式标题
2. **简介 / 引言**：这篇文章要解决什么问题，为什么值得读
3. **你将学到什么**：列出读完本文能掌握的具体知识点或技能（3-6条，用具体、可验证的表述，而不是空泛的词）
4. **适合人群**：明确写给谁看，帮读者快速判断"这是不是写给我的"
5. **前置知识 / 阅读门槛**：读者需要具备的背景知识（如果没有门槛可省略）
6. **预计阅读时间**：给读者一个合理预期
7. **学习路径 / 内容结构导览**：简要预告文章会按什么顺序展开，帮读者建立地图感
8. **正文大纲**：分章节/小节列出，每个章节包含：
   - 章节标题（优先用"信息句"而非抽象名词，例如用"流式传输将首字延迟降低了50%"而不是"效果"）
   - 该章节要传达的核心要点（1-2句话概括，之后写正文时展开）
   - 是否需要示例、代码、图表等
9. **你能从本指南中获得什么 / 结语方向**：文章结尾打算给读者什么收获或行动指引（如可选的下一步、参考资料等）

### 第三步：应用"写好文档"的原则来设计大纲结构

参考[怎样才算好文档](./references/what_makes_documentation_good.md)的核心原则，在设计大纲时就提前考虑，而不是等写完正文再改：

**让读者能快速略读（Make it skimmable）**
- 章节标题尽量用"信息句"，一眼看出这节讲了什么，而不是"背景""结果"这种抽象名词
- 大纲里为每个章节预先想好一句话的"主题句"，正文写作时可以直接作为段首句
- 优先考虑哪些地方适合用列表、表格来呈现，而不是大段文字
- 重要结论放在段落/章节开头，不要"层层铺垫"到最后才说重点

**广泛地帮助读者（Be broadly helpful）**
- 大纲里标注可能需要额外解释的术语或前置概念（哪怕对专家读者是常识，对新手可能是障碍）
- 优先安排"读者最可能遇到的问题"，而不是罕见的边缘情况
- 如果涉及代码示例，大纲里注明尽量保持独立、自包含，减少读者需要来回查阅的情况

**行文一致性**
- 在大纲阶段就定好术语、大小写、称呼方式（如统一用"你"还是"用户"），避免正文风格前后不一致

这些原则不需要在大纲里逐条罗列出来讲给用户听，而是应该体现在大纲的具体设计中（比如章节标题怎么起、顺序怎么排）。

### 第四步：请用户确认

大纲产出后，明确询问用户：
- 大纲结构是否合适？
- 读者定位/深度是否准确？
- 有没有要增删的章节？

得到确认或修改意见后，再进入正文撰写阶段。不要在没有确认大纲的情况下直接写完整正文。

## 大纲输出格式

大纲本身用 Markdown 呈现在对话中即可（不需要生成单独文件），除非用户要求导出为文档。结构示例：

```markdown
# [文章标题]

## 简介
[1-2段，说明这篇文章要解决什么问题]

**你将学到：**
- ...
- ...

**适合人群：** ...
**预计阅读时间：** ... 分钟
**前置知识：** ...（如无可省略）

## 内容导览
本文将按以下顺序展开：① ... ② ... ③ ...

## 正文大纲
### 1. [信息句式章节标题]
- 核心要点：...
- 是否需要示例/代码/图表：...

### 2. [信息句式章节标题]
- 核心要点：...

...

## 结语方向
[读完本文后，希望读者获得的收获或下一步行动]
```

## 注意事项

- 大纲要具体，避免空话套话。比如"你将学到如何使用xx工具"不如"你将学到如何用3行代码用xx工具完成批量重命名"
- 章节数量不要贪多，一般 4-8 个主章节为宜，具体视文章篇幅而定
- 如果用户的主题比较宽泛或模糊，大纲阶段可以顺带帮用户收窄选题角度，而不是等写正文时才发现题目太大