Roo Code 模式Modes实战指南从内置模式到自定义团队工作流【免费下载链接】Roo-CodeRoo Code gives you a whole dev team of AI agents in your code editor.项目地址: https://gitcode.com/GitHub_Trending/ro/Roo-Code这篇技术指南围绕 Roo Code 的模式Modes体系展开带你理解 Code、Architect、Ask、Debug 等内置模式的职责边界与工具权限划分并深入介绍如何通过customModes全局配置或项目级.roomodes文件创建、导入、导出专属自定义模式把 AI 助手塑造成贴合团队规范与个人工作流的专属开发团队成员。读完本文你将掌握 Roo Code 模式体系的完整骨架、配置语法与源码级运行原理能够直接在你的编辑器中落地一套可复用的多角色协作方案。为什么说 Roo Code 是编辑器里的 AI 开发团队Roo Code 的定位可以用一句话概括你的 AI 驱动开发团队就在编辑器里Your AI-Powered Dev Team, Right in Your Editor见 根目录 README。它不是一个只会生成代码的单点助手而是一个能覆盖完整研发链路的多角色协作系统——从需求规划、编码实现、代码提问到故障排查每个环节都有专门的角色负责。围绕这一核心定位Roo Code 能为你做的事情包括从自然语言描述中生成代码通过模式Modes适配不同工作场景Code、Architect、Ask、Debug 以及自定义模式重构与调试已有代码编写与更新文档回答代码库相关问题自动化重复性任务接入 MCP 服务器扩展第三方工具与数据源能力。其中模式Modes是 Roo Code 区别于普通 AI 编码助手的关键设计它让 AI 适应你的工作方式而不是反过来。本指南将围绕这一核心主题展开结合仓库源码packages/types/src/mode.ts、src/shared/modes.ts、src/shared/tools.ts、src/core/config/CustomModesManager.ts逐层拆解其机制。内置模式全景每个角色负责什么Roo Code 开箱即用地提供了五个内置模式它们的默认配置定义在packages/types/src/mode.ts的DEFAULT_MODES常量中约 第 168-227 行并通过 src/shared/modes.ts 导出供全仓库使用。下表整理了各模式的核心职责、适用场景与默认工具组模式名称核心职责roleDefinition 摘要适用场景默认工具组architectArchitect经验丰富的技术负责人负责收集信息、制定详细计划实现前先规划、拆解复杂问题、编写技术规格、设计系统架构readedit仅 MarkdownmcpcodeCode精通多语言/框架/设计模式的高技能软件工程师编写、修改、重构代码实现功能、修复缺陷、创建文件readeditcommandmcpaskAsk知识型技术助手专注回答问题与提供信息解释概念、分析已有代码、获取建议、学习技术不修改代码readmcpdebugDebug专家级软件调试员系统化诊断与解决问题排查故障、分析错误、添加日志、定位根因readeditcommandmcporchestratorOrchestrator战略级工作流编排者将复杂任务委派给合适的专业模式跨领域的多步骤项目、任务拆解、工作流协调无固定组主要通过new_task委派内置模式的职责定义与工具边界从源码可以看到每个模式由slug唯一标识、name显示名、roleDefinition角色定义、whenToUse何时使用、description简介、groups工具组和可选的customInstructions自定义指令组成。以下逐个剖析关键设计Architect规划者角色定义经验丰富的技术领导者好奇心强且善于规划目标是通过信息收集获取上下文制定详细计划供用户审阅批准后再切换到其他模式实施packages/types/src/mode.ts。关键约束它的edit组通过fileRegex: \\.md$限制了只能编辑 Markdown 文件这意味着规划模式在结构上就无法直接改动业务代码只能产出.md计划文档——从工具权限层面强制了规划与实施分离。内置指令要求它使用update_todo_list工具创建可执行的任务清单并在规划完成后用switch_mode请求切换到实施模式还特别约定Mermaid 图中避免在方括号内使用双引号和括号以防解析错误。Code实施者角色定义Roo一名在众多编程语言、框架、设计模式和最佳实践方面拥有丰富知识的高技能软件工程师。工具组最全read读文件/搜索、edit改动代码、command执行命令、mcp调用外部工具是日常编码的主战场。Ask问答者角色定义知识型技术助手专注于回答软件开发生态相关问题。工具组只有readmcp没有edit和command因此它天然无法改动文件或执行命令只负责解释、分析和输出文档化答案内置指令还明确除非用户明确要求否则不要转向实现代码。Debug排障者角色定义专家级软件调试员专注于系统化的问题诊断与解决。工具组与 Code 相同readeditcommandmcp但内置指令引导了不同的工作流先反思 5-7 种可能的问题来源收敛到 1-2 个最可能的根因添加日志验证假设并在修复前明确请用户确认诊断。Orchestrator编排者角色定义战略级工作流编排者通过把复杂任务委派给合适的专业模式来协调。它的groups为空数组这意味着它不直接操作文件而是依靠new_task工具把子任务委派给各个专业模式每个子任务需要携带完整上下文、明确的范围边界、完成信号attempt_completion以及指令优先于模式默认指令的声明packages/types/src/mode.ts。工具组的底层映射模式的工具权限并非独立魔法而是由src/shared/tools.ts中的TOOL_GROUPS统一管理。核心映射如下src/shared/tools.tsread组 →read_file、search_files、list_files、codebase_searchedit组 →apply_diff、write_to_file、generate_image另有edit、search_replace、edit_file、apply_patch等 opt-in 自定义工具command组 →execute_command、read_command_outputmcp组 →use_mcp_tool、access_mcp_resourcemodes组 →switch_mode、new_task标记为alwaysAvailable。除此之外ALWAYS_AVAILABLE_TOOLS定义了所有模式都始终可用的基础工具ask_followup_question、attempt_completion、switch_mode、new_task、update_todo_list、run_slash_command、skill。也就是说无论处于哪个模式AI 都能提问澄清、宣告完成、切换模式、创建子任务、维护待办清单、执行斜杠命令与加载技能。在src/shared/modes.ts的getToolsForMode第 28-42 行中可以看到组装逻辑遍历模式声明的每个工具组收集对应工具再追加ALWAYS_AVAILABLE_TOOLS最终形成该模式的实际工具全集。这也是模式决定能力边界这一设计的实现根基。自定义模式为团队打造专属角色内置模式只定义了通用工作流真正的灵活性来自自定义模式。Roo Code 支持两种来源全局自定义模式存储在全局设置文件customModes配置中对所有项目生效项目级自定义模式存储在项目根目录的.roomodes文件中随仓库分发、随团队共享。两者的合并规则见src/core/config/CustomModesManager.ts的mergeCustomModes第 226-247 行项目级模式优先同名 slug 以.roomodes中的定义覆盖全局配置不同 slug 则两者共存。模式配置 Schema自定义模式的每个字段都由packages/types/src/mode.ts中的modeConfigSchema校验第 96-105 行字段类型必填说明与校验规则slugstring是模式唯一标识正则^[a-zA-Z0-9-]$仅允许字母、数字、短横线namestring是显示名称至少 1 个字符roleDefinitionstring是角色定义提示词核心至少 1 个字符whenToUsestring否何时使用该模式的说明descriptionstring否模式简介customInstructionsstring否附加自定义指令groupsGroupEntry[]是工具组列表自动过滤已废弃组如browser且不允许重复组sourceglobal | project否来源标识由系统按存储位置自动打标其中groups的每一项可以是纯字符串如read也可以是带选项的元组[edit, { fileRegex: \\.md$, description: Markdown files only }]——后者通过fileRegex对工具组施加文件类型限制groupOptionsSchema会先校验正则合法性packages/types/src/mode.ts。编写一份自定义模式示例假设你想创建一个面向测试团队的test-engineer模式。在全局配置中它的 YAML 形态如下结构参考src/core/config/CustomModesManager.ts中yaml.stringify({ customModes: [...] })的持久化格式customModes: - slug: test-engineer name: Test Engineer roleDefinition: You are a test engineer specializing in writing and maintaining automated tests. whenToUse: Use this mode when writing tests, fixing flaky tests, or analyzing test coverage. description: Write and maintain automated tests customInstructions: | - Always run the relevant test suite after making changes. - Prefer the projects existing test framework and conventions. groups: - read - edit - command - mcp若希望该模式只允许改动测试相关文件可借助元组语法限制groups: - read - [edit, { fileRegex: .*\\.(test|spec)\\.(ts|tsx|js|jsx)$, description: Test files only }] - command需要说明的是这里的 YAML 配置在保存时会经过modeConfigSchema校验任何非法字段如 slug 含空格、重复 slug、非法正则都会被拒绝并在编辑器中给出明确的校验错误提示见CustomModesManager.updateCustomMode的校验分支src/core/config/CustomModesManager.ts。自定义模式如何覆盖内置模式从源码看自定义模式不仅可新增还可覆盖。在src/shared/modes.ts的getAllModes第 70-91 行中处理逻辑是以内置模式数组为基础遍历自定义模式——若 slug 与内置模式相同则原地覆盖否则追加为新模式。getModeSelection第 111-132 行则进一步决定最终生效的提示词组件存在自定义模式时完全采用自定义配置否则以内置模式为基础合并customModePrompts中的部分覆盖。模式提示词的组装自定义指令如何生效模式的能力不仅取决于工具权限还取决于注入到系统提示词中的角色定义与自定义指令。在src/core/prompts/sections/custom-instructions.ts及getFullModeDetailssrc/shared/modes.ts中可以看到完整的组装链路从自定义模式或内置模式中取得基础配置读取customModePrompts中针对该 slug 的覆盖项roleDefinition、whenToUse、customInstructions若提供了工作目录cwd调用addCustomInstructions把以下内容按序叠加模式自身的customInstructions→ 全局自定义指令globalCustomInstructions→ 项目工作区中的规则文件最终合并为完整的customInstructions。这解释了为什么在团队项目中.roo目录下的规则文件能够自动注入到对应模式的提示词中无需手工复制。该行为由仓库内的提示词组装测试src/core/prompts/sections/__tests__/custom-instructions.spec.ts及快照如global-and-mode-instructions.snap、architect-mode-rules.snap覆盖验证。模式的导入与导出让团队共享角色配置CustomModesManager还提供了完整的导入导出能力便于在不同机器、不同仓库间迁移模式配置src/core/config/CustomModesManager.ts导出exportModeWithRules第 715-837 行将指定 slug 的模式配置含其roleDefinition、customInstructions、groups连同.roo/rules-{slug}/项目级或全局rules-{slug}/全局级目录下的规则文件一起序列化为customModes数组的 YAML 文本。导入importModeWithRules第 926-999 行解析 YAML逐个校验modeConfigSchema支持覆盖已有 slug若指定source: project则写入当前工作区的.roomodessource: global则写入全局配置。导入时还会对规则文件路径做路径穿越防护——拒绝含..或绝对路径的条目确保导入文件始终落在rules-{slug}目录内见importRulesFiles第 845-918 行。导出的 YAML 结构示例customModes: - slug: test-engineer name: Test Engineer roleDefinition: You are a test engineer specializing in writing and maintaining automated tests. groups: - read - [edit, { fileRegex: .*\\.(test|spec)\\.(ts|tsx)$, description: Test files only }] - command - mcp rulesFiles: - relativePath: conventions.md content: Always use the projects existing test helpers and naming conventions.这样的文件可以直接提交到仓库团队成员导入后即获得一致的测试工程师角色与规则。模式文件热更新机制自定义模式之所以能改完即用是因为CustomModesManager在启动时会为两个来源的文件注册文件系统监听器watchCustomModesFiles监听全局自定义模式配置文件的变化创建/修改/删除监听当前工作区.roomodes文件的变化即使文件尚不存在也会注册 watcher。任一文件变更后管理器都会重新读取两份文件、按项目级优先合并写入扩展的globalState并触发onUpdate刷新界面。同时getCustomModes使用 10 秒 TTL 缓存第 48 行避免频繁磁盘读取。另外YAML 解析前会先清洗不可见字符与智能引号cleanInvisibleCharacters第 115-142 行并在.roomodes的 YAML 解析失败时回退尝试 JSON 解析兼顾了配置文件的健壮性。MCP 与模式扩展 AI 的外部工具生态模式的mcp工具组对应use_mcp_tool与access_mcp_resource两个工具src/shared/tools.ts这意味着只要模式声明了mcp组就能调用用户配置的 MCP 服务器。MCPModel Context Protocol服务器的统一管理由 src/services/mcp/McpHub.ts 与 src/services/mcp/McpServerManager.ts 负责。实际开发中在 Architect/Ask 等模式中mcp组允许 AI 读取外部资源来辅助规划与答疑在 Code/Debug 模式中mcp组让 AI 可以调用数据库、浏览器、CI 系统等第三方工具把编码助手扩展为接入了团队基础设施的智能体。这也解释了 README 中Utilize MCP Servers能力项的来源MCP 不是独立于模式之外的功能而是作为可授予的工具组之一融入每个模式的权限模型中。快速上手在编辑器里试用模式体系安装 Roo Code 扩展后在侧边栏或命令面板中找到模式选择器即可在 Architect / Code / Ask / Debug / Orchestrator 之间切换。从 Ask 模式起步了解代码库只读、零风险需要动手时切换到Code 模式。复杂需求先切 Architect让 AI 先产出计划与 todo 清单审阅通过后再切 Code 实施。排查问题时用 Debug 模式让 AI 按假设—验证—确认—修复的节奏工作。定制团队角色在设置中打开自定义模式配置或直接在项目根目录创建.roomodes文件写入上述 YAML 示例并保存模式会通过文件监听自动热更新。跨团队共享使用模式的导入/导出功能将写好的角色配置连同规则文件一起分享给同事或提交进仓库。结语Roo Code 的模式体系是一套把AI 编码助手升级为多角色开发团队的机制内置模式提供了职责清晰的能力边界自定义模式允许按团队规范自由扩展而工具组映射、提示词组装、文件热更新与导入导出等底层实现保证了这套体系既可配置、又可验证、还便于共享。理解这些机制后你就能把 Roo Code 真正调教成贴合自己与团队工作方式的全栈 AI 队友。【免费下载链接】Roo-CodeRoo Code gives you a whole dev team of AI agents in your code editor.项目地址: https://gitcode.com/GitHub_Trending/ro/Roo-Code创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/13 18:55:37 · 阅读 1.2k Roo Code 模式（Modes）实战指南：从内置模式到自定义团队工作流
Roo Code 模式Modes实战指南从内置模式到自定义团队工作流【免费下载链接】Roo-CodeRoo Code gives you a whole dev team of AI agents in your code editor.项目地址: https://gitcode.com/GitHub_Trending/ro/Roo-Code这篇技术指南围绕 Roo Code 的模式Modes体系展开带你理解 Code、Architect、Ask、Debug 等内置模式的职责边界与工具权限划分并深入介绍如何通过customModes全局配置或项目级.roomodes文件创建、导入、导出专属自定义模式把 AI 助手塑造成贴合团队规范与个人工作流的专属开发团队成员。读完本文你将掌握 Roo Code 模式体系的完整骨架、配置语法与源码级运行原理能够直接在你的编辑器中落地一套可复用的多角色协作方案。为什么说 Roo Code 是编辑器里的 AI 开发团队Roo Code 的定位可以用一句话概括你的 AI 驱动开发团队就在编辑器里Your AI-Powered Dev Team, Right in Your Editor见 根目录 README。它不是一个只会生成代码的单点助手而是一个能覆盖完整研发链路的多角色协作系统——从需求规划、编码实现、代码提问到故障排查每个环节都有专门的角色负责。围绕这一核心定位Roo Code 能为你做的事情包括从自然语言描述中生成代码通过模式Modes适配不同工作场景Code、Architect、Ask、Debug 以及自定义模式重构与调试已有代码编写与更新文档回答代码库相关问题自动化重复性任务接入 MCP 服务器扩展第三方工具与数据源能力。其中模式Modes是 Roo Code 区别于普通 AI 编码助手的关键设计它让 AI 适应你的工作方式而不是反过来。本指南将围绕这一核心主题展开结合仓库源码packages/types/src/mode.ts、src/shared/modes.ts、src/shared/tools.ts、src/core/config/CustomModesManager.ts逐层拆解其机制。内置模式全景每个角色负责什么Roo Code 开箱即用地提供了五个内置模式它们的默认配置定义在packages/types/src/mode.ts的DEFAULT_MODES常量中约 第 168-227 行并通过 src/shared/modes.ts 导出供全仓库使用。下表整理了各模式的核心职责、适用场景与默认工具组模式名称核心职责roleDefinition 摘要适用场景默认工具组architectArchitect经验丰富的技术负责人负责收集信息、制定详细计划实现前先规划、拆解复杂问题、编写技术规格、设计系统架构readedit仅 MarkdownmcpcodeCode精通多语言/框架/设计模式的高技能软件工程师编写、修改、重构代码实现功能、修复缺陷、创建文件readeditcommandmcpaskAsk知识型技术助手专注回答问题与提供信息解释概念、分析已有代码、获取建议、学习技术不修改代码readmcpdebugDebug专家级软件调试员系统化诊断与解决问题排查故障、分析错误、添加日志、定位根因readeditcommandmcporchestratorOrchestrator战略级工作流编排者将复杂任务委派给合适的专业模式跨领域的多步骤项目、任务拆解、工作流协调无固定组主要通过new_task委派内置模式的职责定义与工具边界从源码可以看到每个模式由slug唯一标识、name显示名、roleDefinition角色定义、whenToUse何时使用、description简介、groups工具组和可选的customInstructions自定义指令组成。以下逐个剖析关键设计Architect规划者角色定义经验丰富的技术领导者好奇心强且善于规划目标是通过信息收集获取上下文制定详细计划供用户审阅批准后再切换到其他模式实施packages/types/src/mode.ts。关键约束它的edit组通过fileRegex: \\.md$限制了只能编辑 Markdown 文件这意味着规划模式在结构上就无法直接改动业务代码只能产出.md计划文档——从工具权限层面强制了规划与实施分离。内置指令要求它使用update_todo_list工具创建可执行的任务清单并在规划完成后用switch_mode请求切换到实施模式还特别约定Mermaid 图中避免在方括号内使用双引号和括号以防解析错误。Code实施者角色定义Roo一名在众多编程语言、框架、设计模式和最佳实践方面拥有丰富知识的高技能软件工程师。工具组最全read读文件/搜索、edit改动代码、command执行命令、mcp调用外部工具是日常编码的主战场。Ask问答者角色定义知识型技术助手专注于回答软件开发生态相关问题。工具组只有readmcp没有edit和command因此它天然无法改动文件或执行命令只负责解释、分析和输出文档化答案内置指令还明确除非用户明确要求否则不要转向实现代码。Debug排障者角色定义专家级软件调试员专注于系统化的问题诊断与解决。工具组与 Code 相同readeditcommandmcp但内置指令引导了不同的工作流先反思 5-7 种可能的问题来源收敛到 1-2 个最可能的根因添加日志验证假设并在修复前明确请用户确认诊断。Orchestrator编排者角色定义战略级工作流编排者通过把复杂任务委派给合适的专业模式来协调。它的groups为空数组这意味着它不直接操作文件而是依靠new_task工具把子任务委派给各个专业模式每个子任务需要携带完整上下文、明确的范围边界、完成信号attempt_completion以及指令优先于模式默认指令的声明packages/types/src/mode.ts。工具组的底层映射模式的工具权限并非独立魔法而是由src/shared/tools.ts中的TOOL_GROUPS统一管理。核心映射如下src/shared/tools.tsread组 →read_file、search_files、list_files、codebase_searchedit组 →apply_diff、write_to_file、generate_image另有edit、search_replace、edit_file、apply_patch等 opt-in 自定义工具command组 →execute_command、read_command_outputmcp组 →use_mcp_tool、access_mcp_resourcemodes组 →switch_mode、new_task标记为alwaysAvailable。除此之外ALWAYS_AVAILABLE_TOOLS定义了所有模式都始终可用的基础工具ask_followup_question、attempt_completion、switch_mode、new_task、update_todo_list、run_slash_command、skill。也就是说无论处于哪个模式AI 都能提问澄清、宣告完成、切换模式、创建子任务、维护待办清单、执行斜杠命令与加载技能。在src/shared/modes.ts的getToolsForMode第 28-42 行中可以看到组装逻辑遍历模式声明的每个工具组收集对应工具再追加ALWAYS_AVAILABLE_TOOLS最终形成该模式的实际工具全集。这也是模式决定能力边界这一设计的实现根基。自定义模式为团队打造专属角色内置模式只定义了通用工作流真正的灵活性来自自定义模式。Roo Code 支持两种来源全局自定义模式存储在全局设置文件customModes配置中对所有项目生效项目级自定义模式存储在项目根目录的.roomodes文件中随仓库分发、随团队共享。两者的合并规则见src/core/config/CustomModesManager.ts的mergeCustomModes第 226-247 行项目级模式优先同名 slug 以.roomodes中的定义覆盖全局配置不同 slug 则两者共存。模式配置 Schema自定义模式的每个字段都由packages/types/src/mode.ts中的modeConfigSchema校验第 96-105 行字段类型必填说明与校验规则slugstring是模式唯一标识正则^[a-zA-Z0-9-]$仅允许字母、数字、短横线namestring是显示名称至少 1 个字符roleDefinitionstring是角色定义提示词核心至少 1 个字符whenToUsestring否何时使用该模式的说明descriptionstring否模式简介customInstructionsstring否附加自定义指令groupsGroupEntry[]是工具组列表自动过滤已废弃组如browser且不允许重复组sourceglobal | project否来源标识由系统按存储位置自动打标其中groups的每一项可以是纯字符串如read也可以是带选项的元组[edit, { fileRegex: \\.md$, description: Markdown files only }]——后者通过fileRegex对工具组施加文件类型限制groupOptionsSchema会先校验正则合法性packages/types/src/mode.ts。编写一份自定义模式示例假设你想创建一个面向测试团队的test-engineer模式。在全局配置中它的 YAML 形态如下结构参考src/core/config/CustomModesManager.ts中yaml.stringify({ customModes: [...] })的持久化格式customModes: - slug: test-engineer name: Test Engineer roleDefinition: You are a test engineer specializing in writing and maintaining automated tests. whenToUse: Use this mode when writing tests, fixing flaky tests, or analyzing test coverage. description: Write and maintain automated tests customInstructions: | - Always run the relevant test suite after making changes. - Prefer the projects existing test framework and conventions. groups: - read - edit - command - mcp若希望该模式只允许改动测试相关文件可借助元组语法限制groups: - read - [edit, { fileRegex: .*\\.(test|spec)\\.(ts|tsx|js|jsx)$, description: Test files only }] - command需要说明的是这里的 YAML 配置在保存时会经过modeConfigSchema校验任何非法字段如 slug 含空格、重复 slug、非法正则都会被拒绝并在编辑器中给出明确的校验错误提示见CustomModesManager.updateCustomMode的校验分支src/core/config/CustomModesManager.ts。自定义模式如何覆盖内置模式从源码看自定义模式不仅可新增还可覆盖。在src/shared/modes.ts的getAllModes第 70-91 行中处理逻辑是以内置模式数组为基础遍历自定义模式——若 slug 与内置模式相同则原地覆盖否则追加为新模式。getModeSelection第 111-132 行则进一步决定最终生效的提示词组件存在自定义模式时完全采用自定义配置否则以内置模式为基础合并customModePrompts中的部分覆盖。模式提示词的组装自定义指令如何生效模式的能力不仅取决于工具权限还取决于注入到系统提示词中的角色定义与自定义指令。在src/core/prompts/sections/custom-instructions.ts及getFullModeDetailssrc/shared/modes.ts中可以看到完整的组装链路从自定义模式或内置模式中取得基础配置读取customModePrompts中针对该 slug 的覆盖项roleDefinition、whenToUse、customInstructions若提供了工作目录cwd调用addCustomInstructions把以下内容按序叠加模式自身的customInstructions→ 全局自定义指令globalCustomInstructions→ 项目工作区中的规则文件最终合并为完整的customInstructions。这解释了为什么在团队项目中.roo目录下的规则文件能够自动注入到对应模式的提示词中无需手工复制。该行为由仓库内的提示词组装测试src/core/prompts/sections/__tests__/custom-instructions.spec.ts及快照如global-and-mode-instructions.snap、architect-mode-rules.snap覆盖验证。模式的导入与导出让团队共享角色配置CustomModesManager还提供了完整的导入导出能力便于在不同机器、不同仓库间迁移模式配置src/core/config/CustomModesManager.ts导出exportModeWithRules第 715-837 行将指定 slug 的模式配置含其roleDefinition、customInstructions、groups连同.roo/rules-{slug}/项目级或全局rules-{slug}/全局级目录下的规则文件一起序列化为customModes数组的 YAML 文本。导入importModeWithRules第 926-999 行解析 YAML逐个校验modeConfigSchema支持覆盖已有 slug若指定source: project则写入当前工作区的.roomodessource: global则写入全局配置。导入时还会对规则文件路径做路径穿越防护——拒绝含..或绝对路径的条目确保导入文件始终落在rules-{slug}目录内见importRulesFiles第 845-918 行。导出的 YAML 结构示例customModes: - slug: test-engineer name: Test Engineer roleDefinition: You are a test engineer specializing in writing and maintaining automated tests. groups: - read - [edit, { fileRegex: .*\\.(test|spec)\\.(ts|tsx)$, description: Test files only }] - command - mcp rulesFiles: - relativePath: conventions.md content: Always use the projects existing test helpers and naming conventions.这样的文件可以直接提交到仓库团队成员导入后即获得一致的测试工程师角色与规则。模式文件热更新机制自定义模式之所以能改完即用是因为CustomModesManager在启动时会为两个来源的文件注册文件系统监听器watchCustomModesFiles监听全局自定义模式配置文件的变化创建/修改/删除监听当前工作区.roomodes文件的变化即使文件尚不存在也会注册 watcher。任一文件变更后管理器都会重新读取两份文件、按项目级优先合并写入扩展的globalState并触发onUpdate刷新界面。同时getCustomModes使用 10 秒 TTL 缓存第 48 行避免频繁磁盘读取。另外YAML 解析前会先清洗不可见字符与智能引号cleanInvisibleCharacters第 115-142 行并在.roomodes的 YAML 解析失败时回退尝试 JSON 解析兼顾了配置文件的健壮性。MCP 与模式扩展 AI 的外部工具生态模式的mcp工具组对应use_mcp_tool与access_mcp_resource两个工具src/shared/tools.ts这意味着只要模式声明了mcp组就能调用用户配置的 MCP 服务器。MCPModel Context Protocol服务器的统一管理由 src/services/mcp/McpHub.ts 与 src/services/mcp/McpServerManager.ts 负责。实际开发中在 Architect/Ask 等模式中mcp组允许 AI 读取外部资源来辅助规划与答疑在 Code/Debug 模式中mcp组让 AI 可以调用数据库、浏览器、CI 系统等第三方工具把编码助手扩展为接入了团队基础设施的智能体。这也解释了 README 中Utilize MCP Servers能力项的来源MCP 不是独立于模式之外的功能而是作为可授予的工具组之一融入每个模式的权限模型中。快速上手在编辑器里试用模式体系安装 Roo Code 扩展后在侧边栏或命令面板中找到模式选择器即可在 Architect / Code / Ask / Debug / Orchestrator 之间切换。从 Ask 模式起步了解代码库只读、零风险需要动手时切换到Code 模式。复杂需求先切 Architect让 AI 先产出计划与 todo 清单审阅通过后再切 Code 实施。排查问题时用 Debug 模式让 AI 按假设—验证—确认—修复的节奏工作。定制团队角色在设置中打开自定义模式配置或直接在项目根目录创建.roomodes文件写入上述 YAML 示例并保存模式会通过文件监听自动热更新。跨团队共享使用模式的导入/导出功能将写好的角色配置连同规则文件一起分享给同事或提交进仓库。结语Roo Code 的模式体系是一套把AI 编码助手升级为多角色开发团队的机制内置模式提供了职责清晰的能力边界自定义模式允许按团队规范自由扩展而工具组映射、提示词组装、文件热更新与导入导出等底层实现保证了这套体系既可配置、又可验证、还便于共享。理解这些机制后你就能把 Roo Code 真正调教成贴合自己与团队工作方式的全栈 AI 队友。【免费下载链接】Roo-CodeRoo Code gives you a whole dev team of AI agents in your code editor.项目地址: https://gitcode.com/GitHub_Trending/ro/Roo-Code创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考