Cline 本地提示指南 🚀

欢迎来到 Cline 本地提示指南！本指南将帮助您掌握编写有效提示和自定义指令的技巧，充分利用 Cline 的功能。

自定义指令 ⚙️

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

添加自定义指令的步骤如下：

1. 打开 VSCode

2. 点击 Cline 插件设置图标 ⚙️

3. 找到“自定义指令”字段

4. 粘贴您的指令

自定义指令的强大之处在于：

• 强制编码风格和最佳实践：确保 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 测试

关键优势

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），说明工具使用如何帮助项目。"

  鼓励批判性思维，使决策过程更加透明。

代码质量提示 💻

• 防止代码截断

  "不要偷懒。请不要遗漏代码。"

  替代短语： "仅完整代码" 或 "确保代码完整"

• 自定义指令提醒

  "我承诺遵循自定义指令。"

  强化您在设置 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

  "人类会很生气。"

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