Kiro Steering 指南

什么是 Steering？

Steering 通过 .kiro/steering/ 目录中的 markdown 文件为 Kiro 提供项目的持久化知识。与 Cursor 的 .cursorrules 等传统方法提供基本配置不同，Steering 代表了一种更先进、更复杂的 AI 助手上下文管理方式。虽然 .cursorrules 提供简单的基于规则的指导，但 Steering 提供了随代码库演进的全面、结构化和上下文化的项目知识。

Steering 与 .cursorrules 对比：

• Cursor 的 .cursorrules：带有基本规则的简单配置文件
• Kiro 的 Steering：具有条件加载、文件引用和结构化文档的高级基于 markdown 的知识系统

无需在每次聊天中解释您的约定，steering 文件确保 Kiro 始终遵循您已建立的模式、库和标准。

主要优势

一致的代码生成 - 每个组件、API 端点或测试都遵循您团队已建立的模式和约定。

减少重复 - 无需在每次对话中解释项目标准。Kiro 会记住您的偏好。

团队协调 - 所有开发者都使用相同的标准，无论他们是项目新手还是资深贡献者。

可扩展的项目知识 - 随着代码库增长的文档，捕获项目演进过程中的决策和模式。

默认 Steering 文件

Kiro 自动创建三个基础文件来建立核心项目上下文：

产品概述 (product.md) - 定义您产品的目的、目标用户、关键功能和业务目标。这帮助 Kiro 理解技术决策背后的"为什么"，并建议与您产品目标一致的解决方案。

技术栈 (tech.md) - 记录您选择的框架、库、开发工具和技术约束。当 Kiro 建议实现方案时，它会优先选择您已建立的技术栈而非替代方案。

项目结构 (structure.md) - 概述文件组织、命名约定、导入模式和架构决策。这确保生成的代码无缝融入您现有的代码库。

这些基础文件默认包含在每次交互中，形成 Kiro 项目理解的基线。

创建自定义 Steering 文件

flowchart TD
    A[导航到 Steering 部分] --> B[点击 + 按钮]
    B --> C[选择描述性文件名]
    C --> D[用 Markdown 编写指导]
    D --> E[选择精炼按钮]
    E --> F[Kiro 格式化内容]
    F --> G[Steering 文件就绪]

通过为您项目独特需求量身定制的专门指导来扩展 Kiro 的理解：

1. 导航到 Kiro 面板中的 Steering 部分
2. 点击 + 按钮创建新的 .md 文件
3. 选择描述性文件名（例如，api-standards.md）
4. 使用标准 markdown 语法编写您的指导
5. 用自然语言描述您的需求，然后选择 精炼 按钮，Kiro 将格式化内容

包含模式

Steering 文件可以配置为根据您的需求在不同时间加载。这种灵活性有助于优化性能并确保在需要时提供相关上下文。

通过在 steering 文件顶部添加前置内容来配置包含模式。前置内容使用 YAML 语法，必须放在文件最开始，用三个破折号（---）包围。

graph LR
    A[Steering 文件] --> B[始终包含]
    A --> C[条件包含]
    A --> D[手动包含]
    
    B --> B1[核心标准]
    B --> B2[技术栈]
    B --> B3[编码约定]
    
    C --> C1[文件模式匹配]
    C --> C2[特定域规则]
    
    D --> D1[按需加载]
    D --> D2[专门上下文]

始终包含（默认）

这些文件会自动加载到每个 Kiro 交互中。对于应该影响所有代码生成和建议的核心标准使用此模式。示例包括您的技术栈、编码约定和基本架构原则。

最适合：项目范围的标准、技术偏好、安全策略和普遍适用的编码约定。

条件包含

文件仅在处理匹配指定模式的文件时自动包含。这通过仅在需要时加载专门指导来保持上下文相关性并减少噪音。

常见模式：

• "*.tsx" - React 组件和 JSX 文件
• "app/api/**/*" - API 路由和后端逻辑
• "**/*.test.*" - 测试文件和测试工具
• "src/components/**/*" - 组件特定指南
• "*.md" - 文档文件

最适合：特定域标准，如组件模式、API 设计规则、测试方法或仅适用于特定文件类型的部署程序。

手动包含

通过在聊天消息中使用 #steering-file-name 引用文件来按需提供。这让您精确控制何时需要专门上下文，而不会使每次交互变得混乱。

用法：在聊天中输入 #troubleshooting-guide 或 #performance-optimization 来为当前对话包含该 steering 文件。

最适合：专门工作流程、故障排除指南、迁移程序或仅偶尔需要的上下文密集文档。

文件引用

链接到实时项目文件以保持 steering 当前：

示例：

• API 规范：#[[file:api/openapi.yaml]]
• 组件模式：#[[file:components/ui/button.tsx]]
• 配置模板：#[[file:.env.example]]

最佳实践

保持文件专注 - 每个文件一个域 - API 设计、测试或部署程序。

使用清晰的名称

• api-rest-conventions.md - REST API 标准
• testing-unit-patterns.md - 单元测试方法
• components-form-validation.md - 表单组件标准

包含上下文 - 解释为什么做出决策，而不仅仅是标准是什么。

提供示例 - 使用代码片段和前后对比来演示标准。

安全第一 - 永远不要包含 API 密钥、密码或敏感数据。Steering 文件是代码库的一部分。

定期维护

• 在冲刺规划和架构变更期间审查
• 重构后测试文件引用
• 像对待代码变更一样对待 steering 变更 - 需要审查

常见 Steering 文件策略

API 标准 (api-standards.md) - 定义 REST 约定、错误响应格式、认证流程和版本策略。包括端点命名模式、HTTP 状态码使用和请求/响应示例。

测试方法 (testing-standards.md) - 建立单元测试模式、集成测试策略、模拟方法和覆盖率期望。记录首选测试库、断言样式和测试文件组织。

代码风格 (code-conventions.md) - 指定命名模式、文件组织、导入排序和架构决策。包括首选代码结构、组件模式和要避免的反模式示例。

安全指南 (security-policies.md) - 记录认证要求、数据验证规则、输入清理标准和漏洞预防措施。包括特定于您应用程序的安全编码实践。

部署流程 (deployment-workflow.md) - 概述构建程序、环境配置、部署步骤和回滚策略。包括 CI/CD 管道详细信息和环境特定要求。

案例研究：语言偏好配置

这是如何配置 Kiro 使用中文响应的实际示例：

文件：language-preferences.md

## 沟通指南

- Kiro 使用中文输出
- 前端页面内容使用英文
- 代码注释使用中文

实施说明

此配置确保在开发工作流程的不同方面使用一致的语言，同时为每个上下文保持适当的语言选择。