1. 项目概述：从聊天助手到工程执行环境

如果你和我一样，深度使用 Cursor 进行日常开发，你可能会经历这样一个阶段：一开始，你惊叹于它强大的代码补全和对话能力，但用久了，尤其是在处理复杂、多步骤的软件工程任务时，会感到一丝“力不从心”。你需要在聊天窗口里反复解释上下文，手动拆分任务，来回切换不同的工作模式，整个过程更像是在“指挥”一个理解力很强但缺乏条理的助手，而不是在一个高效、结构化的工程环境中工作。

这正是 KS Cursor Orchestrator 要解决的问题。它不是一个简单的提示词合集，也不是一个独立的应用。你可以把它理解为一套完整的“操作系统”或“工作流引擎”，专门为 Cursor 这个“硬件”而设计。它的核心目标，是将 Cursor 从一个强大的聊天式 AI 助手，转变为一个 协调的、自主的软件工程执行环境 。

想象一下，你不再需要事无巨细地告诉 AI 每一步该怎么做。相反，你给它一个高层次的目标，比如“为这个用户模型添加一个带验证的注册 API 端点”。系统会自动接管后续流程：它会先探索你的代码库，理解现有的项目结构、依赖和模式；然后生成一个详细的、分步骤的实施计划；接着，它会根据计划，将不同的子任务（比如编写控制器逻辑、更新数据库模式、编写单元测试）委派给不同的“专家”子代理去执行；在执行过程中，系统会自动验证代码变更，运行测试，并在出现问题时进行迭代修复。整个过程是结构化的、可复用的，并且保留了完整的操作上下文。

这套系统围绕几个核心构件来组织工作： 规则 定义了全局的执行标准和原则； 命令 提供了可重复调用的工作流入口； 子代理 扮演了不同领域的专家角色； 钩子 在代理执行的生命周期中注入自动化行为； MCP 集成了外部工具和上下文； CLI 工作流 则确保了整个流程可以从命令行触发和自动化。这背后的哲学是“编排”，即通过清晰的规则和流程，让多个 AI 代理协同工作，完成单个代理难以胜任的复杂工程任务。

2. 核心组件深度解析与设计哲学

2.1 规则：定义工程执行的“宪法”

在 KS Cursor Orchestrator 中，规则是最高层级的指导原则。它们不是简单的“不要这样做”的禁令，而是一套完整的工程执行标准和操作惯例。这些规则被放置在 ~/.cursor/rules/ 目录下，以 .mdc 文件形式存在，会被 Cursor 自动加载并全局应用。

规则的核心作用是什么？ 我认为是建立“共享心智模型”。当你和一个 AI 代理协作时，最大的成本之一是上下文对齐。规则预先定义了大量共识，比如：

• 代码风格与质量 ：如何格式化代码、命名约定、错误处理模式。
• 执行流程 ：面对一个任务时，标准的处理步骤是什么（例如：先探索、再计划、后执行、最后验证）。
• 安全与边界 ：哪些操作是禁止的（如直接运行破坏性数据库命令），哪些文件不应被修改。
• 沟通协议 ：代理在输出代码、解释决策时应遵循怎样的结构。

一个具体的例子是 planning.mdc 规则。它可能强制要求代理在执行任何实质性代码修改前，必须先输出一个包含以下要素的书面计划：1) 任务分解；2) 受影响的文件清单；3) 潜在风险与回滚方案；4) 验证方法。这避免了 AI 一上来就“埋头苦干”，结果写了一堆不符合项目架构的代码。

注意 ：项目中的 user-rules/ 目录存放的是维护者个人 Cursor 设置中“User Rules”的公开镜像。这部分规则 不会 通过安装脚本自动应用，因为它们更具个人偏好性质。你需要手动将它们的内容复制到你 Cursor 设置的 Rules 页面。这是一个关键区别： ~/.cursor/rules/ 是系统级、项目导向的规则；而 Settings 中的 User Rules 更像是用户个人的工作习惯设置。

2.2 命令与子代理：模块化与专业分工

如果说规则是宪法，那么命令和子代理就是具体的“政府部门”和“专家团队”。

命令 位于 ~/.cursor/commands/ 目录，以 / 开头在 Cursor 聊天框中调用。它们是封装好的、可重复使用的工作流。例如，你可能有一个 /plan-feature 命令，它触发一整套流程：拉取最新代码、分析需求、生成技术设计文档。另一个 /debug-failing-test 命令则会自动定位测试失败的文件，运行相关测试集，分析日志，并提出修复建议。

命令的强大之处在于其 可组合性 和 一致性 。开发者不需要每次都用自然语言重新描述一套复杂流程，只需调用一个命令，就能获得结构化的输出和可预测的结果。

子代理 则更进一步，它们位于 ~/.cursor/agents/ 目录。你可以将它们理解为拥有特定专长的 AI 角色。系统内置或你可以自定义诸如：

• 架构师代理 ：擅长高层面设计、技术选型和模块划分。
• 前端专家代理 ：精通 React/Vue 组件、状态管理和 UI/UX 实现细节。
• 后端专家代理 ：专注于 API 设计、数据库优化和业务逻辑。
• 测试工程师代理 ：专门编写单元测试、集成测试和生成测试数据。
• 代码审查员代理 ：负责检查代码质量、发现潜在 bug 和安全漏洞。

当主协调代理（Orchestrator）处理一个复杂任务时，它会根据计划，将子任务“派发”给最合适的子代理。例如，主代理接到“开发一个登录页面”的任务，它会先派“架构师代理”确定技术栈和组件结构，然后让“前端专家代理”去实现组件，同时让“后端专家代理”准备认证 API，最后让“测试工程师代理”编写端到端测试。这种基于角色的分工，比让一个“通才”代理处理所有事情，通常能产生更专业、更可靠的输出。

2.3 钩子与 MCP：扩展系统能力边界

钩子和 MCP 是让这个系统变得灵活和强大的两个关键扩展机制。

钩子 类似于生命周期事件监听器。它们被定义在 ~/.cursor/hooks.json 配置文件中，并关联到 ~/.cursor/hooks/ 目录下的具体脚本。钩子允许你在代理执行的特定时间点注入自定义逻辑。常见的钩子类型包括：

• pre_command ：在某个命令执行前运行，可用于环境检查或资源准备。
• post_plan ：在生成计划后运行，可以自动将计划提交到项目管理工具（如 Jira）。
• pre_commit ：在代码变更被提交前运行，可以自动运行 linter 或格式化工具。
• on_error ：当代理执行过程中发生错误时触发，可以收集错误日志并发送通知。

例如，你可以设置一个 post_implementation 钩子，每当代理完成一段代码实现后，自动运行项目的测试套件，并将结果摘要反馈给聊天会话。这实现了“持续验证”，而不是等到最后才发现问题。

MCP 代表“模型上下文协议”，这是 Cursor 引入的一个革命性功能。简单说，它允许 Cursor 安全地连接并使用外部服务器提供的工具和数据源。KS Cursor Orchestrator 的 mcp/ 目录提供了配置示例。

通过 MCP，你可以将整个外部世界接入 Cursor：

• 数据库 MCP 服务器 ：允许 AI 安全地查询数据库 Schema 甚至样本数据（不直接执行写操作），从而更好地理解业务逻辑。
• 内部文档 MCP 服务器 ：连接公司的 Confluence、Notion 或 Wiki，让 AI 在编码时能参考最新的产品需求文档和设计规范。
• 监控/日志 MCP 服务器 ：在调试时，AI 可以直接查询生产环境的错误日志聚合平台（如 Sentry, Datadog）。
• 项目管理 MCP 服务器 ：连接 Jira 或 Linear，让 AI 能读取任务描述、更新状态、甚至关联代码提交。

MCP 打破了 AI 代理的“信息孤岛”，为其提供了执行复杂工程任务所必需的上下文和工具，是实现高度自治的关键。

2.4 CLI 工作流：通向自动化的最后一公里

所有这一切——规则、命令、代理、钩子——最终都可以通过 CLI 工作流 串联起来，实现真正的自动化。这是将交互式的 AI 辅助开发，转变为可脚本化、可集成到 CI/CD 管道中的关键一步。

项目鼓励创建可从终端执行的脚本或命令。例如，你可以有一个 scripts/orchestrate-feature.js ，它接受一个特性描述作为参数，然后：

1. 调用 Cursor 的 API（如果未来开放）或通过模拟交互，触发 /plan-feature 命令。
2. 解析生成的项目计划。
3. 按顺序协调不同的子代理执行计划中的各个部分。
4. 监听钩子事件，收集执行日志。
5. 最终输出一个包含所有代码变更、测试报告和部署说明的结果包。

虽然目前 Cursor 的完全自动化 API 还在发展中，但通过 CLI 工作流的设计理念，你可以提前构建出这样的框架。一旦底层支持到位，你的整个 KS Cursor Orchestrator 配置就能无缝升级为一个软件交付自动化平台。

3. 安装与配置实战指南

理解了核心组件后，我们来亲手搭建这个环境。KS Cursor Orchestrator 的安装流程设计得非常“元”——它本身就是一次对 AI 代理执行能力的演示。整个安装过程由 AI 代理主导完成。

3.1 标准安装流程详解

官方推荐的安装方法是“一键粘贴”。这行指令包含了安装指南的原始文件地址：

Install and configure KS Cursor Orchestrator by following the instructions here:
https://raw.githubusercontent.com/kscius/ks-cursor-orchestrator/main/docs/guide/installation.md

你应该在哪里执行它？ 打开 Cursor，新建或进入一个项目工作区，然后打开 Cursor Chat 面板（通常是侧边栏或底部面板）。将上面这整段文字粘贴到聊天输入框中，然后发送。

接下来会发生什么？ Cursor 的 AI 助手（通常是 Claude 或 GPT 模型）会读取这个链接。它会识别出这是一个安装指南，并请求获得文件系统和终端访问权限。你必须点击“允许”或“授权”。授权后，AI 助手会开始执行 installation.md 文件中的指令。

安装脚本做了什么？ 让我们深入看看 installation.md 这个“给 AI 看的剧本”通常包含什么（具体内容以仓库最新版为准）：

1. 定位 Cursor 配置目录 ：它会首先确定你的操作系统，找到 Cursor 的用户配置目录（ ~/.cursor/ 或 %USERPROFILE%\.cursor\ ）。
2. 备份现有配置 ：一个好的安装脚本会先备份你现有的 rules 、 commands 等目录，防止覆盖你的个人设置。
3. 克隆或复制文件 ：接着，它会从 KS Cursor Orchestrator 的仓库中，将 rules/ , commands/ , agents/ , hooks/ , skills/ 等目录的内容，复制到你的本地 ~/.cursor/ 目录下对应的位置。
4. 配置文件 ：它会设置 ~/.cursor/hooks.json 文件，将钩子脚本与事件关联起来。它可能还会提供一个 mcp.config.example.json 的模板，你需要根据注释手动配置成 mcp.json 。
5. 验证安装 ：最后，脚本会列出所有被创建或修改的文件路径，并可能运行一些简单的检查命令，比如 ls -la ~/.cursor/ ，来确认安装成功。

重要提示 ：安装过程 不会 覆盖 Cursor 内置的 ~/.cursor/skills-cursor/ 目录（这是 Cursor 官方技能存放处），也不会修改你在 Cursor 图形界面 Settings → Rules 中手动设置的“User Rules”。你的个人 MCP 密钥等敏感信息也需要单独配置。这种设计保证了系统配置的可扩展性，而不会破坏你已有的环境。

3.2 高级安装与自定义配置

基于本地仓库的安装 ：如果你打算贡献代码或深度自定义，可以先克隆仓库：

git clone https://github.com/kscius/ks-cursor-orchestrator.git
cd ks-cursor-orchestrator

然后在 Cursor 中打开这个克隆下来的仓库作为工作区。此时，在聊天框中你可以使用更简洁的指令： @docs/guide/installation.md 。AI 助手会直接读取工作区内的这个文件，而不是从网络下载，这确保了安装脚本与你看到的源码版本一致。

配置 MCP 集成 ：安装完成后， ~/.cursor/mcp/ 目录下会有一个 mcp.config.example.json 文件。这是配置 MCP 服务器的模板。要启用它，你需要：

1. 将其复制为 mcp.json ： cp mcp.config.example.json mcp.json 。
2. 编辑 mcp.json ，根据注释填写你要连接的 MCP 服务器信息。例如，如果你使用一个本地的“文件系统搜索” MCP 服务器，配置可能包含服务器命令路径和参数。
3. 重启 Cursor，以使 MCP 配置生效。在 Cursor 中，你应该能在聊天时看到新集成的工具可用。

同步与更新 ：KS Cursor Orchestrator 是一个活跃的项目。当仓库更新后，如何同步到本地？没有一键升级命令。你需要：

1. 如果你是通过克隆仓库安装的，进入该目录执行 git pull 。
2. 比较仓库中的文件与你 ~/.cursor/ 目录下的文件差异。项目提供了 docs/sync-checklist.md 作为参考，帮助你手动合并更新。 切记不要直接覆盖 ，因为你可能已经修改了本地配置。建议使用 diff 工具或手动检查重要文件（如 hooks.json 和规则文件）的变更。
3. 对于通过原始 URL 安装的用户，理论上需要重新执行一次安装指令。但同样，务必先备份你的 ~/.cursor 目录，因为新版本的安装脚本可能会覆盖你的自定义内容。

4. 构建你的第一个自动化工作流

安装配置好后，我们通过一个实际场景，来看看如何利用 KS Cursor Orchestrator 的各个组件，构建一个解决真实问题的自动化工作流。假设我们有一个常见的需求： 为现有项目添加一个新的 API 端点，并确保其质量 。

4.1 场景定义与任务触发

我们从一个相对模糊的需求开始。在 Cursor Chat 中，我们输入：

我需要为用户管理系统添加一个“重置密码”的API端点。请处理。

在传统的聊天模式下，AI 可能会直接开始编写代码。但在我们的编排系统下，全局规则（例如 require_planning.mdc ）会首先被触发。这条规则可能规定：“对于任何涉及创建或修改多个文件的特性开发请求，必须先生成一个审查计划。”

因此，AI 不会立即编码，而是会回复：“我将为您执行‘添加重置密码端点’的任务。根据工作流，首先需要启动探索与计划流程。我将调用 /plan-implementation 命令。”

你可能会看到 AI 自动“输入”了 /plan-implementation 命令并执行。这个命令封装了以下步骤：

1. 探索代码库 ：自动分析项目结构，定位现有的用户模型、认证控制器、路由文件、数据库迁移以及相关的测试文件。
2. 上下文收集 ：读取相关的配置文件（如 package.json , config/database.js ），理解项目使用的框架（比如 Express.js + Sequelize）、代码风格和现有的认证逻辑（如登录、注册是如何实现的）。
3. 生成结构化计划 ：基于探索结果，输出一份 Markdown 格式的计划书，内容可能包括：
   • 任务分解 ：
     • 1.1 在 routes/auth.js 中添加 POST /auth/reset-password-request 路由。
     • 1.2 创建 controllers/auth/resetPasswordController.js 。
     • 1.3 在 models/User.js 中可能需要添加 passwordResetToken 和 resetTokenExpires 字段。
     • 1.4 创建数据库迁移文件以添加上述字段。
     • 1.5 编写单元测试 tests/auth/resetPassword.test.js 。
     • 1.6 更新 API 文档 docs/api.md 。
   • 依赖与风险 ：需要 nodemailer 发送邮件，需要确保令牌生成是加密安全的。
   • 验证方法 ：运行现有测试套件，为新端点编写集成测试。

4.2 子代理协作与任务执行

计划生成后，主协调代理（Orchestrator）开始工作。它不会自己完成所有编码，而是根据计划中的任务项，将其分派给不同的子代理。

1. 派发给“后端专家代理” ：主代理将任务 1.1, 1.2, 1.3 打包，并附上项目上下文和计划，发送给“后端专家代理”。指令可能是：“基于附上的项目上下文和计划，请实现重置密码请求的 API 端点。重点包括：生成安全令牌、存储哈希值、发送邮件逻辑。请遵循项目的 ESLint 和代码风格。”

   • “后端专家代理”被激活，它专注于后端逻辑。它会先仔细阅读项目中的类似控制器（如 loginController.js ），模仿其错误处理、响应格式和日志记录模式，然后开始编写 resetPasswordController.js 。完成后，它会输出代码，并可能自动运行相关的 linter。

2. 派发给“数据库专家代理” ：同时，主代理将任务 1.4 派发给一个专注于数据库的子代理（可能由“后端专家代理”兼任，但角色更细分）。该代理会检查 User 模型的定义，然后生成一个 Sequelize 迁移文件，内容包含添加字段和创建索引。

3. 派发给“测试专家代理” ：当后端代码和迁移文件就绪后，主代理将任务 1.5 和“运行测试套件”的验证要求，派发给“测试专家代理”。这个代理会分析新写的控制器和路由，然后编写单元测试（模拟请求、测试令牌验证、测试过期逻辑等）和集成测试（模拟完整的 API 调用流程）。编写完成后，它会自动运行 npm test 或 jest ，并将测试结果报告给主代理。

在整个过程中， 钩子 在默默工作。例如：

• 一个 pre_commit 钩子可能在“后端专家代理”保存文件时自动触发，运行 prettier --write 来格式化代码。
• 一个 post_file_change 钩子可能监听 models/ 目录下的变化，当 User.js 被修改后，自动运行一个脚本，更新 TypeScript 类型定义文件（如果项目使用 TypeScript）。

4.3 验证、集成与收尾

所有子任务完成后，主协调代理会汇总结果。它会检查：

• 所有计划中的文件是否都已创建或修改。
• “测试专家代理”返回的测试报告是否全部通过。
• 是否有任何钩子报告了错误或警告。

然后，主代理可能会执行一个 /create-summary 命令（如果定义了的话），生成一份最终的工作报告，内容包括：

• 修改的文件列表及 diff 链接（如果集成了 Git）。
• 新增的 API 端点详情（方法、路径、请求/响应体示例）。
• 测试覆盖率变化。
• 后续步骤建议（如“需要配置邮件服务 SMTP 信息”）。

最后，AI 会将这份报告呈现给你，并询问：“重置密码 API 端点的实现已完成，所有测试通过。这是工作报告。您是否需要我协助您创建 Git 提交信息，或进行其他操作？”

至此，你通过一个简单的自然语言指令，触发了一个包含探索、计划、多专家协作、自动化测试和验证的完整软件工程流程。你从“微观管理者”变成了“目标制定者和验收者”，大部分结构化的执行工作都由编排系统自动完成。

5. 常见问题、排查与进阶技巧

在实际使用 KS Cursor Orchestrator 的过程中，你可能会遇到一些挑战。以下是我在深度使用和测试中积累的一些常见问题与解决方案，以及让系统发挥更大效能的进阶技巧。

5.1 安装与初始化问题

问题1：AI 助手没有执行安装指令，或者请求权限被拒绝。

• 排查 ：首先确认你是在 Cursor 的 Chat 界面中粘贴的指令，而不是在编辑器或终端里。确保你粘贴的是完整的、包含原始 URL 的文本块。
• 解决 ：如果 AI 没有主动请求权限，你可以尝试在发送安装指令后，手动在聊天框输入：“请按照该指南执行安装操作，你需要文件系统和终端权限。” 如果之前拒绝了权限，你可能需要重启 Cursor，或者在系统设置中清除 Cursor 的权限缓存。

问题2：安装后，在 Cursor 中看不到新的命令（如 /plan 没有自动补全）。

• 排查 ：检查 ~/.cursor/commands/ 目录下是否有 .mdc 文件。然后，检查 Cursor 的设置（Settings → Commands），查看“Custom Commands”部分是否加载了这些命令。有时需要重启 Cursor 才能识别新命令。
• 解决 ：确保命令文件的格式正确。一个基本的命令 .mdc 文件通常以 # 开头定义命令描述，然后是具体的指令内容。可以参考仓库中 commands/ 目录下的示例。

问题3：钩子（hooks）没有触发。

• 排查 ：首先检查 ~/.cursor/hooks.json 文件是否存在且格式正确（有效的 JSON）。确认其中定义的 script 路径指向的钩子脚本文件存在且具有可执行权限（在 Unix 系统上可能需要 chmod +x ）。
• 解决 ：钩子的调试比较困难。一个简单的测试方法是，在钩子脚本的第一行添加日志输出，比如 echo “Hook X triggered at $(date)” >> /tmp/cursor_hooks.log ，然后触发相关事件，查看日志文件是否生成。

5.2 工作流执行中的问题

问题4：子代理没有被调用，或者调用后行为不符合预期。

• 排查 ：子代理的定义在 ~/.cursor/agents/ 目录。确认主代理在计划中明确提到了要委派任务给某个命名的代理。检查该代理文件 .mdc 中的角色定义和指令是否清晰。有时，主代理可能因为上下文长度限制或指令模糊，而选择自己处理。
• 解决 ：在给主代理的指令或规则中，更明确地要求使用编排。例如，在规则中加入：“对于涉及多个技术领域的任务（如前端+后端+测试），必须使用 @architect_agent 进行任务分解，并委派给相应的 @frontend_agent , @backend_agent 。” 同时，确保子代理的指令文件开头有明确的角色声明，如 # Role: Senior Backend Engineer specializing in Node.js and API design 。

问题5：AI 生成的计划过于笼统或不符合项目实际。

• 解决 ：这是规则和上下文不足导致的。你需要“训练”系统。修改或增强 rules/ 目录下的规划相关规则。例如，在 planning_conventions.mdc 中，可以详细规定：“生成计划时，必须首先引用项目根目录下的 tech-stack.md 和 architecture-decisions.md 文件。计划必须包含数据库变更的 SQL 语句草案，以及需要修改的配置文件清单。” 此外，确保你的项目中有良好的文档（如 README.md , docs/ ），AI 在探索阶段能读到这些信息。

问题6：MCP 服务器连接失败或工具不可用。

• 排查 ：打开 Cursor 的设置，查看 MCP 配置部分，确认你的 mcp.json 配置已被加载且没有语法错误。检查 MCP 服务器本身是否正在运行（例如，运行 ps aux | grep your-mcp-server ）。
• 解决 ：MCP 服务器的配置是关键。确保 command 字段指向正确的可执行文件路径， args 和 env 变量配置正确。一个常见的技巧是，先手动在终端运行 MCP 服务器的启动命令，确保它能独立运行成功，再将其配置到 mcp.json 中。

5.3 性能优化与进阶技巧

技巧1：分层与模块化你的规则 不要把所有规则塞进一个巨大的 .mdc 文件。按领域分层：

• rules/core_principles.mdc ：定义最高层的哲学，如“安全第一”、“渐进式构建”。
• rules/language/javascript.mdc ：定义 JS/TS 特定规则。
• rules/frameworks/express.mdc ：定义 Express 框架下的最佳实践。
• rules/project_specific/your_project.mdc ：定义你当前项目的独特约定。 这种结构让规则管理更清晰，也方便在不同项目间复用通用规则层。

技巧2：创建项目专属的“启动器”命令 为你的每个主要项目创建一个专属的启动命令，比如 /project-alpha 。这个命令可以做：

• 切换到项目根目录。
• 加载项目特定的环境变量。
• 激活项目专属的规则集和代理配置。
• 输出当前项目状态摘要（当前分支、最近更改等）。 这能确保 AI 从一开始就处于正确的上下文中，极大提升后续交互的效率。

技巧3：利用钩子实现“质量门禁” 设置严格的 pre_commit 钩子，例如：

• 自动运行 eslint --fix 和 prettier 。
• 运行单元测试，如果失败则阻止提交并报告错误。
• 检查代码中是否有 TODO 或 FIXME 注释并提醒。
• 自动生成本次变更的简要描述，预填充到提交信息中。 这能将代码质量检查左移，在 AI 生成代码的阶段就确保符合标准。

技巧4：设计“复盘与学习”工作流 当一个人工审查员（也就是你）否决了 AI 的某个方案或修复了 AI 引入的 bug 后，不要浪费这个“教学时刻”。你可以创建一个 /log_correction 命令，记录下：

• 错误的代码片段。
• 你提供的正确方案或解释。
• 错误的原因分类（如“安全漏洞”、“性能问题”、“架构不符”）。 将这些记录存储在一个结构化的文件（如 knowledge/ai_corrections.json ）中。未来，你可以让 AI 在编写类似代码前，先查询这个“错题本”，从而避免重复犯错。这相当于为你的项目构建了一个持续学习的知识库。

技巧5：谨慎对待完全自动化 尽管 KS Cursor Orchestrator 的目标是高自治，但在当前阶段，我强烈建议将人类保持在循环中（Human-in-the-loop）。尤其是对于生产环境的部署、数据库迁移、密钥配置等关键操作，应该通过规则严格限制 AI 的自动执行权限，必须设置为“仅提供建议，等待人工确认”。你可以利用钩子在关键时刻弹出提示，或者要求 AI 必须生成一个需要人工审核和执行的脚本，而不是直接运行。平衡自动化与控制力，是现阶段用好这类工具的关键。