ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">就在上周，AWS 正式发布了号称“Spec‑Driven AI IDE”的 Kiro：它先用智能代理把一句自然语言需求拆解成结构化的 Requirements、Design 和 Tasks 三份规格文档，再驱动代码生成与变更管理，让开发流程从 “Prompt → Spec → 代码” 一键闭环，几乎不留人工漏斗。更酷的是，Kiro 内建的 Agent Hooks 会在文件保存、创建或删除时自动触发安全扫描、测试生成或文档更新，像一位隐形的资深工程师在后台补齐每一个细节——这被业界视为终结 “vibe coding” 混沌时代、把 AI 代码助手真正推向生产级的关键一步ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;display: table;padding: 0px 1em;color: rgb(63, 63, 63);">一、Spec工作流ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;padding-left: 8px;color: rgb(63, 63, 63);">1. Spec工作流简介ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">传统 AI 编码助手习惯直接跳到写代码，容易遗漏需求、不统一风格，语义与上下文混乱。Kiro 的 规划阶段 借助 spec 文件，让 LLM 在动手之前就 fully 理解问题，从而增强一致性与准确性。在 Kiro 中，Spec 会话 会将你的高层需求拆解成三个有版本控制的 Markdown 文件：WHEN … THEN THE SYSTEM SHALL …），格式化清晰，易于测试；•design.md是技术方案蓝图，包括组件描述、架构图（序列图/C4 图）、技术选型与折衷说明；•tasks.md是具体执行计划，以任务列表形式呈现，可供agent执行并追踪。
Kiro 会先通过聊天提问澄清细节，生成并维护这三个文件，然后在将来的每次代码生成、测试、搭建基础设施时引用它们作为上下文指导。你可以在聊天中点击Spec按钮（或输入“Generate spec”）启动该流程，通过编辑 Markdown 文件或点击“优化/更新”任务进行迭代，在 Autopilot 模式中执行计划。最终结果是“动态文档”，它与代码保持同步，同时为agent提供精准的指导。2. Spec工作流最佳实践：- • 保持任务粒度小：将大功能拆成多个目录，提升灵活性与响应速度
- • 配合 Steering 配置：在 .kiro/steering 中定义代码规范，确保生成结果符合团队标准
- • 将 spec 文件推入版本控制：它们成为实时文档和架构决策的记录
- • 初期建议使用 Supervised 模式：先手动审核前几次差异，确保生成计划与预期一致
- • 必要时使用 MCP Server：让 spec 会话引用外部知识库或文档（如 AWS、GCP 文档等）
二、Spec工作流的运行时层在 Kiro 项目根目录下有一份.kiro/spec.yml文件，这是一份“元数据说明书”：它用 YAML 列出一个 Spec 的基础信息（名称、阶段状态、负责人、标签、时间戳等），并将该 Spec 与旁边自动生成的 requirements.md → design.md → tasks.md三大文档串联起来。Kiro 在 IDE 里据此判断「此 Spec 处于哪个阶段、哪些人已审批、哪些任务已完成」，从而驱动工作流、权限控制、对话上下文加载以及后续的自动化 Hook。 1.Spec.yml 存在的背景与作用 | | | | 产品/架构元数据源 | 存放 Spec 的 ID、标题、描述、当前阶段(phase)、优先级、标签等 | | | 审批与状态跟踪 | 记录各阶段(requirements,design,tasks)是否approved:true/false，以及批准人、日期 | 阶段完成后在 Kiro 面板点 ✅ 或用/spec-approve | | 工作流协调器 | Kiro 读这里的状态来决定：
• 打开 Spec 聊天时要不要加载requirements.md
• 是否允许跳到下一阶段
• Hook/CI 是否触发 | | | 权限与可见性 | 可选字段visibility:private/team/public控制共享范围 | |
2. 目录结构my-project/
└─ .kiro/
├─ spec.yml ← 元数据
├─ requirements.md ← EARS 用户故事
├─ design.md ← 架构 & 时序图
└─ tasks.md ← 可执行任务清单
这种「单 Spec 四文件」布局在官方文档“Specs → Concepts”中被称为 Kiro 的三阶段工作流核心。
spec.yml放在同级，方便 YAML ↔ Markdown 相互引用（Kiro 允许在 Markdown 里用#[[file:spec.yml]]链接，反过来spec.yml里可写design: design.md）。 3. Kiro 如何利用 spec.yml- • 加载上下文
打开 Spec 聊天时，Kiro 根据phase决定默认引入哪些文件到模型上下文——例如处于design 阶段时会携带requirements.md + design.md，而不是tasks.md。 - • 权限闸门
未通过approvals.requirements时，IDE 会阻止 “Generate design” 命令，防止跨阶段 “快跑”。 - • 仪表盘与过滤
侧边栏 “Specs” 按priority和status排序；筛选器读取tags 实现一键过滤。 - • Hook 触发
当phase 变为execution且linked_hooks 中包含unit-test-gen时，保存任意文件即可触发对应 Hook 自动生成测试覆盖。 - • CI / ChatOps
Kiro CLI (kiro check-spec) 在 CI 中解析spec.yml，阻断未完成审批的合并请求。
三、agent Hooks功能Kiro 的 Agent Hooks 功能是一个高度智能化的自动触发器，允许你在 IDE 中定义“事件 → 代理动作”的规则。一旦发生指定事件（如保存、创建、删除文件或手动触发），Kiro 就会根据你的自然语言指示自动执行相关动作，比如生成测试、更新文档或进行安全扫描。Hook 的目的是解放你重复的工作，让代码质量和团队流程更一致。 1. 功能总览在 Kiro 中，Agent Hooks 就像“AI 版 Git hooks”：它们监听文件保存、创建、删除或手动触发等事件，把一段自然语言指令送给代理执行，从而自动完成测试生成、安全扫描、文档同步、Git 提交等重复工作，大幅提升一致性与开发效率。
Kiro 的 Hook 引擎由“事件检测 → 指令注入 → 代理执行”三步组成，只要事件被捕获，预设提示就会加入模型上下文并立即运行。
支持四类触发器： - On File Create（文件新建）
- On File Save（文件保存）
- On File Delete（文件删除）
- Manual Trigger（手动运行按钮）
2. 常用场景示例 | | | | 单元测试同步 | On File Save | 找到新增函数→若无对应测试则生成→运行测试并更新覆盖率。 | | 安全预提交扫描 | On File Save | | | 自动生成文档 | Manual Trigger | 对当前文件抽取 API 注释→更新 README/文档站点。 | | Git Commit 助手 | On File Save | |
3. 最佳实践- • 专事专钩：每个 Hook 只做一件事，指令写清楚且具体。
- • 按需限域：用精确的文件模式避免全仓大扫，减少性能开销。
- • 先小范围验证：在示例仓库测试，通过后再推到主分支。
- • 与 Steering / Spec 配合：Steering 约束生成风格，Spec 提供功能蓝图，Hook 负责落地自动化，三者组合效果最佳。
- • 版本控制 Hook 配置：把
.kiro/hooks/或导出的 JSON 存入 Git，确保团队共享。
四、agent steering功能Kiro 的 Agent Steering 为 IDE 中的智能代理提供「长期记忆」：它把项目愿景、技术栈、目录结构、团队规范等写进 .kiro/steering/*.md 文件，并在每一次对话或代码生成时按规则自动注入这些内容，从而让 Kiro 的输出始终符合你的业务上下文、代码风格和安全要求。启用方式很简单——在命令面板执行“Kiro: Setup Steering for Project”即可生成默认文件，然后按需补充或细化。 1. 功能定位传统 AI 编码助手缺乏项目级“制度记忆”，往往导致风格不一致、隐性需求被忽略，甚至生成无法维护的“vibe code”。Kiro 通过持久化的 Steering 文档，把产品目标、架构决策、代码规范等硬约束随时送进模型上下文，确保生成结果始终遵循团队标准。 2. 目录结构与默认文件执行“Kiro: Setup Steering for Project”后，Kiro 会在工作区根目录创建隐藏文件夹： .kiro/
└─ steering/
├─ product.md # 产品愿景、核心功能、目标用户
├─ structure.md # 目录组织、命名约定、分层策略
└─ tech.md # 技术栈、依赖版本、工具链
这些文件为每条提示提供统一上下文，可随时手动编辑或删除。
product.md描述业务目标、业绩指标、用户画像。
structure.md编写目录布局、分层模式、命名规范。
tech.md固定语言版本、框架、Lint/测试策略。
对于特殊需求，新增文件并写入 front‑matter。保存后即刻生效。
运行Kiro: Regenerate Steering可让 Kiro 重新扫描项目并更新文档。也可在聊天中直接让 Kiro“update tech.md to include Python 3.12”等自然语言指令，它会打开并写入改动。
此后每次 聊天、Spec 生成或 Autopilot 代码改动，Kiro 会根据 inclusion 规则把相应片段加到系统提示里，无需额外说明。 3. 控制注入范围每个 Steering 文件顶部使用 YAML Front‑Matter 控制注入范围：
inclusion: always，无条件注入所有请求，典型场景：通用代码规范
inclusion: fileMatch+fileMatchPattern，仅当编辑文件路径符合 glob 时注入，典型场景：仅对components/**/*.tsx生效的 React UI 指南
inclusion: manual，默认不注入，聊天时用 #文件名 手动引用，典型场景：迁移/故障排查文档 Kiro 以 Spec‑Driven 开发 与 Agent Hooks 把「先规划、后编码、持续治理」的理念真正落地：它先用三份结构化 Markdown 规格文件将需求、设计与任务固化为项目的单一可信源，并在 VS Code 分支的预览版中将自动单测、文档同步、安全扫描等 Hook 动作融入保存、创建、删除等 IDE 事件，彻底终结 vibe‑coding 带来的设计漂移和技术债——这一点已被行业媒体与开发者视为 AI IDE 演进的拐点。
|
