在 48 小时内使用 Kiro IDE 构建 GPU 加速的文件资源管理器
Source: Dev.to
挑战
当我决定用 Rust 构建 Nexus Explorer——一款 GPU 加速的文件浏览器时，我知道自己设定了一个雄心勃勃的目标。文件浏览器看似简单，实则复杂：它们需要处理数百万个文件，提供即时反馈，管理异步 I/O 而不冻结 UI，并在多个平台上交付精致的用户体验。
传统开发可能需要数周，甚至数月。我只有 4 小时。
最重要的教训：了解你在构建什么
AI 辅助开发会放大你的专业能力——它并不能取代它。
如果你不理解：
- 为什么文件操作需要异步 I/O
- GPU 渲染与 CPU 渲染的区别
- 什么是良好的 UI 架构
- 何时使用缓存，何时使用新数据
……那么 AI 生成的看似合理的代码在真实使用中会崩溃。AI 并不知道你的约束、用户或性能需求。这些是你知道的。
调研阶段
在写下第一行代码之前，我花时间了解：
- GPUI 的架构——阅读 Zed 的源码以把握 Entity/View 的分离
- Rust 中的异步模式——Tokio、通道以及后台执行器如何交互
- 文件系统性能——为什么
jwalk比walkdir更快，以及批处理如何防止 UI 抖动 - 搜索算法——为什么
nucleo（来自 Helix）优于传统的模糊查找器
这些调研指导了每一个决策。当 AI 提出不符合架构的方案时，我能够识别并引导走向正确的解决方案。
迎接 Kiro IDE：改变游戏规则的工具
这是我第一次使用 Kiro IDE，现在已经成为我的忠实粉丝。经过这次黑客马拉松，Kiro 成为我的首选开发环境。
Kiro 对 AI 辅助开发的结构化方法不仅仅是“与 AI 对话”——它是一个通过明确定义的结构来指挥 AI 工作的完整系统：
需求 → 设计 → 任务
不再是随意的提示，我拥有：
- 需求——功能需要实现的目标
- 设计——应如何构建
- 任务——具体的实现步骤
当我把这些规格交给 Kiro 时，就像有一个可以精准指挥的同事。AI 有计划可循，理解上下文，知道我们在构建什么以及为什么。
这真是轻而易举。
说真的，其他 AI 编码工具感觉像是在向虚空喊话，期待得到有用的回馈。Kiro 则像是与真正阅读了项目文档的伙伴进行配对编程。
什么是 “Vibe Coding”？
Vibe coding 是一种开发哲学，核心是：
- 描述意图 而不是指令实现细节
- 通过对话迭代 与 AI 细化方案
- 专注架构，让 AI 处理样板代码
- 审查并引导 而不是手敲所有代码
- 捕捉错误 因为你了解领域
这就像与一个无限耐心的伙伴配对编程——但你仍是做出决策的高级工程师。借助 Kiro 的规格系统，这位伙伴实际上懂得全局。
第 1 天：架构与基础
使用规格进行规划
Kiro 的规格系统价值巨大。我创建了结构化的需求文档，既是文档也是 AI 的上下文：
.kiro/specs/
├── file-explorer-core/
│ ├── requirements.md # 我们在构建什么
│ ├── design.md # 我们如何构建
│ └── tasks.md # 实现清单
└── ui-enhancements/
├── requirements.md
├── design.md
└── tasks.md这不仅是文档，更是我与 AI 之间的契约。当我引用这些规格时，Kiro 完全理解我们正在构建的上下文。
**关键点：**需求是我写的。AI 并没有自行决定我们需要代际请求 ID 来防止过时的异步结果——这是我基于对问题的理解做出的决定。AI 帮助我正确实现它。
关键架构决策（由我决定，AI 实现）
决策 1：GPUI 框架
我选择 GPUI（来自 Zed 编辑器）进行 GPU 加速渲染。这是一次经过深思熟虑的冒险——GPUI 功能强大但文档有限。我的调研表明它能够在大型目录中实现流畅滚动，这对我想要的用户体验至关重要。
Kiro 的帮助包括：
- 阅读 GPUI 源码以了解模式
- 基于 GPUI 所有权模型建议 Entity/View 分离
- 生成符合 GPUI 约定的样板代码
当 AI 提出不符合 GPUI 模型的模式时，我能够识别并纠正方向。
决策 2：异步优先架构
核心理念： UI 永远不能等待文件系统的响应。
我知道我们需要：
- 用于 I/O 的后台线程
- 用于通信的通道
- 批量更新以防止渲染抖动
- 代际 ID 用于丢弃过时结果
┌─────────────────────────────────────────────────────────┐
│ 主线程 (UI) │
└─────────────────────────────────────────────────────────┘