cline 提示词工程指南-架构篇

本篇是 cline 提示词工程指南的学习和扩展，可以参阅：

https://docs.cline.bot/improving-your-prompting-skills/prompting

前言

cline 是 vscode 的插件，用来在 vscode 里实现 ai 编程。

它使得你可以接入不同的 llm，然后使用其中某个 llm 完成 ai 编程的任务。在编程过程中 cline 可以借助 mcp 服务器，进行各种资源的操作，从而可以做一些 real stuff，而不是仅仅在聊天窗口中输出一些文本。

cline 的神奇之处在于，它本身不是通过函数调用实现的紧耦合 ai 利用，相反，它本身使用了大量提示词工程技巧，释放了 ai 的潜力，使 ai 能够完成编程的任务。

ai 编程的挑战

大模型的巨量参数和其本身具有的广泛的知识基础，使之成为可以进行编程的工具之一，挑战在于：

• 程序设计需求是复杂的，如何让 ai 充分了解需求
• 算法是复杂的，如何让 ai 实现算法并具有良好的架构
• 程序设计出错不可避免，如何让 ai 自动 debug

显然，上述问题的克服，不可能通过简单提示词交互来完成，即，程序设计的对话，和一般的问答式对话不同，它具有一些特殊的要求了流程。

理解 cline 提示词工程的基本框架和部分细节，对我们提高自身使用 cline 的效率非常重要。

自定义指令

在 cline 的设置模块，你可以看到：

UI 上的解释已经非常清楚明确了：

These instructions are added to the end of the system prompt,
sent with every request.

即，在每一个请求中，都会在系统提示词后，嵌入自定义指令。

将自定义指令看作是对cline的编程。

• 标准化 cline 输出
• 生成特定格式的文件
• 遵循某些架构原则
• 强制编码风格和最佳实践
• 孤立 cline 写高质量代码
• 指导错误处理：例如错误的处理、反馈和提示

📌 NOTE
修改自定义指令字段会更新 Cline 的提示缓存，丢弃累积的上下文。

因此在完成 Task 后，下一个 Task 开始前更新较好。

.clinerules

自定义提示是设置到 cline 工具的基本设置中的，这意味着，打开哪个项目，自定义指令中的要求都自动被启用。

那么，如果我有一些要求，仅仅针对当前项目呢？

这就需要一种针对某个特定项目的，项目级别的，提示词嵌入机制。

这个机制也很简单：

在项目根目录，建立 .clinerules 文件，这个文件中的指令，会自动嵌入到自定义指令中，即：

自定义指令 = cline设置中的自定义指令+项目根目录的 .clinerules指令

.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 RecordsCreate ADRs in /docs/adr for:-   Major dependency changes
-   Architectural pattern changes
-   New integration patterns
-   Database schema changesFollow 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

如上面这个要求，它让 ai：

• 更新 docs 目录下的文件，当新功能实现同步readme，维护日志
• 创建架构说明到 docs/adr （架构和数据库需求）下面的文件
• 代码上对api生成、模板、代码偏好、策略偏好进行了要求
• 测试方面要求对业务逻辑、api和关键用户流程进行测试

.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/
└── ...

如上图所示，在项目根目录的 .clinerules 文件，也可以用一个文件夹代替。

因为简单的文件一个 .clinerules 文件就行了，但是对于复杂的规则，可能就需要多个文件，此时，可以将这些文件放到 .clinerules 文件夹。

cline 会将这个文件夹下面的所有 md 文件，合并为一个整体，然后嵌入到用户指令中。

这里面，合并时，哪个文件内容在前，哪个在后呢？

注意看上面，，md 文件主名有数字前缀，cline 会参考这个前缀，按顺序合并相关 md 文件。

规则库（Rules Bank）

下面考虑一个特定场景：

一个大型工程，需要通过若干个项目达成，比如有客户端、架构设计、api和前端等多个项目。

我们可以把每个项目的规则（clinerules）整理成一个文件夹，这样，一个项目一个文件夹，就得到了多个文件夹，这个文件夹的集合，显然也是一个文件夹，就是规则库。

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
└── ...

如上图所示，
规则库放着所有可用的不同项目的规则。

然后，对于某个具体项目，只要从 clinerules-bank 中，复制一个特定的子目录内容到 .clinerules 就行了。

如前所介，复制过去的规则（.clinerules 文件夹下）就会生效。

而 clinerules-bank 里面的所有规则都不参与用户指令注入。

自定义指令的写作技巧

自定义指令指在 cline 设置 custom prompt 文本框 和 项目根目录的 .clinerules 文件中记录的提示词。

其一般写作技巧为：

• 简洁明确
• 描述期望结果，而不是步骤
• 测试和迭代，直到符合你的工作流

cline 系统提示

cline也有系统提示，也叫“内核提示”，它是 cline 系统的一部分，不可以编辑，被硬编码到了一个 ts 文件中：

https://github.com/cline/cline/blob/main/src/core/prompts/system.ts

提示词的最佳实践，可以参阅：

https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview

不同 ai 厂商的提示词最佳实践会有一定差异，上面这个链接是 anthrop 的最佳实践，对于有效使用 cline，显然非常有价值，但本篇集中在 cline 提示词工程的架构，上述最佳实践文献内容从略。

cline 提示词架构总结

当用户向 cline 发起请求时，请求本身的提示词之前，会注入系统提示词和自定义指令，即：

$提示词=系统提示词注入+自定义指令+用户请求提示词$

细节

1. 注入 system.ts 中的提示词
2. 注入 cline 设置中的 custom instructions
3. 注入 .clinerules
   • 注入 项目根目录 .clinerules 文件里面的指令
   • 或 注入 项目根目录 .clinerules 文件夹里面所有 md 文件里面的指令
4. 注入用户输入的提示词

这是一个简化的模型，为构建上下文以使用户要求的任务精准完成，cline 的上下文管理会维护多轮对话历史，但基本地，系统提示和自定义指令将始终存在于每一轮对话（每一个任务）中。

.clineignore

文件 .clineignore 是一个放置在项目根目录的文件，用于告诉 .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，让我们开始一个新任务。创建 user-authentication.js 。我们需要实现用户登录和 JWT 令牌。以下是要求……”
• 总结之前的工作
  “Cline，总结我们在上一个用户仪表板任务中做了什么。我想捕捉主要功能和未解决的问题。将此保存到 cline_docs/user-dashboard-summary.md 。”
• 分析错误
  “Cline，我遇到了这个错误：[错误信息]。它似乎来自于[代码部分]。请分析这个错误并建议一个修复方案。”
• 识别根本原因
  “Cline，当我在[操作]时应用程序崩溃。问题可能出在[问题区域]。请帮我找到根本原因并提出解决方案。”
• 优化代码结构
  “Cline，这个函数太长且复杂。将其重构为更小的函数。”
• 简化逻辑
  “Cline，这段代码难以理解。简化逻辑，使其更易于阅读。”
• 灵感激发新功能
  “Cline，我想添加一个让用户[功能]的功能。集思广益一些想法，并考虑实施挑战。”
• 生成代码
  “Cline，创建一个显示用户资料的组件。列表应可排序和可筛选。为这个组件生成代码。”

高级提示词技巧

• 约束填充
  为了减轻代码截断，请在提示中包含显式约束。例如，“确保代码完整”或“始终提供完整的函数定义。”
• 置信度检查
  请 Cline 对其置信度进行评分（例如，“在 1-10 的范围内，你对这个解决方案有多自信？”）
• 挑战 Cline 的假设
  提出“愚蠢”的问题以促进深入思考并防止错误假设。

社区精选

• “如果你完全理解了我的提示，每次你即将使用一个工具时，请用“好嘞!”回应，而不使用任何工具。”
• “在使用任何工具之前和之后，给我一个信心等级（0-10），表示该工具的使用将如何帮助项目。”
• “鼓励批判性思维，使决策过程透明。”

代码质量提示

• “不要懒惰，不要省略代码”
• “确保代码完整”
• “请遵循自定义指令”

代码重构

• “[文件名]太大了，分析这个文件的工作原理，给出安全的文件拆分建议”
• “确保文档与代码保持同步”

分析与规划

结构化开发

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

透彻分析

要防止过早编码，鼓励全面理解。

“开始分析整个流程，总是给出 1 到 10 的置信度。”

假设检查

在编码的早期发现潜在问题

“列出所有完成本任务的假设和不确定的地方”

深思熟虑的开发

• 暂停反思：“冷静，仔细考虑”
• 完整分析：“不要过早结束分析，即便你觉得已经找到了解决方案，也应当继续深入探讨。”
• 持续置信度检查

“在 保持文件前、保存文件后、被拒绝后、任务完成前给出置信度（1-10）”

最佳实践

• 维护项目完整性：“在结构和依赖变更前，检查项目文件”
• 批判性思维：“你确信这是最好的实现这个的方法么？”
• 代码风格：“简单的” “优雅的”