---
layout: single
title:  "Cline 提示指南 🚀"
date:   2025-04-22 06:00:00 +0800
categories: [编程开发, 教程实践]
tags: [Cline, Prompting, ClineDoc]
---

# [Cline 提示指南 🚀](https://github.com/cline/cline/blob/main/docs/prompting/README.md)

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

## 自定义指令 ⚙️

将**自定义指令视为 Cline 的编程**。它们定义了 Cline 的基准行为，并且**始终"开启"，影响所有交互。**

添加自定义指令：

1. 打开 VSCode
2. 点击 Cline 扩展设置齿轮 ⚙️
3. 找到"自定义指令"字段
4. 粘贴您的指令

![](/images/2025/ClineDoc/custom-instructions.png)

自定义指令在以下方面特别有用：

- 🚀 强制执行代码风格和最佳实践：确保 Cline 始终遵循您团队的编码约定、命名约定和最佳实践。
- 👍 提高代码质量：鼓励 Cline 编写更易读、可维护和高效的代码。
- 📝 指导错误处理：告诉 Cline 如何处理错误、编写错误消息和日志信息。

**`custom-instructions` 文件夹包含了您可以使用或调整的自定义指令示例。**

## .clinerules 文件 📋

虽然自定义指令是特定于用户且全局的（适用于所有项目），但 `.clinerules` 文件提供了**项目特定的指令**，存放在项目的根目录中。这些指令会自动附加到您的自定义指令中，并在 Cline 的系统提示中引用，确保它们影响项目上下文中的所有交互。这使其成为以下场景的出色工具：

### 安全最佳实践 🔒

为了保护敏感信息，您可以在 `.clinerules` 中指示 Cline 忽略特定文件或模式。这对以下内容特别重要：

- 包含 API 密钥和机密的 `.env` 文件
- 包含敏感数据的配置文件
- 私有凭证或令牌

`.clinerules` 中的安全部分示例：

```markdown
# 安全

## 敏感文件

禁止读取或修改：

- .env 文件
- */config/secrets.*
- */*.pem
- 任何包含 API 密钥、令牌或凭证的文件

## 安全实践

- 永不提交敏感文件
- 使用环境变量存储机密
- 保持凭证不出现在日志和输出中
```

### 通用使用场景

`.clinerules` 文件非常适合：

- 在团队成员间维护项目标准
- 强制执行开发实践
- 管理文档要求
- 设置分析框架
- 定义项目特定行为

### .clinerules 结构示例

```markdown
# 项目指南

## 文档要求

- 修改功能时更新 /docs 中的相关文档
- 保持 README.md 与新功能同步
- 在 CHANGELOG.md 中维护更新日志条目

## 架构决策记录

在 /docs/adr 中创建 ADR，用于：

- 主要依赖项更改
- 架构模式更改
- 新集成模式
- 数据库架构更改
按照 /docs/adr/template.md 中的模板

## 代码风格和模式

- 使用 OpenAPI Generator 生成 API 客户端
- 使用 TypeScript axios 模板
- 将生成的代码放在 /src/generated 中
- 优先使用组合而非继承
- 使用仓储模式进行数据访问
- 遵循 /src/utils/errors.ts 中的错误处理模式

## 测试标准

- 业务逻辑需要单元测试
- API 端点需要集成测试
- 关键用户流程需要端到端测试
```

### 主要优势

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/` 目录下的所有文件都会被递归加载，其内容会合并到 clineRulesFileInstructions 中。

#### 示例 1：
```
.clinerules/
├── .local-clinerules
└── .project-clinerules
```

#### 示例 2：
```
.clinerules/
├── .clinerules-nextjs
├── .clinerules-serverside
└── tests/
    ├── .pytest-clinerules
    └── .jest-clinerules
```

## 向 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_

    ```
    "FILENAME 变得太大了。分析这个文件的工作方式并建议安全地拆分它的方法。"
    ```

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

- **文档维护** - _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_
    ```
    "人类会生气。"
    ```
    （一个幽默的提醒，提供清晰的要求和建设性的反馈）