当前位置：首页 > news >正文

我的vibe coding初体验

news 2026/6/6 19:38:45

注：
如果遇到了具体的下载问题，可以检索或者直接问我，如果不忙的话，我会很乐意能帮到你们。
如果对我vibe coding的具体项目感兴趣，可以在YozaPomo-Github或主页查看代码和我的心路历程。

啥是vibe coding？

翻译为氛围编程，说人话就是让ai帮我写代码，我当键盘侠，对他指指点点。

Claude Code

1. 安装 Claude Code

Git，如果是从头开始要先下载Git，但我是糕手😶‍🌫️，就跳过了。
VS Code？大概会需要吧，我倾向于下载CLI，当然如果你喜欢VSCode，用VSCode集成Claude Code也是非常不错的选择。
Claude Code，主角来了，2026年6月份官方提供的Windows一行下载链接
```
irm https://claude.ai/install.ps1 | iex
```

然后claude就可以打开。

2. 配置 Claude Code

首先，我肯定是准备使用便宜好用的国内模型，在网上检索到有一些开源的项目可以做到：cc-switch和 claude-code-router，如果没有看到第二个的记录，那肯定是我第一个就成功了😋。

CC-Switch
1. 在cc-switch中下载Windows的msi版本，一路下一步，成功。
2. 打开cc-switch(居然有图形化界面)，点击右上角的加号，添加自己喜欢的模型
3. 回到Powershell，输入claude 回车回车
4. 提问“你是什么模型“，回答“mimo-2.5”，出乎意料的简单

怎么vibe coding？

告诉ai需求，让他生成代码，然后 run！起飞 🛫🛫
“帮我把前端后端都写了”

很显然，以上是正确的😶‍🌫️😶‍🌫️，只不过vibe coding的正确姿势需要拆解下这句话。对，《只不过》… …。

我希望ai能完整的听懂我的意思，并有计划的一步步实现、测试。所以这是我现在感觉比较稳妥的流程

打磨需求/技术选型 -> 分步开发规划 -> 步骤1开发文档校验 -> 开发 -> 测试 -> 步骤2开发文档 … …

1. 告诉ai需求，再让ai给你你的需求

如果你不太在乎这一点点的Token，你可以打开Plan Mode，或者像我一样在网上随便选一个网页版的ai(抠门这一块的)，详细的阐述你的软件需求

我是一个不懂代码的小白(有点经验/经验丰富的程序员/无敌的大佬)，想做一个xxxxxx
功能介绍…
页面介绍…
UI介绍…
以上是我的想法，帮我进一步整理我的需求，做好技术选型
如果有不妥的内容做好记录并提出优化建议，如果有不确定的地方先问我，我们先沟通需求，等我确认好再进一步执行。

这一步可以多找几个AI，反正不消耗Token，总会有一个靠谱的… 吧。

需求文档是这个项目的地基，没有好的需求文档，后面拿到的代码大概率也是一团乱麻。在解决完所有问题之后，仍然需要检查和打磨这份文档。我的方式是通过手动检查和修改后的文档，继续发给ai检查仍然潜在的问题，这时候就需要分辨哪些问题是需求问题，比如我的ai就会问我建表语句相关，这很显然是后续才会涉及的内容… …

我准备通过vibe coding来实现一个项目，帮我检查下当前的需求文档
… …

2. 生成开发计划(不积跬步，就是没走😐)

此时此刻，我们手中已经有(可能)完美的需求文档，最后让免费劳动力生成一份README.md，后续的计划我总不放心交给网上的流浪AI，就打开Claude Code，键入神圣的/plan指令，开始做计划(被迫做一个J人)。这一步也是处处小心的告诉克劳德：

为了让项目稳定完全有效的推进，阅读文档目录，永远不要尝试修改需求文档下的文档，在开发日志对应位置记录修改和优化。在docs下生成技术、设计规范执行步骤等具体标准，在Claude.md中添加指引各标准文件路径及工作说明。(需要我确认的内容需要用中文解释)
– – 引用自抖音@大牙大

但是因为步骤稍有不同，我会更期望他这次不生成开发计划

为了让项目稳定完全有效的推进，阅读文档目录，在docs下生成除开发流程外的技术、设计规范执行步骤等具体标准，在Claude.md中添加指引各标准文件路径及工作说明。

这一个步骤的开销会稍微有些大，如果只是想试试，可以试着增加一点诸如简介简单之类的限定词。

如果你和我一样，生成了开发的计划，可以尝试让他再次检查
根据需求再次检查开发流程，是否有什么问题，让我每一步能测试，尽量在图形化界面测试或Swagger
如果没有生成，这时候就可以根据项目的大小生成开发计划了
规划开发的步骤，(一次性不要做太多)，让我每一步能测试，尽量在图形化界面测试或Swagger
不要忘记Git提交一下🤫

3. 然后就是开发环节(原来是刚开始吗？)

马上要结束了也说不定，直接告诉ai开干！

根据开发流程逐步推进，保留开发日志，每次验证时由我验证

然后，所有项目都一样的，他会给你准备环境，这时候就疯狂的点yes。

下载 – yes

更新文件 - yes

… … - yes

它干了啥？谁知道呢？ - yes yes yes！！！🫨🫨🫨

Tips：
其实还是要稍微看看的，要不会… … 很无聊。

4. 修改bug和优化

最恐怖的内容来喽，为了让这个漫长又繁琐的时间出现不可控的修改的概率降低

我将在docs/需求文档/(指定目录，替换成你放需求的目录)目录下新建文件来记录bug和优化项。
每次只修复一个bug或优化一处内容，
修复前，请先描述：
如何触发这个 bug
你认为最可能的原因是什么
你打算改哪几个文件
做完交由我验证，验证后我修改需求文档下的状态，然后你在开发日志目录下对应文件记录并一同提交。

随后就是漫长且略显枯燥的改bug时间