Kiro Steering 指南
Steering 通过 `.kiro/steering/` 目录中的 markdown 文件为 Kiro 提供项目的持久化知识。与 Cursor 的 `.cursorrules` 等传统方法提供基本配置不同，Steering 代表了一种更先进、更复杂的 AI 助手上下文管理方式。虽然 `.cursorrules` 提供简单的基于规则的指导，但 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 文件
通过为您项目独特需求量身定制的专门指导来扩展 Kiro 的理解：
- 导航到 Kiro 面板中的 Steering 部分
- 点击 + 按钮创建新的
.md文件 - 选择描述性文件名（例如，
api-standards.md） - 使用标准 markdown 语法编写您的指导
- 用自然语言描述您的需求，然后选择 精炼 按钮，Kiro 将格式化内容
包含模式
Steering 文件可以配置为根据您的需求在不同时间加载。这种灵活性有助于优化性能并确保在需要时提供相关上下文。
通过在 steering 文件顶部添加前置内容来配置包含模式。前置内容使用 YAML 语法，必须放在文件最开始，用三个破折号（---）包围。
始终包含（默认）
这些文件会自动加载到每个 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 使用中文输出
- 前端页面内容使用英文
- 代码注释使用中文
实施说明
此配置确保在开发工作流程的不同方面使用一致的语言，同时为每个上下文保持适当的语言选择。
浙公网安备 33010602011771号