1. 从“玩具”到“副驾”为什么我们需要一个本地编程助手最近在折腾一个个人项目需要频繁地在不同编程语言和框架之间切换一会儿是Python的数据处理一会儿是前端的Vue组件中间还夹杂着一些数据库查询优化。说实话虽然各种AI编程工具层出不穷但每次把代码片段、报错信息复制粘贴到网页聊天框里等待网络响应再处理上下文限制这个过程本身就挺打断思路的。更别提有些涉及内部项目结构或者敏感信息的代码根本不敢往外发。这让我开始思考能不能有一个更“贴身”的助手它不需要联网能直接读取我本地的项目文件理解上下文然后基于我的指令生成代码、解释逻辑甚至帮我重构。这不就是“AI Agent”概念在个人开发环境中的落地吗一个专属于我、在我电脑上“跑”的智能副驾。所以我决定动手搭建一个。核心思路很明确利用开源的大语言模型LLM在本地运行再结合ReActReasoning Acting框架和Function Calling函数调用能力让这个AI不仅能“想”还能“做”——比如读取文件、执行命令、分析代码结构。最终的目标是通过自然语言对话让它成为我编码流程中无缝衔接的一部分。这篇文章就是这次实战的完整记录和踩坑总结。2. 技术栈选型在能力、成本与效率间寻找平衡点构建一个本地编程助手技术选型是第一步也是最关键的一步。它直接决定了助手的智商上限、响应速度以及你的硬件门槛。我的选型核心围绕三个点模型能力、推理速度、资源消耗。2.1 大语言模型放弃“巨无霸”拥抱“小钢炮”早期的尝试让我直接排除了动辄上百亿参数的模型比如Llama 2 70B。即使量化到4-bit它对显存的要求也远超普通消费级显卡如RTX 4060的8GB而且推理速度慢不符合“助手”应有的交互即时性。我的目标是寻找一个在7B-13B参数规模、经过高质量代码数据精调、且量化后性能损失较小的模型。经过一番测试对比我最终锁定了DeepSeek-Coder-V2-Lite。选择它的理由很充分代码能力专精DeepSeek-Coder系列在多项代码基准测试如HumanEval, MBPP上表现亮眼对多语言Python, JavaScript, Java, C等的理解和生成能力均衡。尺寸友好V2-Lite版本约6.7B参数使用GPTQ或AWQ量化到4-bit后模型文件仅需4GB左右8GB显存的显卡加载后仍有充裕空间进行推理。对长上下文支持好支持16K甚至更长的上下文这对于分析整个项目文件或多个相关文件至关重要。开源与生态完全开源且有活跃的社区和成熟的推理库支持如llama.cpp, vLLM, Transformers。注意模型选择见仁见智。CodeLlama-7B-Python和Qwen2.5-Coder-7B也是极好的候选。关键是在你的硬件上实际跑几个代码生成和推理任务感受一下速度和质量。别只看排行榜分数。2.2 推理后端Ollama一站式省心之选为了让模型跑起来你需要一个推理后端。这里避开了需要复杂配置的原始Transformers库或vLLM选择了Ollama。它对于本地部署的开发者来说简直是“神器”。开箱即用一条命令ollama run deepseek-coder-v2-lite:6.7b就能拉取、量化自动选择最佳方式并启动模型服务。统一的API无论底层是什么模型都通过简单的HTTP API兼容OpenAI格式进行对话极大降低了客户端开发复杂度。模型管理方便可以轻松切换、列出、删除本地模型。性能不错底层基于高效的C实现推理速度有保障。安装Ollawa只需去官网下载对应操作系统的安装包几分钟就能搞定。启动模型后它会在本地11434端口提供一个API服务。2.3 Agent框架LangChain vs. 自建轻量框架这是核心架构的选择。成熟的框架如LangChain提供了大量现成的Agent、Tool组件和记忆管理。但对于我们这个相对聚焦的目标编程助手LangChain显得有些臃肿学习曲线陡峭且在某些简单场景下开销过大。我决定采用自建轻量框架的思路核心只实现两个部分ReAct逻辑引擎一个循环负责解析模型输出决定下一步是“思考”还是“调用工具”。工具集Tools一系列Python函数每个函数对应一个能力如读文件、写文件、执行命令、代码分析。这样做的好处是完全可控每一行代码都知道在干什么调试极其方便。极度轻量没有额外的抽象层响应更快。高度定制工具函数可以完全贴合我的个人工作流。接下来我们就进入核心的构建环节。3. 核心构建实现ReAct循环与关键工具函数我们的助手大脑运作流程遵循标准的ReAct模式观察(Observation) - 思考(Thought) - 行动(Action) - 结果(Observation)。我们将用Python来实现这个循环并定义几个编程助手必备的工具。3.1 设计系统提示词为AI设定角色与规则系统提示词System Prompt是Agent的“宪法”它定义了AI的身份、能力和行为规范。一个好的提示词能极大提升输出的稳定性和安全性。SYSTEM_PROMPT 你是一个运行在开发者本地的AI编程助手名为DevPilot。你的核心能力是帮助用户分析、生成、修改和优化代码。你必须严格遵守以下规则 1. **安全与本地性**你只能使用我提供给你的工具函数来操作。绝对不能自行尝试执行任何未授权的系统命令、访问网络或进行文件读写。所有操作必须通过工具调用完成。 2. **ReAct格式**你必须严格按照以下格式进行响应Thought: 这里是你对当前问题和上下文的思考分析。你需要决定是否需要使用工具以及使用哪个工具。 Action: 需要使用的工具名称。如果不需要工具则输出Action: FINAL_ANSWER。 Action Input: 调用工具所需的输入参数必须是合法的JSON字符串。如果不需要工具这里输出一个空JSON对象{}。3. **工具使用逻辑**在以下情况你必须使用工具 - 用户要求查看、分析或修改某个文件时使用 read_file 或 write_file。 - 用户的问题涉及当前目录结构、文件查找时使用 list_directory 或 find_files。 - 用户要求运行测试、安装依赖或执行其他Shell命令时在确认安全后使用 run_shell_command。 - 你需要获取更多上下文信息才能回答时。 4. **代码生成与解释**生成代码时务必注明语言并在关键处添加注释。解释代码时要逻辑清晰分点说明。 5. **诚实与边界**如果你不知道或无法通过工具获取信息请直接说明。不要虚构代码或命令。 当前工作目录{working_directory} 可用工具列表{tool_descriptions} 现在开始与用户对话。记住每一步都必须先输出Thought。 这个提示词有几个关键点明确边界第一条就强调了“只能使用提供的工具”这是安全基石。强制格式化要求模型严格按Thought/Action/Action Input输出便于程序解析。场景化引导第三条给出了具体何时该用工具的例子降低了模型的困惑。注入上下文最后会动态填入当前工作目录和工具描述让AI知道它能做什么以及在哪做。3.2 实现工具集给AI装上“手和脚”工具就是Python函数加上一些元数据描述名称、描述、参数schema以便AI理解如何调用。我们实现几个最核心的。import os import subprocess import json from typing import Dict, Any from pathlib import Path def read_file(file_path: str) - str: 读取指定路径文件的内容。 try: path Path(file_path) if not path.exists(): return f错误文件 {file_path} 不存在。 if not path.is_file(): return f错误{file_path} 不是一个文件。 # 安全限制避免读取过大或二进制文件 if path.stat().st_size 1_000_000: # 1MB限制 return f错误文件过大超过1MB出于性能考虑拒绝读取。 with open(path, r, encodingutf-8, errorsignore) as f: content f.read() return content except Exception as e: return f读取文件时发生错误{str(e)} def write_file(file_path: str, content: str) - str: 将内容写入指定文件。如果文件存在会覆盖如果不存在会创建。 try: path Path(file_path) # 简单安全校验避免写入系统关键目录可根据需要调整 if path.is_relative_to(Path.home()) or path.is_relative_to(os.getcwd()): path.parent.mkdir(parentsTrue, exist_okTrue) with open(path, w, encodingutf-8) as f: f.write(content) return f成功写入文件{file_path} else: return f错误出于安全考虑只能写入用户目录或当前项目子目录下的文件。 except Exception as e: return f写入文件时发生错误{str(e)} def list_directory(dir_path: str .) - str: 列出指定目录下的文件和文件夹。 try: path Path(dir_path) if not path.exists(): return f错误目录 {dir_path} 不存在。 if not path.is_dir(): return f错误{dir_path} 不是一个目录。 items [] for item in path.iterdir(): item_type 目录 if item.is_dir() else 文件 items.append(f{item_type}: {item.name}) return \n.join(items) if items else 目录为空。 except Exception as e: return f列出目录时发生错误{str(e)} def run_shell_command(command: str) - str: 在安全沙箱中运行一个Shell命令并返回输出。 # !!! 重要安全限制 !!! # 这里可以定义一个危险命令黑名单或者只允许白名单命令。 # 为了演示我们做一个简单的黑名单检查。 dangerous_keywords [rm -rf, format, dd, mkfs, /dev/sda, chmod 777] for kw in dangerous_keywords: if kw in command: return f错误拒绝执行可能危险的命令包含 {kw}。 try: # 限制命令运行时间和工作目录 result subprocess.run( command, shellTrue, capture_outputTrue, textTrue, timeout30, # 30秒超时 cwdos.getcwd() # 在当前工作目录运行 ) output f标准输出:\n{result.stdout} if result.stderr: output f\n标准错误:\n{result.stderr} output f\n返回码: {result.returncode} return output except subprocess.TimeoutExpired: return 错误命令执行超时超过30秒。 except Exception as e: return f执行命令时发生错误{str(e)} # 工具元数据用于告诉AI这些工具怎么用 TOOLS [ { type: function, function: { name: read_file, description: 读取一个文本文件的内容。, parameters: { type: object, properties: { file_path: {type: string, description: 要读取的文件的路径可以是相对或绝对路径。} }, required: [file_path] } } }, { type: function, function: { name: write_file, description: 将内容写入一个文件。如果文件不存在则创建存在则覆盖。, parameters: { type: object, properties: { file_path: {type: string, description: 要写入的文件的路径。}, content: {type: string, description: 要写入文件的内容。} }, required: [file_path, content] } } }, { type: function, function: { name: list_directory, description: 列出指定目录下的所有条目文件和文件夹。, parameters: { type: object, properties: { dir_path: {type: string, description: 要列出的目录路径默认为当前目录 .。} }, required: [] } } }, { type: function, function: { name: run_shell_command, description: 在安全环境下执行一个Shell命令如运行测试、安装包、查看进程等。禁止执行危险命令如rm -rf, 格式化磁盘。, parameters: { type: object, properties: { command: {type: string, description: 要执行的Shell命令字符串。} }, required: [command] } } } ]实操心得run_shell_command是风险最高的工具。在实际私人使用中你可以根据信任级别调整。我的做法是初期完全禁用或者只允许ls,cat,python -m pytest等少数白名单命令。随着测试稳定再逐步放开。永远不要在生产环境或存有重要数据的目录下未经审查就开放此功能。3.3 组装ReAct引擎让AI学会“思考-行动”这是最核心的驱动循环。我们将与Ollama的API交互解析模型的输出调用工具并将结果反馈给模型直到它给出最终答案。import requests import re class LocalCodeAssistant: def __init__(self, model_namedeepseek-coder-v2-lite, base_urlhttp://localhost:11434): self.base_url base_url self.model_name model_name self.conversation_history [] # 保存对话历史 self.working_directory os.getcwd() def _call_llm(self, messages, temperature0.2): 调用Ollama API。 # Ollama的API格式与OpenAI兼容 payload { model: self.model_name, messages: messages, stream: False, options: { temperature: temperature, num_predict: 2048 # 控制生成的最大token数 } } try: response requests.post(f{self.base_url}/api/chat, jsonpayload, timeout60) response.raise_for_status() return response.json()[message][content] except requests.exceptions.RequestException as e: return f调用模型API失败{str(e)} def _parse_llm_response(self, response_text): 解析模型返回的文本提取Thought, Action, Action Input。 thought_match re.search(rThought:\s*(.*?)(?\nAction:|$), response_text, re.DOTALL) action_match re.search(rAction:\s*(\w), response_text) action_input_match re.search(rAction Input:\s*(\{.*?\}|$), response_text, re.DOTALL) thought thought_match.group(1).strip() if thought_match else action action_match.group(1).strip() if action_match else FINAL_ANSWER action_input_str action_input_match.group(1).strip() if action_input_match and action_input_match.group(1).strip() else {} try: action_input json.loads(action_input_str) except json.JSONDecodeError: action_input {} return thought, action, action_input def _execute_tool(self, action_name, action_input): 根据Action名称和输入执行对应的工具函数。 tool_map { read_file: read_file, write_file: write_file, list_directory: list_directory, run_shell_command: run_shell_command, } if action_name not in tool_map: return f错误未知的工具 {action_name}。 tool_func tool_map[action_name] try: # 将字典参数解包传递给函数 result tool_func(**action_input) return str(result) except TypeError as e: return f调用工具参数错误{str(e)}期望参数{tool_func.__annotations__} except Exception as e: return f工具执行过程中出错{str(e)} def chat(self, user_query): 主对话循环。 print(f\n[用户] {user_query}) # 1. 构建本次请求的消息历史 messages [] # 系统提示词动态注入当前目录和工具描述 tool_descriptions \n.join([f- {t[function][name]}: {t[function][description]} for t in TOOLS]) system_msg SYSTEM_PROMPT.format(working_directoryself.working_directory, tool_descriptionstool_descriptions) messages.append({role: system, content: system_msg}) # 加入之前的对话历史避免上下文过长可设置截断 for hist in self.conversation_history[-6:]: # 保留最近3轮对话 messages.append(hist) # 加入当前用户问题 messages.append({role: user, content: user_query}) max_steps 10 # 防止无限循环 step 0 while step max_steps: step 1 # 2. 调用LLM获取响应 llm_response self._call_llm(messages) # print(f[DEBUG] LLM原始响应:\n{llm_response}) # 调试时打开 # 3. 解析响应 thought, action, action_input self._parse_llm_response(llm_response) print(f[助手思考] {thought}) # 4. 判断是否结束 if action FINAL_ANSWER: final_answer_match re.search(rFINAL_ANSWER:\s*(.*), llm_response, re.DOTALL) final_answer final_answer_match.group(1).strip() if final_answer_match else 思考完成但未提供明确答案。 print(f[助手答案] {final_answer}) # 将最终答案也记录到历史 self.conversation_history.append({role: user, content: user_query}) self.conversation_history.append({role: assistant, content: final_answer}) return final_answer # 5. 执行工具调用 print(f[助手行动] 调用工具: {action}, 输入: {action_input}) observation self._execute_tool(action, action_input) # 避免过长的工具输出淹没对话可以截断 if len(observation) 1000: observation observation[:1000] ... [输出已截断] print(f[工具结果] {observation}) # 6. 将本次“行动-观察”加入到消息中让LLM进行下一轮思考 # 注意格式我们需要把Thought, Action, Action Input, Observation都喂回去 messages.append({role: assistant, content: llm_response}) messages.append({role: user, content: fObservation: {observation}}) # 循环超过最大步数 return 助手思考步数过多可能陷入了循环。请尝试更明确地提问。这个LocalCodeAssistant类就是整个助手的大脑。它的工作流程清晰体现了ReAct接收用户问题。构建包含系统提示、历史、当前问题的消息发送给LLM。解析LLM输出得到“思考”、“行动”指令。如果行动是FINAL_ANSWER则输出最终答案并结束。否则执行对应工具得到“观察”结果。将“观察”结果作为新消息连同之前的LLM输出一起送回给LLM进入下一轮“思考-行动”。循环直到得出最终答案或超时。4. 实战演练与深度调优让助手真正“好用”代码写完了但一个能跑的程序和一个好用的助手之间还隔着大量的调试和优化。这一部分我会分享几个典型的交互案例并深入讲解如何通过提示词工程和工具设计来解决实际问题。4.1 案例一分析现有项目结构并生成新代码假设我有一个简单的Flask项目结构如下my_flask_app/ ├── app.py ├── requirements.txt └── templates/ └── index.html我想让助手帮我添加一个用户登录功能。我会这样提问“帮我分析当前项目的结构然后为它添加一个简单的用户登录功能包括一个登录路由和模板。”助手的工作流会是这样的第一轮思考用户想添加登录功能我需要先了解项目结构。行动调用list_directory输入{dir_path: .}。观察看到app.py,requirements.txt,templates/等。第二轮思考我需要查看主应用文件app.py来理解现有路由和结构。行动调用read_file输入{file_path: app.py}。观察获取到app.py的完整代码。第三轮思考这是一个基础的Flask应用。我需要修改app.py添加/login路由GET和POST并创建一个login.html模板。还需要检查是否需要添加flask-login之类的依赖。行动首先调用read_file查看requirements.txt。观察发现只有Flask。第四轮思考为了简化我先实现一个基于会话的简单登录。现在生成新的app.py代码。行动调用write_file输入{file_path: app.py_new, content: 新生成的完整app.py代码包含旧代码和登录路由}。这里我故意写到一个新文件避免直接覆盖。第五轮思考用户可能想先预览。同时我需要创建templates/login.html。行动调用write_file输入{file_path: templates/login.html, content: 生成的登录表单HTML代码}。第六轮思考代码已生成。现在可以给出最终答案解释我做了什么并建议用户对比app.py_new和原文件以及运行应用测试。行动Action: FINAL_ANSWER。实操心得在工具设计中“写文件”这类破坏性操作要格外小心。我的做法是默认不覆盖像上面案例先写到app.py_new或app.py.bak。提供差异对比可以写一个diff_files工具用difflib生成新旧文件差异让用户确认。关键文件备份在真正执行覆盖前工具函数内部可以自动备份原文件如备份为app.py.backup_20240527。 这些策略能极大避免因AI误判导致的代码丢失。4.2 案例二调试与错误分析用户提问“我运行python test.py时遇到了ModuleNotFoundError: No module named requests错误该怎么办”助手的工作流思考这是一个Python导入错误。我需要查看test.py的内容了解它试图导入什么并检查当前环境。行动调用read_file输入{file_path: test.py}。观察看到文件开头有import requests。思考错误表明requests库未安装。我需要验证当前Python环境并指导用户安装。行动调用run_shell_command输入{command: python -c \import sys; print(sys.executable)\}。观察获取到Python解释器路径。思考确认是哪个Python。现在可以建议安装命令。但为了更稳妥我可以先检查是否已通过pip安装。行动调用run_shell_command输入{command: pip list | grep -i requests}。观察返回空确认未安装。最终答案给出清晰的步骤1) 确认使用上述Python解释器2) 运行pip install requests3) 再次运行python test.py。这个案例展示了助手如何通过组合工具读文件、运行命令来诊断问题而不是仅仅给出一个通用的“安装requests”的回答。它通过实际检查提供了更精确的上下文。4.3 提示词调优解决“工具逃逸”和“思维短路”在初期测试中你肯定会遇到两个经典问题问题1工具逃逸Tool EvasionAI有时会直接在你的问题里写“我可以帮你写一个登录功能代码如下...”完全跳过了使用read_file和write_file工具的步骤。原因系统提示词中“必须使用工具”的约束力不够或者模型在训练时更习惯于直接生成代码。解决方案强化规则在系统提示词开头用更强烈的语气例如“你必须、且只能使用我提供的工具来获取信息或修改文件。绝对禁止在未使用工具的情况下直接假设文件内容或生成文件修改方案。”示例学习Few-Shot在系统提示词中加入一两个完整的、格式正确的ReAct对话示例让模型模仿。后处理惩罚如果在解析响应时发现模型没有按规定格式输出或者在不该给出FINAL_ANSWER时给出了可以在返回给模型的消息中追加批评如“你未遵守规则。请先使用read_file工具查看相关文件内容再基于实际情况回答。”问题2思维短路Lazy ReasoningAI的“Thought”部分非常敷衍比如只是简单重复用户问题然后就调用工具缺乏深度的规划和分析。原因温度temperature参数可能太低导致模型创造性不足或者提示词没有鼓励深度思考。解决方案调整温度将temperature从0.2略微提高到0.3-0.4让思考过程更有探索性。细化思考要求在系统提示词的“ReAct格式”部分明确要求“Thought:部分应详细分析当前状况、已有信息、下一步计划以及为什么选择这个工具。”在工具描述中增加引导例如在read_file的描述中加入“在修改一个文件之前务必先使用本工具读取其当前内容。”4.4 性能与上下文管理优化本地模型和频繁的工具调用会带来性能挑战。上下文长度与历史管理问题对话历史会越来越长消耗大量上下文窗口导致后续生成速度变慢、成本变高对于按token收费的API甚至可能丢失早期关键信息。优化摘要历史不要无脑保存所有原始消息。可以设计一个summarize_conversation工具让AI自己定期对之前的对话进行摘要然后用摘要替换掉冗长的原始历史。滑动窗口像上面代码中做的只保留最近N轮对话如3-5轮。这对于短期任务足够但会丢失更早的上下文。向量检索将历史对话片段存入向量数据库如Chroma。当需要长期记忆时让AI先通过查询向量库来检索相关历史。这更复杂但能力更强。工具调用延迟问题run_shell_command如果执行一个耗时命令如npm install会阻塞整个循环。优化异步执行。可以将工具调用改为异步主循环不等待而是设置一个回调或轮询机制。但这会大幅增加架构复杂度。对于个人助手一个简单办法是在run_shell_command中为耗时命令设置更长的timeout并提示用户“该操作可能需要较长时间”。模型推理加速使用vLLM或llama.cpp的gguf格式配合llama-cpp-python库通常能获得比Ollama默认设置更好的推理性能。根据你的显卡调整num_gpu_layers参数将尽可能多的层放到GPU上能显著提升速度。5. 从“能用”到“爱用”进阶功能与生态集成一个基础的、在命令行交互的助手已经能解决很多问题。但要让它真正融入开发流成为不可或缺的“副驾”还需要一些进阶功能和生态集成。5.1 增强工具集让助手更全能基础工具只能解决信息获取和简单执行问题。我们可以为它添加更专业的“装备”代码分析工具集成pylint,flake8,mypy或tree-sitter让助手不仅能读代码还能进行静态分析指出代码风格问题、潜在bug或类型错误。def analyze_code_with_pylint(file_path: str) - str: 使用pylint分析Python代码并返回报告。 import subprocess result subprocess.run([pylint, --output-formattext, file_path], capture_outputTrue, textTrue) return result.stdout if result.stdout else result.stderrGit集成工具git diff,git log,git status。让助手可以告诉你上次提交改了啥当前分支状态甚至帮你写规范的commit message。文档查询工具虽然我们不联网但可以内置离线文档。例如为Python的sqlite3模块预加载其官方文档的文本摘要当用户问到相关API时助手可以快速引用。项目特定知识库通过read_file读取你项目的README.md、ARCHITECTURE.md或docs/下的文档将这些内容在对话开始时作为上下文注入让助手深刻理解你的项目。5.2 集成开发环境插件脱离终端触手可及命令行助手终究需要切换窗口。最好的体验是将其集成到IDE如VSCode或编辑器如Vim/Neovim中。VSCode扩展思路创建一个VSCode扩展提供一个侧边栏或聊天面板。扩展后端就是你上面写的PythonLocalCodeAssistant类作为一个本地服务运行。在编辑器中你可以选中代码右键点击“向助手解释/优化/调试这段代码”。在聊天框输入“为当前打开的文件添加错误处理”。助手能直接获取当前编辑器的文件路径、选中内容、项目根目录上下文更加精准。扩展可以将助手的回答直接插入编辑器或者以差异视图diff view的形式展示建议的修改。Neovim集成思路 利用Neovim的LSPLanguage Server Protocol客户端或自定义插件将助手封装成一个“代码补全”或“代码操作”的源。你可以通过快捷键唤出浮动窗口与助手对话并执行它的建议。实操心得IDE集成的最大好处是上下文共享。助手能直接知道你在看哪个文件、光标在哪一行、项目结构如何。这省去了大量手动输入文件路径的麻烦交互体验是质的飞跃。初期可以做一个最简单的“执行系统命令”的插件调用你的Python脚本再逐步丰富功能。5.3 个性化与学习让助手更懂你最初的助手是通用的。但你的编码习惯、常用库、项目规范是独特的。我们可以让助手学习并适应你。对话历史持久化将对话历史保存到本地数据库如SQLite。不仅可以回顾还能用于分析你的常见问题模式。创建“习惯”配置文件一个YAML文件记录你的偏好。# .devpilot_config.yaml preferred_language: python code_style: indent: 4 quote: single common_commands: run_tests: pytest -xvs format_code: black . project_context: - path: ./src description: 核心业务逻辑目录 - path: ./tests description: 单元测试目录系统提示词在初始化时加载这个配置AI的行为就会更贴合你的习惯例如默认用4空格缩进生成Python代码。结果反馈与微调当助手生成一段代码后你可以给出“好”或“不好”的反馈。这些反馈数据可以收集起来未来用于对基础模型进行提示词微调Prompt Tuning或轻量微调LoRA让它在你的任务上表现越来越好。虽然本地微调有门槛但这是打造“专属”助手的终极路径。构建这样一个本地编程助手的过程与其说是在开发一个工具不如说是在设计和训练一个工作伙伴。从最开始的简单问答到能够理解上下文、操作文件、执行命令再到最后融入你的开发环境每一步的进化都让它变得更强大、更贴心。最大的收获不是最终的那个程序而是在这个过程中你被迫清晰地定义了你希望如何与机器协作以及如何将模糊的意图转化为精确的指令序列。这本身就是对“智能”和“工具”关系的一次深刻实践。