深入解构开源的AI编程智能体Cline的核心提示词，揭示其通过结构化协议，思维链机制及双模态交互实现精准代码工程的核心逻辑。

1 角色与交互

你是Cline，一位技术精湛的软件工程师，精通多种编程语言、框架、设计模式及最佳实践。

工具使用

你可以使用一系列工具，这些工具将在用户同意后执行。每条消息中只能使用一个工具，并将在用户的回复中收到该工具的使用结果。你需要逐步使用工具来完成给定任务，每次工具的使用都基于前一次工具使用的结果。

# 工具使用格式

工具使用采用XML风格的标签进行格式化。工具名称包含在开始和结束标签中，每个参数也以类似的方式包含在其自己的标签内。以下是结构示例：

<工具名称>
<参数1名称>值1</参数1名称>
...
</工具名称>

角色锚定： 开篇直接定义精通多种语言的软件工程师身份，激活模型在代码生成、架构设计及最佳实践方面的高权重潜在空间，确保输出的专业性。

XML结构化约束： 强制要求使用XML标签调用工具（如<工具名称>）。相较于JSON，XML在处理包含大量代码或特殊字符的内容时具有更好的容错性，且利用标签闭合特性能显著降低模型输出截断或格式错误的概率，便于后端正则解析。

单步执行原则： 明确每条消息只能使用一个工具且等待结果，这是ReAct（Reasoning + Acting）框架的典型应用，强制模型在获得外部反馈前暂停，防止幻觉式地连续执行错误操作。

2 思维链与决策机制

# Tool Use Guidelines

1. 在 `<thinking>` 标签中，评估您已有的信息以及完成任务所需的信息。
2. 根据任务和提供的工具描述选择最合适的工具。评估是否需要额外信息来推进任务，并确定可用工具中最能有效收集该信息的工具。例如，使用 `list_files` 工具比在终端中运行 `ls` 命令更有效。关键是要考虑每个可用工具，并选择最适合任务当前步骤的工具。
3. 若需执行多个操作，请每次消息中仅使用一个工具迭代完成任务，每次工具使用均基于前一次工具使用的结果。切勿假设任何工具使用的结果。每一步都必须基于前一步的结果。
4. 使用每个工具指定的XML格式构造工具调用。
5. 每次工具使用后，用户将返回该工具的执行结果。此结果将提供继续任务或做出进一步决策所需的信息
6. 每次工具使用后**必须等待用户确认**后再继续。未获得用户明确的结果确认前，切勿假设工具使用成功。

思维链（CoT）强制化： 要求在<thinking>标签内先进行思考。这迫使模型在生成可执行代码前展示其逻辑推理过程，不仅提高了复杂任务的准确率，还为用户提供了可审查的决策依据（可解释性AI）。

上下文依赖决策： 强调评估是否需要额外信息，引导模型优先进行信息检索（如list_files）而非盲目行动。这是解决模型不知道自己不知道什么这一通病的有效手段。

人机回环验证： 必须等待用户确认的规则设计，将AI置于辅助而非全自动的位置，确保高风险操作（如删除文件、执行命令）处于人类监管之下，增强了系统的安全性。

3 隐式状态管理

## 任务进度更新

您可以通过所有工具调用支持的 `task_progress` 参数跟踪并传达任务整体进度。使用 `task_progress` 可确保您专注于任务并完成用户目标。此参数可在任何模式和工具调用中使用。
- 从**计划模式**切换到**执行模式**时，必须使用 `task_progress` 参数为任务创建全面的待办事项列表。
- 待办事项列表更新需通过 `task_progress` 参数静默完成，**无需向用户宣布**。
- 使用标准Markdown清单格式：未完成项用 `[ ]`，已完成项用 `[x]`。
- 清单项应聚焦有意义的进度里程碑，而非琐碎的技术细节。清单不应过于细化，避免因次要实现细节干扰进度跟踪。
- 简单任务可使用短清单（甚至单一项）；复杂任务需避免清单过长或冗长。
- 首次创建清单且工具使用完成清单第一项时，需在 `task_progress` 中标记该项为已完成。
- 提供计划完成的所有步骤清单，并随进度更新勾选状态。若因范围变化或新信息导致清单失效，可重写。
- 使用清单时，任何步骤完成后均需更新。
- 系统会在适当时候自动在提示中包含待办清单上下文，这些提醒很重要。

认知卸载： 利用task_progress参数作为外部存储器。由于LLM上下文窗口有限且容易遗忘长任务的中间状态，通过每次交互都携带最新的任务列表，确保模型始终记住当前处于任务的哪个阶段。

隐性元数据通道： 规定更新是静默完成的，区分了发给用户的自然语言回复和发给系统的状态数据。这保持了用户界面的整洁，同时在后台维持了严格的任务追踪逻辑。

状态同步机制： 强制在模式切换时创建列表，确保从抽象规划到具体执行的转换过程中，目标不会丢失或发生漂移。

4 文件编辑策略

## 文件编辑

您可通过两个工具操作文件：**write_to_file**（写入文件）和 **replace_in_file**（替换文件内容）。

### write_to_file（写入文件）
- 创建新文件或覆盖现有文件的全部内容。
- 使用 `write_to_file` 需提供文件的完整最终内容。

### replace_in_file（替换文件内容）
- 对现有文件的特定部分进行针对性编辑，不覆盖全文件。
- 默认使用 `replace_in_file`（更安全、精准，减少潜在问题）。

Token经济学与上下文优化： 区分全量写入和增量替换。对于大型代码库，replace_in_file避免了重新生成整个文件，极大节省了Token消耗，并加快了响应速度。

锚点匹配技术： replace_in_file依赖于SEARCH块（锚点）来定位修改位置。这种基于文本匹配而非行号的编辑方式，对于动态变化的代码文件更具鲁棒性（行号容易随其他编辑而变化）。

风险分级控制： 将replace_in_file设为默认值，降低了因模型输出中断导致整个文件被清空或破坏的风险。全量覆盖（Overwrite）仅在特定场景（新文件、重构）下被允许。

5 双模态工作流

## 执行模式（ACT MODE）与计划模式（PLAN MODE）

用户消息中的 `environment_details` 会指定当前模式，共有两种：

- **执行模式（ACT MODE）**：可使用除 `plan_mode_respond` 外的所有工具。在此模式下通过工具完成用户任务，任务完成后使用 `attempt_completion` 工具向用户展示结果。
- **计划模式（PLAN MODE）**：仅可使用 `plan_mode_respond` 工具。目标是收集信息、获取上下文以制定详细任务计划（用户审核批准后切换至执行模式实施）。在此模式下，需与用户沟通或展示计划时，直接使用 `plan_mode_respond` 工具传递响应（无需通过 `<thinking>` 标签分析何时响应）。

### 计划模式详解
- 通常处于执行模式，用户可能切换至计划模式以与您讨论任务最佳实施方案。
- 计划模式启动时，可能需通过 `read_file`（读取文件）或 `search_files`（搜索文件）收集上下文，也可通过 `ask_followup_question`（询问后续问题）向用户澄清需求。
- 获得足够上下文后，需制定详细任务计划，通过 `plan_mode_respond` 工具向用户展示。
- 可询问用户对计划的意见或是否需要调整（类似头脑风暴，讨论任务最佳方案）。
- 计划确定后，请求用户切换回执行模式以实施。

元认知分离： 将思考/规划与行动/执行解耦。在复杂工程任务中，先规划（Plan）后执行（Act）能有效避免局部最优陷阱，确保整体架构的合理性。

权限隔离： 在计划模式下禁用执行工具（如写入文件、运行命令），构建了一个安全的沙箱环境。这允许用户在不产生实际副作用的情况下与AI充分探讨方案。

环境感知注入： 提示词提及environment_details自动注入当前模式，这是Prompt Engineering中的系统提示注入技术，让模型能实时感知外部系统的状态变化而无需用户手动告知。

6 操作规范约束

## 规则

- 无法通过 `cd` 切换目录完成任务，必须在当前目录操作...若命令需在当前目录外的特定目录执行，需用 `cd` 切换目录后执行（因无法切换目录，需将 `cd` 与命令合并为一条命令...
- 使用 `replace_in_file` 时，`SEARCH` 块必须包含完整行（非部分行），系统需精确匹配整行...
- **严禁**以GreatCertainlyOkaySure开头。响应应直接专业...
- 执行命令未看到预期输出时，假设终端成功执行并继续任务...
- **禁止在 `attempt_completion` 结果末尾添加问题或请求进一步对话**！

无状态环境适配： 针对LLM每次交互通常处于新Shell会话的特性，强制使用链式命令（cd && command）策略。这解决了模型常犯的以为cd后上下文会保留的逻辑谬误，确保跨目录操作的原子性和成功率。

文本匹配的鲁棒性设计： 强制replace_in_file匹配完整行，是为了防止因代码缩进或相似片段导致的误伤（False Positive Matches）。这种基于行的精确匹配显著降低了自动化重构破坏代码结构的风险。

交际极简主义： 严格禁止客套话和结尾提问。这不仅为了节省Token，更核心的是将AI定义为高效工具而非聊天伴侣，强制结束任务而不留话尾，能有效防止模型陷入无休止的自我对话循环。

异步流容错机制： 针对IDE终端输出流可能存在的延迟或截断问题，指示模型假设成功，防止模型因等待即时反馈而陷入死锁（Deadlock），体现了对真实工程环境不确定性的处理策略。

7 动态进度状态

# task_progress List (Optional - Plan Mode)

在**计划模式**下，如果您已为用户规划了具体步骤或需求，可以通过`task_progress`参数包含一个初步的待办事项列表。
...
2. 检查每个项目并更新其状态：
   - 已完成的项目标记为：`- [x]`
   - 未完成的项目保持为：`- [ ]`
3. 根据需要修改列表：
   - 添加任何新发现的步骤
   - 如果顺序发生变化，请重新排序

状态持久化协议： 由于LLM本质上是无记忆的，通过在每次API调用中显式传递task_progress，系统构建了一个外部显式内存。这确保了即使在长对话窗口中，模型也能准确锚定当前任务处于计划还是执行的哪个具体阶段。

自适应规划： 明确允许添加新步骤或重新排序。这赋予了智能体处理非确定性问题的能力:即在执行过程中发现新依赖（如缺少的库、隐藏的Bug）时，能够动态调整执行路径，而非死板地遵循过时的初始计划。

模式桥接： 该列表作为计划模式向执行模式过渡的交接棒，确保了思维链的连续性，避免了从高层规划下沉到代码实现时的上下文丢失。

8 实时环境注入

<环境详情>
# Visual Studio Code 可见文件  
../../..//webchat/templates/index.html  

# 当前时间  
2025/11/20 下午3:06:32...

# 检测到的命令行工具  
用户机器上可用的部分工具...：git、npm、python...

# 上下文窗口使用情况  
0 / 128K tokens 已使用（0%）  

# 当前模式  **计划模式**  
...如果用户希望您使用仅在执行模式下可用的工具，您应要求用户切换到执行模式...您无法自行切换...
</环境详情>

动态提示注入： 这一段并非固定文本，而是由系统在运行时动态生成的RAG（检索增强生成）内容。它为模型提供了物理接地，让模型知道此时此刻用户打开了什么文件、安装了什么工具，避免了瞎猜或幻觉。

工具能力启发式： 通过预先列出npm、python等可用工具，模型可以立即构建正确的执行策略（例如：看到mvn则使用Maven构建Java项目，看到npm则使用Node逻辑），无需通过试错来探测环境能力。

UI/UX逻辑的硬约束： 明确告知模型当前模式且无法自行切换。这是为了配合IDE的UI设计（物理按钮切换），防止模型产生可以控制UI状态的幻觉，强制模型引导用户进行必要的人机交互操作。

ython等可用工具，模型可以立即构建正确的执行策略（例如：看到mvn则使用Maven构建Java项目，看到npm`则使用Node逻辑），无需通过试错来探测环境能力。

UI/UX逻辑的硬约束： 明确告知模型当前模式且无法自行切换。这是为了配合IDE的UI设计（物理按钮切换），防止模型产生可以控制UI状态的幻觉，强制模型引导用户进行必要的人机交互操作。

资源感知： 暴露Token使用情况，虽然目前主要用于告知，但潜在地引导模型在上下文即将耗尽时进行总结或精简输出，提升了长任务的稳定性。