前言

2025 年我试了不少 AI 编程工具。用下来以后，我发现自己对这类工具的期待已经变了。

以前我更关心它能不能写一个函数、解释一个报错、补一段样板代码。现在我更关心它能不能陪我把一个小项目从想法推进到能用。

这次我用 Kiro 做了一个自己的工具站。项目本身不算大，主要是把一些平时零散用的小工具集中起来，比如文本处理、JSON 格式化、时间戳转换、编码解码、随机字符串生成这些。

但这个过程很适合观察 Kiro 这类 AI IDE 的价值：它不是只生成一段代码，而是从需求拆分、页面结构、组件设计、状态处理到最后调样式，完整参与了一遍。

为什么想做工具站

平时开发时，经常会用到一些很碎的小工具。

比如接口联调时要格式化 JSON，排查日志时要把时间戳转成时间，写配置时要做 Base64 编码，临时造数据时要生成 UUID 或随机字符串。

这些工具网上都有，但每次打开不同网站，总会遇到几个问题：

1.页面广告太多。 2.工具入口分散。 3.有些工具会把数据传到服务端，不放心。 4.常用选项不符合自己的习惯。 5.想加一个小功能时改不了。

所以我一直想做一个自己的工具站。功能不用很复杂，但要满足几个点：打开快、界面干净、尽量本地计算、常用工具集中在一起、后面想加工具时结构清楚。

以前这种小项目我会自己慢慢写。现在有了 AI 编程工具，我更愿意把它当成一次实践：看看 Kiro 能不能把这种个人项目做得比较顺。

Kiro 给我的第一印象

Kiro 给我的感觉不是单纯的聊天框，也不是只会自动补全的编辑器。

它比较强调先把需求说清楚，再围绕需求生成设计和任务。这个思路对我挺有用，因为个人工具站这种项目很容易越做越散。

如果只是直接说“帮我做一个工具站”，AI 很可能会马上生成一个看起来很完整的页面，但里面的工具、组件、路由、样式和数据结构不一定经得起后续扩展。

我更希望它先回答这些问题：

1.第一版到底包含哪些工具。 2.工具之间有没有统一输入输出结构。 3.页面怎么组织，左侧导航还是卡片入口。 4.每个工具是否需要历史记录。 5.哪些逻辑可以抽成公共组件。 6.后面新增工具时要改哪些文件。

Kiro 这种偏规格和任务的工作方式，刚好适合把这些问题先摊开。

第一版功能怎么定

我没有一开始就把工具站做得很大。

第一版只定了几个最常用的工具：

1.JSON 格式化和压缩。 2.时间戳和日期互转。 3.Base64 编码解码。 4.URL 编码解码。 5.UUID 和随机字符串生成。 6.文本去重、排序和统计。

这些工具有一个共同特点：都可以在浏览器本地完成，不需要后端接口。

这对个人工具站很重要。很多时候我处理的是接口返回、日志片段、配置内容，不一定适合上传到第三方服务。哪怕只是个人使用，也应该默认本地处理。

所以我给 Kiro 的边界很明确：第一版不做登录，不接数据库，不做服务端存储，所有工具逻辑都在前端完成。

先搭结构，不急着堆功能

我让 Kiro 先做的不是某一个工具，而是项目结构。

工具站如果后面要长期加东西，结构比单个页面更重要。我的要求大概是：

1.每个工具有独立配置。 2.工具列表可以从配置生成。 3.工具页面有统一布局。 4.输入区、输出区、操作按钮风格一致。 5.工具逻辑和 UI 尽量分开。

这样后面加一个工具，不需要到处复制页面。

一个工具配置可以简单理解成这样：

export interface ToolMeta {
  key: string;
  name: string;
  description: string;
  category: string;
}

这类代码本身并不难，但让 AI 一开始就按可扩展结构写，会比后面再重构省很多事。

JSON 工具最适合打样

第一个实现的是 JSON 工具。

因为它能代表很多工具站的共性：有输入、有输出、有格式化按钮、有错误提示、有复制结果。

我让 Kiro 先做一个 JSON 格式化工具，要求是：

1.输入非法 JSON 时给出明确错误。 2.格式化结果缩进统一。 3.支持压缩成一行。 4.支持一键复制。 5.不清空用户原始输入。

这里我特别强调不要把错误吞掉。很多工具站只显示“格式化失败”，但不告诉你哪里错了。实际开发时，错误位置和错误信息很重要。

Kiro 生成第一版后，我主要看三点：

1.异常处理是否清楚。 2.输入输出状态是否互相污染。 3.复制、清空、格式化这些操作是否会让用户丢数据。

小工具看起来简单，但用户体验差通常就差在这些地方。

时间戳工具要照顾使用习惯

时间戳转换是我经常用的工具。

这里我给 Kiro 提了几个很具体的要求：

1.同时支持秒和毫秒时间戳。 2.能显示本地时间。 3.能显示 ISO 格式。 4.能一键填入当前时间。 5.输入长度不同要能自动判断秒或毫秒。

这些需求如果不说清楚，AI 往往会做一个最普通的转换框。但真实使用时，细节会影响效率。

比如日志里常见的是毫秒时间戳，某些接口里又是秒时间戳。如果工具不能自动识别，我每次都要自己数位数，这就不够顺手。

所以我现在用 AI 做工具时，会尽量把自己的使用习惯说出来。AI 不一定知道我平时怎么用，但它很擅长把明确规则落实成代码。

样式不要做成炫技页面

个人工具站最怕两种设计。

一种是太简陋，像临时 demo。另一种是太花，渐变、卡片、动效很多，但真正用的时候很累。

我给 Kiro 的要求是：界面要干净、密度适中、按钮明确、输入输出区域要够大。

工具站不是 landing page，不需要大 hero，也不需要很多宣传文案。用户打开它，是为了快速完成一个动作。

所以页面重点应该是：

1.工具入口清楚。 2.当前工具名称明确。 3.输入输出区域足够稳定。 4.主要操作按钮容易找到。 5.错误提示直接贴近问题。

Kiro 生成的第一版样式通常会有一点“模板感”。我会继续让它收敛，比如减小圆角、减少装饰色、拉开输入输出区域、统一按钮尺寸。

AI 做前端很快，但审美和产品取舍仍然要靠人把关。

我怎么和 Kiro 协作

这次我没有让 Kiro 一次性做完所有工具。

我的节奏是：

1.先让它根据需求整理功能清单。 2.再让它生成项目结构。 3.先实现一个 JSON 工具作为样板。 4.确认样板没问题后，再复制模式实现其他工具。 5.最后统一样式和交互细节。

这个节奏比一句话生成完整项目稳定很多。

AI 最容易出问题的地方，是在需求还没完全定的时候就开始大量写代码。写得越多，后面修起来越麻烦。

如果先把工具站拆成几步，每一步都能验收，AI 的产出就更可控。

代码还是要自己看

Kiro 能把代码写得很快，但我不会直接全盘接受。

我主要会检查这些地方：

1.有没有不必要的依赖。 2.工具逻辑是否可以纯函数化。 3.错误处理是否可靠。 4.复制和清空是否会误删用户输入。 5.是否有把用户输入发到外部服务的代码。 6.组件拆分是不是为了拆而拆。

个人工具站虽然不是核心业务系统，但它处理的内容可能很敏感。比如接口 token、日志、配置片段，如果某个工具偷偷接了外部接口，那就违背了我做它的初衷。

所以我会特别关注网络请求。第一版工具站只要能纯前端完成，就不应该引入服务端。

做完以后最大的收获

这个工具站本身没有什么高深技术，但它让我更明确地感受到 AI IDE 的适用场景。

它特别适合这种项目：

1.目标明确。 2.功能边界不大。 3.有一批相似模块。 4.需要快速搭出可用版本。 5.后续还会持续迭代。

工具站里的每个工具都不难，但如果全部手写，会有很多重复劳动。输入区、输出区、按钮、复制、错误提示、布局、配置注册，这些东西很适合交给 AI 提速。

但项目方向、功能取舍、隐私边界、最终体验，还是要自己决定。

后面想继续加什么

第一版跑起来以后，我还想继续加一些更贴近日常开发的工具：

1.JWT 解析。 2.Cron 表达式解释。 3.正则测试。 4.SQL 格式化。 5.Markdown 预览。 6.颜色格式转换。 7.常用 HTTP 状态码查询。 8.简单的 diff 对比。

这些功能仍然可以坚持本地处理。只有确实需要联网的能力，才考虑后端或外部 API。

我也想给每个工具加一点本地历史记录，但这部分要谨慎。历史记录方便，但也可能保存敏感内容。比较稳的做法是默认关闭，由用户自己决定是否开启。

小结

这次用 Kiro 做自己的工具站，我最大的感受是：AI 编程工具已经很适合参与个人项目的完整开发流程。

它能帮我把需求拆开，把结构搭起来，把重复代码写掉，也能快速补齐一些容易遗漏的交互细节。

但工具站最后好不好用，不取决于 AI 一次生成了多少代码，而取决于需求边界是否清楚、交互是否贴近日常习惯、隐私和本地处理这些底线有没有守住。

我现在更愿意把 Kiro 这类工具当成结对开发者。它能显著提高起步速度，但方向盘还是要握在自己手里。

我用Kiro做了个自己的工具站

前言