为了不浪费 Kiro 的 Claude AI，我聊了个新项目，已经对这个项目的重构。
新项目是一个云端记忆系统，用于解决用户在多端、多AI的记忆共享问题，以及多用户的记忆分享。
我认为记忆和开发规范和SKILL其实差别没那么大，越是开发得深入，越是觉得是一回事。但是由于额度有限，我在一个较为稳定的阶段收手，同时保证该项目能够正常、方便的用起来，还准备给朋友用。总之效果真的很惊艳，就干了一天，感觉我自己写不出这好的项目，甚至需要半年的时间，还不一定有他写得好。充值就能变强。
开发中，我深刻感受到当前的一个趋势是云开发，kiro就是云开发，就算它有桌面版，但是web版也好用，而且这个东西看代理，没有代理就降智到ds模型，有代理就给你用claude 4.7。其实GPT的网页版，背后也是云开发，这个连招的顺序就是，通过在 web里聊好项目，慢慢开发，每次往绑定的github 仓库里推送，然后本地服务器用hermes，直接按照github仓库项目，并启动，甚至配置域名代理出来。
这次把 Kiro从30 踩到 90，一个从头搞了一个开源的云记忆系统，EchoMe，一个就是这个博客的重构，非常的满意。4.7 你真厉害。
全程，自己几乎不敲代码，当然，为了节省，有时候 clone 和 build 我还是会敲。
但是如果，kiro在自己的开发环境没问题，然后在我的生产有问题，那么我也不想，也看不进代码的时候，hermes 就决定是你了，你帮我把这个项目排查、修复、启动吧。
比如这次，我的项目在本地一直有个bug，编辑的记忆，无法保存，而且前几个小时是好的。kiro也排查不出来。后来只能让 hermes在生产环境排查，hermes的主职其实是不参与代码的，代码是kiro负责的，但是它排查出是 pgvector 这个库一个字段的长度不对，我真实僵住了，因为长度不对，最后事务commit不了，但是kiro不知道我本地的情况，虽然所有代码都是它复杂的的，但是长期开发过程中，技术的迁移，数据的迁移，最后就出现了这种bug。这种换我，我也不知道啊，只能说牛大了。
以上都是优点，后面 hermes 在给我重构这个blog项目的时候，也是因为调整结构，从docker volume迁移到数据目录挂载，然后顺手给我删了volume，我X你啊，hermes，你这个CS，这么顺手的吗。我数据都没迁移出来，引以为戒！
充实的一天，blog全部重写吧，旧的不去，新的不来，时常记录，多活几年，看一看未来！