基于Tauri与Next.js构建本地AI聊天室：隐私优先的RAG与多模型聚合实践

1. 项目概述：一个真正属于你的本地AI聊天室

最近几年，AI聊天工具井喷式发展，但用久了总感觉缺了点什么。要么是数据要上传到云端，心里不踏实；要么是功能被平台限制，想加点自己的知识库或者用个本地模型都麻烦。我自己折腾过不少开源项目，要么配置复杂，要么界面简陋，总想找一个能兼顾隐私、功能和易用性的桌面端解决方案。

直到我遇到了chatless。这个名字起得很有意思，“less”可能意味着更少的依赖、更少的隐私顾虑。它本质上是一个基于Tauri 2.0和Next.js构建的桌面应用，核心思路是“本地优先”。你的所有对话历史、上传的文档、构建的知识库，都老老实实待在你自己的电脑硬盘里，不经过任何第三方服务器。同时，它又像一个灵活的“聚合器”，让你可以自由接入 OpenAI、Claude、DeepSeek 这些云端服务，或者通过 Ollama、LM Studio 调用本地跑的大模型，甚至还能把两者混合使用。

我花了几天时间深度体验和研究了它的代码，发现这不仅仅是一个客户端，更像是一个为开发者或进阶用户打造的“AI工作台”。它解决了我的几个核心痛点：一是数据隐私，敏感的工作文档再也不用担心泄露；二是功能聚合，不用在十几个网页和工具间来回切换；三是扩展性，通过文档解析和本地RAG（检索增强生成），能让AI的回答更精准、更有料。

如果你也厌倦了在浏览器标签页里开一堆聊天窗口，或者担心商业对话数据的安全，想找一个能完全掌控在自己手里的AI助手，那么 chatless 值得你花时间了解一下。接下来，我会从一个实际使用者的角度，拆解它的设计思路、核心功能实现，并分享一些从部署到深度使用的实操经验和避坑指南。

2. 架构与设计思路拆解：为什么是 Tauri + Next.js？

刚接触 chatless 时，我第一个好奇的点就是它的技术选型。市面上桌面应用框架不少，Electron 生态成熟，Flutter 势头正猛，为什么它选择了Tauri 2.0搭配Next.js这套组合拳？深入使用后，我理解了作者背后的权衡。

2.1 核心诉求：极致的性能与隐私

chatless 的定位是“本地优先”的 AI 客户端。这意味着：

1. 数据零上传：所有数据（对话、文档、向量索引）必须存储在本地。
2. 资源占用低：需要长时间驻留后台，资源消耗要尽可能小。
3. 启动速度快：作为工具类应用，即开即用是基本要求。

传统的 Electron 应用，每个实例都打包了一个完整的 Chromium 浏览器内核，内存占用动辄几百MB。对于 chatless 这种可能需要常驻后台、同时处理本地模型推理（哪怕只是调度）的应用来说，这是一个不小的负担。而Tauri的核心优势就在这里：它使用操作系统自带的 WebView（在 Windows 上是 WebView2，macOS 和 Linux 上也有相应实现），将前端代码运行在一个轻量级的原生 Web 视图里。后端则用Rust编写，编译成高效的原生二进制文件。

实测对比：我同时打开一个功能类似的 Electron 应用和 chatless。Electron 应用仅启动后静置，内存占用约为 210MB；而 chatless 在完成初始化、加载了本地 SQLite 数据库后，内存占用稳定在 85MB 左右。对于需要同时开启 Ollama 本地模型（这本身就很吃内存）的用户来说，这节省下来的 100MB+ 内存可能就是能否流畅运行的关键。

2.2 前端选型：Next.js 带来的全栈能力与开发体验

为什么用 Next.js，而不是更轻量的 Vite + React？我认为这体现了 chatless 在“应用”而不仅仅是“界面”层面的思考。

1. 服务端组件与流式渲染：Next.js 15 的服务端组件和流式渲染，非常适合 AI 聊天这种场景。当调用云端 API 或本地模型时，后端（这里指 Tauri 的 Rust 后端）返回的是流式数据。Next.js 的前端架构可以很自然地处理这种数据流，实现打字机效果的消息逐字输出，用户体验更流畅。如果只用纯客户端 React，实现起来会更复杂，且容易阻塞 UI。
2. 一体化路由与数据获取：Next.js 的 App Router 和fetch缓存机制，使得管理复杂的对话列表、会话切换和提示词库变得非常结构化。例如，每个聊天会话可以对应一个路由，状态管理更清晰。
3. 便于功能扩展：虽然目前是一个桌面应用，但 Next.js 的架构为未来可能的“轻量级服务端”需求留有余地。比如，如果未来想增加一个迷你 HTTP 服务器来提供简单的 API 供其他本地工具调用，基于 Next.js 的代码结构会更容易改造。

一个具体的例子：在 chatless 中，设置页面里配置多个 AI 服务商（OpenAI, Anthropic, Ollama），这些配置信息被保存在前端的 Zustand 或 Jotai 状态库中，同时也通过 Tauri 的命令调用 Rust 后端，持久化到本地的 SQLite 数据库。Next.js 的架构让这种“前端状态管理 + 后端持久化”的双向同步逻辑写起来非常顺手。

2.3 数据持久化策略：SQLite 作为单一可信源

所有数据存本地，那用什么存？chatless 选择了SQLite。这是一个非常务实且高效的选择。

• 轻量且强大：SQLite 是一个库，不是一个服务器进程。它直接读写一个磁盘文件，零配置，却支持完整的 SQL 语法、事务、触发器等。对于桌面应用来说，它比启动一个 MySQL 或 PostgreSQL 服务要简单得多，也可靠得多。
• Rust 原生支持优秀：Rust 生态中有rusqlite这样成熟、安全的库，与 Tauri 后端集成无缝。
• 数据结构化：聊天记录、会话元数据、文档块、向量索引（通过sqlite-vss扩展）都可以用关系型数据库很好地组织。相比纯文件存储（如 JSON 文件），查询效率更高，特别是进行 RAG 检索时，需要快速查询向量相似度，SQLite 配合扩展能很好地胜任。

注意：在开发环境中，如果你修改了数据库 schema，可能需要手动清理或迁移数据库文件。chatless 的项目中，数据库文件通常位于$APPDATA/chatless(Windows) 或~/.config/chatless(macOS/Linux) 目录下。在调试时，直接删除这个目录下的.db文件，应用重启后会重新初始化，可以解决很多奇怪的数据库锁死或 schema 不匹配问题。

2.4 安全边界：Tauri 的 IPC 通信机制

隐私安全不能只靠口号。Tauri 的架构天然为安全加分。前端（Next.js）运行在沙盒化的 WebView 中，后端（Rust）是原生代码。它们之间通过一个严格定义的进程间通信（IPC）机制进行交互。

这意味着，前端 JavaScript 代码无法直接访问文件系统、执行系统命令或读取环境变量。任何需要操作本地文件（如保存对话、解析文档）、调用系统资源（如启动 Ollama 进程）或读取敏感配置（如 API 密钥）的操作，都必须通过预先在 Rust 后端定义好的“命令（Command）”来调用。这些命令就像一道道严格审查的关卡，你可以精确控制前端能请求什么、不能请求什么。

例如，前端想读取一个 PDF 文件，它会发送一个read_pdf的 IPC 消息。Rust 后端收到后，会验证文件路径是否在允许的目录内，然后使用pdf-extract这样的库进行解析，最后只将解析出的纯文本内容返回给前端。原始 PDF 文件数据永远不会暴露给可能不安全的 Web 前端环境。

这种设计从根本上杜绝了恶意网站或注入的前端代码窃取你本地数据的可能性，是“本地优先”和“隐私聚焦”得以实现的技术基石。

3. 核心功能深度解析与实操要点

了解了骨架，我们再来看看血肉。chatless 宣称的功能不少，但哪些是核心，用起来到底怎么样？我挑几个最有特色的功能，结合我的实操经验，深入聊聊。

3.1 多模型供应商接入：从配置到混用的实践

这是 chatless 作为“聚合器”的核心价值。它抽象了一个统一的聊天接口，背后可以对接不同的提供商。

配置云端 API： 在设置页面，添加一个 OpenAI 提供商，你需要填的其实就三个关键信息：Base URL、API Key和Model Name。这里有个隐藏技巧：Base URL不一定非得是https://api.openai.com/v1。这意味着你可以用它来对接任何兼容 OpenAI API 格式的代理服务或自建服务，比如常见的http://localhost:11434/v1（Ollama 的 OpenAI 兼容接口）或者一些第三方聚合网关。这大大增强了灵活性。

配置本地 Ollama： 这是让 chatless 真正“离线”起来的关键。你需要在系统上先安装并运行 Ollama，然后拉取模型，比如ollama pull llama3.2:1b。在 chatless 设置中，添加 Ollama 提供商，Base URL填写http://localhost:11434（默认端口），模型名填写你拉取的具体模型名，如llama3.2:1b。

实操心得：Ollama 模型第一次加载会比较慢，chatless 的 UI 可能会显示“超时”或“无响应”。这不是 chatless 的问题，而是 Ollama 在加载模型权重到内存。建议在第一次使用某个本地模型前，先到终端里用ollama run llama3.2:1b手动运行一次，让它完成初始化，之后再在 chatless 里调用就会快很多。

模型切换与混用： 配置好后，在聊天界面左上角或输入框附近，通常会有一个模型选择下拉框。你可以随时在 GPT-4、Claude 3 Sonnet 和本地 Llama 3 之间切换。更高级的用法是，你可以为不同的会话（Session）预设不同的默认模型。比如，一个专门用于代码调试的会话，我设置为使用 DeepSeek Coder；一个用于创意写作的会话，设置为使用 Claude；一个处理本地私有文档的会话，则固定使用 Ollama 上的本地模型，确保数据不出境。

3.2 本地 RAG 知识库：让 AI 真正“读懂”你的文档

RAG（检索增强生成）是目前让大模型获取“新知识”和“精确知识”最有效的方法之一。chatless 的 RAG 功能是完全本地的，流程如下：

1. 文档解析：你上传 PDF、Word 或 Markdown 文件。chatless 的后端（Rust）会调用相应的解析库（如pdf-extract,docx,pulldown-cmark），将文档内容提取为纯文本。
2. 文本分块：一篇长文档会被智能地切割成大小适中的“块”（Chunk）。这里的分块策略很有讲究，直接影响到检索质量。chatless 默认可能采用按段落或固定重叠窗口的分块方式。理想情况下，应避免在句子中间切断，并保持块之间有少量重叠，以防检索时丢失上下文。
3. 向量化嵌入：每个文本块通过一个嵌入模型（Embedding Model）转换为一个高维向量（比如 384 维或 1536 维）。关键点来了：这个嵌入模型也需要在本地运行。chatless 很可能集成了像all-MiniLM-L6-v2这样的轻量级开源嵌入模型，并通过 ONNX Runtime（项目致谢里提到了ort）在 CPU 上高效推理。这一步的计算量不小，但得益于 Rust 和 ONNX 的性能，在普通电脑上也能接受。
4. 向量存储与检索：生成的向量和对应的文本块，被存入 SQLite 数据库，并利用sqlite-vss扩展建立向量索引。当你在聊天中提问时，你的问题也会被转换成向量，然后在向量数据库中进行相似度搜索（通常用余弦相似度），找出最相关的几个文本块。
5. 提示词组装与生成：系统会将你的原始问题，连同检索到的相关文本块，一起组装成一个新的、信息更丰富的提示词，发送给大模型。模型基于这个“增强后”的上下文来生成回答，准确性和相关性会大幅提升。

避坑指南：

• 文档质量是关键：如果原始文档是扫描版 PDF（图片），需要先进行 OCR 识别。chatless 的默认解析器可能处理不了。你需要确保上传的是可选中文本的 PDF。
• 分块大小需要调整：对于技术文档，较小的块（如 256 字符）可能更精准；对于文学性内容，较大的块（如 512 或 1024 字符）能保留更多上下文。如果 chatless 的设置里提供了分块参数，可以根据文档类型微调。
• 检索结果不理想：如果 AI 的回答还是胡言乱语，没有引用到文档内容，首先检查检索步骤。看看它到底检索出了哪些文本块（有些 RAG 系统会显示检索来源）。可能是嵌入模型不适合你的领域，或者需要调整检索时返回的相似块数量（top-k）。

3.3 图片分析与 MCP 协议集成：能力的边界拓展

这两个功能体现了 chatless 的“工作台”野心。

图片分析： 这依赖于支持视觉功能的大模型，如 GPT-4V、Claude 3 Opus 或本地部署的 LLaVA。在 chatless 中，你可以将图片拖拽或粘贴到输入框。应用会将图片编码（如 Base64）并添加到消息的multipart内容中，发送给模型。这对于分析图表、识别物体、解读截图中的信息非常有用。需要注意的是，这会消耗大量 Token，且并非所有模型都支持。使用前请确认你选择的模型具备视觉能力。

MCP（Model Context Protocol）协议集成： 这是一个由 Anthropic 提出的新兴协议，旨在让大模型能够更安全、更标准化地使用外部工具（如计算器、搜索引擎、数据库）。chatless 集成 MCP，意味着它不仅仅是一个聊天界面，而可以成为一个“AI 智能体”的调度平台。通过配置 MCP 服务器，你可以让模型获得实时天气、查询数据库、执行代码等能力。例如，你可以运行一个本地的“计算器 MCP 服务器”，当你在聊天中问“123乘以456等于多少”时，模型会通过 MCP 协议调用这个计算器工具，返回精确结果，而不是自己可能算错。

这个功能目前可能还处于早期，但方向非常前沿。它把 chatless 从一个被动的问答工具，向一个能主动调用工具完成任务的操作系统层面迈进了一步。

4. 从零开始：部署、配置与核心工作流实操

光说不练假把式。下面我以在 macOS 上从源码构建和配置为例，带你走一遍完整的流程，并记录下关键节点和容易踩的坑。

4.1 环境准备与源码构建

首先，你需要一个像样的开发环境。chatless 涉及前端（Node.js）、后端（Rust）和打包（Tauri），工具链稍显复杂。

步骤 1：安装基础依赖

# 1. 安装 Node.js 和 pnpm (推荐版本 Node.js 18+) # 可以从官网下载安装，或用 nvm 管理 nvm install 20 nvm use 20 # 安装 pnpm (比 npm/yarn 更快，更适合 Monorepo) npm install -g pnpm # 2. 安装 Rust 工具链 (通过 rustup) curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh # 安装完成后，重启终端或运行 source $HOME/.cargo/env rustup default stable # 3. 安装 Tauri CLI cargo install tauri-cli # 4. (macOS 特定) 安装创建 DMG 镜像所需的工具 brew install create-dmg

步骤 2：克隆与安装

git clone https://github.com/kamjin3086/chatless.git cd chatless pnpm install # 安装前端依赖，这步可能会花点时间

pnpm install会安装 Next.js、React、UI 组件库以及各种前端工具。同时，它会触发 Tauri 的准备工作，检查 Rust 后端依赖。

步骤 3：开发模式运行

pnpm tauri dev

这个命令会同时启动两个进程：

1. Next.js 开发服务器（通常跑在http://localhost:3000），负责热重载前端代码。
2. Tauri 的 Rust 后端，并启动一个原生窗口加载前端页面。

如果一切顺利，你就能看到 chatless 的应用窗口弹出来了。第一次运行，Rust 需要编译所有依赖，可能会比较慢，请耐心等待。

常见问题排查：

• 错误：error: linkerccnot found：说明缺少 C 编译器。在 macOS 上，运行xcode-select --install安装命令行工具。在 Ubuntu/Debian 上，运行sudo apt install build-essential。
• 错误：Failed to fetch或网络问题：前端依赖安装失败，可以尝试切换 npm 镜像源pnpm config set registry https://registry.npmmirror.com，或检查网络。
• Tauri 编译错误：仔细阅读错误信息，通常是缺少某个系统库。Tauri 官网有详细的 平台依赖说明 ，对照安装即可。

步骤 4：构建生产版本

pnpm tauri build

这个过程会：

1. 构建优化的 Next.js 生产包。
2. 编译 Release 版本的 Rust 二进制文件。
3. 将前端资源打包进二进制文件。
4. 生成对应平台的安装包（macOS 的.app和.dmg，Windows 的.exe和.msi，Linux 的.AppImage等）。

生成的安装包位于src-tauri/target/release/bundle/目录下。你可以直接分发或安装这个包。

4.2 核心工作流配置实战

假设应用已经安装好，我们从一个空白状态开始，配置一个“云端+本地混合”的 AI 工作流。

场景：我想让 chatless 既能用 GPT-4 处理通用问题和复杂推理，又能用本地 Llama 3 模型处理我的私有工作笔记，并且能为这些笔记建立 RAG 知识库。

操作流程：

1. 配置 OpenAI：

   • 打开 chatless，进入设置->AI 提供商。
   • 点击添加提供商，选择OpenAI（或Custom，如果用的是第三方兼容接口）。
   • 名称填GPT-4，Base URL保持默认的https://api.openai.com/v1，在API Key处填入你的 OpenAI Key。
   • 在模型列表里，点击刷新或添加，输入gpt-4-turbo-preview（或其他你拥有的模型名）。保存。

2. 配置本地 Ollama：

   • 确保 Ollama 已在后台运行（终端执行ollama serve）。
   • 在AI 提供商设置页，再次点击添加提供商，选择Ollama。
   • 名称填本地 Llama，Base URL填http://localhost:11434。
   • 点击刷新模型，如果 Ollama 里有拉取好的模型（如llama3.2:3b），它会自动出现在下拉列表中。选择它并保存。

3. 创建并管理会话：

   • 回到主界面，侧边栏点击+ 新会话。
   • 给会话起个名字，比如“技术问题求助”。在会话设置（通常在会话标题旁或输入框上方）中，将默认模型选为GPT-4。
   • 再创建一个新会话，命名为“私有文档分析”，默认模型选为本地 Llama。
   • 这样，我就有了两个独立的工作区，数据隔离，模型专用。

4. 构建本地知识库：

   • 进入私有文档分析会话。
   • 寻找“知识库”或“文档”管理入口（通常在侧边栏或设置中）。
   • 点击“上传文档”或“添加文件夹”，选择你的 PDF、Word 工作笔记。
   • 上传后，chatless 会在后台自动执行“解析 -> 分块 -> 向量化 -> 入库”的流程。界面上应有进度提示。对于大量文档，这可能需要一些时间。
   • 上传完成后，确保在该会话的设置中，开启“启用知识库检索”或类似的选项。这样，在此会话中的每一次提问，都会先从你上传的文档中检索相关信息。

5. 开始对话与验证：

   • 在技术问题求助会话中，问一个编程问题，如“如何在 Rust 中优雅地处理错误？”。观察回答是否来自 GPT-4，且流式输出正常。
   • 在私有文档分析会话中，问一个基于你上传文档的问题。例如，如果你上传了公司项目计划书，可以问“本项目下一阶段的三个主要目标是什么？”。理想的回答应该能准确引用文档中的内容。
   • 如果 RAG 生效，回答中可能会以类似【来源1】...的形式标注出处，或者你可以点击某个按钮查看本次回答引用了哪些文档片段。

4.3 WebDAV 同步提示词的实战细节

这个功能非常实用，尤其是你在多台设备（如公司电脑和家用电脑）上使用 chatless 时，可以同步你精心调教的提示词（Prompts）。

配置步骤：

1. 在设置->同步中，找到 WebDAV 配置。
2. URL：填写你的 WebDAV 服务器地址，例如坚果云的https://dav.jianguoyun.com/dav/，或 Nextcloud/ ownCloud 的地址。
3. 用户名/密码：填写对应的认证信息。
4. 基础路径：填写在 WebDAV 服务器上用于存储 chatless 数据的目录，例如/chatless-sync/。
5. 点击“测试连接”，成功后再点击“启用同步”。

背后的逻辑与注意事项：

• 数据结构：chatless 会将你的提示词集合（可能是一个 JSON 数组）进行“分块”（JSON-Chunk）。每个提示词被保存为一个独立的{id}.json文件，同时还有一个metadata.json文件记录所有提示词的元信息和删除状态（tombstone）。这种设计避免了单个文件冲突，也便于增量同步。
• 删除策略：当你在 A 设备删除一个提示词，chatless 不会直接删除远端的{id}.json文件，而是会在metadata.json中将其标记为deleted_at（逻辑删除）。当 B 设备同步时，读到这个标记，就会在本地也执行删除。这解决了分布式删除的同步冲突问题。
• 冲突解决：如果两台设备同时修改了同一个提示词，后同步的设备可能会遇到冲突。chatless 的策略可能是“以最新修改时间为准”，或者保留两者并标记冲突需要手动解决。具体策略需要看代码实现，使用时建议避免多人同时编辑同一个提示词集。
• 安全提醒：WebDAV 密码会以明文或加密形式存储在本地配置文件中。请确保你的电脑本身是安全的。如果使用公共云盘的 WebDAV，建议为该功能单独创建一个应用密码或子账户，而不是使用主账户密码。

5. 进阶技巧与疑难问题排查实录

用了一段时间，总会遇到一些稀奇古怪的问题。下面是我踩过的一些坑和总结的解决方案，希望能帮你节省时间。

5.1 性能优化与资源管理

chatless 本身很轻量，但当你同时运行它和本地大模型时，系统资源还是会紧张。

• 内存占用过高：
  • 症状：应用卡顿，系统内存告急。
  • 排查：打开系统活动监视器，查看chatless（前端进程）和可能的ollama进程内存占用。
  • 解决：
    1. 清理对话历史：长期不用的会话，特别是包含长上下文或大量附件的，会占用内存和数据库空间。定期导出重要对话后清空。
    2. 限制本地模型参数：在 Ollama 中运行模型时，可以通过参数限制 GPU 层数或使用量化版本。例如ollama run llama3.2:3b --num-gpu-layers 20（仅20层用GPU，其余用CPU）。这能显著降低显存占用。
    3. 调整 RAG 索引：如果知识库文档非常多，向量索引会占用不少内存。考虑将不常用的文档集合暂时从激活的知识库中移除。
• 启动或响应慢：
  • 症状：点击应用图标后很久才打开，或发送消息后很久才开始响应。
  • 排查：首次启动慢通常是 Rust 后端或 SQLite 数据库初始化耗时。响应慢则可能是模型加载或网络问题。
  • 解决：
    1. 确保应用安装在 SSD 硬盘上。
    2. 如果是首次使用本地模型，如前所述，先通过命令行预热模型。
    3. 检查网络连接（针对云端模型）。可以尝试在设置中调整 API 调用的超时时间。

5.2 常见错误与解决方案速查表

5.3 高级调试：日志与数据目录

当遇到无法解决的问题时，查看日志是最直接的方法。

• 日志文件位置：
  • macOS/Linux:~/.config/chatless/logs/或~/.cache/chatless/logs/
  • Windows:%APPDATA%\chatless\logs\或%LOCALAPPDATA%\chatless\logs\里面通常有frontend.log和backend.log，分别记录前端 Next.js 和后端 Rust 的日志。打开它们，搜索ERROR或panic关键词。
• 数据目录：
  • 同样在上述配置目录下，会有data或databases子文件夹，里面存放着 SQLite 数据库文件（如chatless.db）。在应用完全退出后，可以尝试用 SQLite 浏览器（如 DB Browser for SQLite）打开它，检查表结构和数据是否正常。注意：直接修改数据库文件风险极高，可能导致数据损坏，务必先备份！
• 重置应用： 如果问题依旧，可以尝试“核武器”——重置应用数据。此操作会清空所有本地对话、设置和知识库！
  1. 完全退出 chatless 应用。
  2. 删除上述的整个配置目录（如~/.config/chatless或%APPDATA%\chatless）。
  3. 重新启动 chatless，它将回到初始状态。

5.4 安全与隐私的再思考

虽然 chatless 是本地优先，但仍有几个安全层面需要考虑：

1. API 密钥存储：你配置的云端 API 密钥，被加密后存储在本地 SQLite 数据库中。加密的强度依赖于 Tauri 和 Rust 的实现。一般来说，这比放在浏览器 LocalStorage 中安全。但无论如何，不要在公用或不受信任的电脑上使用 chatless 保存重要 API 密钥。
2. 本地模型的安全性：使用本地模型（如通过 Ollama）是隐私性最高的方式，因为数据完全不出设备。但你需要信任所下载的模型文件来源。建议从官方或信誉良好的社区渠道获取模型。
3. 文档内容：RAG 功能会将你的文档内容解析、向量化后存入本地数据库。请确保这些文档本身不涉及极度敏感的信息，或者你完全信任你正在使用的这台设备。
4. 网络请求：即使使用本地模型，chatless 的前端可能仍会加载远程的字体、图标库（如果用了 CDN）。检查网络请求，确保没有不必要的隐私泄露。如果极度敏感，可以考虑在防火墙中禁止 chatless 应用访问互联网（前提是你只用本地模型）。

chatless 为我打开了一扇门，一扇将强大的 AI 能力真正“据为己有”的门。它不是一个完美的产品，在易用性上可能还比不上一些商业软件，在功能深度上也有继续挖掘的空间。但它的设计理念——隐私、可控、聚合、开源——深深地吸引了我。通过自己部署、配置、甚至阅读和修改它的代码，我不仅获得了一个好用的工具，更对现代桌面应用开发、RAG 技术实现、以及本地 AI 应用的架构有了更深的理解。如果你也厌倦了被云端服务“绑架”，渴望一个完全受自己掌控的智能工作伙伴，那么投入一些时间到 chatless 这类开源项目中，绝对是值得的。至少，你的数据，第一次真正地只属于你自己。