使用 Kiro 重建旧网站（以及出现的问题）

Source: Dev.to

我使用 Kiro 以及一些从未尝试过的技术，重建了一个已有 7 年未触碰的旧网站。我从不到一小时内实现身份验证，花了六天才弄清楚一个带文件上传的简单 CRUD，随后进入一个高效阶段，在四天内从零开始完成了剩余的 CMS 和站点功能（没有使用框架），最后又花了三天痛苦地清理 AI 生成的垃圾，只是为了确保一切在生产环境中真正运行。

你可能已经看到过很多关于 AI 编码助手的类似帖子，但我还是想分享一下我的经历。

首先学习概念，当你对自己要构建的东西一无所知时

如果你在尝试新事物，花时间真正学习概念。就我而言，我花了好几天卡在一个简单的 CRUD 上，因为我对 Cloudflare R2、Workers 和 Cloudflare Image Resizing 的工作原理完全不熟悉，导致无法正确指示 AI 完成我的需求。阅读文档并理解这些概念后，我终于能弄清自己制造的混乱，进行清理并让它正常工作。

规范驱动开发很强大，但…

我发现很多情况下，我对自己想做的事情非常清楚，而不写任何规范直接“即兴编码”要高效得多。对于开发团队来说，这意味着 AI 的需求规范暂时无法取代 PM 或 QA 编写的规范——至少目前如此。

保持规范简短

在使用规范驱动开发（Kiro 风格）时，我最多只能处理四个需求才能保持高效。每个规范包含两到三个需求效果要好得多。超过这个数量，我就会失去阅读需求、设计方案以及理解生成代码所需的认知能力。把你的规范拆分开。就这么简单。

引导文件非常重要

我发现的最佳技巧就是花时间保持引导文件的更新。每当我完成某项实现时，更新引导文件可以帮助 AI 理解之前模糊的内容或我已经改变想法的地方。在此之前，我常常需要纠正输出。使用更新后的引导文件，结果从一开始就更接近我的预期。虽然我没有正式测量，但节省的时间差异非常明显。

AI 静默地破坏了东西

即使使用了 steering 文件并让 Kiro 在实现任务前搜索并阅读代码库，它仍然把事情弄乱了。它可能会重新实现功能而不是复用现有代码，导致隐藏的不稳定性；添加冲突的 CSS 规则，这些规则在实际构建和部署之前不会被注意到；或者注入过于严格的安全配置，使应用无法使用。我还发现 Kiro 有倾向于过度设计。

为了了解实际发生了什么，我频繁地提交到 git，这样我就可以比较整体的文件差异。这比在任务执行过程中跟踪零散的小差异要容易得多。

检查点功能被低估了

Kiro 有一个我非常喜欢的功能：checkpointing（检查点）。如果我在实现某个功能的过程中改变主意，我可以轻松地把聊天记录和代码恢复到之前的某个点。这基本上是编程的撤销按钮。能够撤销并用不同的方法重试极其有价值，老实说，这让我想起了当我还有生活时，如何在 Football Manager 中把一支随便的 Serie C 俱乐部带到欧洲冠军的经历。

ChatGPT 是 Kiro 的类固醇助推器

也许是因为我使用了自动模型选择，有时会得到一个较弱的模型，但我发现 ChatGPT 在构思解决方案时的推理往往更好。Kiro 倾向于接受并执行你说的任何话，快速投入实现，这让调试感觉像是反复试错。使用 ChatGPT 时，基于聊天的交互让你有时间把事情想清楚。最终，对我来说，最佳的配置是我和 ChatGPT 共同“指挥” Kiro，真正把工作做好。

人类在短程冲刺中胜过 AI

我说过 vibe coding 可能更高效吗？有时最有效的方式是自己实现或修复代码，尤其是当我已经非常清楚需要写什么时。我发现人类——至少是我——在小型项目中比 AI 更能保留上下文，所以我不需要不断扫描已有代码来开始。我根本打不出和 AI 一样快的速度。

前后对比

旧站点
(原始站点的截图或描述)

重建
(重建后站点的截图或描述)

更重要的是，我现在拥有了坚实的基础，能够帮助他人并将 AI 编码助手的使用规模扩大到更复杂的层面。