在48小时内使用 Kiro IDE 构建 GPU 加速的文件资源管理器

Source: Dev.to

请提供您希望翻译的完整文本（除代码块和 URL 之外），我将为您翻译成简体中文并保持原有的 Markdown 格式。

挑战

当我决定构建 Nexus Explorer——一个使用 Rust 编写的 GPU 加速文件资源管理器时，我就知道自己设定了一个雄心勃勃的目标。文件资源管理器看似简单，实则极其复杂：它们需要处理数百万个文件，提供即时反馈，管理异步 I/O 而不导致 UI 卡顿，并在多个平台上提供精致的用户体验。

传统的开发可能需要数周，甚至数月。我只有 4 小时。

最重要的一课：了解你在构建什么

AI 辅助开发放大了你的专业知识——它并不取代它。

如果你不理解：

• 为什么异步 I/O 对文件操作很重要
• GPU 渲染与 CPU 渲染的区别
• 什么构成良好的 UI 架构
• 何时使用缓存而不是实时数据

…那么 AI 将生成看似合理的代码，但在实际使用中会崩溃。AI 并不知道你的约束、用户或性能需求。你知道。

研究阶段

在写下任何代码之前，我花时间了解：

• GPUI 的架构 – 阅读 Zed 的源代码以把握 Entity/View 分离
• Rust 中的异步模式 – Tokio、通道和后台执行器如何交互
• 文件系统性能 – 为什么 jwalk 比 walkdir 更快，以及批处理如何防止 UI 抖动
• 搜索算法 – 为什么来自 Helix 的 nucleo 优于传统模糊查找器

这些研究为每个决策提供了依据。当 AI 提出与架构不匹配的建议时，我能够识别并引导其走向正确的解决方案。

Source: …

进入 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 用于丢弃过时结果。

┌─────────────────────────────────────────────────────────┐
│                    Main Thread (UI)                    │
│  ┌─────────┐  ┌──────────┐  ┌─────────┐  ┌──────────┐   │
│  │Workspace│  │ FileList │  │ Sidebar │  │ Preview  │   │
│  └────┬────┘  └────┬─────┘  └────┬────┘  └────┬─────┘   │
└───────┼────────────┼─────────────┼────────────┼─────────┘
        │            │             │            │
        └────────────┴─────────────┴────────────┘
                          │ async channels
┌─────────────────────────┼───────────────────────────────┐
│              Background Executor (GPUI)                │
└─────────────────────────┼───────────────────────────────┘
                          │ spawn_blocking
┌─────────────────────────┼───────────────────────────────┐
│                 Tokio Thread Pool                      │
│  ┌─────────┐  ┌──────────┐  ┌─────────┐  ┌──────────┐   │
│  │ jwalk   │  │  notify  │  │  icons  │  │  search  │   │
│  └─────────┘  └──────────┘  └─────────┘  └──────────┘   │
└─────────────────────────────────────────────────────────┘

决策 3：Steering 文件以保持一致性

我在 .kiro/steering/ 中设置了 steering 规则，以在生成的代码中保持一致性。

# attention.md
- No unnecessary linter warnings
- Enforce consistent naming (snake_case for variables, PascalCase for types)
- Keep UI modules separate from core logic