AWS旗下的代理式AI开发环境Kiro，针对既有应用的维护与调试场景，扩展其规格导向开发功能Specs，新增技术设计优先（Tech Design-first）与错误修复（Bugfix）两种工作流程。开发者在既定架构或高回归风险的前提下，可通过结构化文档与测试来限定代理的改动范围，避免代理误改已有正确代码。

AWS指出，过去Specs流程主要对应传统产品经理与工程师协作的步骤，先写需求、再做设计，最后拆解任务，适合从零开始的新项目。但在已有代码库上新增功能或修复缺陷时，开发者往往已具备明确的技术路径或既定限制，若仍强制从需求出发，容易浪费时间反复对齐，甚至导致代理在理解不足时扩大改动范围。

技术设计优先流程

Kiro在Specs中新增了技术设计优先流程，允许开发者在撰写规格时，不必从需求出发，而是可以从现有技术设计入手。Kiro会首先生成设计文档，用户可根据高层或底层设计反复迭代，确认组件选型与关键技术取舍后，再由设计反向推导出需求与后续任务。

错误修复流程

Kiro的另一项更新是错误修复工作流程，将调试过程中所需的变更边界写入规格文档，要求用户不仅描述错误信息，还需说明触发条件与上下文，并明确标注哪些行为必须保持不变。错误修复的规格文档包含三部分内容：当前行为（Current Behavior），说明当前何时会出现问题；预期行为（Expected Behavior），定义修复后应达成的结果；不变行为（Unchanged Behavior），界定原有正确流程不得被影响的部分。

AWS强调，系统会依据当前行为、预期行为与不变行为三类描述，自动生成属性导向测试（Property-based Testing），以更系统化的方式验证修复是否生效，并降低回归风险。这些测试一方面用于确认当前版本能够复现问题，另一方面验证修复后符合预期，同时确保不变行为未被破坏。

官方引用软件工程研究者Laurence Tratt关于规格的循环困境（Circular Specification Problem）与观察者效应（Observer Effect）的讨论，主张软件需求与实现往往需要在迭代中逐步收敛，工具设计不应假设一开始就能完整定义所有需求。因此，Kiro此次扩展了原本仅限需求优先的单一模式，新增了技术设计优先与错误修复两种工作流程。