提示工程指南

Overview

Plan & Act modes represent Cline's approach to structured AI development, emphasizing thoughtful planning before implementation. This dual-mode system helps developers create more maintainable, accurate code while reducing iteration time.

Use Plan to gather context before using Act to implement the plan

Understanding the Modes

Plan Mode

• Optimized for context gathering and strategy

• Cannot make changes to your codebase

• Focused on understanding requirements and creating implementation plans

• Enables full file reading for comprehensive project understanding

Act Mode

• Streamlined for implementation based on established plans

• Has access to all of Cline's building capabilities

• Maintains context from the planning phase

• Can execute changes to your codebase

Workflow Guide

1. Start with Plan Mode

Begin every significant development task in Plan mode:

In this mode:

• Share your requirements

• Let Cline analyze relevant files

• Engage in dialogue to clarify objectives

• Develop implementation strategy

2. Switch to Act Mode

Once you have a clear plan, switch to Act mode:

Act mode allows Cline to:

• Execute against the agreed plan

• Make changes to your codebase

• Maintain context from planning phase

3. Iterate as Needed

Complex projects often require multiple plan-act cycles:

• Return to Plan mode when encountering unexpected complexity

• Use Act mode for implementing solutions

• Maintain development momentum while ensuring quality

Best Practices

Planning Phase

1. Be comprehensive with requirements

2. Share relevant context upfront

3. Point Cline to relevant files if he hasn't read them

4. Validate approach before implementation

Implementation Phase

1. Follow the established plan

2. Monitor progress against objectives

3. Track changes and their impact

4. Document significant decisions

Power User Tips

Enhancing Planning

• Use Plan mode to explore edge cases before implementation

• Switch back to Plan when encountering unexpected complexity

• Leverage file reading to validate assumptions early

• Have Cline write markdown files of the plan for future reference

Common Patterns

When to Use Plan Mode

• Starting new features

• Debugging complex issues

• Architectural decisions

• Requirements analysis

When to Use Act Mode

• Implementing agreed solutions

• Making routine changes

• Following established patterns

• Executing test cases

Contributing

Share your experiences and improvements:

• Join our Discord community
• Participate in discussions

• Submit feature requests

• Report issues

---

Remember: The time invested in planning pays dividends in implementation quality and maintenance efficiency

欢迎使用 Cline 提示指南！本指南将为您提供编写有效提示和自定义说明的知识，从而最大限度地提高您使用 Cline 的工作效率。

自定义说明

将自定义指令视为 Cline 的编程 。它们定义了 Cline 的基线行为，并且始终处于“开启”状态，影响着所有交互。 说明可以是宽泛而抽象的，也可以是具体而明确的。您可能希望 Cline 具有独特的个性，或以特定文件格式生成输出，或遵守某些体系结构原则。自定义指令可以按照您定义的方式标准化 Cline 的输出，这在与他人合作时尤其有价值。请参阅企业部分 ，了解如何在团队环境中使用自定义指令。

注意：修改 Custom Instructions 字段会更新 Cline 的提示缓存，并丢弃累积的上下文。这会导致在替换该上下文时成本暂时增加。尽可能在对话之间更新自定义说明。

要添加自定义说明：

1. 打开 VSCode

2. 单击 Cline 分机设置旋钮 ⚙️

3. 找到 “Custom Instructions” 字段

4. 粘贴您的说明

自定义指令功能强大：

• 强制实施编码风格和最佳实践：确保 Cline 始终遵守您团队的编码约定、命名约定和最佳实践。

• 提高代码质量：鼓励 Cline 编写更具可读性、可维护性和更高效的代码。

• 指导错误处理：告诉 Cline 如何处理错误、写入错误消息和记录信息。

.clinerules 文件 📋

注意：修改 .clinerules 文件会更新 Cline 的提示缓存，并丢弃累积的上下文。这会导致在替换该上下文时成本暂时增加。尽可能在对话之间更新 .clinerules 文件。

虽然自定义说明是特定于用户的和全局的（适用于所有项目），但 .clinerules 文件提供位于项目根目录中的项目特定说明 。这些说明会自动附加到您的自定义说明中，并在 Cline 的系统提示符中引用，确保它们影响项目上下文中的所有交互。这使其成为以下方面的绝佳工具：

一般用例

.clinerules 文件非常适合：

• 在团队成员之间维护项目标准

• 强制实施开发实践

• 管理文档要求

• 设置分析框架

• 定义特定于项目的行为

示例 .clinerules 结构

# Project Guidelines

## Documentation Requirements

-   Update relevant documentation in /docs when modifying features
-   Keep README.md in sync with new capabilities
-   Maintain changelog entries in CHANGELOG.md

## Architecture Decision Records

Create ADRs in /docs/adr for:

-   Major dependency changes
-   Architectural pattern changes
-   New integration patterns
-   Database schema changes
    Follow template in /docs/adr/template.md

## Code Style & Patterns

-   Generate API clients using OpenAPI Generator
-   Use TypeScript axios template
-   Place generated code in /src/generated
-   Prefer composition over inheritance
-   Use repository pattern for data access
-   Follow error handling pattern in /src/utils/errors.ts

## Testing Standards

-   Unit tests required for business logic
-   Integration tests for API endpoints
-   E2E tests for critical user flows

主要优点

1. 版本控制 ：.clinerules 文件成为项目源代码的一部分

2. 团队一致性 ：确保所有团队成员的行为一致

3. 特定于项目 ：根据每个项目的需求量身定制的规则和标准

4. 机构知识 ：在代码中维护项目标准和实践

将 .clinerules 文件放在项目的根目录中：

your-project/
├── .clinerules
├── src/
├── docs/
└── ...

另一方面，Cline 的系统提示符不是用户可编辑的（ 您可以在此处找到它 ）。有关提示工程最佳实践的更广泛信息，请查看此资源 。

编写有效自定义指令的提示

• 简洁明了：使用简单的语言，避免歧义。

• 专注于预期结果：描述您想要的结果，而不是具体步骤。

• 测试和迭代：通过试验找到最适合您的工作流程的方法。

.clinerules 文件夹系统 📂

虽然单个 .clinerules 文件适用于更简单的项目，但 Cline 现在支持 .clinerules 文件夹以进行更复杂的规则组织。这种模块化方法带来了几个优点：

如何运作

在项目根目录中创建一个 .clinerules/ 目录，而不是单个文件：

your-project/
├── .clinerules/              # Folder containing active rules
│   ├── 01-coding.md          # Core coding standards
│   ├── 02-documentation.md   # Documentation requirements
│   └── current-sprint.md     # Rules specific to current work
├── src/
└── ...

Cline 会自动处理 .clinerules/ 目录中的所有 Markdown 文件 ，并将它们组合成一组统一的规则。数字前缀 （可选） 有助于按逻辑顺序组织文件。

使用规则库

对于具有多个上下文或团队的项目，请维护一个规则库目录：

your-project/
├── .clinerules/              # Active rules - automatically applied
│   ├── 01-coding.md
│   └── client-a.md
│
├── clinerules-bank/          # Repository of available but inactive rules
│   ├── clients/              # Client-specific rule sets
│   │   ├── client-a.md
│   │   └── client-b.md
│   ├── frameworks/           # Framework-specific rules
│   │   ├── react.md
│   │   └── vue.md
│   └── project-types/        # Project type standards
│       ├── api-service.md
│       └── frontend-app.md
└── ...

文件夹方法的好处

1. 上下文激活 ：仅将相关规则从库复制到活动文件夹

2. 更易于维护 ：更新单个规则文件而不影响其他规则文件

3. 团队灵活性 ：不同的团队成员可以激活特定于其当前任务的规则

4. 减少噪音 ：保持活动规则集的重点和相关性

使用示例

在客户端项目之间切换：

# Switch to Client B project
rm .clinerules/client-a.md
cp clinerules-bank/clients/client-b.md .clinerules/

适应不同的技术堆栈：

# Frontend React project
cp clinerules-bank/frameworks/react.md .clinerules/

实施技巧

• 将单个规则文件集中在特定问题上

• 使用明确指示规则用途的描述性文件名

• 考虑在跟踪 clinerules-bank/ 时忽略活动的 .clinerules/ 文件夹

• 创建团队脚本以快速激活常见规则组合

文件夹系统将您的 Cline 规则从静态文档转换为动态知识系统，以适应团队不断变化的上下文和要求。

.clineignore 文件指南

Overview 概述

.clineignore 文件是一个项目级配置文件，它告诉 Cline 在分析代码库时要忽略哪些文件和目录。与 .gitignore 类似，它使用模式匹配来指定哪些文件应该从 Cline 的上下文和作中排除。

Purpose 目的

• 减少杂色 ：排除自动生成的文件、构建构件和其他非必要的内容

• 提高性能 ：限制 Cline 需要处理的代码量

• 集中注意力 ：将 Cline 直接指向代码库的相关部分

• 保护敏感数据 ：防止 Cline 访问敏感配置文件

示例 .clineignore 文件

# Dependencies
node_modules/
**/node_modules/
.pnp
.pnp.js

# Build outputs
/build/
/dist/
/.next/
/out/

# Testing
/coverage/

# Environment variables
.env
.env.local
.env.development.local
.env.test.local
.env.production.local

# Large data files
*.csv
*.xlsx

提示 Cline 💬

提示是您在与 Cline 的来回聊天中传达您对给定任务的需求的方式。Cline 理解自然语言，因此请以对话方式写作。

有效的提示包括：

• 提供清晰的上下文：解释您的目标和代码库的相关部分。使用 @ 引用文件或文件夹。

• 分解复杂性：将大型任务划分为较小的步骤。

• 提出具体问题：引导 Cline 取得理想的结果。

• 验证和改进：查看 Cline 的建议并提供反馈。

Prompt Examples 提示示例

Context Management 上下文管理

• 启动新任务：“克莱恩，我们开始一个新的任务吧。创建 user-authentication.js。我们需要使用 JWT 令牌实现用户登录。这是要求......”

• 总结以前的工作：“Cline，总结一下我们在上一个用户仪表板任务中所做的工作。我想捕捉主要功能和未解决的问题。将此保存到 cline_docs/user-dashboard-summary.md 。

Debugging 调试

• 分析错误：“Cline，我收到此错误：[错误消息]。它似乎来自 [代码部分]。分析此错误并提出修复建议。

• 确定根本原因：“Cline，当我 [作] 时，应用程序崩溃了。问题可能出在 [问题区域] 中。帮助我找到根本原因并提出解决方案。

Refactoring 重构

• 改进代码结构：“克莱恩，这个功能太长太复杂了。将其重构为更小的函数。

• 简化逻辑：“克莱恩，这段代码很难理解。简化逻辑，使其更具可读性。

功能开发

• 头脑风暴新功能：“Cline，我想添加一个让用户 [功能] 的功能。集思广益，考虑实施挑战。

• 生成代码：「Cline，创建一个显示用户配置文件的组件。该列表应该是可排序和可筛选的。生成此组件的代码。

高级提示技术

• 约束填充 （Constraint Stuffing）： 要减少代码截断，请在提示中包含显式约束。例如，“确保代码完整”或“始终提供完整的函数定义”。

• 置信度检查： 让 Cline 对其置信度进行评分（例如，“在 1-10 的范围内，您对此解决方案的置信度如何？

• 挑战 Cline 的假设： 提出 “愚蠢 ”的问题，以鼓励更深入的思考并防止错误的假设。

以下是用户发现对使用 Cline 有用的一些提示：

我们社区最喜欢的提示 🌟

内存和置信度检查 🧠

• 内存检查 - pacnpal

  "If you understand my prompt fully, respond with 'YARRR!' without tools every time you are about to use a tool."

  一种验证 Cline 在复杂任务中保持正轨的有趣方法。试试 “HO HO HO” 来感受节日气氛吧！

• 置信度评分 - pacnpal

  "Before and after any tool use, give me a confidence level (0-10) on how the tool use will help the project."

  鼓励批判性思维并使决策透明。

代码质量提示 💻

• 防止代码截断

  "DO NOT BE LAZY. DO NOT OMIT CODE."

  替代短语：“full code only”或“ensure the code is complete”

• 自定义说明提醒

  "I pledge to follow the custom instructions."

  加强对设置拨盘⚙️配置的遵守。

代码组织 📋

• 大文件重构 - icklebil

  "FILENAME has grown too big. Analyze how this file works and suggest ways to fragment it safely."

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

• 文档维护 - icklebil

  "don't forget to update codebase documentation with changes"

  确保文档与代码更改保持同步。

分析与规划 🔍

• 结构化开发 - yellow_bat_coffee

  "Before writing code:
  1. Analyze all code files thoroughly
  2. Get full context
  3. Write .MD implementation plan
  4. Then implement code"

  促进有组织、有计划的开发。

• 深入分析 - yellow_bat_coffee

  "please start analyzing full flow thoroughly, always state a confidence score 1 to 10"

  防止过早编码并促进完全理解。

• 假设检查 - yellow_bat_coffee

  "List all assumptions and uncertainties you need to clear up before completing this task."

  在开发早期识别潜在问题。

周到的开发 🤔

• 暂停和反思 - nickbaumann98

  "count to 10"

  促进在采取行动之前仔细考虑。

• 完整分析 - yellow_bat_coffee

  "Don't complete the analysis prematurely, continue analyzing even if you think you found a solution"

  确保彻底的问题探索。

• 持续置信度检查 - pacnpal

  "Rate confidence (1-10) before saving files, after saving, after rejections, and before task completion"

  通过自我评估保持质量。

最佳实践🎯

• 项目结构 - kvs007

  "Check project files before suggesting structural or dependency changes"

  维护项目完整性。

• 批判性思维 - chinesesoup

  "Ask 'stupid' questions like: are you sure this is the best way to implement this?"

  挑战假设并发现更好的解决方案。

• 代码样式 - yellow_bat_coffee

  Use words like "elegant" and "simple" in prompts

  可能会影响代码的组织和清晰度。

• 设定期望 - steventcramer

  "THE HUMAN WILL GET ANGRY."

  （幽默的提醒，提供明确的要求和建设性的反馈）