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 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
如上面这个要求，它让 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 发起请求时，请求本身的提示词之前，会注入系统提示词和自定义指令，即：
提示词 = 系统提示词注入 + 自定义指令 + 用户请求提示词 提示词=系统提示词注入+自定义指令+用户请求提示词 提示词=系统提示词注入+自定义指令+用户请求提示词
细节
- 注入 system.ts 中的提示词
- 注入 cline 设置中的 custom instructions
- 注入 .clinerules
- 注入 项目根目录 .clinerules 文件里面的指令
- 或 注入 项目根目录 .clinerules 文件夹里面所有 md 文件里面的指令
- 注入用户输入的提示词
这是一个简化的模型，为构建上下文以使用户要求的任务精准完成，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）”
最佳实践
- 维护项目完整性：“在结构和依赖变更前，检查项目文件”
- 批判性思维：“你确信这是最好的实现这个的方法么？”
- 代码风格：“简单的” “优雅的”
