Context 注入方案总结
本文总结当前主流 AI Coding 工具中的 Context 注入策略，聚焦三种核心机制：Cursor index 本地 RAG、.cursor/rules 全局注入、@file 运行时注入。
一、Cursor Index 本地 RAG
工作原理
Cursor 使用本地向量数据库（基于 embedding）对项目代码建立索引，在对话时自动检索与当前任务最相关的代码片段作为 context。
核心流程
代码库 → 分块（Chunking）→ Embedding → 向量数据库
↓
用户查询 → 检索相关片段 → 注入 context → LLM 生成关键特性
- 本地处理：索引和检索都在本地完成，适合有隐私要求的代码
- 自动触发：当 AI 需要理解项目结构时自动调用
- 语义检索：基于语义相似度，而非关键词匹配
- 增量更新：文件变更时增量更新索引，无需全量重建
局限性
- Embedding 质量直接影响检索效果
- 长上下文窗口中相关片段可能排名下降
- 多语言混合项目检索精度不稳定
- 无法理解代码的业务逻辑上下文
二、.cursor/rules 全局注入
工作原理
.cursor/rules 是一个 YAML/DSL 格式的规则文件，在项目级别定义 AI 的行为约束、代码风格偏好、业务上下文等。
文件结构示例
yaml
# .cursor/rules/project-context.yaml
version: 1
rules:
- name: api-design
description: API 设计规范
prompt: |
所有 API 必须遵循 RESTful 规范：
- 使用名词复数形式endpoint
- 返回标准 HTTP 状态码
- 统一错误响应格式
- name: testing-require
description: 测试要求
prompt: |
新增功能必须包含对应的单元测试
测试覆盖率不低于 80%关键特性
- 全局生效：对该项目所有对话都有效
- 结构化约束：通过 DSL 表达复杂的规则逻辑
- 持久化：规则随代码版本控制，团队共享
- 优先级控制：可设置规则优先级，处理冲突
局限性
- 规则编写需要学习成本
- 规则过多时可能影响推理速度
- 无法动态适应对话中的即时需求
三、@file 运行时注入
工作原理
在对话过程中，用户通过 @filename 或 @路径 显式引用特定文件/文件夹，AI 将其内容注入到当前 context 中。
使用方式
@src/utils/auth.js # 引用单个文件
@src/components/ # 引用整个目录
@docs/api-spec.md # 引用文档关键特性
- 显式控制：用户精确控制注入哪些 context
- 即时生效：对话过程中随时可用
- 灵活组合：可同时引用多个不同来源
- 会话内共享：被引用内容在当前会话中持续有效
局限性
- 需要用户手动操作，增加认知负担
- 容易引入过多不相关的 context
- 不适合大规模代码库的上下文注入
方案对比
| 维度 | Cursor Index (RAG) | .cursor/rules | @file 运行时注入 |
|---|---|---|---|
| 自动化程度 | 全自动 | 半自动 | 全手动 |
| 精度 | 中等 | 高（明确规则） | 高（用户指定） |
| 覆盖面 | 代码语义层面 | 项目规范层面 | 特定文件层面 |
| 维护成本 | 低（自动索引） | 中（规则编写） | 高（手动管理） |
| 适用场景 | 理解项目结构 | 约束团队规范 | 特定任务参考 |
| 时效性 | 依赖索引更新 | 静态 | 完全实时 |
组合使用策略
最佳实践是组合使用三种方案：
- RAG 为基础层：让 AI 自动理解项目整体结构
- rules 为规范层：定义代码风格、业务约束、团队约定
- @file 为任务层：针对具体任务显式注入关键文件
┌─────────────────────────────────┐
│ @file (任务层) │ ← 精确控制，高优先级
├─────────────────────────────────┤
│ .cursor/rules (规范层) │ ← 项目级约束
├─────────────────────────────────┤
│ Cursor Index (基础层) │ ← 自动理解，背景知识
└─────────────────────────────────┘核心要点
- 三种方案各有侧重，没有绝对优劣
- 组合使用能覆盖不同层面的 context 需求
- 关键是理解每种方案的边界和最佳适用场景
- 过多 context 可能适得其反，需要权衡精度与覆盖