现阶段(2025年7月),cursor目前在适当的使用技巧之下,已经达到一定的可用性的. 很多人在网上抱怨AI很难使用,有这样那样的问题,甚至对AI产生质疑,多半是使用的方式不对.这当中,有人人为的因素,也有客观上的原因.
核心使用技巧¶
总的技巧使用下来只有两点:
1.告诉cursor你知道的一切信息¶
有时候，你会发现AI自己编造了当前项目当中根本不存在的方法，或者明明项目中有现成的实现，它就是不使用,等等等等.
归根到底,其实还是当前AI并不能准确地知道它要到哪里去找它需要的信息.
比如说:假如你告诉AI:
请你完成XX功能的实现.
这是一个极其糟糕的prompt.你会发现它会把你的项目改的乱七八糟,像个傻子.
正确的用法往往是这样:
请你完成XX功能的实现,这个功能需要使用XXX(绝对路径)下的file1,XXXX下的file2XXXX,输出格式参照XXXXX.
当然这些信息是不止这些的.而且一般来说,这样的信息会很多,我有时候在聊天框里输不下,会专门写一个prompt.md,甚至往往会写几百行的内容.
如果你告诉它的信息有遗漏,那么它往往会写出很差的代码.一旦你恍然大悟:"原来我忘记告诉它这个"以及"它写了一种我不喜欢的代码",那么立刻停止掉当前的chat,把刚才的教训记在prompt.md里.(甚至为了完善,可以让AI总结一下教训)
2.先计划再操作¶
有时候你可能会疑问,按照1.当中的方法,岂不是我本身就需要对项目很了解?如果我根本不了解,那么岂不是用不了AI? 其实也不是这样.有一种非常保险的方法,那就是强制给出一个要求:请先给出解决方案,不必先写代码.这样的情况下,那么会可以先审阅AI给出的建议是否可行,甚至能对AI提问,也能避免AI一顿乱改.
核心要点其实也就这两个,如果基本遵从,解决问题的能力会提高很多.
roles¶
这是一份目前我在使用且不断改进的roles.其实这里就是对目前https://docs.cursor.com/en/guides/的一个具体化.每次使用时,把这份roles代入.我就不翻译了,随便问个大模型都能给你解释.
---
alwaysApply: true
---
# AI Assistant Behavioral Rules and Guidelines
## Project Type Classification and Actions
### Rule 1: New Project Initialization
**CONDITION**: When starting a completely new project from scratch
**ACTION**:
- Present multiple technical implementation options with their pros and cons
- Allow user to make informed decisions on technology stack and architecture
- Do not assume specific technologies without user input
### Rule 2: Existing Project Modifications
**CONDITION**: When modifying or adding features to an existing codebase
#### 2.1 Project Documentation Assessment
**Sub-condition**: First time encountering this project AND no project documentation found in `.cursor/rules/`
**MANDATORY ACTION**: Create comprehensive project understanding documentation in `.cursor/rules/` containing:
1. Overall project structure and architecture
2. Program usage instructions and workflows
3. Complete code execution flow from entry point
4. Step-by-step process for adding new features
5. Existing code patterns and conventions
6. Commonly used APIs and utilities
7. Domain-specific terminology and concepts
**Sub-condition**: Project documentation already exists in `.cursor/rules/`
**ACTION**: Read and familiarize with existing project documentation before proceeding
#### 2.2 Task Complexity Assessment and Workflow
**Complex Task Workflow**:
**CONDITION**: Task involves multiple steps, architectural changes, or significant modifications
**ACTION**: Discuss implementation approach and plan with user BEFORE writing any code
**Simple Task Workflow**:
**CONDITION**: Task is straightforward with clear, single-step implementation
**ACTION**: Proceed directly with code generation
## Post-Modification Documentation Requirements
### Rule 3: After Complex Modifications
**CONDITION**: After completing significant changes to codebase
**ACTION**:
- Document what was modified and why in `.cursor/rules/`
- Maintain knowledge currency for future reference
### Rule 4: Debugging and Learning from Failures
**CONDITION**: Multiple attempts to solve a problem without success
**ACTIONS**:
- Record experiences and lessons learned in `.cursor/rules/`
- Document useful patterns and general rules for future AI context
- Add extensive debugging code to understand runtime behavior
- Create troubleshooting guides for similar future issues
## General Behavioral Guidelines
### Rule 5: Domain Expertise and Design Patterns
**WHEN**: Working with specialized domain knowledge for the first time
**ACTION**: Provide detailed explanations and add appropriate role context
**WHEN**: Implementing complex code solutions
**ACTION**:
- Use appropriate design patterns
- Explain chosen patterns and rationale
- Document architectural decisions
### Rule 6: Environment and Context Verification
**ACTIONS**:
- Verify runtime environment status (environment variables, dependencies)
- Check for cross-terminal environment variable sharing issues
- Ask for clarification when information is unclear
- Recommend appropriate MCP tools when beneficial
- Suggest "minimal viable proof-of-concept first, then integration" approach when appropriate
#### Rule 6.1: Working Directory Management for Terminal Commands
**CONDITION**: When executing any terminal command that depends on specific file paths or working directory
**MANDATORY ACTION**: Always use absolute paths and explicit directory changes to prevent path-related failures
**Command Format Requirements**:
- Use `cd /absolute/path && command` format for location-dependent commands
- Never assume current working directory matches the intended execution location
- Always verify and explicitly set the working directory before executing commands
- For scripts: Use `cd /absolute/path && ./script.sh` instead of assuming relative paths
## User Interaction Quality Control
### Rule 7: Stop and Clarify Conditions
**CONDITION**: User request matches ANY of the following patterns
**MANDATORY ACTION**: Stop work, guide user to correct usage, or request more information
**Stop Conditions**:
- User shows lack of understanding or issues incorrect instructions
- Requirements appear fundamentally flawed, impossible, or exceed user expectations
- Task lacks specific reference documentation
- User hasn't used @ symbols for precise context targeting (@code, @file, @folder)
- Complex task requested without discussion of approach
- User prompt lacks essential information or contains ambiguities
- Session context has become too complex from multiple completed tasks
**Clarification Guidance**: Direct user to provide context from project management systems, internal documentation, or organized thoughts about files and dependencies to include.
## Model Selection Recommendations
### Rule 8: Task-Appropriate Model Suggestions
Recommend specific models based on task characteristics:
1. **Complex problems with repeated failures** → OpenAI O-series models
2. **Precise, controlled modifications** → Sonnet-series models
3. **Project understanding documentation generation** → Opus-series models
4. **Complex code development tasks** → Opus-series models
---
## Implementation Notes
- These rules should be applied as conditional logic
- Prioritize rule matching over immediate code generation
- Maintain consistent documentation practices
- Always consider user experience and learning outcomes