在 vibe coding 已经成为日常之后，下一步自然就是在实际项目中应用，这一点也在上月的月报中提到。
日常开发是琐碎的，由于本月的重点放在了团队英文技术站点 - Mona 和工业 Agent 专家团队上，对于新型花式 Vibe Coding 姿势并没有过多专注。
本月强调的实践
月初，在开发会议上发觉团队的 Vibe Coding 的上若干问题，于是总结成了文章：忽视了这些，给你的 CLaude Code 配再多工具也没用，主要观点：
- 缺乏任务所需的知识体系将很难驾驭 ai
- 迷信工具并不能给你带来惊喜
- 一组我们总结的 ai 工具规范和经验
总的来讲，我属于极简派，不主张一开始就靠堆砌工具和其他辅助设施的方式来进行 Vibe Coding。该观点在AI 夺命三连鞭，兼谈为啥在 vibe coding 时我尽量手动运行 tools。也有提到。
本月尝试的工具
我们在这个月也简单地尝试了将 aws 的 kiro 应用于项目中，但初步感觉是：革命尚未成功，kiro 仍需努力 😄。【参见附录中来自我们团队成员的使用体验。】
另一个值得一提的是将 Claude Code 对接到 Gemini 上，打算看看这种嫁接是否能带来某些意想不到的效果。
我看到的趋势
从各方面来看， cli 都是大势所趋，各家都在积极地推自己的 cli 工具，连带着 TUI 相关框架和库也开始得到一些关注。这其中， Groq Cli 有点不一样，详见 Groq Code CLI 工作机制揭秘：
它并没打算成为新的 Claude Code 或 Gemini CLI，而是为开发者提供了一个白标解决方案，让他们能够构建自己的 Coding CLI。
不少文章都提到：上下文管理才是 Vibe Coding 的核心，这一点倒是跟我的观点高度一致。同时，我也看到有相关论文在进行相关尝试，主要集中在 agent 的 memory 和经验学习上。
附录： kiro 的体验
提示：
- 下面内容来自未经修饰的原文，请过滤情绪部分，客观参考！
- 大量使用集中在本月中上旬，成员最近的反馈：
最近偶尔使用，除了
trust command无效这个 BUG 似乎有所改善之外，其他 BUG 依旧。
spec 模式华而不实
- Spec 模式乍一看很好，非常唬人，尤其是还会自动生成 design, tasks, steering 等等相当专业，实际这些东西大部分情况下并没有给 AI 提供足够有效的上下文，感觉根本没生效一样，反而浪费大量的宝贵的上下文资源，导致它忽视重点
- tasks 列表一眼看上去相当专业，但是由于太过细粒度化，反而导致了整体代码把控不佳
- 比如由于 task 的细分化，可能它执着于在单一文件上“雕虫小巧”，能在单一文件上反复修改玩出花来，可惜对于全局毫无用处
- 子任务的做法往往会导致忽视上下文的前提 —— 将任务打散，本质上是为了让任务细化，但是细化后的任务又需要符合全局总任务的大方向，而 kiro 过于详细的 tasks 会导致 AI 很可能忽视总 task，也就是这么做的目的是什么？太过于执着于在细微处发力，忽视了总体方向
这一点反倒不如 Claude Code Vibe Coding + 子任务的规划模式
一直未解决的 BUG 项
官方对于一些影响体验的 BUG 修复并不那么上心，甚至出现了官方开发者下场跟用户互怼的名场面
- trust command 经常无效，明明已经添加到 trust 列表了，还是没完没了的让我确认命令执行
- 终端交互BUG: 经常出现命令都执行完了 command 还在 waiting，有时甚至永远 waiting 停不下来，或者终端还没执行完毕，结果 command 结果就被显示成 success了
- 动不动就会出现
An unexpected error occurred, please retry.，然后就挂了，UI部分也没有 retry 按钮，内部也不会自动 retry，这一点相比 github copilot 体验差了好多