一个月Vibe Coding：我写了什么，又学到了什么

近一个月，我使用Alma客户端搭配Kimi模型Vibe Coding了若干小玩意，本文记录一些过程和想法。

用量统计

账单显示一个月总消费361.8元，日消费峰值未超80元。从4月24日到5月22日，累计输入Token 1.92亿，输出Token 113万，Cached Token 1.85亿。以上均为Vibe Coding消耗，期间经历了Kimi 2.5升级到Kimi 2.6。

做了啥

1、一个稍后阅读应用

服务端基于Supabase + Cloudflare，客户端基于Flutter开发了iOS版，并开发了Chrome插件。这是Vibe Coding练手项目，从服务端到客户端全部跑通了，产品基本达到可用状态。

2、一个高度定制的博客系统

• 开发了一个Obsidian插件，使用Github API将笔记发布到仓库。
• 基于Astro开发了一个静态博客生成器，集成giscus评论。
• 博客生成器和文章分属独立仓库，确保文章发布和博客迭代互不干扰。

最终，创作和发布全部在Obsidian内完成，体验很流畅。下图为部署在Cloudflare Pages上的示例站点。

• Typecho博客所在的阿里云服务器尚有一年，到期前不想折腾。
• Typecho博客有几千条评论无法迁移到giscus。

3、开发Typecho的warmpaper主题

Typecho主题开发详见《Typecho升级到1.3，使用Warmpaper主题》，此处不再缀述。

4、日常开发脚本处理解决一些小需求

比如这篇文章介绍的Rime输入法五笔词库管理脚本，便是AI生成的。

一些感受

1、「我有一个想法，就差一个程序员」已成历史。

这句调侃产品经理的段子，如今彻底过时了。我折腾的几个项目，几乎没有手写一行代码（仅偶尔手动改个文案，此场景没必要消耗Token），全部是通过自然语言在对话框中完成的。

如果一定要加个条件，AI至少在CRUD类业务逻辑和前端/客户端相关的功能开发上，已经非常好用了。

2022年我开发Pinfive网站，没有AI加持，在一个Python开源项目上魔改，过程不可谓不艰辛。若今天用AI重做，估计两个小时就能做出来。

2、但是，想用好Vibe Coding，还得懂点技术和软件工程规范。

我不确定完全不懂技术的人Vibe Coding的真实体验如何。但我确信，Vibe Coding对我这种没在生产环境写过代码，但对API、函数、数据结构、schema等等编程概念非常熟悉的产品经理非常友好。

Vibe Coding时，我仿佛在和一个技术能力很强，但经验不丰富的程序员打交道。在磨合和过程中，形成一套流程：

• 先和AI讨论一个产品想法，将其细化为PRD。
• 然后，再与AI讨论技术选型，我会提些要求，比如网络环境要求国内、国际都能正常访问，客户端开发要求ios/android一套代码等等。
• 接着，我会和AI讨论数据库schema和api设计，输出技术方案文档。
• 最后，要求AI严格按技术文档写代码，并让AI自己写测试用例，所有测试通过后再找我验收。

这和真实工作中产研合作流程如出一辙。

如此，AI产出的稳定性和确定性提高不少。道理很简单：需求不讲清楚，AI很容易自由发挥，导致产出不符合预期。工作中提「一句话需求」，技术同学会直接驳回，但任劳任怨的AI，就会陷入盲目发挥。

3、Alma + Kimi的能力边界和特性

使用Alma + kimi 2.5（后来升级到2.6）进行Vibe Coding，我观察到一些特点：

• AI很喜欢长篇大论和coding：有时候我只是想就方案中某个细节深入讨论，但AI会长篇大论的把整个方案复述一遍，甚至直接coding（超级浪费Token）。以至于我现在常常强调「我们来讨论一下xxx，先别写代码」。
• AI经常对代码进行大范围编辑：有时只是很小的需求调整，我确定只需要很少的改动即可，但AI却会进行大范围增删代码，这让人非常不安。同样的，我会用prompt控制，让AI先输出方案，说明改动的文件、代码及理由。
• AI在技术选型时倾向于国外方案：尤其是SaaS服务选择时，默认都是选择国际主流方案，但这些方案未必适合国内。比如supabase + vercel在国内就无法访问，虽然这套方案Vibe Coding真的爽到爆。
• 在代码部署方面，自动化还不够：本地运行正常，部署却报错，我目前还是人肉搬运错误信息给AI，让AI修复。这部分的瓶颈不完全在AI模型，也在于开发者工具对AI是否友好。
• 没有错误日志的问题，AI容易「鬼打墙」：有错误日志的问题，AI通常都能解决。没有错误日志时，AI容易瞎猜乱改。比如我用Flutter开发iOS App，编译到iPhone真机上，首次运行正常，但kill app后重新打开，就会闪退。Xcode终端没有错误日志，Kimi分析优化了几轮也未解决。后来，我把问题抛给Gemini，让他猜测一下可能的原因，Gemini点出了要点：这是Flutter Debug模式的问题，和代码没有关系，使用release模式编译就解决了。
• 更长的上下文，不一定有更高的准确率：开发warmpaper主题时，不同子话题，全部在一个对话框内完成，上下文极长。到了后来，一些小迭代，AI也要思考很长时间，并常常犯错。观察Kimi的思考过程，有时就是无关上下文引用导致。上周读到《你的AI Agent越用越蠢？港中大、浙大戳破「记忆」的谎言》，文中提到AI的记忆只是备忘录，非人类的那种记忆，深有同感。
• 涉及到UI的调整，靠自然语言沟通困难：UI调整有时候不好用自然语言描述，Kimi有多模态，截图+自然语言描述，能解决部分情况。

4、Vibe Coding让人上瘾

编程是一个反馈很清晰的活动，从产品想法到MVP，再至体验完善，所获得的成就感极强。古法编程比较慢，偶尔还会卡在一个问题上几个小时，容易打击信心。但Vibe Coding加快了反馈速度，你说一段话，AI几分钟就能修改一版，立马查看效果。很快的冒出想法，很快获得反馈，太容易上瘾了。我经常Vibe Coding到忘记时间。