Each language version is independently generated for its own context, not a direct translation.
这篇论文就像是在做一场**“给 AI 编程助手写‘使用说明书’的大调查”**。
想象一下，你刚雇了一位超级聪明但有点“没头没脑”的AI 编程助手（比如 Cursor）。它虽然懂很多代码，但它不知道你们公司的“家规”、不知道你们项目的“装修风格”，甚至不知道你们喜欢用什么“方言”写代码。
如果直接让它干活，它可能会写出风格杂乱、甚至完全不符合你项目要求的代码。于是，聪明的开发者们开始给这位 AI 助手写**“Cursor Rules"（光标规则）——这就好比是给 AI 准备的一份“入职指南”或“项目圣经”**。
这篇论文的研究者们（来自加州大学尔湾分校）就好奇：大家到底在这份“入职指南”里写了什么？大家是怎么写的？有没有什么规律？
他们收集了 401 个开源项目 里的这些规则文件，像侦探一样仔细分析，最后得出了以下有趣的发现：
1. 开发者们都在写什么？（五大类“家规”）
研究者把大家写的规则分成了五大类，我们可以用**“装修房子”**来打比方：
- 🏠 项目信息 (Project Info)：告诉 AI“这是谁的家”
- 内容：这个项目是干嘛的？用了什么技术栈（比如是 Vue 还是 React）？怎么启动？
- 比喻：就像告诉 AI：“这是张三的公寓，用的是北欧风，厨房在左边，别把客厅当卧室用。”
- 📏 约定俗成 (Convention)：告诉 AI“咱们怎么说话”
- 内容：代码命名要什么样？缩进用几个空格？文件放哪个文件夹？
- 比喻：就像规定：“咱们家说话要轻声细语（命名规范），鞋子必须摆在门口（文件结构），不能乱扔袜子（代码风格）。”
- 💡 指导原则 (Guideline)：告诉 AI“做事的哲学”
- 内容：要重视安全吗？要追求性能吗？怎么测试代码？
- 比喻：就像家训：“做人要诚实（代码安全），做事要高效（性能优化），出门要锁门（异常处理）。”
- 🤖 给 AI 的“特别指令” (LLM Directives)：告诉 AI“你怎么思考”
- 内容：这是最有趣的一类！直接教 AI 怎么思考。比如：“遇到不懂的先问清楚，别瞎猜”、“先列计划再动手”、“你要扮演一个资深 Python 专家”。
- 比喻：这是给 AI 的**“思维训练课”**。就像告诉它：“别急着干活，先想三步；如果不确定，就举手提问；记住，你现在是这里的‘技术总监’。”
- 📝 示例 (Example)：告诉 AI“照着这个做”
- 内容：直接给一段好的代码或坏的代码做对比。
- 比喻：就像给 AI 看一张“样板房”照片：“看看这个柜子是怎么打的，照着这个做。”
2. 大家是怎么写的？（几个有趣的发现）
🗣️ 语言不同，写法不同
- 用 JavaScript/PHP 这种“自由奔放”的语言，开发者写的规则特别多，因为怕 AI 乱来，得把规矩定死。
- 用 Go/Java 这种“严谨刻板”的语言，规则反而少一点，因为语言本身就很严格，AI 不容易跑偏。
- 比喻：就像教小孩，教“自由派”小孩（动态语言）得啰嗦点，多立规矩；教“纪律派”小孩（静态语言）只要给个大方向就行。
🏗️ 领域不同，重点不同
- 做网页的：喜欢给很多“示例”，因为网页样式变化太快，得让 AI 看样图。
- 做数据或系统的：喜欢给很多“指导原则”，因为逻辑复杂，怕 AI 算错。
- 比喻：做菜的，如果是做创意菜（前端），得给菜谱和成品图；如果是做精密仪器（后端/系统），得给操作手册和安全条例。
📄 很多人都在“抄作业”
- 研究发现，近 30% 的规则行是直接复制粘贴的！大家喜欢互相抄，或者抄网上的“万能模板”。
- 比喻：就像大家写“家规”时，发现隔壁老王写得挺好，直接拿过来改个名字就用。虽然省事，但有时候可能不完全适合自己家。
🕰️ 越老的项目，越“惜字如金”
- 新创建的项目，大家喜欢写很多关于"AI 该怎么思考”的指令（LLM Directives），因为大家还在摸索怎么跟 AI 相处。
- 老项目，大家更关注具体的项目细节，或者把规则精简了。
- 比喻：刚认识新朋友（新项目），你会拼命介绍自己怎么思考、怎么工作；老朋友（老项目）了，大家默契了，说话就简单直接，只提重点。
3. 这篇论文告诉我们什么？（给未来的启示）
- AI 也需要“懂行”的搭档：现在的 AI 很聪明，但它不懂你的“潜规则”。开发者写的这些规则，其实就是把人类的经验“翻译”给 AI 听。
- 工具需要更聪明：现在的工具（比如 Cursor）还在让大家手动写这些规则，而且很多人都在“抄作业”。未来的工具应该能自动分析你的项目，然后自动生成一份最适合你的“入职指南”，不用大家手动去抄。
- 别把 AI 当傻子，也别把它当神：开发者们发现，有时候写太多废话（比如把 AI 能自己查到的文档也写进去）是浪费空间。我们需要更精准地告诉 AI：“哪些是你不知道的，必须告诉我；哪些是你自己就能查到的，别让我重复。”
总结
简单来说，这篇论文就是**“人类如何教 AI 适应人类工作习惯”的田野调查**。
它告诉我们，开发者们正在努力给 AI 写**“说明书”，从“怎么干活”到“怎么思考”都在教。虽然目前大家还在互相“抄作业”，还在摸索最佳实践，但这标志着人类和 AI 的协作方式正在发生巨大的变化**——我们不再只是给 AI 下命令，而是在培养一个懂规矩、懂业务、懂思考的数字同事。
Each language version is independently generated for its own context, not a direct translation.
1. 研究背景与问题 (Problem)
- 背景：大型语言模型（LLM）在软件工程中的有效性不仅取决于直接的提示词（Prompt），还高度依赖于更广泛的上下文（Context）。在软件开发中，项目的目标、架构和协作规范对代码生成质量至关重要。
- 现状：为了支持这一需求，AI 编程助手（如 Cursor IDE）引入了“规则文件”（Rule Files，如
.mdc 文件），允许开发者编写持久化、机器可读的指令，以编码项目的独特约束。
- 核心问题：尽管这种编写 AI 指令的实践正在增长，但这些指令的具体内容、结构及其对开发者的意义尚未得到系统性研究。缺乏对开发者认为重要内容的理解，可能导致工具设计不当、上下文冗余或 AI 响应质量下降。
- 研究目标：通过大规模实证研究，刻画开发者为 AI 助手提供的上下文类型，建立分类体系，并分析其在不同项目类型和编程语言中的差异。
2. 方法论 (Methodology)
- 数据来源：
- 使用 Sourcegraph 搜索 GitHub 上所有包含
.mdc 文件（Cursor 规则文件）的公开仓库。
- 初始收集 487 个仓库，经过清洗（去除非英文、空文件、模板文件、重复项等），最终获得 401 个有效开源仓库 作为分析对象。
- 数据集包含 1,876 个
.mdc 文件，共 69,409 行代码/文本。
- 分析方法：
- 定性分析（主题分析）：采用归纳法，对 30 个分层抽样的仓库进行人工编码，识别重复模式和主题。
- 混合编码策略：
- 两名研究者对初始样本进行人工编码，构建初步编码方案（Cohen's Kappa = 0.71）。
- 利用大语言模型（LLM，Gemini-2.5-flash）辅助对剩余 371 个仓库进行大规模编码。
- 通过多次运行（3 次）并采用多数投票机制（Majority Vote）确保 LLM 编码的可靠性（与人工编码的一致性 Kappa 约为 0.64-0.65）。
- 量化分析：基于编码结果，分析上下文类型在不同编程语言、应用领域、重复率及时间维度上的分布差异。
3. 关键贡献：上下文分类体系 (Key Contributions & Taxonomy)
研究提出了一个全面的开发者提供上下文分类体系，包含 5 个高层主题 和 20 个详细代码：
- 项目信息 (Project) (85% 的仓库包含)：
- 环境 (Env)：技术栈、构建/运行命令、环境变量。
- 功能 (Func)：架构描述、模块用途、文件关系。
- 变更 (Change)：近期更新、废弃功能说明（类似发布说明）。
- 规范 (Convention) (84% 的仓库包含)：
- 代码风格 (Code Style)：命名、格式化、注释规范。
- 语言/框架特定 (Language/Framework)：特定框架的最佳实践（如 WordPress Hooks）。
- 项目结构 (Structure)：目录组织、文件命名约定。
- 指南 (Guideline) (89% 的仓库包含)：
- 质量保证 (QA)：测试、调试、异常处理。
- 通用编程 (General)：设计模式、模块化、类型安全。
- 沟通 (Comm.)：提交信息、PR 文档规范。
- 其他：性能优化、一致性、UI/无障碍、安全、依赖管理。
- LLM 指令 (LLM Directive) (50% 的仓库包含)：
- 行为 (Behavior)：要求 LLM 提问、验证假设、避免猜测（提示工程技巧）。
- 工作流 (Workflow)：规定多步骤任务执行顺序。
- 角色 (Persona)：定义 LLM 的角色（如“你是 Python 专家”）。
- 格式与粒度：输出格式模板、详细程度控制。
- 示例 (Example) (50% 的仓库包含)：
4. 主要研究结果 (Results)
RQ1: 编程语言的影响
- 静态类型语言（如 Go, C#, Java）：提供的上下文较少。开发者认为类型系统能辅助 LLM 推断，减少了额外说明的需求。
- 动态类型语言（如 JavaScript, PHP）：提供更多上下文，特别是关于指南（Guideline）和项目信息（Project）。PHP 项目尤其多，可能因其风格多样性导致 LLM 难以推断。
- 特定领域语言（如 C#）：包含更多 LLM 指令，可能因为企业级应用对代码安全性要求更高。
- 前端语言（JS/TS）：包含更多“示例”，以应对快速演变的框架和库。
RQ2: 应用领域的影响
- 复杂项目（数据分析、系统基础设施）：倾向于提供更多示例，因为工作流复杂，需要具体参考。
- 稀缺资源领域（如 MCP 工具）：提供更多项目信息，因为缺乏公开文档。
- 高风险/难测试领域（LLM Agent、数据分析）：提供更多指南，强调执行前的谨慎考虑。
RQ3: 规则复用性
- 高复用率：约 28.7% 的代码行是重复的（来自模板仓库如
awesome-cursor-rules 或依赖文档）。
- LLM 指令复用最高：LLM 特定指令的重复率最高（32%），表明这类指令具有通用性，开发者倾向于直接复制。
- 项目特定内容：项目相关内容的重复率较低，开发者更倾向于提供独特信息。
RQ4: 上下文共现
- 全面性：37% 的仓库包含所有 4 个核心类别（项目、规范、指南、LLM 指令），24% 包含所有 5 类。
- 选择性：大多数仓库（80%）包含 3-15 个独特的代码类型，开发者会平衡覆盖范围以避免信息过载。
RQ5: 时间演变
- LLM 指令的变化：较新的仓库（创建后 7 个月内）包含更多 LLM 特定指令，表明开发者对 AI 能力的认知在加深。
- 老仓库：更侧重于项目文档和指南，LLM 指令较少。
- 成熟项目：随着项目成熟，项目细节类上下文略有减少，转而聚焦于核心指南和 LLM 指令的维护。
5. 意义与启示 (Significance & Implications)
- 对工具设计的启示：
- 上下文透明度：开发者经常复制 AI 可能已经能访问的文档内容（如依赖库的规范）。工具应提供“上下文透明度”，告知开发者哪些信息 AI 已知，避免浪费 Token 和上下文窗口。
- 智能规则生成：目前的规则生成多基于通用模板。未来的工具应能根据编程语言和应用领域自动推荐或生成更精准的上下文规则（例如，为 Python 项目推荐更多指南，为 C# 推荐更多项目特定约束）。
- 对开发实践的启示：
- 开发者正在将传统文档规范（如 README、Style Guide）迁移到 AI 协作中，但也开始探索针对 LLM 特性的新指令（如 Chain-of-Thought 引导）。
- 需要教育开发者如何编写针对 LLM 的有效指令，而不仅仅是复制粘贴。
- 未来研究方向：
- 实证评估：需要量化不同上下文类型对 LLM 任务完成质量的具体影响（例如，过多的项目信息是否反而降低了性能？）。
- 纵向研究：随着 LLM 能力的提升，开发者编写规则的习惯将如何演变。
总结
该论文是首个针对 AI 编程助手中“持久化规则文件”的大规模实证研究。它揭示了开发者如何通过结构化指令将项目知识传递给 AI，建立了一个包含 5 类 20 种的详细分类体系。研究发现，虽然大部分内容沿用了传统软件工程文档的规范，但针对 LLM 的特定指令（如行为引导、工作流控制）正在兴起，且其使用模式受编程语言和项目领域显著影响。这些发现为优化下一代 AI 编程助手的上下文管理机制提供了重要依据。