基于RAG与向量数据库构建GitHub代码库智能问答助手 1. 项目概述从“能用”到“会改”的智能助手进阶之路最近在GitHub上泡着发现一个挺有意思的现象很多朋友在遇到项目报错、依赖冲突或者配置问题时第一反应是去搜索引擎或者社区提问。这个过程其实挺耗时的你得组织语言、截图、等待回复运气不好可能半天都解决不了。与此同时AI大模型的能力大家有目共睹尤其是代码理解和生成方面已经相当成熟。于是我就琢磨能不能把这两件事结合起来与其让AI大模型去生成一个全新的、可能不靠谱的代码片段不如让它来深度理解我们手头已有的、正在运行的代码仓库——也就是GitHub项目然后针对这个具体项目进行精准答疑。这就是“打造专属GitHub智能答疑助手”这个想法的来源。它不是一个通用的聊天机器人而是一个深度绑定到你指定GitHub仓库的“专属顾问”。你只需要把仓库链接给它它就能基于整个项目的源码、README、issues甚至commit历史来回答你关于这个项目的任何技术问题。比如“这个docker-compose.yml里第三行的环境变量是干嘛用的”、“我想给这个项目加个新功能应该从哪个文件开始看”、“昨天更新的这个PR引入了什么破坏性变更吗”。它的目标不是替代搜索引擎而是成为你深入理解和参与某个特定开源项目的“第二大脑”。这个项目适合谁呢首先肯定是开源项目的贡献者和维护者尤其是刚接手一个复杂项目的新人它能帮你快速理清脉络。其次是学习者你想深入学习某个知名项目的架构设计它可以作为你的互动式教程。最后哪怕是项目的普通用户遇到部署或使用问题也能通过它获得比通用AI更精准的解答。核心价值就在于“专属”和“深度”将大模型的泛化能力通过工程化的手段聚焦到单一代码库的上下文中实现质变。2. 核心设计思路让大模型“读懂”你的代码库要实现一个能对特定GitHub仓库进行智能答疑的助手光靠把仓库链接扔给大模型是远远不够的。大模型有上下文长度限制不可能一次性塞入整个仓库的所有代码。因此核心设计思路围绕着“如何高效地为大模型准备最相关的上下文”展开。整个系统的架构可以分解为几个关键环节仓库获取与解析、代码索引与检索、问题理解与上下文组装、以及最终的答案生成与溯源。2.1 仓库获取与解析不只是git clone第一步是获取目标仓库的数据。最直接的方式当然是使用git clone。但在生产环境中我们需要考虑更多认证与权限对于私有仓库需要集成GitHub API并使用Personal Access Token或OAuth App进行认证。这里推荐使用PyGithub或官方的Octokit库它们封装了API的复杂细节。增量更新一个活跃的仓库每天都在更新。我们的助手不应该每次问答都全量克隆。理想的做法是首次全量克隆后续通过git pull或监听GitHub的Webhook事件进行增量同步。解析范围我们不仅要代码文件.py,.js,.java等还需要非代码但富含信息的文件如README.md,CONTRIBUTING.md,docs/目录下的文档、Dockerfile、docker-compose.yml、.env.example等配置文件。同时issues和pull requests里的讨论往往包含了关键的问题背景和解决方案思路价值极高。实操心得在解析时建议忽略一些无关紧要的文件比如node_modules/,__pycache__/,.git/, 以及图片等二进制文件。可以建立一个.gitignore风格的忽略列表提升处理效率。对于超大型仓库如Linux内核可能需要采用分层或按需加载的策略。2.2 代码索引与检索构建项目的“记忆中枢”这是整个系统的核心。我们不能在每次提问时都让大模型去“阅读”所有文件必须建立一个高效的检索系统能根据问题快速找到最相关的代码片段和文档。文本分块Chunking将每个文件的内容切割成大小适中的片段。切割策略至关重要按语义分割对于源代码最好能按函数、类或逻辑块进行切割保持代码的完整性。对于Markdown文档可以按章节或段落分割。重叠窗口在块与块之间保留少量重叠文本例如50-100个字符防止关键信息如函数定义被割裂在两个块的边缘。元数据附加为每个文本块附加元数据如源文件路径、在文件中的起止行号、所属的模块/类名等。这些元数据对于后续的答案溯源至关重要。向量化与嵌入Embedding使用嵌入模型如text-embedding-ada-002,BGE,M3E等将每个文本块转换为一个高维向量即嵌入向量。这个向量在数学上表征了该文本块的语义信息。语义相近的文本其向量在空间中的距离也更近。向量数据库存储将所有文本块的向量及其对应的元数据原始文本、文件路径、行号存入一个向量数据库。常用的有ChromaDB轻量、易用、Pinecone云服务、高性能、Qdrant开源、功能全、Weaviate开源、带图数据库特性。向量数据库的核心能力是“近似最近邻搜索ANN”能快速从海量向量中找到与问题向量最相似的几个向量。为什么是向量检索而不是关键词匹配假设你问“这个项目如何处理用户上传的图片” 关键词匹配可能会找到所有包含“图片”、“上传”、“处理”的文件但可能漏掉那些用了“图像”、“file”、“storage”等同义词但逻辑相关的代码。而向量检索基于语义即使没有完全相同的词汇也能找到语义相关的代码片段比如一段关于“AWS S3存储桶配置”和“图片缩略图生成”的代码。2.3 问题理解与上下文组装提出一个好问题当用户提出一个问题时系统并不是直接拿原始问题去检索。问题重写与扩展首先大模型或一个轻量级模型可以对原始问题进行润色和扩展。例如用户问“为啥报错”系统可以结合当前对话历史或仓库的通用技术栈将其重写为“请解释在运行本项目时可能遇到的常见错误及其解决方法”。这能显著提升检索质量。检索相关上下文将优化后的问题文本同样转化为向量在向量数据库中进行相似性搜索召回Top-K个例如5-10个最相关的文本块。上下文组装将检索到的文本块按照相关性排序并附上它们的元数据来源文件行号组合成一个长的“上下文字符串”。同时一些全局信息如项目的README摘要、核心依赖列表从requirements.txt或package.json解析也可以作为固定前缀加入上下文帮助大模型建立整体认知。2.4 答案生成与溯源可信的回答最后将“组装好的上下文”和“用户的问题”一起构造成一个提示词Prompt发送给大语言模型如GPT-4、Claude 3、或开源的Llama 3、Qwen等来生成最终答案。提示词的设计是艺术也是科学一个基本的模板如下你是一个资深的软件开发专家专门负责为以下GitHub仓库提供技术支持。 请严格根据提供的上下文信息来回答问题。如果上下文信息不足以回答请如实告知不要编造信息。 ## 项目仓库上下文 {这里插入检索到的相关代码块和文档每个块标明来源} ## 用户问题 {用户的问题} ## 你的回答模型基于这个强约束的提示词生成答案。在返回答案时必须同时返回答案中每一处结论所引用的源代码位置文件路径和行号。这既是可解释性的要求也方便用户快速跳转到源码进行验证极大增强了答案的可信度。3. 技术栈选型与工具解析实现这样一个系统技术选型上有很多组合。这里我基于稳定性、社区生态和开发效率推荐一套经过实践验证的方案。3.1 后端核心框架LangChain与LlamaIndex的抉择这两个是目前最流行的AI应用框架都能极大简化我们上面描述的流程。LangChain更像一个“乐高工具箱”提供了极其丰富的组件Models, Prompts, Indexes, Chains, Agents等灵活性极高。你可以用它的DocumentLoaders加载GitHub仓库用TextSplitters分割文本用VectorStore接口连接各种向量数据库再用RetrievalQA链把检索和生成串起来。它的学习曲线稍陡但当你需要实现复杂、定制化的逻辑时LangChain的能力更强。LlamaIndex现更名为GPTIndex它更专注于“数据索引和检索”这一件事并将其做到了极致。它抽象出了Index、Retriever、QueryEngine等核心概念对于构建检索增强生成RAG应用来说API更加直观和专注。如果你想要快速搭建一个基于文档问答的系统LlamaIndex通常是更直接的选择。我的选择与理由对于这个GitHub答疑助手项目我倾向于使用LlamaIndex。因为我们的核心就是一个高质量的RAG系统LlamaIndex的抽象与我们的需求高度吻合。它的GitHubRepositoryReader可以方便地拉取仓库内容内置的SentenceSplitter和TokenTextSplitter能很好地处理代码分割与ChromaDB、Qdrant等向量库的集成也很顺畅。代码写起来更简洁心智负担更小。3.2 嵌入模型与向量数据库平衡效果、速度与成本嵌入模型Embedding Model云端API如OpenAI的text-embedding-3-small/large。效果稳定使用简单但会产生持续费用且数据需要出境可能涉及合规问题。本地开源模型如BAAI/bge-large-zh中文效果好、thenlper/gte-large、intfloat/multilingual-e5-large。需要本地GPU或CPU推理初期部署稍复杂但数据隐私有保障长期成本低。使用SentenceTransformers库可以轻松调用这些模型。选型建议如果项目涉及公司内部或敏感代码必须选择本地模型。对于公开的开源项目可以权衡速度和成本。实测中bge-base模型在CPU上也能有不错的速度和效果是很好的起点。向量数据库Vector DatabaseChromaDB轻量级嵌入式可以直接集成在Python应用中无需单独部署服务器。非常适合原型开发、小规模项目或对延迟敏感的场景。它的持久化能力也在不断增强。Qdrant性能强劲功能丰富支持过滤、分片、复制提供Docker镜像部署简单。适合生产环境尤其是数据量较大或需要复杂查询过滤的情况。选型建议从快速验证想法的角度首选ChromaDB。几行代码就能集成进你的Python脚本整个索引可以保存在本地一个目录里。当项目需要服务多个用户、索引成千上万个仓库时再考虑迁移到Qdrant或Weaviate这类更健壮的系统。3.3 大语言模型云端巨兽与本地猛禽云端模型GPT-4, Claude 3, DeepSeek在代码理解、逻辑推理和生成质量上通常表现最佳尤其是GPT-4。API调用方便但成本高、有速率限制、且回答延迟受网络影响。本地模型Llama 3, Qwen 1.5/2.5, DeepSeek Coder通过Ollama、vLLM或Transformers库部署在自有服务器上。数据完全私有无使用费用响应延迟稳定。当前顶尖的70B参数模型在代码任务上已接近GPT-3.5 Turbo的水平7B/8B的模型经过量化后甚至可以在消费级显卡或MacBook上流畅运行。选型建议强烈建议从本地模型开始。例如使用Ollama一键拉取并运行qwen2.5:7b或llama3.1:8b模型。这能让你完全掌控流程深入理解模型输入输出的每个环节且没有账单焦虑。在确认核心流程跑通后如果对答案质量有极致要求可以尝试将本地模型作为“默认引擎”同时提供切换至GPT-4 API的选项作为“增强模式”。3.4 前端与部署让助手触手可及前端界面一个简单的Web界面足矣。可以使用Gradio或Streamlit快速搭建。它们都是Python框架能让你用几十行代码就做出一个包含聊天历史、文件上传仓库URL输入、模型选择等组件的交互界面非常适合AI原型展示。部署对于个人使用或小团队可以将整个应用后端逻辑前端打包成一个Docker镜像部署到云服务器或本地NAS上。如果使用Gradio它甚至自带内网分享功能。对于更正式的项目可以考虑使用FastAPI构建RESTful API后端然后开发一个独立的Vue/React前端。4. 分步实现指南从零搭建你的第一个助手下面我将用一个最小化的可行产品MVP示例带你一步步实现核心功能。我们假设使用LlamaIndex ChromaDB Ollama本地Qwen2.5模型这套全本地化的技术栈。4.1 环境准备与依赖安装首先创建一个新的Python虚拟环境并安装核心依赖。# 创建并激活虚拟环境以conda为例 conda create -n github-qa-assistant python3.10 conda activate github-qa-assistant # 安装核心库 pip install llama-index llama-index-llms-ollama llama-index-embeddings-huggingface llama-index-readers-file llama-index-readers-github chromadb sentence-transformers pypdf # 安装Ollama用于运行本地大模型 # 访问 https://ollama.ai/ 下载并安装对应操作系统的Ollama # 安装后在终端拉取一个模型例如Qwen2.5 7B ollama pull qwen2.5:7b4.2 构建GitHub仓库索引接下来我们编写一个脚本用于克隆指定的GitHub仓库并为其创建向量索引。# build_index.py import os from llama_index.core import VectorStoreIndex, Settings from llama_index.core.node_parser import SemanticSplitterNodeParser from llama_index.embeddings.huggingface import HuggingFaceEmbedding from llama_index.llms.ollama import Ollama from llama_index.readers.github import GitHubRepositoryReader from llama_index.vector_stores.chroma import ChromaVectorStore import chromadb from dotenv import load_dotenv # 加载环境变量用于GitHub Token如果需要访问私有库 load_dotenv() github_token os.getenv(GITHUB_TOKEN) # 1. 配置LLM和Embedding模型 # 使用本地Ollama服务的Qwen2.5模型 Settings.llm Ollama(modelqwen2.5:7b, base_urlhttp://localhost:11434, request_timeout120.0) # 使用本地HuggingFace嵌入模型这里选用轻量且效果不错的BGE模型 Settings.embed_model HuggingFaceEmbedding(model_nameBAAI/bge-small-zh-v1.5) # 设置文本分割器对于代码语义分割比简单按字符分割效果好 Settings.text_splitter SemanticSplitterNodeParser.from_defaults() # 2. 初始化ChromaDB向量存储 # 持久化到本地目录 ./chroma_db chroma_client chromadb.PersistentClient(path./chroma_db) chroma_collection chroma_client.get_or_create_collection(namegithub_repo) vector_store ChromaVectorStore(chroma_collectionchroma_collection) # 3. 加载GitHub仓库文档 # 注意首次加载大型仓库可能较慢因为它会克隆仓库。 print(正在加载GitHub仓库文档...) loader GitHubRepositoryReader( github_tokengithub_token, # 如果是公开库可以设为None verboseTrue, ignore_directories[.git, node_modules, __pycache__, dist, build], # 忽略无关目录 ignore_file_extensions[.png, .jpg, .jpeg, .gif, .ico, .pdf] # 忽略二进制文件 ) # 加载指定仓库的文档这里以 llama-index 官方仓库为例 documents loader.load_data( ownerrun-llama, repollama_index, branchmain, # 可以指定只加载某些文件类型 # file_filterlambda file_path: file_path.endswith((.py, .md, .rst, .txt, .yaml, .yml, .json)) ) print(f成功加载 {len(documents)} 个文档片段。) # 4. 创建索引并存储到向量数据库 print(正在构建向量索引...) index VectorStoreIndex.from_documents( documents, vector_storevector_store, show_progressTrue ) print(索引构建完成并已持久化到 ./chroma_db。)运行这个脚本python build_index.py。首次运行会下载嵌入模型并克隆/处理仓库文件需要一些时间。完成后所有向量数据都保存在本地的./chroma_db目录中。4.3 实现问答查询引擎索引建好后我们就可以基于它来回答问题了。# query_engine.py from llama_index.core import VectorStoreIndex, Settings from llama_index.embeddings.huggingface import HuggingFaceEmbedding from llama_index.llms.ollama import Ollama from llama_index.vector_stores.chroma import ChromaVectorStore import chromadb # 配置与构建索引时保持一致 Settings.llm Ollama(modelqwen2.5:7b, base_urlhttp://localhost:11434, request_timeout120.0) Settings.embed_model HuggingFaceEmbedding(model_nameBAAI/bge-small-zh-v1.5) # 加载已有的ChromaDB集合 chroma_client chromadb.PersistentClient(path./chroma_db) chroma_collection chroma_client.get_collection(namegithub_repo) vector_store ChromaVectorStore(chroma_collectionchroma_collection) # 从向量存储加载索引 index VectorStoreIndex.from_vector_store(vector_storevector_store) # 创建查询引擎并启用引用溯源功能 query_engine index.as_query_engine(similarity_top_k5, response_modecompact) # similarity_top_k 控制检索的上下文块数量 # 开始问答循环 print(GitHub仓库智能问答助手已启动输入 quit 退出) while True: question input(\n请输入你的问题: ) if question.lower() quit: break print(思考中...) try: response query_engine.query(question) print(f\n回答: {response.response}) # 打印引用的来源增强可信度 if response.source_nodes: print(\n--- 参考来源 ---) for i, source_node in enumerate(response.source_nodes[:3]): # 显示前3个来源 file_path source_node.metadata.get(file_path, 未知文件) # 可能包含行号信息 print(f{i1}. {file_path}) # 可以打印一小段源码预览 # print(f 预览: {source_node.text[:200]}...) except Exception as e: print(f查询过程中出现错误: {e})运行python query_engine.py就可以在命令行与你的专属助手对话了。它会从之前构建的索引中检索相关信息并调用本地Qwen2.5模型生成答案。4.4 使用Gradio构建Web界面为了让体验更好我们用Gradio快速搭建一个Web UI。# app.py import gradio as gr from query_engine import query_engine # 导入上面写好的查询引擎 def respond(message, history): 处理用户消息并返回助手响应 history history or [] try: response query_engine.query(message) answer response.response # 格式化来源信息 sources if response.source_nodes: sources \n\n**参考来源**\n for i, node in enumerate(response.source_nodes[:3]): file_path node.metadata.get(file_path, N/A) sources f{i1}. {file_path}\n full_response answer sources except Exception as e: full_response f抱歉处理您的请求时出错了: {str(e)} history.append((message, full_response)) return history, history # 创建Gradio界面 with gr.Blocks(titleGitHub智能答疑助手, themegr.themes.Soft()) as demo: gr.Markdown(# GitHub仓库智能答疑助手) gr.Markdown(输入关于已索引仓库的技术问题获取基于源码的精准解答。) chatbot gr.Chatbot(label对话历史, height500) msg gr.Textbox(label您的问题, placeholder例如这个项目是如何处理错误日志的) clear gr.Button(清空对话) def user(user_message, history): return , history [[user_message, None]] def bot(history): user_message history[-1][0] _, updated_history respond(user_message, history[:-1]) # Gradio Chatbot期望的格式是列表的列表每个子列表是[用户消息 助手消息] # 我们这里简单处理将最后一次交互的结果放入history history[-1][1] updated_history[-1][1] if updated_history else 无响应 return history msg.submit(user, [msg, chatbot], [msg, chatbot], queueFalse).then( bot, chatbot, chatbot ) clear.click(lambda: None, None, chatbot, queueFalse) if __name__ __main__: demo.launch(server_name0.0.0.0, server_port7860, shareFalse) # shareTrue可生成临时公网链接运行python app.py打开浏览器访问http://localhost:7860一个美观的聊天界面就出现了。5. 进阶优化与深度定制基础版本跑通后我们可以从多个维度进行优化让助手变得更聪明、更强大。5.1 提升检索质量超越简单向量搜索混合检索Hybrid Search结合向量检索语义相似和关键词检索词汇匹配。例如使用BM25算法进行关键词检索将两者的结果按分数融合。这能同时保证语义相关性和关键词命中率尤其适合函数名、变量名等精确匹配的场景。LlamaIndex和ChromaDB需企业版都支持混合检索。重排序Re-ranking初步检索可能返回很多相关片段但排序未必最优。可以使用一个更小、更快的重排序模型如BAAI/bge-reranker-base对Top-N的检索结果进行二次排序将最相关的一两个片段排到最前面显著提升最终答案的质量。元数据过滤在检索时加入过滤器。例如用户问“config.py里的这个函数是干嘛的”系统可以优先检索file_path包含config.py的片段。或者在问答时让用户选择“仅搜索源代码”或“也搜索Issues和文档”。5.2 优化提示工程引导模型生成更佳答案基础的提示词可以大幅改进你是一位专注于[仓库名称]项目的资深工程师。请根据以下提供的项目上下文信息以清晰、准确、专业的方式回答用户问题。 ## 项目上下文信息来源已标注 {context_str} ## 用户问题 {query_str} ## 回答要求 1. 答案必须严格基于提供的上下文。如果上下文信息不足请明确说明“根据现有资料无法确定”并可以建议用户查看哪些具体文件如src/core/engine.py以获取更多信息。 2. 如果涉及代码请尽量引用具体的函数名、类名和行号。 3. 如果问题关于错误请先分析可能的原因再给出解决步骤。 4. 回答格式请使用Markdown使结构清晰。 现在请开始回答通过细化角色、明确要求和格式化输出能显著提升模型回答的针对性和可用性。5.3 处理超大型仓库与长上下文分层索引对于巨型仓库如Chromium可以建立分层索引。先为顶级目录如/src,/docs,/tests创建摘要索引用户提问时先定位到相关模块再深入检索该模块下的详细代码索引。智能摘要对于超长的文件如庞大的README.md可以先使用大模型为其生成一个结构化摘要目录、核心功能、快速开始步骤并将摘要也存入索引。在回答概览性问题时优先使用摘要。利用长上下文模型随着Claude 3200K、GPT-4 Turbo128K以及本地模型如Qwen2.5-72B32K等长上下文模型的发展我们可以一次性注入更多上下文。但需注意成本与速度的平衡并非越多越好精准的检索依然关键。5.4 集成外部知识让助手更“博学”一个项目不可能孤立存在。助手还可以集成官方文档链接在回答中除了引用源码还可以附上项目官方文档的相关链接如果索引时包含了文档。Stack Overflow与社区讨论可以通过网络搜索API谨慎使用将检索范围扩大到与该仓库相关的Stack Overflow问题或论坛讨论但必须明确标注外部来源。依赖库知识解析项目的requirements.txt或package.json当问题涉及第三方库的使用时可以结合该库的官方文档片段来回答但这需要建立更广泛的知识库。6. 避坑指南与常见问题排查在实际开发和部署过程中我踩过不少坑这里总结一下希望能帮你绕过去。6.1 索引构建慢或内存溢出问题处理一个大型仓库时脚本运行缓慢甚至被Killed。排查与解决检查忽略列表确保ignore_directories和ignore_file_extensions设置正确排除了所有不必要的二进制文件和依赖目录。分步处理不要一次性处理整个仓库。可以先用GitHubRepositoryReader的load_data分批加载或者先只处理特定后缀的文件如.py,.md。调整文本分割器SemanticSplitterNodeParser可能较慢。对于初期测试可以换用更快的TokenTextSplitter或SentenceSplitter。使用更轻量的嵌入模型bge-small比bge-large快得多在初期效果差异可接受。增量索引实现增量更新逻辑只处理新的commit而不是每次都全量重建。6.2 检索结果不相关问题助手回答的问题“答非所问”引用的代码片段和问题无关。排查与解决检查嵌入模型确认使用的嵌入模型是否适合你的文本领域主要是代码和英文文档。对于中文注释较多的项目bge-zh系列模型是更好的选择。优化分块策略代码被不恰当地切断会导致语义丢失。尝试调整分块大小chunk_size和重叠窗口chunk_overlap。对于代码较小的块如256-512 tokens和较大的重叠如100 tokens有时效果更好。启用混合检索如前所述引入关键词检索BM25能有效提升对特定符号、函数名的召回率。审视问题本身用户的问题可能太模糊。可以在前端引导用户问得更具体或者在后台对问题进行简单的重写扩展。6.3 模型回答质量差或胡言乱语问题答案看起来是编造的或者完全没有利用提供的上下文。排查与解决强化提示词约束在提示词中反复强调“严格基于上下文”、“不要编造信息”。使用类似“如果上下文没有提到请说不知道”的强硬指令。检查上下文是否有效注入打印出最终发送给模型的完整提示词前500个字符看看检索到的上下文是否真的被拼接进去了以及格式是否正确。降低模型“创造力”对于Ollama模型可以在调用时设置更低的temperature参数如0.1让答案更确定、更少随机性。换用更强的模型如果本地7B/8B模型效果不佳可以尝试升级到14B、32B甚至70B参数的模型或者换用GPT-4等顶级模型进行对比测试。6.4 部署后的性能问题问题Web界面响应慢用户等待时间长。排查与解决向量数据库查询优化确保向量数据库的索引已经建立。对于ChromaDB持久化后再次加载查询会很快。对于生产环境考虑使用Qdrant并为其配置足够的资源。模型推理加速对于本地模型使用vLLM或TGI等高性能推理框架替代Ollama虽然Ollama更方便可以极大提升吞吐量。同时对模型进行量化如GPTQ, AWQ能在几乎不损失精度的情况下大幅降低显存占用和提升速度。异步处理与缓存使用asyncio实现异步查询避免阻塞。对于常见问题可以引入缓存如redis将“问题-答案”对缓存一段时间。分离索引服务与问答服务将索引构建和更新作为一个独立的后台服务问答API作为另一个服务。这样可以分别进行扩缩容。这个项目最吸引我的地方在于它不是一个黑盒应用。从数据准备、索引构建、检索策略到提示工程每一个环节你都可以深入干预和优化。你可以根据目标仓库的特点是前端项目还是后端项目文档多还是代码多来调整流程。比如对于文档丰富的项目可以加大文档的检索权重对于框架源码可以更注重类与函数的关系提取。这个过程本身就是对“如何让AI更好地理解复杂信息”的一次深刻实践。