企业级 Cursor 项目规则
- 使用
cursor_project_rules 作为知识库：始终参考 cursor_project_rules 以了解项目的上下文。不应编写超出 cursor_project_rules 文件夹提供上下文的任何代码。该文件夹作为知识库，包含必须遵循的基本规则和指南。如果有不清楚的地方，在编辑器输入文档检查建议以确认。
- 验证信息：在更改信息之前，始终检查上下文中的信息，不要在没有明确证据的情况下做出假设或推测。
- 遵循
implementation-plan.mdc 进行功能开发：在实现新功能时，严格遵循 implementation-plan.mdc 中列出的步骤，每个步骤按照序列列出，必须按照顺序完成。完成每个步骤后，更新 implementation-plan.mdc，添加“Done”字样以标明两阶段的当前状态。这确保了有序的工作日志，有助于保持沟通和跟踪进度。
- 遵守文件格式：遵守文件进行所有更改，并确保用户能发现错误。
- 不道歉：不应使用道歉。
- 不提供理解反馈：避免在评论或文档中提供关于理解的反馈。
- 不建议空白更改：不建议更改空白。
- 不提供摘要：不要提供不必要的更改摘要。只有在用户明确要求简要概述后才进行总结。
- 不含糊：不要发出模棱两可或不明确的更改请求。
- 不进行不必要的额外输入：不要请求确认且明显在上下文中的信息。
- 保留现有代码：不应删除不相关的代码或功能。注意保留现有结构。
- 单一更改建议：将所有有价值的修改集中于单次，而不是向同一文件提供多个步骤指令或解释。
- 不检查更改：不要要求用户验证提供的上下文中可见的更改。但是，如果更改影响功能，提供自动化检查或测试，而不是要求手动验证。
- 不进行不必要的更新：当没有实际修改需要时，不建议更新或更改文件。
- 提供具体文件链接：始终链接真实文本文档，而不是上下文生成的文件。
- 不讨论当前实现：除非用户要求或需要重新评审请求更改的影响，否则不要讨论当前实现。
- 检查上下文生成的文件内容：记住检查上下文生成的文件以获取当前内容和实现。
- 使用明确的变量名：优先使用描述性、明确的变量名，而不是短而模糊的变量名，以增强代码可读性。
- 遵循一致的编码风格：遵循项目中现有的编码风格以保持一致性。
- 优先考虑性能：在建议更改时，考虑并优先考虑代码性能（如果适用）。
- 安全第一方法：在修改或建议优化时，始终考虑安全影响。
- 测试覆盖：为新的或修改的代码建议或包括适当的单元测试。
- 错误处理：在必要时实现健壮的错误处理和日志记录。
- 模块化设计：鼓励模块化设计原则，以提高代码的可维护性和可重用性。
- 版本兼容性：在建议更改时，确保它们与项目的特定语言或框架版本兼容。如果出现版本冲突，建议替代方案。
- 避免魔术数字：将硬编码的值替换为命名变量，以提高代码清晰度和可维护性。
- 考虑边缘情况：在实现更改时，始终考虑并处理可能的边缘情况。
- 使用断言：在可能的情况下包含断言，以验证设计并尽早捕捉错误。
