当您需要工作流程时，请停止添加规则

你发现了 /pr-review.md，现在，一个命令就可以处理你整个 PR 审查过程——收集上下文，分析更改，请求确认，并执行批准。过去需要 15 分钟手动操作的工作，现在只需一个斜杠命令即可完成。

但是大多数开发人员仍然在手动执行重复性任务，或者在应该构建工作流时，用规则文件来混淆他们的上下文。这不仅仅是语义上的区别；它关乎架构，理解它将彻底改变你使用 Cline 的方式。

工作流到底是什么

工作流是针对多步骤流程的按需自动化。当你输入 /pr-review.md时，Cline 会将该工作流的内容包装在 <explicit_instructions> 标签中，并将其注入到该特定消息中。工作流执行一次，完成其序列，然后消失。

这与 clinerules 有根本不同，后者会附加到你的系统提示词中并影响每次交互。工作流是程序性的（“现在执行这个过程”），而 clinerules 是行为性的（“始终以这种方式行事”）。

技术上的区别很重要。工作流只在被调用时消耗 token。Clinerules 在每条消息中都会消耗 token，因为它们是持久系统上下文的一部分。选择错误，要么为你未使用的上下文付费，要么手动重复本应自动化的过程。

决策框架

当你能将某事描述为“首先我做 X，然后 Y，然后 Z”时，就构建一个工作流。PR 审查工作流完美地体现了这一点。

首先，它使用 gh pr view 和 gh pr diff 收集 PR 信息。然后它使用 read_file 和 search_files 检查原始文件以理解上下文。接下来，它分析更改以查找质量问题和潜在错误。最后，它请求确认并使用适当的 gh pr review 命令执行批准。

这个序列涉及多个工具——GitHub CLI、Cline 的内置文件操作以及通过 ask_followup_question 进行的用户交互。这是一个完整的流程，会产生一个特定的结果：一个经过审查和批准（或拒绝）的 PR。

当你希望所有任务都保持一致行为时，请使用 clinerules。编码标准、架构约束和项目特定上下文属于 clinerules，因为它们应该影响每次交互。关于“始终使用 TypeScript 严格模式”的规则应该影响所有代码生成，而不是只在你记得调用它时才影响。

实际工作流示例

自我改进的 Cline 工作流 展示了另一种模式。它会反思已完成的任务，并根据用户反馈对你活跃的 clinerules 提出改进建议。这种元工作流只有作为按需流程才有意义——你不会希望 Cline 不断地分析和提出规则更改。

考虑一个由 /deploy-staging.md 触发的部署工作流。首先，它运行 npm test 来验证代码。然后它使用 npm run build 构建应用程序。接下来，它使用 docker deploy 部署到 staging 环境，并使用 curl /health 运行健康检查。最后，它通过 Slack MCP 服务器通知团队，并在继续生产部署之前请求用户批准。

这个序列展示了工作流的强大功能：将多个工具（CLI 命令、文件操作、MCP 服务器、用户交互）编排成一个命令。过去可能需要 20 分钟手动操作的相同流程，现在变成了一次性自动化，同时在关键决策点保持了人工监督。

内容生成工作流在重复性发布任务中大放异彩。一个博客工作流可以收集研究资料、构建论点、撰写草稿并格式化以便发布。数据库迁移工作流可以运行迁移、检查冲突、更新文档，并通知团队架构更改。

部署工作流编排复杂的发布过程。它们可以运行测试、构建 artifact、更新版本号、创建发布说明并部署到 staging 环境。这些序列涉及多个 CLI 工具和外部服务，使其成为理想的工作流候选者。

如何创建和调用工作流

通过 Cline 界面的“工作流”选项卡访问工作流。你会看到全局工作流（存储在 ~/Documents/Cline/Workflows）和工作区工作流（存储在 .clinerules/workflows/）。每个工作流都有一个切换开关来启用或禁用它，以及编辑和删除选项。

要创建新的工作流，请单击“新建工作流文件...”。这会打开一个 markdown 文件，你可以在其中定义你的流程。或者，你可以直接在 .clinerules/workflows/ 目录中创建文件。

全局工作流适用于你的所有项目，而工作区工作流是项目特定的。当两者存在同名时，本地工作流优先，允许对全局流程进行项目特定的定制。

构建你的第一个工作流

刚完成一个需要重复的任务？让 Cline 为你创建一个工作流。只需说“Cline，为我刚才完成的过程创建一个工作流”，它将分析对话，确定步骤，并生成一个结构正确的工作流文件。

如果你需要更多指导，实际上有一个用于创建工作流的工作流。它会引导你定义目的、目标、主要步骤和详细子步骤，然后生成结构正确的工作流文件。像这样的元工作流展示了系统的递归能力。

工作流结构使用 <task_objective> 来定义目标，并使用 <detailed_sequence_of_steps> 来概述过程。Cline 可以引用其内置工具，例如 read_file、search_files 和 ask_followup_question，你已安装的 CLI 工具，以及用于外部集成的 MCP 服务器调用。

通过在聊天中输入 /create-new-workflow.md 来调用任何工作流。文件名即成为命令。在将其用于关键工作之前，先在小示例上测试你的工作流。工作流通过迭代改进——从简单开始，根据需要增加复杂性。

工作流擅长的场景

工作流在涉及多个工具和决策点的流程中表现出色。PR 审查工作流结合了 GitHub CLI 命令、文件分析和人工确认。部署工作流可能编排 Docker 构建、环境更新和健康检查。

对于需要在行动之前收集上下文的流程，它们尤其强大。研究工作流可以查询多个来源、综合信息并生成结构化输出。测试工作流可以运行测试套件、分析结果并生成报告。

工作流还擅长标准化团队流程。与其将流程文档化在过时的维基中，不如将其编码为可执行的工作流。新团队成员可以运行与经验丰富的开发人员相同的流程，确保一致性并减少入职时间。

入门

提示词仓库 包含了你可以调整的工作流示例。PR 审查工作流提供了涉及外部工具和用户确认的流程模板。自我改进工作流展示了如何创建增强你的 Cline 设置的元流程。

你最繁琐的重复性任务可能是你最好的第一个工作流候选者。将那个重复的序列变成一个命令，并发现当你的 AI 助手真正自动化你的工作而不仅仅是协助时是什么感觉。

准备好构建真正有效的工作流了吗？在我们的Reddit 和Discord社区分享你的创造和发现。最好的工作流源于实际问题，你独特的挑战可能会激发其他人需要的解决方案。

-Nick