我如何使用 Kiro 构建 MCP 时间旅行者：开发者在 Vibe Coding、Specs、Steering、Hooks 和 MCP 中的旅程

Source: Dev.to

🌱 想法的起点

开发者经常讨论“我该用什么技术栈？”但很少会问，“五年或十年前这个技术栈是什么样的？”
我想象了一个简单的界面：

1. 选择语言 →
2. 选择框架 →
3. 选定年份 →
4. 获取该年份的完整运行时 + 依赖栈。

关键在于，我不想伪造数据——我想从真实的包注册表中获取。为此我需要：

• 前端
• API
• 共享类型层
• 自定义 MCP 服务器
• 真正的注册表集成
• 端到端的 Kiro 支持

作为单独的开发者，这工作量不小，但 Kiro 让它感觉出奇地可管理。

⚡ Vibe Coding：把随意的想法变成真实项目

我先用了 vibe coding——直接和 Kiro 讨论概念。几分钟内 Kiro 生成了：

• 完整的 monorepo 结构
• 一个 Express API
• 一个 React/Vite 前端
• 共享的 TypeScript 类型
• 一个入门的 MCP 服务器
• 初始路由和验证逻辑

Kiro 从一开始就让每个部分相互对齐，感觉像是和一位懂架构的工程师配对编程。

📘 Specs：从探索走向结构

在明确想法后，我转向了基于规范的开发。我编写了两个规范文件：

• .kiro/specs/app-spec.md
• .kiro/specs/mcp-spec.md

这些规范定义了：

• 输入/输出合约
• 类型结构
• 预期的 API 行为
• 输入验证
• 错误形状
• 集成点

随后我对 Kiro 说：

Update the API implementation based on the current spec.

Kiro 更新了所有内容——API 路由、类型、辅助函数——在整个 monorepo 中保持一致。规范把项目从探索阶段转变为内部连贯的结构。

🎛 Steering Docs：教会 Kiro 我的偏好

为了确保一致性，我添加了 .kiro/steering/coding-style.md，描述了：

• 命名约定
• 错误格式
• TypeScript 模式
• 文件夹结构规则
• 预期的注释
• 文件布局偏好

结果是：项目的每一部分，无论是第一天生成的还是第五天生成的，都看起来像出自同一位作者，省去了清理时间并加快了迭代。

🔌 MCP 服务器：项目的核心

自定义的 MCP 服务器让 MCP Time‑Traveler 不再只是演示。我构建了三个 MCP 工具：

• npm 历史版本查询
• PyPI 历史版本查询
• RubyGems 版本查询

Kiro 帮助生成了：

• MCP 工具模式
• 验证逻辑
• 错误处理
• 工具处理器实现
• EOF‑安全的请求/响应类型

MCP 层使应用能够获取真实、准确的生态系统数据——而不是硬编码的值。例如：

• Node 4.9.1 + Express 4.13.4（2015 年）
• Python 3.7.17 + Django 2.1.15（2018 年）

在 UI 中看到真实的历史栈出现，感觉非常神奇。

🔁 Hooks：自动化那些拖慢你的工作流

我添加了两个 Kiro 代理钩子：

1. Scaffold regeneration hook – 当规范改变时触发，保持项目结构一致。
2. Pre‑commit hook – 执行类型检查和轻量级构建步骤。

这些钩子像护栏一样，帮助单独的开发者在不记住每个细节的情况下保持纪律和一致性。

☁️ 部署完整项目

• API → 部署到 Heroku
• 前端 → 部署到 Vercel
• MCP 服务器 → 在本地为 Kiro 开发时运行
• GitHub 仓库 → 公开、开源、MIT 许可证

你可以在这里尝试：

• 前端：
• API 健康检查端点：
• 源码：

💡 这个项目教会我的事

• AI 驱动的 IDE 如何提升单独开发者的效率
• vibe coding 在早期探索中的优势
• 规范如何强制结构并保证长期一致性
• steering docs 如何统一代码库
• MCP 如何把 AI 与真实世界数据桥接起来
• Hooks 如何自动化重复任务

Kiro 不仅帮助我更快地构建；它还帮助我更干净、可预测且更愉快地构建。

🎃 最后感想

当我开始时，我以为 MCP 服务器是最难的部分。结果，最难的其实是相信一个 AI 辅助的 IDE 能够引导完整的多服务构建。Kiro 做到了——始终如一、可靠且富有创造力。MCP Time‑Traveler 不再是一次黑客马拉松的项目；它成为了我未来构建工具的蓝图。