夜雨聆风Documents 插件就像一个专门处理正式材料的助手，适合用来写报告、方案、讲义、说明书、会议纪要、项目资料和操作手册。它不只是生成几段文字，而是能根据用途和读者安排结构，也能在已有草稿基础上检查问题、补充内容、统一格式和调整表达，让文档更清楚、更规范，也更方便后续继续修改。
一、Documents 插件能做什么
图 1：创建和编辑文档的基本流程
1、从零创建文档
Documents 可以根据主题、用途、受众和格式要求，生成一份完整文档。例如项目方案、产品说明、课程讲义、培训材料、会议纪要、研究摘要、使用手册和商业计划书。
这类任务的重点不是“写一段文字”，而是先确定文档结构：标题、章节、层级、段落、列表、示例、附录和结论如何组织。
2、编辑已有文档
如果已有初稿，Documents 可以帮助检查逻辑、压缩冗余、补充遗漏、统一术语、调整语气，并优化章节顺序。
它适合处理“内容基本有了，但还不够清晰”的文档。例如把零散笔记整理成正式报告，把草稿改成发布稿，把会议记录整理成行动清单。
3、统一格式与风格
很多文档的问题不在内容，而在格式不统一：标题层级混乱，列表样式不一致，术语前后不统一，段落长短差异过大，语气忽正式忽口语。
Documents 可以按照指定规范统一文档格式，例如章节编号、标题层级、列表方式、术语翻译、引用格式、图表说明和小结风格。
4、生成结构化文档
Documents 适合生成结构化程度较高的内容，例如需求文档、产品规格说明、项目计划、测试报告、用户手册和知识库文章。
这类文档通常需要固定模块：背景、目标、范围、功能、流程、风险、交付物、时间表和责任分工。提前给出结构，生成结果会更稳定。
5、改写、压缩与扩展
Documents 可以根据不同场景调整文档长度和表达方式。例如把长报告压缩成摘要，把简短提纲扩展成完整文章，把技术说明改成面向普通读者的说明。
使用时要明确说明：是“压缩不删核心内容”，还是“重写为更通俗版本”；是“保留原有结构”，还是“重新组织结构”。
二、怎样把任务说清楚
使用 Documents 时，不要只说“帮我写个文档”或“优化一下”。更好的做法是提前说明文档目标、读者对象、输出格式和修改边界。
至少应说清楚以下几类信息：
1、文档类型：报告、方案、说明书、会议纪要、课程讲义、合同草案、操作手册或知识库文章。
2、目标读者：管理层、客户、学生、开发者、普通用户、内部团队或外部合作方。
3、处理方式：从零创建、基于草稿重写、压缩、扩展、润色、校对、结构调整或格式统一。
4、格式要求：章节标题、编号方式、是否使用列表、是否需要小结、是否保留原文结构、是否输出为可编辑文档。
5、边界要求：不要编造数据，不要改变原意，不要删除关键结论，不要加入未经确认的信息，不要使用过度营销化表达。
这些信息越明确，Documents 越容易生成符合用途、便于审阅、便于继续修改的文档。
如果不知道怎么描述，可以从下面的模板开始：
请使用 Documents 插件处理这个文档任务。
文档类型：[报告 / 方案 / 说明书 / 会议纪要 / 课程讲义 / 合同草案 / 操作手册 / 知识库文章]
使用场景：[内部汇报 / 客户沟通 / 课堂教学 / 项目管理 / 产品发布 / 培训学习]
目标读者：[管理层 / 客户 / 学生 / 开发者 / 普通用户 / 团队成员]
处理方式：[从零创建 / 修改初稿 / 压缩 / 扩展 / 润色 / 校对 / 统一格式]
内容输入：[主题 / 提纲 / 草稿 / 会议记录 / 数据 / 参考材料 / 旧版本文档]
结构要求：[前言 / 背景 / 目标 / 正文 / 示例 / 风险 / 小结 / 附录]
风格要求：[正式 / 简明 / 教材风 / 商务风 / 技术文档风 / 面向普通读者]
边界要求：[不要编造数据 / 不要改变原意 / 不要删除关键内容 / 标出需要确认的问题]
交付要求：[Markdown / Word 文档 / PDF 草稿 / 修改说明 / 摘要版 / 可继续编辑版本]
完成后请列出：文档结构、主要修改点、保留内容、补充内容和需要人工确认的问题。
三、场景示例
示例 1：项目方案文档
请使用 Documents 插件生成一份“AI 作业批改助手”的项目方案。
要求包括项目背景、目标用户、核心功能、使用流程、技术实现思路、风险与边界、阶段计划和预期成果。风格正式但不要空泛，不要编造市场数据，适合给学校管理层阅读。
示例 2：会议纪要整理
请使用 Documents 插件把以下会议记录整理成正式会议纪要。
要求提取会议主题、参会人员、讨论事项、关键结论、待办任务、负责人和截止时间。语气简洁清楚，不要添加会议中没有提到的决定，对不确定事项标注“待确认”。
示例 3：产品说明书
请使用 Documents 插件为一款在线课程平台撰写产品说明书。
要求面向普通用户，说明主要功能、注册登录、课程学习、作业提交、学习进度查看和常见问题。语言通俗，结构清晰，避免过多技术术语。
示例 4：技术文档优化
请使用 Documents 插件优化一份 API 使用说明。
要求保留原有技术含义，统一术语和标题层级，补充参数说明、返回值说明、错误处理和调用示例。不要改变接口行为，不要编造不存在的字段。
示例 5：长文压缩成摘要
请使用 Documents 插件把一份 8000 字报告压缩成 1000 字摘要。
要求保留核心结论、关键依据、主要风险和建议措施。删除重复表述和背景性铺垫，不要改变原文立场，并列出被压缩掉的次要内容类型。
四、使用时要注意
1、先明确文档用途
同一主题，写给管理层、客户、学生和开发者，结构和语言都不同。
2、不要只要求“润色”
最好说明是要更正式、更简洁、更通俗，还是更适合发布。
3、区分改写与重写
改写通常保留原意和结构；重写可以重新组织内容。两者边界要提前说明。
4、重要事实需要人工确认
涉及数据、法律、合同、报价、医学、财务和政策内容时，应标出来源和待确认项。
5、保留可编辑性
标题、章节、列表、图表说明和附录应结构清楚，方便后续继续修改和维护。
📘 小结
Documents 插件适合创建、编辑、润色和整理结构化材料。它可以从零生成内容，也可以优化已有草稿。使用时要明确类型、读者、处理方式、格式要求和事实边界，才能得到更稳定、可审阅、可继续修改的成果。
