先说我的“结论”：
- 10 小时（分两天）较专注的编程全程 AI 代码生成，0 人工代码，只参与了前期需求定稿产品：一个复古样式的 Hangman 猜单词游戏
[图一：游戏启动]
（项目仓库地址）
个人编程经验
我个人算有一些编程的经验，近几年主要用 PHP 和 TypeScript 写我的个人站点，用 C++写一些算法题。对各类开发工具有一定了解，对当今技术趋势有一定了解。
总体过程
16 号晚上下载了 Kiro ，先用它对我现在在重写的“任氏有无轩”项目进行了一两个测试，感觉模型可以（直接 Claude 4 ），速度可以（不用等），结果可以。然后试图创建一个“大”程序……到晚上，放弃。但积累了一些过程性体验和经验。
17 号上午，决定用一个比较“小”的程序——也就是 Hangman 猜英文单词——入手。当天编程时间较多，估计在 7-8 个小时，进入基本可玩状态（但有一个后来发现的问题）。
18 号上午，修正了 AI 调用的问题，加入了一些修饰功能（如个人进度跟踪等），用时 3 小时左右。
全程 10 个小时中：
- 人工输入：确定需求、设计和任务（下文详述）；手工干预一些设置；现场输入；点击“运行”让 Kiro 执行命令。也就是说，人工的输入已经来到了“最低”限度。AI 产出：分析、编码、纠错、提示人机交互。
详细过程
第一天
Kiro 的工作流程很有意思。Kiro 会提示你用“Spec”的方式来进行开发。
什么是“Spec”式开发？我的理解是，用户作为“甲方”只管提出要求，而 Kiro 会根据它的经验，进行进一步的分解，最终形成 3 个供后续开发使用的文件。
我的第一步工作（也算是最大的输入工作）是创建了一个spec.md文件，写下了我最根本、最基本的要求，全文如下[^1]：
# ObjectiveTo build a retro Hangman game using latest technology and a beautiful UI.# Tech requirements1. Typescript, with framework support (say Nuxt)2. Elegant UI, such as Tailwind, Flowbite3. Use locally installed Ollama qwen3:1.7b to get a random word4. Show correct letters and guessed letters.5. Every failed attempt will decrease your "life" and show progress accordingly.6. Display "Win" or "Lose" accordingly.[^1]: 这里的模型需求后来被我 override 了，改用了豆包的 API 接入。
Kiro 看了这个文件，生成了三个新文件：requirements.md，design.md和tasks.md。
requirements.md是一个比较结构化的文档，对于每个需求（requirement），有“用户叙事”（ User Story ）和“验收标准”（ Acceptance Criteria ）。对这个文件，用户应该花一些心思进行修订。design.md是一个技术设计文档。其中规定了应用使用到的技术栈，Kiro 还贴心地画出 Mermaid 流程图让“甲方”更好地理解程序整体架构。对这个文件，用户应该花很多心思进行审阅，因为技术栈的选择对整个程序的开发速度和难度至关重要。tasks.md是一个具体指导 Kiro 开发的详细技术文档。我这个 Hangman 程序，最终有 13 个一级任务，涉及项目自举、后台准备（如难度、游戏状态、游戏逻辑）、界面、AI 调用、个人成就、集成、单元测试、集成测试等重要节点。对于每个一级任务，Kiro 会将它分解为一些二级任务以及更小的待实现功能点。用户应该认真地审阅这个文件，但不用过细。我就只看了一级任务和一些二级任务。这三个文件一旦确定，就可以进入 Kiro 自驱动的开发。
整体而言，第一天的开发还是比较顺利的。我只进行了两次代码提交，就已经有了一个还可以看的界面，游戏逻辑已经基本就位，还加入了一些音效反馈。
这一天的工作中，有不少是耗在了调用外部 AI 以及相关的工作上。我弃用了本地 Ollama 提供单词的想法，申请了豆包 API ，花了很多时间调试提供给豆包的提示词，调整参数（为的是在速度和准确度间找到平衡）。最终在测试中得到较好的结果。
第二天上午
在第二天上午的试用中，我发现了一个重大问题：程序在找单词的时候，一直在所谓 fallback 的词库里选择单词，游戏因此不具备了可玩性。
（我手动修改了程序中的 Fallback 词库，使其只包含无意义的一些中文字。这样，我就能判断程序是否真正用了 AI 提供的单词。）[^2]
[^2]: 另一种做法，是手工维护一个本地词库。但这样一来，这个程序本身就一点都和 AI 挂不上边了，对吧？
我和 Kiro 进行了长时间的对话，而 Kiro 也非常配合，通过不同的 API 调用方式，最终找到了问题，并完成了最有突破性的修订（见这个Git Commit）。之后我又对 UI 提出了一些改进意见，Kiro 也都一一完成。
第二天的另一个重要功能，是加入了所谓的“个人进度”：你玩了几次游戏？各个难度的准确率是多少？——这也是我一开始对 Kiro 的要求。而 Kiro 显然不满足于这么简单的一个进度系统。它主动加入了“成就”系统——虽然还很少，目前只有 5 个——并很快完成。
最终运行
游戏运行后，会出现“难度选择”（见图一）。选择难度后，进入初始界面：
[图二：游戏开始的初始界面]
随着用户的输入，界面不断更新：吊死鬼的状态、猜对/猜错的字母，当前游戏整体进度等。
[图三：游戏进行中]
这是游戏中的“个人进度”：
[图四：个人进度和成就]
写在最后
这几年，“用了 XXX ，0 代码一天我编写了一个？？？？”的帖子是很能吸引眼球的。我做这样的一个“试验”，也是为了去验证这样的说法到底是不是成立。
你问我的结论？我的结论是：用了 AI ，0 代码一天写一个 app ，可行但不要过于乐观。
“可行”在于，通过我的实践，我发现确实可以 0 代码用一天的时间写一个 app 。
“不要过于乐观”在于，我是一个有一定编程基础的“非程序员”。我可以不知道正确的代码、最好的做法是啥——这是 AI 的工作，但我知道：我想要什么，程序设计应有的结构，一些关键的“卡点”。
Kiro 和所有的 AI 一样，一般都会 over thinking （过度思考）。在不少场合，我必须打断它“无休止”的思考而提出强硬的要求，而如果没有一定（可能还是很深厚）的编程基础和实践，真的编程小白恐怕是无法做到这个的。
AI 编程的意义在哪里？
对于那些重复性的、可验证的、可参考性强的工作，AI 比人有着巨大的优势。无论是快速原型迭代还是功能、细节的改进，AI 的“知识库”一定胜过任何程序员。
如果一项任务可被验证，比如：应用启动时，应该显示一个“复古”界面就是一个可被验证的任务——Kiro“知道”复古界面是什么意思，应该有些什么元素。
人的优势在于，对于开发的进程以及一些关键节点（以及相应的干预）有着清楚的认识。在人的干（ tiao ）预（ jiao ）下，AI 不至于陷入“幻觉”或者“过度思考”。人在这个模式下，更像一个纯甲方+PM ，提出需求、迭代需求、适当干预、最终验收（方式各异）。
Kiro 还提供了 Vibe 模式——抽烟喝酒烫头式模式——进行开发，我会用这个模式试着开发下一个练手项目。
如果你已经看到这里，不妨访问我的代码仓库，clone 一份到本机执行，顺便加个 star 吧！
（原文连接： https://blog.rsywx.net/2025/07/18/kiro-you-are-really-good/）
