> ## Documentation Index
> Fetch the complete documentation index at: https://cat.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 提示工程指南

欢迎使用 Cline 提示指南！本指南将为您提供编写有效提示和自定义指令的知识，最大化您使用 Cline 的生产力。

## .clineignore 文件指南

### 概述

`.clineignore` 文件是项目级配置文件，告诉 Cline 在分析代码库时应忽略哪些文件和目录。类似于 `.gitignore`，它使用模式匹配来指定应从 Cline 的上下文和操作中排除的文件。

### 用途

* **减少噪音**：排除自动生成的文件、构建产物和其他非必要内容
* **提高性能**：限制 Cline 需要处理的代码量
* **集中注意力**：引导 Cline 关注代码库的相关部分
* **保护敏感数据**：防止 Cline 访问敏感配置文件

### 示例 .clineignore 文件

```
# 依赖项
node_modules/
**/node_modules/
.pnp
.pnp.js

# 构建输出
/build/
/dist/
/.next/
/out/

# 测试
/coverage/

# 环境变量
.env
.env.local
.env.development.local
.env.test.local
.env.production.local

# 大型数据文件
*.csv
*.xlsx
```

## 提示 Cline 💬

**提示是您在与 Cline 的来回聊天中传达特定任务需求的方式。** Cline 理解自然语言，所以请用对话的方式书写。

有效的提示包括：

* 提供清晰的上下文：解释您的目标和代码库的相关部分。使用 `@` 引用文件或文件夹。
* 分解复杂性：将大型任务分解为更小的步骤。
* 提出具体问题：引导 Cline 朝向期望的结果。
* 验证和完善：审查 Cline 的建议并提供反馈。

### 提示示例

#### 上下文管理

* **开始新任务：** "Cline，让我们开始一个新任务。创建 `user-authentication.js`。我们需要使用 JWT 令牌实现用户登录。以下是要求…"
* **总结之前的工作：** "Cline，总结我们在上次用户仪表板任务中做的工作。我想捕获主要功能和未解决的问题。保存到 `cline_docs/user-dashboard-summary.md`。"

#### 调试

* **分析错误：** "Cline，我遇到了这个错误：\[错误消息]。似乎来自 \[代码部分]。分析这个错误并建议修复方案。"
* **识别根本原因：** "Cline，当我 \[操作] 时应用程序崩溃。问题可能在 \[问题区域]。帮我找到根本原因并提出解决方案。"

#### 重构

* **改进代码结构：** "Cline，这个函数太长太复杂了。将其重构为更小的函数。"
* **简化逻辑：** "Cline，这段代码难以理解。简化逻辑并使其更易读。"

#### 功能开发

* **头脑风暴新功能：** "Cline，我想添加一个让用户 \[功能] 的功能。头脑风暴一些想法并考虑实现挑战。"
* **生成代码：** "Cline，创建一个显示用户配置文件的组件。列表应该是可排序和可过滤的。为这个组件生成代码。"

## 高级提示技巧

* **约束填充**：为了减少代码截断，在提示中包含明确的约束。例如，"确保代码完整"或"始终提供完整的函数定义"。
* **信心检查**：要求 Cline 评估其信心（例如，"在 1-10 的尺度上，您对这个解决方案有多自信？"）
* **挑战 Cline 的假设**：提出"愚蠢"的问题来鼓励更深入的思考并防止错误假设。

以下是用户发现的一些与 Cline 工作时有用的提示技巧：

## 我们社区最喜爱的提示 🌟

### 记忆和信心检查 🧠

* **记忆检查** - *pacnpal*

  ```
  "如果您完全理解我的提示，在每次即将使用工具时都回应 'YARRR!' 而不使用工具。"
  ```

  一种在复杂任务期间验证 Cline 保持正轨的有趣方式。尝试 "HO HO HO" 来增加节日气氛！

* **信心评分** - *pacnpal*

  ```
  "在任何工具使用前后，给我一个信心级别（0-10），说明工具使用将如何帮助项目。"
  ```

  鼓励批判性思维并使决策制定透明化。

### 代码质量提示 💻

* **防止代码截断**

  ```
  "不要懒惰。不要省略代码。"
  ```

  替代短语："仅完整代码"或"确保代码完整"

* **自定义指令提醒**

  ```
  "我承诺遵循自定义指令。"
  ```

  强化对您的设置盘 ⚙️ 配置的遵守。

### 代码组织 📋

* **大文件重构** - *icklebil*

  ```
  "文件名已经变得太大。分析这个文件的工作方式并建议安全分片的方法。"
  ```

  通过战略性分解帮助管理复杂文件。

* **文档维护** - *icklebil*

  ```
  "不要忘记更新代码库文档的更改"
  ```

  确保文档与代码更改保持同步。

### 分析和规划 🔍

* **结构化开发** - *yellow\_bat\_coffee*

  ```
  "在编写代码之前：
  1. 彻底分析所有代码文件
  2. 获取完整上下文
  3. 编写 .MD 实现计划
  4. 然后实现代码"
  ```

  促进有组织、精心规划的开发。

* **彻底分析** - *yellow\_bat\_coffee*

  ```
  "请开始彻底分析完整流程，始终声明 1 到 10 的信心分数"
  ```

  防止过早编码并鼓励完整理解。

* **假设检查** - *yellow\_bat\_coffee*

  ```
  "列出您在完成此任务之前需要澄清的所有假设和不确定性。"
  ```

  在开发早期识别潜在问题。

### 深思熟虑的开发 🤔

* **暂停和反思** - *nickbaumann98*

  ```
  "数到 10"
  ```

  在采取行动前促进仔细考虑。

* **完整分析** - *yellow\_bat\_coffee*

  ```
  "不要过早完成分析，即使您认为已经找到了解决方案，也要继续分析"
  ```

  确保彻底的问题探索。

* **持续信心检查** - *pacnpal*

  ```
  "在保存文件前、保存后、拒绝后和任务完成前评估信心（1-10）"
  ```

  通过自我评估维持质量。

### 最佳实践 🎯

* **项目结构** - *kvs007*

  ```
  "在建议结构或依赖项更改之前检查项目文件"
  ```

  维护项目完整性。

* **批判性思维** - *chinesesoup*

  ```
  "提出'愚蠢'的问题，如：您确定这是实现此功能的最佳方法吗？"
  ```

  挑战假设并发现更好的解决方案。

* **代码风格** - *yellow\_bat\_coffee*

  ```
  在提示中使用"优雅"和"简单"等词汇
  ```

  可能影响代码组织和清晰度。

* **设定期望** - *steventcramer*

  ```
  "人类会生气。"
  ```

  （一个幽默的提醒，要提供清晰的要求和建设性的反馈）


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.