DeepWiki-Open：基于RAG与AI的代码文档自动化生成与问答系统实践

1. 项目概述：DeepWiki-Open，你的AI代码文档生成器

如果你和我一样，经常面对一个全新的、文档寥寥无几的GitHub仓库，需要花上半天甚至一天时间去理解它的结构、逻辑和用法，那么你一定会爱上DeepWiki-Open。这不仅仅是一个工具，更像是一位不知疲倦的代码架构师和文档工程师的结合体。你只需要给它一个仓库链接——无论是GitHub、GitLab还是Bitbucket，公开的还是私有的——它就能在几分钟内，为你生成一个结构清晰、图文并茂、甚至能与之对话的交互式Wiki。

这个项目的核心价值在于，它用AI自动化解决了开发者最头疼的“代码理解”和“知识沉淀”问题。想象一下，接手一个遗留项目，或者评估一个开源库，你不再需要逐行阅读代码，或者大海捞针般地搜索零散的Issue和PR。DeepWiki-Open会为你克隆代码、分析结构、理解模块关系，并用自然语言生成详尽的文档，同时绘制出直观的架构图和数据流图。更酷的是，它的“Ask”功能让你能像与专家对话一样，直接向代码库提问，获取基于代码上下文的精准答案。而“DeepResearch”功能则能对复杂问题进行多轮深度研究，输出结构化的分析报告。

我最初接触这个项目，是因为团队内部有大量缺乏文档的微服务，新人上手成本极高。手动维护Wiki又耗时耗力。DeepWiki-Open的出现，完美地填补了这个空白。它支持多种主流AI模型后端（Google Gemini, OpenAI, OpenRouter, Azure OpenAI, 本地Ollama），也支持多种嵌入模型，这意味着你可以根据成本、性能和数据隐私需求，灵活地搭建属于你自己的私有化文档生成流水线。接下来，我将从设计思路到实操细节，为你完整拆解如何部署和使用这个强大的工具。

2. 核心架构与设计思路拆解

DeepWiki-Open的成功，源于其清晰的分层架构和对开发者痛点的精准把握。它不是简单地将代码扔给大语言模型（LLM）然后生成一堆废话，而是构建了一个完整的“理解-分析-呈现”管道。

2.1 核心工作流：从代码仓库到交互式Wiki

整个系统的运作可以概括为四个核心阶段，我将其称为“代码理解四部曲”：

1. 代码摄取与解析阶段：系统首先会克隆你指定的Git仓库。这里有一个关键设计是支持私有仓库，通过用户提供的Personal Access Token进行认证。克隆后，它不是简单地读取文件，而是会进行一轮静态分析，识别项目结构（如src/,tests/,config/目录）、主要编程语言、入口文件以及文件之间的导入/依赖关系。这一步为后续的深度理解奠定了基础。

2. 知识向量化与存储阶段（RAG核心）：这是项目的“大脑”所在。系统会将代码文件（以及可能的README等文档）切割成有意义的片段（Chunk），然后使用嵌入模型（Embedding Model）将这些文本片段转换为高维向量（Vector）。这些向量被存储在一个向量数据库中。为什么这么做？因为直接让LLM阅读几十万行代码是不现实且低效的。向量化之后，当用户提问时，系统可以快速从海量代码中“检索”出与问题语义最相关的几个代码片段，作为上下文喂给LLM。这就是检索增强生成（RAG）的精髓，确保了回答的准确性和相关性。

3. 智能生成与绘图阶段：有了代码结构和检索到的相关上下文，LLM开始工作。它被要求扮演一个技术文档工程师，根据代码生成模块说明、API文档、使用示例等。同时，另一个并行的任务是根据分析出的模块关系，生成Mermaid图表定义，用于可视化架构。这里的设计巧妙之处在于“模型无关性”。系统通过一个Provider抽象层，可以无缝切换Google Gemini、OpenAI GPT、OpenRouter上的Claude/Mistral，甚至本地运行的Llama 3等模型。这意味着你可以选择最适合你预算和需求的“大脑”。

4. 交互式呈现与问答阶段：生成的文档和图表被组织成一个具有导航栏的静态Wiki站点。而“Ask”功能则开放了一个持续对话的接口。用户可以在侧边栏提问，系统会实时从向量数据库中检索相关代码，并流式输出回答。“DeepResearch”则更进一步，它会将复杂问题分解，进行多轮（最多5轮）迭代检索和思考，最终生成一份带有研究计划、过程更新和最终结论的深度报告，非常适合理解复杂的设计决策或算法实现。

2.2 技术栈选型背后的考量

项目的技术栈选择体现了实用主义和现代化：

• 后端（API）：采用Python + FastAPI。FastAPI的异步特性非常适合处理LLM调用这类I/O密集型任务，能高效管理并发请求。依赖管理使用Poetry，这比传统的requirements.txt更现代，能更好地处理依赖冲突和锁定版本。
• 前端（Web UI）：采用Next.js (React)+TypeScript。Next.js提供了开箱即用的服务端渲染、路由等能力，能快速构建出体验良好的单页应用。TypeScript则保证了代码在复杂交互下的类型安全。
• 向量数据库与嵌入：项目使用ChromaDB作为默认的向量存储，它轻量、易用且与Python生态集成良好。嵌入模型支持OpenAI的text-embedding-3-small、Google的text-embedding-004以及Ollama的本地模型。这种多样性让用户可以在效果、成本和数据隐私之间做权衡。例如，如果你全程使用Google Gemini生成文档，那么搭配Google的嵌入模型通常能获得更好的语义一致性。
• 容器化与部署：提供完整的Docker和Docker Compose配置。这是现代应用部署的标配，它解决了“在我机器上能跑”的环境依赖问题，让一键部署成为可能。数据持久化通过挂载~/.adalflow目录到容器内实现，确保了克隆的仓库、生成的向量索引和缓存内容不会随着容器销毁而丢失。

实操心得：Provider抽象层的价值项目将LLM调用抽象成统一的Provider接口，这个设计非常漂亮。它带来的最大好处是“可插拔性”。当有新的AI服务（比如某天出了个更便宜的国产API）出现时，开发者只需要实现一个新的Provider类，而无需改动核心的业务逻辑（RAG检索、文档生成流程）。这极大地降低了维护成本和扩展难度。在实际使用中，我经常根据任务切换模型：快速生成初稿用Gemini Flash（便宜且快），需要深度推理时切到GPT-4或Claude。

3. 从零开始的详细部署与配置指南

理论讲完，我们进入实战环节。我会带你走一遍最稳定、最推荐的部署路径：使用Docker Compose。这种方式隔离性好，依赖清晰，最适合生产或个人长期使用。

3.1 环境准备与前置条件

在开始之前，你需要准备好以下几样东西：

1. 一台服务器或本地开发机：建议配置至少2核CPU、4GB内存。如果处理大型仓库（超过100MB），内存最好在8GB以上。操作系统可以是Linux、macOS或Windows（需安装Docker Desktop）。
2. Docker与Docker Compose：确保你的系统已安装Docker Engine和Docker Compose插件。可以通过运行docker --version和docker compose version来验证。
3. 至少一个可用的AI API Key：这是项目的“燃料”。你可以从以下任选其一或准备多个：
   • Google Gemini API Key：前往 Google AI Studio 免费创建。Gemini API目前对个人开发者比较友好，有免费的调用额度。
   • OpenAI API Key：前往 OpenAI Platform 创建，需要绑定支付方式。
   • OpenRouter API Key：前往 OpenRouter 注册获取。这是一个聚合平台，可以调用Claude、GPT、Gemini等多种模型，适合想一站式体验的用户。
   • 本地Ollama：如果你希望完全离线、数据不出本地，需要在机器上安装并运行 Ollama ，然后拉取如llama3.2、qwen2.5等模型。这不需要API Key，但需要较强的本地算力。

3.2 使用Docker Compose一键部署（推荐）

这是最省心的方法，适合绝大多数用户。

步骤一：获取项目代码打开终端，执行以下命令克隆仓库并进入目录：

git clone https://github.com/AsyncFuncAI/deepwiki-open.git cd deepwiki-open

步骤二：配置环境变量文件在项目根目录下，创建一个名为.env的文件。这个文件包含了所有敏感的API密钥和配置。你可以用任何文本编辑器创建它。

一个最基础的、使用Google Gemini的配置示例如下：

# 你的Google Gemini API密钥（必需，用于生成文档） GOOGLE_API_KEY=your_actual_google_api_key_here # 嵌入模型类型：openai, google, ollama。这里我们选择google，与生成模型保持一致。 DEEPWIKI_EMBEDDER_TYPE=google # （可选）如果你想使用OpenAI或OpenRouter，取消注释并填写下面几行 # OPENAI_API_KEY=your_openai_key # OPENROUTER_API_KEY=your_openrouter_key # （可选）API服务器端口，一般不用改 PORT=8001 # （可选）前端访问后端的地址，如果部署在同一台机器，默认即可 SERVER_BASE_URL=http://localhost:8001

重要提示：安全第一.env文件包含了你的核心密钥，绝对不要将其提交到Git或其他版本控制系统。项目根目录下的.gitignore文件已经默认忽略了.env，但你在操作时仍需格外小心。在服务器上，建议将该文件的权限设置为仅所有者可读（chmod 600 .env）。

步骤三：启动服务在终端中，确保位于deepwiki-open目录下，然后运行一个简单的命令：

docker-compose up -d

这个-d参数代表“后台运行”。Docker Compose会读取当前目录下的docker-compose.yml文件，自动拉取镜像、创建网络和卷，并启动所有定义的服务（前端和后端）。

步骤四：验证服务启动完成后，你可以通过以下命令查看容器运行状态：

docker-compose ps

你应该能看到两个服务deepwiki-open-api和deepwiki-open-frontend的状态都是Up。

现在，打开你的浏览器，访问http://你的服务器IP:3000（如果是本地部署，就是http://localhost:3000）。你应该能看到DeepWiki的简洁主页。

步骤五：数据持久化说明在docker-compose.yml中，有一行关键的配置：

volumes: - ~/.adalflow:/root/.adalflow

这行配置将你宿主机（你的电脑或服务器）上的~/.adalflow目录，映射到了容器内部的/root/.adalflow目录。DeepWiki会将所有生成的数据存储在这里：

• ~/.adalflow/repos/：克隆的Git仓库原始文件。
• ~/.adalflow/databases/：生成的向量数据库（ChromaDB数据）。
• ~/.adalflow/wikicache/：生成的Wiki页面缓存。

这意味着，即使你删除了容器（docker-compose down），这些数据依然保留在宿主机上。下次启动时，如果分析同一个仓库，系统可以直接读取缓存和索引，速度会快很多。这也是为什么推荐使用Docker Compose部署的原因之一——数据管理非常清晰。

3.3 手动部署（适合深度定制开发者）

如果你需要对代码进行修改，或者想更清晰地了解前后端如何协作，手动部署是更好的选择。这需要你的本地环境有Python和Node.js。

后端API部署：

1. 进入api目录，使用Poetry安装Python依赖（Poetry是一个现代的Python包管理工具，比pip更优）。

   cd api # 确保已安装poetry，如果没有：pip install poetry poetry install

   这个过程会创建一个虚拟环境并安装所有依赖。如果遇到系统依赖问题（比如某些Python包需要编译），你可能需要根据错误提示安装系统级的开发工具（如gcc,python3-dev）。

2. 在项目根目录（deepwiki-open/）配置好.env文件（同上一步）。

3. 启动后端服务器：

   # 在api目录下 poetry run python -m main # 或者激活虚拟环境后运行 poetry shell python -m main

   后端服务默认会在http://localhost:8001启动。你可以在浏览器访问http://localhost:8001/docs查看自动生成的交互式API文档（Swagger UI）。

前端Web应用部署：

1. 打开一个新的终端窗口，进入项目根目录。
2. 安装Node.js依赖（项目使用npm或yarn均可）：

   npm install # 或 yarn install

3. 启动前端开发服务器：

   npm run dev # 或 yarn dev

   前端服务默认在http://localhost:3000启动。它会自动代理API请求到http://localhost:8001（这个配置在next.config.js中）。

现在，你可以同时访问前端（localhost:3000）和后端API文档（localhost:8001/docs）了。

4. 核心功能实战：生成你的第一个项目Wiki

服务跑起来后，我们来看看怎么用它真正解决实际问题。我将以一个中等复杂度的开源项目为例，演示完整流程。

4.1 分析一个公开仓库

假设我想快速理解项目facebookresearch/faiss（一个高效的相似性搜索库）。

1. 输入仓库地址：在DeepWiki主页的输入框，粘贴https://github.com/facebookresearch/faiss。

2. 点击生成：直接点击“Generate Wiki”按钮。对于公开仓库，不需要任何令牌。

3. 观察过程：页面会进入一个实时日志界面。你会看到系统在后台执行一系列步骤：

   • Cloning repository...->Repository cloned successfully.
   • Analyzing repository structure...->Found X Python files, Y C++ files...
   • Creating embeddings...->Embeddings created and stored.
   • Generating documentation...-> 这里会开始流式输出生成的文档内容。
   • Generating diagrams...-> 生成Mermaid图表。
   • Organizing into wiki...-> 最终整合。

4. 浏览结果：生成完成后，页面会自动跳转到生成的Wiki界面。左侧是清晰的导航栏，通常包括：

   • 项目概览：项目简介、核心功能、快速开始指南。
   • 架构设计：包含自动生成的Mermaid架构图，展示模块间的依赖关系。
   • 核心模块详解：对Index、IndexIVF等核心类进行详细说明，包括其作用、关键方法和属性。
   • API参考：从代码中提取出的重要函数签名和说明。
   • 示例代码：从项目测试或示例目录中提炼的使用片段。
   • 构建与测试：项目的编译、安装和测试方法。

整个过程大约需要2-10分钟，取决于仓库大小和网络速度。生成的结果虽然可能不及人工编写的Wiki那么完美和深入，但它提供了一个极其出色的起点和全局视图，能让你在几分钟内抓住项目精髓，效率提升十倍不止。

4.2 处理私有仓库与访问令牌

对于公司内部的GitLab或私有的GitHub仓库，操作略有不同。

1. 生成访问令牌：

   • GitHub：进入 Settings -> Developer settings -> Personal access tokens -> Tokens (classic)，生成一个Token，至少需要勾选repo（完全控制私有仓库）权限。
   • GitLab：进入 User Settings -> Access Tokens，生成一个Token，权限需要read_repository。

2. 在DeepWiki中添加令牌：在主页输入仓库URL（如https://github.com/your-company/private-repo）后，下方会出现一个“+ Add access tokens”的按钮。点击它，会弹出一个表单让你输入平台（GitHub/GitLab）和对应的Token。

3. 安全存储：DeepWiki会将你添加的Token加密后存储在浏览器的本地存储（LocalStorage）中，仅用于本次浏览器会话向你的API后端发送请求。Token不会发送到除你指定仓库和API后端之外的任何第三方服务器。这是一个相对安全的设计，但请务必在你个人的、安全的设备上操作。

注意事项：令牌权限与安全为DeepWiki创建的令牌，权限应遵循“最小权限原则”。对于GitHub，repo权限范围很大。如果可能，可以创建一个仅具有public_repo（如果你只分析公开库）或更细粒度权限的Token。分析完成后，可以在GitHub/GitLab设置中立即吊销（Revoke）该Token。虽然DeepWiki前端将Token存在本地，但后端在克隆仓库时需要使用它。确保你部署的DeepWiki后端（localhost:8001）是可信的，且运行在你的可控环境中。

4.3 使用“Ask”功能进行智能问答

这是DeepWiki的“杀手级”功能。生成了Wiki之后，你可以像与一个熟悉该代码库的同事聊天一样提问。

1. 在Wiki页面找到Ask侧边栏：通常在页面右侧或有一个浮动按钮。
2. 输入你的问题：问题可以非常具体。例如，在分析FAISS后，你可以问：
   • “这个库是如何对高维向量进行量化的？”
   • “IndexIVFFlat和IndexFlatL2的主要区别是什么？分别在什么场景下使用？”
   • “请给我一个使用GPU进行搜索的示例代码。”
3. 观察RAG过程：系统不是凭空想象。在回答前，它会先在后台执行“检索”动作，从向量数据库中找出与问题最相关的代码片段（例如IndexIVF.cpp中的量化代码，或示例文件中的GPU代码），然后将这些片段作为上下文与你的问题一起提交给LLM。回答是流式输出的，体验很好。
4. 利用对话历史：你可以进行多轮对话。例如，先问“什么是乘积量化？”，接着基于它的回答追问“在这个项目中，乘积量化是在哪个类里实现的？”。系统会保持对话上下文，使问答更连贯。

4.4 启用“DeepResearch”进行深度探索

对于更复杂、开放性的问题，可以打开“DeepResearch”开关。比如，你可以问：“Faiss库为了提升搜索效率，采用了哪些主要的优化策略？请详细分析其实现原理和 trade-off。”

开启DeepResearch后，系统会：

1. 制定研究计划：首先输出一个计划，比如“我将从索引结构、量化方法、并行计算和内存优化四个方面进行研究”。
2. 进行多轮迭代：它会自动进行最多5轮的研究。每一轮，它都会基于上一轮的发现，提出更深入的问题去检索代码，例如“第一轮：研究Index基类的设计。第二轮：研究ProductQuantizer类的实现...”。
3. 输出最终结论：最后，它会汇总所有轮次的研究成果，生成一份结构完整、引用了具体代码文件的详细报告。这相当于让AI帮你做了一次深度的代码阅读和总结。

5. 高级配置与模型调优指南

DeepWiki的强大之处在于其高度的可配置性。你可以根据需求，精细调整其行为。

5.1 模型提供者（Provider）的选择与配置

项目支持多种LLM，通过api/config/generator.json文件进行配置。你可以直接编辑这个文件，或者通过环境变量来影响模型选择。

通过前端界面选择：在主页输入仓库URL的下方，通常会有模型选择下拉框。你可以在这里快速切换不同的Provider和模型，例如从“Google Gemini”切换到“OpenAI GPT-4”。

深入配置文件：如果你想修改默认模型或添加自定义模型，可以查看api/config/generator.json。它的结构大致如下：

{ "providers": { "google": { "class": "GoogleProvider", "default_model": "gemini-2.0-flash-exp", "available_models": ["gemini-2.0-flash-exp", "gemini-2.0-pro-exp"] }, "openai": { "class": "OpenAIProvider", "default_model": "gpt-4o-mini", "available_models": ["gpt-4o", "gpt-4o-mini", "o1-preview"] } // ... 其他provider } }

• 修改默认模型：如果你觉得gemini-2.0-flash-exp太快但质量稍逊，可以将其default_model改为gemini-2.0-pro-exp。
• 添加自定义模型：对于OpenRouter或Azure OpenAI，你可以在available_models列表中添加特定的模型ID。例如，在OpenRouter下添加"anthropic/claude-3.5-sonnet"。

环境变量覆盖：一些关键参数可以通过环境变量设置，优先级更高。例如，设置OPENAI_BASE_URL=https://your-custom-endpoint.com/v1可以让OpenAI Provider指向你自己的代理或兼容API。

5.2 嵌入模型（Embedder）的选择

嵌入模型的选择直接影响检索质量，进而影响问答和文档生成的准确性。DeepWiki支持三种类型：

1. OpenAI Embeddings (text-embedding-3-small)：默认选项。效果稳定，通用性强，但需要OpenAI API Key，且数据会发送到OpenAI。
2. Google AI Embeddings (text-embedding-004)：如果你主要使用Google Gemini生成内容，强烈推荐使用此选项。同一家的嵌入和生成模型在语义空间上通常更对齐，可能获得更好的效果。只需在.env中设置DEEPWIKI_EMBEDDER_TYPE=google。
3. Ollama Embeddings (如nomic-embed-text)：完全本地运行，数据不出境，隐私性最高。你需要先在本地Ollama中拉取一个嵌入模型，如ollama pull nomic-embed-text，然后在.env中设置DEEPWIKI_EMBEDDER_TYPE=ollama。缺点是速度可能较慢，且效果取决于所选模型。

实操心得：嵌入模型切换与重建索引切换嵌入模型后，之前为仓库生成的向量索引将失效。因为不同模型产生的向量空间不同，无法直接混合检索。你需要手动删除~/.adalflow/databases/目录下对应仓库的文件夹，然后重新生成Wiki，以使用新的嵌入模型创建索引。这是一个重要的维护点。

5.3 使用本地Ollama实现完全私有化

对于有严格数据保密要求的场景，可以搭建一个完全离线的DeepWiki。

1. 安装并启动Ollama：按照 Ollama官网 指引，下载并安装。然后拉取你需要的模型：

   ollama pull llama3.2:latest # 用于文本生成 ollama pull nomic-embed-text:latest # 用于嵌入

2. 配置DeepWiki：在.env文件中进行如下配置：

   # 不需要任何在线API Key DEEPWIKI_EMBEDDER_TYPE=ollama # 确保Ollama在默认地址运行 OLLAMA_HOST=http://localhost:11434

   同时，你需要修改generator.json，将默认的Provider改为ollama，或者确保在前端界面可以选择Ollama模型。
3. 性能考量：本地运行LLM对硬件要求较高。生成文档（尤其是大型仓库）可能非常慢，且需要大量内存（例如，运行7B参数的模型可能需要8GB以上空闲内存）。建议从较小的模型（如llama3.2:3b）开始尝试。嵌入任务通常对算力要求较低。

5.4 授权模式与访问控制

如果你将DeepWiki部署在内网，并希望限制使用权限，可以启用授权模式。

1. 启用授权：在.env文件中设置：

   DEEPWIKI_AUTH_MODE=true DEEPWIKI_AUTH_CODE=your_secret_password_here

2. 前端验证：启用后，前端主页会出现一个输入框，要求输入授权码。只有输入正确的DEEPWIKI_AUTH_CODE后，“Generate Wiki”按钮才会激活。
3. 重要提醒：这个授权模式主要是一个前端控制措施。它阻止了未授权用户通过Web界面触发生成任务。但是，知道API地址（http://your-server:8001）的人仍然可以直接调用后端接口。因此，它不是一个严格的安全屏障。对于生产环境，你应该在DeepWiki前面配置反向代理（如Nginx），并设置更完善的认证（如HTTP Basic Auth, OAuth）和网络防火墙规则。

6. 常见问题排查与性能优化

在实际使用中，你可能会遇到一些问题。这里我总结了一些常见坑点和解决方案。

6.1 部署与启动问题

6.2 仓库处理与生成问题

6.3 性能优化建议

1. 缓存利用：DeepWiki会缓存生成的Wiki内容。如果你重复分析同一个仓库的同一个提交，它会直接读取缓存，速度极快。因此，对于稳定版本的项目，第一次生成后即可享受快速的查看体验。
2. 模型选择策略：
   • 速度优先：文档生成使用gemini-2.0-flash-exp或gpt-4o-mini，嵌入使用text-embedding-3-small。
   • 质量优先：文档生成使用gemini-2.0-pro-exp、gpt-4o或claude-3.5-sonnet，嵌入使用text-embedding-3-large或text-embedding-004。
   • 成本优先：使用OpenRouter上的小型开源模型，或本地Ollama。
3. 硬件资源配置：如果使用Docker，可以通过docker-compose.yml中的deploy.resources.limits为容器分配更多的CPU和内存资源，尤其是在处理大型仓库时。
4. 定期清理：~/.adalflow目录会随着时间增长。可以定期清理不再需要的仓库缓存（删除~/.adalflow/repos/和~/.adalflow/databases/下的对应文件夹）以释放磁盘空间。

7. 项目维护、自定义与扩展

DeepWiki-Open是一个开源项目，你可以根据自己的需求对其进行修改和扩展。

7.1 理解项目结构进行自定义

项目的代码结构非常清晰：

• api/：所有后端逻辑。rag.py是RAG链的核心，data_pipeline.py处理代码解析和清洗，providers/目录下是各个模型提供者的实现。
• src/：Next.js前端应用。app/page.tsx是主页面，components/里是React组件。
• api/config/：关键配置文件。修改generator.json,embedder.json,repo.json可以分别调整模型行为、嵌入参数和仓库处理规则。

常见的自定义场景：

• 修改文件忽略规则：编辑api/config/repo.json中的ignore_patterns，添加你不想分析的特定文件模式，例如*.min.js,*.log,dist/等。
• 调整文本分块策略：在api/config/embedder.json中，修改chunk_size（块大小）和chunk_overlap（重叠大小）。对于代码，较小的块（如512 tokens）和一定的重叠（如100 tokens）有助于提高检索精度。
• 添加新的AI提供商：参考api/providers/下的现有类（如openai.py），实现一个新的Provider类，主要完成generate_text方法。然后在api/config/generator.json中注册它。

7.2 日志与调试

当遇到问题时，查看日志是首要的排查手段。

在Docker Compose中查看日志：

# 查看所有服务的日志 docker-compose logs # 仅查看后端API服务的日志 docker-compose logs api # 实时跟踪日志输出 docker-compose logs -f api

调整日志级别：在.env中设置LOG_LEVEL=DEBUG，可以输出最详细的日志信息，有助于定位复杂问题。生产环境中建议设置为INFO或WARNING。

7.3 参与贡献与社区

如果你发现了Bug，或者有很棒的新功能想法，可以到项目的GitHub仓库提交Issue或Pull Request。在提交前，建议：

1. 在本地充分测试你的修改。
2. 确保代码风格与项目现有代码保持一致。
3. 更新相关的文档（如README）。

项目采用MIT许可证，意味着你可以在遵守许可条款的前提下自由地使用、修改和分发。