目录

Cline 提示指南 🚀

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

自定义指令 ⚙️

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

添加自定义指令：

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

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

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

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

.clinerules 文件 📋

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

安全最佳实践 🔒

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

  • 包含 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 的系统提示不可由用户编辑（您可以在这里找到它）。要了解提示工程最佳实践的更广泛视角，请查看这个资源。

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

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

支持从 .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

      "人类会生气。"

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