演进与展望
设计演进简史
Phase 0：规则收集阶段（初期）
项目最初以"awesome-list"风格运作：一个 README 文件列出所有规则文件的链接，用户手动复制文件内容。
问题：
- 规则质量参差不齐，没有验证机制
- 发现规则的体验差（只有一个文本列表）
- 规则格式不统一，frontmatter 字段随意添加
Phase 1：工程化阶段
引入验证脚本和结构化目录：
- 增加
validate-rules.mjs，建立 frontmatter 规范 - 增加
build-rule-catalog.mjs，生成结构化rules.json - VitePress 站点从
rules.json动态渲染规则目录
关键决策：规则文件保持在根目录（ADR-001），生成目录不手动编辑（ADR-002）。
Phase 2：展示层升级（当前阶段）
从单一的"规则浏览器"进化为"技术白皮书 + 学习中心"：
- 增加四个文档章节：入门指南、架构文档、参考手册、高级主题
- 修复 SVG 图标的深/浅色模式兼容性问题（内联 Vue 组件替代
<img>标签） - 增加 Mermaid 架构图，使系统结构可视化
- 增加学术参考与演进文档
当前局限性
坦诚地说，当前版本仍有若干值得改进的地方：
规则内容质量不均匀
部分规则文件的内容深度不足，约定过于泛化（如"使用最佳实践"这类无指导性的表述）。规则内容的质量保证目前完全依赖人工审查。
潜在改进：引入 LLM 辅助的规则内容评估，检测模糊表述并给出改进建议。
缺少规则效果验证
目前没有机制验证"规则是否真的改变了 AI 的行为"。规则的有效性完全依赖经验判断。
潜在改进：构建基准测试集（"给定规则 + 任务，AI 的输出应满足 X 条件"），对规则进行量化评估。
工具绑定
.mdc 格式是 Cursor 专有的。如果开发者切换到 Continue.dev 或 GitHub Copilot，需要手动转换规则格式。
潜在改进：增加格式转换脚本，支持将 .mdc 规则导出为 .cursorrules、copilot-instructions.md 等格式。
未来方向思考
方向 1：规则的语义搜索
当规则库规则数量增长到 100+ 条时，基于关键词的筛选会遇到瓶颈。自然语言语义搜索（"找一个适合我的 React + TypeScript 项目的规则"）可以显著提升发现体验。
这需要：
- 规则的向量嵌入（embedding）
- 相似度搜索接口
- 或直接接入支持 RAG 的 AI 接口
方向 2：规则的自动生成
基于对现有代码库的分析（lint 报告、PR review 历史、代码风格统计），自动建议应该添加哪些规则。这是"从 AI 使用规则"到"AI 帮助生成规则"的转变。
方向 3：规则的社区评分机制
类似 npm 的下载统计，追踪每条规则的使用频率和社区反馈，帮助用户识别"最受认可"的规则。
方向 4：跨工具规则格式标准化
如前文所述，AI 编码规则领域目前缺少跨工具标准。如果多个工具（Cursor、Continue.dev、Copilot）能就一套基础格式达成共识，规则可以跨工具复用，规则库的价值会成倍增加。
归档级别稳定性原则
cursor-rules 的设计哲学有一个重要基调：归档级别稳定性（Archive-Grade Stability）。
这个原则意味着：
- 选择不随时间快速贬值的技术（静态站点优于 SPA，标准 HTML/CSS 优于框架）
- 避免引入维护成本高的依赖
- 优先考虑"10 年后这个仓库还能正常运行吗？"
这不是保守主义，而是对"长期收益"的务实判断。一个规则库的价值在于规则内容本身，而不在于展示它的技术栈有多新颖。
技术选型最好的结局是"无聊但可靠"，而不是"令人兴奋但需要持续维护"。
致谢
cursor-rules 的设计受到以下开源项目的启发：
- PatrickJS/awesome-cursorrules — 规则社区的先行者
- VitePress — 优雅的静态文档框架
- Mermaid — 让架构图成为代码