概述

Cline 提示指南 🚀

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

自定义指令 ⚙️

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

要添加自定义指令：

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

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

• 强制执行编码风格和最佳实践：确保 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 端点需要集成测试
-   关键用户流程需要端到端测试

主要优势

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

将 .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

  "人类会生气的。"
  

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