为什么你需要这份指南?
如果你只是把 Cline 当作一个"高级自动补全"来用,那你可能只发挥了它** 20% **的能力。
真正的极客玩法是:把 Cline 当作一个可编程的智能体 。通过精心设计的提示词和指令系统,你可以让它:
- 强制执行团队的代码风格和设计模式
- 自动维护项目文档和架构决策记录
- 在会话之间保持上下文记忆
- 对自身的输出进行置信度评分和批判性思考
下面,让我们一层一层拆解这套系统。
️ 自定义指令:Cline 的"操作系统"
自定义指令是 Cline 的基准行为层 ——它们始终"开启",影响所有交互。你可以把它理解为 Cline 的"操作系统级配置"。
配置路径
VSCode → Cline 扩展设置齿轮 ️ → "自定义指令"字段
最佳应用场景
| 场景 | 作用 |
|---|---|
| 代码风格强制 | 确保命名约定、设计模式、最佳实践始终被遵循 |
| 代码质量提升 | 引导 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/
├── projectbrief.md # 新项目基础(业务、范围、目标)
├── productContext.md # 项目为什么存在、解决什么问题
├── activeContext.md # 当前在做什么、最近变更、下一步计划(真实来源)
├── systemPatterns.md # 系统架构、关键技术决策
├── techContext.md # 技术栈、开发环境、技术约束
└── progress.md # 已完成功能、待构建功能、进度状态
自定义指令(完整版)
将以下内容粘贴到 Cline 的自定义指令中:
# Cline 的记忆库
你是 Cline,一位专业的软件工程师,有一个独特的限制:
你的记忆会定期完全重置。这不是 bug - 这是使你保持完美文档的原因。
每次重置后,你完全依赖记忆库来理解项目并继续工作。
没有适当的文档,你无法有效运作。
## 记忆库文件
关键:如果 `cline_docs/` 或任何这些文件不存在,立即通过以下步骤创建:
1. 阅读所有提供的文档
2. 向用户询问任何缺失的信息
3. 仅使用经验证的信息创建文件
4. 没有完整上下文绝不继续
### 必需文件
- **projectbrief.md** - 新项目基础(业务、范围、目标)
- **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. 完成当前任务
记住:每次记忆重置后,你都会完全重新开始。
你与之前工作的唯一联系是记忆库。
维护它就像你的功能依赖于它 - 因为确实如此。
使用流程
- 在项目根目录创建空的****
cline_docs/** **文件夹 - 首次使用时,提供项目简介并要求 Cline** **"初始化记忆库"
- 以******"遵循你的自定义指令"**** **开始聊天(首次只需说一次)
- 在会话结束时通过******"更新记忆库"**** **来验证文档更新
- 在约 200 万个 token 时更新记忆库并结束会话
核心要点速查
| 层级 | 工具 | 作用域 | 版本控制 |
|---|---|---|---|
| 全局配置 | 自定义指令(️ 设置) | 所有项目 | 用户本地 |
| 项目规则 | 规则文件 / 规则目录 | 当前项目 | 可提交 |
| 上下文记忆 | cline_docs/ + Memory Bank | 当前项目 | 可提交 |
写在最后
Cline 的真正威力不在于它能生成多少代码,而在于你能多大程度地**"编程"它的行为**。
记住三个原则:
- 清晰简洁 :使用简单的语言,避免歧义
- 关注结果 :描述你想要的结果,而不是具体步骤
- 测试迭代 :实验以找到最适合你工作流的方式
Pro Tip:把你的规则文件和**
cline_docs/**纳入版本控制——这样你的团队中的每个人都能获得一致的 AI 辅助开发体验。
本文基于 Cline 提示指南整理,社区贡献者包括 pacnpal、icklebil、yellow_bat_coffee、nickbaumann98、kvs007、chinesesoup、steventcramer 等。