| name | effective-document-writing |
| version | 2.3.2.0 |
| description | 起草、重构或评审面向交付的技术文档、设计文档、方案、报告、说明和 Markdown。用于解决主线不清、黑话或空话过多、内容重复、细节淹没重点、术语混乱,以及把对话和修改过程带入正式文档等问题;不替代特定文件格式的排版工具。 |
Effective Document Writing
把文档当作帮助读者理解、判断和行动的接口,而不是对话、探索过程或知识素材的堆放处。
确定写作任务
写作前明确三件事:目标读者已经知道什么,读完需要判断或执行什么,哪些事实、依据、约束和风险会影响该行动。无法服务这些目标的内容不进入正文。
文档类型决定内容边界:设计文档写结论、依据和取舍;规范写可执行规则;报告写发现、影响和行动;操作指南写前置条件、步骤、验证与回退。不要把一种文档写成另一种文档。
重构已有文档时,先识别权威输入及其优先级;原稿是待审材料,不因已经写入就自动成为事实。低优先级原稿中的独有说法,即使未被权威输入否定,也不等于获得支持;无依据的细节应删除或标为待确认,不能自行补全。用户指定的修改是全文约束,应同步到定义、正文、表格、图和验证项,而不是只改被点名的段落。
组织主线
优先按读者理解顺序组织:结论或目标、关键依据、影响与边界、行动或验证。结构随内容调整,不为满足形式机械填充章节。
- 标题表达认知层级,不装饰版面。
- 表格用于稳定映射和比较,列表用于并列规则,图用于关系、顺序或状态。
- 正文承载所有目标读者都需要的主线;原始证据、完整参数和低频细节移入引用或附录。
- 同一事实只在权威位置完整表达一次,其他位置引用或补充新信息。
控制语言和信息密度
每段至少提供一项新内容:事实、结论、关键原因、约束、风险或行动。删除后不影响理解、判断和执行的段落应删除或合并。
- 优先使用行业通用词和具体对象,避免用抽象名词包装简单事实。
- 必要术语首次出现时定义一次;同一概念保持同一名称。
- 不使用“赋能、抓手、闭环、拉通、沉淀、对齐颗粒度”等词替代可直接说明的动作、对象和结果;行业内确有精确定义时除外。
- 避免“显著提升、全面保障、充分考虑、持续优化”等没有对象、条件或验证方式的表态。
- 重要结论提前,不用重复和大段加粗制造重点。
- 复杂内容可以详细,但实现细节、背景知识和例子不能淹没决策主线。
隔离对话和修改过程
正式正文应脱离对话和编辑过程独立成立,只保留当前有效的事实、规则、决策,以及文档目的所需的迁移和兼容关系。
例如,应排除:
- 依赖前置对话才能理解的内容,如“根据你的要求”“如前所述”“经过讨论”;
- 与文档目的无关的生成过程,如 Agent、生成轮次、提示词或工具试跑记录;
- 不影响最终结论的探索过程,如被推翻的方案、排查轨迹和作者心理活动。
保持准确和可评审
- 区分事实、判断和待确认项;没有依据时不把推测写成结论。
- 关键结论提供足以复核的依据,但不把完整取证过程复制进正文。
- 写清适用范围、前提、失败条件和不包含内容,避免绝对化承诺。
- 细节精确到支持当前读者行动即可;不要用伪代码、字段大全或逐行解释替代设计和说明。
交付前检查
- 读者能否快速找到结论、风险和下一步?
- 每段是否提供新的认知或行动价值?
- 是否存在黑话、空泛表态、同义重复或不必要的新术语?
- 主线是否被背景、证据或实现细节遮蔽?
- 是否混入对话、修改历史、试错过程或 AI 生成痕迹?
- 同一事实是否只有一个权威定义,术语和结论是否前后一致?
- 原稿中的结论是否有权威输入支撑,指定修改是否已贯穿所有相关位置?
- 读者能否依据文档完成预期判断或行动?
发现问题时优先删除、合并、重排和具体化,不通过追加解释掩盖结构问题。