> For the complete documentation index, see [llms.txt](https://modelmesh.gitbook.io/cline-zhong-wen-ban-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://modelmesh.gitbook.io/cline-zhong-wen-ban-docs/ti-gao-ti-shi-ji-qiao/ti-shi-gong-cheng-zhi-nan.md).
# 提示工程指南
### Overview
Plan & Act modes represent Cline's approach to structured AI development, emphasizing thoughtful planning before implementation. This dual-mode system helps developers create more maintainable, accurate code while reducing iteration time.
Use Plan to gather context before using Act to implement the plan
#### Understanding the Modes
**Plan Mode**
* Optimized for context gathering and strategy
* Cannot make changes to your codebase
* Focused on understanding requirements and creating implementation plans
* Enables full file reading for comprehensive project understanding
**Act Mode**
* Streamlined for implementation based on established plans
* Has access to all of Cline's building capabilities
* Maintains context from the planning phase
* Can execute changes to your codebase
#### Workflow Guide
**1. Start with Plan Mode**
Begin every significant development task in Plan mode:
In this mode:
* Share your requirements
* Let Cline analyze relevant files
* Engage in dialogue to clarify objectives
* Develop implementation strategy
**2. Switch to Act Mode**
Once you have a clear plan, switch to Act mode:
Act mode allows Cline to:
* Execute against the agreed plan
* Make changes to your codebase
* Maintain context from planning phase
**3. Iterate as Needed**
Complex projects often require multiple plan-act cycles:
* Return to Plan mode when encountering unexpected complexity
* Use Act mode for implementing solutions
* Maintain development momentum while ensuring quality
#### Best Practices
**Planning Phase**
1. Be comprehensive with requirements
2. Share relevant context upfront
3. Point Cline to relevant files if he hasn't read them
4. Validate approach before implementation
**Implementation Phase**
1. Follow the established plan
2. Monitor progress against objectives
3. Track changes and their impact
4. Document significant decisions
#### Power User Tips
**Enhancing Planning**
* Use Plan mode to explore edge cases before implementation
* Switch back to Plan when encountering unexpected complexity
* Leverage file reading to validate assumptions early
* Have Cline write markdown files of the plan for future reference
#### Common Patterns
**When to Use Plan Mode**
* Starting new features
* Debugging complex issues
* Architectural decisions
* Requirements analysis
**When to Use Act Mode**
* Implementing agreed solutions
* Making routine changes
* Following established patterns
* Executing test cases
#### Contributing
Share your experiences and improvements:
* Join our [Discord community](https://discord.gg/cline)
* Participate in discussions
* Submit feature requests
* Report issues
***
Remember: The time invested in planning pays dividends in implementation quality and maintenance efficiency
欢迎使用 Cline 提示指南！本指南将为您提供编写有效提示和自定义说明的知识，从而最大限度地提高您使用 Cline 的工作效率。
## **自定义说明**
将**自定义指令视为 Cline 的编程** 。它们定义了 Cline 的基线行为，并且**始终处于“开启”状态，影响着所有交互。** 说明可以是宽泛而抽象的，也可以是具体而明确的。您可能希望 Cline 具有独特的个性，或以特定文件格式生成输出，或遵守某些体系结构原则。自定义指令可以按照您定义的方式标准化 Cline 的输出，这在与他人合作时尤其有价值。请参阅[企业部分 ](https://docs.cline.bot/enterprise-solutions/custom-instructions)，了解如何在团队环境中使用自定义指令。
注意：修改 Custom Instructions 字段会更新 Cline 的提示缓存，并丢弃累积的上下文。这会导致在替换该上下文时成本暂时增加。尽可能在对话之间更新自定义说明。
要添加自定义说明：
1. 打开 VSCode
2. 单击 Cline 分机设置旋钮 ⚙️
3. 找到 “Custom Instructions” 字段
4. 粘贴您的说明
自定义指令功能强大：
* 强制实施编码风格和最佳实践：确保 Cline 始终遵守您团队的编码约定、命名约定和最佳实践。
* 提高代码质量：鼓励 Cline 编写更具可读性、可维护性和更高效的代码。
* 指导错误处理：告诉 Cline 如何处理错误、写入错误消息和记录信息。
### **.clinerules 文件** 📋
注意：修改 `.clinerules` 文件会更新 Cline 的提示缓存，并丢弃累积的上下文。这会导致在替换该上下文时成本暂时增加。尽可能在对话之间更新 `.clinerules` 文件。
虽然自定义说明是特定于用户的和全局的（适用于所有项目），但 `.clinerules` 文件提供位于项目根目录中的项目**特定说明** 。这些说明会自动附加到您的自定义说明中，并在 Cline 的系统提示符中引用，确保它们影响项目上下文中的所有交互。这使其成为以下方面的绝佳工具：
### **一般用例**
`.clinerules` 文件非常适合：
* 在团队成员之间维护项目标准
* 强制实施开发实践
* 管理文档要求
* 设置分析框架
* 定义特定于项目的行为
### **示例 .clinerules 结构**
```
# Project Guidelines
## Documentation Requirements
- Update relevant documentation in /docs when modifying features
- Keep README.md in sync with new capabilities
- Maintain changelog entries in CHANGELOG.md
## Architecture Decision Records
Create ADRs in /docs/adr for:
- Major dependency changes
- Architectural pattern changes
- New integration patterns
- Database schema changes
Follow template in /docs/adr/template.md
## Code Style & Patterns
- Generate API clients using OpenAPI Generator
- Use TypeScript axios template
- Place generated code in /src/generated
- Prefer composition over inheritance
- Use repository pattern for data access
- Follow error handling pattern in /src/utils/errors.ts
## Testing Standards
- Unit tests required for business logic
- Integration tests for API endpoints
- E2E tests for critical user flows
```
### **主要优点**
1. **版本控制** ：`.clinerules` 文件成为项目源代码的一部分
2. **团队一致性** ：确保所有团队成员的行为一致
3. **特定于项目** ：根据每个项目的需求量身定制的规则和标准
4. **机构知识** ：在代码中维护项目标准和实践
将 `.clinerules` 文件放在项目的根目录中：
```
your-project/
├── .clinerules
├── src/
├── docs/
└── ...
```
另一方面，Cline 的系统提示符不是用户可编辑的（[ 您可以在此处找到它 ](https://github.com/cline/cline/blob/main/src/core/prompts/system.ts)）。有关提示工程最佳实践的更广泛信息，请查看[此资源 ](https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview)。
### **编写有效自定义指令的提示**
* 简洁明了：使用简单的语言，避免歧义。
* 专注于预期结果：描述您想要的结果，而不是具体步骤。
* 测试和迭代：通过试验找到最适合您的工作流程的方法。
### **.clinerules 文件夹系统** 📂
虽然单个 `.clinerules` 文件适用于更简单的项目，但 Cline 现在支持 `.clinerules` 文件夹以进行更复杂的规则组织。这种模块化方法带来了几个优点：
#### **如何运作**
在项目根目录中创建一个 `.clinerules/` 目录，而不是单个文件：
```
your-project/
├── .clinerules/ # Folder containing active rules
│ ├── 01-coding.md # Core coding standards
│ ├── 02-documentation.md # Documentation requirements
│ └── current-sprint.md # Rules specific to current work
├── src/
└── ...
```
Cline 会自动处理 `.clinerules/` 目录中**的所有 Markdown 文件** ，并将它们组合成一组统一的规则。数字前缀 （可选） 有助于按逻辑顺序组织文件。
#### **使用规则库**
对于具有多个上下文或团队的项目，请维护一个规则库目录：
```
your-project/
├── .clinerules/ # Active rules - automatically applied
│ ├── 01-coding.md
│ └── client-a.md
│
├── clinerules-bank/ # Repository of available but inactive rules
│ ├── clients/ # Client-specific rule sets
│ │ ├── client-a.md
│ │ └── client-b.md
│ ├── frameworks/ # Framework-specific rules
│ │ ├── react.md
│ │ └── vue.md
│ └── project-types/ # Project type standards
│ ├── api-service.md
│ └── frontend-app.md
└── ...
```
#### **文件夹方法的好处**
1. **上下文激活** ：仅将相关规则从库复制到活动文件夹
2. **更易于维护** ：更新单个规则文件而不影响其他规则文件
3. **团队灵活性** ：不同的团队成员可以激活特定于其当前任务的规则
4. **减少噪音** ：保持活动规则集的重点和相关性
#### **使用示例**
在客户端项目之间切换：
```
# Switch to Client B project
rm .clinerules/client-a.md
cp clinerules-bank/clients/client-b.md .clinerules/
```
适应不同的技术堆栈：
```
# Frontend React project
cp clinerules-bank/frameworks/react.md .clinerules/
```
#### **实施技巧**
* 将单个规则文件集中在特定问题上
* 使用明确指示规则用途的描述性文件名
* 考虑在跟踪 `clinerules-bank/` 时忽略活动的 `.clinerules/` 文件夹
* 创建团队脚本以快速激活常见规则组合
文件夹系统将您的 Cline 规则从静态文档转换为动态知识系统，以适应团队不断变化的上下文和要求。
## **.clineignore 文件指南**
### **Overview 概述**
`.clineignore` 文件是一个项目级配置文件，它告诉 Cline 在分析代码库时要忽略哪些文件和目录。与 `.gitignore` 类似，它使用模式匹配来指定哪些文件应该从 Cline 的上下文和作中排除。
### **Purpose 目的**
* **减少杂色** ：排除自动生成的文件、构建构件和其他非必要的内容
* **提高性能** ：限制 Cline 需要处理的代码量
* **集中注意力** ：将 Cline 直接指向代码库的相关部分
* **保护敏感数据** ：防止 Cline 访问敏感配置文件
### **示例 .clineignore 文件**
```
# Dependencies
node_modules/
**/node_modules/
.pnp
.pnp.js
# Build outputs
/build/
/dist/
/.next/
/out/
# Testing
/coverage/
# Environment variables
.env
.env.local
.env.development.local
.env.test.local
.env.production.local
# Large data files
*.csv
*.xlsx
```
## **提示 Cline** 💬
**提示是您在与 Cline 的来回聊天中传达您对给定任务的需求的方式。**Cline 理解自然语言，因此请以对话方式写作。
有效的提示包括：
* 提供清晰的上下文：解释您的目标和代码库的相关部分。使用 `@` 引用文件或文件夹。
* 分解复杂性：将大型任务划分为较小的步骤。
* 提出具体问题：引导 Cline 取得理想的结果。
* 验证和改进：查看 Cline 的建议并提供反馈。
### **Prompt Examples 提示示例**
#### **Context Management 上下文管理**
* **启动新任务：**“克莱恩，我们开始一个新的任务吧。创建 `user-authentication.js`。我们需要使用 JWT 令牌实现用户登录。这是要求......”
* **总结以前的工作：**“Cline，总结一下我们在上一个用户仪表板任务中所做的工作。我想捕捉主要功能和未解决的问题。将此保存到 `cline_docs/user-dashboard-summary.md` 。
#### **Debugging 调试**
* **分析错误：**“Cline，我收到此错误：\[错误消息]。它似乎来自 \[代码部分]。分析此错误并提出修复建议。
* **确定根本原因：**“Cline，当我 \[作] 时，应用程序崩溃了。问题可能出在 \[问题区域] 中。帮助我找到根本原因并提出解决方案。
#### **Refactoring 重构**
* **改进代码结构：**“克莱恩，这个功能太长太复杂了。将其重构为更小的函数。
* **简化逻辑：**“克莱恩，这段代码很难理解。简化逻辑，使其更具可读性。
#### **功能开发**
* **头脑风暴新功能：**“Cline，我想添加一个让用户 \[功能] 的功能。集思广益，考虑实施挑战。
* **生成代码：**「Cline，创建一个显示用户配置文件的组件。该列表应该是可排序和可筛选的。生成此组件的代码。
## **高级提示技术**
* **约束填充 （Constraint Stuffing）：** 要减少代码截断，请在提示中包含显式约束。例如，“确保代码完整”或“始终提供完整的函数定义”。
* **置信度检查：** 让 Cline 对其置信度进行评分（例如，“在 1-10 的范围内，您对此解决方案的置信度如何？
* **挑战 Cline 的假设：** 提出 “愚蠢 ”的问题，以鼓励更深入的思考并防止错误的假设。
以下是用户发现对使用 Cline 有用的一些提示：
## **我们社区最喜欢的提示** 🌟
### **内存和置信度检查** 🧠
* **内存检查** - *pacnpal*
```
"If you understand my prompt fully, respond with 'YARRR!' without tools every time you are about to use a tool."
```
一种验证 Cline 在复杂任务中保持正轨的有趣方法。试试 “HO HO HO” 来感受节日气氛吧！
* **置信度评分** - *pacnpal*
```
"Before and after any tool use, give me a confidence level (0-10) on how the tool use will help the project."
```
鼓励批判性思维并使决策透明。
### **代码质量提示** 💻
* **防止代码截断**
```
"DO NOT BE LAZY. DO NOT OMIT CODE."
```
替代短语：“full code only”或“ensure the code is complete”
* **自定义说明提醒**
```
"I pledge to follow the custom instructions."
```
加强对设置拨盘⚙️配置的遵守。
### **代码组织** 📋
* **大文件重构** - *icklebil*
```
"FILENAME has grown too big. Analyze how this file works and suggest ways to fragment it safely."
```
通过策略性分解帮助管理复杂文件。
* **文档维护** - *icklebil*
```
"don't forget to update codebase documentation with changes"
```
确保文档与代码更改保持同步。
### **分析与规划** 🔍
* **结构化开发** - *yellow\_bat\_coffee*
```
"Before writing code:
1. Analyze all code files thoroughly
2. Get full context
3. Write .MD implementation plan
4. Then implement code"
```
促进有组织、有计划的开发。
* **深入分析** - *yellow\_bat\_coffee*
```
"please start analyzing full flow thoroughly, always state a confidence score 1 to 10"
```
防止过早编码并促进完全理解。
* **假设检查** - *yellow\_bat\_coffee*
```
"List all assumptions and uncertainties you need to clear up before completing this task."
```
在开发早期识别潜在问题。
### **周到的开发** 🤔
* **暂停和反思** - *nickbaumann98*
```
"count to 10"
```
促进在采取行动之前仔细考虑。
* **完整分析** - *yellow\_bat\_coffee*
```
"Don't complete the analysis prematurely, continue analyzing even if you think you found a solution"
```
确保彻底的问题探索。
* **持续置信度检查** - *pacnpal*
```
"Rate confidence (1-10) before saving files, after saving, after rejections, and before task completion"
```
通过自我评估保持质量。
### **最佳实践**🎯
* **项目结构** - *kvs007*
```
"Check project files before suggesting structural or dependency changes"
```
维护项目完整性。
* **批判性思维** - *chinesesoup*
```
"Ask 'stupid' questions like: are you sure this is the best way to implement this?"
```
挑战假设并发现更好的解决方案。
* **代码样式** - *yellow\_bat\_coffee*
```
Use words like "elegant" and "simple" in prompts
```
可能会影响代码的组织和清晰度。
* **设定期望** - *steventcramer*
```
"THE HUMAN WILL GET ANGRY."
```
（幽默的提醒，提供明确的要求和建设性的反馈）