Vibe Coding实战

简介：

完整体验了一次 Vibe Coding。或者说——程序员角色扮演。

完整成果： cry4o4n0tfound.cn

心血来潮的 cry ：

在学习完基本的 typescript 以及一些 react 的知识后，我很想看一看一个 typescript + React 项目是如何构建的。

于是盯上了自己的博客——正如我之前在某一周的周记中提到过，打算用新一点的技术来重构一个真正属于自己的不基于老旧模板的博客。

当然了，受限于技术，我现在只能写基本的 typescript 逻辑，甚至某些语法糖用的都不是很熟悉，所以这次的重写基于 cursor 和 mcp 服务的集成，完完整整的体验了一次程序员 cosplay ，在 token 输出中体验着虚假的代码快感...

不过要真正体验比较可靠的 Vibe Coding 前，我认为还是需要一些准备，这里也为未来可能想要做 Vibe Coding 的大家提供一些参考与建议。

Vibe Coding 前的准备：

首先，一个可靠的 ai ide，也许是 windsurf、cursor、vscode + copilot，又或许是字节的 trae，或者 vscode + cline，支持 mcp 服务的 ide 是非常关键的。

因为我认为 Vibe Coding 最重要的一点就是如何把信息传递给 ai ，让它能更明白你的需求，就像我们在完成任务时喜欢将问题细化，越是精细的讨论，越能将问题分解成小步骤来完成——这有点像分治，但受限于模型有限的上下文，我们需要将自己的对应需求表达的更准确。

你不能一上来对着 ai 说：“赶紧的，给我生成个博客，我要这样的（放张图片给它）。”然后就拍拍屁股走人，希望它能给你生成完美的作品，回来一看，结果发现这生成的是个什么玩意儿，大骂 ai 是个蠢蛋。

显然，这是错误的。在 Vibe Coding 中你将扮演一位~~旅行者~~产品经理，如何将你的需求信息准确传递给大模型是最重要的，于是就引出了 mcp。

大模型对于自然语言的理解是不如 json 的，我们很难在有限的自然语言把需求以及对应的信息传递给它，mcp 则解决了这件事。

可以理解为，mcp 作为一个即时知识库，将对应需求转化为大模型通俗易懂的 json 格式 ——本质上大多数 mcp 服务器只是在做对应的 api 请求，把返回的 json 信息投喂给大模型，让它在使用尽量少 token 阅读信息的同时，来更高效的实现对应的需求，一定程度上解决了大模型上下文有限的痛点——也只是一定程度，近期 mcp 的话题不怎么热了，也是因为它自己抽象出来的这层接口也需要 llm 进行理解需要消耗一定的上下文，但这就是别的话题了。

接下来我们来配置 mcp 服务器。

MCP 配置：

我本次主要用到了 4 个 mcp 服务来构建这个博客，体感不错，在这里分享我的配置。

注：我使用 cursor，其余 ide 的 mcp 配置可能并不一样，请自行查询官方仓库查找对应 ide 所需配置。

github-mcp-server：

https://github.com/github/github-mcp-server

顾名思义，github 官方提供的 mcp 服务器，通过 api 请求的方式，使得大模型可以通过他们的 api 得知我的 github 上的信息。这对于重构先前的项目很有帮助，比如我之前的 hexo 博客托管在 github.io 上，那么大模型就可以通过这个 get_file_content 来了解我完整的目录结构，定向的检索有关内容，让它对于整个项目的构建有所理解。同时还可以一键提交，一键 pr，一键 issue，一键...反正很方便，让我 commit 都不用写了（甚至跟着学会了对应的 commit 格式，新特性是 feat: .... ，修 bug 是 fix: ....）。

我使用的是基于源程序的 mcp 服务器（也是用 go 写的，更加坚定了我学好 go 的决心），对应配置如下：

"github": {
      "command": "D:/github-mcp-server/github-mcp-server/cmd/github-mcp-server/github-mcp-server",
      "args": ["stdio"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "Your-github-Token" 
      }

任务大师：

https://github.com/eyaltoledano/claude-task-master

任务大师通过一开始的需求编排，将需求转换为一系列 task 文件，再将其转化为 task.json 文件，让大模型充分理解整个流程的运作和进行，让每一个实现更为清晰，省了我不少无用的口舌。本质上是从场外又调用了个 llm 做任务编排，同时生成对应的 .cursorrule 和任务流程文件，具体使用请参考官方文档。

我的配置如下：

"taskmaster-ai": {
			"command": "npx",
			"args": ["-y", "--package=task-master-ai", "task-master-ai"],
			"env": {
				"ANTHROPIC_API_KEY": "YOUR_ANTHROPIC_API_KEY_HERE",
				"PERPLEXITY_API_KEY": "YOUR_PERPLEXITY_API_KEY_HERE",
				"OPENAI_API_KEY": "YOUR_OPENAI_KEY_HERE",
				"GOOGLE_API_KEY": "YOUR_GOOGLE_KEY",
				"MISTRAL_API_KEY": "YOUR_MISTRAL_KEY_HERE",
				"OPENROUTER_API_KEY": "YOUR_OPENROUTER_KEY",
				"XAI_API_KEY": "YOUR_XAI_KEY_HERE",
				"AZURE_OPENAI_API_KEY": "YOUR_AZURE_KEY_HERE",
				"OLLAMA_API_KEY": "YOUR_OLLAMA_API_KEY_HERE"
			}

Figma：

https://github.com/GLips/Figma-Context-MCP

这个 mcp 服务器可以将设计的 Figma 图案以链接方式传递给大模型理解，让大模型复刻你在 Figma 上设计的图案。非常方便，但这次我没用到...因为我不会设计，等待某位设计大佬的成长来捞一捞我。

我的配置：

"Framelink Figma MCP": {
      "command": "cmd",
      "args": ["/c", "npx", "-y", "figma-developer-mcp", "--figma-api-key=YOUR-KEY", "--stdio"]
    }

交互式反馈：

https://github.com/noopstudios/interactive-feedback-mcp

对应的 ai ide 一般对每次对话的工具调用（也就是 mcp 中所谓的函数）有限制，以及每次对话中可能对话中途你就想做对应的更改，如果此时中断就浪费了对应的额度，交互式反馈可以帮助进行中断，重新设置需求，大大节省了我的 cursor 使用次数。

Stagewise：

https://github.com/stagewise-io/stagewise

非常好用的前端工具，可以锁定网页上对应的 DOM ，直接在网页上对话将其传递给编辑器中的 llm。但这次因为在 react 上的 bug 没有使用，让我费了好大劲儿去给 llm 找对应的 DOM。

CodeRabbit：

除此之外，我还使用了一个 vscode 插件——CodeRabbit。它会在每次 git commit 之前，对你（或者说 ai 的) 的 code 做一次审计，检查不安全以及不合理的实现，非常好用，这里检查到了它本次 Vibe Coding 中的唯一错误——由 cry 编写实现的 steam api 请求没使用 https 会泄露密钥...当然，现在修复了，就别想着看密钥了。

个人用户的免费额度也基本够用，对于一个完整 Vibe Coding 的项目来说很有帮助。我称之为（VibeCoding) ^2。

以上是我本次使用的 mcp 服务器配置，如果你感兴趣，不妨也尝试配置你想实现项目对应的 mcp 服务器来进行一次 Vibe Coding。这也是一场很有趣的经历😁

成果与反思：

从这次实际使用 Vibe Coding 的体验来讲，称得上受益匪浅——我不仅借此重构了自己的博客，也成功理解了一个 Next.js 项目目录结构和完整的构建过程。

但在享受这些便利的同时，我能感受到我与这个项目之间还是割裂的（还是有那么一点点联系， steam 请求的 api 接口是我用 go 写的😂），它的维护依旧是困难的（但是比 hexo 冗杂的目录简单...那个才是真的一点没参与构建），因为本质上没有经过严格 review 的代码，是难以理解的。

所以我认为 Vibe Coding 构建一些不太严谨的项目还是非常好用的，但真正到了工业级别，无论是架构选择，还是性能优化，llm 的上下文肯定是不够支撑的。至于未来，未来是什么样我管不着，我得先在两年后吃上口饭先...

在 Vibe Coding 风靡的当下，我认为代码能力可能会在未来的程序员中好的更好，坏的更坏。就我个人而言，我觉得未来 2 年会写代码可能会大大加强就业能力，因为最近的大学生都被 Vibe Coding 惯坏了（比如 cry）。

不过这并不是让大家就不去 Vibe Coding 了，我可不是二极管，要不然也不会写下这篇文章，Vibe Coding 这种东西还是得亲身体验才明白。

Just Coding ！