1. 项目概述：从零理解Cursor规则引擎的实战价值

如果你是一名开发者，尤其是深度使用Cursor这类AI编程助手的开发者，你肯定遇到过这样的场景：你希望AI助手在生成代码时，能遵循你团队特定的代码风格、自动导入某些工具库、或者避免写出某些已知的“坏味道”代码。每次在聊天框里重复输入这些要求，不仅效率低下，而且容易遗漏。这正是 cursor_rules_example 这个项目要解决的核心痛点。它不是一个简单的代码片段集合，而是一个关于如何为Cursor AI助手创建、管理和应用“规则”（Rules）的完整示例与最佳实践指南。

简单来说，你可以把Cursor的Rules理解为一份给AI的“编程规范说明书”或“上下文提示模板”。当你在项目中定义了这些规则后，Cursor在为你生成代码、回答问题、甚至重构代码时，都会自动参考这些规则，确保输出结果更符合你的预期和项目规范。 kryst4lskyxx/cursor_rules_example 这个仓库，就是一位资深开发者（kryst4lskyxx）分享的他如何构建这套规则体系的实战记录。它不仅仅展示了规则文件（ .cursorrules ）怎么写，更重要的是，它拆解了背后的设计思路、组织架构以及如何让规则真正发挥效能的经验。对于想要将Cursor从“好用的工具”升级为“懂我的搭档”的开发者来说，这个项目提供了极具价值的路线图。

2. 核心设计哲学：规则不是约束，而是赋能

在深入技术细节之前，理解这个项目背后的设计哲学至关重要。很多开发者初次接触规则时，容易把它当成一种限制AI的条条框框，生怕规则定死了，AI就不灵活了。但 cursor_rules_example 展示的理念恰恰相反： 好的规则是为了解放生产力，而不是束缚创造力。

2.1 从“人适应AI”到“AI适应人”

在没有规则的情况下，我们与Cursor的协作模式是“人适应AI”。我们需要在每次对话中，不厌其烦地交代背景：“我们项目用TypeScript，禁止使用any类型，组件要用函数式，状态管理用Zustand，API调用要用封装好的 useApi 钩子……” 这个过程低效且容易出错。

定义规则后，协作模式转变为“AI适应人”。所有这些上下文和约束，都被预先、静默地注入到了每一次AI交互中。当你简单地说“帮我写个登录表单”，Cursor生成的代码会自动符合你的技术栈和规范，仿佛它已经在你团队里工作了很久。 cursor_rules_example 项目正是致力于构建这样一个高度定制化的、懂你的AI编程环境。

2.2 规则的三层结构：从全局到局部

该示例项目隐含地倡导了一种清晰的三层规则结构，这是其设计上的一个亮点：

  1. 全局规则（Global Rules） ：适用于所有项目的基础规范。例如，代码注释的书写风格（是用 // 还是 /* */ ）、基本的安全警示（如“避免将敏感信息硬编码”）、通用的AI交互指令（如“优先给出解释，再给出代码”）。这些规则通常放在用户主目录的Cursor配置中。
  2. 技术栈规则（Stack-Specific Rules） ：针对特定技术生态的规则。这是 cursor_rules_example 的重点展示部分。例如，针对React项目的一套规则（Hooks使用规范、组件结构）、针对Node.js后端项目的规则（错误处理中间件格式、日志规范）、针对Python数据科学项目的规则（Pandas操作最佳实践、可视化库选择）。这些规则可以作为模板，在创建新项目时引入。
  3. 项目特定规则（Project-Specific Rules） ：最细粒度的规则，定义在单个项目的 .cursorrules 文件中。它包含该项目独一无二的配置：比如API基地址、特有的工具函数库的导入方式、业务领域的专有名词解释、甚至当前正在进行的重构任务的注意事项（例如：“在修改 UserService 时，注意新老接口兼容性”）。

这种分层结构使得规则管理变得模块化和可维护。 cursor_rules_example 通过多个示例文件，演示了如何为不同层级的规则创建模板和继承关系。

3. .cursorrules 文件深度解析与实操要点

项目的核心是 .cursorrules 文件。这是一个纯文本文件，使用一种近似自然语言与YAML/JSON混合风格的语法。它的强大之处在于其描述性，但初学者也可能被其灵活性所困惑。下面我们结合示例，拆解其核心组成部分和书写要点。

3.1 文件结构与基本语法

一个典型的 .cursorrules 文件可能如下所示（基于示例项目的模式归纳）：

# 项目核心规则
This project is a Next.js 14 application using the App Router.

## 技术栈与规范
- Use TypeScript strictly. Avoid `any` type. Prefer `unknown` over `any` when dealing with dynamic data.
- Use Tailwind CSS for styling. Do not write custom CSS unless absolutely necessary.
- State management is handled by Zustand. Do not suggest React Context or Redux for new features.
- HTTP client: Use the wrapped `fetch` utility from `@/lib/api`. It handles auth headers and error parsing automatically.

## 组件约定
- All React components must be function components using the `const ComponentName: React.FC<Props> = () => {}` syntax.
- Use named exports for components.
- Place components in the `/components` directory, grouped by feature (e.g., `/components/auth/LoginForm.tsx`).

## AI交互指令
- When asked to generate code, first provide a brief explanation of the approach.
- If you're unsure about a business logic detail, ask for clarification rather than making assumptions.
- When refactoring, always run the existing tests first and ensure they pass after your changes.

## 禁止事项
- Never write code that contains hardcoded API keys, passwords, or secrets.
- Do not use `console.log` for debugging in production code. Use the logger from `@/lib/logger`.

关键解析：

  • 自然语言为主 ：规则大部分是用英文（或你指定的语言）句子和列表书写的。AI能很好地理解这种指令。
  • 使用标题和列表 ：用 ## 、 - 来组织内容，提高可读性，也帮助AI理解不同规则的权重和范畴。
  • 具体且可操作 ：避免模糊的指令。对比“写好代码”（模糊）和“使用 async/await 处理异步，避免嵌套回调”（具体）。

3.2 规则内容的分类与撰写技巧

根据 cursor_rules_example 的启示，我们可以将规则内容分为以下几类，每类都有其撰写技巧：

1. 项目上下文与架构说明： 这是规则的基石。告诉AI项目的基本情况。

  • 技巧 ：像给一位新加入的开发者介绍项目一样写。包括框架版本、主要库、目录结构、架构模式（如MVC、Clean Architecture）。
  • 示例 ：“这是一个基于NestJS的微服务，使用Monorepo管理，主服务在 apps/api 目录下，共享代码在 libs 目录下。数据库使用Prisma ORM。”

2. 编码规范与风格指南： 将你的ESLint配置、Prettier规则用自然语言描述出来。

  • 技巧 ：无需复制所有ESLint规则，提炼核心。强调团队最在意、最容易出错的部分。
  • 示例 ：“使用双引号。缩进为2个空格。在 import 语句后保留一个空行。React组件props的类型定义必须使用 interface 。”

3. 工具库与工具函数的使用规范： 指导AI如何正确使用项目内封装的工具。

  • 技巧 ：给出确切的导入路径和使用示例。这能极大减少AI生成代码后需要手动修改的工作量。
  • 示例 ：“日期处理统一使用 dayjs 库，从 @/utils/date 导入配置好的 dayjs 实例。表单验证使用 zod ，模式定义应放在 /schemas 目录下。”

4. 安全与最佳实践： 强制性的安全红线。

  • 技巧 ：使用“Always”（总是）、“Never”（绝不）等绝对性词语，引起AI足够重视。
  • 示例 ：“Never suggest SQL string concatenation. Always use parameterized queries via Prisma or query builders.” “用户密码必须使用 bcrypt 哈希后再存储。”

5. AI交互行为设定： 调整AI与你对话和输出代码的方式。

  • 技巧 ：这部分非常个性化。你可以要求AI“思维链”更详细，或者更简洁。
  • 示例 ：“When generating a complex function, break down the logic step by step in comments before writing the code.” “优先给出代码，解释可以简短。”

注意 ：规则不是越多越好。过于冗长复杂的规则文件可能会让AI困惑，或拖慢响应速度。 cursor_rules_example 的精髓在于展示如何通过良好的组织（分层、分模块）来保持规则的有效性和可管理性。建议从一个核心的、经常需要重复强调的规则子集开始，逐步迭代。

4. 高级用法与模块化规则管理

当规则越来越多，管理单个庞大的 .cursorrules 文件会变得困难。 cursor_rules_example 项目更高级的价值在于它暗示或示范了模块化管理的思路。

4.1 规则的分割与引用

虽然Cursor官方可能尚未直接支持 #include 这样的语法，但我们可以通过策略实现模块化：

  1. 按功能分文件 ：创建 rules-frontend.md 、 rules-backend.md 、 rules-ai-behavior.md 等文件。
  2. 在主规则文件中聚合 ：在项目的 .cursorrules 文件中，你可以这样写： 
    # 项目总规则
请严格遵守以下所有规则文件中的约定：

## 前端规则
（此处粘贴或描述`rules-frontend.md`的核心内容摘要，或指示AI参考该文件）
- 技术栈：React 18, TypeScript, Vite.
- 样式：CSS Modules with Sass.
- （更多关键点...）

## 后端规则
（此处粘贴或描述`rules-backend.md`的核心内容摘要）
- 框架：Express.js with TypeScript.
- 数据库：PostgreSQL with Drizzle ORM.
- （更多关键点...）

## 完整规则请参阅项目根目录下的 `docs/cursor-rules/` 目录。
    实际上，你可以将详细的规则放在 docs 目录下，而在根目录的 .cursorrules 中提供一个精炼的索引和最关键、最通用的指令。AI在理解项目上下文时，会读取 .cursorrules ，而其中的指引可以让你在对话中更便捷地让AI去参考那些详细文档（例如，你可以说：“请根据我们 docs/cursor-rules/frontend.md 中的样式规范来修改这个组件”）。

4.2 动态上下文与“当前任务”规则

一个非常实用的高级技巧是利用规则来设置“当前工作焦点”。例如，你正在重构用户认证模块，你可以在 .cursorrules 文件的顶部或特定区域添加一个临时章节：

## [当前重点任务 - 2024-05-27]
我们正在重构认证流程，将所有`/api/auth/*`端点从REST迁移到GraphQL。
- 新的GraphQL模式定义在 `src/graphql/schema/auth.graphql`。
- 旧的REST控制器（`AuthController`）将被弃用。
- 在修改相关代码时，优先参考 `src/modules/auth/graphql-resolvers.ts` 中的新实现。
- **重要**：保持现有用户的会话兼容性。

这相当于给AI设置了一个“临时上下文”，让它在一段时间内的所有代码建议都围绕这个核心任务进行，极大地提升了重构和专项开发的效率。 cursor_rules_example 项目体现了这种“规则即动态上下文”的思想。

4.3 规则与项目配置文件的结合

最有效的规则，往往是那些与项目现有工具链无缝结合的规则。例如：

  • ESLint/Prettier ：在规则中写明“代码风格以项目中的 .eslintrc.js 和 .prettierrc 为准”。AI虽然不能直接读取这些配置的细节，但知道存在这些约束。
  • TypeScript配置 ：强调“严格遵守 tsconfig.json 中的 strict: true 模式”。
  • 测试框架 ：要求“为新功能编写测试，使用项目中已有的Jest/Vitest配置和工具函数”。

通过规则引用这些实体配置文件，你建立了一个从AI到现有开发工具的桥梁，确保了规则不是空中楼阁，而是扎根于项目现有的质量保障体系之中。

5. 实战：为一个全栈项目创建规则集

让我们跟随 cursor_rules_example 的范式，为一个假设的“全栈待办事项应用”（Next.js + FastAPI）创建一套实用的规则集。我们将创建两个核心规则文件。

5.1 前端（Next.js）规则文件： .cursorrules.frontend 

# 前端项目规则 (Next.js 14 + TypeScript + Tailwind)

## 项目概览
这是一个使用Next.js 14 App Router构建的待办事项应用前端。UI库为Shadcn/ui，状态管理使用Zustand，HTTP客户端为TanStack Query (React Query)。

## 核心开发规范
1. **TypeScript**：启用严格模式。所有函数参数和返回值必须有明确类型。优先使用`interface`定义对象类型。
2. **路由与布局**：页面组件定义在`/app/(route-group)/page.tsx`。共享布局放在`/app/layout.tsx`。使用`<Link>`组件进行客户端导航。
3. **组件设计**：
   - 所有通用UI组件位于`/components/ui`，使用Shadcn/ui的CLI生成和更新。
   - 业务组件按功能模块组织在`/components`下，如`/components/todo`。
   - 组件使用`const TodoList: React.FC<TodoListProps> = ({ todos }) => { ... }`格式声明。
   - Props使用`interface`定义，并添加JSDoc注释说明。

## 数据获取与状态
1. **服务端数据**：在Server Component中使用`async/await`直接获取数据。对于需要缓存的请求，使用`fetch`并配置`next: { revalidate: 60 }`。
2. **客户端状态**：使用Zustand。Store定义在`/lib/stores`目录下。每个Store应是一个独立的hook（`useTodoStore`）。
3. **服务端状态（API数据）**：**必须**使用TanStack Query。Query Key工厂函数在`/lib/api/query-keys.ts`。所有API调用封装在`/lib/api`目录下的自定义hooks中（如`useTodos`）。

## 样式与UI
- 唯一样式方案是Tailwind CSS。禁止编写`.css`、`.scss`或`styled-components`文件。
- 使用Shadcn/ui的预制组件作为基础，通过`className`属性覆盖样式。
- 响应式设计优先：使用移动端优先的断点（`sm:`, `md:`, `lg:`）。

## API交互规范
- 所有后端API调用**必须**通过`/lib/api/client.ts`中导出的`apiClient`实例进行。它已配置基地址和认证令牌拦截器。
- 错误处理：使用`apiClient`的统一错误处理。在UI中，使用`@/components/ui/alert`显示错误信息。

## AI协作指令
- 生成组件时，请同时提供该组件对应的`interface`定义。
- 当被要求实现一个功能时，先分析是否需要创建新的Store、API Hook或UI组件。
- 在修改涉及数据流的代码时，提示可能受影响的关联组件。

5.2 后端（FastAPI）规则文件： .cursorrules.backend 

# 后端项目规则 (FastAPI + SQLModel + PostgreSQL)

## 项目概览
这是待办事项应用的后端API服务，基于FastAPI框架。使用SQLModel作为ORM，PostgreSQL数据库。遵循依赖注入和仓库模式。

## 代码结构与架构
1. **项目布局**：
   - `app/main.py`: 应用入口。
   - `app/api/v1/`: API路由端点。
   - `app/models/`: SQLModel数据模型定义。
   - `app/schemas/`: Pydantic请求/响应模型。
   - `app/crud/`: 数据库操作（CRUD）层。
   - `app/services/`: 业务逻辑层。
   - `app/dependencies/`: FastAPI依赖项（如数据库会话）。

2. **分层职责**：
   - 路由层 (`api/`)：只处理HTTP相关逻辑（路径、方法、依赖注入），调用服务层。
   - 服务层 (`services/`)：包含核心业务逻辑，调用CRUD层。
   - CRUD层 (`crud/`)：封装所有数据库操作，返回Pydantic模型或SQLModel实例。
   - 模型层 (`models/` & `schemas/`)：定义数据结构。

## 开发规范
1. **类型注解**：所有函数必须使用完整的Python类型提示（Type Hints）。
2. **异步处理**：数据库操作和外部API调用**必须**使用`async/await`。路由处理函数定义为`async def`。
3. **错误处理**：使用FastAPI的`HTTPException`。业务逻辑错误应定义在`app/exceptions.py`中，并配套相应的异常处理器。
4. **依赖注入**：数据库会话等应通过FastAPI的`Depends`注入，而不是在函数内直接创建。

## 数据库与模型
1. **模型定义**：使用SQLModel的`SQLModel`类。每个模型需在`app/models/__init__.py`中导出。
2. **关系定义**：使用SQLModel的`Relationship`。注意避免循环导入。
3. **迁移**：使用Alembic。模型变更后，需生成新的迁移脚本。

## API设计规范
1. **响应格式**：所有成功响应统一包装为`{"data": ..., "message": "success"}`格式。使用`app/schemas/responses.py`中的`StandardResponse`模型。
2. **错误响应**：错误响应格式为`{"error": {"code": "...", "detail": "..."}}`。
3. **文档**：所有端点必须包含详细的`summary`和`description`。复杂的请求体需要用Pydantic模型清晰定义。

## 安全与性能
1. **认证**：使用JWT，依赖项`get_current_user`定义在`app/dependencies/auth.py`。
2. **密码**：使用`passlib`的`[bcrypt]`上下文进行哈希。
3. **查询优化**：避免N+1查询。使用SQLModel的`select`进行关联数据的主动加载。
4. **环境变量**：所有配置从`app/core/config.py`读取，该文件基于Pydantic的`BaseSettings`。

## AI协作指令
- 创建新API端点时，请按照“路由 -> 服务 -> CRUD -> 模型/模式”的顺序生成代码框架。
- 当涉及数据库查询时，提示是否需要添加索引。
- 在生成Pydantic模式时，考虑字段的验证规则和示例值。

5.3 项目根规则文件： .cursorrules

最后，在项目根目录创建一个简洁的 .cursorrules 文件，作为总入口和跨栈通用规则的存放地：

# 全栈待办事项应用 - Cursor规则总览

**欢迎，AI助手！请仔细阅读并遵循以下所有规则。**

## 项目简介
这是一个全栈的待办事项应用。前端是Next.js，后端是FastAPI。两个子项目的详细规则位于：
- 前端规则：`/.cursorrules.frontend`
- 后端规则：`/.cursorrules.backend`

**在进行任何代码操作前，请先确认你正在处理前端还是后端代码，并严格遵守对应规则文件。**

## 跨栈通用规则
1. **代码质量**：保持代码简洁、可读。使用有意义的变量名和函数名。
2. **注释**：为复杂的业务逻辑添加注释，解释“为什么”这么做，而不是“做了什么”。
3. **提交信息**：（提示）在生成与Git相关的代码或文档时，请遵循Conventional Commits格式。
4. **安全第一**：任何时候都不要生成或建议包含硬编码密钥、密码或内部URL的代码。
5. **沟通**：如果你对某个业务规则或实现细节不确定，请主动提问澄清，而不是做出可能错误的假设。

## 当前开发重点 (2024-05-27)
- 前端：正在实现任务的拖拽排序功能，请参考`/components/todo/TodoBoard.tsx`的现有结构。
- 后端：`/todos`端点正在添加基于标签的过滤功能，相关模式已在`app/schemas/todo.py`中更新。

---
*规则最后更新：2024-05-27。规则是动态的，会随项目演进。*

通过这样的结构，你将拥有一个强大、有序且易于维护的AI编程规则体系。前端和后端开发者可以专注于各自领域的规则，而根规则则确保了跨栈协作的一致性和当前任务的聚焦。

6. 常见问题、调试技巧与经验实录

即使有了完善的规则，在实际使用中也可能遇到AI“不听话”的情况。以下是一些从实战中总结的排查思路和技巧。

6.1 规则不生效？排查清单

  1. 文件位置与名称 ：确保规则文件名为 .cursorrules （注意开头的点），并且位于项目的 根目录 下。Cursor通常从这里读取规则。子目录下的规则文件可能不会被自动加载。
  2. 语法与格式 ：检查规则文件是否有明显的语法错误，比如不匹配的括号、奇怪的字符。尽量使用清晰的Markdown式标题和列表。过于复杂或矛盾的指令可能导致AI理解偏差。
  3. 规则冲突与优先级 ：如果你在用户全局配置和项目规则中都定义了同名或矛盾的规则，其优先级行为可能不明确。一个最佳实践是： 项目规则应包含所有必要指令 ，并假设它是唯一的规则来源。在项目规则中，你可以明确声明“忽略其他全局规则”。
  4. AI的“注意力”限制 ：Cursor的上下文窗口有限。如果 .cursorrules 文件非常巨大（例如超过几千字），AI可能无法完全“记住”或有效处理所有规则。这就是为什么 模块化和精炼化 如此重要。将最核心、最常用的规则放在文件最前面。
  5. 重启Cursor或重载项目 ：有时，新添加或修改的规则可能需要重启Cursor IDE，或者关闭再重新打开项目，才能被正确加载到AI的会话上下文中。

6.2 提升规则效能的经验技巧

  1. 用示例说话 ：对于复杂的规范，光有文字描述不够。在规则中直接嵌入一个小代码示例，效果极佳。 
    ## 正确的错误处理示例
// 好的做法：
try {
  const data = await apiClient.get('/items');
  return data;
} catch (error) {
  // 使用项目封装的日志工具
  logger.error('Failed to fetch items', error);
  // 抛出统一的错误类型，供UI层捕获
  throw new AppError('FETCH_FAILED', 'Could not load items');
}

// 避免的做法：直接使用 console.error 或静默吞掉错误。
  2. 定义“人物角色” ：给你的AI助手一个“人设”，这能奇妙地改变它的响应风格。 
    # 你是一位经验丰富、注重代码质量和可维护性的高级全栈工程师。你思维严谨，喜欢在动手前先厘清需求，并乐于解释你的设计决策。
  3. 迭代优化，从问题中学习 ：规则文件不是一蹴而就的。当你发现AI反复犯同一个错误时，就把纠正这个错误的明确指令添加到规则中。例如，如果AI总是忘记导入你的工具库，就增加一条：“在生成使用到 @/lib/utils 中函数的代码时，请务必在文件顶部添加相应的import语句。”
  4. 区分“强制”与“建议” ：使用强烈的词语（ Must , Never , Always , 禁止 , 必须 ）来表示强制性规则。使用（Prefer, Consider, It‘s recommended to）来表示建议。这有助于AI判断规则的严格程度。
  5. 结合 .cursor/misc 文件 ：Cursor项目目录下的 .cursor/misc 文件夹可以用来存放更详细的文档、架构图或设计稿。你可以在规则中引导AI去参考这些文件，例如：“关于数据库ER图，请参考 .cursor/misc/er-diagram.png 。”

6.3 实测案例：规则如何改变输出

假设没有规则，你让Cursor“创建一个新的用户注册API端点”。

没有规则的输出可能：

  • 随意选择一个框架（比如Flask）。
  • 使用原始的SQL拼接，存在SQL注入风险。
  • 密码可能明文存储。
  • 代码结构随意，不符合项目现有模式。

在应用了上述后端规则后，输出会被显著规范：

  1. 框架选择 ：它会自动选择FastAPI，因为规则里指定了。
  2. 代码结构 ：它会按照“路由 -> 服务 -> CRUD -> 模型”的层次生成文件或代码块。
  3. 安全 ：它会使用Pydantic模型验证输入，使用 passlib 哈希密码，并使用参数化查询（通过SQLModel）。
  4. 符合规范 ：响应格式会自动包装成 StandardResponse ，并包含合适的文档字符串。
  5. 上下文感知 ：它甚至可能会问：“用户模型是否已经定义了 email 和 hashed_password 字段？我需要先确认 app/models/user.py 中的结构。”

这种差异，正是精心设计的规则带来的巨大价值。它让AI从一个需要详细指导的新手，变成了一个熟悉项目所有章程的资深协作者。

7. 规则体系的维护与团队协作

将 cursor_rules_example 的理念扩展到团队环境，规则文件就成为了团队知识沉淀和新人 onboarding 的重要资产。

  1. 版本控制 ：将 .cursorrules 及其相关的模块化规则文件纳入Git版本控制。这样，规则的变更历史清晰可见，团队成员可以共同维护和更新它。
  2. 代码审查的一部分 ：当规则文件发生变更时，应像代码变更一样进行审查。讨论“为什么增加这条规则？”、“这条规则是否足够清晰？”、“会不会造成意想不到的限制？”。这能促进团队对编码规范达成共识。
  3. 新人快速上手 ：新成员加入项目时，除了阅读README，让他们仔细阅读 .cursorrules 文件是了解项目技术栈、架构和编码习惯的最快途径。他们可以立即用符合规范的姿势开始编码，而AI助手会在这个过程中提供一致的引导。
  4. 作为活文档 ：规则文件本身就是一份永远最新的、可执行的开发文档。当技术栈升级（例如从React 17升级到18），第一时间更新规则文件，就能确保所有AI生成的代码都基于新版本的最佳实践。

kryst4lskyxx/cursor_rules_example 这个项目，其意义远不止于几个示例文件。它为我们展示了一种与AI协同编程的新范式：通过清晰、结构化、可维护的指令集，将人类的项目智慧和团队规范，无缝地注入到AI的每一次代码生成和问题解答中。这不仅仅是提升效率，更是在规模化团队开发中，保障代码库一致性、安全性和可维护性的关键一步。开始构建你的规则体系吧，让你的Cursor真正成为你项目的“编外核心成员”。

# 代码规范
Logo
DeepSeek技术社区

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

更多推荐

cover

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

avatar DeepSeek技术社区
cover

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

avatar DeepSeek技术社区
cover

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

avatar DeepSeek技术社区