提示工程指南

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

  "文件名已经变得太大。分析这个文件的工作方式并建议安全分片的方法。"
  

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

• 文档维护 - 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

  "人类会生气。"
  

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