Cline 规则怎么写：创建 .clinerules 并验证加载
先建立两份能够验收的规则
在仓库的 .clinerules/ 目录中放入任务约定和检查交付规则。启用两份文件，新建任务，再核对计划、代码差异与测试输出。先让基本配置在当前客户端生效，再增加路径条件。
本文提供完整示例文件和验收流程。我们于 2026 年 10 月 23 日核对了官方文档与公开源码快照，没有实际运行 Cline 处理仓库，也没有测量这些指令能否改善模型表现。
规则把指令加入模型上下文，不会建立权限边界或安全沙箱。工具审批和仓库访问权限需要单独配置，具体控制见 Cline 的 Auto Approve 文档。
按客户端选择存放位置
配置指南列出项目目录 .cline/rules/ 和较早的 .clinerules/，也列出仓库根目录的 AGENTS.md 与全局 ~/.agents/AGENTS.md。下文统一使用 .clinerules/，不要把相同指令复制到两个目录。
当前加载器也兼容没有扩展名的 .clinerules 文件。同一路径不能同时是文件和目录。转换已有文件前，先保存原文，再将原文移入新目录中的 Markdown 文件。规则文件直接放在目录内；该加载器扫描 .md、.markdown 和 .txt 文件，不会递归加载嵌套的规则目录。
个人默认规则的共享路径解析器会查找 ~/.cline/rules、~/Cline/Rules 及 Documents 下的 Cline Rules 目录。Windows 还可能使用 OneDrive 重定向的 Documents 位置。以客户端实际显示的目录为准，不要猜测它使用哪个文档文件夹。
规则文档说明，项目规则与全局规则冲突时，项目规则优先。实际维护时仍应消除矛盾。数字前缀便于整理文件，不会建立权限层级，也不能证明模型会遵循哪条冲突指令。
不同客户端需要分别检查。
- 编辑器通过天平图标打开 Rules 面板，逐个检查文件开关。
- CLI 使用文档列出的规则目录，但有自己的配置与审批控制。检查
cline config。CLI 概览目前将全局自动批准列为默认开启，试用前核对实际设置。 - Cloud Agents 当前不加载规则、技能、MCP 服务器或连接器。将规则提交到仓库，不代表云端会话会启用它。
创建任务约定与交付规则
在编辑器中打开仓库根目录。如果 .clinerules 尚不存在，创建该目录。按下面的文件名保存完整内容。示例假设仓库是包含 package.json 的 JavaScript 或 TypeScript 项目，允许修改的路径、包管理器与检查命令都应按实际项目调整。
保存为 .clinerules/01-task-contract.md：
# 任务约定
提出修改前：
- 阅读 README.md 和 package.json，根据锁文件确认包管理器。
- 检查目标文件与附近测试，不读取 .env 文件或凭据。
- 说明目标行为、计划修改的文件与相关检查。
- 如果请求没有定义修改范围，先提出范围，再开始编辑。
实现期间：
- 只修改约定任务需要的文件，保留用户已有的无关改动。
- 修改依赖或锁文件前，先解释必要性。
- 如果必要修改超出约定范围，停止并说明原因。
保存为 .clinerules/02-checks-and-delivery.md：
# 检查与交付
交付前：
- 从 package.json 和项目 README 中找到已有检查命令。
- 改变程序行为时，如果项目已有测试体系，增加或更新对应的精简测试。
- 运行相关测试，以及针对所改代码配置的类型检查或 lint 检查。
- 如果必要检查不存在或无法运行，明确报告限制。
交付时：
- 检查最终差异，排除无关修改与空白错误。
- 交付时列出改动文件、完整命令及结果、尚未解决的问题。
- 只有亲眼看到成功结果，才能报告检查通过。
规则要求 Cline 查找实际命令，没有假设每个项目都有 lint、typecheck 或 test。例如，npm 项目可能使用下面的命令。最后两条只有在脚本存在，且测试运行器支持文件参数时才适用，必须替换为仓库的实际命令。
git status --short
npm run
git diff --check
npm run typecheck
npm test -- src/utils/parse-label.test.ts
检查要求应保持无条件加载。只在 *.test.ts 匹配时才加载的测试规则，可能漏掉只改业务代码、没有创建测试的任务。
先确认加载，再检查执行
在编辑器的 Rules 面板中确认两份文件都位于项目范围，且开关已开启。然后通过 Git 检查文件。当前扩展实现使用 YAML disabled 元数据保存开关，因此关闭规则可能修改已跟踪的文件。提交前检查差异，避免把个人临时选择带给团队。
新建 Plan 会话，提出范围明确的请求。将示例路径替换为仓库中已有的函数与测试。
只做计划。在 src/utils/parse-label.ts 中，让 parseLabel 拒绝空字符串
及只有空白的输入，保留有效输入的现有行为。
修改范围仅限该文件及 src/utils/parse-label.test.ts。
编辑前，指出相关现有代码与测试命令。
检查回复是否指出两个文件的修改范围、现有实现与适用检查。模型说“已加载规则”不足以证明规则生效，还要把计划与它实际检查的文件对照。确认计划后，以所需审批设置切换到 Act，再让它尝试修改。
只有检查了最终差异与真实检查结果，才能验收。结果必须拒绝指定输入、保留原有有效行为，并且没有越界修改。Cline 的检查点使用独立的影子 Git 仓库，可以帮助恢复本地修改，但不能代替你的提交、分支审查或备份。
增加条件规则，分别验证匹配与不匹配
规则指南将 paths 定义为相对项目根目录的 glob 模式数组。任意路径匹配即可触发规则。编辑器标签页、提示词中的路径与任务涉及的文件都可能提供上下文。路径匹配不能绕过关闭的规则开关。
把这份可选文件保存为 .clinerules/20-typescript.md：
---
paths:
- "src/**/*.ts"
- "src/**/*.tsx"
---
# TypeScript 修改
当任务修改 src 下的 .ts 或 .tsx 文件时：
- 在规则验收期间，首次计划中包含一次 TS-RULE-ACTIVE。
- 新增公共类型前，先检查附近已有类型。
- 除非任务需要改变 API，否则保留导出签名。
- 解释新增 any 类型或 TypeScript 错误抑制注释的原因。
路径条件必须在你安装的客户端中验证。当前 SDK 规则渲染器筛选启用规则时，该函数没有评估 paths。这次源码检查不能证明编辑器、Desktop 与 CLI 的条件行为完全相同。在确认实际客户端前，把必要任务约束保留在无条件规则里。
- 新建编辑器任务，在普通提示词中写出一个真实匹配文件，不要只将路径放在粘贴的代码块中。观察文档描述的条件规则通知，以及临时标记
TS-RULE-ACTIVE。 - 再新建一个处理
src之外 Markdown 文件的任务，先关闭匹配的 TypeScript 标签页，检查条件规则没有触发。 - 关闭可选规则，重复匹配任务，检查规则仍未激活。完成后恢复你需要的开关状态。
- 验收后删除规则中的临时标记要求，保留需要的代码约定。
标记只检查指令是否传达，不衡量代码质量。是否遵守规则，需要看真实差异和检查结果。规则即使加载，模型仍可能忽略或误解它。
排查规则未加载或意外触发
扩充规则库前，按以下顺序检查。
- 确认客户端和工作区根目录。Cloud 会话不加载这些文件。把子目录作为工作区打开，可能改变发现根规则的位置。
- 确认准确路径和开关。将非空 Markdown 文件直接放进
.clinerules/或.cline/rules/。检查disabled: true，以及全局规则、AGENTS.md中的冲突副本。 - 检查 YAML 分隔符和缩进，使用上面带引号的字符串数组。文档称无效 YAML 会按 fail-open 处理，但当前 SDK 解析器会在解析错误时抛错。直接修正语法，不要依赖任何一种回退行为。
- 检查上下文和 glob 范围。
src/*.ts不覆盖嵌套目录。新建任务，写明相对路径，并关闭无关的匹配标签页。文档规定paths: []不匹配任何文件，不要用空数组表示始终启用。 - 区分加载与遵守。如果可见规则已经加载，但修改仍违反指令，就缩短指令、消除冲突，再重跑小任务验收。记录客户端版本，不要据此断言所有 Cline 版本都有缺陷。
每次试验保存一份记录。
| 记录项 | 保存内容 |
|---|---|
| 环境 | 客户端及版本、仓库提交、服务商与准确模型标识 |
| 规则状态 | 文件名、规则提交或差异、开关、匹配路径 |
| 加载证据 | Rules 面板状态、可见时的条件通知、标记结果 |
| 任务证据 | 提示词、拟定范围、最终差异、无关修改 |
| 验收 | 完整检查命令及结果、人工修正、剩余失败 |
将规则作为项目文件审查维护
把共享规则与相关代码一起提交。规则修改需要审查者，并在变更说明中附上小任务验收方法。脚本、目录或约定变化时，在同一个拉取请求中更新规则。个人默认值放在全局位置，任何共享规则都不应包含凭据。
“Awesome .clinerules”合集可以提供思路，但导入前逐条检查。删除仓库中不存在的文件引用、不支持的命令、宽泛的自动批准要求，以及与任务冲突的指令。少量经过验收的指令更便于维护者审查。
如果正在迁移旧 Roo 规则，Roo 官方公告说明其扩展、Cloud 和 Router 已于 2026 年 5 月 15 日停运。按 Cline 重新表达原有意图，并重新验收。给旧 Roo 规则文件改名，不会迁移模式限制、权限或托管服务。Roo 迁移到 Cline 指南介绍迁移流程；如果需要选择仍在维护的客户端，参阅 Kilo Code 与 Cline 对比。
