Vibe Coding 经验总结

Vibe Coding 实践中的一些经验总结。

模型选择

从最开始的使用 MiniMax 2.7、再到 智谱GLM5.2、再到 Kimi 2.5、再到第三方中转站对接的 Claude Opus 4.6｜7｜8、再到 DeepSeek V4 First。

单纯从个人使用体验，可以感觉到国外的模型是相对比较强的更准确更少的思考次数更聪明点。但国内也是有很好用的模型比如 DeepSeek、Kimi、智谱。

如果将国内的模型硬要排个顺序的话，只能这样排序：DeepSeek（便宜且很聪明）> Kimi（较贵且很聪明） > 智谱（较贵且聪明） > MiniMax（便宜但不聪明）。

工具推荐

最开始使用 Cursor 这类 AI 编辑器，它提供 Chat、Agent 模式，通过输入需求即可帮助修改代码和文件。

虽然很方便，但仍需要手动编写部分代码，无法做到完全不写代码。同时，Cursor 的上下文长度不易控制，聊天内容过多时容易出现幻觉（可能存在解决方法）。此外，Cursor 需要会员，平时使用不多，高峰期使用较好的模型还需要长时间等待。

因此，我开始寻找其他 AI 编程工具。恰逢 MiniMax 发布 2.7 模型，于是通过 CC-Switch 接入 Claude Code，开始转向 CLI 类型的编程工具（实际上 CLI 还能完成很多编程之外的事情）。

CLI 工具只需要输入整理好的需求，剩下的代码编写工作基本都可以交给 AI，实现完全不写代码。相比之下，Cursor 的体验就弱了一些。

Claude Code 除了 CLI 版本，也有客户端版本（个人使用较少），Codex 也是如此。个人推荐：CLI（方便）> 客户端（较方便）> Cursor 类 AI 编程工具（不太方便）。

最后的方案是：VS Code 作为修改代码的编辑器、使用 reasonix 作为 Claude Code 的替代。

reasonix 是开源社区维护的一个对接 DeepSeek 模型的编码。

开发流程

此处只介绍如何开发项目思路流程，不涉及具体功能介绍、工具的安装、环境配置等，请自行查阅官方文档。

设备环境：MacBook Air 2022年（macOS 26.4）  
语言模型：deepseek-v4-flash  
编写工具：VS Code  
编码 Agent：reasonix  

初始化项目

在开发项目的初期（在已有项目的情况下），需要让编码 Agent 初步了解你的项目，生成项目整体概况的文件，如：CLAUDE.md。在 reasonix 中则是 AGENTS.md。

通过命令 /init 生成，执行命令后，编码 Agent 会自己阅读整个项目整理归纳总结，包括：项目主要功能、所有技术架构、目录结构模式等信息。

如果需要创建一个新的项目，可以建一个新的项目文件夹，然后让编码 Agent 帮你生成初始的项目文件。如：帮我生成一个博客项目使用 Golang 语言，前端使用 Vue ...，同时帮我执行 /init 命令。

这里的提示词只是个大概具体的需要根据项目编写。更复杂的可以在项目中新建一个 Markdown 文件（其他文件也行，文本文件也行，能完整描述整个项目就行）

文件中记录完整的项目信息，如：

这是一个个人博客网站

使用的技术架构是 Gin 作为 web 服务器。前端页面使用 Vue 框架、并使用 Naive UI 组件库。

项目目录结构：

blog-sever
blog-front

注意事项：
保持尽量少的代码，同时前端不要自己编写样式代码，一律使用 tailwindcss 作为样式代码。
...

这也是个示例文件，需求或者说明越详细，生成的项目约符合预期。（其实这个文件就是 /init 将会生成的文件）

前置工作

在正式开始和编码 Agent 对话并让其编写代码前，最好进行前置工作。这个工作是为了告诉它，项目里的代码需要如何防止编写，哪些地方需要注意，等等。

代码规范

举个例子：

go 语言有一份官方的代码规范 Effective Go，可以把它放到项目中专门存放文档的目录中。通常我会创建一个 docs 的文件夹存放。

在里面在创建多个文件夹如：rules、api、business、other 等。分别存放规范文档、API接口文档、需求原型、其他文档。

在记录好规范文档后，需要让编码 Agent 能够识别到该文档，那就在 /init 命令生成的文件 AGENTS.md（CLAUDE.md 这是 Claude 的）中添加上，因为每次与编码 Agent 对话时，它总是会先阅读一遍这个文件。添加的内容，如下：

## Rule

- After making changes to the project, you need to update the CLAUDE.md file.
- When developing new features, refer to `backend/docs/开发指南.md` for the complete workflow (model → db → handler → router) and layer-specific conventions.
- Coding rule document `backend/docs/Effective Go - The Go Programming Language.md` and `backend/docs/Go编码规范.md`
- The code you write must adhere to these principles `设计模式6大原则.md` and `软件架构规范.md`
- Key architectural constraints:
  - Handler defines its own interfaces (consumer defines interface, producer provides struct)
  - Never call `bcrypt` directly; use `pkg/password` facade
  - `config` package is a pure library and must not parse command-line flags
  - One entity per file in `model/` and `db/` packages
- If the changes involve the API, please remember to update the API documentation: `backend/docs/api`

如果你不想自己加的话，页可以起一个对话，告诉他在哪里叫它帮你添加（如果你足够懒的话，可以叫它做很多事）。

可以看到我添加的规则中还有一条 - After making changes to the project, you need to update the CLAUDE.md file. 这条规则是让编码 Agent 每次执行完对话后，就修改一遍 CLAUDE.md 文件。

因为之前说过编码 Agent 每个对话都会先阅读一遍这个文件，所以保持其是最新的是很重要的，比如增加了一个业务接口生成了 API 文档，要让前端项目能知道，在对话完毕后，它会自动把该接口的简介添加到文件中。编写前端代码的对话就能够读取。

原型需求

编程开发到现在这个时代，感觉 AI 已将帮我们把代码编写的工作完全接手了。那剩下的就是前期的需求分析、原型设计等，更多的分析设计工作。比如模型字段、功能流程、等。

为此我会专门创建一个叫 business 的文件夹（名字不重要），在里面为每个业务模块创建一个文件：user、db、等。每个业务模块中编写好，模型的定义、请求接口的参数、返回参数、处理流程、注意事项。

然后我会启动一个对话把这个文件夹贴给它，让它帮我阅读理解，可以让它先给我一个方案需要修改哪些代码，增加哪些代码，等它返回结果判断一下是否符合我的预期，符合就告诉它进行编码。不符合则告诉它哪里需要修改，直到符合我的期望。

通常这些编写的需求原型文档，已经足够了，足够生成代码，同时可以利用这些文档生成 API 文档，存放到 docs 中的 API 文档中。（当然是让它帮忙生成）

进一步的

比如我开发一个工具模块放在了项目的 utils 中，可以让它帮你阅读一下这个工具模块并生成一个使用文档存放到同级目录下。每次需要要使用到该工具时，直接告诉它查阅文档。

现在也有很多 skill 可以直接查阅很多第三方库的文档，如：context7。或者可以自己写一个 skill ，不过暂时没研究。

注意事项

最后通常我会创建一个名为 claude_chat.md 用来记录每次我写对话，这样如果有类似的对话就能很快速的修改复制发送。当然可以通过 /rewind、/history 等指令查看历史对话。但我还是习惯单独记录在一个文件中并存放到最外层目录下。

需求编写

在上面的前置工作都做完后，已经准备好了规范文档和各种开发文档后，就可以开始编写需求了。我通常会在 docs 目录下创建一个 business 中编写最开始的需求文档。

在文件夹中创建了一个需求文件，编写在代码中的那些层级需要增加那些功能接口方法，最后时注意事项。下面是个示例：

功能背景：
一个用于 xxx 的功能模块

---

API 层：
一个 xxx 接口
参数：
{
    xxx xxx
    xxx xxx 
}

处理逻辑：
1、先获取数据
2、做 xxx 处理
3、返回 xxx 数据

---

其他 层：
一个专门处理 xxx 的方法

处理逻辑：
1、xxx
2、xxx
3、xxx

---

调用逻辑参考：
backend/docs/business/aaa.md

底层功能实现接口：
backend/docs/business/bbb.md

...（其他补充说明）

编写好初始文档后，可以让编码 Agent 帮你补充完善细节生成一个份更详细的需求文件。然后再仔细看一遍里面的描述预期是否有出入。没有出入就让编码 Agent 根据这份详细需求文件进行编码开发。

文件中可以提及其他参考模版文件、底层具体实现功能需要调用的方法接口的文档。如示例中的最后两部分。注意！大语言模型是很灵活的，可以让它干很多事情，不要局限自己的想法。

代码生产、审核

在项目的详细需求文档生成后，剩下的就是让编码 Agent 进行编码工作了。这一部分基本上没什么好说的，因为大多数情况下，是不会中断它生成代码的过程的。通常都是一路 yes 到底。如果不小心点到 no 了，可以发 请继续 它就会继续工作。还有编码 Agent 基本上都是自动模型，即不需要你一直点击 yes ，自动跳过人工审核。

编码工作完成，编码 Agent 也会帮你进行一遍代码审核包括：语法、编译、等。等待它全部执行完毕后，我会再大致的看过一遍代码，是否有些不符合预期的。有的话我会记录下来，哪里出问题，我希望要怎么改。编写好这些东西后，重新发送给编码 Agent 让它帮我修改。一般情况下，我很少手动修改代码，避免修改部分代码而遗漏了其他地方。

遗留问题

最后的遗留问题是即使代码生成完毕，功能模块也完全实现了。到最后项目的实际运行，实际效果，还是需要我来确定。这一步基本上无法跳过。人总要完成最后的把关工作。即便有些代码可以实现单元测试、和其他的自动化测试。但最后的效果还是需要人介入。

结束

在现在大模型已经可以帮我们完成很大部分工作了，但最后看来，我们可能从繁琐的编码工作中跳出，回到最开始的需求分析、原型设计、代码审查、项目验收。更像软件开发周期的中前后工作。

初级的编码工作已经被替代了，但更多的是转变成需求审核这些工作。因为最后使用工具的还是我们。

（上述内容可以能还有不足错误之处，请见谅，确实还有很多地方需要在细节研究学习）