大量用 Kiro 之后，发现发现越用越喜欢，越用越好用。
主要还是 Spec 模式，对系统实现的掌控感很好，另外 Kiro 的一些细节处理也让人爱不释手。
比如 Autopilot模式，他可以自动确认而不用用户手动决定。 虽然这个不是 Copilot 独有的。
还有无论是对话框的变动列表，还是编辑器里面的变动列表，都让人很有成就感。 也可能是新鲜感的原因吧，毕竟每个工具都能看到修改的文件，只是没有和Session关联而已。
一些变好的问题
出错问题
我昨天遇到的出错情况，今天试了下也会有，但是极少，可以忽略不计，猜测大部分是网络情况引起的。
等待执行
Kiro 执行系统命令等待的问题，虽然有时候会比较慢，经常性的出了错也不会自动解决错误。 但是我发现我可以手动进行提示来让他继续下去。
这个可能是 Kiro 的设计模式如此，不像别的工具，必须要停止任务才能对话。
每日限额
由于每日的限额问题（大概两个小时就能用完了），剩下的部分就要借助其他 IDE 完成了。
我的提示词也很简单，比如 Tare，不管他懂不懂 SPEC 模式，直接让他写：
不管怎么说，一步一步的最后把所有页面都写好了，目前只是完成了前端，比较简单。
关于代码质量
使用同样的大模型，相比于 Cursor,Trae来说，Kiro 感觉给出的结果更加具有一致性。 代码出现过错误的概率也更小一些，很少有吧你的代码改乱，或者加错地方的现象出现。
代码成功率也是我一直挺好奇的地方，有可能是因为 Kiro 每次代码生成都会查看很多上下文和需求设计， 所以生成代码一致性高，正确率也比较高。但是比较慢的原因。
AI 代码生成模式
使用 Kiro 之后，还发现了一些很好的 AI 代码生成模式，或者说是开发步骤或提示词模式都行。 这也是我用其他编辑器在实现大项目时经常遇到的一些问题。
先实现项目结构
对于涉及多文件的任务，无论是前端还是后端，都可以先实现项目的结构，比如先实现页面文件，页面内容可以先写「待开发」，后端先定义服务和模型。
这样可以很好的规范后续复杂的代码出错问题。比如我用 Trae 经常遇到两个任务，或者一个任务的多次提示给我生成了不同的、重复的代码。
先定义类型
这一点和前面项目结构类似。类型定义好，前端就只剩下界面了，而且对界面有一个很好的约束。
后端一样，而且前后换交互的数据模型也仍让开发和调试前后端的时候AI可以更少出错。
公共组件
不难否认，用 Cursor，Trae 以及 Windsurf 写代码确实快，而且每个功能单独看都很好，但是整体项目的代码质量就不是那么高了。
即使你告诉他要定义公共组件，在后续功能实现的时候，公共组件的使用也并不尽如人意。而且你要经常告诉 AI 去使用组件。 特别是两三个页面 AI 实现之后，你让他重构一些公共组件的时候，你会发现与人交流，比和 AI 交流要开心的多。
这时候用 Kiro 就可以很好的解决这个问题。Kiro 经常在多页面任务的时候自己去设计定义哪些公共组件，虽然任务要一个个实现，花费的时间看似更长，但是比起哪些 写的快、但是要重构 的代码， 作为生产项目让 AI 重构的消耗，远比你想象的多。
我想着也是为什么今年虽然 AI 编程越来越强了，但是满意度确下降了的原因。
主动优化
Kiro 生成的任务规划中，最后的五分之一甚至四分之一都是优化和重构类型的任务。用来完善代码质量，而不仅仅是完成代码功能，这是我们人工编码手动实现的过程中会去做的事情。 AI每次实现的代码质量还都不错，但是合在一起就经常出问题，有了这样有目的优化，代码质量会高很多。
比如响应式布局合理移动端优化：
- [x] 16. Implement responsive design and mobile optimization
- Ensure all components work across different screen sizes
- Optimize touch interactions for mobile devices
- Implement progressive disclosure for complex interfaces
- Add mobile-specific navigation patterns
- _Requirements: 1.1, 2.1, 3.1, 4.1_或者打包和性能优化：
- [x] 19. Optimize performance and bundle size
- Implement code splitting for each module
- Add lazy loading for heavy components and charts
- Optimize bundle size with tree shaking
- Implement virtual scrolling for large data tables
- _Requirements: 1.3, 2.2, 3.1, 4.1_未来发展
AI 降低编程门槛的同时，也慢慢把编程这件事情变得更加牛马化了。
当前主流的使用体验依然是你要面对一个时而聪明，有时候又愚蠢的AI，你的工作就是不停和它沟通。
以前产品经理、测试的任务现在都要做，似乎唯独程序员的工作不要做。其实也不是不做，只是如果想要快乐的和 AI 沟通， 普通程序员要在架构师的角度去定规范，还要亲自写文档，然后落实。
好的是，随着大家对当前问题认识越来越深刻，不就可定会有比 SPEC 更完善的 AI 编码模式和工具出现。 即使没有，每个人在重度使用之后，也会积累一套适合自己的工作流程和文档提示词。