1. 项目概述与核心价值

如果你是一名 macOS 开发者，同时又深度依赖 Anthropic 的 Claude 进行编程辅助和日常对话，那么你很可能对官方的 Claude Desktop 应用又爱又恨。爱的是它提供了一个便捷的桌面入口，恨的是其基于 Electron 的技术栈带来的资源占用和偶尔的响应迟滞。这正是 lockieluke/Claudia 这个开源项目诞生的背景。简单来说，Claudia 是一个使用原生 SwiftUI 框架，对 Claude Desktop 客户端进行的“重制版”。它并非一个功能迥异的新产品，而是一个在保持与原版核心功能（尤其是至关重要的官方认证流程）完全兼容的前提下，追求更佳性能、更低资源消耗和更符合 macOS 设计语言体验的替代选择。

这个项目的核心价值，在于它精准地切入了一个细分但真实的需求痛点：为追求极致效率和系统融合感的 macOS 用户提供一个“更好用”的 Claude 客户端。它直接面向的，是那些已经将 Claude 作为日常“编程伙伴”（Cowork）的开发者、写作者或知识工作者。通过采用 Swift 和 SwiftUI 这一苹果生态的“亲儿子”技术栈，Claudia 理论上能够实现更快的启动速度、更流畅的交互动画、更低的内存占用，并且能更好地集成系统级的特性，比如原生菜单栏支持、更好的快捷键响应以及符合 macOS 设计规范的 UI 细节。对于开发者而言，研究这个项目本身也是一次绝佳的 SwiftUI 实战学习机会，你可以看到一个相对复杂的、涉及网络通信和状态管理的真实应用是如何构建的。

2. 技术选型与架构解析

2.1 为什么是 SwiftUI？

Claudia 选择 SwiftUI 作为其重建的核心框架，这背后是一系列经过深思熟虑的技术决策。首先，从性能角度出发，SwiftUI 作为苹果力推的声明式 UI 框架，与 AppKit 的互操作性良好，并能充分利用 Metal 等底层技术进行渲染，相比基于 Web 技术（如 Electron）的客户端，在绘制复杂界面和滚动长列表时，能提供更稳定、更跟手的帧率。这对于一个以文本对话为核心的应用至关重要，流畅的输入和消息流浏览体验能显著提升工作效率。

其次，开发效率与可维护性。SwiftUI 的声明式语法让 UI 构建和状态绑定变得直观。当对话列表、当前会话内容、模型选择等状态发生变化时，SwiftUI 会自动处理视图的更新，减少了大量手动同步视图与数据的样板代码。这对于 Claudia 这样状态相对复杂（需要管理多个会话、消息历史、认证状态等）的应用来说，能大幅降低 Bug 出现的概率，并提升代码的可读性。

最后，生态与未来兼容性。Swift 是苹果平台的未来，SwiftUI 更是其 UI 开发的战略方向。使用 SwiftUI 意味着 Claudia 能更容易地适配未来 macOS 的新特性（如 Stage Manager、更丰富的快捷键 API），并且为潜在的跨平台到 iOS/iPadOS 提供了技术基础。虽然当前项目聚焦于 macOS，但技术栈的选择为其留下了扩展空间。

2.2 核心架构设计思路

一个聊天客户端，尤其是对接第三方 API 的客户端，其架构通常遵循清晰的分层模式。Claudia 的架构可以推断为以下几个核心层：

  1. 表示层 (Presentation Layer) ：由 SwiftUI Views 和 ViewModels 构成。 View 负责定义 UI 布局和外观，例如消息气泡、输入框、侧边栏会话列表。 ViewModel （或使用 @Observable 模型）则负责持有和准备数据，将来自业务逻辑层的数据转换为视图可以直接使用的格式，并处理用户的输入事件（如发送消息、创建新会话）。这一层严格遵循 SwiftUI 的数据驱动原则。

  2. 业务逻辑层 (Business Logic Layer) ：这是应用的大脑。它包含处理核心业务流程的组件，例如：

    • 会话管理 ：负责创建、加载、保存和删除聊天会话。每个会话包含其唯一的标识符、标题（可能由 AI 生成或用户自定义）、消息历史以及选用的模型（如 Claude 3.5 Sonnet, Haiku 等）。
    • 消息处理流水线 ：当用户发送一条消息时，该层负责组装请求（包含对话历史、模型参数、系统提示等），调用网络层，并处理返回的流式响应。对于流式响应，它需要实时将收到的数据块解析为可显示的文本，并更新到当前会话的消息列表中。
    • 认证状态管理 ：维护用户的登录状态，在需要时触发重新认证流程。

  3. 网络层 (Network Layer) ：使用 Swift 的 URLSession 或更高级的封装（如 Alamofire ）来与 Anthropic 的官方 API 进行通信。这一层的关键职责包括：

    • 构建符合 Anthropic API 规范的 HTTP 请求。
    • 处理 OAuth 2.0 或类似的原生认证流程（这是项目强调的“支持原始认证流程”的核心）。
    • 实现 Server-Sent Events (SSE) 以处理 Claude API 的流式响应，这是实现打字机效果的关键。
    • 管理网络错误、重试逻辑和速率限制。

  4. 数据持久层 (Persistence Layer) ：负责将用户的会话数据、应用设置等保存到本地。在 macOS 上，通常使用 UserDefaults 存储简单设置，而使用 Core Data 或 SQLite（通过 GRDB 等库）甚至纯文件（如 JSON）来存储结构化的会话历史数据。这一层的设计直接影响数据迁移的难易和应用性能。

注意 ：保持与原版认证流程的兼容性是 Claudia 项目的基石。这意味着它很可能没有实现自己的认证服务器，而是通过内嵌 WebView 或系统浏览器，引导用户到 Anthropic 官方页面登录授权，然后通过回调 URL 或某种令牌交换机制获取有效的 API 密钥或会话令牌。这种方式既安全（用户密码不经过第三方应用），又确保了合法性。

3. 关键功能模块实现细节

3.1 认证流程的集成与实现

“支持原始认证流程”是 Claudia 区别于一些需要手动配置 API Key 的第三方客户端的核心特性。其实现路径通常如下：

  1. 启动认证 ：用户在 Claudia 内点击登录按钮，应用会打开一个内置的、隔离的 WKWebView 或调用系统默认浏览器，导航至 Anthropic 专门为 Claude Desktop 设计的 OAuth 授权端点（例如 https://claude.ai/desktop-auth ）。

  2. 用户交互 ：用户在此官方页面上输入自己的邮箱和密码进行登录。这个过程完全发生在 Anthropic 的受信任环境中，Claudia 应用无法窃取用户的凭证。

  3. 回调与令牌获取 ：登录授权成功后，Anthropic 的服务器会将用户重定向到一个预先在 Claude Desktop 应用中注册好的自定义 URL Scheme（例如 claudia://auth-callback ）。这个回调 URL 中会包含一个一次性的授权码（ code ）或直接是访问令牌（ access_token ）。

  4. 令牌交换与存储 ：Claudia 应用会捕获到这个自定义 URL Scheme 的打开事件。如果收到的是授权码，它需要在后台用这个 code 向 Anthropic 的令牌端点发起一个安全的服务器间请求，以换取最终的 access_token 和 refresh_token 。获取到的令牌会被安全地存储在系统的钥匙串（Keychain）中，而不是普通的文件或 UserDefaults ，这是保护敏感信息的最佳实践。

  5. 会话维持 ：使用 access_token 来调用 Claude API。当 access_token 过期时，使用存储的 refresh_token 自动刷新，用户无需重新登录。整个流程对用户而言，体验与原版 Claude Desktop 几乎一致：点击登录 -> 跳转浏览器 -> 输入密码 -> 自动返回应用并已登录成功。

3.2 流式对话与消息渲染

Claudia 作为 AI 对话客户端，其核心体验在于流畅的、实时的对话交互。这依赖于对 Claude API 流式响应（Server-Sent Events, SSE）的良好支持。

网络请求实现 ： 在 Swift 中，处理 SSE 通常使用 URLSession 的 dataTask 或专门的 URLSessionWebSocketTask （虽然 SSE 不是 WebSocket，但 URLSession 可以处理）。关键步骤是创建一个指向 Claude Messages API 流式端点的请求，设置 Accept: text/event-stream 请求头，并在收到数据时进行增量处理。

// 伪代码示例，展示核心思路
let url = URL(string: "https://api.anthropic.com/v1/messages")!
var request = URLRequest(url: url)
request.httpMethod = "POST"
request.setValue("application/json", forHTTPHeaderField: "Content-Type")
request.setValue("text/event-stream", forHTTPHeaderField: "Accept")
request.setValue("Bearer \(accessToken)", forHTTPHeaderField: "Authorization")
// ... 设置请求体（model, messages, max_tokens等）

let task = URLSession.shared.dataTask(with: request) { data, response, error in
    // 处理响应
}
// 或者使用 URLSession 的 delegate 模式来接收分块数据

数据解析与状态更新 ： API 返回的数据是遵循 SSE 格式的文本流，每一条数据以 data: 开头。Claudia 需要实时解析这个流，提取出 JSON 数据块。每个数据块可能包含：

  • type: “message_start” ： 表示消息开始。
  • type: “content_block_delta” ： 这是最重要的类型，其 delta 字段包含了最新生成的一小段文本（可能是一个词或几个字符）。
  • type: “message_stop” ： 表示消息生成结束。

每当收到一个 content_block_delta 事件，业务逻辑层就会将 delta.text 追加到当前正在构建的 AI 回复消息的末尾。由于这个消息对象被 @Published 或 @Observable 包装，SwiftUI 视图会立即检测到变化，并触发 UI 重新渲染，从而在界面上实现“打字机”效果。

UI 渲染优化 ： 为了确保在快速追加文本时 UI 依然流畅，消息显示控件（通常是 Text 或 AttributedString 渲染的视图）需要高效。对于超长的消息，可能需要引入动态加载或虚拟滚动技术（SwiftUI 的 List 或 ScrollView + LazyVStack 对此有良好支持），避免一次性渲染数万字符导致的卡顿。

3.3 会话管理与本地数据持久化

一个实用的对话客户端必须能管理多个独立的会话。Claudia 的会话管理模块需要处理：

  1. 会话模型设计 ：一个 Conversation 对象可能包含以下属性：

    struct Conversation: Identifiable, Codable {
    let id: UUID
    var title: String // 会话标题，可能根据第一条用户消息自动生成
    var messages: [Message] // 消息数组
    var model: String // 使用的模型，如 “claude-3-5-sonnet-20241022”
    var createdAt: Date
    var updatedAt: Date
}

struct Message: Identifiable, Codable {
    let id: UUID
    let role: Role // .user, .assistant
    var content: String // 或更复杂的 ContentBlock 数组
    let createdAt: Date
}

  2. 持久化策略 ：

    • 简单场景 ：对于轻量级需求，可以将 [Conversation] 数组编码为 JSON，直接保存在应用沙盒的 Documents 目录。每次启动时读取，每次变更时写入。这种方法实现简单，但数据量大时读写效率可能成为瓶颈。
    • 推荐场景 ：使用 Core Data 或 SQLite.swift / GRDB 这类 SQLite 封装库。它们能提供高效的关系查询（例如，按更新时间排序所有会话）、增量更新和更好的数据迁移能力。Core Data 与 SwiftUI 的 @FetchRequest 可以无缝集成，自动驱动 UI 更新。

  3. 自动保存与性能权衡 ：为了避免数据丢失，应在每次对话发生变更（新增消息、修改标题）后自动保存。但频繁的磁盘 I/O 会影响性能。一个常见的优化策略是使用“防抖”（debounce）：在数据变更后启动一个定时器（例如 1 秒），如果在定时器触发前又有新的变更，则重置定时器；直到用户停止操作 1 秒后，才执行一次实际的保存操作。

3.4 UI/UX 设计与 SwiftUI 实践

Claudia 的界面需要清晰地区分几个主要区域：侧边栏（会话列表）、主聊天区域、输入框以及可能的设置面板。使用 SwiftUI 可以优雅地实现这一布局。

布局结构 ：

// 简化后的主视图结构
struct ContentView: View {
    @StateObject private var viewModel = AppViewModel()
    @State private var selectedConversationId: UUID?
    
    var body: some View {
        NavigationSplitView {
            // 侧边栏：会话列表
            ConversationListView(
                conversations: viewModel.conversations,
                selection: $selectedConversationId
            )
        } detail: {
            // 主区域：聊天详情
            if let conversation = viewModel.conversation(for: selectedConversationId) {
                ChatDetailView(conversation: conversation)
            } else {
                PlaceholderView() // 空状态视图
            }
        }
    }
}

自定义视图与交互 ：

  • 消息气泡 ：需要根据消息角色（用户/AI）显示不同的背景色和对齐方式。用户消息通常居右，AI 消息居左。可以使用 HStack 结合 Spacer() 来控制对齐。
  • 流式文本效果 ：在显示 AI 流式回复的 Text 视图上，可以添加一个微小的闪烁光标动画，增强“正在输入”的感知。这可以通过一个带有 opacity 动画的 Rectangle 覆盖在文本末尾来实现。
  • Markdown 渲染 ：Claude 的回复常包含 Markdown 格式（代码块、列表、粗体等）。直接使用 Text 无法渲染。需要集成第三方库（如 Down 、 MarkdownUI ）或将富文本转换为 AttributedString 进行显示。这是提升阅读体验的关键点。
  • 快捷键支持 ：通过 .keyboardShortcut() 修饰符为常用操作（如 Cmd+N 新建会话， Cmd+K 聚焦输入框， Cmd+Enter 发送消息）添加快捷键，能极大提升键盘用户的操作效率。

4. 开发、构建与分发实战

4.1 项目环境搭建与依赖管理

要开始贡献代码或自行构建 Claudia，首先需要搭建合适的开发环境。

  1. Xcode 版本 ：由于项目使用 SwiftUI，你需要安装最新稳定版本的 Xcode（例如 15.x 或更高）。这可以从 Mac App Store 免费获取。确保同时安装命令行工具（ xcode-select --install ）。

  2. 获取源代码 ：

    git clone https://github.com/lockieluke/Claudia.git
cd Claudia

    通常，Swift 项目的依赖管理使用 Swift Package Manager (SPM)。打开项目根目录下的 Package.swift 文件或 .xcodeproj / .xcworkspace 文件，Xcode 会自动解析并下载依赖。

  3. 依赖解析 ：在 Xcode 中，打开项目后，导航到 File -> Packages -> Resolve Package Versions 。常见的依赖可能包括：

    • 网络库 ：如 Alamofire ，用于简化 HTTP 请求。
    • Keychain 访问库 ：如 KeychainAccess ，用于安全存储令牌。
    • Markdown 渲染库 ：如 MarkdownUI 。
    • 本地存储库 ：如 GRDB ，如果项目使用了 SQLite。

  4. 配置与运行 ：克隆项目后，你可能需要一些初始配置。检查项目根目录下是否存在 README.md 或 CONTRIBUTING.md 文件，其中通常包含构建说明。直接点击 Xcode 左上角的运行（Run）按钮，尝试构建并运行项目。首次运行可能会失败，因为缺少必要的认证配置（如自定义 URL Scheme 或 API 端点设置），这需要进一步配置。

4.2 项目结构与核心代码导航

一个组织良好的 Swift 项目通常按功能和模块划分目录。Claudia 的代码结构可能如下：

Claudia/
├── ClaudiaApp.swift              // 应用入口，@main
├── Resources/                    // 资源文件（图标、本地化字符串）
├── Models/                       // 数据模型定义（Conversation, Message, User等）
│   ├── Conversation.swift
│   └── Message.swift
├── Services/                     // 业务逻辑与网络服务
│   ├── APIService.swift          // 封装 Anthropic API 调用
│   ├── AuthService.swift         // 处理 OAuth 认证流程
│   └── ConversationService.swift // 会话的增删改查逻辑
├── ViewModels/                   // 连接视图与模型的 ViewModel
│   ├── ConversationListViewModel.swift
│   └── ChatViewModel.swift
├── Views/                        // 所有 SwiftUI 视图
│   ├── Components/               // 可复用组件（MessageBubble, InputBar）
│   ├── ConversationListView.swift
│   └── ChatView.swift
└── Utilities/                    // 工具类（扩展、助手函数）
    └── KeychainHelper.swift

核心文件解读 ：

  • APIService.swift ：这是与 Claude API 通信的核心。你会找到构建请求、发送消息、处理流式响应的方法。重点关注 sendMessage 函数，它很可能返回一个 AsyncThrowingStream 以便在 Swift 并发环境中消费流数据。
  • AuthService.swift ：这里实现了前述的 OAuth 流程。查找 startAuthentication() 、 handleCallback(url:) 等方法，以及如何使用 ASWebAuthenticationSession （系统级的安全浏览器会话）或 WKWebView 。
  • ChatViewModel.swift ：这是聊天界面的“大脑”。它持有当前会话的 Conversation 对象，包含用户输入文本的 @Published 属性，以及一个发送消息并处理流式响应的函数。这个函数会调用 APIService ，并实时更新 Conversation 中 AI 的回复消息。

4.3 构建、调试与打包

  1. 调试技巧 ：

    • 网络请求调试 ：在 APIService 中，使用 URLSession 的代理或打印出完整的请求和响应头、体，对于调试认证失败或 API 错误至关重要。可以临时在控制台打印出 accessToken 的前几位（切勿打印完整令牌！）以确认令牌已正确获取。
    • SwiftUI 预览 ：充分利用 SwiftUI 的预览功能。为 MessageBubble 、 InputBar 等小组件提供静态的预览数据，可以极大地提高 UI 开发的效率。
    • 状态观察 ：使用 Xcode 的调试器或简单的 print 语句，观察 @Published 属性或 @State 变量的变化，确保数据流符合预期。

  2. 打包与分发 ：

    • 代码签名 ：要在真机（自己的 Mac）上运行或分发，你需要一个免费的 Apple Developer 账号（或个人付费账号）来对应用进行签名。在 Xcode 的 Signing & Capabilities 标签页中，选择你的团队。
    • 配置 URL Scheme ：为了让 OAuth 回调能跳回你的应用，必须在 Xcode 项目的 Info 标签页下，添加一个自定义 URL Types。 Identifier 可以填你的 Bundle ID， URL Schemes 填 claudia （与代码中处理回调的 scheme 一致）。
    • 打包归档 ：选择 Product -> Archive 。归档成功后，你可以将应用导出为 .app 文件，直接拖入 Applications 文件夹使用。对于开源项目，更常见的分发方式是通过 Homebrew Cask 或直接发布 GitHub Releases，提供已签名的 .dmg 或 .zip 文件。

实操心得 ：在开发涉及 OAuth 的应用时，一个常见的坑是回调 URL Scheme 不匹配。务必确保 Info.plist 中定义的 URL Scheme、你在 Anthropic 开发者门户（如果 Claude Desktop 有的话）注册的回调 URL、以及代码中处理 onOpenURL 的 scheme 三者完全一致，包括大小写。另一个坑是 Keychain 访问权限，确保你的应用有正确的 Keychain 访问组（Keychain Access Groups）设置，否则可能无法读取之前存储的令牌。

5. 常见问题、优化与进阶方向

5.1 典型问题排查指南

在实际使用或开发 Claudia 时，你可能会遇到以下问题：

问题现象 可能原因 排查步骤与解决方案
无法登录，点击登录无反应或报错 1. 网络连接问题。
2. 自定义 URL Scheme 未正确配置。
3. 认证服务端点变更。		 1. 检查网络，尝试能否访问 claude.ai 。
2. 检查 Xcode 项目 Info -> URL Types 配置，并确保 AppDelegate 或 onOpenURL 已正确设置。
3. 查看项目源码或 Issues，确认认证 URL 是否最新。
登录成功但发送消息失败 1. API 令牌未正确存储或读取。
2. 令牌已过期且刷新失败。
3. 请求格式或模型名称错误。		 1. 使用 Keychain 查看工具（如钥匙串访问）检查令牌是否存在。
2. 查看控制台日志，确认 API 返回的错误信息（如 401, 403）。
3. 对比 APIService 中的请求体与官方 API 文档是否一致。
流式回复不显示或中断 1. SSE 连接被防火墙或代理拦截。
2. 数据解析逻辑有 Bug。
3. 内存压力导致连接被系统终止。		 1. 尝试在简单网络环境下测试。
2. 在 APIService 的流处理回调中打印原始数据，检查是否收到完整事件流。
3. 检查代码中是否妥善处理了网络中断和重连逻辑。
应用卡顿，特别是长对话时 1. 消息历史数据量过大，一次性加载到内存。
2. UI 渲染效率低（如未惰性加载长列表）。
3. 频繁的自动保存操作阻塞主线程。		 1. 实现分页加载，只加载最近 N 条消息。
2. 确保会话列表和聊天消息列表使用 List 或 LazyVStack 。
3. 将数据保存操作移到后台线程，或使用防抖优化。
Markdown 或代码块渲染异常 1. 使用的 Markdown 渲染库有 Bug 或配置不当。
2. AI 返回的内容包含非标准格式。		 1. 尝试更新 Markdown 渲染库到最新版本。
2. 在渲染前，对原始文本进行预处理，清理可能引起问题的字符。
3. 考虑使用 AttributedString 的 MarkdownParsingOptions 进行基础渲染。

5.2 性能与体验优化建议

一个优秀的原生客户端应该在细节上超越 Web 版本。以下是一些可以深入优化的方向：

  1. 内存与存储优化 ：

    • 对话历史分页 ：不要一次性加载所有历史消息。首次只加载最近 50 条，当用户向上滚动到底部时，再异步加载更早的消息。
    • 附件与缓存 ：如果支持文件上传，需要对图片、PDF 等附件进行本地缓存和缩略图生成，避免重复下载。
    • 数据库索引 ：如果使用 SQLite，为会话的 updatedAt 、 createdAt 字段建立索引，可以大幅加快会话列表的排序和查询速度。

  2. 网络与响应优化 ：

    • 智能重试 ：对于网络错误（如超时、5xx 错误），实现指数退避算法的重试机制，而不是立即报错。
    • 请求取消 ：当用户快速切换会话或在消息发送中途点击取消时，确保能正确取消正在进行的网络请求，避免资源浪费和状态混乱。
    • 离线支持 ：至少应将用户发送的消息和 AI 的回复在发送/接收时立即存入本地数据库，即使网络请求失败，界面也已更新，提供“乐观 UI”体验。待网络恢复后，可以提示用户重新发送失败的消息。

  3. UI/UX 细节打磨 ：

    • 文本选择与操作 ：优化消息气泡的文本选择体验，并添加上下文菜单，支持复制、朗读、重新生成等操作。
    • 快捷键全覆盖 ：除了基本快捷键，还可以支持 Cmd+1 、 Cmd+2 快速切换会话， Cmd+/ 聚焦模型选择器等。
    • 系统集成 ：实现全局快捷键（需申请辅助功能权限），让用户在任何地方都能快速唤出 Claudia 并开始对话。支持 macOS 的“聚焦搜索”（Spotlight）集成，快速搜索历史对话内容。

5.3 可能的进阶功能与扩展

Claudia 作为一个开源项目，有巨大的扩展潜力。社区或开发者可以在此基础上添加更多增强功能：

  1. 多模型/多提供商支持 ：除了 Claude，是否可以集成 OpenAI 的 GPT、Google 的 Gemini 或开源的本地模型？这需要设计一个抽象的 AIModelProvider 协议，让不同的 API 服务实现统一的接口。这会将 Claudia 从一个单一客户端升级为一个“AI 工作台”。

  2. 高级提示词管理 ：内置一个提示词库，用户可以保存、分类和快速插入常用的系统提示词或对话开场白。甚至可以支持提示词变量替换。

  3. 本地知识库与检索增强生成（RAG） ：允许用户上传本地文档（TXT, PDF, MD），建立索引。在对话时，能自动从这些文档中检索相关信息，并作为上下文提供给 Claude，实现基于私有知识的问答。这需要集成本地向量数据库（如 LanceDB , Chroma ）和嵌入模型。

  4. 自动化与工作流 ：通过 AppleScript 或 URL Scheme 暴露接口，让其他应用（如编辑器、笔记软件）能调用 Claudia 进行处理。或者内置简单的自动化规则，例如定时总结某个会话的内容并发送邮件。

  5. 完全离线模式 ：集成本地运行的小型开源模型（通过 llama.cpp 或 MLX 框架），在无网络或隐私要求极高的场景下，提供基础的对话能力。

开发这类应用，最大的挑战往往不在于 UI 或某个单一功能，而在于状态管理、数据同步和错误处理的复杂性。如何优雅地处理网络中断时的重连、如何管理多个并发的流式请求、如何保证本地状态与远程 API 的一致性，这些都是考验架构设计的地方。从 Claudia 的项目代码中学习这些问题的解决思路，其价值远超过单纯获得一个可用的客户端。

Logo
DeepSeek技术社区

欢迎加入DeepSeek 技术社区。在这里，你可以找到志同道合的朋友，共同探索AI技术的奥秘。

更多推荐

cover

流式补全与 diff 视图同步的工程实现：DeepSeek-V4 代码助手落地踩坑

avatar DeepSeek技术社区
cover

Gemini 结构化输出 JSON mode 生产实践：DeepSeek 护栏与安全对齐的工程解法

avatar DeepSeek技术社区
cover

RAG 混合检索实战：向量+关键词何时能1+1>2，何时反成灾难？

avatar DeepSeek技术社区