Skip to main content
可访问的文档是LangChain的重要组成部分。我们欢迎对新功能/集成的文档以及现有文档的社区改进。
我们通常在没有迫切需求的情况下不会合并外部贡献者的新教程。如果您觉得文档中缺少某个主题或覆盖不足，请新建一个issue。
所有文档均属于以下四个类别之一：

Conceptual guides

提供更深入理解和洞察的解释

References

API 技术描述和实现细节

Tutorials (Learn)

指导用户通过实践活动来建立理解的课程

How-to guides

面向任务的指令，适用于知道他们想完成什么任务的用户

​
入门

​
快速编辑：修复错别字

对于简单的修改，例如修复错别字，您可以直接在GitHub上编辑，无需设置本地开发环境：
先决条件：
1

Find the page

跳转到任何文档页面，滚动到页面底部，并点击链接“在GitHub上编辑此页面的源代码”
2

Fork the repository

GitHub 将会提示您将仓库分叉到您的账户中。请确保将分叉到您的
3

Make your changes

直接在GitHub的网页编辑器中更正拼写错误
4
点击 Commit changes... 并给你的提交提供一个描述性的标题，例如 fix(docs): summary of change。如果适用，添加一个 扩展描述。
5

Create pull request

GitHub 将会重定向您以创建一个拉取请求。给它一个标题（通常与提交相同）并遵循 PR 模板清单，如果有的话
文档的PR通常在几天内就会被审查。请留意您的PR，以便回应维护者的任何反馈。除非您有新的信息提供，否则不要提交新的PR - 维护者会在他们方便的时候处理。

​
完整开发 IDE 设置

对于较大的更改或持续贡献，在您的机器上设置本地开发环境非常重要。我们的文档构建管道提供本地预览和实时刷新功能，在您编辑时可以确保您的更改在提交前以预期的方式显示。 请查阅在文档仓库中概述的设置环境步骤 README.md。

​
文档类型

在适用的情况下，所有文档必须提供 Python 和 JavaScript/TypeScript 两种语言的翻译。请参阅我们的本地化指南获取详细信息。

​
概念指南

概念指南以抽象的方式涵盖核心概念，提供深入理解。
  • 以理解为导向：解释事物为何如此运作
  • 宏观视角：比其他类型有更高的视野
  • 面向设计：解释决策和权衡
  • 内容丰富：使用类比和比较
  • 解释设计决策 - “为什么概念X存在？”
  • 使用类比并参考替代方案
  • 避免过多地融合参考内容
  • 链接到相关教程和指南
  • 专注于**“为什么”**而不是”如何”

Memory

Context

​
参考文献

参考文档包含详细且低级别的信息，精确描述了现有功能及其使用方法。

JavaScript/TypeScript reference

一个优秀的参考应该：
  • 描述存在的内容（所有参数、选项、返回值）
  • 内容全面且结构化，便于查找
  • 作为技术细节的权威来源
查看JavaScript/TypeScript参考文档的贡献力量指南。
  • 保持一致性；遵循现有模式进行特定提供者的文档编写
  • 包含基本用法（代码片段）和常见的边缘情况/故障模式
  • 注意功能需要特定版本的情况
  • 新的集成或提供商需要专门的参考页面
  • 复杂的配置选项需要详细的说明
  • API 变更引入了新的参数或行为
  • 社区经常询问关于特定功能的问题

​
编写标准

参考文档有不同的标准 - 请参阅参考文档贡献指南以获取详细信息。

​
Mintlify 组件

使用适当的 Mintlify 组件 提高可读性：
  • <Note> 用于提供有用的补充信息
  • <Warning> 用于重要的注意事项和重大变更
  • <Tip> 用于最佳实践和建议
  • <Info> 用于中性的上下文信息
  • <Check> 用于成功确认

​
页面结构

每个文档页面都必须以 YAML 前置元数据开始： 
---
title: "Clear, specific title"
---

​
本地化

所有文档在可能的情况下都必须在Python和JavaScript/TypeScript中进行本地化。为此，我们使用自定义的行内语法来区分应出现在一种或两种语言中的部分： 
:::python
Python-specific content. In real docs, the preceding backslash (before `python`) is omitted.
:::

:::js
JavaScript/TypeScript-specific content. In real docs, the preceding backslash (before `js`) is omitted.
:::

Content for both languages (not wrapped)
我们不希望缺乏一致性阻碍贡献。如果一个功能只在一个语言中可用，那么在另一个语言赶上来之前，只有该语言的文档是可以接受的。在这种情况下，请包括一个说明，指出该功能在其他语言中尚未可用。
如果您需要帮助在Python和JavaScript/TypeScript之间翻译内容，请在该社区Slack中提问或在其PR中标记维护者。

​
质量标准

​
通用指南

包含相同内容的多个页面难以维护并造成混淆。每个概念或功能应只有一个规范页面。请通过链接到其他指南而不是重新解释来访问。
采取少即是多的方法。如果另一个部分有很好的解释，请链接到它，而不是重新解释，除非你的内容提供了新的角度。

​
可访问性要求

确保文档对所有用户均易访问：
  • 使用标题和列表结构内容，以便于快速浏览
  • 使用具体的、可操作的链接文本，而不是“点击此处”
  • 为所有图像和图表添加描述性的替代文本

​
测试与验证

在提交文档之前：
1

Test all code

运行所有代码示例以确保它们正确工作
2

Check formatting

make lint
make format
3

Build locally

docs build
验证构建过程无错误完成
4

Review links

检查所有内部链接是否正常工作

​
代码内文档

​
语言和风格

使用Google风格的docstrings为所有公共函数提供完整的类型提示。
遵循以下标准编写所有文档：
  • 语音：使用第二人称（“你”）进行指令
  • 时态：使用主动语态和现在时
  • 清晰度：为技术受众撰写清晰、直接的语言
  • 一致性：在整个文档中保持术语的一致性
  • 简洁性：在提供必要上下文的同时，保持句子简洁

​
代码示例

在发布前始终测试代码示例。切勿包含真实的API密钥或秘密。
代码示例要求：
1

Completeness

包含完整、可运行的示例，用户可以复制并执行而不会出错
2
使用真实数据而不是像 “foo” 或 “example” 这样的占位符值
3

Error handling

显示适当的错误处理和边缘情况管理
4

Documentation

为复杂的逻辑添加解释性注释
示例：一个文档良好的函数 
def filter_unknown_users(users: list[str], known_users: set[str]) -> list[str]:
    """Filter out users that are not in the known users set.

    Args:
        users: List of user identifiers to filter.
        known_users: Set of known/valid user identifiers.

    Returns:
        List of users that are not in the known_users set.

    Raises:
        ValueError: If users list contains invalid identifiers.
    """
    return [user for user in users if user not in known_users]

​
获取帮助

我们的目标是实现尽可能简单的开发者设置。如果您在设置过程中遇到任何困难，请通过社区Slack咨询或打开一个论坛帖子。
您现在拥有为LangChain贡献高质量文档所需的一切！🎤🦜
在GitHub上编辑此页面的源代码。
通过MCP将这些文档编程连接到Claude、VSCode等，以获取实时答案。