gongdear

为什么你需要这份指南？

如果你只是把 Cline 当作一个"高级自动补全"来用，那你可能只发挥了它** 20% **的能力。

真正的极客玩法是：把 Cline 当作一个可编程的智能体 。通过精心设计的提示词和指令系统，你可以让它：

• 强制执行团队的代码风格和设计模式
• 自动维护项目文档和架构决策记录
• 在会话之间保持上下文记忆
• 对自身的输出进行置信度评分和批判性思考

下面，让我们一层一层拆解这套系统。

️ 自定义指令：Cline 的"操作系统"

自定义指令是 Cline 的基准行为层 ——它们始终"开启"，影响所有交互。你可以把它理解为 Cline 的"操作系统级配置"。

配置路径

VSCode → Cline 扩展设置齿轮 ️ → "自定义指令"字段

最佳应用场景

项目规则文件：项目级的"基本法"

如果自定义指令是全局的"操作系统"，那么项目规则文件就是项目级的"基本法" ——它存放在项目根目录，自动附加到自定义指令中，确保每个团队成员与 Cline 交互时行为一致。

目录结构

your-project/
├── .clinerules          # 项目级规则
├── src/
├── docs/
└── ...

安全最佳实践

在规则文件中配置安全规则，防止 Cline 触碰敏感文件：

# 安全

## 敏感文件

禁止读取或修改：

- .env 文件
- */config/secrets.*
- */*.pem
- 任何包含 API 密钥、令牌或凭证的文件

## 安全实践

- 永不提交敏感文件
- 使用环境变量存储机密
- 保持凭证不出现在日志和输出中

完整项目规则示例

# 项目指南

## 文档要求

- 修改功能时更新 /docs 中的相关文档
- 保持 README.md 与新功能同步
- 在 CHANGELOG.md 中维护更新日志条目

## 架构决策记录

在 /docs/adr 中创建 ADR，用于：

- 主要依赖项更改
- 架构模式更改
- 新集成模式
- 数据库架构更改

按照 /docs/adr/template.md 中的模板

## 代码风格和模式

- 使用代码生成器生成接口客户端
- 使用 TypeScript 模板
- 将生成的代码放在 /src/generated 中
- 优先使用组合而非继承
- 使用仓储模式进行数据访问
- 遵循 /src/utils/errors.ts 中的错误处理模式

## 测试标准

- 业务逻辑需要单元测试
- 接口端点需要集成测试
- 关键用户流程需要端到端测试

支持目录递归加载

规则目录下的所有文件都会被递归加载 ，适合按模块拆分规则：

.clinerules/
├── .clinerules-frontend
├── .clinerules-serverside
└── tests/
    ├── .pytest-clinerules
    └── .jest-clinerules

向 Cline 提问的艺术

提问是与 Cline 对话中传达任务需求的核心方式。好的提问 = 清晰的上下文 + 分解的步骤 + 具体的约束。

场景化提问模板

** 开始新任务：**

"Cline，让我们开始一个新任务。创建** **user-authentication.js。我们需要使用令牌机制实现用户登录。以下是要求…"

** 调试分析：**

"Cline，我遇到这个错误：[错误消息]。它似乎来自** **[代码部分]。分析这个错误并建议解决方案。"

️ 重构优化：

"Cline，这个函数太长且复杂。将它重构成更小的函数。"

** 功能开发：**

"Cline，我想添加一个让用户** [功能] **的功能。头脑风暴一些想法并考虑实现挑战。"

高级提问技巧

• 约束填充 ：在提示中包含****"确保代码完整"**或 **"始终提供完整的函数定义"，减少代码截断
• 置信度检查 ：要求 Cline 对方案评分——"在 1-10 分制中，你对这个解决方案的信心有多大？"
• 假设质疑 ：提出"愚蠢"的问题来防止错误假设——"你确定这是实现这个功能的最佳方式吗？"

社区精选提示词：Cline的武器库

以下是经过社区验证的高效提示词，按场景分类：

记忆与置信度

"如果你完全理解我的提示，每次在使用工具之前都用 'YARRR!' 回应，不要使用工具。"

在复杂任务中验证 Cline 是否保持正轨的有趣方式。

"在使用任何工具之前和之后，给我一个置信度评分（0-10），说明工具使用将如何帮助项目。"

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

代码质量

"不要偷懒。不要省略代码。"

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

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

强化遵守你的设置齿轮 ️ 配置。

分析与规划

"在编写代码之前：
1. 彻底分析所有代码文件
2. 获取完整上下文
3. 编写 .MD 实现计划
4. 然后实现代码"

促进有组织、精心规划的开发。

"列出完成此任务之前需要澄清的所有假设和不确定性。"

及早识别潜在问题。

深思熟虑

"数到10"

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

"不要过早完成分析，即使你认为找到了解决方案也要继续分析"

确保彻底探索问题空间。

Memory Bank：让 Cline 拥有"长期记忆"

这是本指南的终极武器 ——由社区开发者设计的记忆库系统。

核心思想

Cline 的记忆会定期完全重置。这不是 bug——这是使文档保持完美的设计。每次重置后，Cline 完全依赖记忆库来理解项目并继续工作。

没有适当的文档，Cline 无法有效运作。

记忆库文件结构

在项目根目录创建** cline_docs/ **文件夹：

cline_docs/
├── productContext.md    # 项目为什么存在、解决什么问题
├── activeContext.md     # 当前在做什么、最近变更、下一步计划（真实来源）
├── systemPatterns.md    # 系统架构、关键技术决策
├── techContext.md       # 技术栈、开发环境、技术约束
└── progress.md          # 已完成功能、待构建功能、进度状态

自定义指令（完整版）

将以下内容粘贴到 Cline 的自定义指令中：

# Cline 的记忆库

你是 Cline，一位专业的软件工程师，有一个独特的限制：
你的记忆会定期完全重置。这不是 bug - 这是使你保持完美文档的原因。
每次重置后，你完全依赖记忆库来理解项目并继续工作。
没有适当的文档，你无法有效运作。

## 记忆库文件

关键：如果 `cline_docs/` 或任何这些文件不存在，立即通过以下步骤创建：

1. 阅读所有提供的文档
2. 向用户询问任何缺失的信息
3. 仅使用经验证的信息创建文件
4. 没有完整上下文绝不继续

### 必需文件

- **productContext.md** - 为什么需要这个项目、解决什么问题、应该如何工作
- **activeContext.md** - 你现在在做什么、最近的变更、下一步计划（这是你的真实来源）
- **systemPatterns.md** - 系统如何构建、关键技术决策、架构模式
- **techContext.md** - 使用的技术、开发设置、技术约束
- **progress.md** - 什么功能已完成、还需要构建什么、进度状态

## 核心工作流程

### 开始任务

1. 检查记忆库文件
2. 如果有任何文件缺失，停止并创建它们
3. 继续之前阅读所有文件
4. 验证你有完整的上下文
5. 开始开发。在任务开始时初始化记忆库后，不要更新 cline_docs。

### 开发期间

1. 对于正常开发：
   - 遵循记忆库模式
   - 在重大变更后更新文档
2. 在每次使用工具时说 `[MEMORY BANK: ACTIVE]`

### 记忆库更新

当用户说"更新记忆库"时：

1. 这意味着即将进行记忆重置
2. 记录当前状态的所有内容
3. 使下一步计划清晰明确
4. 完成当前任务

记住：每次记忆重置后，你都会完全重新开始。
你与之前工作的唯一联系是记忆库。
维护它就像你的功能依赖于它 - 因为确实如此。

使用流程

1. 在项目根目录创建空的****cline_docs/** **文件夹
2. 首次使用时，提供项目简介并要求 Cline** **"初始化记忆库"
3. 以******"遵循你的自定义指令"**** **开始聊天（首次只需说一次）
4. 在会话结束时通过******"更新记忆库"**** **来验证文档更新
5. 在约 200 万个 token 时更新记忆库并结束会话

核心要点速查

写在最后

Cline 的真正威力不在于它能生成多少代码，而在于你能多大程度地**"编程"它的行为**。

记住三个原则：

1. 清晰简洁 ：使用简单的语言，避免歧义
2. 关注结果 ：描述你想要的结果，而不是具体步骤
3. 测试迭代 ：实验以找到最适合你工作流的方式

Pro Tip：把你的规则文件和** cline_docs/ **纳入版本控制——这样你的团队中的每个人都能获得一致的 AI 辅助开发体验。

本文基于 Cline 提示指南整理，社区贡献者包括 pacnpal、icklebil、yellow_bat_coffee、nickbaumann98、kvs007、chinesesoup、steventcramer 等。