Appearance
Steering 是 Kiro 的"项目记忆"机制：把技术栈、代码规范、架构决策写成 Markdown 文件放进 .kiro/steering/ 目录，Kiro 就会在每次对话中自动加载这些上下文。你不再需要每次都告诉 AI "我们用 TypeScript、用 Zod 做校验、用 Conventional Commits"——Steering 文件帮你记住这一切，并确保团队所有成员获得一致的 AI 辅助体验。
什么是 steering
Steering 通过 .kiro/steering/ 目录下的 Markdown 文件给 Kiro 持久化的项目知识。你不需要在每次对话中重复说明项目规范，steering 文件确保 Kiro 始终遵循你已建立的代码模式、库选择和团队标准。
核心价值
代码生成一致性 — 每个组件、API 端点或测试用例都遵循团队既有模式和规范。
消除重复沟通 — 无需在每次对话中解释项目标准，Kiro 会记住你的偏好。
团队对齐 — 无论是刚加入的新人还是资深贡献者，所有人使用相同的标准工作。
项目知识可扩展 — 随代码库成长的文档，随着项目演进持续记录决策和模式。
Steering 文件的作用域
工作区 steering
工作区 steering 文件存放在项目根目录的 .kiro/steering/ 下，只作用于该工作区。适合用于记录单个项目专属的代码模式、库选择和规范。
全局 steering
全局 steering 文件存放在家目录的 ~/.kiro/steering/ 下，作用于所有工作区。适合记录跨项目通用的个人偏好和惯例。
当全局和工作区 steering 指令冲突时，Kiro 优先采用工作区 steering。这让你可以设置全局默认值，同时保留针对特定项目覆盖的能力。
团队 steering
全局 steering 机制也可用于定义适用于整个团队的集中式 steering 文件。团队 steering 文件可通过 MDM 或组策略推送到成员电脑，或由成员从中央仓库下载后放入 ~/.kiro/steering/ 文件夹，Kiro 会自动识别。
基础 steering 文件
建议创建以下三个基础 steering 文件来建立核心项目上下文：
- 在项目根目录创建
.kiro/steering/文件夹（全局则用~/.kiro/steering/） - 添加项目标准的 Markdown 文件
- Kiro 会在对话时自动加载这些文件
产品概述（product.md） — 定义产品目标、目标用户、核心功能和业务目标，帮助 Kiro 理解技术决策背后的"为什么"，从而给出与产品方向一致的建议。
技术栈（tech.md） — 记录选用的框架、库、开发工具和技术约束。Kiro 在给出实现方案时会优先使用你已有的技术栈，而不是推荐替代品。
项目结构（structure.md） — 描述文件组织方式、命名规范、导入模式和架构决策，确保生成的代码能无缝融入现有代码库。
这三个基础文件默认包含在每次对话中，构成 Kiro 理解项目的基线。
创建自定义 steering 文件
根据项目特定需求扩展 Kiro 的知识：
- 在
.kiro/steering/中新建.md文件 - 选择描述性文件名（如
api-standards.md） - 用标准 Markdown 语法写下你的指导规范
- 用自然语言描述你的要求即可
在自定义 agents 中使用 steering
使用自定义 agents 时，steering 文件不会自动加载，需要在 agent 的 resources 配置中显式添加：
json
{
"resources": ["file://.kiro/steering/**/*.md"]
}这个 glob 模式确保 steering 目录中所有 Markdown 文件在使用该 agent 时都会加载。完整配置示例参考自定义 agents 文档。
AGENTS.md 兼容支持
Kiro 支持 AGENTS.md 标准的 steering 指令。AGENTS.md 格式与 Kiro steering 文件相同，区别是 AGENTS.md 文件始终会被加载。
可以把 AGENTS.md 放在全局 steering 目录（~/.kiro/steering/）或工作区根目录，Kiro 会自动识别。
最佳实践
单文件单领域 — 每个文件只覆盖一个领域，如 API 设计、测试策略或部署流程，避免把所有内容堆在一个文件里。
使用清晰的文件名：
api-rest-conventions.md— REST API 规范testing-unit-patterns.md— 单元测试方法components-form-validation.md— 表单组件规范
解释决策背景 — 不只写"怎么做"，还要写"为什么这样做"，让 Kiro 和团队成员都能理解规范的意图。
提供示例 — 用代码片段和前后对比示例来演示规范，比纯文字描述更有效。
绝不包含敏感信息 — steering 文件是代码库的一部分，绝对不能写 API key、密码或其他敏感数据。
定期维护：
- 在迭代计划和架构评审时更新 steering 文件
- 重构后检查文件引用是否仍然有效
- 把 steering 变更当作代码变更对待，需要代码审查
常见 steering 文件策略
API 规范（api-standards.md） — 定义 REST 规范、错误响应格式、认证流程和版本策略。包含端点命名模式、HTTP 状态码用法和请求/响应示例。
测试方法（testing-standards.md） — 建立单元测试模式、集成测试策略、Mock 方法和覆盖率要求。记录首选测试库、断言风格和测试文件组织方式。
代码风格（code-conventions.md） — 规定命名模式、文件组织、导入排序和架构决策。包含首选代码结构、组件模式的示例，以及应避免的反模式。
安全规范（security-policies.md） — 记录认证要求、数据校验规则、输入净化标准和漏洞预防措施。包含针对当前应用的安全编码实践。
部署流程（deployment-workflow.md） — 描述构建步骤、环境配置、部署步骤和回滚策略。包含 CI/CD 流水线细节和各环境特定要求。
自定义 steering 文件存放在 .kiro/steering/，在所有 Kiro CLI 对话中立即生效。
常见问题
Q：steering 和 skills 有什么区别？
A：两者服务于不同目的。Steering 提供项目背景知识（技术栈、规范、架构决策），始终作为背景上下文存在。Skills 则是针对特定工作流的可执行指令包（PR 审查清单、部署步骤），按需触发。日常来说，steering 让 Kiro"了解你的项目"，skills 让 Kiro"知道怎么做某件事"。
Q：steering 文件会占用多少上下文窗口？
A：基础 steering 文件（product.md、tech.md、structure.md）默认包含在每次对话中，其他自定义文件按需加载。建议保持 steering 文件简洁，聚焦关键决策，避免把每个细节都塞进去，以免浪费上下文空间。
Q：新加入团队成员需要手动配置 steering 文件吗？
A：不需要。工作区 steering 文件存放在 .kiro/steering/ 并纳入版本控制，克隆仓库后 Kiro 自动识别。全局 steering 和团队 steering 可通过 MDM 或让成员手动下载到 ~/.kiro/steering/ 完成配置。