在AI辅助编程工具日益普及的今天，Kiro作为一款新兴的智能编辑器，通过灵活的规则配置让AI更好地理解开发者的习惯和项目需求。与Cursor等工具不同，Kiro目前采用文件化的规则管理方式，没有提供图形界面，但这也带来了更高的可定制性和版本控制友好性。本文将详细介绍Kiro的全局规则与项目规则设置方法，并通过分步说明和原理流程图帮助你快速上手。

一、理解Kiro的规则体系

全局规则是指适用于所有项目的通用性指令或偏好设定。一旦配置完成，无论在哪个项目中与 AI 交互，这些规则都会持续生效。
项目规则：存放在特定项目根目录下的规则文件，用于覆盖或补充全局规则，满足单个项目的特殊需求（如测试框架、代码风格例外等）。

典型的全局规则包括：

• 语言偏好（如“请使用中文回复”）
• 注释风格（如“函数级注释”）
• 操作系统适配（如“我的系统是 macOS”）

Kiro 的全局规则存储在一个名为 global-steering.md 的文件中，位于用户配置目录下。这一点与 Cursor 的图形化界面不同，Kiro 更倾向于文件即配置的方式，便于版本管理和迁移。

二、全局规则的存放路径

Kiro的全局规则文件名为global-steering.md，不同操作系统的默认路径如下：：

操作系统	路径
Windows	%APPDATA%\Kiro\global-steering.md
macOS	~/Library/Application Support/Kiro/global-steering.md
Linux	~/.config/Kiro/global-steering.md

你可以通过环境变量或直接导航到上述文件夹确认路径是否存在。如果Kiro文件夹不存在，可以手动创建。

三、如何设置全局规则？

方法一：手动创建与编辑

1. 根据你的操作系统，找到对应的配置目录。
2. 如果不存在 global-steering.md 文件，请手动创建。
3. 使用任何文本编辑器打开，写入你希望 AI 遵循的规则。例如：

# 全局开发规范与习惯

- 请保持对话语言为中文
- 我的系统为 macOS
- 请在生成代码时添加函数级注释
- 使用4个空格进行缩进
- 变量命名采用驼峰式

4. 保存文件后，重启 Kiro 或新建对话即可生效。

方法二：自动生成规则文件

如果你希望 AI 根据你的历史项目习惯自动生成规则，可以通过对话提示实现：

输入提示词：

请基于我所有项目的通用习惯，生成一份全局规则文件 global-steering.md，保存在 Kiro 的用户配置目录。

AI会自动分析你的项目历史（如果Kiro有访问权限）或根据常见最佳实践生成一份规则文件，并保存到正确的位置。你之后可以手动修改该文件，添加或删除规则。

四、项目级规则的配置

除了全局规则，Kiro 还支持项目级规则，用于覆盖或补充当前项目的特定需求。

项目级规则通常存放在项目根目录下的 .kiro/steering.md 文件中。

示例：创建功能测试规则

你可以在对话中输入以下提示词，让 AI 自动生成项目级规则文件：

输入提示词：

帮我在当前项目根目录下创建 .kiro/steering.md，并自动创建功能测试用例规则。

AI 会生成如下内容示例（可根据需要调整）：

---
inclusion: manual
---

# 功能测试用例生成规则

## 一、测试用例设计方法

在生成功能测试用例时，必须综合运用以下测试设计方法：

### 1. 等价类划分法
- 将输入数据划分为有效等价类和无效等价类
- 每个等价类至少设计一个测试用例
- 有效等价类：符合需求规格的输入数据集合
- 无效等价类：不符合需求规格的输入数据集合

### 2. 边界值分析法
- 测试边界值及其附近的值
- 包括：最小值、最大值、最小值-1、最大值+1
- 关注输入和输出的边界条件
- 特别注意临界点的处理
。。。。。。

五、原理流程图

为了更好地理解 Kiro 规则的工作机制，下图展示了从规则配置到 AI 响应的流程：

---

六、同项目多规则如何设置

在实际项目开发中，我们往往需要管理多种类型的规则，比如功能测试规范、接口测试规范、UI测试规范等。Kiro 支持通过主入口文件 + 模块化规则文件的方式，实现规则的分类管理。

6.1 Kiro 的硬性约定

在开始配置之前，需要了解 Kiro 的两个关键约定：

约定项	说明
主入口固定名	项目级规则的主入口文件必须命名为 .kiro/steering.md，不可更改
模块文件命名	推荐使用 rules-*.md 或 steering-*.md 的命名方式，便于识别和管理

6.2 规则拆分示例

假设你的项目结构如下：

.kiro/
├── steering.md                # 主入口（固定名）
├── rules-functional-test.md    # 功能测试用例规则
├── rules-api-test.md           # 接口测试用例规则
└── rules-ui-test.md            # UI/E2E测试规则（可选）

6.3 配置步骤

步骤1：创建主入口文件

在项目根目录下创建 .kiro/steering.md 文件。

步骤2：创建模块规则文件

根据实际需求，在 .kiro/ 目录下创建多个规则文档，如 rules-functional-test.md、rules-api-test.md 等。

注意：文件的显示顺序不影响解析结果。只要 steering.md 存在且正确配置了导入指令，Kiro 会自动解析所有被引用的规则文件。

步骤3：编写规则内容

在每个模块规则文件中写入对应的规范内容。例如：

rules-functional-test.md

# 功能测试用例规则

- 每个功能模块需至少包含一个正向测试用例
- 异常场景测试用例覆盖率不低于80%
- 测试用例命名格式：test_[功能名]_[场景描述]

rules-api-test.md

# 接口测试用例规则

- 所有API接口需测试状态码200、400、401、500
- 参数校验测试需包含：必填校验、类型校验、边界值校验
- 敏感接口需添加权限测试用例

步骤4：在主入口统一导入

在 steering.md 文件顶部，使用 @import 指令引入所有模块规则文件：

# 项目级规则主入口

@import "./rules-functional-test.md"
@import "./rules-api-test.md"
@import "./rules-ui-test.md"

## 通用开发规范
- 代码缩进使用4个空格
- 变量命名采用驼峰式
- ...

6.4 规则的使用方式

配置完成后，在对话中使用规则的方式与 Cursor 类似：

1. 直接引用规则文件：在对话中提及规则文件名或内容关键词
2. 结合项目上下文：AI 会自动读取 steering.md 及其导入的所有规则文件
3. 动态调整：可以在对话中临时指定使用哪些规则，例如“请按照功能测试规则为这个接口编写测试用例”
   pro.md为需求内容：
   
   引用按照既定的用例生成规则，根据需求发送生成用例的指令：
   

按照规则生成的用例效果如下：

6.5 多规则管理的优势

• 分类清晰：不同类型的规则分开管理，便于维护
• 复用性强：可以在多个项目间共享通用的规则模块
• 按需加载：对话中可以根据需求指定使用哪些规则，避免信息过载
• 团队协作：不同角色（开发、测试、运维）可以各自维护自己关注的规则文件

通过这种模块化的规则配置方式，你可以像管理代码一样管理项目规范，让 AI 辅助更加精准、高效。

---

七、拓展内容：规则的最佳实践

1. 规则分层管理

建议将通用习惯放入全局规则，将项目特有规范放入项目规则，避免重复配置，也便于团队共享。

2. 使用 Markdown 结构化

规则文件采用 Markdown 格式，建议使用标题、列表、代码块等结构，便于 AI 解析和理解。

3. 结合团队规范

如果团队有统一的代码风格或文档标准，可以将这些内容写入项目级规则，确保所有成员在使用 AI 时遵循一致标准。

4. 定期回顾与优化

随着项目演进，规则也需同步更新。建议每季度回顾一次规则文件，删除过时内容，补充新需求。

结语

Kiro 的规则设置虽然目前以文件配置为主，但其灵活性和可控性为开发者提供了更精细的 AI 行为引导能力。通过合理配置全局与项目规则，你可以让 AI 更贴合你的开发习惯，从而提升编码效率与代码质量。

如果你还未尝试过 Kiro 的规则配置，不妨从今天开始，为你的编辑器“定制”一个懂你的 AI 助手吧！

---