Kiro 的规格写得漂亮但后面做不动，问题多半出在“需求像愿望，任务像标题”。规格驱动开发真正有用的地方，不是生成一份文档，而是把需求、设计、任务和验收标准串起来，让每一步都能被检查。

需求先写用户行为，不写抽象目标

“提升搜索体验”不是一个好规格，因为 AI 很难判断做到什么程度算完成。换成“用户输入关键词后，列表在 300ms 内展示匹配结果；无结果时显示空状态；清空输入后恢复默认列表”，就容易落地得多。Kiro 的 Specs 文档强调围绕需求、设计和任务推进，关键是每个需求都能对应到可验证行为。

设计阶段要暴露取舍

如果规格里只有最终方案，没有说明数据来源、状态边界、错误处理和不做什么，生成任务时就会变成一串泛泛的开发项。设计段可以写得短，但要回答四件事：用哪个现有模块、是否需要新增接口、失败状态如何处理、哪些旧逻辑保持不变。这些取舍会决定后面的任务是否准确。

任务不要只写“实现某功能”

一个可执行任务至少要包含改动范围、完成条件和验证方式。例如“在搜索组件内增加防抖输入，保持现有筛选 API 不变；新增空状态；运行相关组件测试”。如果任务拆完仍然需要开发者猜路径、猜状态、猜测试命令，就说明规格还没写到位。

卡住时先补验收，不要重生成整份规格

很多人一卡住就让 Kiro 重写规格，结果越写越长。更好的做法是回到卡住的那一条任务，补充验收条件：用户能看到什么、接口返回异常怎么办、如何证明没有影响旧功能。规格驱动开发不是为了让文档更完整，而是为了让实现过程少猜测、少返工。