wxya 王小扬博客
Git
AI
产品
film
AI Code
Java
其他
计算机网络
DB
云原生
Node
Docker
操作系统
Elasticsearch
Apollo
Nestjs
Think
大前端
PHP
软件开发
设计
生活技巧
CI
缓存
Claude Code + Kiro Spec：别急着生成代码，先让AI理解你的需求
我们正迎来「新代码」时代，而这份「新代码」，不是你我熟知的程序语言，而是 「规范」（Specification，下文简称 Spec）。
最近在研究Kiro的时候，发现了一个很有意思的现象。Kiro的spec功能设计得很直接，你说"我要做个评论系统"，它就直接生成requirements、design和tasks三个文件。
但真正执行之后，我发现一个问题：直接从需求到spec，生成的内容往往差强人意。不是需求理解偏差，就是设计过于粗糙。
这让我想起了传统开发中的一个痛点：需求不清楚就开始写代码，最后做出来的东西完全不是用户想要的。
问题的根源：直接toSpec的陷阱
传统开发中的教训
还记得我之前分享的那套软件工程流程吗？需求分析(/ask) → 代码实现(/code) → 测试用例(/test) → 代码审查(/review) → 优化调整(/optimize, /refactor)。
这套流程的核心逻辑很简单：先把需求搞清楚，再写代码，最后验证。但实际操作中，大部分团队都是直接上手写代码，需求文档要么没有，要么写完就束之高阁。
在传统软件开发中，我们都知道一个道理：需求分析是整个项目的基石。如果需求都没搞清楚，后面的设计和实现再精美也是空中楼阁。
我见过太多这样的场景：
- 产品经理甩过来一个模糊的需求文档
- 开发直接开始写代码
- 结果做出来的东西完全不是用户想要的
这种情况下，即使技术实现再完美，最终也是徒劳。
AI开发中的相同问题
现在到了AI辅助开发的时代，同样的问题依然存在。
很多人使用Kiro的时候，流程是这样的：
这种做法的问题在于：
- AI没有充分理解需求背景
- 缺乏交互式的需求澄清过程
- 生成的spec往往过于泛化
就像我之前在Claude Code的实践中发现的，不能再随意跳过文档和测试环节，因为后续的命令都依赖前面的输出。同样道理，Kiro的spec生成也不应该跳过需求理解这个关键环节。
我的解决方案：/ask + /spec 组合拳
经过一段时间的摸索，我发现了一个更有效的工作流程：
第一步：使用/ask进行需求沟通
在使用
/spec之前，先用/ask和AI进行充分的对话。这个过程就像是和产品经理、技术总监进行需求评审会议。记住，一定要使用/clear清理上下文，否则被Claude Code自动压缩后质量降低非常多。
举个例子：
AI会反问你：
- 这个系统的目标用户是谁？
- 需要支持多少用户规模？
- 有哪些核心功能需求？
- 有什么特殊的业务规则？
- 需要集成哪些外部系统？
第二步：深入交流，澄清细节
通过多轮对话，让AI真正理解你的需求：
AI会继续追问：
- RBAC的角色层级是怎样的？
- OA系统的集成方式是什么？
- 数据同步的频率要求？
- 安全性方面有什么特殊要求？
这就像我在Claude Code中强制规范化流程一样，强制你思考那些平时容易忽略的问题，比如数据一致性、服务间通信、故障恢复等。
第三步：确认理解，生成spec
经过充分的交流后，AI对你的需求有了深入理解。这时候再使用
/spec：这时生成的三个spec files就会：
- requirements.md - 更加贴合实际需求的用户故事
- design.md - 考虑到业务场景复杂性的系统架构
- tasks.md - 包含必要技术细节的实现计划
实际效果对比
直接使用/spec的结果：
- 生成的requirements往往很泛化
- design缺乏针对性的架构考虑
- tasks分解不够细致
- 容易遗漏重要的边界条件
/ask + /spec组合的结果：
- requirements描述更加精确
- design方案考虑更加周全
- tasks划分更加合理
- 包含了业务场景的特殊处理
就像我在Kiro的体验中发现的，它不是直接开始写代码，而是先生成三个spec files。这种spec-driven development的理念是对的，但前提是spec本身要高质量。
深层思考：为什么这样更有效？
1. 知识的渐进构建
AI和人类一样，理解复杂问题需要一个渐进的过程。通过对话，AI可以：
- 逐步建立对业务领域的理解
- 识别潜在的技术风险点
- 考虑不同方案的权衡
这就像Claude Code的Memory机制一样，上下文连续性确保生成的代码符合各层级的要求。
2. 上下文的丰富化
每一次
/ask的交互都在为AI提供更丰富的上下文信息。这些信息在后续的/spec生成中会发挥重要作用。就像我在项目Memory中记录的那样：技术栈选择理由、非功能性需求分析、潜在风险点识别。这些都需要通过对话来澄清。
3. 需求的双向验证
通过对话，不仅AI在理解你的需求，你也在通过AI的反馈来完善自己的需求描述。这是一个双向的验证过程。
实践建议
1. 不要急于求成
给AI足够的时间来理解你的需求。一个好的
/ask会话可能需要5-10轮的交互。记住Kiro的Agent Hooks功能，它能自动处理那些琐碎但重要的事情。同样，你也要给AI时间来处理需求理解这个重要环节。
2. 提供具体的场景
不要只说"我要做一个系统"，而是说"我要为我们公司的HR部门做一个员工管理系统"。
就像我在Claude Code中发现的，具体的上下文信息是代码质量的关键。
3. 主动澄清歧义
当AI的理解和你的预期不一致时，要主动澄清，不要将就。
这就像代码review一样，发现问题要明确指出哪里不符合预期，以及具体的修改建议。
4. 逐步细化
从大的框架开始，逐步细化到具体的功能点。
这个过程就像从全局Memory到项目Memory再到模块Memory的渐进式完善。
实际开发案例
举个具体例子，用这套流程开发一个用户认证系统：
第一步：需求分析
通过多轮对话，澄清：
- 用户规模和并发需求
- 安全等级要求
- 与现有系统的集成方式
- 密码策略和账号管理规则
第二步：生成spec
这时生成的spec会包含：
- requirements.md - 明确的用户故事和验收标准
- design.md - 考虑安全性和可扩展性的架构设计
- tasks.md - 详细的开发任务分解
第三步：基于spec开发
有了高质量的spec，后续的开发就会非常顺畅。Claude Code可以基于这些specs生成符合要求的代码，而不是凭空想象。
我的真实感受
用了这套方法后，发现几个明显的好处：
1. 提高需求理解准确性不会再出现"我以为你要的是这个"的情况。
2. 减少返工前期把需求和架构想清楚，后面写代码就很少需要大改。
3. 提升团队协作效率生成的spec文档成为团队沟通的基础，避免了各种误解。
4. 知识沉淀每次的需求澄清过程都会形成文档，后续类似项目可以复用。
当然也有一些成本：
1. 学习成本需要适应这种工作方式，习惯了直接写代码的开发者可能不太适应。
2. 时间投入前期需要花更多时间在需求理解上，但这个投入是值得的。
总结
从我在Claude Code的实践，到现在对Kiro的理解，有一个共同的感悟：AI工具不是要替代我们思考，而是要让我们思考得更深入、更系统。
Kiro的spec功能确实强大，但它的真正价值不是快速生成文档，而是帮助我们建立spec-driven development的工作习惯。
而这个习惯的前提是：你要先让AI真正理解你的需求。
所以，下次使用Kiro 或者 Claude Code 的时候，别急着
/spec，先用/ask和AI聊聊你要做什么。给AI足够的上下文，它会给你更好的回报。记住：好的代码来自于好的设计，好的设计来自于好的需求理解。
在AI的世界里，这个道理同样适用。
Loading...