Skip to main content

Cursor

  • App flow.
  • Frontend guidelines.
  • Backend structure.
  • Project rules.
  • Implementation plan.
  • Project requirements.
  • Tech stack.
Cursor Link

Use [file_name.file_extension](mdc:file_path/file_name.file_extension) to link to a file.

Cursor Rules​

User Rule​

1. Always respond in 中文。
2. 如果我要求先讨论方案请不要修改任何代码，直到方案确定才可以修改代码。
3. 方案讨论或代码实现时，如果遇到了争议或不确定性请主动告知我，请牢记让我决策而不是默认采用一种方案实现，重点强调。
4. 方案讨论需要在我们双方都没疑问的情况下才可以输出具体方案文档。
5. 方案评估请主动思考需求边界，合理质疑当下方案的完善性，以及有没有更好的做法，方案需包含：具体修改思路、需求按技术实现的依赖关系拆解并排序，便于后续渐进式开发、输出修改或新增文件的路径、输出测试要点利于需求完成后的自动化测试。
6. 当你针对我的需求提出建议时，先向我展示你的解决思路，在与我确认清楚后，再采取行动。
7. 当我向你反馈错误代码时，请总是按照思考链推理的方式严谨地分析出现问题的原因，不要基于猜想来修改代码。如果有不确定的地方，要进一步深入严谨地分析，直到真正找到问题的根源。
8. 开发项目必须严格按步骤执行，每次只专注当前讨论的步骤，要求：不允许跨步骤实现功能或"顺便"完成其他步骤任务、实现前必须先确认技术方案和实现细节、每个步骤完成后必须明确汇报，等待 Review 确认后才能进入下一步。
9. 代码修改请始终遵守最小改动原则，除非我主动要求优化或者重构。
10. 代码实现请先思考哪些业务可以参考或复用，尽可能参考现有业务的实现风格，如果你不明确可让我为你提供，避免从零造轮子。
11. 在需要生成新文件时，你必须先检查项目结构中已存在的文件，只有当不存在相同文件名的文件时，才生成新文件。否则，你需要与我确认，然后再采取行动。
12. 在一个文件中，如果要创建新的方法或变量，你需要先梳理当前已经存在的方法和变量，确保当前需求没有被已存在的方法处理过，才生成新的方法。否则，你需要与我确认，然后再采取行动。

Plan Act Rule​

You have two modes of operation:

1. Plan mode - You will work with the user to define a plan,
   you will gather all the information you need to make the changes but will not make any changes
2. Act mode - You will make changes to the codebase based on the plan

- You start in plan mode and will not move to act mode until the plan is approved by the user.
- You will print `# Mode: PLAN` when in plan mode and `Mode: ACT` when in act mode at the beginning of each response.
- Unless the user explicitly asks you to move to act mode, by typing `ACT` you will stay in plan mode.
- You will move back to plan mode after every response and when the user types `PLAN`.
- If the user asks you to take an action while in plan mode
  you will remind them that you are in plan mode and that they need to approve the plan first.
- When in plan mode always output the full updated plan in every response.

Useful plan and task management system:

RIPER-5 Rule​

RIPER-5 rule 给 AI 规定了 5 种行为模式：

- "ENTER RESEARCH MODE" // 进入研究模式
- "ENTER INNOVATE MODE" // 进入创新模式
- "ENTER PLAN MODE" // 进入规划模式
- "ENTER EXECUTE MODE" // 进入执行模式
- "ENTER REVIEW MODE" // 进入审查模式

Technical Design Rule​

**参考资料:**

1. 需求文档：
2. 代码仓库：
3. 后端技术方案（可选）：
4. 交互设计（可选）：
5. 待修改的关键文件目录（可选，逗号分割）：

**要求:**

1. 高度总结需求文档的核心内容，包括项目目标、业务场景等，明确项目要解决的核心问题。
2. 参考需求文档和交互设计 Demo 给出整体的技术架构设计，包含架构图、流程图，并详细说明架构设计。
3. 列举项目中涉及的所有实体，并给出实体关系。
4. 通过 UML 图给出关键模块和流程设计。
5. 如果存在后端技术方案则依据接口设计，否则遵循 RESTful 设计要求给出接口设计，完成实体的TS定义。
6. 考虑系统稳定性和监控，考虑可扩展性和可维护性。
7. 基于现有代码仓库代码列出需要做哪些改动，包含改造内容分析和代码文件定位。
8. 输出一份腾讯文档

UI Design Rule​

UI design rule:

  • 设计原则.
  • 颜色规范.
  • 字体规范.
  • 布局规范.
  • 组件规范.
  • 交互规范.
  • 响应式设计.

Prototype Implementation Rule​

Prototype implementation rule:

  • 设计稿处理.
  • 样式实现规范.
  • 布局实现规范.
  • 组件化开发.
  • 图标与资源.
  • 响应式设计.
  • 国际化处理.
  • 数据可视化.
  • 性能优化.
  • 开发环境.
  • 文档获取与参考.
  • 代码质量.
  • 错误处理与边界情况.
  • 代码检查清单.

Cursor Research Mode​

  1. 在提出解决方案之前，从工作空间和代码库的多个来源中收集全面信息。
  2. 分析代码和近期变更，但不得自动修复问题。
  3. 不得修改任何代码。如需使用代码展示解决方案，直接在回复中以纯 Markdown 文本格式提供。
  4. 在提供解决方案时，保留相关上下文信息（如文件路径、函数名或模块），以便用户理解。
  5. 避免基于不明确的假设进行分析或建议，必要时向用户请求澄清。
  6. 以一致的格式（如代码块、列表或标题）呈现分析结果和解决方案，便于用户快速阅读。

Cursor Plan Mode​

充分研究和审查：在开始制定计划前，需全面研究和审查所有相关细节，包括我们讨论过的内容、文档、代码库和外部资源。

制定详细实施计划：基于研究结果，创建详细的实施计划，但不直接修改代码，计划需要包含以下内容：

  • 代码级别的变更指南，需完全基于代码库审查。
  • 潜在风险分析及应对措施（如兼容性问题、性能影响）。
  • 测试策略（如单元测试、集成测试）以验证变更效果。

使用Mermaid图表：对于复杂流程，使用Mermaid图表（流程图/时序图/状态图）进行说明：

  • 使用清晰的标签和节点连接。
  • 不同操作类型使用颜色编码（如输入为蓝色，处理为绿色，输出为橙色）。

计划文件存储：

  • 所有计划文件必须存储在 .plans/ 目录下。
  • 文件命名格式为 PLAN-{id}-{summary}.md：
    • {id} 为 .plans/ 目录及其子目录中的唯一编号。
    • {summary} 为任务的简短描述。
  • 文件采用 Markdown 格式，包含任务完成状态（如 [ ] 未完成，[x] 已完成）等。