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）”

最佳實踐

• 維護項目完整性：“在結構和依賴變更前，檢查項目文件”
• 批判性思維：“你確信這是最好的實現這個的方法么？”
• 代碼風格：“簡單的” “優雅的”