> ## Documentation Index > Fetch the complete documentation index at: https://cat.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # 新任务工具 ### `new_task` 工具和上下文管理策略 #### 概述 Cline 包含一个强大的内部工具 `new_task`，旨在帮助管理工作流连续性和上下文保存，特别是在复杂或长期运行的任务期间。该工具结合 Cline 对自身上下文窗口使用情况的感知和 `.clinerules` 的灵活性，支持复杂的策略来分解工作并确保任务会话之间的无缝转换。 理解核心功能以及它们如何与自定义规则交互是有效利用此功能的关键。 #### 核心功能 两个基本功能使高级上下文管理成为可能： 1. **`new_task` 工具：** * **功能：** 允许 Cline 在用户批准后结束当前任务会话并立即开始新的会话。 * **上下文预加载：** 至关重要的是，Cline 可以为这个新的任务会话**预加载**工具的 `` 块内提供的特定上下文。此上下文可以是 Cline 或 `.clinerules` 文件定义的任何内容——摘要、代码片段、下一步骤、项目状态等。 2. **上下文窗口感知：** * **跟踪：** Cline 内部跟踪任务期间当前使用的可用上下文窗口百分比。 * **可见性：** 此信息在 Cline 提示中提供的 `environment_details` 中可见。 #### 使用 `/newtask` 斜杠命令 作为 Cline 建议 `newtask` 工具或定义复杂规则的快速替代方案，您可以使用斜杠命令直接启动该过程。 * **如何：** 只需在聊天输入字段中键入 `/newtask`。 * **操作：** Cline 将建议创建新任务，通常根据当前会话建议上下文（类似于使用工具时的默认行为）。您仍然会收到 `ask_followup_question` 提示来确认并可能在创建新任务之前修改上下文。 * **好处：** 提供一种快速的、用户启动的方式来利用 `new_task` 功能进行分支探索或管理长会话，而无需等待 Cline 建议。 > [!NOTE] > > 有关使用 `/newtask` 斜杠命令的更多详细信息，请参阅[新任务命令](https://cat.mintlify.site/features/slash-commands/new-task.md)文档。 #### 默认行为（没有 `.clinerules`） 默认情况下，没有特定的 `.clinerules` 指示其行为： * **工具可用性：** `new_task` 工具存在，Cline *可以* 选择使用它。 * **上下文感知：** Cline *知道* 其上下文使用百分比。 * **无自动触发：** Cline **不会** *仅仅* 基于上下文使用达到特定百分比（如 50%）自动启动任务移交。使用 `new_task` 的决定来自 AI 模型基于整体任务进度和提示指令的推理。 * **基本上下文预加载：** 如果在没有定义 `` 块结构的特定规则的情况下使用 `new_task`，Cline 将尝试根据其当前理解预加载相关信息（例如，进度和下一步骤的基本摘要），但这可能不如规则驱动的方法全面。 #### `.clinerules` 的力量：启用自定义工作流 虽然核心功能默认存在，但当您将 `new_task` 和上下文感知与 `.clinerules` 中定义的自定义工作流结合时，真正的力量、自动化和自定义才会出现。这允许您精确控制 *何时* 和 *如何* Cline 管理上下文和任务连续性。 使用 `.clinerules` 与 `new_task` 的主要好处： * **自动化上下文管理：** 定义规则以在特定上下文百分比（例如，>50%，>70%）或令牌计数时自动触发移交，确保最佳性能并防止上下文丢失。 * **模型特定优化：** 根据不同 LLM 的已知阈值定制移交触发器（例如，对于已知在超过特定令牌计数后会降级的模型，更早触发）。 * **智能断点：** 在通过上下文阈值 *后*，通过规则指示 Cline 找到逻辑停止点（例如，完成函数或测试后），确保更清洁的移交。 * **结构化任务分解：** 使用计划模式定义子任务，然后使用 `.clinerules` 让 Cline 在完成每个子任务后通过 `new_task` 自动创建新任务，为 *下一个* 子任务预加载上下文。 * **自定义上下文打包：** 在 `.clinerules` 中强制规定 `` 块的确切结构和内容，以获得高度详细和一致的移交（见下面的示例）。 * **改进的内存持久性：** 使用 `new_task` 上下文块作为跨会话持久化信息的主要集成方式，可能替代或补充基于文件的内存系统。 * **工作流自动化：** 为特定场景定义规则，比如在开始特定类型的任务时总是预加载某些设置指令或项目样板。 #### 示例规则驱动的工作流：任务移交过程 一个常见的工作流，**由下面示例等特定 `.clinerules` 驱动**，涉及以下步骤： 1. **触发识别（基于规则）：** Cline 监控规则中定义的移交点（例如，上下文使用 > 50%，任务完成）。 2. **用户确认：** Cline 使用 `ask_followup_question` 建议创建新任务，通常显示规则定义的预期上下文。 ```xml 我已完成 [具体成就]，上下文使用率很高（XX%）。您希望我创建新任务以继续 [剩余工作]，预加载以下上下文吗？ ["是，创建新任务", "先修改上下文", "不，继续此会话"] ``` 3. **用户控制：** 您可以批准、拒绝或要求 Cline 在创建新任务之前修改上下文。 4. **上下文打包（`new_task` 工具）：** 如果批准，Cline 使用 `new_task`，根据 `.clinerules` 强制规定的结构打包上下文。 5. **新任务创建：** 当前任务结束，新会话立即开始，预加载指定的上下文。 #### 移交上下文块（规则定义的结构） 规则驱动移交的有效性在很大程度上取决于 `.clinerules` 如何定义 `` 块。全面的结构通常包括： * **`## 已完成工作`**：成就、修改/创建的文件、关键决策的详细列表。 * **`## 当前状态`**：项目状态、运行进程、关键文件状态。 * **`## 下一步骤`**：剩余任务的清晰、优先级列表、实施详细信息、已知挑战。 * **`## 参考信息`**：链接、代码片段、模式、用户偏好。 * **可操作的开始：** 立即下一步操作的清晰指示。 #### 潜在用例和工作流 `new_task` 与 `.clinerules` 结合的灵活性开启了许多可能性： * **主动上下文窗口管理：** 在特定百分比（例如，50%，70%）或令牌计数时自动触发移交以保持最佳性能。 * **智能断点：** 在通过上下文阈值 *后*，指示 Cline 找到逻辑停止点（例如，完成函数或测试后），确保更清洁的移交。 * **结构化任务分解：** 使用计划模式定义子任务，然后使用 `.clinerules` 让 Cline 在完成每个子任务后通过 `new_task` 自动创建新任务。 * **自动化会话摘要：** 配置 `` 块以始终包含前一个会话关键讨论点的摘要。 * **预加载样板/设置：** 开始与特定项目相关的新任务时预加载标准设置指令或文件模板。 * **"内存库"替代方案：** 使用 `new_task` 上下文块作为跨会话持久化信息的主要方式，可能替代基于文件的内存系统。 鼓励尝试 `.clinerules` 以发现最适合您需求的工作流！ #### 示例 `.clinerules`：任务移交策略指南 以下是一个专门针对使用 `new_task` 进行上下文窗口管理的示例 `.clinerules` 文件。**请记住，这只是一个特定策略；核心 `new_task` 工具可以与其他自定义规则一起以不同方式使用。** ````markdown # 您必须使用 `new_task` 工具：任务移交策略指南 **⚠️ 重要指令 - 您必须遵循这些指导原则 ⚠️** 本指南提供了有效分解复杂任务和实施任务之间平滑移交过程的**强制**指令。您**必须**遵循这些指导原则以确保连续性、上下文保存和高效的任务完成。 ## ⚠️ 上下文窗口监控 - 需要强制操作 ⚠️ 您**必须**监控环境详细信息中显示的上下文窗口使用情况。当使用超过可用上下文窗口的 50% 时，您**必须**使用 `new_task` 工具启动任务移交。 200K 上下文窗口使用超过 50% 的示例： \`\`\`text # 上下文窗口使用情况 105,000 / 200,000 令牌（53%） 模型：anthropic/claude-sonnet-4（200K 上下文窗口） \`\`\` **重要**：当您看到上下文窗口使用率达到或超过 50% 时，您必须： 1. 完成当前逻辑步骤 2. 使用 `ask_followup_question` 工具提供创建新任务 3. 如果批准，使用带有全面移交指令的 `new_task` 工具 ## 计划模式中的任务分解 - 必需流程 计划模式专门设计用于分析复杂任务并将其分解为可管理的子任务。在计划模式下，您**必须**： ### 1. 初始任务分析 - 必需 - **必须**首先彻底理解用户请求的完整范围 - **必须**识别任务的所有主要组件和依赖关系 - **必须**考虑潜在挑战、边缘情况和先决条件 ### 2. 战略任务分解 - 必需 - **必须**将整体任务分解为逻辑的、离散的子任务 - **必须**基于依赖关系优先处理子任务（必须首先完成什么） - **必须**针对可在单个会话中完成的子任务（15-30 分钟的工作） - **必须**考虑上下文切换有意义的自然断点 ### 3. 创建任务路线图 - 必需 - **必须**向用户呈现清晰的、编号的子任务列表 - **必须**解释子任务之间的依赖关系 - **必须**在可能的情况下为每个子任务提供时间估计 - **必须**在有帮助的情况下使用 Mermaid 图表可视化任务流程和依赖关系 \`\`\`mermaid graph TD A[主任务] --> B[子任务 1：设置] A --> C[子任务 2：核心实现] A --> D[子任务 3：测试] A --> E[子任务 4：文档] B --> C C --> D \`\`\` ### 4. 获得用户批准 - 必需 - **必须**要求用户对建议的任务分解给出反馈 - **必须**根据用户优先级或其他要求调整计划 - **必须**确认开始哪个子任务 - **必须**要求用户在准备实施时切换到行动模式 ## 任务实施和移交流程 - 强制程序 在行动模式下实施任务时，您**必须**遵循这些有效任务移交的指导原则： ### 1. 专注实施 - 必需 - **必须**专注于完全完成当前子任务 - **必须**通过注释和提交消息清楚地记录进度 - **必须**在逻辑完成点创建检查点 ### 2. 识别完成点 - 关键 您**必须**在以下情况下识别自然移交点： - 当前子任务完全完成 - 您已达到较大子任务中的逻辑停止点 - 实施时间超过预期且可以稍后继续 - 任务范围已超出原始计划 - **关键**：上下文窗口使用超过 50%（例如，200K 上下文窗口的 100,000+ 令牌） ### 3. 启动移交流程 - 强制操作 当您达到完成点时，您**必须**： 1. 总结到目前为止已完成的工作 2. 清楚地说明剩余的工作 3. **强制**：使用 `ask_followup_question` 工具提供创建新任务： \`\`\`xml 我已完成 [具体成就]。您希望我创建新任务以继续 [剩余工作]吗？ ["是，创建新任务", "不，在此会话中继续", "让我考虑一下"] \`\`\` ### 4. 创建带有上下文的新任务 - 必需操作 如果用户同意创建新任务，您**必须**使用带有全面移交指令的 `new_task` 工具： \`\`\`xml # 任务继续：[简要任务标题] ## 已完成工作 - [已完成项目的详细列表] - [包括修改/创建的特定文件] - [注意做出的任何重要决定] ## 当前状态 - [项目当前状态的描述] - [任何运行进程或环境设置] - [关键文件及其当前状态] ## 下一步骤 - [剩余任务的详细列表] - [要解决的具体实施细节] - [需要注意的任何已知挑战] ## 参考信息 - [相关文档的链接] - [要遵循的重要代码片段或模式] - [当前会话中注意到的任何用户偏好] 请通过[具体下一步操作]继续实施。 \`\`\` ### 5. 详细上下文转移 - 强制组件 创建新任务时，您**必须**始终包括： #### 项目上下文 - 必需 - **必须**包括项目的整体目标和目的 - **必须**包括关键架构决定和模式 - **必须**包括技术栈和依赖关系 #### 实施细节 - 必需 - **必须**列出当前会话中创建或修改的文件 - **必须**描述实施的特定函数、类或组件 - **必须**解释遵循的设计模式 - **必须**概述测试方法 #### 进度跟踪 - 必需 - **必须**提供已完成项目的检查表 - **必须**提供剩余项目的检查表 - **必须**注意遇到的任何阻滞或挑战 #### 用户偏好 - 必需 - **必须**注意用户提到的编码风格偏好 - **必须**记录用户要求的特定方法 - **必须**突出用户识别的优先区域 ## 有效移交的最佳实践 - 强制指导原则 ### 1. 保持连续性 - 必需 - **必须**在任务之间使用一致的术语 - **必须**引用以前的决定及其理由 - **必须**保持相同的架构方法，除非明确改变方向 ### 2. 保存上下文 - 必需 - **必须**在移交中包含相关代码片段 - **必须**总结前一个会话的关键讨论 - **必须**在适用时引用特定文件和行号 ### 3. 设置清晰的下一步操作 - 必需 - **必须**以清晰的、可操作的下一步开始移交 - **必须**优先处理剩余任务 - **必须**突出需要做出的任何决定 ### 4. 记录假设 - 必需 - **必须**清楚地说明实施期间做出的任何假设 - **必须**注意可能需要用户输入的区域 - **必须**识别潜在的替代方法 ### 5. 优化可恢复性 - 必需 - **必须**构建移交，以便下一个会话可以立即开始工作 - **必须**如果需要环境配置，包括设置指令 - **必须**在顶部提供快速总结以快速恢复上下文 ## 示例任务移交 ### 有效任务移交的示例 #1： \`\`\`xml # 任务继续：实施用户身份验证系统 ## 已完成工作 - 创建了基本的 Express.js 服务器结构 - 实施了 MongoDB 连接和用户模式 - 完成了带有密码哈希的用户注册端点 - 使用 Joi 添加了输入验证 - 为注册端点创建了初始测试套件 ## 当前状态 - 服务器在端口 3000 上成功运行 - MongoDB 连接已建立 - 注册端点（/api/users/register）完全功能 - 测试套件通过所有注册场景 ## 下一步骤 1. 实施登录端点（/api/users/login） - 使用 bcrypt 比较密码 - 成功登录后生成 JWT 令牌 - 为无效凭据添加适当的错误处理 2. 创建身份验证中间件 - 验证 JWT 令牌 - 提取用户信息 - 处理过期令牌 3. 添加需要身份验证的受保护路由 4. 实施密码重置功能 ## 参考信息 - JWT 密钥应存储在 .env 文件中 - 遵循 routes/users.js 中现有的错误处理模式 - 用户模式在 models/User.js 中定义 - 测试模式在 tests/auth.test.js 中建立 请遵循注册端点中建立的相同模式继续实施登录端点。 \`\`\` ### 无效任务移交的示例 #2： _（注意：原始规则中提供的示例显示"YOLO MODE Implementation"似乎不太像直接移交上下文块，更像是带有未来考虑的一般状态更新。真正无效的移交可能在'当前状态'或'下一步骤'中缺乏细节）。_ ## 何时使用任务移交 - 强制触发器 您**必须**在这些场景中启动任务移交： 1. **关键**：当上下文窗口使用超过 50%（例如，200K 上下文窗口的 100,000+ 令牌） 2. **长期项目**超出单个会话 3. **复杂实施**具有多个不同阶段 4. **当上下文窗口限制**接近时 5. **在更大项目中切换焦点区域**时 6. **当不同的专业知识**可能对任务的不同部分有益时 **⚠️ 最后提醒 - 关键指令 ⚠️** 您**必须**监控环境详细信息部分中的上下文窗口使用情况。当它超过 50%（例如，"105,000 / 200,000 令牌（53%）"）时，您**必须**主动使用 `ask_followup_question` 工具启动任务移交流程，然后使用 `new_task` 工具。您必须使用 `new_task` 工具。 通过严格遵循这些指导原则，您将确保任务之间的平滑转换，保持项目势头，并为在复杂的多会话项目上工作的用户提供最佳体验。 ```markdown ## 用户交互和工作流考虑 - **线性流程：** 目前，使用 `new_task` 创建线性序列。旧任务结束，新任务开始。旧任务历史仍可访问以进行回溯。 - **用户批准：** 您始终有控制权，批准移交并有机会修改 Cline 建议转发的上下文。 - **灵活性：** 核心 `new_task` 工具是一个灵活的构建块。尝试 `.clinerules` 以创建最适合您需求的工作流，无论是严格的上下文管理、任务分解还是其他创造性用途。 ``` ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.