Prompt Engineering Guide

欢迎使用 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

  "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

  "人类会生气的。"

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