前言
项目：github.com/AsyncFuncAI…（源自b站关注的一个up的周报）
测试网址：deepwiki.com/
使用：将github地址贴进去就可以自动生成文档和对话了，而且里面已经有很多知名的项目的文档了，可以直接对话。
于是我来了个套娃，用它的测试网站来分析它自己的开源项目，短短几个问题，就可以快速了解deepwiki-open的作用。
Q1：怎么快速使用
您询问的是如何快速使用 DeepWiki 系统。根据代码库中的文档，DeepWiki 是一个自动为 GitHub、GitLab 或 Bitbucket 仓库生成交互式 wiki 的工具。
快速开始方法
方法一：使用 Docker（推荐） 1
- 克隆仓库并创建
.env文件配置 API 密钥 - 运行
docker-compose up启动服务
方法二：手动安装 2
需要三个步骤：
- 配置 API 密钥：创建包含 Google API 和 OpenAI API 密钥的
.env文件 - 启动后端：安装 Python 依赖并运行
python -m api.main - 启动前端：安装 JavaScript 依赖并运行
npm run dev
使用方式
启动后访问 http://localhost:3000，您可以： 3
- 在输入框中输入仓库 URL（支持 GitHub、GitLab、Bitbucket）
- 对于私有仓库，点击"+ Add access tokens"添加访问令牌
- 点击"Generate Wiki"生成 wiki 4
系统支持多种仓库格式，包括完整 URL 和简化的 owner/repo 格式。
API 密钥获取 5
- Google API 密钥：从 Google AI Studio 获取
- OpenAI API 密钥：从 OpenAI Platform 获取
Notes
DeepWiki 使用 AI 技术分析代码结构、生成文档和创建可视化图表。所有数据都存储在本地（~/.adalflow/ 目录），无需云存储依赖。系统还提供 Ask 功能，允许您通过 RAG 技术与仓库进行智能问答。
Wiki pages you might want to explore:
Q2：具体对于人们来说，这个项目有什么应用场景
您询问的是 DeepWiki 项目对人们的具体应用场景。根据代码库分析，DeepWiki 是一个自动为代码仓库生成交互式文档的 AI 工具，主要有以下应用场景：
开发团队协作场景
新成员快速上手 1
当新开发者加入项目时，DeepWiki 可以自动分析代码结构并生成全面的文档，帮助他们快速理解项目架构和工作流程。
代码审查和知识传承 2
系统能够智能分析代码关系，生成可视化图表，便于团队进行代码审查和知识传承。
项目管理场景
技术文档自动化 3
DeepWiki 使用 AI 技术自动生成文档，减少手动维护文档的工作量，确保文档与代码同步。
多平台仓库支持 4
支持 GitHub、GitLab、Bitbucket 等多个平台，适用于不同的开发环境。
学习和研究场景
开源项目理解 5
研究人员和学习者可以输入任何公开仓库，快速生成结构化的项目说明，便于理解复杂的开源项目。
智能问答功能 6
Ask 功能允许用户与仓库进行智能对话，基于 RAG 技术提供准确的代码相关答案。
深度研究能力 7
DeepResearch 功能提供多轮研究过程，适合深入分析复杂技术问题。
企业应用场景
私有仓库文档化 8
支持私有仓库访问，企业可以为内部项目生成文档，提高开发效率。
本地化部署 9
所有数据本地存储，无云依赖，满足企业数据安全要求。
Notes
DeepWiki 的核心价值在于将复杂的代码分析和文档生成过程自动化，通过 AI 技术降低了理解和维护代码的门槛。无论是个人学习、团队协作还是企业级应用，都能显著提高开发效率和代码可维护性。
Wiki pages you might want to explore:
- System Architecture (AsyncFuncAI/deepwiki-open)
- Backend API Architecture (AsyncFuncAI/deepwiki-open)
Q3：它使用的RAG技术，向量数据库使用的是哪一个，是否数据存储在本地
您询问的是 DeepWiki 使用的 RAG 技术中的向量数据库类型以及数据存储位置。
向量数据库技术
DeepWiki 使用 FAISS (Facebook AI Similarity Search) 作为向量数据库。这在多个地方得到确认： 1
在 RAG 系统的初始化中，系统创建 FAISSRetriever 来处理向量检索： 2
数据存储位置
所有数据都存储在本地，无需云存储依赖。具体存储路径如下：
仓库文件存储 3
克隆的仓库存储在 ~/.adalflow/repos/{repo_name} 目录下。
向量数据库存储 4
FAISS 向量数据库以 .pkl 格式存储在 ~/.adalflow/databases/{repo_name}.pkl 路径下。
RAG 工作流程
系统的 RAG 实现包含以下步骤：
本地存储优势 8
这种本地存储设计确保了：
- 数据隐私和安全
- 无需云服务依赖
- 离线工作能力
- 更快的访问速度
Notes
DeepWiki 的 RAG 系统完全基于本地技术栈，使用 FAISS 作为向量数据库，所有数据（包括克隆的仓库和生成的嵌入向量）都存储在用户本地的 ~/.adalflow/ 目录中，确保了数据安全和系统的独立性。
Wiki pages you might want to explore:
- System Architecture (AsyncFuncAI/deepwiki-open)
- Backend API Architecture (AsyncFuncAI/deepwiki-open)
- Data Flow (AsyncFuncAI/deepwiki-open)
Q4：为什么要配置谷歌和openai的key，如果是私有仓库，确保数据安全的情况下，应该如何让这个项目为实际工作赋能？
您询问的是为什么需要配置 Google 和 OpenAI 的 API 密钥，以及如何在确保私有仓库数据安全的情况下让这个项目为实际工作赋能。
为什么需要配置两个 API 密钥
DeepWiki 使用两个不同的 AI 服务来实现其核心功能：
Google API 密钥的用途 1
Google Gemini API 主要用于文本生成，包括生成文档内容、回答用户问题和创建 wiki 结构。
OpenAI API 密钥的用途 2
OpenAI API 专门用于创建嵌入向量，使用 text-embedding-3-small 模型将代码文件转换为向量，用于 RAG 系统的相似性搜索。
数据安全保障
DeepWiki 在数据安全方面有以下保障：
本地存储架构 3
所有数据都存储在本地，包括：
私有仓库支持 6
系统支持通过个人访问令牌安全访问私有仓库，令牌仅用于克隆仓库，不会发送给第三方服务。
为实际工作赋能的建议
1. 本地部署方案
使用 Docker 进行完全本地化部署： 7
这确保了整个系统在企业内网运行，代码不会离开本地环境。
2. 替代方案考虑
系统还支持本地 Ollama 模型： 8
这可以进一步减少对外部 API 的依赖，但需要本地部署大语言模型。
3. 企业级应用场景
- 内部文档自动化：为企业内部项目自动生成技术文档
- 代码审查辅助：通过 Ask 功能快速理解复杂代码逻辑
- 新员工培训：快速生成项目概览和架构说明
- 技术债务分析：使用 DeepResearch 功能深入分析代码问题
Notes
虽然需要外部 API 密钥，但 DeepWiki 的设计确保了代码内容仅用于生成嵌入和文档，不会被存储在云端。对于高度敏感的企业环境，可以考虑使用本地 Ollama 模型或在隔离网络中部署，以实现完全的数据控制。
Wiki pages you might want to explore:
- System Architecture (AsyncFuncAI/deepwiki-open)
- Backend API Architecture (AsyncFuncAI/deepwiki-open)
Q5：google gemini和openai的embeding-3是最好的选择吗，如果是本地部署Ollama，有什么好的开源模型推荐
您询问的是关于 DeepWiki 中 AI 模型选择的问题，具体是 Google Gemini 和 OpenAI embedding-3 是否是最佳选择，以及本地部署 Ollama 时的开源模型推荐。
当前模型配置分析
Google Gemini 用于文本生成 1
系统使用 gemini-2.5-flash-preview-04-17 作为主要的文本生成模型，负责生成文档内容和回答用户问题。
OpenAI Embedding-3 用于向量化 2
使用 text-embedding-3-small 模型创建 256 维的嵌入向量，用于 RAG 系统的语义搜索。
本地 Ollama 替代方案
DeepWiki 已经内置了对本地 Ollama 模型的支持：
嵌入模型配置 3
系统配置了 nomic-embed-text 作为本地嵌入模型。
生成模型配置 4
使用 qwen3:1.7b 作为本地文本生成模型。
推荐的开源模型
基于代码中的配置和实际应用需求，推荐以下开源模型：
嵌入模型推荐
- nomic-embed-text（已配置）- 专为代码和文档设计的高质量嵌入模型
- all-MiniLM-L6-v2 - 轻量级但效果良好的通用嵌入模型
- bge-large-en-v1.5 - 中文和英文都表现优秀的嵌入模型
生成模型推荐
- qwen2.5:7b - 比当前配置的 1.7b 版本更强大
- llama3.1:8b - Meta 的开源模型，代码理解能力强
- codellama:7b - 专门为代码任务优化的模型
- deepseek-coder:6.7b - 在代码生成和理解方面表现出色
模型选择考虑因素
性能 vs 资源消耗
- 1.7b 模型：资源消耗低，适合个人开发环境
- 7b-8b 模型：平衡性能和资源消耗，适合团队使用
- 更大模型：性能更好但需要更多 GPU 内存
代码理解能力
专门的代码模型（如 CodeLlama、DeepSeek-Coder）在理解代码结构和生成技术文档方面通常表现更好。
实际部署建议
对于企业级部署，建议：
- 使用 nomic-embed-text 作为嵌入模型（已配置）
- 根据硬件资源选择 qwen2.5:7b 或 deepseek-coder:6.7b 作为生成模型
- 在隔离环境中部署 Ollama 服务，确保数据安全
Notes
当前的模型配置已经考虑了性能和资源的平衡。如果您有更强的硬件资源，升级到 7b 或更大的模型会显著提升文档生成质量。对于中文内容处理，Qwen 系列模型表现更佳。
Wiki pages you might want to explore:
