1. 项目概述从零构建你自己的“Claude Code”智能体最近在开发者社区里一个名为“build-your-own-claude-code”的项目引起了我的注意。这名字听起来就很有意思它直指一个核心痛点我们能否不依赖闭源的、昂贵的商业大模型API自己动手搭建一个具备代码理解、生成和调试能力的智能编程助手就像那个知名的Claude Code一样。答案是肯定的而且这个过程远比想象中更有趣也更具启发性。这个项目的核心并非要完全复刻某个特定产品而是探索如何利用当前开源生态中最强大的代码大模型结合一套精心设计的工程化框架构建一个私有化、可定制、且完全受控的“AI程序员伙伴”。它解决的是开发者在日常编码中寻求智能辅助但又对数据隐私、API成本、网络延迟或功能定制化有更高要求的场景。无论是想为团队内部打造一个专属的代码审查助手还是希望有一个能理解自己特定项目架构和编码规范的“结对编程”伙伴这个自建方案都提供了一个清晰的实现路径。我自己花了几天时间从环境搭建、模型选型、服务部署到功能测试完整地走了一遍流程。实测下来整个方案非常“扎实”它没有追求华而不实的功能而是聚焦于代码场景下大模型应用最核心的几个环节如何高效地与模型交互、如何为模型提供充足的上下文、如何设计针对代码的提示词Prompt、以及如何将整个流程封装成易用的服务。接下来我就把这套方案的详细设计思路、实操步骤以及我踩过的几个“坑”分享给你。2. 核心架构与设计思路拆解在动手写第一行代码之前我们必须想清楚一个合格的代码智能助手它的“大脑”和“身体”分别是什么这决定了我们整个技术栈的选型。2.1 大脑开源代码大模型选型这是整个项目的基石。我们的目标是找一个在代码任务上表现接近甚至超越 Claude Code 的开源模型。目前社区有几个明确的佼佼者DeepSeek-Coder系列这是国内团队深度求索推出的专注于代码的模型家族。它的优势非常明显在多项代码基准测试如HumanEval, MBPP上名列前茅对中英文指令的理解都很好并且提供了从1.3B到33B多种尺寸的版本方便我们在算力和性能之间做权衡。我最终选择了DeepSeek-Coder-V2-Lite这个版本它在16B参数量级上取得了非常好的性能对消费级显卡如RTX 4090比较友好。CodeLlama系列Meta基于Llama 2专门为代码微调的模型。它的生态非常成熟有Python specialist版本CodeLlama-Python和通用代码版本。其70B版本能力极强但需要更多的显存。对于个人或小团队7B或13B的CodeLlama-Instruct是更务实的选择。Qwen2.5-Coder系列通义千问的代码模型同样表现不俗特别是在长上下文和中文代码注释生成方面有优势。选型心得我选择DeepSeek-Coder-V2-Lite主要基于三点第一它在同等尺寸下代码能力有口碑第二它对中文支持好符合我的需求第三它有INT4量化版本能在24G显存的卡上流畅运行部署成本可控。如果你的显卡显存更大比如48G以上完全可以尝试33B甚至70B的模型效果会再上一个台阶。2.2 身体模型服务与应用框架光有模型文件还不够我们需要一个高效的“发动机”来加载它并提供API服务。这里有两个主流选择vLLM这是一个由加州大学伯克利分校团队开发的高吞吐量、低延迟的LLM推理和服务引擎。它的核心优势是使用了PagedAttention注意力算法极大地优化了显存使用尤其是在处理长序列和并发请求时。对于需要提供在线服务的场景vLLM几乎是生产环境的首选。Ollama如果你更追求极简的本地体验Ollama是完美的选择。它把模型下载、加载、运行和提供API封装成了一个简单的命令行工具在Mac和Linux上体验尤其顺畅。它内置了对很多流行模型的支持一键拉取运行。框架选择本项目我选择了vLLM。原因在于我希望这个“编程助手”能作为一个常驻服务被我的IDE插件、命令行工具或者其他脚本调用。vLLM的API兼容OpenAI格式这意味着任何兼容OpenAI的客户端都能无缝接入生态兼容性极好。Ollama虽然简单但在高并发和精细控制上不如vLLM灵活。2.3 神经与血管上下文管理与提示工程这是让模型真正“懂”代码的关键。一个代码助手不能只基于单文件工作它需要看到相关的模块、依赖、配置文件甚至文档。上下文管理我们需要一个模块能够根据用户的问题例如“修复这个函数里的bug”自动从代码仓库中搜集相关的上下文。这通常通过以下步骤实现文件检索根据问题中的关键词如函数名、类名、文件名在项目中定位文件。代码解析使用语法树AST解析器如Python的ast模块来理解代码结构精准提取相关的函数、类定义而不是粗暴地塞入整个文件。相关性排序将搜集到的代码片段根据与问题的语义相关性进行排序优先将最相关的部分放入有限的上下文窗口。提示工程针对代码任务的提示词需要精心设计。一个通用的代码助手提示词模板通常包含以下几个部分系统角色设定明确告诉模型它是一个专家程序员助手。上下文代码插入上一步搜集到的相关代码用清晰的标记如分隔。用户问题/指令用户的具体需求。输出格式要求明确要求模型只输出代码、代码加解释、或者进行代码审查评论。例如你是一个经验丰富的软件工程师。请根据以下相关代码上下文回答用户的问题。只输出最终的代码块不要输出任何额外的解释。 相关代码上下文 python # utils/helper.py def calculate_average(data_list): if not data_list: return 0 return sum(data_list) / len(data_list)用户问题请为上面的calculate_average函数添加对输入参数类型的检查确保data_list是一个数字列表。2.4 交互界面打造使用入口服务部署好后我们需要一个方式去使用它。有两种主要方式兼容OpenAI的API这是最灵活的方式。vLLM启动的服务其API端点与OpenAI的/v1/chat/completions兼容。这意味着你可以使用curl命令直接测试。用任何语言的OpenAI SDK如openaiPython包进行调用只需修改base_url和api_key。接入支持自定义OpenAI后端的主流IDE插件如Cursor、Windsurf、Continue等。构建一个简单的Web界面如果你想有一个类似ChatGPT的聊天窗口专门用于代码讨论可以用Gradio或Streamlit快速搭建一个前端后端调用自己的vLLM API。整个架构的流程图可以概括为用户通过IDE或Web界面提出问题 - 上下文管理模块检索相关代码 - 组装成提示词 - 发送给vLLM服务的模型 - 模型生成回答 - 返回给用户。接下来我们就进入具体的实操环节。3. 环境准备与模型部署实战理论清晰后我们开始在Linux服务器我用的是一台Ubuntu 22.04配有RTX 4090显卡上动手部署。整个过程分为环境配置、模型下载、服务启动三个大步。3.1 基础环境与依赖安装首先确保你的系统有NVIDIA显卡驱动、CUDA Toolkit和cuDNN。这部分网上教程很多不再赘述。我们直接从Python环境开始。我强烈建议使用conda或venv创建独立的Python环境避免依赖冲突。# 创建并激活conda环境 conda create -n claude-code python3.10 -y conda activate claude-code # 安装PyTorch (请根据你的CUDA版本到PyTorch官网选择对应命令) # 例如CUDA 12.1 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 # 安装vLLM及其基础依赖 pip install vllmvllm的安装会附带很多依赖包括transformers,accelerate等。如果安装过程中遇到任何关于ninja或flash-attn的编译错误可能需要先安装一些系统依赖sudo apt-get update sudo apt-get install -y build-essential cmake3.2 下载与准备模型这里以deepseek-ai/DeepSeek-Coder-V2-Lite-Instruct模型为例。我们可以使用huggingface-cli或者直接git clone如果模型仓库支持。# 安装huggingface-hub工具 pip install huggingface-hub # 使用huggingface-cli下载模型需要先登录 huggingface-cli login huggingface-cli download deepseek-ai/DeepSeek-Coder-V2-Lite-Instruct --local-dir ./models/DeepSeek-Coder-V2-Lite-Instruct --local-dir-use-symlinks False模型很大约16B参数的FP16格式约30GB下载需要较长时间和足够的磁盘空间。也可以考虑先下载量化版本如AWQ, GPTQ能显著减少显存占用和磁盘空间。在Hugging Face模型页面的“Files and versions”标签下通常能找到*-awq或*-gptq的模型文件。重要提示对于vLLM它支持AWQ量化格式并内置了高效的推理支持。我推荐下载AWQ量化版例如deepseek-ai/DeepSeek-Coder-V2-Lite-Instruct-AWQ。这能将模型显存占用降低到原来的1/3到1/4让16B模型在16G甚至更少显存上运行成为可能。3.3 启动vLLM推理服务模型准备好后启动服务就一行命令。这是最激动人心的时刻。# 基本启动命令使用AWQ量化模型 python -m vllm.entrypoints.openai.api_server \ --model ./models/DeepSeek-Coder-V2-Lite-Instruct-AWQ \ --served-model-name deepseek-coder \ --api-key token-abc123 \ # 设置一个简单的API密钥 --port 8000 \ --tensor-parallel-size 1 \ # 如果多卡可以设置为卡数 --gpu-memory-utilization 0.9 \ # GPU显存使用率目标 --max-model-len 16384 # 模型支持的最大上下文长度参数解析--model: 指定模型路径可以是本地路径也可以是Hugging Face模型ID如deepseek-ai/DeepSeek-Coder-V2-Lite-Instruct-AWQvLLM会自动下载。--served-model-name: 服务对外暴露的模型名称客户端调用时会用到。--api-key: 设置一个API密钥虽然本地测试可以不设但建议设置一个简单的以模拟真实环境。--port: 服务监听的端口。--tensor-parallel-size: 张量并行大小单卡设为1如果你有两张相同的卡可以设为2以加速推理。--gpu-memory-utilization: 这是一个非常关键的参数。它控制vLLM为KV Cache预留的显存比例。设置得越高服务能缓存的对话历史就越多吞吐量可能更高但留给模型权重的显存就少了。通常0.8-0.9是个安全范围需要根据你的模型大小和显存实际情况调整。--max-model-len: 不要超过模型本身训练时的上下文长度。DeepSeek-Coder-V2支持128K但为了性能我们可以先设为16384。执行命令后如果一切顺利你会看到输出显示模型加载进度最后出现INFO: Application startup complete.和Uvicorn running on http://0.0.0.0:8000。恭喜你你的私有代码大模型API服务已经就绪3.4 服务验证与基础测试让我们用最简单的curl命令来测试一下服务是否正常。curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer token-abc123 \ -d { model: deepseek-coder, messages: [ {role: system, content: 你是一个编程助手请用Python回答问题。}, {role: user, content: 写一个函数计算斐波那契数列的第n项。} ], max_tokens: 512, temperature: 0.1 }你应该会收到一个JSON格式的响应其中choices[0].message.content字段就是模型生成的代码。如果看到了正确的Python函数说明模型服务运行完美。4. 构建上下文感知的代码助手引擎现在我们有了一個强大的“大脑”模型API但要让它成为真正的“代码助手”我们需要给它装上“眼睛”和“耳朵”也就是上下文管理模块。这个模块负责理解用户问题并从代码库中提取相关信息。4.1 设计代码检索器我们将创建一个CodeRetriever类。它的核心功能是给定一个项目根路径和一个查询用户问题返回一系列相关的代码片段。# code_retriever.py import os import ast from pathlib import Path from typing import List, Dict, Tuple import hashlib class CodeRetriever: def __init__(self, repo_path: str): self.repo_path Path(repo_path) self.file_index {} # 缓存文件路径和简单内容 self._build_index() def _build_index(self): 遍历代码库建立文件索引这里简化只索引.py文件 for py_file in self.repo_path.rglob(*.py): try: # 只读取文件开头一部分内容用于初步检索避免内存过大 with open(py_file, r, encodingutf-8) as f: preview f.read(5000) # 读取前5000字符 # 使用文件路径的相对路径作为key rel_path str(py_file.relative_to(self.repo_path)) self.file_index[rel_path] { full_path: py_file, preview: preview, functions: self._extract_functions(py_file) # 提取函数名 } except Exception as e: print(fError indexing {py_file}: {e}) def _extract_functions(self, file_path: Path) - List[str]: 使用AST解析提取函数和类名 func_names [] try: with open(file_path, r, encodingutf-8) as f: tree ast.parse(f.read(), filenamestr(file_path)) for node in ast.walk(tree): if isinstance(node, ast.FunctionDef): func_names.append(node.name) elif isinstance(node, ast.AsyncFunctionDef): func_names.append(node.name) elif isinstance(node, ast.ClassDef): func_names.append(node.name) except: pass return func_names def retrieve(self, query: str, top_k: int 5) - List[Dict]: 根据查询检索最相关的代码文件。 这里实现一个简单的基于关键词匹配的检索。 生产环境可以考虑使用嵌入模型如BGE进行语义检索。 scores [] query_terms set(query.lower().split()) for rel_path, info in self.file_index.items(): score 0 # 1. 检查文件名是否匹配 if any(term in rel_path.lower() for term in query_terms): score 3 # 2. 检查预览内容是否包含关键词 content info[preview].lower() for term in query_terms: if term in content: score 1 # 3. 检查函数名是否匹配 for func in info[functions]: if any(term in func.lower() for term in query_terms): score 2 if score 0: scores.append((score, rel_path, info[full_path])) # 按分数排序返回top_k个 scores.sort(keylambda x: x[0], reverseTrue) results [] for _, rel_path, full_path in scores[:top_k]: # 读取整个文件内容对于大文件这里可以优化为只读相关部分 try: with open(full_path, r, encodingutf-8) as f: content f.read() # 可以进一步优化只提取包含查询关键词的代码块 results.append({ file_path: rel_path, content: content[:10000] # 限制单个文件上下文长度 }) except: pass return results这个检索器还很基础但它实现了核心逻辑通过关键词匹配文件名、函数名、内容来找到可能相关的文件。在真实场景中你可以引入更先进的语义检索比如用sentence-transformers库将代码片段和查询都编码成向量然后计算余弦相似度。4.2 组装智能提示词有了检索到的代码上下文我们需要将其与用户问题一起组装成模型能理解的提示词。这里我们设计一个PromptBuilder类。# prompt_builder.py class PromptBuilder: SYSTEM_PROMPT 你是一个资深且专业的软件开发助手。你的任务是帮助用户解决编程问题、编写代码、审查代码或解释代码逻辑。 用户会提供一些相关的代码上下文可能来自多个文件。请仔细分析这些上下文并结合你的知识准确、高效地回应用户的请求。 在输出代码时确保代码正确、高效、符合最佳实践。如果用户的问题涉及修改现有代码请清晰地指出修改的位置和内容。 如果上下文不足以回答问题请基于常识进行回答并说明上下文的不足。 请用中文回答除非用户明确要求使用其他语言。 classmethod def build_chat_prompt(cls, query: str, contexts: List[Dict]) - List[Dict]: 构建符合OpenAI Chat格式的messages列表。 Args: query: 用户问题 contexts: 由CodeRetriever返回的上下文列表 Returns: 一个包含role和content的messages列表 messages [ {role: system, content: cls.SYSTEM_PROMPT} ] # 组装上下文 if contexts: context_text 以下是你可能需要参考的代码上下文\n\n for idx, ctx in enumerate(contexts, 1): context_text f[上下文片段 {idx}来自文件: {ctx[file_path]}]\n context_text python\n context_text ctx[content][:8000] # 控制每个上下文长度 context_text \n\n\n messages.append({role: user, content: context_text}) # 加入用户最终问题 final_query f用户问题{query}\n\n请根据以上信息如果有和你的知识进行回答。 messages.append({role: user, content: final_query}) return messages这个构建器做了几件重要的事定义了清晰的系统提示设定了AI的角色和行为准则。将检索到的代码上下文以结构化的方式标明来源文件插入到对话中。将用户最终的问题放在最后符合对话逻辑。4.3 集成与调用创建助手客户端现在我们把检索器、提示词构建器和模型API调用集成在一起。# code_assistant.py import requests import json from typing import Optional from .code_retriever import CodeRetriever from .prompt_builder import PromptBuilder class CodeAssistant: def __init__(self, api_base: str http://localhost:8000/v1, api_key: str token-abc123, model: str deepseek-coder, repo_path: Optional[str] None): self.api_url f{api_base}/chat/completions self.api_key api_key self.model model self.headers { Content-Type: application/json, Authorization: fBearer {api_key} } self.retriever CodeRetriever(repo_path) if repo_path else None def ask(self, query: str, use_context: bool True) - str: 向代码助手提问。 Args: query: 用户问题 use_context: 是否使用代码库上下文 Returns: 模型生成的回答 contexts [] if use_context and self.retriever: contexts self.retriever.retrieve(query, top_k3) messages PromptBuilder.build_chat_prompt(query, contexts) payload { model: self.model, messages: messages, max_tokens: 2048, temperature: 0.1, # 代码生成温度设低更确定性 stream: False } try: response requests.post(self.api_url, headersself.headers, datajson.dumps(payload), timeout60) response.raise_for_status() result response.json() return result[choices][0][message][content] except requests.exceptions.RequestException as e: return f请求API时出错{e} except KeyError as e: return f解析API响应时出错{e}响应内容{response.text} # 使用示例 if __name__ __main__: # 初始化助手指向你的代码仓库 assistant CodeAssistant( api_basehttp://localhost:8000/v1, repo_path/path/to/your/python/project ) # 提问 answer assistant.ask(请帮我检查utils/helper.py里的calculate_average函数是否有潜在问题) print(answer)至此一个具备基础上下文感知能力的代码助手核心引擎就构建完成了。你可以运行这个脚本针对你自己的项目提问看看它是否能结合你的代码给出更精准的回答。5. 高级功能扩展与工程化考量基础功能跑通后我们可以考虑如何让它更强大、更稳定、更像一个产品。5.1 实现代码补全与行内建议除了问答代码助手另一个核心功能是补全。我们可以模仿IDE插件的做法实现一个简单的补全接口。这需要模型支持“填充”Infilling任务或者我们使用一种技巧将光标前的代码和光标后的代码作为上下文让模型预测中间部分。def complete_code(self, file_path: str, prefix: str, suffix: str ) - str: 代码补全。 Args: file_path: 文件路径用于检索相关上下文 prefix: 光标前的代码 suffix: 光标后的代码可选 Returns: 建议补全的代码片段 # 可以检索当前文件的其他部分作为上下文 contexts [] if self.retriever: # 简单实现以当前文件名作为查询进行检索 contexts self.retriever.retrieve(file_path, top_k2) # 构建针对补全的提示 prompt f请完成以下代码。你只需要输出最可能出现在FILL_HERE位置的代码。 相关上下文 {self._format_contexts(contexts)} 需要补全的代码 python {prefix}FILL_HERE{suffix} 补全内容 messages [{role: user, content: prompt}] # ... 调用模型API设置较低temperature和max_tokens # 返回补全结果5.2 集成到开发环境让助手变得易用集成是关键。命令行工具CLI用argparse或click库包装CodeAssistant类创建一个命令行工具。例如my-code-assistant ask --repo ./myproject 这个函数怎么优化 my-code-assistant review --file ./src/main.pyIDE/编辑器插件这是体验提升最大的方式。VS Code你可以开发一个扩展使用Language Server Protocol (LSP) 或直接通过命令面板调用你的助手API。扩展可以监听当前打开的文件、光标位置自动获取上下文并发送请求。Vim/Neovim通过Python或Lua插件绑定快捷键来调用助手。JetBrains IDE可以开发一个插件利用它们的OpenAI API集成功能将后端地址指向你的本地服务。核心思路都是获取当前编辑器状态文件内容、光标位置、项目路径 - 调用本地助手API - 将结果插入编辑器或显示在弹出窗口。5.3 性能优化与缓存策略随着使用频率增加性能问题会浮现。模型推理优化量化始终使用量化模型AWQ, GPTQ进行部署这是提升吞吐、降低延迟最有效的手段。批处理vLLM支持动态批处理。如果你的应用场景有多个并发请求vLLM会自动将它们批处理以提高GPU利用率。调整gpu-memory-utilization这个参数需要根据实际负载微调。如果发现服务经常因为显存不足而崩溃适当调低此值如0.7如果显存充足且希望提高并发可以调高。上下文检索优化向量数据库对于大型代码库基于关键词的检索会失效。应该将代码片段函数、类通过嵌入模型如BGE-M3,text-embedding-3-small向量化存入ChromaDB、Qdrant或Milvus等向量数据库。查询时先将用户问题转换成向量再进行相似度搜索。这能实现真正的语义检索。索引缓存CodeRetriever中的文件索引应该被缓存到磁盘而不是每次启动都重新构建。只有在代码库发生更改通过监控git hook或文件系统事件时才更新索引。结果缓存对于相同或相似的查询可以缓存模型的回答。可以使用redis或简单的diskcache库以(query, context_hash)为键存储回答并设置合理的过期时间。5.4 提升回答质量的技巧思维链Chain-of-Thought对于复杂问题在提示词中要求模型“一步一步思考”。例如在代码审查时提示词可以是“请首先分析代码的功能然后逐行检查可能的问题包括逻辑错误、性能瓶颈、安全漏洞和代码风格最后给出修改建议。”少样本学习Few-shot Learning在系统提示词或上下文中提供一两个高质量的例子。例如展示一个“用户提问-代码上下文-理想回答”的示例能显著引导模型输出更符合你期望的格式和风格。后处理对模型输出的代码可以自动调用语法检查器如pyflakes、black格式化或单元测试快速验证确保其基本正确性再将结果返回给用户。6. 常见问题、故障排查与优化记录在搭建和调试过程中我遇到了不少问题。这里把典型问题和解决方案记录下来希望能帮你绕过这些坑。6.1 模型服务启动失败问题现象可能原因解决方案报错CUDA out of memory模型太大显存不足。1. 使用量化模型-AWQ后缀。2. 减小--gpu-memory-utilization如0.7。3. 换用更小的模型如7B版本。4. 增加--tensor-parallel-size使用多卡。报错ValueError: Unknown model ...模型路径错误或格式vLLM不支持。1. 确认模型路径正确且是vLLM支持的格式如Hugging Face格式AWQ格式。2. 尝试直接用Hugging Face模型ID启动。服务启动慢卡在Loading model weights...模型首次加载需要时间或磁盘IO慢。耐心等待。首次加载后vLLM会将部分权重缓存下次启动会快很多。确保模型在SSD上。报错关于protobuf或typing版本冲突Python环境依赖冲突。在全新的conda或venv环境中严格按照vLLM官方文档顺序安装。先安装PyTorch再安装vLLM。6.2 API调用与响应问题问题现象可能原因解决方案curl测试返回401 UnauthorizedAPI密钥未设置或错误。检查启动命令中的--api-key和curl命令中的Authorization头是否一致。本地测试也可暂时去掉密钥验证启动时不加--api-key调用时不加Header。响应速度非常慢提示词过长或模型正在处理其他请求。1. 优化提示词减少不必要的上下文。2. 检查--max-model-len是否设置得过大。3. 使用streamTrue参数流式输出提升用户体验。模型回答胡言乱语或格式错误温度temperature参数过高或提示词设计不佳。1. 代码生成任务将temperature设为0.1或0.2增加确定性。2. 在提示词中明确指定输出格式例如“只输出代码不要解释”。3. 使用更严格的停止词stoptokens如“”。回答不基于提供的上下文模型忽略了上下文。1. 强化系统提示词例如“你必须严格依据提供的代码上下文来回答问题”。2. 将上下文放在更靠近用户问题的地方。3. 尝试不同的模型。有些模型对上下文指令遵循能力更强。6.3 上下文检索不准确问题现象可能原因解决方案检索不到相关文件关键词匹配太简单或代码库结构复杂。1. 实现基于向量数据库的语义检索强烈推荐。2. 在检索时不仅匹配文件名、函数名也匹配类名、变量名和注释。3. 扩大检索范围增加top_k。检索到的文件太大挤占上下文窗口代码文件本身很大。1. 在CodeRetriever.retrieve方法中不要返回整个文件内容而是使用AST解析只提取与查询最相关的函数或类定义。2. 对长文件进行分块chunk比如按函数或按固定行数分割分别建立索引。检索速度慢每次检索都遍历所有文件。1. 实现索引的持久化缓存。2. 使用更高效的数据结构如倒排索引针对关键词或向量索引。3. 只在代码变更时更新索引。6.4 工程化部署建议使用进程管理不要直接在前台运行python -m vllm.entrypoints.openai.api_server。使用systemdLinux或supervisord来管理服务进程实现开机自启、自动重启。配置反向代理如果你需要通过域名访问或者需要HTTPS使用nginx或Caddy作为反向代理转发请求到本地的8000端口。监控与日志vLLM会输出日志到标准输出。使用journalctlsystemd或重定向到文件来记录日志。监控GPU使用率nvidia-smi和API请求频率以便扩容或优化。安全考虑如果你的服务暴露在公网务必使用强API密钥。通过反向代理配置速率限制防止滥用。仅在内网或通过VPN访问是更安全的选择。搭建自己的“Claude Code”之旅到这里就基本完成了。从选择一个合适的开源模型到用vLLM搭建高性能推理服务再到实现上下文检索和提示词工程最后考虑集成和优化每一步都充满了动手的乐趣和解决问题的成就感。这个项目最大的价值不在于复刻某个产品而在于你获得了一个完全可控、可深度定制、且能随着开源模型进步而不断进化的智能编程伙伴。你可以根据团队的编码规范微调提示词可以针对特定技术栈如你的React前端或Go后端优化检索器也可以随时切换到底层更强的新模型。这种自由度和掌控感是使用任何商业API都无法比拟的。