我们正迎来「新代码」时代，而这份「新代码」，不是你我熟知的程序语言，而是 「规范」（Specification，下文简称 Spec）。

Claude Code + Kiro Spec：别急着生成代码，先让AI理解你的需求

最近在研究Kiro的时候，发现了一个很有意思的现象。Kiro的spec功能设计得很直接，你说"我要做个评论系统"，它就直接生成requirements、design和tasks三个文件。

但真正执行之后，我发现一个问题：直接从需求到spec，生成的内容往往差强人意。不是需求理解偏差，就是设计过于粗糙。

这让我想起了传统开发中的一个痛点：需求不清楚就开始写代码，最后做出来的东西完全不是用户想要的。

问题的根源：直接toSpec的陷阱

传统开发中的教训

还记得我之前分享的那套软件工程流程吗？需求分析(/ask) → 代码实现(/code) → 测试用例(/test) → 代码审查(/review) → 优化调整(/optimize, /refactor)。

这套流程的核心逻辑很简单：先把需求搞清楚，再写代码，最后验证。但实际操作中，大部分团队都是直接上手写代码，需求文档要么没有，要么写完就束之高阁。

在传统软件开发中，我们都知道一个道理：需求分析是整个项目的基石。如果需求都没搞清楚，后面的设计和实现再精美也是空中楼阁。

我见过太多这样的场景：

• 产品经理甩过来一个模糊的需求文档
• 开发直接开始写代码
• 结果做出来的东西完全不是用户想要的

这种情况下，即使技术实现再完美，最终也是徒劳。

AI开发中的相同问题

现在到了AI辅助开发的时代，同样的问题依然存在。

很多人使用Kiro的时候，流程是这样的：

需求 → 直接spec → 生成requirements/design/tasks → 开发