Cline 本地提示指南 🚀
欢迎来到 Cline 本地提示指南！本指南将帮助您掌握编写有效提示和自定义指令的技巧，充分利用 Cline 的功能。
自定义指令 ⚙️
将自定义指令视为 Cline 的编程功能。它们定义了 Cline 的基本行为，并且始终开启，影响所有交互。
添加自定义指令的步骤如下：
打开 VSCode
点击 Cline 插件设置图标 ⚙️
找到“自定义指令”字段
粘贴您的指令
自定义指令的强大之处在于：
强制编码风格和最佳实践：确保 Cline 始终遵循您的团队编码规范、命名约定和最佳实践。
提升代码质量：鼓励 Cline 编写更易读、更易维护且更高效的代码。
指导错误处理：告诉 Cline 如何处理错误、编写错误消息和记录信息。
custom-instructions 文件夹包含您可以使用的自定义指令示例或适应的示例。
.clinerules 文件 📋
虽然自定义指令是用户特定的且全局适用（跨项目），但 .clinerules 文件提供了项目特定的指令，存放在项目的根目录中。这些指令会自动附加到自定义指令，并在 Cline 的系统提示中引用，确保它们影响项目上下文中的所有交互。这使其非常适合：
安全最佳实践 🔒
为了保护敏感信息，您可以指示 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 端点需要集成测试
- 关键用户流需要 E2E 测试关键优势
版本控制：
.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），说明工具使用如何帮助项目。"鼓励批判性思维，使决策过程更加透明。
代码质量提示 💻
防止代码截断
"不要偷懒。请不要遗漏代码。"替代短语： "仅完整代码" 或 "确保代码完整"
自定义指令提醒
"我承诺遵循自定义指令。"强化您在设置 dial ⚙️ 中的配置。
代码组织 📋
大型文件重构 - icklebil
"FILENAME 已经变得太大。分析此文件的工作原理，并提出安全分解它的方法。"通过战略分解帮助管理复杂文件。
文档维护 - icklebil
"不要忘记在代码更改时更新代码库文档。"确保文档与代码更改同步更新。
分析与规划 🔍
结构化开发 - yellow_bat_coffee
"编写代码前： 1. 彻底分析所有代码文件 2. 获取完整上下文 3. 编写 .MD 实施计划 4. 再进行代码实现"促进有条理、计划周密的开发。
彻底分析 - yellow_bat_coffee
"在找到解决方案之前，请继续彻底分析整个流程，即使你认为已经找到了解决方法。"防止在理解不透彻的情况下草率编码。
假设检查 - yellow_bat_coffee
"列出您在完成此任务之前需要澄清的所有假设和不确定性。"提早识别潜在问题。
深思熟虑的开发 🤔
暂停并反思 - nickbaumann98
"数到 10"在采取行动前促进仔细考虑。
完整分析 - yellow_bat_coffee
"不要在分析阶段草率结束，即使你认为已经找到了解决方案，也要继续分析。"确保彻底探索问题。
持续信心检查 - pacnpal
"在保存文件前、保存后、被拒绝时以及任务完成前，对信心进行评分（1-10）。"通过自我评估来维持质量。
最佳实践 🎯
项目结构 - kvs007
"在建议结构或依赖关系更改之前，请检查项目文件。"维持项目完整性。
批判性思维 - chinesesoup
"提出‘愚蠢’的问题，例如：‘确定这真的是实现这一点的最佳方法吗？’"质疑假设，发现更好的解决方案。
代码样式 - yellow_bat_coffee
在提示中使用诸如“优雅”和“简洁”等词语可能影响代码组织和清晰度。
设置期望 - steventcramer
"人类会很生气。"（这是一个幽默的提醒，强调请提供清晰的要求和建设性反馈）
Last updated