日常工作流

Plan 与 Act 模式

Plan 与 Act 把思考和动手分开：Plan 模式让你探索和谋划而不改文件，Act 模式按你的计划执行。

Plan 模式是你和 Cline 搞清楚「做什么、怎么做」的地方。在这个模式里，Cline 能读代码库、运行搜索和讨论策略，但不能修改任何文件或执行命令。这个限制是有意的：它让对话聚焦于理解和规划，不被实现细节分心，你可以自由探索、提问并反复推敲做法，再决定是否改动。用 Plan 模式：探索不熟悉的代码库；讨论架构决策与取舍；提前找出边界情况和潜在问题；形成清晰的实现策略；评审代码并理解复杂的工作流。

Act 模式：有了计划之后切到 Act。Cline 保留规划期间的完整上下文，现在可以修改文件、运行命令并执行你的策略。切换模式时对话历史会延续，Cline 记得你在 Plan 模式里讨论的一切。虽然可以直接从 Act 开始，但强烈建议先规划：规划阶段有意地构建 Cline 有效实现改动所需的上下文，没有它，Cline 可能缺乏做出正确决定所需的理解。

典型流程：从 Plan 模式开始描述想构建的东西；让 Cline 探索相关文件并理解代码库；讨论做法，考虑边界情况和潜在问题；对计划有把握后切到 Act；Cline 基于规划会话实现方案。复杂项目可以多次在两种模式间循环：遇到意外的复杂度或需要重新思考做法时，回到 Plan，再切回 Act 继续。

为两种模式配不同的模型：你可以给 Plan 和 Act 配置单独的模型，用更强的推理模型做规划，用更快的模型做实现。做法：打开 Cline 设置，启用「Use different models for Plan and Act」，为每个模式选模型；启用后，切换模式会自动切到为该模式配置的模型。官方给的配置例子有：成本优化、最高质量（规划用更强的模型、执行用较快的模型）、速度优先等，具体模型名随时间变化，以官方为准。

/deep-planning：对需要彻底分析的复杂任务，用这个斜杠命令触发一次扩展的规划会话：系统地探索代码库；找出所有受影响的文件和依赖；创建详细的实现计划；在继续之前提出澄清问题。深度规划的提示词针对每个模型系列优化，所以会适应你所用模型的长处。

按任务大小选择做法：小任务（改错别字、加缺失的 import、更新配置值、重命名变量）只用 Act，规划是多余的开销；中等任务（加新 API 端点、实现 UI 组件、需要调查的 bug、重构单个模块）用 Plan → Act；大任务（跨前后端的新功能、大范围重构、实现新系统或集成、多步迁移）用 /deep-planning，它创建 Cline 在整个工作中可参考的详细实现计划。

提示：让 Cline 写一个总结计划的 markdown 文件供以后参考；规划时用文件提及把 Cline 指向相关文件；遇到意外复杂度时切回 Plan，而不是硬推；在 Act 之前启用检查点，需要时能回滚；对大任务，让 Cline 在规划时创建待办清单，在 Act 里跟踪。

添加上下文

Cline 在有「对的」上下文（而不只是更多上下文）时效果最好。@ 提及让你拉进对任务重要的文件和文件夹，无需复制粘贴。添加上下文有两种方式：在聊天输入框里输入 @ 并选择文件或文件夹；点左下角的 + 按钮浏览文件或图片。

其他上下文（git 历史、网页、终端错误）直接描述即可，Cline 会自己运行 git log、获取 URL 或读取输出。

• 文件提及：用 @/path/to/file 引用任何文件，Cline 看到完整的文件内容，包括导入、相关函数和周围上下文，例如「Can you refactor the error handling in @/src/api/users.ts?」。
• 文件夹提及：用 @/path/to/folder/（注意末尾斜杠）引用整个目录，Cline 看到文件夹结构和所有文件内容。多根工作区里，路径要加工作区名前缀：@workspace-name:/path/to/file。
• 拖放：把文件直接拖进聊天输入框加入对话（VS Code 里拖动时按住 Shift）；拖动工作区文件会自动创建文件提及，也可以从 Finder 或文件资源管理器直接拖进 Cline。支持工作区里的文本文件，以及你文件系统里的图片、PDF、CSV 和 Excel 文件；图片需要多模态模型。

右键上下文菜单：在选中的代码上右键即可不打字就访问 Cline，它自动包含选中的文本及其文件位置作为上下文。编辑器里有 Add to Cline（就特定代码提问、获得建议或开始对话）、Fix with Cline（快速修复选中代码里的错误或问题，也出现在光标位于错误或警告处的灯泡快速修复菜单里）、Explain with Cline（理解不熟悉的代码、复杂逻辑或你正在评审的代码）、Improve with Cline（重构建议、性能改进或更干净的实现）。在终端里右键「Add to Cline」可以就构建错误、测试失败和堆栈跟踪、配置问题或任何你需要解读的终端输出求助。在源代码管理面板里，用「Generate Commit Message」根据暂存的改动生成 AI 提交信息，Cline 分析 diff 并按约定式提交的模式写出描述性的提交信息。

斜杠命令

在聊天输入框里输入 / 查看可用的斜杠命令：

• /newtask 像开发者交接：把重要的东西（总体计划、已完成的工作、相关文件、下一步）打包成一个上下文窗口干净的新任务，留下工具调用和实现细节的噪音。做复杂实现时用：比如十步流程完成了三步、上下文已经满了 75%，就用它提取关键决定、文件改动和进度，而不带噪音。
• /smol（或别名 /compact）压缩你的对话历史并保留关键上下文；与创建新任务的 /newtask 不同，它把当前对话浓缩成完整摘要，释放上下文窗口空间，让你在同一个任务里继续。深入调试或头脑风暴、需要继续同一任务又不想丢掉已得到的洞见时用。
• /newrule 创建教 Cline 你偏好的规则文件：Cline 引导你设置沟通风格、编码规范、项目上下文和可复用实践的准则，规则保存到你的 .clinerules 目录并在以后的对话里自动加载。当你发现自己在不同任务里重复同样的指令时用。
• /deep-planning 把 Cline 变成一丝不苟的架构师：在写任何代码之前，调查你的代码库、提出澄清问题并创建全面的实现计划。分四步：静默调查（探索代码库结构和模式）、讨论（针对需求和做法的有针对性的问题）、创建计划（生成含详细规格的 implementation_plan.md）、创建任务（创建带可跟踪实现步骤的新任务）。用于涉及代码库多个部分的功能、架构变更或复杂集成。
• /reportbug 收集诊断信息并帮你报告 Cline 的问题：收集你的配置、最近的错误和系统详情，使 bug 报告对开发团队更有用。

通过斜杠命令触发技能：除内置命令外，你还可以用斜杠命令从聊天里直接触发已启用的技能：输入 / 打开命令建议，选一个技能命令（如 /aws-deploy），Cline 加载该技能并把它的 SKILL.md 指令应用于任务。任何已启用的技能都可以这样触发，让你无需重写同样的指令就走到技能特定的指导。

检查点

检查点让你撤销代码改动而不丢失对话。每次 Cline 修改文件或运行命令，它都会保存项目文件的快照；你可以恢复到任何检查点，保留你建立的上下文而回退代码。这改变了你的工作方式：与其在批准之前小心评审每个改动，你可以让 Cline 快速推进，出问题时再回滚，犯错的成本降到几乎为零。检查点默认启用。

工作原理：Cline 维护一个与你项目真正 Git 历史分开的影子 Git 仓库。每次工具使用（文件编辑、命令等）之后，Cline 把你文件的当前状态提交到这个影子仓库，你的主 Git 仓库保持不变。这意味着：你的 Git 历史保持干净并由你掌控；检查点捕获一切，包括 Git 不跟踪的文件；你可以恢复到任务里的任何一点而不影响你已做的提交；检查点跨编辑器会话持久。每个检查点捕获该时刻完整的文件状态；Cline 依次编辑三个文件，就有三个检查点，可以独立恢复到其中任何一个。

启用或禁用：默认启用；要切换，打开 Cline 设置（Cline 侧边栏里的齿轮图标），滚动到「Feature Settings」部分，切换「Enable Checkpoints」。对非常大的仓库，检查点可能占用大量存储，并在每次工具使用后提交文件快照时拖慢 Cline；注意到性能问题时考虑禁用它们。

查看和比较改动：每次工具使用之后，对话里出现检查点指示器：一个标着「Checkpoint」的书签图标，用虚线连到 Compare 和 Restore 按钮。点 Compare 打开 diff 视图，显示该检查点具体改了什么（在你编辑器的 diff 查看器里打开，能看到所有受影响文件的新增、删除和修改）。

恢复检查点：点任一步骤旁的 Restore 打开恢复菜单，有三个选项：

怎么选取决于哪里出了问题：对话富有成效但代码改动弄坏了东西，用 Restore Files，Cline 保留你们讨论过的所有上下文并能尝试不同的实现；Cline 的代码改动很好但对话跑偏了，用 Restore Task Only，保留文件并以不同方式引导对话；想从干净的状态重新开始，用 Restore Files & Task，把文件和对话都重置到该检查点。典型用法：Cline 重构代码并弄坏了东西，Restore Files 后要求不同的做法；尝试多种解法，Compare 每个检查点并恢复到最好的；Cline 误解了你的意图，Restore Files & Task 后重新措辞；想试不同的提示，Restore Task Only 后重新提交；提交到 Git 之前评审改动，用 Compare 检查然后手动提交；测试有风险的改动，让 Cline 继续，失败就恢复。

配合自动批准：检查点让自动批准变得可行：没有检查点，自动批准感觉有风险，因为 Cline 可能在你注意到问题之前做了许多改动；有了检查点，你可以让 Cline 自主工作，需要时回滚。典型流程：为文件编辑和命令启用自动批准；让 Cline 快速完成你的任务；评审最终结果；有问题就恢复到最后一个良好的检查点；给 Cline 更具体的指导。检查点与消息编辑：消息编辑功能与检查点集成：当你编辑之前的消息并选择「Restore All」时，Cline 在重新提交你编辑后的消息之前，先把文件恢复到那一刻的检查点，所以你可以一步修正措辞不佳的提示并撤销由它导致的所有改动。

自动批准与 YOLO 模式

自动批准让你决定 Cline 能在不每次询问你的情况下做哪些动作，使你在例行工作中不被批准弹窗打扰，同时对高风险动作保持严格控制。它按工具调用评估：Cline 即将读文件、编辑文件、运行命令或使用浏览器时，检查你对该类别的自动批准设置。要点：

• 工作区内与工作区外：「Read all files」和「Edit all files」只是扩展基础开关；基础开关关闭时，「all files」选项不起作用。
• 终端命令：Cline 把命令视为安全的或需要批准的；「Execute safe commands」覆盖安全命令，「Execute all commands」扩展到被标记为需要批准的命令。
• 通知：启用后，需要批准时、以及自动批准的终端命令运行 30 秒时，Cline 发送操作系统级通知。

安全命令与需批准命令：Cline 不使用固定的允许列表：模型根据命令及其参数给每个命令标上 requires_approval 标志。以下是例子而非保证：通常视为安全的有 npm run build、npm test（构建/测试输出）和 git status、ls -la、cat package.json（只读命令）；通常需要批准的有 npm install <pkg>（修改依赖）、rm -rf <path>（删除文件）、mv <a> <b>（移动文件，可能覆盖）和 sed -i ...（原地编辑文件）。建议：一个好的默认设置是启用 Read project files，在你有具体理由之前让编辑、命令、浏览器和 MCP 保持关闭；如果启用编辑，要用检查点以便快速回滚。

YOLO 模式是加强版自动批准：勾选后，Cline 自动批准一切：文件改动、终端命令、浏览器动作、MCP 工具和模式转换（Plan 到 Act）。注意：这很危险，YOLO 模式禁用所有安全检查，Cline 执行它决定的任何事而不征求许可。启用时，系统上任何地方的所有文件操作、包括可能具破坏性的所有终端命令、浏览器动作、MCP 服务器工具和模式转换都被自动批准。适合：快速原型（你想要零摩擦、不在乎潜在错误，非常适合一次性实验）；受信任的重复任务（你已验证过 Cline 的做法、想消除批准开销）；演示（想不被打断地展示 Cline 的能力）。可能出错的地方：Cline 可能不警告就删除重要文件；执行修改系统设置的命令；向外部服务发起网络请求；覆盖配置文件；安装或卸载包；向版本控制提交并推送改动。最佳实践：先在隔离环境里用（一次性项目或沙盒环境）；请求要具体（含糊的指令加无限的权限等于不可预测的结果）；监控输出（Cline 仍然显示它在做什么，留意终端和文件改动）；保持版本控制就手（Git 成为你的安全网）。启用方式：进入 Cline 设置，再到 Features，勾选「YOLO Mode」，没有确认对话框，启用后 Cline 立即自动批准所有动作；取消勾选即禁用。

子智能体

子智能体让 Cline 派生并行运行的聚焦研究智能体：每个子智能体有自己的提示词和上下文窗口，独立探索代码库，并向主智能体返回详细报告。这让主智能体的上下文保持干净，同时快速收集广泛的信息。这是实验性功能，行为可能在未来版本里改变。

当 Cline 使用 use_subagents 工具时，它同时启动独立的智能体。每个：获得描述要调查什么的自己的提示词；以单独的上下文窗口和 token 预算运行；可以读文件、搜索代码、列目录、运行只读命令和使用技能；不能编辑文件、使用浏览器、访问 MCP 服务器或派生嵌套的子智能体；返回聚焦于最相关文件路径的结果，供主智能体下一步阅读。子智能体的成本（token 和 API 花费）按子智能体分别跟踪并计入任务总成本，运行时可以在聊天界面看到每个子智能体的统计（工具调用、token、成本）。

子智能体默认启用：Cline 判断并行研究何时值得开销，你无需选择加入或在提示里点名。要关闭，在 Settings → Features → Agent 里禁用 use_subagents 工具；该设置适用于所有编辑器（VS Code、JetBrains、CLI）。子智能体启用时，Cline 在任务受益于并行探索时自行使用它们，你也可以在提示里明确要求并行研究，例如「Use subagents to explore how authentication works and where the database models are defined」。每个子智能体的提示应描述一个聚焦的研究问题，Cline 并行运行它们并综合结果；任务够小、并行发现是多余开销时，也可以只运行一个子智能体。

子智能体遵循 Read project files 自动批准权限：如果你在自动批准里启用了它，子智能体的启动会被自动批准；自动批准关闭时，Cline 在启动子智能体前征求你的批准，并向你展示它打算发送的提示。子智能体是只读的研究智能体，可用的工具：read_file（读文件内容）、list_files（列目录内容）、search_files（跨文件的正则搜索）、list_code_definition_names（列出顶层类、函数和方法）、execute_command（运行 ls、grep、git log、git diff 这类只读命令）和 use_skill（加载并激活技能）。它们不能写文件、应用补丁、使用浏览器、访问 MCP 服务器或做网页搜索，也不能派生自己的子智能体。子智能体运行的命令在后台执行并限于只读操作，不会运行修改文件或系统状态的命令。适合在需要同时从代码库多个区域获得广泛上下文时使用：上手不熟悉的项目（并行映射架构、关键入口和数据流）；调查横切关注点（让不同的子智能体同时追踪认证、日志和错误处理）；编辑前的研究（改动之前从相关文件收集上下文）；大型代码库（依次读许多文件会耗尽主智能体的上下文时）。对你已经知道看哪些文件的小而聚焦的任务，子智能体只是多余的开销，直接问 Cline 就行。

智能体团队

注意：这个功能目前只适用于 Cline SDK、CLI 和 Kanban，暂不适用于 VS Code 和 JetBrains 扩展。智能体团队让你把复杂工作拆给多个通过共享任务板协调的智能体：一个智能体充当协调者，把子任务委派给专家智能体。

cline --team-name auth-sprint "Plan and implement user authentication with tests"

--team-name 标志启用团队模式，协调者智能体获得用于派生队友和委派任务的额外工具。团队状态跨会话持久，可以从中断处继续：cline --team-name auth-sprint "Continue with incomplete tasks"。在交互模式里用 /team 斜杠命令，例如 /team Plan and implement a REST API with tests。团队状态存储在 ~/.cline/data/teams/[team-name]/，包括带当前任务和状态的任务板、智能体间的邮箱和带活动历史的任务日志。团队默认启用，用 cline --no-teams "your prompt" 禁用。对单个会话内更简单的委派（无持久状态），用上面的子智能体，它们并行运行只读研究并向主智能体返回聚焦的报告；编程接口见 SDK 的多智能体团队指南。

Memory Bank

Memory Bank 是一种文档方法，把 Cline 从无状态的助手变成持久的开发伙伴：通过结构化的 markdown 文件，Cline 能跨会话「记住」你的项目细节。快速设置：复制下面的自定义指令；把它们加到 Cline 规则文件里，如 .clinerules/memory-bank.md；让 Cline「initialize memory bank」。

Memory Bank 文件是你项目里普通的 markdown 文件，你和 Cline 都能访问，按层级组织，构建项目的完整图景：

memory-bank/
├── projectbrief.md      # 基础文档
├── productContext.md    # 项目为什么存在
├── activeContext.md     # 当前工作重点
├── systemPatterns.md    # 架构与模式
├── techContext.md       # 技术栈与设置
└── progress.md          # 状态与里程碑

关键命令：「follow your custom instructions」让 Cline 读取 Memory Bank 并从你离开的地方继续；「initialize memory bank」为新项目创建初始结构；「update memory bank」触发完整的文档评审与更新。它们与 Cline 内置的斜杠命令并用，尤其是 /newtask 和 /smol 帮你管理上下文窗口而不丢进度。

管理上下文窗口：每个 AI 模型都有限制一次能处理多少信息的上下文窗口。工作时，这个窗口被对话历史、文件内容和工具结果填满；Memory Bank 帮你在需要腾出空间时保存重要知识。手动做法：上下文窗口快满时，让 Cline「update memory bank」记录当前状态；开始新对话；让 Cline「follow your custom instructions」。这在窗口清空之前把重要上下文保存进 Memory Bank 文件，让你在全新的对话里无缝继续。

最佳实践：从基本的项目简介开始，让结构自己演化；让 Cline 帮助创建初始结构；activeContext.md 变化最频繁，每次会话后更新它；progress.md 跟踪里程碑，恢复工作时评审它；在重大里程碑或方向变化之后更新；用 Cline 规则按项目存储 Memory Bank 指令。

常见问题：自定义指令还是 Cline 规则？两者皆可：自定义指令在所有项目全局适用，Cline 规则文件是项目特定的、存放在你的仓库里，便于与协作者共享；你也可以用条件规则，只在处理 memory-bank/ 文件时才激活 Memory Bank 指令。更新频率？在重大里程碑或方向变化之后；活跃开发时每隔几个会话；你也可以让自动压缩处理例行的上下文管理，把手动的「update memory bank」留给重要的检查点。它能与其他 AI 工具一起用吗？可以，Memory Bank 是适用于任何能读文档的 AI 的文档方法，命令可能不同但做法通用。与 README 有何不同？Memory Bank 提供为 AI 上下文管理设计的结构化、全面的文档，超出单个 README 能涵盖的内容，包括像活跃上下文和进度跟踪这样经常变化的文件。

官方还给出了完整的 Memory Bank 自定义指令（一段以「I am Cline, an expert software engineer with a unique characteristic: my memory resets completely between sessions」开头的规则文本），其要点是：每个任务开始时必须读取所有 Memory Bank 文件；核心文件按上表的层级相互构建，可在 memory-bank/ 下按需添加复杂功能文档、集成规格、API 文档、测试策略和部署流程；在发现新的项目模式、实现重大改动之后、用户要求「update memory bank」（必须评审所有文件）或需要澄清上下文时更新。完整文本见官方 Memory Bank 页。