企业官网建设流程全解析

1. 项目概述：从喧嚣到实践

最近几年，AI编程助手的概念被炒得火热，各种“智能生成”、“自动编程”的宣传语满天飞。作为一名在开发一线摸爬滚打了十多年的老码农，我最初也是抱着怀疑态度。直到我真正动手，为自己和团队搭建了一个专属的、本地化的AI代码助手，我才发现，这玩意儿确实能带来质变，但前提是你要绕过那些华而不实的“噱气”，直击核心痛点。这个项目，就是一次“祛魅”之旅，目标不是创造一个能取代程序员的“超级AI”，而是打造一个真正懂你、懂你团队、懂你代码库的“超级副驾”。它不会替你写整个系统，但能在你卡壳时提供精准的代码片段，在你重构时嗅出潜在的依赖风险，在你接手祖传代码时快速理清脉络。这篇文章，就是一份完全从实战出发的指南，我会拆解从零构建一个AI代码库助手的完整思路、技术选型、实现细节以及我踩过的那些坑，目标是让你也能拥有一个24小时在线、完全可控、且不断进化的编码伙伴。

2. 核心思路与架构设计：为什么是“RAG”而非“大模型”

当你决定要自己动手时，第一个灵魂拷问就是：技术路线怎么选？是直接调用某个现成的、参数巨大的通用大模型API，还是另辟蹊径？我的选择非常明确：基于RAG（检索增强生成）架构，构建一个专属于你代码库的智能体。这个决策背后，是几个非常现实的考量。

2.1 通用大模型的“水土不服”

直接使用ChatGPT、Claude或国内的一些大模型API来回答代码问题，听起来很美好，但实际用起来问题一堆。首先，知识滞后性。你的代码库每天都在变，新增了模块，废弃了旧函数，但通用模型的训练数据可能是一年甚至更久之前的，它对你最新的代码结构一无所知。你跟它说“帮我看看UserService里的validateEmail方法”，它可能只能根据公开的、常见的UserService模式给你编一个，跟你实际的逻辑天差地别。其次，缺乏上下文。一个复杂的业务函数，其逻辑深度依赖于项目特有的工具类、配置常量、数据库模型。通用模型没有这些信息，生成的代码要么过于通用而无法运行，要么就是“一本正经地胡说八道”，引入根本不存在的类或方法。最后，也是最重要的，安全和隐私。把公司核心业务的源代码作为prompt发给第三方API？这在绝大多数稍有规模或对代码安全有要求的企业里，都是不可触碰的红线。

2.2 RAG架构的优势：将大模型变成“领域专家”

RAG的核心思想可以简单理解为“先查资料，再组织答案”。对于代码助手来说，这个“资料库”就是你的整个代码仓库（Git Repo）。它的工作流程分三步：

1. 索引（Indexing）：将你的源代码文件进行解析、切片（Chunking），并转换成向量（Embedding），存入一个本地的向量数据库（如ChromaDB, Weaviate, Qdrant）。
2. 检索（Retrieval）：当你提出一个问题，比如“登录接口的密码加密逻辑在哪里？”，系统会将这个问题也转换成向量，然后在向量数据库中搜索与之最相关的代码片段（通常是3-5个）。
3. 生成（Generation）：将这些检索到的、最相关的代码片段作为“上下文”（Context），连同你的问题一起，提交给一个本地的、轻量级的大语言模型（LLM）。模型基于这些确切的上下文来生成回答，比如“密码加密逻辑位于src/utils/crypto.js的hashPassword函数中，它使用了bcrypt算法，工作因子（work factor）为12。”

这样做的好处是降维打击式的：

• 答案精准可靠：回答完全基于你的真实代码，杜绝了幻觉（Hallucination）。
• 实时同步：代码库一更新，重新索引一下，助手立刻获得最新知识。
• 绝对私有：所有过程都在你的服务器或电脑上完成，代码不出域。
• 成本可控：推理时只需要一个较小的、能在消费级显卡（甚至CPU）上运行的模型，无需为庞大的通用模型API付费。

我的架构选型最终定格为：FastAPI（后端服务） + ChromaDB（向量数据库） + Sentence Transformers（文本嵌入模型） + Ollama（本地LLM运行引擎）。这是一个在性能、易用性和资源消耗之间取得了很好平衡的栈。

3. 环境准备与核心组件部署

理论说清楚了，我们开始动手。整个系统可以部署在你的开发机、一台内部服务器，甚至Docker容器里。我以一台配备16GB内存和一张RTX 4060显卡的开发机为例进行说明。

3.1 基础环境与依赖安装

首先，确保你的Python环境在3.9以上。我强烈建议使用conda或venv创建独立的虚拟环境，避免依赖冲突。

# 创建并激活虚拟环境 python -m venv ai_coder_assistant source ai_coder_assistant/bin/activate # Linux/macOS # ai_coder_assistant\Scripts\activate # Windows # 安装核心依赖 pip install fastapi uvicorn chromadb sentence-transformers pydantic # 安装代码解析和Git相关库 pip install tree-sitter tree-sitter-languages gitpython # 安装Ollama的Python客户端（用于与本地LLM交互） pip install ollama

这里解释几个关键依赖：

• chromadb: 轻量级、嵌入式的向量数据库，无需单独服务，直接作为库集成，非常适合本项目。
• sentence-transformers: 来自Hugging Face的库，提供了大量预训练的文本嵌入模型，我们将用它把代码文本转换成向量。
• tree-sitter: 一个增量解析库，能高效地将源代码解析成语法树（AST）。这对于智能地“切片”代码至关重要——我们不想把一整文件当成一个文本块，而是希望按函数、类来切分，保持语义完整性。
• ollama: 一个强大的工具，可以让你在本地轻松拉取和运行各种开源LLM（如Llama 3, CodeLlama, DeepSeek-Coder等）。它封装了模型下载、加载和推理的复杂过程。

3.2 部署本地大语言模型（Ollama）

Ollama的安装极其简单。访问其官网下载对应系统的安装包，安装后，在终端就可以操作。我们选择一个在代码生成和理解上表现优异的模型，比如deepseek-coder:6.7b（67亿参数，对代码有专门优化，且6.7B的规模在消费级显卡上运行流畅）。

# 拉取模型（这需要一些时间，取决于你的网速和模型大小） ollama pull deepseek-coder:6.7b # 运行模型服务（默认在11434端口） ollama run deepseek-coder:6.7b # 通常我们会让它在后台运行，或者通过API调用，而不是交互式运行。

你可以通过简单的API调用来测试模型是否正常工作：

curl http://localhost:11434/api/generate -d '{ "model": "deepseek-coder:6.7b", "prompt": "用Python写一个快速排序函数", "stream": false }'

注意：模型选择是关键。CodeLlama系列、DeepSeek-Coder系列、StarCoder系列都是优秀的代码专用模型。参数规模上，7B左右的模型是性价比之选，能在16GB内存的机器上良好运行。如果你的显卡显存足够（如24GB），可以尝试更大的34B模型，效果会更好，但响应速度会变慢。务必根据你的硬件条件选择。

3.3 初始化向量数据库与嵌入模型

接下来，我们要准备“记忆库”。首先选择一个合适的嵌入模型。对于代码，all-MiniLM-L6-v2是一个轻量且通用的选择，但更专业的选择是microsoft/codebert-base或Salesforce/codet5-base，它们在代码语义理解上更强。这里我们使用sentence-transformers库加载。

# 在项目初始化脚本中 from sentence_transformers import SentenceTransformer embed_model = SentenceTransformer('all-MiniLM-L6-v2') # 或 'microsoft/codebert-base'

然后初始化ChromaDB。我们需要为它指定一个持久化路径，这样索引数据就不会丢失。

import chromadb from chromadb.config import Settings # 创建一个持久化的客户端 chroma_client = chromadb.PersistentClient(path="./chroma_db") # 创建一个集合（Collection），可以理解为一张表，用来存放我们代码库的索引 code_collection = chroma_client.create_collection( name="codebase_index", metadata={"hnsw:space": "cosine"} # 使用余弦相似度进行检索 )

4. 代码库的解析与向量化索引

这是整个系统的“数据灌入”阶段，也是最需要精细处理的环节。目标是把杂乱无章的源代码，变成结构清晰、便于检索的“知识卡片”。

4.1 智能代码切片（Chunking）

粗暴地按行或按固定字符数切割代码是灾难性的，会切断函数、分割逻辑。我们必须基于语法树进行智能切割。下面是一个使用tree-sitter解析Python代码并按函数/类切割的示例：

import os from tree_sitter import Language, Parser import git # 加载Python语法（需要先编译，这里假设已准备好） PYTHON_LANGUAGE = Language('./path/to/tree-sitter-python.so', 'python') parser = Parser(PYTHON_LANGUAGE) def get_code_chunks(file_path, repo_root): """解析单个文件，提取函数和类级别的代码块""" with open(file_path, 'r', encoding='utf-8') as f: code_text = f.read() tree = parser.parse(bytes(code_text, 'utf-8')) root_node = tree.root_node chunks = [] # 遍历语法树，提取函数和类定义 def _traverse(node, source_code): if node.type in ('function_definition', 'class_definition'): start_byte = node.start_byte end_byte = node.end_byte chunk_text = source_code[start_byte:end_byte].decode('utf-8') # 获取块名（函数名或类名） for child in node.children: if child.type == 'identifier': chunk_name = source_code[child.start_byte:child.end_byte].decode('utf-8') break else: chunk_name = 'anonymous' # 计算相对于仓库根目录的文件路径 rel_path = os.path.relpath(file_path, repo_root) metadata = { "source_file": rel_path, "chunk_type": node.type, "chunk_name": chunk_name, "line_start": node.start_point[0] + 1, # 行号从1开始 "line_end": node.end_point[0] + 1 } chunks.append((chunk_text, metadata)) else: for child in node.children: _traverse(child, source_code) _traverse(root_node, bytes(code_text, 'utf-8')) # 如果文件没有明确的函数/类（如配置文件、脚本），则将整个文件作为一个块 if not chunks: rel_path = os.path.relpath(file_path, repo_root) metadata = {"source_file": rel_path, "chunk_type": "file", "chunk_name": os.path.basename(file_path)} chunks.append((code_text, metadata)) return chunks

这个函数会返回一个列表，每个元素是（代码文本，元数据）。元数据里包含了文件路径、块类型、块名和行号，这些在后续检索和展示时至关重要。

4.2 构建索引管道

有了切片函数，我们就可以遍历整个Git仓库，为每个代码块生成向量并存入ChromaDB。

import hashlib from tqdm import tqdm # 用于显示进度条 def index_repository(repo_path, embed_model, collection): """索引整个代码仓库""" repo = git.Repo(repo_path) all_files = [] # 获取所有源代码文件（这里以.py为例，可扩展） for blob in repo.tree().traverse(): if blob.path.endswith('.py'): all_files.append(os.path.join(repo_path, blob.path)) all_chunks = [] all_metadatas = [] all_ids = [] print(f"开始解析 {len(all_files)} 个文件...") for file_path in tqdm(all_files): chunks_with_meta = get_code_chunks(file_path, repo_path) for chunk_text, metadata in chunks_with_meta: all_chunks.append(chunk_text) all_metadatas.append(metadata) # 生成一个唯一ID，例如使用文件路径和行号的哈希 unique_id = hashlib.md5(f"{metadata['source_file']}:{metadata['line_start']}:{metadata['line_end']}".encode()).hexdigest() all_ids.append(unique_id) print(f"共提取 {len(all_chunks)} 个代码块，开始生成向量...") # 批量生成嵌入向量 embeddings = embed_model.encode(all_chunks, show_progress_bar=True, batch_size=32) print("正在存入向量数据库...") # 批量添加到集合 collection.add( embeddings=embeddings.tolist(), # ChromaDB接受列表形式的向量 documents=all_chunks, # 原始文本 metadatas=all_metadatas, # 元数据 ids=all_ids # ID ) print("索引构建完成！")

实操心得：

1. 增量更新：上述流程是全量索引。在实际使用中，你应该监听Git的post-commit钩子，或者定期（如每天）运行一个增量索引脚本，只处理变更的文件，以提升效率。
2. 多语言支持：你需要为每种编程语言（Java, JavaScript, Go等）准备对应的tree-sitter语法库（.so或.dll文件），并在get_code_chunks函数中根据文件后缀切换解析器。这是一个体力活，但一劳永逸。
3. 过滤文件：不要索引node_modules,__pycache__,.git, 编译产物等目录，会极大增加噪音和索引体积。在遍历文件时做好过滤。
4. 块大小控制：对于特别长的函数或类，可能还需要进一步切割。可以设置一个token数量上限（如512），超过则按语法结构（如函数内的逻辑块）再次细分。

5. 检索与生成服务端实现

索引建好后，我们需要一个服务来接收问题，执行检索-生成流程。这里用FastAPI搭建一个轻量的后端。

5.1 构建检索器（Retriever）

检索器的核心是：将用户问题向量化，然后在ChromaDB中查找最相似的K个代码块。

from typing import List, Dict, Any class CodeRetriever: def __init__(self, collection, embed_model, top_k: int = 4): self.collection = collection self.embed_model = embed_model self.top_k = top_k def retrieve(self, query: str) -> List[Dict[str, Any]]: # 1. 将问题转换为向量 query_embedding = self.embed_model.encode(query).tolist() # 2. 在向量数据库中查询 results = self.collection.query( query_embeddings=[query_embedding], n_results=self.top_k, include=["documents", "metadatas", "distances"] ) # 3. 整理结果 retrieved_chunks = [] if results['documents']: for i in range(len(results['documents'][0])): chunk = { "content": results['documents'][0][i], "metadata": results['metadatas'][0][i], "similarity_score": 1 - results['distances'][0][i] # 假设使用余弦相似度，距离越小越相似 } retrieved_chunks.append(chunk) return retrieved_chunks

5.2 构建提示词（Prompt）工程

这是连接检索结果和LLM的桥梁，直接决定回答的质量。一个好的提示词需要清晰定义角色、任务，并结构化地提供上下文。

def build_prompt(user_query: str, retrieved_chunks: List[Dict]) -> str: """构建给LLM的提示词""" context_str = "" for i, chunk in enumerate(retrieved_chunks): meta = chunk['metadata'] context_str += f"[代码片段 {i+1}，来自文件: {meta['source_file']}， 行号: {meta['line_start']}-{meta['line_end']}]\n" context_str += f"```\n{chunk['content']}\n```\n\n" prompt = f"""你是一个资深软件开发助手，精通项目中的代码。请严格根据下面提供的相关代码片段（来自项目代码库）来回答用户的问题。 如果提供的代码片段不足以回答问题，请如实说明“根据现有代码无法确定”，不要编造信息。 相关代码片段： {context_str} 用户问题：{user_query} 请按以下格式回答： 1. **答案摘要**：用一两句话概括核心答案。 2. **详细解释**：结合代码片段，详细说明逻辑、流程或位置。 3. **相关代码定位**：明确指出答案主要涉及哪个/哪些代码片段（按上面的编号）。 4. **潜在影响/注意事项**：（如果适用）指出修改或使用该部分代码需要注意什么。 """ return prompt

这个提示词做了几件事：限定了LLM的角色和知识范围（只基于提供的代码）、提供了结构化的上下文（标注了来源）、要求了结构化的输出。这能极大提高回答的准确性和可用性。

5.3 集成LLM并创建API

最后，我们将检索器、提示词构建器和Ollama（或其他LLM API）集成起来，并通过FastAPI暴露为HTTP接口。

from fastapi import FastAPI, HTTPException from pydantic import BaseModel import ollama app = FastAPI(title="AI Codebase Assistant API") # 初始化组件（在实际应用中，这些应该通过依赖注入等方式管理） retriever = CodeRetriever(code_collection, embed_model, top_k=4) class QueryRequest(BaseModel): question: str model: str = "deepseek-coder:6.7b" # 允许前端指定模型 class QueryResponse(BaseModel): answer: str relevant_sources: List[Dict] # 返回相关的代码片段信息，供前端高亮展示 @app.post("/ask", response_model=QueryResponse) async def ask_question(request: QueryRequest): try: # 1. 检索相关代码 relevant_chunks = retriever.retrieve(request.question) if not relevant_chunks: return QueryResponse( answer="未在代码库中找到与您问题直接相关的内容。请尝试更具体地描述您的问题，或检查索引是否包含目标文件。", relevant_sources=[] ) # 2. 构建提示词 prompt = build_prompt(request.question, relevant_chunks) # 3. 调用本地LLM response = ollama.generate( model=request.model, prompt=prompt, options={"temperature": 0.1} # 低温度，让输出更确定、更少创造性 ) # 4. 整理响应 answer_text = response['response'] # 提取用于前端展示的源信息 sources_for_frontend = [ { "file": chunk['metadata']['source_file'], "line_start": chunk['metadata']['line_start'], "line_end": chunk['metadata']['line_end'], "chunk_name": chunk['metadata'].get('chunk_name', 'N/A'), "preview": chunk['content'][:200] + "..." if len(chunk['content']) > 200 else chunk['content'] } for chunk in relevant_chunks ] return QueryResponse(answer=answer_text, relevant_sources=sources_for_frontend) except Exception as e: raise HTTPException(status_code=500, detail=f"处理请求时出错: {str(e)}") if __name__ == "__main__": import uvicorn uvicorn.run(app, host="0.0.0.0", port=8000)

现在，运行这个FastAPI应用，你就拥有了一个本地的、私有的代码助手后端服务。你可以通过curl或任何HTTP客户端（如Postman）向http://localhost:8000/ask发送POST请求来提问。

6. 前端界面与集成开发环境（IDE）插件

一个强大的后端需要一个便捷的前端来调用。你可以选择两种主要方式：

6.1 轻量级Web界面

使用简单的HTML/JS框架（如Vue/React）构建一个聊天界面。这适合团队内部分享，或者作为一个小型内部工具使用。界面核心是调用上面的/askAPI，并将返回的答案和代码引用优雅地展示出来，比如可以点击引用直接跳转到仓库对应的文件行。

6.2 IDE插件（更高阶的集成）

这才是真正提升开发效率的“杀手锏”。为VS Code或JetBrains全家桶开发一个插件。插件的核心功能是：

1. 上下文感知：插件能获取当前打开的文件、光标位置、甚至选中的代码块，自动将这些信息作为问题上下文的一部分，让提问更精准。例如，选中一个函数名，右键菜单出现“解释此函数”、“查找调用者”、“生成单元测试”等选项。
2. 无缝交互：在IDE侧边栏或内联弹窗中直接与助手对话，回答可以直接插入到编辑器，或者导航到相关代码位置。
3. 低摩擦：无需切换窗口，编码思考流不被中断。

开发一个VS Code插件涉及TypeScript和其扩展API，这里给出一个最简单的概念示例——添加一个命令，将当前选中的文本作为问题发送给我们的后端：

// extension.js 片段 const vscode = require('vscode'); const axios = require('axios'); // 需要安装 function activate(context) { let disposable = vscode.commands.registerCommand('codeAssistant.ask', async function () { const editor = vscode.window.activeTextEditor; if (!editor) { vscode.window.showErrorMessage('没有活动的编辑器！'); return; } const selection = editor.selection; const selectedText = editor.document.getText(selection); // 获取用户问题 const userQuestion = await vscode.window.showInputBox({ placeHolder: '请输入关于这段代码的问题...', value: selectedText ? `关于这段代码: "${selectedText.substring(0,50)}..."` : '' }); if (userQuestion) { try { // 调用本地后端API const response = await axios.post('http://localhost:8000/ask', { question: userQuestion, model: 'deepseek-coder:6.7b' }); // 在输出通道或新的Webview中显示结果 // 这里简单弹出一个信息框 vscode.window.showInformationMessage(`助手回答: ${response.data.answer.substring(0,200)}...`); // 更优的做法是打开一个自定义的Webview面板，漂亮地展示答案和代码链接 } catch (error) { vscode.window.showErrorMessage(`请求助手失败: ${error.message}`); } } }); context.subscriptions.push(disposable); }

7. 进阶优化与实战技巧

基础系统搭建完成后，可以从以下几个方面进行深度优化，使其从“能用”变得“好用”、“爱用”。

7.1 提升检索质量：超越简单向量搜索

单纯的余弦相似度向量搜索有时会“跑偏”，尤其是当问题表述和代码注释、变量名差异较大时。可以引入混合搜索（Hybrid Search）策略：

• 关键词增强：在向量搜索的同时，也用BM25等传统算法进行关键词匹配，然后将两者的结果进行加权融合（Rerank）。ChromaDB本身支持。
• 元数据过滤：允许用户在提问时指定文件路径、语言等。例如：“在src/services/目录下，查找处理用户支付的方法”。在检索时加入这些元数据过滤条件，能极大提升精度。
• 查询扩展：在将用户问题向量化前，先用一个小模型或规则对问题进行同义词扩展、代码术语标准化（如“增删改查” -> “CRUD”）。

7.2 优化提示词与回答格式

针对不同类型的代码问题，可以设计不同的提示词模板，让LLM扮演更具体的角色：

• 代码解释模板：专注于解释复杂算法或业务逻辑。
• 代码生成模板：基于现有代码模式，生成新的函数或测试用例。
• 错误排查模板：提供错误日志和上下文代码，让助手分析可能原因。
• 代码审查模板：让助手以资深工程师的角度，对一段新代码提出改进建议（命名、性能、安全性等）。

7.3 处理超长上下文与代码依赖

LLM有上下文长度限制（如4K、8K、16K tokens）。当检索到的相关代码片段总长度超过限制时，需要策略性裁剪：

• 优先级排序：根据相似度分数、代码块类型（函数定义可能比整个文件更重要）、文件重要性（核心业务文件优先）对片段排序。
• 智能摘要：对于过长的类或文件，可以先用一个简单的规则或另一个小模型，提取其类/方法签名和简要注释，只将摘要和最关键的部分送入上下文。
• 分层检索：先检索到相关的文件或模块，如果用户需要更深度的分析，再发起第二轮针对该文件的详细检索。

7.4 系统监控与持续迭代

• 日志与反馈：记录每一次问答的提问、检索结果、最终回答。提供一个“点赞/点踩”的反馈机制。这些数据是优化检索策略和提示词的黄金资料。
• 索引健康度检查：定期检查索引覆盖率，是否有新增的文件类型未被支持，是否有大文件切割不合理。
• 模型更新：关注开源社区，当有更强大的代码小模型（如DeepSeek-Coder V2）发布时，可以平滑升级你的Ollama模型，以获得更好的生成效果。

8. 常见问题与排查实录

在实际搭建和使用的过程中，我遇到了不少问题，这里记录下最典型的几个及其解决方案。

8.1 检索结果不相关

现象：问“用户登录的逻辑”，返回的却是数据库配置或工具函数。排查：

1. 检查嵌入模型：all-MiniLM-L6-v2对通用文本不错，但对代码语义可能捕捉不佳。换用microsoft/codebert-base或Salesforce/codet5-base重试索引。
2. 检查代码切片：查看检索到的片段内容，是不是切割得太碎，丢失了函数名等关键信息？优化get_code_chunks函数，确保函数/类定义的完整性。
3. 检查问题表述：尝试用更“代码化”的语言提问，比如“查找用户登录验证的函数”而不是“用户登录的逻辑”。
4. 引入混合搜索：在ChromaDB查询时开启where过滤或使用query_texts进行关键词辅助。

8.2 LLM回答“一本正经地胡说八道”

现象：即使提供了正确的代码片段，LLM的回答还是基于其固有知识编造，而非你提供的上下文。排查：

1. 强化提示词约束：在提示词开头用非常强烈的语气强调“严格根据下面提供的代码片段回答”，并警告“不要使用外部知识”。可以多次强调。
2. 降低Temperature：将生成参数中的temperature调到0.1或更低，减少随机性。
3. 检查上下文注入：打印出发送给LLM的完整提示词，确认检索到的代码片段确实被正确拼接进去了，没有因为长度限制被意外截断。
4. 尝试不同模型：不同的模型遵循指令的能力不同。CodeLlama和DeepSeek-Coder在遵循代码上下文方面通常比通用聊天模型（如Llama 3）更强。

8.3 索引和查询速度慢

现象：首次索引大型仓库（几十万行代码）耗时极长，或者查询响应慢。优化：

1. 并行化索引：使用multiprocessing库并行处理多个文件，充分利用多核CPU。
2. 增量索引：这是必须的。只对新提交的、修改的文件进行重新索引。
3. 优化嵌入模型：如果使用CPU，可以考虑更小的嵌入模型（如all-MiniLM-L6-v2已经很小了）。如果使用GPU，确保sentence-transformers正确调用了CUDA。
4. ChromaDB配置：对于纯内存操作，它很快。但如果持久化到磁盘，查询速度受磁盘IO影响。确保数据库文件在SSD上。

8.4 内存/显存不足

现象：运行Ollama大模型时崩溃，或索引时内存爆掉。解决：

1. 量化模型：Ollama拉取的模型通常是原始精度（FP16）。可以寻找或自己量化成INT4或INT8版本，能大幅降低显存占用，对精度损失却很小。例如使用llama.cpp或AutoGPTQ进行量化后，再配置给Ollama使用。
2. 使用更小的模型：从7B模型降到更小的（如1B-3B）代码模型，虽然能力有下降，但对许多简单的代码问答和补全任务可能足够。
3. CPU推理：如果没有独立显卡，可以强制Ollama使用CPU运行模型（ollama run deepseek-coder:6.7b --num-ctx 2048 --num-thread 8），速度会慢很多，但可以运行。
4. 控制索引规模：只索引核心的业务代码目录，忽略测试、文档、第三方库。

构建自己的AI代码助手，不是一个一蹴而就的“魔法黑盒”部署，而是一个持续迭代和调优的工程过程。它最大的价值不在于替代你思考，而在于将你从繁琐的代码导航、记忆和重复性查找中解放出来，让你更专注于真正的架构设计和复杂逻辑实现。当你看到助手能准确指出三年前写的一个隐蔽的边界条件处理逻辑时，那种“它真的懂我的代码”的成就感，是使用任何通用AI工具都无法比拟的。从这个项目开始，你的代码库将不再是一堆冰冷的文件，而是一个可以被随时“咨询”的活知识库。