Appearance
Bugfix Specs 模拟有经验开发者处理 Bug 的方式：识别根本原因、明确需要改变的内容，并显式保留不应改变的行为。通过 bugfix.md 记录当前（错误）行为、预期（正确）行为和不变行为，Kiro 生成带属性测试的实现任务，同时验证修复效果和回归预防。适合关键路径 Bug、多次修复失败的历史 Bug 或需要合规留档的场景。
什么是 Bugfix Specs？
Bugfix Specs 模拟有经验的开发者处理 Bug 的方式：识别根本原因，明确哪些内容需要改变，并显式保留哪些不应改变。通过结构化工作流，Bugfix Specs 引导你完成根本原因分析、修复设计和回归预防，确保手术式、可靠的修复。
核心优势
精确修复：明确约束确保只做必要改动
回归预防：不变行为被文档化并通过测试验证
留档记录：完整记录 Bug、修复方案和决策依据，供后续参考
可靠性：结构化工作流避免临时修复的常见陷阱
适用场景
Bugfix Specs 最适合：
- 需要根本原因分析的复杂 Bug
- 关键代码路径上代价高昂的 Bug
- 需要合规或团队知识留存文档的 Bug
- 之前修复尝试导致回归的情况
工作原理
Bugfix Specs 遵循与 Feature Specs 相同的三阶段工作流（需求 → 设计 → 任务），但内容专为精确 Bug 修复量身定制。
第一阶段：Bug 分析
创建 bugfix.md，记录以下三类行为：
当前行为（缺陷）
WHEN [触发条件] THEN 系统 [错误行为]预期行为（正确）
WHEN [触发条件] THEN 系统 SHALL [正确行为]不变行为（回归预防）
WHEN [触发条件] THEN 系统 SHALL CONTINUE TO [现有行为]这种显式结构确保 Kiro 不只知道哪里坏了，还清楚哪些必须继续正常工作。
第二阶段：设计
Kiro 探索代码库，定位问题根源，并生成 design.md，包含：
- 根本原因分析
- 建议的修复方案
- 需要测试的属性：
- 当前实现产生错误行为（验证 Bug 确实存在）
- 修复后实现产生正确行为（验证修复有效）
- 不变实现继续正常工作（防止回归）
第三阶段：任务
生成带属性测试（PBTs）的实现任务，验证以下三点：
- Bug 可以被复现
- Bug 已被修复
- 没有引入回归
快速开始
- 在聊天框中选择 Spec
- 描述 Bug，包括：
- Bug 触发的时机（复现步骤）
- 应有的正确行为
- 任何约束（不应被修改的代码）
- Kiro 询问意图时选择 Bugfix
- 跟随分析、设计、实现三个阶段完成修复
进一步学习
- 属性测试与正确性验证 — 了解 PBT 如何验证修复的正确性
- 最佳实践 — Bugfix Specs 使用技巧与常见问题解答
- Feature Specs — 新功能开发的结构化流程
常见问题
Q：Bugfix Spec 和直接在聊天里修复 Bug 有什么区别？
直接对话修复适合简单、已充分理解的问题（如拼写错误、单行逻辑修复）。Bugfix Spec 适合根本原因不明显、之前修复失败过、或位于关键路径需要文档留存的 Bug。结构化工作流强制进行根本原因分析，并通过属性测试提供更强的正确性保证。
Q：bugfix.md 中的"不变行为"是必须填写的吗？
强烈建议填写。"不变行为"是 Bugfix Spec 的核心价值所在——Kiro 会据此生成属性测试，确保修复不会破坏现有功能。如果跳过这部分，就失去了系统性防回归的能力。
Q：根本原因分析发现需要大量重构，该怎么办？
如果分析发现修复需要引入重大新功能，建议为新工作单独创建 Feature Spec，让 Bugfix Spec 聚焦在最小必要修复上。这样可以保持修复的精确性，同时通过独立 Spec 管理更大范围的改动。