我的博客园地址 https://www.cnblogs.com/huangyingsheng/p/19925861

使用 Kiro 写代码的实践分享

在过去一段时间里，我尝试用 Kiro 来辅助日常编码工作，从最初的好奇，到逐渐形成依赖，这个过程让我对“AI + 编程”的协作方式有了更具体的理解。

这篇博客主要记录我在使用 Kiro 写代码过程中的一些体验、优势、问题以及适用场景，希望能给正在观望或刚开始使用的人一些参考。

---

一、Kiro 是什么？

Kiro 可以理解为一个面向开发者的 AI 编程助手，它的核心能力包括：

• 代码生成（从需求直接生成实现）
• 代码补全与重构
• Bug 排查与解释
• 架构建议与设计辅助

和传统 IDE 插件不同的是，它更偏向“对话式编程”，你可以直接用自然语言描述需求，然后逐步推进实现。

---

二、我为什么开始用 Kiro

最初使用 Kiro 的原因很简单：提高效率。

在日常开发中，经常会遇到这些问题：

• 写样板代码很重复
• 调接口、写 DTO 很机械
• 小功能拆分成本高
• debug 时间不稳定

Kiro 在这些场景下确实能显著减少心智负担。

---

三、实际使用体验

1. 写代码的方式变了

以前是：

设计 → 编码 → 调试

现在变成：

描述需求 → AI 生成初稿 → 人做结构调整 → AI 优化细节

开发更像是在“指挥一个初级工程师”。

---

2. 适合做什么

经过一段时间实践，我发现 Kiro 特别适合：

• CRUD 接口快速生成
• SQL / 查询逻辑编写
• 代码重构（尤其是重复逻辑）
• 测试用例生成
• 小型工具脚本

这些场景基本可以做到“提需求即出代码”。

---

3. 不太适合做什么

当然，它也不是万能的：

• 核心架构设计（仍需要人主导）
• 复杂分布式系统边界定义
• 性能极限优化（需要经验判断）
• 业务规则非常隐含的系统

简单来说：越靠近业务本质，AI 越需要人兜底。

---

四、几个真实使用案例

案例 1：接口开发

以前写一个列表查询接口：

• Controller
• Service
• DAO
• SQL

需要 30~60 分钟。

用 Kiro：

• 描述需求
• 生成基础代码
• 调整字段映射

整体时间缩短到 10~15 分钟。

---

案例 2：重构旧代码

面对一段 500+ 行的业务逻辑：

Kiro 可以帮我：

• 拆分方法
• 提取公共逻辑
• 标注潜在风险点

相当于一个“代码审计助手”。

---

五、使用 Kiro 的正确姿势

我总结了几个关键点：

1. 不要直接让它“写完系统”

正确方式是拆需求：

✔ 先生成模块结构
✔ 再生成单个函数
✔ 最后再优化细节

---

2. 明确约束比描述功能更重要

比如：

❌ “帮我写一个用户系统”

✔ “用 Spring Boot，实现用户注册接口，字段包括 username/password/email，密码需要 bcrypt，加事务控制”

---

3. 把它当“初级工程师”

你需要：

• review 代码
• 修正设计
• 控制边界

而不是完全信任输出。

---

六、带来的变化

最大的变化其实不是“写代码变快”，而是：

👉 更愿意做设计，而不是写细节
👉 更专注业务逻辑，而不是语法
👉 更快验证想法

开发的重心开始上移。

---

七、一些风险和思考

当然，也有一些问题：

• 过度依赖会削弱基础编码能力
• 代码风格可能变得不一致
• AI 生成的逻辑不一定符合团队规范

所以在团队环境中，需要：

• 统一代码规范
• 做强 review
• 控制 AI 使用边界

---

八、总结

Kiro 不是替代程序员的工具，而是：

一个把“写代码”变成“描述问题”的工具

它改变的是开发方式，而不是开发本身。

如果用得好，它可以让你：

• 更快实现想法
• 更专注设计
• 减少重复劳动

但最终质量，仍然取决于你如何使用它。

---

九、懒得写博客了，这篇blog也是AI写的

….