- Published on
【转载】Claude Code + Kiro Spec：别急着生成代码，先让 AI 理解你的需求
- Authors
- Name
- aosan
最近在研究 Kiro 的时候，发现了一个很有意思的现象。Kiro 的 spec 功能设计得很直接，你说"我要做个评论系统"，它就直接生成 requirements 、design 和 tasks 三个文件。
但真正执行之后，我发现一个问题：直接从需求到 spec ，生成的内容往往差强人意。不是需求理解偏差，就是设计过于粗糙。
这让我想起了传统开发中的一个痛点：需求不清楚就开始写代码，最后做出来的东西完全不是用户想要的。
问题的根源：直接 toSpec 的陷阱
传统开发中的教训
还记得我之前分享的那套软件工程流程吗？
需求分析(/ask) → 代码实现(/code) → 测试用例(/test) → 代码审查(/review) → 优化调整(/optimize, /refactor)。
这套流程的核心逻辑很简单：先把需求搞清楚，再写代码，最后验证。但实际操作中，大部分团队都是直接上手写代码，需求文档要么没有，要么写完就束之高阁。
在传统软件开发中，我们都知道一个道理：需求分析是整个项目的基石。如果需求都没搞清楚，后面的设计和实现再精美也是空中楼阁。
我见过太多这样的场景：
产品经理甩过来一个模糊的需求文档
开发直接开始写代码
结果做出来的东西完全不是用户想要的
这种情况下，即使技术实现再完美，最终也是徒劳。
AI 开发中的相同问题
现在到了 AI 辅助开发的时代，同样的问题依然存在。
很多人使用 Kiro 的时候，流程是这样的：
需求 → 直接 spec → 生成 requirements/design/tasks → 开发
这种做法的问题在于：
AI 没有充分理解需求背景
缺乏交互式的需求澄清过程
生成的 spec 往往过于泛化
就像我之前在 Claude Code 的实践中发现的，不能再随意跳过文档和测试环节，因为后续的命令都依赖前面的输出。同样道理，Kiro 的 spec 生成也不应该跳过需求理解这个关键环节。
我的解决方案：/ask + /spec 组合拳
经过一段时间的摸索，我发现了一个更有效的工作流程：
第一步：使用/ask 进行需求沟通
在使用/spec之前，先用/ask和 AI 进行充分的对话。这个过程就像是和产品经理、技术总监进行需求评审会议。
记住，一定要使用/clear 清理上下文，否则被 Claude Code 自动压缩后质量降低非常多。
举个例子：
/ask 我想开发一个用户管理系统，你能帮我理解一下具体需要考虑哪些方面吗？
AI 会反问你：
这个系统的目标用户是谁？
需要支持多少用户规模？
有哪些核心功能需求？
有什么特殊的业务规则？
需要集成哪些外部系统？
第二步：深入交流，澄清细节
通过多轮对话，让 AI 真正理解你的需求：
/ask 我们的用户管理系统主要面向企业内部，大概 500 人规模，需要支持 RBAC 权限控制，还要能和我们现有的 OA 系统集成
AI 会继续追问：
RBAC 的角色层级是怎样的？
OA 系统的集成方式是什么？
数据同步的频率要求？
安全性方面有什么特殊要求？
这时生成的三个 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 的渐进式完善。
实际开发案例
举个具体例子，用这套流程开发一个用户认证系统：
第一步：需求分析
/ask 我想为我们的企业内部系统开发一个用户认证模块，需要支持 JWT ，你觉得我们应该考虑哪些方面？
通过多轮对话，澄清：
用户规模和并发需求
安全等级要求
与现有系统的集成方式
密码策略和账号管理规则
第二步：生成 spec
/spec 基于我们的讨论，生成企业用户认证系统的完整规格说明
这时生成的 spec 会包含：
requirements.md - 明确的用户故事和验收标准
design.md - 考虑安全性和可扩展性的架构设计
tasks.md - 详细的开发任务分解
第三步：基于 spec 开发
有了高质量的 spec ，后续的开发就会非常顺畅。Claude Code 可以基于这些 specs 生成符合要求的代码，而不是凭空想象。
我的真实感受
用了这套方法后，发现几个明显的好处：
提高需求理解准确性：不会再出现"我以为你要的是这个"的情况。
减少返工：前期把需求和架构想清楚，后面写代码就很少需要大改。
提升团队协作效率：生成的 spec 文档成为团队沟通的基础，避免了各种误解。
知识沉淀：每次的需求澄清过程都会形成文档，后续类似项目可以复用。
当然也有一些成本：
学习成本：需要适应这种工作方式，习惯了直接写代码的开发者可能不太适应。
时间投入：前期需要花更多时间在需求理解上，但这个投入是值得的。
总结
从我在 Claude Code 的实践，到现在对 Kiro 的理解，有一个共同的感悟：AI 工具不是要替代我们思考，而是要让我们思考得更深入、更系统。
Kiro 的 spec 功能确实强大，但它的真正价值不是快速生成文档，而是帮助我们建立 spec-driven development 的工作习惯。
而这个习惯的前提是：你要先让 AI 真正理解你的需求。
所以，下次使用 Kiro 或者 Claude Code 的时候，别急着/spec，先用/ask和 AI 聊聊你要做什么。给 AI 足够的上下文，它会给你更好的回报。
记住：好的代码来自于好的设计，好的设计来自于好的需求理解。
在 AI 的世界里，这个道理同样适用。