先大纲后成文是什么
把写作任务拆成两步：第 1 步只出大纲，第 2 步按确认的大纲逐节成文。这样做的好处是返工成本低——结构问题在百字阶段就能发现，不必等写完几千字再推翻重来。第 1 步还可以顺带产出开放问题清单：哪些信息需要确认、哪些内容作者自己还没想清楚，先摆出来比藏在成文里更容易被发现。
要点
| 好处 | 结构问题在百字阶段暴露，避免写完长文再推翻 |
|---|---|
| 确认点 | 大纲里列出开放问题清单，让分工明确 |
| 约束 | 第 2 步只写覆盖范围内的内容，防跑题扩写 |
| 小节规格 | 每节给出字数区间，避免某节过长挤占其他内容 |
| 变更处理 | 成文阶段发现需要新增章节时先停下确认，不要自行加 |
典型使用场景
- 迁移说明与技术方案：结构先对齐，避免写完才发现章节缺失
- 长文写作：报告、手册、白皮书按节展开
- 多人协作写作：大纲作为分工依据，各节负责人明确
- 对外材料：结构先经业务确认，减少敏感表述返工
- 教学材料：按由易到难排章节顺序，先确认结构再补内容
两步提示
两步提示
第 1 步：为《内部 API 网关迁移说明》写 5 节大纲，每节给出 1 句内容摘要与我需要你确认的开放问题。
（确认后）第 2 步：按确认的大纲逐节展开，每节 150-250 字； # 细化到节，避免长文跑偏
只写大纲覆盖的内容，新增观点先停下来问。两步分工
| 阶段 | 产出 | 验收点 |
|---|---|---|
| 第 1 步 | 章节标题 + 每节一句摘要 + 开放问题 | 结构是否覆盖需求、有无重复章节 |
| 第 2 步 | 按大纲逐节成文 | 每节是否在字数区间内、是否只写覆盖范围 |
| 合并检查 | 通读定稿 | 章节衔接、术语一致、结论与开篇呼应 |
大纲里让模型显式列出「我不确定的地方」，这些正是需要业务确认的点；等成文后再问，往往已经写进正文了。