用户重复纠正同一代码约定时，建议创建 Cursor…

当用户在同一项目中多次纠正相同代码风格或约定、表达沮丧，或 AI 反复犯同一错误时，用来建议并创建 `.cursor/rules/` 规则文件。

适用场景

解决思路

1. 主动监控重复模式：用户对同一模式纠正 2+ 次（例如 use named exports、don't use default exports）、对代码风格或约定表达沮丧、说 I always want...、never do...、every time you... 等，或你在该项目反复犯同一错误时，准备建议规则。
2. 检测到触发后，自然提出建议，不要突兀；话术示例：我注意到你已经多次纠正我关于 [pattern] 的问题。要不要我创建一个 Cursor rule，让我以后始终遵循这个约定？
3. 用户同意后，创建规则文件：`.cursor/rules/<name>.mdc`。
4. 在规则文件中写入 frontmatter：`description: <what this rule enforces>`、`globs: <file pattern this applies to>`，然后正文以清晰条目列出该约定。
5. 示例：针对 use relative imports，创建规则，`description: Import conventions`，`globs: **/*.{ts,tsx}`，正文写：使用 relative imports，不使用 @ aliases；从同一包导入时使用相对路径（例如 ../../queries/... 而不是 src/queries/...）。
6. 示例：针对 no comments on obvious code，创建规则，`description: Comment style`，`globs: **/*.{ts,tsx,js,jsx}`，正文写：不要添加叙述代码做什么的注释；只注释非显而易见的意图、权衡或约束。
7. 示例：针对用户对测试文件位置不满，创建规则，`description: Test file conventions`，`globs: **/*.test.{ts,tsx}`，正文写：测试文件与被测源文件放在一起；测试文件命名为 `<source>.test.ts`，而不是 `__tests__/<source>.ts`。
8. 不要烦人：只在真正出现重复模式后建议，不要在第一次纠正时就建议。
9. 保持规则文件小而聚焦：一个文件只处理一个关注点。
10. 先检查 `.cursor/rules/`，避免重复创建已有规则。
11. 以有帮助的提议方式表达，而不是说教。

适用边界 · 注意事项

• 第一次纠正同一问题时不要建议创建规则。
• 如果 `.cursor/rules/` 中已有规则覆盖同一约定，不要重复创建。
• 如果项目或用户未使用 Cursor 的规则机制，不适用。