leeyorke 简介
在动笔写正文之前，先产出一份结构化大纲，让用户确认方向、受众和内容框架无误后，再进行正式写作。这样可以避免写了很长内容之后才发现方向不对。
什么时候用
- 用户要求写文章、博客、教程、指南、白皮书、深度解析等长文时
- 内容会被别人阅读、需要清晰的信息组织时（不是内部草稿、聊天式回答）
- 用户明确说"先构思大纲""先列个提纲"时
不需要用于：简短的问答、代码片段说明、内部笔记性质的总结。
工作流程
第一步：了解读者与目标（如信息不足，先问）
在动笔构思大纲前，尽量确认以下几点（如果用户已经在需求里说清楚了，就不用再问）：
- 这篇文章是写给谁看的？（新手 / 有一定基础 / 专家）
- 读者读完希望获得什么结果？（学会一个技能、理解一个概念、做出一个决策）
- 大概篇幅/深度？（快速入门 5 分钟读完，还是深度指南 30 分钟）
如果用户的需求已经足够具体，直接给出合理假设，不必逐一发问。
第二步：产出大纲
大纲应包含以下"文章开篇元信息"模块，根据文章类型灵活取舍，不是每篇都要全部具备：
- 标题：清晰、信息量大，避免空洞的名词式标题
- 简介 / 引言：这篇文章要解决什么问题，为什么值得读
- 你将学到什么：列出读完本文能掌握的具体知识点或技能（3-6条，用具体、可验证的表述，而不是空泛的词）
- 适合人群：明确写给谁看，帮读者快速判断"这是不是写给我的"
- 前置知识 / 阅读门槛：读者需要具备的背景知识（如果没有门槛可省略）
- 预计阅读时间：给读者一个合理预期
- 学习路径 / 内容结构导览：简要预告文章会按什么顺序展开，帮读者建立地图感
- 正文大纲：分章节/小节列出，每个章节包含：
- 章节标题（优先用"信息句"而非抽象名词，例如用"流式传输将首字延迟降低了50%"而不是"效果"）
- 该章节要传达的核心要点（1-2句话概括，之后写正文时展开）
- 是否需要示例、代码、图表等
- 你能从本指南中获得什么 / 结语方向：文章结尾打算给读者什么收获或行动指引（如可选的下一步、参考资料等）
第三步：应用"写好文档"的原则来设计大纲结构
参考怎样才算好文档的核心原则，在设计大纲时就提前考虑，而不是等写完正文再改：
让读者能快速略读（Make it skimmable）
- 章节标题尽量用"信息句"，一眼看出这节讲了什么，而不是"背景""结果"这种抽象名词
- 大纲里为每个章节预先想好一句话的"主题句"，正文写作时可以直接作为段首句
- 优先考虑哪些地方适合用列表、表格来呈现，而不是大段文字
- 重要结论放在段落/章节开头，不要"层层铺垫"到最后才说重点
广泛地帮助读者（Be broadly helpful）
- 大纲里标注可能需要额外解释的术语或前置概念（哪怕对专家读者是常识，对新手可能是障碍）
- 优先安排"读者最可能遇到的问题"，而不是罕见的边缘情况
- 如果涉及代码示例，大纲里注明尽量保持独立、自包含，减少读者需要来回查阅的情况
行文一致性
- 在大纲阶段就定好术语、大小写、称呼方式（如统一用"你"还是"用户"），避免正文风格前后不一致
这些原则不需要在大纲里逐条罗列出来讲给用户听，而是应该体现在大纲的具体设计中（比如章节标题怎么起、顺序怎么排）。
第四步：请用户确认
大纲产出后，明确询问用户：
- 大纲结构是否合适？
- 读者定位/深度是否准确？
- 有没有要增删的章节？
得到确认或修改意见后，再进入正文撰写阶段。不要在没有确认大纲的情况下直接写完整正文。
大纲输出格式
大纲本身用 Markdown 呈现在对话中即可（不需要生成单独文件），除非用户要求导出为文档。结构示例：
# [文章标题]
## 简介
[1-2段，说明这篇文章要解决什么问题]
**你将学到：**
- ...
- ...
**适合人群：** ...
**预计阅读时间：** ... 分钟
**前置知识：** ...（如无可省略）
## 内容导览
本文将按以下顺序展开：① ... ② ... ③ ...
## 正文大纲
### 1. [信息句式章节标题]
- 核心要点：...
- 是否需要示例/代码/图表：...
### 2. [信息句式章节标题]
- 核心要点：...
...
## 结语方向
[读完本文后，希望读者获得的收获或下一步行动]
注意事项
- 大纲要具体，避免空话套话。比如"你将学到如何使用xx工具"不如"你将学到如何用3行代码用xx工具完成批量重命名"
- 章节数量不要贪多，一般 4-8 个主章节为宜，具体视文章篇幅而定
- 如果用户的主题比较宽泛或模糊，大纲阶段可以顺带帮用户收窄选题角度，而不是等写正文时才发现题目太大