1. 项目概述：当大语言模型学会“说”SQL

如果你是一名开发者、数据分析师，或者任何需要频繁与数据库打交道的人，下面这个场景你一定不陌生：面对一个复杂的业务需求，你需要在脑海里把自然语言描述（比如“找出上个月下单金额超过一万且从未退过货的VIP客户”）翻译成结构化的SQL查询语句。这个过程不仅考验你对业务逻辑的理解，更考验你对数据库表结构、关联关系、SQL语法的熟练程度。一个不留神， JOIN 条件写错、聚合函数用混，或者子查询性能拉胯，都是常有的事。

SQL-GPT 这个项目，就是为了解决这个“翻译”痛点而生的。它的核心目标很直接： 让你用说人话的方式操作数据库和文件系统 。你不再需要死记硬背那些 GROUP BY 、 HAVING 的复杂组合，只需要用自然语言描述你的需求，剩下的交给大语言模型（LLM）来完成。这听起来像是把 ChatGPT 接上了数据库的“大脑”，让它不仅能理解你的问题，还能直接生成可执行的代码，甚至帮你检查和优化已有的SQL。

我花了些时间深入研究了这个开源工具，它不仅仅是简单地将用户输入扔给 OpenAI API 然后回显结果。其背后是一套完整的本地化问答系统架构，集成了向量数据库用于文件对话、Redis缓存来加速查询，并且设计了一套健壮的API密钥管理和数据库连接机制。对于中小型团队或个人开发者来说，它提供了一个低成本、高可控性的“AI数据库助手”实现方案。接下来，我将带你从设计思路到实操细节，完整拆解这个项目，并分享我在部署和测试过程中积累的一手经验。

2. 核心设计思路与架构解析

2.1 为什么是“LLM + SQL”？

在深入代码之前，我们先要理解这个组合的合理性。大语言模型（如GPT系列）在代码生成和自然语言理解上的能力已经得到了广泛验证。SQL作为一种声明式、结构化的查询语言，其语法相对固定，模式（Schema）定义明确，这恰恰是LLM所擅长的领域——在给定规则和上下文的情况下，生成符合规范的文本。

SQL-GPT 的设计者显然意识到了这一点。项目的核心思路是 “上下文学习（In-context Learning）” 。它不仅仅把用户的自然语言描述直接丢给LLM，而是会先将当前连接的数据库结构（表名、字段名、字段类型、主外键关系）作为“背景知识”提供给模型。这就好比你在向一个数据分析师提问前，先给了他一份完整的数据库设计文档。模型基于这份文档和你用自然语言描述的需求，生成SQL语句的准确率会大幅提升。

这种设计带来了几个关键优势：

  1. 降低使用门槛 ：非技术人员（如产品经理、业务运营）也能直接查询数据，只需描述业务问题。
  2. 提升开发效率 ：开发者可以快速生成复杂查询的草稿，专注于业务逻辑而非语法细节。
  3. 减少错误 ：模型可以基于已知的表结构，避免出现查询不存在的字段或表这类低级错误。
  4. 知识沉淀 ：结合文件对话功能，可以将项目文档、数据字典等知识库化，实现基于文档的智能问答。

2.2 系统架构全景图

SQL-GPT 的架构可以清晰地分为三层： 交互层、逻辑处理层和资源层 。这种分层设计保证了系统的模块化和可扩展性。

资源层 是系统的基石，包括：

  • 大语言模型服务 ：默认是 OpenAI 的 GPT 系列，通过 API 调用。项目也预留了接口，理论上可以接入其他兼容 OpenAI API 格式的模型（如本地部署的 ChatGLM、Vicuna 等），这通过在 config.json 中配置不同的 BASE_URL 实现。
  • 数据库 ：支持 MySQL、PostgreSQL 等多种关系型数据库，用于执行生成的 SQL 和获取结构信息。
  • 向量数据库 ：项目集成了 Chroma，用于存储文件（如 PDF、TXT）经过文本分割和嵌入（Embedding）后的向量数据。这是实现“文件系统对话”功能的核心。
  • Redis ：作为缓存数据库，用于缓存向量检索的结果或频繁访问的元数据，旨在提升文件问答的响应速度。官方称其能提升平均30%的查询速度。

逻辑处理层 是大脑，包含两个核心模块：

  • SQL_GPT 模块 ：负责处理所有与 SQL 相关的逻辑。它接收自然语言查询，结合从数据库拉取的结构信息，构造出给 LLM 的提示词（Prompt），调用模型 API，解析返回的 SQL，并可选择性地直接执行或返回给用户。
  • File_GPT 模块 ：负责处理文件对话。它利用 LangChain 或 LlamaIndex 等框架的能力，将用户上传的文件进行分块、向量化并存入 Chroma。当用户提问时，它先在向量库中进行语义检索，找到最相关的文本片段，然后将这些片段作为上下文与问题一并提交给 LLM，生成答案。

交互层 目前主要是 Python API 接口。用户通过调用 SQL_GPT.generateSQL() 或 File_GPT.askFile() 这样的方法，与系统进行交互。虽然项目 README 中展示的是一个简单的脚本调用示例，但这个架构非常容易扩展出 Web 界面（如 Gradio、Streamlit）或聊天机器人接口。

注意 ：整个系统默认运行在本地。你的数据库、向量库、Redis 以及调用 LLM API 的客户端都在本地环境，这意味着你的数据（除发送给 OpenAI API 的提示词和上下文外）不会离开你的控制范围，对于处理敏感数据来说，这是一个重要的隐私考量。

2.3 关键技术选型背后的考量

  1. LangChain / LlamaIndex ：这两个框架是当前构建 LLM 应用的事实标准。SQL-GPT 利用它们来简化与 LLM 的交互、管理对话历史、以及构建复杂的处理链（如“检索-生成”）。选用它们避免了重复造轮子，能快速集成最新的生态工具。
  2. Chroma ：作为一个轻量级、开源的向量数据库，Chroma 非常适合本地开发和中小规模应用。它易于安装（ pip install chromadb ），API 简单，足以应对项目初期的文件存储和检索需求。项目也提及了 Milvus，这是一个面向大规模生产的分布式向量数据库，为未来性能扩展预留了可能性。
  3. Redis 缓存 ：这是一个非常务实的优化。向量检索虽然精准，但计算相似度（如余弦相似度）是计算密集型操作，尤其当文件库很大时。将“问题-最相关片段”的对应关系缓存起来，当相似问题再次被问及时，可以直接返回缓存结果，避免了昂贵的向量检索和 LLM 调用，这对提升交互体验至关重要。
  4. 多 API Key 轮询 ：这是一个针对生产环境的实用设计。直接调用 OpenAI API 有速率限制（RPM/TPM）。通过配置多个 API Key 并实现简单的轮询或故障转移逻辑，可以有效缓解限流问题，提高服务的稳定性和可用性。

3. 从零开始：环境部署与配置详解

纸上得来终觉浅，绝知此事要躬行。要真正理解一个工具，最好的办法就是亲手把它跑起来。下面是我在 Ubuntu 22.04 服务器上从零部署 SQL-GPT 的完整过程，其中包含了许多官方文档未提及的细节和坑点。

3.1 基础环境准备

首先，确保你的系统有 Python 3.8 或更高版本。我强烈建议使用虚拟环境来管理依赖，避免污染全局环境。

# 1. 克隆项目代码
git clone https://github.com/CL-lau/SQL-GPT.git
cd SQL-GPT

# 2. 创建并激活虚拟环境 (以 venv 为例)
python3 -m venv venv
source venv/bin/activate  # Linux/macOS
# venv\Scripts\activate  # Windows

# 3. 安装核心依赖
pip install -r requirements.txt

这里第一个“坑”可能就出现了。原项目的 requirements.txt 可能不会锁定所有子依赖的精确版本，可能会遇到版本冲突。如果安装失败，可以尝试先安装一些核心包，再安装剩余部分。

# 如果直接安装失败，可以尝试分步安装
pip install langchain==0.0.340 openai==0.28.1 chromadb==0.4.18
pip install -r requirements.txt --no-deps  # 谨慎使用，或根据报错手动调整

3.2 依赖服务部署：MySQL、Redis、Chroma

SQL-GPT 需要这些服务作为后端支撑。使用 Docker 部署是最简单、最干净的方式。

MySQL 部署： 

docker run -d \
  --name mysql-for-sqlgpt \
  -p 3306:3306 \
  -e MYSQL_ROOT_PASSWORD=your_strong_password \ # 务必修改！
  -e MYSQL_DATABASE=test_db \ # 创建一个初始数据库，方便测试
  -v /your/local/path/mysql_data:/var/lib/mysql \ # 挂载数据卷，持久化数据
  mysql:8.0

部署后，记得进入容器或使用客户端（如 DBeaver）创建测试表，以便后续验证。

-- 在 test_db 中创建一个简单的用户表
CREATE TABLE users (
    id INT PRIMARY KEY AUTO_INCREMENT,
    username VARCHAR(50) NOT NULL,
    email VARCHAR(100),
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
INSERT INTO users (username, email) VALUES ('alice', 'alice@example.com'), ('bob', 'bob@example.com');

Redis 部署： 

docker run -d \
  --name redis-for-sqlgpt \
  -p 6379:6379 \
  -e REDIS_PASSWORD=admin \ # 项目默认密码是 admin，可在 config.json 修改
  redis:7.0.12-alpine \
  --requirepass admin

--requirepass admin 参数直接在启动命令中设置了密码。 -e REDIS_PASSWORD 是另一种方式，但 Redis 官方镜像更推荐使用 --requirepass 命令行参数或配置文件来设置密码。

Chroma 向量数据库： Chroma 默认以客户端库的形式运行，数据存储在本地。无需单独部署服务，这在开发阶段非常方便。你只需要在代码中指定一个持久化目录（如 ./chroma_db ）即可。

3.3 核心配置文件 config.json 解读

这是整个项目的“控制中心”，所有关键配置都在这里。让我们逐项拆解：

{
  "OPENAI_API_KEY": "sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", // 你的OpenAI API Key
  "OPENAI_API_BASE": "https://api.openai.com/v1", // OpenAI API 端点，若用第三方代理需修改
  "OPENAI_MODEL": "gpt-3.5-turbo", // 使用的模型，可改为 gpt-4 等
  "OPENAI_KEYS": [ // 多Key轮询列表，第一个为主Key
    "sk-key1",
    "sk-key2"
  ],
  "DATABASE": {
    "host": "localhost",
    "port": 3306,
    "user": "root",
    "password": "your_strong_password", // 对应MySQL的root密码
    "database": "test_db" // 默认连接的数据库
  },
  "REDIS": {
    "host": "localhost",
    "port": 6379,
    "password": "admin", // 对应Redis密码
    "db": 0
  },
  "EMBEDDING_MODEL": "text-embedding-ada-002", // 文件向量化使用的模型
  "CHROMA_PERSIST_DIRECTORY": "./chroma_db", // Chroma数据持久化目录
  "FILE_CACHE_EXPIRE": 3600 // 文件对话缓存过期时间（秒）
}

实操心得与避坑指南：

  1. API Key 与 Base URL ：如果你无法直接访问 api.openai.com ，需要使用第三方代理服务，那么 OPENAI_API_BASE 就需要改成代理服务商提供的地址，例如 https://your-proxy.com/v1 。同时， OPENAI_API_KEY 也要换成代理服务商提供的Key。
  2. 数据库连接 ：确保 DATABASE 配置中的主机、端口、密码和数据库名完全正确。一个常见的错误是 host 在 Docker 环境下填写 localhost 。如果 MySQL 容器和 SQL-GPT 应用不在同一个 Docker 网络内， localhost 指的是容器自身，而不是宿主机的 MySQL。此时需要填写宿主机的IP或 Docker 网络内的容器服务名。
  3. Redis 密码 ：如果 Redis 设置了密码， REDIS 配置中的 password 字段 必须填写 ，否则连接会失败。很多同学部署时忘了这里，导致文件缓存功能不生效且无明确报错。
  4. 向量模型 ： EMBEDDING_MODEL 默认使用 OpenAI 的付费嵌入模型。如果你希望完全本地化运行，可以探索集成 sentence-transformers 等开源模型，但这需要修改 File_GPT 模块的初始化代码。

4. 核心功能实战与代码剖析

配置妥当后，我们就可以开始体验 SQL-GPT 的核心功能了。我将通过几个具体的代码示例，展示其能力边界，并深入源码层面看其实现逻辑。

4.1 自然语言生成 SQL

这是最核心的功能。我们来看一个完整的例子：

from gpt.SQLGPT import SQL_GPT

# 初始化，会自动读取 config.json 并连接数据库
sql_gpt = SQL_GPT()

# 场景1：简单的条件查询
question = “找出所有邮箱包含 ‘example.com’ 的用户”
generated_sql = sql_gpt.generateSQL(question)
print(f“问题：{question}”)
print(f“生成SQL：{generated_sql}”)
# 预期输出：SELECT * FROM users WHERE email LIKE ‘%example.com%’;

# 场景2：涉及聚合和排序的复杂查询
question2 = “计算每个用户名的长度，并按长度从长到短排序”
generated_sql2 = sql_gpt.generateSQL(question2)
print(f“\n问题：{question2}”)
print(f“生成SQL：{generated_sql2}”)
# 预期输出：SELECT username, LENGTH(username) as name_length FROM users ORDER BY name_length DESC;

背后的原理： 当你调用 generateSQL 时， SQL_GPT 类内部大致做了以下几件事：

  1. 获取数据库模式 ：通过 INFORMATION_SCHEMA 数据库，查询当前连接数据库的所有表、字段、数据类型等信息，并将其格式化成一段清晰的文本描述。
  2. 构造 Prompt ：将数据库模式描述和你的自然语言问题，按照预定义的模板拼接成一个完整的提示词。模板可能长这样： 
    你是一个专业的SQL专家。请根据以下数据库表结构信息，将用户的问题转换为标准的MySQL SQL查询语句。
只输出SQL语句，不要有任何解释。

数据库结构：
{database_schema}

用户问题：{user_question}

SQL查询语句：
  3. 调用 LLM ：将构造好的 Prompt 发送给配置的 OpenAI 模型。
  4. 解析与返回 ：提取模型返回内容中的 SQL 语句部分（通常就是第一段代码块），返回给调用者。

注意 ：生成的 SQL 不一定总是完美的，特别是对于非常复杂、涉及多表深度关联或特定数据库函数（如窗口函数）的场景。 在将生成SQL用于生产环境前，务必在测试环境进行验证 。这也是为什么这个工具更适合作为“高级助手”而非“全自动代码编写器”。

4.2 SQL 错误检查与修正

这个功能非常实用。当你的 SQL 在执行时报错，可以将错误信息一起喂给 SQL-GPT，让它帮你诊断和修复。

# 假设我们写了一个有问题的SQL
bad_sql = “SELECT username, COUNT(*) FROM users”
error_msg = “SQL执行失败: (1140, In aggregated query without GROUP BY, expression #1 of SELECT list contains nonaggregated column ‘test_db.users.username’; this is incompatible with sql_mode=only_full_group_by)”

corrected_sql = sql_gpt.SQL_ERROR_CHECK(bad_sql, error_msg)
print(f“错误SQL：{bad_sql}”)
print(f“数据库报错：{error_msg}”)
print(f“修正建议：{corrected_sql}”)
# 预期输出可能为：SELECT username, COUNT(*) FROM users GROUP BY username
# 或 SELECT ANY_VALUE(username), COUNT(*) FROM users

实现逻辑： SQL_ERROR_CHECK 方法会构造一个不同的 Prompt，将错误 SQL、数据库返回的错误信息以及当前数据库模式一起发送给 LLM。模型基于对 SQL 语法和语义的理解，结合具体的错误信息，推理出最可能的修正方案。这对于解决那些晦涩难懂的数据库错误信息尤其有帮助。

4.3 文件系统对话

这是另一个强大的模块。它允许你将本地文档（如项目需求书、技术 PDF、日志文件）导入系统，然后像聊天一样向这些文档提问。

from gpt.FILEGPT import File_GPT

file_gpt = File_GPT(persist_directory=“./my_chroma_db”) # 可以指定自定义存储路径

# 1. 添加文件到知识库
# 文件会被读取、分割成小块（如每块500字符），然后通过Embedding模型转化为向量，存入Chroma
file_gpt.addFile(“需求文档.pdf”, “./docs”)
file_gpt.addFile(“api接口说明.md”, “./docs”)
print(“文件已添加并向量化完成。”)

# 2. 向知识库提问
answer = file_gpt.askFile(“我们的产品支持哪些支付方式？”)
print(f“回答：{answer}”)
# 答案将从“需求文档.pdf”和“api接口说明.md”中检索相关信息并生成

# 3. 后续可以继续添加文件或提问，形成持续的知识积累

技术细节与优化：

  1. 文本分割 ：这是影响检索效果的关键。分割得太碎，上下文不完整；分割得太大，会引入无关噪声。项目中可能使用 RecursiveCharacterTextSplitter ，按字符递归分割，尽量保证段落或句子的完整性。
  2. 向量检索 ：当提问时，系统先将问题本身向量化，然后在 Chroma 中计算与所有文本块向量的相似度（如余弦相似度），返回最相似的 K 个块（例如前3个）。
  3. 上下文构造与生成 ：将检索到的相关文本块作为“参考文档”，与原始问题一起构成新的 Prompt，发送给 LLM 生成最终答案。Prompt 模板通常是：“请根据以下上下文信息回答问题：{context} \n\n 问题：{question}”。
  4. Redis 缓存加速 ： File_GPT 类在初始化时可能会连接 Redis。每次 askFile 时，它先计算问题的哈希值（如 MD5），以这个哈希值为 Key 去 Redis 中查找是否有缓存的结果。如果有且未过期，则直接返回，跳过向量检索和 LLM 生成步骤，极大提升重复问题的响应速度。

5. 生产级考量、常见问题与调优

将 SQL-GPT 从一个演示项目变成一个稳定可用的内部工具，还需要考虑很多问题。下面是我在测试和使用中遇到的一些典型情况及其解决方案。

5.1 安全性：重中之重

1. SQL 注入风险： 这是最大的安全隐患。虽然 LLM 生成的 SQL 是动态的，但 SQL_GPT 模块在执行生成的 SQL 时， 务必使用参数化查询 。检查项目源码中执行 SQL 的部分（通常在某个 execute_query 方法里），看它是否使用了像 cursor.execute(sql) 这样的直接执行，还是安全的 cursor.execute(sql, params) 。如果项目没有使用参数化查询，你需要强烈建议修改或自行 Fork 修改。

2. 权限控制： 配置文件中使用的数据库账号（如 root）权限过高。在生产环境中，应该创建一个仅具有特定数据库 SELECT （和必要的 EXPLAIN 、 SHOW ）权限的只读账号。绝对不要赋予其 DROP 、 DELETE 、 UPDATE 等写权限。

3. API Key 管理： 不要将包含真实 API Key 的 config.json 文件提交到 Git 仓库。应该使用环境变量或 .env 文件来管理敏感信息。可以改造代码，优先从环境变量中读取配置。

# 改进思路：在 SQL_GPT 初始化时
import os
openai_api_key = os.getenv(“OPENAI_API_KEY”, config.get(“OPENAI_API_KEY”))

5.2 性能与成本优化

1. Token 消耗与成本： 每次生成 SQL 或文件问答，都会向 OpenAI 发送包含数据库模式或文件上下文的 Prompt，这可能消耗大量 Token（尤其是数据库表很多、结构复杂时）。优化策略：

  • 精简模式信息 ：不是每次都需要发送全库模式。可以根据用户问题中的关键词（如提到的表名），动态选择只发送相关表的结构。
  • 使用更便宜的模型 ：对于简单的 SQL 生成， gpt-3.5-turbo 通常足够且成本远低于 gpt-4 。
  • 实现本地模型 ：对于文件对话，Embedding 模型和对话模型都可以考虑替换为本地模型（如 all-MiniLM-L6-v2 做嵌入，ChatGLM3-6B 做生成），实现零 API 成本。但这需要较强的工程能力。

2. 响应速度：

  • 缓存策略 ：除了项目已实现的 Redis 缓存，对于 SQL 生成，也可以缓存“自然语言问题 - 生成SQL”的对应关系。因为业务问题往往重复。
  • 连接池 ：确保数据库和 Redis 连接被复用，而不是每次请求都新建连接。

5.3 常见错误排查

问题现象 可能原因 解决方案
ModuleNotFoundError: No module named ‘xxx’ 依赖未安装或虚拟环境未激活 检查是否在正确的虚拟环境中，并尝试 pip install xxx
pymysql.err.OperationalError: (2003, “Can’t connect to MySQL server”) 数据库配置错误或服务未启动 1. 检查 config.json 中的 host, port, password。
2. 运行 docker ps 确认 MySQL 容器在运行。
3. 尝试用命令行工具（如 mysql -h host -u root -p ）手动连接。
openai.error.AuthenticationError API Key 无效或余额不足 1. 检查 OPENAI_API_KEY 是否正确，开头是否为 sk- 。
2. 登录 OpenAI 平台检查余额和用量。
redis.exceptions.AuthenticationError Redis 密码错误或未配置 检查 config.json 中 REDIS.password 是否与 Docker 启动时设置的密码一致。
文件问答返回“我不知道”或无关内容 1. 文件未成功向量化。
2. 检索到的上下文不相关。
3. Embedding 模型不适合该类型文本。		 1. 检查 addFile 是否报错，文件路径是否正确。
2. 尝试调整文本分割的大小（chunk_size）和重叠度（chunk_overlap）。
3. 对于中文文档，可尝试换用针对中文优化的 Embedding 模型。
生成的 SQL 语法正确但逻辑错误 LLM 误解了问题或数据库模式信息不足 1. 将问题描述得更精确，例如指明表名“从 orders 表里查”。
2. 在 Prompt 中提供更详细的表关系说明（如外键）。
3. 对于复杂逻辑，采用“分步询问”策略，先让模型生成查询思路，再生成具体 SQL。

5.4 扩展功能设想

基于现有架构，这个项目有巨大的扩展潜力：

  1. Web 图形界面 ：使用 Gradio 或 Streamlit 快速搭建一个 Web UI，让非命令行用户也能轻松使用。可以设计两个标签页，一个用于 SQL 生成，一个用于文件对话。
  2. 历史记录与收藏 ：将用户的历史问答记录保存下来（可存数据库），支持收藏常用的查询模板。
  3. 自定义 Prompt 模板 ：允许高级用户修改发给 LLM 的 Prompt 模板，以适配不同的任务风格或特定数据库方言（如 PostgreSQL 与 MySQL 的差异）。
  4. 结果可视化 ：正如项目 Roadmap 中所说，可以将查询结果自动转化为简单的图表（如折线图、柱状图），这对于数据分析场景价值巨大。
  5. 多轮对话优化 SQL ：实现一个对话状态管理，允许用户说“不对，我的意思是查上个月的订单，不是这个月”，然后模型能基于对话历史修正之前生成的 SQL。

6. 总结与个人实践建议

经过一番深入的探索和实践，SQL-GPT 给我最深的印象是它找准了一个非常具体的痛点，并用当前最可行的技术栈（LLM + 传统数据库/向量库）给出了一个优雅的解决方案。它不是一个炫技的玩具，而是一个能真正融入开发工作流、提升效率的工具。

对于想要引入类似工具的团队或个人，我的建议是：

首先，明确它的定位——一个“副驾驶”而非“自动驾驶” 。它最适合的场景是：

  • 探索性数据分析 ：当你面对一个新数据库，快速了解数据分布和关联。
  • 生成复杂查询的初稿 ：节省你手动编写冗长 JOIN 和子查询的时间。
  • 文档知识库问答 ：快速从大量的项目文档、会议纪要中查找信息。
  • SQL 学习和教学 ：初学者可以通过自然语言和生成 SQL 的对比，快速理解语法。

其次，从“内部工具”开始试点 。先在一个非核心的、数据相对简单的项目上部署，让少数几个同事试用。重点关注：

  1. 生成准确率 ：在你们的业务场景下，SQL 生成的准确率有多高？
  2. 易用性 ：现有的 API 调用方式是否方便？是否需要封装成更友好的形式？
  3. 安全与成本 ：监控 API 调用量和费用，评估安全风险是否可控。

最后，做好“人工审核”这道最终防线 。至少在可预见的未来，所有由 AI 生成的、将要操作生产数据或影响业务决策的 SQL，都必须经过专业开发者的 review 才能执行。你可以将 SQL-GPT 集成到你们的 CI/CD 流程或数据平台中，让它生成 SQL 草案，然后推送给负责人审核确认后再执行。

这个项目的代码结构清晰，模块化程度高，为二次开发提供了很好的基础。无论是想增强其 Prompt 工程以提升准确率，还是替换底层模型以降低成本，都有足够的切入点。开源项目的魅力就在于此，你不仅是在使用一个工具，更是在参与塑造一个未来工作方式的可能。

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

更多推荐

cover

把真实的时间序列数据喂给TimechoAI，让它帮你找异常

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

Python深度学习：从入门到实战

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

【AI大模型接入SDK】名词解释

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