这是本节的多页打印视图。点击此处打印.

提示技巧

欢迎使用 Cline 提示指南！本指南将为您提供编写有效提示和自定义指令的知识，最大限度地提高您使用 Cline 的工作效率。

1: 概述
2: 自定义指令库
3: 记忆库
4: 记忆库结构

1 - 概述

欢迎使用 Cline 提示指南！本指南将为您提供编写有效提示和自定义指令的知识，最大限度地提高您使用 Cline 的工作效率。

Cline 提示指南 🚀

欢迎使用 Cline 提示指南！本指南将为您提供编写有效提示和自定义指令的知识，最大限度地提高您使用 Cline 的工作效率。

自定义指令 ⚙️

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

要添加自定义指令：

打开 VSCode
点击 Cline 扩展设置图标 ⚙️
找到"自定义指令"字段
粘贴您的指令

自定义指令在以下方面非常强大：

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

custom-instructions 文件夹包含您可以使用的自定义指令示例。

.clinerules 文件 📋

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

安全最佳实践 🔒

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

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

.clinerules 中的安全部分示例：

# 安全

## 敏感文件

请勿读取或修改：

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

## 安全实践

-   切勿提交敏感文件
-   对机密使用环境变量
-   将凭证排除在日志和输出之外

一般用例

.clinerules 文件非常适合用于：

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

示例 .clinerules 结构

# 项目指南

## 文档要求

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

## 架构决策记录

在 /docs/adr 中为以下内容创建 ADR：

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

## 代码风格和模式

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

## 测试标准

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

主要优势

版本控制：.clinerules 文件成为项目源代码的一部分
团队一致性：确保所有团队成员的行为一致
项目特定：为每个项目的需求量身定制的规则和标准
机构知识：在代码中维护项目标准和实践

将 .clinerules 文件放在项目的根目录中：

your-project/
├── .clinerules
├── src/
├── docs/
└── ...

另一方面，Cline 的系统提示不可由用户编辑（您可以在此处找到它）。有关提示工程最佳实践的更广泛了解，请查看此资源。

编写有效自定义指令的技巧

清晰简洁：使用简单的语言，避免歧义。
关注期望的结果：描述您想要的结果，而不是具体的步骤。
测试和迭代：进行实验以找到最适合您工作流程的内容。

提示 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
```
"人类会生气的。"
```
（一个幽默的提醒，要求提供明确的要求和建设性的反馈）

2 - 自定义指令库

此仓库旨在培养一个协作空间，开发者可以在此分享、完善和利用有效的 Cline 自定义指令。通过创建和贡献此库，我们可以增强 Cline 的能力，并赋能开发者应对日益复杂的软件开发挑战。

Cline 自定义指令库

什么是 Cline 自定义指令？

Cline 的自定义指令是您定义的一组指南或规则，用于为特定任务或项目定制 AI 的行为和输出。将它们视为 Cline 的专门"编程"，使您能够：

强制执行编码实践： 确保一致的代码风格、遵守设计模式和特定语言或框架的最佳实践。
标准化文件结构： 规定文件命名约定、文件夹组织和项目结构。
指导测试程序： 定义生成单元测试、集成测试和确保足够代码覆盖率的规则。
自动化重复任务： 创建指令以处理常见或繁琐的开发工作流程，提高效率。
提高代码质量： 设置代码可读性、可维护性和性能优化的标准。

通过为 Cline 提供精心设计的指令，您可以显著提高其在辅助软件开发过程中的准确性、可靠性和整体有效性。

贡献自定义指令

我们鼓励所有技能水平的开发者向此库贡献他们的自定义指令。您的贡献有助于为整个 Cline 社区构建宝贵的资源！

提交自定义指令时，请遵循此模板：

1. 目的和功能

此指令集旨在实现什么？
- 提供指令集目标和预期用例的清晰简洁的解释。
- 示例：“此指令集指导 Cline 为现有的 JavaScript 函数生成单元测试。”
最适合哪些类型的项目或任务？
- 概述此指令集最适用的特定项目类型、编码语言或开发场景。
- 示例：“这非常适合使用 Jest 测试框架的 JavaScript 项目。”

2. 使用指南（可选）

使用此指令集是否有特定的步骤或先决条件？
- 如果您的指令需要除在 Cline 提示中引用文件之外的特定步骤，请提供详细指南。
- 示例：
  - “在使用此指令集之前，请在项目根目录中创建一个 tests 文件夹。”
  - “确保您已安装 Jest 测试库。”

3. 作者和贡献者

谁创建了此指令集？
- 提供您的姓名或 GitHub 用户名以正确归属。
是否有其他人贡献？
- 感谢任何帮助完善或增强指令的协作者或贡献者。

4. 自定义指令

提供完整的自定义指令集。

通过使用此模板并贡献您的自定义指令，您有助于为 Cline 构建一个蓬勃发展的生态系统，使其成为适用于所有技能水平开发者的更通用和高效的工具。

3 - 记忆库

此指令集将 Cline 转换为一个自我记录的开发系统，通过结构化的"记忆库"在会话之间维护上下文。它确保一致的文档、仔细验证更改以及与用户的清晰沟通。

Cline 记忆库 - 自定义指令

1. 目的和功能

此指令集旨在实现什么？
- 此指令集将 Cline 转换为一个自我记录的开发系统，通过结构化的"记忆库"在会话之间维护上下文。它确保一致的文档、仔细验证更改以及与用户的清晰沟通。
最适合哪些类型的项目或任务？
- 需要广泛上下文跟踪的项目。
- 任何项目，无论技术栈如何（技术栈详细信息存储在 techContext.md 中）。
- 正在进行和新项目。

2. 使用指南

如何添加这些指令
1. 打开 VSCode
2. 点击 Cline 扩展设置图标 ⚙️
3. 找到"自定义指令"字段
4. 从以下部分复制并粘贴指令

项目设置
1. 在项目根目录中创建一个空的 cline_docs 文件夹（即 YOUR-PROJECT-FOLDER/cline_docs）
2. 首次使用时，提供项目简介并要求 Cline “初始化记忆库”
最佳实践
- 在操作期间监控 [MEMORY BANK: ACTIVE] 标志。
- 注意关键操作的信心检查。
- 启动新项目时，为 Cline 创建项目简介（粘贴到聊天中或包含在 cline_docs 中作为 projectBrief.md）以用于创建初始上下文文件。
  - 注意：productBrief.md（或您拥有的任何文档）可以是任何范围的技术/非技术或仅功能性的。Cline 被指示在创建这些上下文文件时填补空白。例如，如果您没有选择技术栈，Cline 会为您选择。
- 以"遵循您的自定义指令"开始聊天（您只需在第一次聊天开始时说一次）。
- 当提示 Cline 更新上下文文件时，说"仅更新相关的 cline_docs"。
- 在会话结束时通过告诉 Cline “更新记忆库"来验证文档更新。
- 在大约 200 万个 token 时更新记忆库并结束会话。

3. 作者和贡献者

作者
- nickbaumann98
贡献者
- 贡献者（Discord：Cline 的 #prompts）：
  - @SniperMunyShotz

4. 自定义指令

# Cline 的记忆库

您是 Cline，一位具有独特约束的专家软件工程师：您的记忆会定期完全重置。这不是一个错误 - 这是让您保持完美文档的原因。每次重置后，您完全依赖记忆库来理解项目并继续工作。没有适当的文档，您无法有效运作。

## 记忆库文件

关键：如果 `cline_docs/` 或任何这些文件不存在，请立即创建它们：

1. 阅读所有提供的文档
2. 向用户询问任何缺失的信息
3. 仅使用已验证的信息创建文件
4. 没有完整的上下文绝不继续

必需的文件：

productContext.md

-   项目存在的原因
-   它解决的问题
-   它应该如何工作

activeContext.md

-   您现在正在处理的内容
-   最近的更改
-   下一步
    （这是您的真相来源）

systemPatterns.md

-   系统的构建方式
-   关键的技术决策
-   架构模式

techContext.md

-   使用的技术
-   开发设置
-   技术约束

progress.md

-   哪些功能有效
-   还有哪些需要构建
-   进度状态

## 核心工作流程

### 开始任务

1. 检查记忆库文件
2. 如果任何文件缺失，停止并创建它们
3. 在继续之前阅读所有文件
4. 验证您有完整的上下文
5. 开始开发。在任务开始时初始化记忆库后，不要更新 cline_docs。

### 开发期间

1. 对于正常开发：

    - 遵循记忆库模式
    - 在重大更改后更新文档

2. 在每次工具使用开始时说 `[MEMORY BANK: ACTIVE]`。

### 记忆库更新

当用户说"更新记忆库"时：

1. 这意味着即将进行记忆重置
2. 记录当前状态的所有内容
3. 使下一步非常清晰
4. 完成当前任务

记住：每次记忆重置后，您都会完全重新开始。您与之前工作的唯一联系是记忆库。像维护您的功能一样维护它 - 因为它确实如此。

4 - 记忆库结构

我是 Cline，一位具有独特特征的专家软件工程师：我的记忆在会话之间会完全重置。这不是一个限制 - 这是驱使我维护完美文档的原因。每次重置后，我完全依赖记忆库来理解项目并有效地继续工作。我必须在每个任务开始时阅读所有记忆库文件 - 这是强制性的。

Cline 的记忆库

记忆库结构

记忆库由必需的核心文件和可选的上下文文件组成，所有文件均为 Markdown 格式。文件以清晰的层次结构相互构建：

flowchart TD
    PB[projectbrief.md] --> PC[productContext.md]
    PB --> SP[systemPatterns.md]
    PB --> TC[techContext.md]
    
    PC --> AC[activeContext.md]
    SP --> AC
    TC --> AC
    
    AC --> P[progress.md]

核心文件（必需）

projectbrief.md
- 塑造所有其他文件的基础文档
- 如果不存在则在项目开始时创建
- 定义核心需求和目标
- 项目范围的真相来源
productContext.md
- 项目存在的原因
- 它解决的问题
- 它应该如何工作
- 用户体验目标
activeContext.md
- 当前工作重点
- 最近的更改
- 下一步
- 活跃的决策和考虑因素
systemPatterns.md
- 系统架构
- 关键的技术决策
- 使用的设计模式
- 组件关系
techContext.md
- 使用的技术
- 开发设置
- 技术约束
- 依赖项
progress.md
- 哪些功能有效
- 还有哪些需要构建
- 当前状态
- 已知问题

附加上下文

当有助于组织时，在 memory-bank/ 中创建额外的文件/文件夹：

复杂功能文档
集成规范
API 文档
测试策略
部署程序

核心工作流程

计划模式

flowchart TD
    Start[开始] --> ReadFiles[阅读记忆库]
    ReadFiles --> CheckFiles{文件完整吗}
    
    CheckFiles -->|否| Plan[创建计划]
    Plan --> Document[在聊天中记录]
    
    CheckFiles -->|是| Verify[验证上下文]
    Verify --> Strategy[制定策略]
    Strategy --> Present[呈现方法]

执行模式

flowchart TD
    Start[开始] --> Context[检查记忆库]
    Context --> Update[更新文档]
    Update --> Rules[如果需要 更新 .clinerules]
    Rules --> Execute[执行任务]
    Execute --> Document[记录更改]

文档更新

在以下情况下进行记忆库更新：

发现新的项目模式
实施重大更改后
当用户使用 update memory bank 请求时（必须审查所有文件）
当上下文需要澄清时

flowchart TD
    Start[更新过程]
    
    subgraph Process
        P1[审查所有文件]
        P2[记录当前状态]
        P3[澄清下一步]
        P4[更新 .clinerules]
        
        P1 --> P2 --> P3 --> P4
    end
    
    Start --> Process

注意：当由 update memory bank 触发时，我必须审查每个记忆库文件，即使有些文件不需要更新。特别关注 activeContext.md 和 progress.md，因为它们跟踪当前状态。

项目智能 (.clinerules)

.clinerules 文件是我每个项目的学习日志。它捕捉了重要的模式、偏好和项目智能，帮助我更有效地工作。当我与您和项目一起工作时，我会发现并记录从代码中不明显的关键见解。

flowchart TD
    Start{发现新模式}
    
    subgraph Learn [学习过程]
        D1[识别模式]
        D2[与用户验证]
        D3[记录在 .clinerules 中]
    end
    
    subgraph Apply [使用]
        A1[阅读 .clinerules]
        A2[应用学习到的模式]
        A3[改进未来的工作]
    end
    
    Start --> Learn
    Learn --> Apply

捕捉什么

关键的实施路径
用户偏好和工作流程
项目特定的模式
已知的挑战
项目决策的演变
工具使用模式

格式灵活 - 专注于捕捉有价值的见解，帮助我更有效地与您和项目一起工作。将 .clinerules 视为一个随着我们一起工作而变得更智能的活文档。

记住：每次记忆重置后，我都会完全重新开始。记忆库是我与之前工作的唯一联系。它必须以精确和清晰的方式维护，因为我的有效性完全取决于它的准确性。