极狐 GitLab

自定义指令/规则/工作流

自定义指令#

自定义指令允许你个性化 CodeRider 的行为，提供特定的指导来塑造响应、编码风格和决策过程。

什么是自定义指令？#

自定义指令定义了扩展的特定行为、偏好和约束，超出了 CodeRider 的基本角色定义。示例包括编码风格、文档标准、测试要求和工作流指南。

自定义指令 VS 规则
自定义指令是 IDE 范围的，适用于所有工作区，无论你在处理哪个项目，都会保持你的偏好。与指令不同，自定义规则 是项目特定的，允许你设置基于工作区的规则集。

设置自定义指令#

如何设置#

instruction
  1. 打开提示标签： 点击 CodeRider 模式编辑按钮
  2. 找到部分： 下滑找到 "所有模式的自定义指令" 部分
  3. 输入指令： 在文本区域输入你的指令
  4. 保存更改： 点击 "完成" 保存你的更改

模式特定指令#

模式特定指令可以使用提示标签设置

instruction
  • 打开标签： 点击 CodeRider 模式编辑按钮
  • 选择模式： 在模式标题下，点击你想要自定义的模式按钮
  • 输入指令： 在 "模式特定自定义指令（可选）" 下的文本区域输入你的指令
  • 保存更改： 点击 "完成" 保存你的更改

全局模式规则
如果模式本身是全局的（非工作区特定），你为其设置的任何自定义指令也将全局适用于所有工作区的该模式。

自定义规则#

自定义规则提供了一种强大的方式来定义项目特定的行为和约束，以确保 CodeRider AI 智能体的一致性。通过自定义规则，你可以确保格式一致、限制对敏感文件的访问、强制执行编码标准，并根据你的项目需求自定义 AI 的行为。

概述#

自定义规则允许您创建文本指令，所有 AI 模型在与您的项目交互时都将遵循这些指令。这些规则充当护栏和约定，在与您的代码库的所有交互中始终得到遵守。规则可以通过文件系统和内置 UI 界面进行管理。

规则格式#

自定义规则可以用纯文本编写，但建议使用 Markdown 格式，以便更好地组织和让 AI 模型理解。Markdown 的结构化特性有助于模型更有效地解析和理解你的规则。

  • 使用 Markdown 标题（#, ## 等）定义规则类别
  • 使用列表（-, *）枚举特定项目或约束
  • 使用代码块在需要时包含代码示例

规则类型#

CodeRider 支持两种类型的自定义规则：

  • 项目规则：仅适用于当前项目工作区
  • 全局规则：适用于所有项目和工作区

UI 支持
内置规则管理 UI 仅适用于一般规则。模式特定规则必须通过文件系统进行管理。

规则位置#

项目规则#

自定义规则主要从 .coderider/rules/ 目录 加载。这是组织项目特定规则的推荐方法。每个规则通常放置在具有描述性名称的 Markdown 文件中：

text
1project/
2├── .coderider/
3│   ├── rules/
4│   │   ├── formatting.md
5│   │   ├── restricted_files.md
6│   │   └── naming_conventions.md
7├── src/
8└── ...

全局规则#

全局规则存储在您的主目录中，适用于所有项目：

text
~/.coderider/
├── rules/
│   ├── coding_standards.md
│   ├── security_guidelines.md
│   └── documentation_style.md

通过 UI 管理规则#

CodeRider 提供了一个内置界面，用于管理您的自定义规则，而无需手动编辑 .coderider/rules/ 目录中的文件。要访问 UI，请单击 CodeRider 窗口右下角的“管理CodeRider规则和工作流”图标。

您可以访问规则管理 UI 来：

  • 查看所有活动规则（项目和全局）
  • 在不删除规则的情况下切换规则的开启/关闭状态
  • 直接在界面中创建和编辑规则
  • 按类别和优先级组织规则

规则加载顺序#

通用规则（所有模式）#

规则按以下优先级顺序加载：

  1. 存放在 ~/.coderider/rules/ 目录的全局规则
  2. 存放在 .coderider/rules/目录的项目规则

当全局规则和项目规则都存在时，它们将合并，存在冲突时项目规则优先于全局规则。

备注: 我们强烈建议将规则保留在 .coderider/rules/ 文件夹中，因为它提供了更好的组织，并且是未来版本的首选方法。基于文件夹的结构允许更细粒度的规则组织和更清晰的关注点分离。基于文件的旧方法为了向后兼容而保留，但可能会在未来的版本中发生变化。

模式特定规则#

此外，系统支持模式特定的规则，这些规则会单独加载，并有自己的优先级顺序：

  • 检查 .coderider/rules-${mode}/ 目录

目前，模式特定规则仅在项目级别受支持。 当通用规则和模式特定规则同时存在时，模式特定规则在最终输出中具有优先权。

创建自定义规则#

使用 UI 界面#

创建和管理规则的最简单方法是通过内置 UI：

  1. 从 CodeRider 面板访问规则管理界面
  2. 选择创建项目特定规则或全局规则
  3. 使用界面创建、编辑或切换规则
  4. 规则会自动保存并立即应用

使用文件系统#

手动创建规则：

对于项目规则：

  1. 如果不存在，请创建 .coderider/rules/ 目录
  2. 在此目录中创建一个具有描述性名称的新 Markdown 文件
  3. 使用 Markdown 格式编写你的规则
  4. 保存文件

对于全局规则：

  1. 如果 ~/.coderider/rules/ 目录尚不存在，则创建它
  2. 在此目录中创建一个新的 Markdown 文件，并带有描述性名称
  3. 使用 Markdown 格式编写您的规则
  4. 保存文件

该规则将自动应用于你项目中所有未来的 CodeRider 交互。任何新更改都会立即生效。

规则示例#

示例 1：表格格式化#

text
# 表格
打印表格时，始终在每列标题中添加感叹号

这个简单的规则指示 AI 在生成表格时在所有列标题中添加感叹号。

示例 2：限制文件访问#

text
1# 受限文件
2
3列表中包含敏感数据的文件，禁止读取
4
5- supersecrets.txt
6- credentials.json
7- .env

此规则防止 AI 读取或访问敏感文件，即使明确要求这样做。

使用场景#

自定义规则可以应用于各种场景：

  • 代码风格：强制执行一致的格式、命名约定和文档风格
  • 安全控制：防止访问敏感文件或目录
  • 项目结构：定义不同类型文件的创建位置
  • 文档要求：指定文档格式和要求
  • 测试模式：定义测试的结构方式
  • API 使用：指定 API 的使用和文档方式
  • 错误处理：定义错误处理约定

自定义规则示例#

  • "严格遵守代码风格指南 [你的项目特定代码风格指南]"
  • "始终使用空格缩进，宽度为 4 个空格"
  • "使用 camelCase 命名变量"
  • "为所有新函数编写单元测试"
  • "在提供代码之前解释你的推理"
  • "专注于代码的可读性和可维护性"
  • "优先使用社区中最常见的库"
  • "当为网站添加新功能时，确保它们是响应式且可访问的"

最佳实践#

  • 具体明确：明确定义每个规则的范围和意图
  • 使用类别：将相关规则组织在共同的标题下
  • 分离关注点：为不同类型的规则使用不同的文件
  • 使用示例：包含示例以说明预期行为
  • 保持简单：规则应简洁易懂
  • 定期更新：随着项目需求的变化，定期审查和更新规则

限制#

  • 规则由 AI 模型尽力应用
  • 复杂规则可能需要多个示例才能清晰理解
  • 项目规则仅适用于定义它们的项目
  • 全局规则适用于所有项目

自定义工作流#

Workflows 通过为 CodeRider 定义分步指令来自动化重复性任务。通过在聊天中键入 /[workflow-name.md] 来调用任何工作流。

workflow

创建工作流#

工作流是存储在 .coderider/workflows/ 中的 markdown 文件：

  • 全局工作流：~/.coderider/workflows/（在所有项目中可用）
  • 项目工作流：[project]/.coderider/workflows/（项目特定）

基本设置#

  1. 创建一个包含分步指令的 .md 文件
  2. 将其保存在您的工作流目录中
  3. 键入 /filename.md 执行

常见工作流模式#

发布管理#

  1. 收集自上次发布以来合并的 MR
  2. 从提交消息生成更新日志
  3. 更新版本号
  4. 创建发布分支和标签
  5. 部署到 staging 环境

项目设置#

  1. 克隆仓库模板
  2. 安装依赖项（npm install、pip install -r requirements.txt）
  3. 配置环境文件
  4. 初始化数据库/服务
  5. 运行初始测试

代码审查准备#

  1. 搜索 TODO 注释和 debug 语句
  2. 运行 linting 和格式化
  3. 执行测试套件
  4. 从最近的提交生成 MR 描述

示例：MR 提交工作流#

让我们逐步创建一个用于提交拉取请求的工作流。此工作流处理从代码审查到部署通知的整个过程。 在您的 .coderiderkilo/workflows 目录中创建一个名为 submit-mr.md 的文件：

text
1# 提交 MR 工作流
2
3您正在帮助提交合并请求。请按照以下步骤操作：
4
5## 步骤
61. 使用 `search_files` 检查是否有不应提交的 TODO 注释或 console.log 语句
72. 使用 `execute_command` 运行测试：`npm test` 或适当的测试命令
83. 如果测试通过，暂存并提交更改，附上描述性提交消息
94. 推送分支并创建 MR：
10   `git push origin <分支名称> -o merge_request.create`
115. 使用 `ask_followup_question` 从用户那里获取 MR 标题和描述
12
13## 所需参数
14如果未提供则询问：
15- 分支名称
16- 要分配的审阅者

现在您可以通过在聊天中键入 /submit-mr.md 来触发此工作流。CodeRider 将：

  • 在提交之前扫描您的代码以查找常见问题
  • 运行您的测试套件以尽早发现问题
  • 处理 Git 操作和 MR 创建
  • 自动通知您的团队
  • 设置部署的后续任务

这使您无需手动运行相同的 7 步过程，每次您想提交代码进行审查时。