document-content-quality

文档内容处理

把正式内容整理成目标读者无需补充背景也能看懂、执行和验收的文档。格式服务于理解，内容服务于行动；不要为了“看起来丰富”堆叠组件。

先确定任务边界

1. 判断任务是创建、改写、整理、审视、展示优化还是最终交付。
2. 明确阅读对象、文档目的，以及读者看完后需要采取的行动。
3. 识别用户允许的改动范围。只要求审视或提出建议时，不修改原文件或线上文档；要求创建、改写或写入时，完成相应交付。
4. 保留原始事实、数字、范围、名称、链接、立场和已经确认的决定。信息不足时标记“待确认”，不得自行补造。
5. 不把经验做法、合理推断或为了补全文档而新增的流程写成已确认要求。确有帮助时将其单独标为“建议”，不得擅自指定原材料未提供的负责人、日期、金额、责任或验收动作。

组织内容

默认按“结论与行动 → 必要背景 → 执行内容 → 验收与待确认事项”组织。根据文档类型调整，但始终把核心结论、关键决定和下一步放在前面。

根据内容选择表达形式：

内容	推荐形式
背景、原因、分析、判断	简短连贯的段落
数据、价格、排期、方案对比	表格
操作过程、审批路径	编号步骤；复杂时使用流程图
准备材料、检查事项	可勾选清单
时间安排、项目阶段	时间线或表格
角色关系、系统关系、复杂结构	关系图或画板
页面操作说明	基于真实页面的截图，并标出关键位置
长文档	清晰、统一且不跳级的标题层级

只在图示明显比文字更易懂时使用图示。高亮块、分栏、颜色和装饰性图片要克制；同类信息保持同一种呈现方式。正式公文、法律材料和需要复制到外部平台的内容，优先使用稳定的标题、段落、列表和表格。

写得简单易懂

• 一句话尽量只表达一个意思，优先使用常用词和主动表达。
• 删除不影响结论、行动或判断的重复话和空话。
• 非必要不使用专业术语；必须使用时，在第一次出现后用括号补充普通人能理解的解释。
• 抽象要求、容易误解的填写项和验收标准，尽量补充一个正确示例。
• 不把需要解释的背景全部拆成项目符号，也不把真正的步骤写成长段落。

保证他人能够执行

站在没有参与前期讨论的读者角度检查。根据任务需要补齐或明确标记以下信息：

• 为什么要做；
• 谁负责、谁配合、遇到问题找谁；
• 具体做什么、不做什么；
• 何时开始、何时完成；
• 需要哪些资料、权限或前置条件；
• 最终交付什么；
• 做到什么程度算完成；
• 有哪些风险、例外和待确认事项。

区分“已确认事实”“判断或建议”“待确认事项”，不要混写。表格中的任务、负责人、时间和验收要求也遵守同一规则；原材料未确认的内容必须标为“待确认”或“建议”。可能变化的价格、规则、产品能力和外部资料，应标明查询或确认日期。

处理链接、隐私和时效

• 涉及第三方产品时，在相关内容附近加入名称清楚的超链接，优先使用官方网站、官方说明或实际操作页面，不写含糊的“点击这里”。
• 交付前检查链接是否能打开、是否需要额外权限，并说明相关费用、限制、风险或时效。需要当前信息时，先查证再写入。
• 对外内容不得包含内部账号、密钥、个人隐私、内部路径或未开放权限的内部链接。
• 正文只保留理解和执行所需的信息；复杂背景、详细说明和参考资料放入附录。

与其他能力配合

本 Skill 负责内容结构、表达、可执行性和展示选择，不替代文件或平台操作能力：

• 读取或修改 Lark 文档时，同时使用 lark-doc；涉及画板时使用 lark-whiteboard。遵循对应能力的读取、写入和回读要求。
• 创建或修改 Word、PDF、表格或幻灯片时，同时使用对应文件能力，并完成其要求的渲染或视觉检查。
• 只进行思想共创、逻辑拆解且暂不形成正式交付时，使用 structured-thinking-advisor。
• 只做自媒体成稿审校、公众号排版或多平台内容生产时，使用相应内容能力；正式制度、通知、方案、报告、JD 和客户材料仍使用本 Skill。

交付前检查

完成前逐项检查：

1. 目标读者能否在不询问作者的情况下理解核心结论和下一步？
2. 负责人、时间、输入、交付物和验收标准是否足够明确？
3. 标题层级、编号、表格、清单和图示是否选用合理且保持一致？
4. 专业术语是否已解释，抽象要求是否有必要的示例？
5. 已确认、建议和待确认内容是否清楚分开？
6. 第三方链接是否有效、命名清楚、权限和时效说明完整？
7. 是否泄露隐私、密钥或仅内部可见的信息？
8. 是否保留了原始事实和用户限定的范围，没有擅自扩写或遗漏？

修改线上文档后必须重新打开或回读；生成 Word、PDF 或其他可视化文件后必须渲染检查。发现内容、格式、链接或执行信息不完整时，先修正再交付。