• 格式：支持 PDF、CSV、DOCX、TXT、Markdown 格式，优先推荐使用 Markdown 格式。

• 大小：每次最多上传 10 个文件，单文件大小不超过 10MB。

详细说明与示例如下：

文档类型与命名

• 类型：推荐使用 Markdown 格式。相较于 Word 和 PDF，我们推荐使用 Markdown 格式以获得更佳的文档处理效果。
• 编码：推荐使用 UTF-8 编码，以确保字符兼容性最佳。
• 文档命名：文档名用词简洁明了，不同命名之间应有明显差异，便于模型理解。避免使用含义不明的英文缩写、数字或符号。

反例：《编码规范》、《安全规范1》、《安全规范2》、《SR3》这些命名缺乏具体性，不易区分，且可能造成混淆。

文档结构

• 层级结构：需采用多级标题来组织文档内容，避免将信息堆砌在单一段落。特别是对于专有名词的释义，每个专有名词建议单独成行。

• 各级标题：各层级标题含义清晰用词简洁明了，不同标题之间有明显差异。避免使用含义不明的英文缩写、数字或符号。避免罗列文章关键词，会对模型造成干扰。

《AK安全使用规范》【目录】关键词：AK、安全规范、Access Key一、 定义Access Key（简称AK），是用于身份验证的一种密钥对，由Access Key ID 和 Access Key Secret 组成。它允许用户通过API调用安全地访问系统服务。本规范旨在明确AK的使用规则，确保系统的安全性与稳定性。Access Key ID是代表用于标识用户的身份。Access Key Secret是代表用于加密签名，保证请求的唯一性和不可抵赖性。二、 使用原则确保Access Key Secret的保密性，不得泄露给任何未经授权的第三方。遵循最小权限原则授予API调用权限，仅授予完成任务所必需的权限。定期每90天更换Access Key Secret。记录AK的使用情况，并定期审查使用日志，确保没有异常行为，以及在不需要时及时撤销其权限。三、 安全实践为确保访问密钥（AK）的安全，我们实施了以下简化的安全实践：在生产环境中，我们优先使用环境变量存储AK，避免硬编码；通过配置管理系统统一管理AK，防止其在代码中的直接暴露。同时，我们对日志进行过滤，确保AK的Secret信息不会被记录。我们还定期进行权限审查，确保AK仅拥有执行必要操作所需的最低权限。此外，建立了异常检测机制，以便快速识别并响应任何可疑的AK使用活动。这些措施共同保障了AK的安全和合理使用。四、 API调用示例● 示例1Node.js中使用AK/SK进行API调用：在Node.js中，可以使用axios库来发送API请求，并在请求头中包含AK和SK。例如，使用AK和SK进行签名认证的API请求可能如下所示：【示例代码块】● 示例2Python中使用AK/SK调用API：在Python中，可以使用requests库来发送带有AK和SK的API请求。以下是一个示例代码，展示了如何构建请求并添加签名：【示例代码块】

正例（注释为优化说明）：

《AK安全使用规范》/*去除干扰元素：文章开头的目录、关键词等无需召回的内容可以删除，以减少干扰。专业名词解释：专业名词及其解释应以条目形式列出，以便于模型更好地查找和理解。 */一、 定义● Access Key（简称AK）：是用于身份验证的一种密钥对，由Access Key ID 和 Access Key Secret 组成，它允许用户通过API调用安全地访问系统服务。● Access Key ID：用于标识用户的身份。● Access Key Secret：用于加密签名，保证请求的唯一性和不可抵赖性。/*避免使用大段落陈述，建议采用分点陈述的方式，以便模型更容易理解 */二、 使用原则● 保密性：Access Key Secret 必须严格保密，不得泄露给任何未经授权的第三方。● 最小权限：授予API调用的权限应遵循最小权限原则，仅授予完成任务所必需的权限。● 定期轮换：定期更换Access Key Secret，推荐每90天更换一次。● 监控与审计：记录AK的使用情况，并定期审查使用日志，确保没有异常行为。● 及时撤销：当不再需要使用某个AK时，应及时撤销其权限。三、 安全实践● 环境变量：在生产环境中，使用环境变量而非硬编码的方式存储AK。● 配置管理：使用配置管理系统来管理AK，避免直接在代码中出现。● 日志过滤：确保日志记录中不会出现Access Key Secret。● 权限审查：定期检查AK的权限设置，确保符合最小权限原则。● 异常检测：建立异常检测机制，及时发现并处理可疑活动。/*关于API调用示例部分，示例层级的名字不清晰，其中“示例1”和“示例2”，需要修改为某个示例的具体名字*/四、API调用示例● Node.js中使用AK/SK进行API调用示例 在Node.js中，可以使用axios库来发送API请求，并在请求头中包含AK和SK。例如，使用AK和SK进行签名认证的API请求可能如下所示：【示例代码块】● Python中使用AK/SK调用API示例在Python中，可以使用requests库来发送带有AK和SK的API请求。以下是一个示例代码，展示了如何构建请求并添加签名：【示例代码块】

‍文档章节和段落

• 将相关性强的内容尽量聚集在同一段落或章节内，以确保数据处理文档切片的准确性和相关内容的连续性。
• 避免指代或缩略关键信息。如果遇到内容相同，避免“同上”或“与某个模块相同”这样的表述，应该具体写明内容。
• 避免无意义的空行。

• 建议利用项目符号（如 Markdown 中的“-”或“*”）和有意义的缩进来分点阐述，可以在一定程度上辅助模型更准确地理解。

反例：1）无意义的空行

6.3 方法的接收器推荐以类名第一个英文首字母的小写作为接收器的命名。
接收器的命名在函数超过`20行`的时候不要用单字符。
命名不能采用 `me`，`this`，`self` 这类易混淆名称。

2）使用省略描述或指代描述

4.6 Go语言的接口命名规则命名规则和结构体命名规则一致。或同3.2章《命名规则和结构体命名规则》

正例：1）去掉无意义的空行

6.3 方法的接收器● 推荐以类名第一个英文首字母的小写作为接收器的命名。● 接收器的命名在函数超过`20行`的时候不要用单字符。● 命名不能采用 `me`，`this`，`self` 这类易混淆名称。

4.6 Go语言的接口命名规则● 采用驼峰命名方式，首字母根据访问控制采用大写或者小写。● 结构体名应该是名词或名词短语，如 Customer、WikiPage、Account、AddressParser，它不应是动词。● 避免使用 Data、Info 这类意义太宽泛的结构体名。

特殊内容与媒体处理

当文档段落中出现图片、表格时，应该对应注意以下几点：

文档中关于表格的处理：

• 表格格式要求：表格的第一行应为表头，不要将表格名称作为表格的第一行内容。
• 表格结构说明：对于表格结构没有特别的要求。可以根据内容的需要自由设计列和行。
• 保持样式简洁：建议去除所有不必要的格式，如背景色、字体样式等。表格线条应保持清晰，使用默认的线条样式。
• 补充说明：

• 企业标准版，由于表格处理能力仍在持续优化，建议在文档中尽量减少表格，或考虑比如文本列表等替代方式来展示表格数据。
• 企业专属版与私有化版本，通义灵码已经具备了更高级的表格处理能力，可确保表格数据的准确性。

• 优先使用文字：尽可能地使用文字表达信息，如果图像中的文字比较少且包含重要信息，建议将信息转录成文字的形式。
• 添加图示说明：确保所有核心图都有图示说明（即图解或说明），图示说明应清晰地解释图中的主题。

• 特殊字符：避免包含表情包的特殊字符，以免造成解析问题。

• 页眉页脚、水印、批注：避免包含批注、页眉、页脚或水印，以免造成不必要的干扰。
• 文档背景：文档每页尽可能无背景，复杂背景容易造成干扰。
• 统一文字方向：确保文档中所有文字的方向一致。
• 音视频：避免包含音视频等多媒体内容。

不同类型文档的处理准则：

• 使用更新格式：优先采用 2007 版或之后的 Word 格式。
• 使用全局样式：统一使用全局标题和段落样式。
• 避免字符样式：不要使用字符样式，如特殊字体格式、边框和底纹。
• 使用段落样式：应使用段落样式来保持文档格式的一致性。

• 避免使用图片：不要直接将图像转换成 PDF 文件。应该将图像中的重要信息转录成文本，并按照本文中的文档规范要求进行组织。
• 不包含嵌入压缩文件： 请确保文件中不包含嵌入的压缩文件。
• 保持文档单栏布局：避免双栏并排形式，以确保内容被正确解析。

CSV：

• 避免使用图片：不插入图片，以确保文档的文本可搜索性。
• 不嵌入压缩文件：不要在文档中嵌入压缩文件。
• 表头作为第一行：在表格中，将表头放在第一行，不要将表格名称作为表格的第一行内容。

• 特别说明：

• 推荐用法：保存 FAQ（常见问题解答）中的问答对。FAQ 的问题表述清晰明确，答案简洁易懂，使用用户熟悉的术语，突出关键词，以提高检索召回准确度。例如：

• 不推荐：在 CSV 中上传复杂的关系型数据表。可能会导致数据处理时间超长，导致数据处理失败。

• 在撰写文档内容时，如介绍特性或功能时，检查是否存在与其他文档重叠的内容，并尽量减少重复。
• 尽量保证每个文档都是自成一体的知识单元，能够独立提供完整而准确的信息。

知识聚合：尽量将与同一主题相关的所有信息整合到一起。

规范统一：确保同类信息在不同文档间保持一致性和标准化。

• 确保所有文档遵循一致的风格和术语标准。
• 制定详细的风格指南和术语表，并对文档编写者进行培训，确保他们能够正确应用这些规则。

覆盖全面：确保文档的完整性、及时性、准确性。

• 确保知识库覆盖问答所需的高频知识。针对需要高精确度回答的问题，知识无遗漏，如对于某个 API 的咨询，需确保包含了所有相关的接口、参数。
• 定期对知识库进行审核和更新，补充缺失的知识点，淘汰过时的内容。

遵循上述原则，不仅能帮助企业知识库管理员创建高质量的产品文档，还能提升用户的满意度和体验。通过系统化的方法来组织和维护文档，确保了信息的准确性、易用性和完整性，为用户提供了一个更加可靠的知识资源库。

2）手把手带你体验通义灵码企业 RAG，让问答和代码补全更贴合企业规范和业务特点。赢通义灵码超大鼠标垫 1000 份，领完为止：https://developer.aliyun.com/topic/lingma/202409

点击阅读原文，下载使用通义灵码！