扩写与细节补全是什么
扩写不是往句子里加形容词，而是按固定维度把要点展开：是什么、为什么这样、怎么做、注意什么。先定维度再动笔，长度自然由维度数量决定，而不是靠重复同义句凑字数。素材没有覆盖的细节要显式留占位（如「待补充：」），交给人来补——让模型自己填，产出的就是看起来完整、实际无据的内容。
基本信息
| 适用平台 | 任意文本模型；长文写作、文档扩写、说明文生成 |
|---|---|
| 核心方法 | 先声明要补的维度清单，再逐维度展开，最后按维度自检 |
| 边界原则 | 素材未覆盖的细节留占位，由人补齐或注明来源 |
| 长度控制 | 按维度数估算篇幅，避免某一段无限展开 |
典型使用场景
- 把会议要点扩成可执行说明，补上责任人与验收标准
- 把术语条目扩成面向新同事的解释，补背景与常见误解
- 把结论扩成有论证链的报告段落，补数据来源与推导步骤
- 把运维操作单扩成手册，补前置条件、回滚方式与验证步骤
- 把零散备注扩成产品需求，补边界情况与不做的事
扩写模板
扩写模板
把要点扩写为 300 字说明，按以下维度依次补充：
1) 术语解释（面向不了解背景的同事）
2) 为什么这样设计（依据来自素材，不得臆测）
3) 操作示例（优先使用素材中已有的命令或步骤）
4) 常见误解澄清（写清正确做法）
5) 已知限制与不适用场景
素材未覆盖的细节用「待补充：…」标注，不要编造。
要点：<points>……</points>四个维度的作用
| 维度 | 回答的问题 | 缺失后果 |
|---|---|---|
| 是什么 | 它指什么、边界在哪 | 读者自行想象，理解各不相同 |
| 为什么 | 为什么采用这个做法 | 只知步骤，变动时无从判断能否改 |
| 怎么做 | 具体操作与参数 | 文档无法落地执行 |
| 注意什么 | 限制、风险、常见错误 | 踩坑后才发现文档没写 |
占位符要统一格式（如统一用「待补充：」前缀）并集中成清单，否则后续在长文里检索补写点会很费劲。
分两轮比一轮好：第一轮只补齐维度骨架，第二轮再润色措辞。混在一起时，模型容易为了通顺而删掉不确定但重要的细节。