1. 项目概述：当数据库管理遇上本地AI

如果你和我一样，每天的工作都离不开Navicat，那肯定对反复执行相似的SQL查询、整理表结构文档或者调试复杂存储过程感到一丝疲惫。这些工作本身技术含量不高，但极其耗费时间，而且容易出错。最近，我尝试把Ollama这个本地大模型工具和Navicat结合起来，折腾出了一套“AI数据库助手”的工作流。简单来说，就是让一个运行在你本机上的AI模型，来帮你理解数据库上下文、生成SQL语句、解释查询逻辑，甚至优化性能。

这听起来可能有点“未来感”，但其实门槛比想象中低很多。Ollama让部署和运行Llama 2、CodeLlama、Mistral这类开源大模型变得像安装一个普通软件一样简单，完全在本地运行，数据不出私域，响应速度也快。而Navicat作为我们最熟悉的数据库图形化管理工具，其强大的连接管理、数据浏览和SQL编辑功能，正是AI需要“观察”和“操作”的窗口。

我最初的想法很简单：能不能在我写SQL卡壳的时候，不用去搜索引擎里大海捞针，也不用离开Navicat的编辑界面，就能得到一个靠谱的提示？或者，当我拿到一个陌生的数据库时，能不能让AI快速帮我梳理出核心的表关系和业务逻辑？经过一段时间的摸索和配置，我发现这个组合不仅能实现这些，还能带来不少意外之喜。接下来，我就把这套从零开始的配置思路、实操步骤以及我踩过的坑，毫无保留地分享出来。

2. 核心工具选型与部署策略

2.1 为什么是Ollama + Navicat？

在开始动手之前，我们先聊聊为什么选这两个工具，以及它们组合起来的独特优势。市面上AI代码助手不少，比如Cursor、Copilot，但它们通常是云端服务，或者专注于通用编程。而我们的场景非常垂直：数据库开发与管理。

Ollama的核心优势在于“本地化”和“轻量化” 。它把大模型复杂的部署过程封装成了几条简单的命令，支持Windows、macOS和Linux。你下载的模型文件就存放在本地，所有的推理计算也在你的电脑上进行。这意味着：

  1. 数据安全 ：你的数据库结构、查询语句等敏感信息完全不会上传到任何第三方服务器。
  2. 离线可用 ：即使没有网络，你依然可以使用AI助手进行代码补全或问题分析。
  3. 响应迅速 ：省去了网络往返的延迟，对于简单的提示，响应几乎是实时的。
  4. 模型可选 ：你可以根据自己电脑的配置（特别是GPU显存）选择不同尺寸的模型，从70亿参数到700亿参数，总有适合你硬件的。

Navicat则是数据库管理领域的“瑞士军刀” 。它支持MySQL、PostgreSQL、Oracle、SQL Server、SQLite等几乎所有主流数据库，提供了直观的图形界面进行连接管理、数据编辑、SQL编写和调试。我们将AI能力注入Navicat，本质上是扩展了它的“智能”维度，让它从一个被动的操作工具，变成一个能主动提供建议的协作伙伴。

这个组合解决了一个核心痛点： 上下文切换 。传统工作流中，你在Navicat里遇到问题，需要切到浏览器查资料，再切回来尝试，效率被打断。而现在，AI助手就在你的工作流内部，理解你当前正在操作的数据库对象，提供沉浸式的辅助体验。

2.2 Ollama的安装与国内镜像加速

Ollama的官方安装非常 straightforward。以Windows为例，直接去官网下载安装包，一路下一步即可。安装完成后，打开命令行（CMD或PowerShell），输入 ollama run llama2 就可以尝试运行一个模型。

但是，这里会遇到第一个，也是最大的一个坑： 下载速度极慢，甚至失败 。因为模型动辄几个GB，直接从海外服务器拉取对国内用户非常不友好。

解决方案：使用国内镜像源 。这是必须做的一步，能节省你数小时甚至数天的等待时间。

  1. 配置环境变量（关键步骤） ： 对于Windows用户，你需要设置一个系统环境变量，告诉Ollama从国内的镜像站下载模型。

    • 右键点击“此电脑” -> “属性” -> “高级系统设置” -> “环境变量”。
    • 在“系统变量”部分，点击“新建”。
    • 变量名填写： OLLAMA_HOST
    • 变量值填写： https://ollama.operatorx.cn （这是一个可用的国内镜像示例，请优先搜索确认当前可用的最新镜像地址，社区常有分享）。
    • 点击“确定”保存。

  2. 验证与拉取模型 ： 重新打开一个命令行窗口，再次运行 ollama run llama2 。你会发现下载速度有了质的飞跃。 llama2 是Meta开源的70亿参数模型，对中文支持尚可，英文能力很强，适合作为入门首选。如果你的电脑配置较好（比如有8GB以上显存），可以尝试 ollama run codellama ，这是专为代码生成的微调版本，在SQL生成上表现更出色。

  3. 常用模型推荐 ：

    • llama2:7b ：通用性强，资源占用相对较小（约4GB RAM），适合初次体验。
    • codellama:7b ：代码专用模型，生成SQL、解释代码逻辑是其强项。
    • mistral:7b ：一个表现非常出色的70亿参数模型，在很多基准测试中超越了Llama 2，综合能力优秀，强烈推荐。
    • qwen:7b ：通义千问的开源模型，对中文理解和生成有天然优势。

注意 ：国内镜像地址可能会变化。如果上述镜像失效，请搜索“Ollama 国内镜像”寻找最新的可用地址。也可以尝试一些大学或机构提供的镜像服务。

2.3 Navicat的准备：版本选择与基础配置

Navicat有Premium（旗舰版）、Standard（标准版）等不同版本。对于这个AI助手工作流，任何能运行SQL编辑器的版本都可以，因为核心是利用它的查询编辑器。

如果你使用的是 Navicat Premium 17 ，确保它已正确激活。网络上流传的所谓“破解脚本”或“注册码”存在巨大风险，包括软件不稳定、功能缺失、潜在后门病毒等。对于生产环境或长期使用的工具，我强烈建议通过官方渠道购买正版许可证，这是对自身工作和数据安全最基本的投资。Navicat也提供14天的全功能免费试用，足够你完成本教程的探索。

基础配置建议 ：

  1. 打开Navicat，连接到你的测试数据库（建议使用本地安装的MySQL或SQLite，避免对生产环境造成影响）。
  2. 熟悉“查询”功能：新建一个查询窗口，这是我们与AI交互的主战场。
  3. （可选）在查询编辑器的设置中，调整字体和主题，让自己看得更舒服。一个清晰的工作界面能提升效率。

3. 连接桥梁：构建AI与数据库的对话上下文

Ollama安装好后，默认提供了一个类似聊天机器的命令行交互界面。但这离我们的目标——在Navicat里获得智能帮助——还差一步。我们需要一个“中间人”，既能接收来自Navicat的请求（比如一段不完整的SQL），又能调用本地的Ollama服务获取补全或建议，最后把结果返回给Navicat。

目前，并没有Navicat官方的Ollama插件。因此，我们需要一点“曲线救国”的思路。我实践下来最有效、最灵活的方法是： 使用一个轻量级的本地API服务器 + Navicat的“自定义命令”或外部工具集成功能 。

3.1 搭建本地AI API服务

Ollama本身提供了API。运行 ollama run 后，它会在本地 http://127.0.0.1:11434 启动一个API服务。我们可以直接向这个端口发送HTTP请求来与模型对话。

但是，直接调用原始API格式比较繁琐。我们可以写一个简单的Python脚本作为代理服务器，它负责：

  1. 接收我们自定义格式的请求（比如包含数据库上下文和问题）。
  2. 整理成Ollama API需要的格式（构造一个包含系统提示词和用户消息的Prompt）。
  3. 调用Ollama API。
  4. 将回复返回。

这里给出一个极简的示例，使用Python的Flask框架：

# 文件保存为 ai_db_helper.py
from flask import Flask, request, jsonify
import requests
import json

app = Flask(__name__)
OLLAMA_API_URL = "http://127.0.0.1:11434/api/generate"

def ask_ollama(prompt):
    """向本地Ollama服务发送请求"""
    data = {
        "model": "mistral:7b",  # 替换成你实际使用的模型名
        "prompt": prompt,
        "stream": False
    }
    try:
        response = requests.post(OLLAMA_API_URL, json=data)
        response.raise_for_status()
        result = response.json()
        return result.get("response", "").strip()
    except Exception as e:
        return f"Error calling Ollama: {e}"

@app.route('/sql_help', methods=['POST'])
def sql_assistant():
    """处理SQL帮助请求"""
    user_data = request.json
    db_context = user_data.get('context', '')  # 可传入当前表结构等上下文
    user_question = user_data.get('question', '')

    # 构造一个精心设计的系统提示词，这是效果好坏的关键！
    system_prompt = """你是一个专业的SQL数据库专家。请根据用户提供的数据库上下文（如果有）和问题，生成准确、高效、安全的SQL语句，或对SQL进行解释、优化。
    你的回答应当直接给出SQL代码或明确的解释，不要包含多余的道歉或开场白。如果用户问题模糊，请先做出合理假设并说明。"""
    
    full_prompt = f"{system_prompt}\n\n数据库上下文：\n{db_context}\n\n用户问题：\n{user_question}"
    
    answer = ask_ollama(full_prompt)
    return jsonify({"answer": answer})

if __name__ == '__main__':
    # 在本地11435端口启动服务，避免与Ollama默认端口冲突
    app.run(host='127.0.0.1', port=11435, debug=False)

运行这个脚本前，你需要确保已安装Flask和requests库 ( pip install flask requests )。然后，在命令行运行 python ai_db_helper.py 。现在，你的本地就有了一个运行在 http://127.0.0.1:11435/sql_help 的AI助手接口。

3.2 将AI服务集成到Navicat工作流

有了API服务，我们如何在Navicat中使用它呢？这里介绍两种实用方法。

方法一：利用Navicat的“自定义命令”功能（推荐） Navicat的“自定义命令”功能允许你定义外部工具，并传入当前选中的文本。

  1. 在Navicat顶部菜单栏，点击“工具” -> “自定义命令” -> “新建”。
  2. “命令名称”填写：“AI SQL助手”。
  3. “程序”填写：一个批处理脚本或Python脚本的路径。我们需要一个能发送HTTP请求的脚本。例如，创建一个 call_ai_helper.bat (Windows)： 
    @echo off
setlocal
REM 获取Navicat传递的参数（当前选中的SQL文本）
set USER_QUESTION=%1
REM 这里简化处理，实际可以构造更复杂的JSON。也可以用一个Python小脚本来实现更复杂的逻辑。
echo 正在向AI助手提问：%USER_QUESTION%
REM 实际调用时，更稳健的做法是写一个Python脚本，接收参数，调用我们刚启动的本地API（http://127.0.0.1:11435/sql_help），并弹窗显示结果。
pause
    更高级的做法是写一个Python GUI小工具，弹窗显示问答结果。这需要更多的编程工作，但体验更好。

方法二：手动复制粘贴的“半自动”工作流（最简单） 对于不想折腾编程的用户，最直接的方法就是：

  1. 在Navicat的查询编辑器里，选中你不理解的SQL片段，或者写下你的问题描述（如“请为 users 表创建一个查询，找出过去一周活跃的用户”）。
  2. 打开一个文本编辑器或笔记软件，手动构造一个简单的JSON，或者直接整理你的问题。
  3. 使用Postman、curl或者一个简单的HTML页面，向你本地运行的 http://127.0.0.1:11435/sql_help 发送POST请求。
  4. 将返回的答案复制回Navicat的查询编辑器。

虽然看起来步骤多了点，但避免了复杂的集成，并且让你对提问的过程有更强的控制力。你可以精心构思问题，附上相关的 CREATE TABLE 语句作为上下文，这样AI给出的答案会准确得多。

实操心得 ：初期建议使用方法二。它能让你更清晰地理解AI助手的能力边界和提问技巧。等你熟悉了整个交互流程，再考虑用Python写一个集成度更高的小工具，一键获取答案。 提问的质量直接决定了回答的质量 。给AI提供清晰的表结构、字段名和业务逻辑描述，比问一个模糊的问题有效十倍。

4. 实战场景：AI助手在数据库工作中的妙用

配置好了环境，接下来我们看看这个组合能在哪些具体场景中发光发热。我把它总结为四个核心应用方向。

4.1 场景一：智能SQL生成与补全

这是最直接的需求。你脑子里有业务逻辑，但不确定SQL该怎么写。

操作示例 ：

  1. 上下文准备 ：在向AI提问前，最好先提供相关表的结构。在Navicat中，可以右键点击表 -> “对象信息” -> “DDL”，复制 CREATE TABLE 语句。
  2. 构造请求 ：假设我们有一个简单的用户表 users (id, name, email, created_at)和订单表 orders (id, user_id, amount, status, created_at)。
  3. 提问 ：将以下内容作为“问题”发送给你的AI助手接口： “根据以下表结构，请写一个SQL查询，找出在2023年下单总金额超过1000元的所有用户的姓名和总消费金额，并按总消费金额降序排列。” 同时，将两个表的 CREATE TABLE 语句放在“数据库上下文”里。
  4. AI输出 ：一个合格的AI助手（如CodeLlama或Mistral）应该能生成类似下面的SQL： 
    SELECT 
    u.name,
    SUM(o.amount) as total_spent
FROM users u
INNER JOIN orders o ON u.id = o.user_id
WHERE o.status = 'completed' 
    AND YEAR(o.created_at) = 2023
GROUP BY u.id, u.name
HAVING total_spent > 1000
ORDER BY total_spent DESC;
    它甚至可能会加上注释，解释连接条件和聚合函数的使用。

注意事项 ：

  • 永远要验证 ：AI生成的SQL，尤其是涉及数据更新（ INSERT , UPDATE , DELETE ）的语句， 务必先在测试环境或事务中验证 ，确认无误后再在生产环境执行。AI可能会犯“幻觉”错误，比如引用不存在的字段。
  • 提供明确的状态字段 ：在上例中，AI假设了 o.status = 'completed' ，这是因为在真实的电商场景中这是合理的。如果你的业务逻辑不同，需要在问题中明确指出。

4.2 场景二：复杂SQL语句的解释与调试

遇到别人写的、或者自己很久以前写的复杂嵌套查询、多重连接或窗口函数，一时半会儿看不懂怎么办？让AI做你的代码注释员。

操作示例 ：

  1. 在Navicat中，选中那段令人费解的SQL。
  2. 提问：“请详细解释以下SQL语句的每一部分是在做什么，它的业务逻辑可能是什么？”
  3. AI会逐层拆解，例如：

    “这是一个使用了公共表表达式（CTE）和窗口函数的查询。首先，CTE user_stats 计算了每个用户每天的订单数和金额。然后，主查询从这个CTE中，使用 LAG 窗口函数获取每个用户前一天的数据，并计算日环比增长率。最后筛选出增长率超过10%的记录。其业务逻辑可能是用于识别近期活跃度显著提升的用户。”

这个功能对于接手老项目、进行代码审查或者学习高级SQL技巧非常有帮助。

4.3 场景三：数据库设计与文档生成

在设计新表或分析现有数据库时，AI可以充当一个 brainstorming 的伙伴。

  • 表结构建议 ：你可以描述业务实体（如“我需要一个商品表，包含商品基本信息、库存、价格、分类”），让AI给出初步的字段设计、数据类型建议，甚至索引建议。
  • ER图描述 ：让AI根据已有的多个 CREATE TABLE 语句，用文字描述出表之间的关系，帮你快速理解数据库架构。
  • 生成数据字典 ：提供一个脚本模板，让AI帮你批量生成描述表和字段的注释语句，或者整理成Markdown格式的文档。

4.4 场景四：查询性能分析与优化建议

对于慢查询，AI可以提供一个初步的分析视角。

操作示例 ： 将你的慢查询SQL和 EXPLAIN （或 EXPLAIN ANALYZE ）的执行计划结果一起发给AI。 提问：“以下SQL查询较慢，这是它的执行计划。请分析可能存在的性能瓶颈，并提供优化建议（例如，是否缺少索引，连接顺序是否合理，是否有不必要的全表扫描）。”

AI可能会指出：

  • “ users 表的 created_at 字段上缺少索引，导致在WHERE子句中进行全表扫描。”
  • “建议在 orders.user_id 和 orders.created_at 上创建复合索引。”
  • “考虑将子查询重写为JOIN，可能效率更高。”

重要提醒 ：AI的优化建议仅供参考， 绝不能盲目采纳 。你必须结合数据库的实际数据分布、数据量、服务器配置和数据库引擎的特性（如MySQL的InnoDB和PostgreSQL的规划器行为不同）来进行验证。AI的建议是一个很好的起点，但最终的优化方案需要由你这位真正的DBA或开发者来决策和测试。

5. 提示词工程：让AI成为真正的专家

与本地大模型交互， 提示词（Prompt）的质量是成败的关键 。你不能像问搜索引擎一样问它，而是需要像给一个聪明但缺乏背景知识的实习生布置任务一样，给出清晰的指令和上下文。

5.1 构建高效的系统提示词

回顾我们之前API服务器中的 system_prompt ，它定义了AI的角色和能力边界。一个优秀的系统提示词应该包含：

  1. 明确角色 ：“你是一个专业的SQL数据库专家，精通MySQL/PostgreSQL语法和性能优化。”
  2. 定义任务 ：“你的任务是生成、解释、优化SQL语句，并提供数据库设计建议。”
  3. 输出格式要求 ：“直接给出SQL代码块，或分点列出解释。除非用户要求，否则不要解释基础知识。”
  4. 安全与准确性原则 ：“生成的SQL必须语法正确。对于数据修改操作（DML），必须提醒用户在测试环境先验证。如果你不确定，请明确说明。”

你可以根据你的主要数据库类型（MySQL, PostgreSQL等）来微调这个系统提示词，使其更专业。

5.2 用户提问的黄金法则

在具体提问时，遵循以下法则可以极大提升回答的准确率：

  • 法则一：提供充足上下文 。永远把相关的 CREATE TABLE 语句放在问题前面。AI不知道你的表长什么样。
  • 法则二：问题具体化 。不要问“怎么查用户数据？”，要问“如何查询 users 表中2023年注册、状态为‘active’的用户，并按注册时间倒序排列？”
  • 法则三：指定数据库类型 。虽然SQL标准大同小异，但方言有区别。可以在问题开头加上“[MySQL]”或“[PostgreSQL]”。
  • 法则四：分步引导 。对于复杂需求，可以拆解。先让AI设计表结构，确认后再让它基于这个结构写查询。
  • 法则五：要求解释 。在让AI生成代码后，可以追加一句“请解释一下这个查询的逻辑”，加深你的理解。

5.3 处理AI的“幻觉”与错误

本地模型，尤其是70亿参数级别的模型，有时会产生“幻觉”——即自信地给出一个错误答案。你需要学会鉴别：

  1. 语法检查 ：拿到生成的SQL，第一件事是放到Navicat里执行一下“语法检查”或“运行”看是否有明显错误。
  2. 逻辑验证 ：对于查询语句，用少量测试数据验证结果是否符合预期。
  3. 交叉提问 ：如果对答案存疑，换个问法再问一次，或者要求AI逐步推导。
  4. 保持批判性思维 ：记住，AI是辅助工具，你才是最终的决策者和责任人。对于任何重要的、涉及数据安全的操作，必须亲自复核。

6. 进阶配置与性能调优

当基本流程跑通后，你可以考虑以下进阶优化，让体验更上一层楼。

6.1 模型选择与硬件考量

  • CPU vs GPU ：Ollama在启动时会自动检测并使用GPU（如果支持CUDA）。在任务管理器中查看，如果Ollama进程的GPU利用率很高，说明正在用GPU加速，推理速度会快很多。如果只有CPU，响应会慢一些，但对于7B模型，通常也在可接受范围（几秒到十几秒）。
  • 模型大小 ：
    • 7B模型 ：适合大多数日常辅助任务，在16GB内存的电脑上运行流畅。是性价比之选。
    • 13B/34B模型 ：理解能力和生成质量更高，但需要更多的内存和显存。如果你的电脑有32GB以上内存和足够显存，可以尝试，响应时间会更长。
    • 量化版本 ：许多模型提供量化版（如 llama2:7b-q4_0 ），在几乎不损失精度的情况下大幅减少内存占用，是资源有限时的首选。
  • 专用代码模型 ：对于SQL生成任务， codellama:7b 和 deepseek-coder:6.7b 是经过代码数据专门训练的，表现通常比通用模型更好。

6.2 构建更强大的本地AI助手链

单一的问答模式有时不够。我们可以设想更复杂的工作流：

  1. 自动化上下文收集 ：写一个脚本，自动从Navicat连接中提取当前数据库的所有表名或选中表的DDL，并附加到提问中。
  2. 历史对话记忆 ：改造我们的Flask API，加入简单的会话记忆功能，让AI能参考之前的问答，进行连续对话。
  3. 多模型路由 ：针对不同任务调用不同模型。例如，简单解释用7B模型，复杂代码生成用13B模型。

这些都需要更多的编程工作，但能打造出一个真正个性化的、强大的数据库协作者。

6.3 安全与隐私再强调

使用本地Ollama模型的最大优势就是隐私。但即便如此，也请注意：

  • 你的API服务（ http://127.0.0.1:11435 ）默认只监听本地回路（127.0.0.1），外部无法访问，这是安全的。
  • 不要在提示词中传入真实的敏感生产数据。始终使用脱敏的测试数据或表结构进行交互。
  • 定期更新Ollama和模型，以获得更好的性能和安全性。

7. 常见问题与故障排除实录

在配置和使用过程中，我遇到了不少问题，这里把典型问题和解决方案列出来，希望能帮你少走弯路。

问题现象 可能原因 解决方案
运行 ollama run 时下载模型极慢或失败 网络连接问题，未使用国内镜像 1. 确认已正确设置 OLLAMA_HOST 环境变量指向国内镜像。
2. 检查网络代理设置，有时系统代理会干扰。
3. 尝试更换其他社区提供的镜像地址。
运行模型时提示“内存不足”或“CUDA out of memory” 模型所需内存超过可用资源 1. 换用更小的模型（如从7B换到更小的）或量化版本（ -q4_0 ）。
2. 关闭其他占用大量内存/显存的程序。
3. 对于GPU错误，可尝试设置环境变量 OLLAMA_NUM_GPU=0 强制使用CPU运行（速度会慢）。
本地API服务（Flask脚本）启动失败，端口被占用 端口11434或11435已被其他程序使用 1. 修改Flask脚本中的 app.run(port=11435) ，换一个其他端口，如11436。
2. 检查Ollama是否已在运行并占用了11434端口，这是正常的。
向API发送请求后无响应或报错 1. Ollama服务未启动。
2. API请求格式错误。
3. 模型未加载。		 1. 确保先在一个命令行窗口运行了 ollama run <模型名> 。
2. 检查Flask脚本中的API URL和端口是否正确。
3. 查看Ollama命令行窗口是否有错误输出。
AI生成的SQL语法错误或逻辑明显不对 1. 提示词不清晰，缺乏上下文。
2. 模型能力有限或产生“幻觉”。
3. 问题本身过于模糊或复杂。		 1. 优化你的提问 ：提供完整的表结构，描述清晰的业务逻辑。
2. 换用更强的模型 ：尝试 codellama 或 mistral 。
3. 分步提问 ：将复杂问题拆解成多个简单步骤让AI逐步解决。
Navicat自定义命令调用批处理脚本不工作 路径包含空格或特殊字符，参数传递错误 1. 将批处理脚本和依赖程序放在纯英文无空格的路径下。
2. 在批处理脚本中增加日志输出，调试接收到的参数。
3. 考虑使用Python等脚本语言实现，它们处理参数和HTTP请求更稳健。

一个关键的踩坑记录 ：最初我试图让AI直接连接数据库来“看”数据，但这引入了极大的复杂性和安全风险。后来我意识到， “提供上下文”比“授予访问权限”更安全、更简单 。我们只需要把表结构（DDL）作为文本传给AI，就足以让它进行绝大部分的辅助工作。永远记住，AI在这里是“顾问”，不是“操作员”。

折腾这一套Ollama+Navicat的本地AI助手，前后花了不少时间，但我觉得非常值。它并没有完全替代我的思考，而是像一个不知疲倦、知识渊博的副驾驶，在我思路卡顿、需要快速验证想法或者处理枯燥的文档工作时，能立刻提供高质量的参考。这种工作流上的小创新，积累起来就是效率上的大提升。

最让我满意的是，整个体系完全运行在本地，没有任何数据泄露的担忧。你可以放心地用公司的数据库结构去提问，去生成测试数据，去优化查询，这一切都发生在你的电脑内部。

如果你也受够了在数据库工具和浏览器之间反复横跳，不妨花上一个下午，按照这个教程搭一套属于自己的环境。从最简单的“解释SQL”功能开始用起，你会很快感受到它带来的便利。当然，别忘了保持批判性思维，AI给出的每一行代码，最终的责任人依然是你。

# Ollama
Logo
亚马逊云科技技术品牌专区

更多推荐

cover

Hugging Face Optimum 源码静态评测：模型部署优化框架的工程结构与验证边界

avatar 亚马逊云科技技术品牌专区
cover

单片机基础核心知识点汇总（十）

avatar 亚马逊云科技技术品牌专区
cover

AI 工具能解决独立站获客难的问题吗？

avatar 亚马逊云科技技术品牌专区