Vibe Coding，也就是 “氛围编程” 这个概念已经火了很长一段时间了，可惜主包之前碍于种种原因一直没能找到机会亲自试一下。不过就在上周正好要做一个新的系统，给了我尝试 Vibe Coding 的机会。现在系统已经搭建完毕，本文就用来记录这一周多一点的 “氛围编程” 体验吧。

什么是氛围编程 (vibe coding)？

引用 Google Cloud 上对 Vibe Coding 的介绍：

氛围编程 (vibe coding) 是一种新兴的软件开发实践，它使用人工智能 (AI) 根据自然语言提示生成功能代码，从而加快开发速度，并让应用构建变得更加容易，对于那些编程经验有限的用户尤其如此。

该术语由 AI 研究人员 Andrej Karpathy 于 2025 年初创造，用于描述一种工作流，其中开发者的主要角色从逐行编写代码转变为通过对话风格更浓的过程指导 AI 助理生成、完善和调试应用。这样，您就可以腾出时间和精力思考大方向或应用的主要目标，而 AI 则负责编写实际代码。

在实践中，氛围编程通常有两种主要的应用方式：

• “纯”氛围编程：在这种最探索性的形式中，用户可能会完全信任 AI 的输出能够按预期工作。正如 Karpathy 所描述的那样，这就好比是“忘记了代码的存在”，因此它最适合用于快速构思，或者他所说的“周末即兴项目”，在这些场景中，速度是首要目标。

• Responsible AI 辅助开发：这是该概念的实际专业应用。在这种模式下，AI 工具充当功能强大的协作者或“编程搭档”。用户会指导 AI 操作，然后审查、测试并理解 AI 生成的代码，因此对最终产品拥有完全的所有权。

在我这一周多的工作时间里，我才用的算是介于这两种模式中间的第三种模式：

• 向 AI 描述任务，指导 AI 操作，设定架构（哪些代码该放在哪个文件夹下），同时框定限制（比如些许代码格式）。
• 一些并不全面的审查，然后尽量不去理解 AI 所编写的代码的具体细节。

打个比方就是：

我要求 AI 收拾书架，第一层放编程类书籍，第二层放小说，第三层... 并且按照从高到低排序。
最终 AI 排好了，我看了一眼确实是从高到低排序，也是按照编程类、小说... 的顺序放置。
但是我没有去具体的了解每层都有哪些书。

我做了个什么系统？

我这个的任务是要开发一个小系统，它的作用是尽可能地将 “GitLab MR Review” 这件事自动化起来，并且接入 AI 与思码逸辅助 Review。这套系统的运行流程基本如下图所示：

任务拆解

从流程图上来看，这个系统需要实现以下功能：

• 它需要部署到服务器上，这里我选择的是 Docker。
• 有一系列围绕 GitLab 的功能。
  • 监听 MR 中的一些行为事件。
    • 评论的发布。
    • 标签的修改。
  • 在 MR 中发布评论。
  • 为 MR 评论评论添加 emoji（未在流程图中体现）。
  • 为 MR 设置标签。
  • 通过 api 触发 GitLab-CI 流水线。
• 封装多个 Review 辅助系统。
  • AI api。
  • 思码逸 api。
• 第三方通知系统。
  • 这里我接入的是其他部门提供的企业微信机器人发送消息接口。

技术栈

熟悉我的都知道，我之前有 python + Flask 开发后端系统的经验，所以本次这个小型系统主包也采用了相同的系统架构设计。

其余三方库方面主要用到了以下这些：

• flask-redis
• python-gitlab
• python-dotenv
• dynaconf
• dataclasses-json

其中最后两个是 AI 推荐使用的，主包之前并未接触过。

AI 客户端方面我主要的以下这些：

也就是说交给 AI 的工作中，75% 是使用 “免费版的 Gemini-CLI + gemini-2.5-pro 模型” 完成的。

之所以用免费的 AI，主要原因还是穷。非要说得好听一点就是想看看 AI 的下限在哪里，又或者大部分人应该用的都是免费的 AI。

另外需要说明的是，在这次工作我没有使用任何的 mcp，也没有使用任何的 AI 配置文件，比如 GEMINI.md 等。

最终效果怎么样？

抛去项目初始框架的搭建以及部署，几乎所有业务逻辑我都是提供任务描述之后 让 AI 给我实现的。那么结论也就像标题说的这样，对于我这样一个初次尝试 Vibe Coding 的小白而言，可以说是 “又爱又恨”，感觉也是和互联网上大部分人的感受一样。

爱在哪里？

AI 的强大无需多言，可以说 80% 的任务它都完成的很好：

• 我没有看过 python-gitlab 的文档，我只需要告诉 AI 要使用这个框架，它几乎就可以使用正确的 API，而就在去年，网页版免费的 ChatGPT 还做不到这一点。
• 只需要告诉 AI “我希望实现配置热更新，这样在我修改配置时就不需要再重启 Docker 服务了”。它就给我推荐了 dynaconf 这个框架，代替搜索引擎的同时还帮我实现了需求。

这个小系统虽然简单，但是它也有一个需要用到算法的地方：在使用 AI 辅助 Review 时，如果代码 diff 过长会导致超出模型的上下文，此时需要分片多次提问。在这点上 AI 处理的也很好，让我真正感受到了什么是 “面向结果而不面向实现细节”。

恨又在哪里？

• 调用 python-gitlab 中的方法时，有过好几次使用了错误的返回值的情况。需要我手动查看源码后再告诉 AI 正确的返回类型是什么。
• AI 稳定性可以说是让人捉摸不透：它能很好的推荐你通过 dataclasses-json 解决 “接口参数驼峰式命名” 与 “python 属性下划线式命名” 的矛盾，但是它想不到将 Model 转 JSON 时使用的方法改为 dataclasses-json 专用的方法。
• 对于 "\n" 换行符会犯一些难以理解的错误，特别是处理多行字符串时，会直接使用换行来代替字符串的 "\n"。
• ...

如果说上面的还是一些 “小细节”，那么接下来的就是针对 Qwen 的吐槽了：

Qwen-Code CLI 虽说是基于开源的 Gemini-CLI 进行开发，但是这两者的差距还是很大。在开发思码逸 API 封装模块时，我直接让 AI 去读完整的 swagger json 文档，这份文档非常大，足足有 3万 8 千行 之多。我一开始让 Qwen-Code CLI 去读取，直接占用了将近 20% 的上下文，而且读取时间非常长（Qwen 的模型是分批多次读取）。后来我试了以下用 Gemini-CLI 去读取，结果发现占用的占下文非常小，而且读取速度非常快，同时也能根据文档准确回答出我的问题，完成后续的任务开发。

并且在我让 Qwen 根据这份 swagger 文档所描述的，思码逸 api 所提供的能力，来回答我能否实现某些需求时，它也给出了错误的答案：实际上是不能满足我的需求的。叠加当时我因为缺少 api-key 无法直接验证 AI 编写的逻辑，最终导致了将近两天的工作完全白做。

Gemini 虽说比 Qwen 要强，但是在 “提问的艺术” 方面也有一些需要注意点的：

• 你需要尽可能地提及所有细节，就像是上面提到的 dataclasses-json 的例子，你没有在提问时说 “同时修改所有 Model 转 JSON 时使用的方法”，那么 AI 就有可能不会去修改 —— 但是如果你像我一样第一次使用这个库，不知道要去修改这个地方，那就会像我一样遇到这个问题；又或者把它写入到一个通用规则里：每次类似的修改，都要检查调用逻辑是否需要修改。
• 先列出方案再实际修改，会比一开始就让它修改效果好很多。这一点在过去很多人的文章中都有提到，事实也是如此，这不光能减少代码回滚的次数，也能让你去审查 AI 是否真正的理解了你的需求。
• 只让 AI 使用中文回答还不够，这不足以让它理解它是在为一个中国人打工。你还需要告诉它 “日志和注释都使用中文”。
• 意外的，合理使用标点符号，比如句号，可以让 AI 更好的理解你的意思，比如这句话是否结束了？
• ...

诸如此类的点还有很多，总的来说就是：

你真的真的真的真的需要向 AI 描述的很细很细很细，有的时候这真的很累很辛苦。

以上种种导致的问题就是：

• 如果你是一个偶尔丢失一些小细节，或者根本就是一个粗心大意的人，那么 AI 的使用体验将会大打折扣；
• 光有严谨还不够，你还需要足够的耐心去组织每次的提问内容，还要有一定程度上的语文表达能力、语言组织能力（绝不止大家平时日常的口头交流）。对于那些平时在互联网上习惯使用书面表达方式而非口语化描述的人来说会有一定的优势。相反则会面临不少的问题。

另外，光让 AI 列出计划还不够，它还有一个喜欢 “胡编” 的通病。对此我的解决方案是告诉它 “如果有哪些不确定，或者是推测东西，请使用 # TODO 标记，并在修改完成后向我汇报。”，这样它虽然还会执行一些推测，但是至少我可以更好的分辨哪些是它推测的东西，以便在后续的对话中帮助它解决这些 TODO。

Prompt

在这里贴一下我做这个项目时最常用的提示词：

我每完成一个任务，都会 /clear，然后使用新的提示词开启一个新的会话。

你是一位资深的 python 开发工程师，尤其熟悉 flask 框架。现在我们所处的工作目录正是一个 flask python 后端项目。

<!-- 描述具体的需求或者任务 -->

一些规范要求：
1. 始终用中文回复我，并且日志、代码注释都使用中文。
2. 所以日志都应该使用 `logging` 框架实现，比如 `logging.info(f"...")`。
3. python 文件的开头不需要包含 python 版本注释的内容。
4. 私有方法放在文件的最后面，越是工具性质的方法越靠后。
5. 调用方法时候，如果参数多于两个，则必须显式指定参数；如果只有一个，那么不要添加参数名称。
6. 一个方法的参数的数量最多为 5 个（包括 `self`），如果超过，则应该以**类型**的方式去定义，并放在对应模块的 `/models/param` 文件夹中，并且每个属性都应该有注释。
7. 如果有哪些不确定，或者是推测东西，请使用 `# TODO` 标记，并在修改完成后向我汇报。
8. 请你做任何修改前，先向我确认你的计划，当我认可你的计划后，再实施你的修改。
9. 不要创建 `Optional[List[...]]` 可选值数组，使用空数组 `[]` 代替。
10. 文件的末尾要有一个单独的空行。
11. 注释使用 Google 风格。

聊一些 “理想主义”

说我上班不为了钱是假的，但是我也是真的喜欢敲代码，喜欢通过代码去做产品。

最早的时候让我回答为什么选择做程序员而不是产品经理，我的回答是 “相比较产品，程序员可以通过自己双手亲自实现自己的想法，这更酷”。但是做了这么多年程序员，写了这么多年代码之后，我已经不知道我是更喜欢敲代码还是更喜欢做产品了。

Vibe Coding 对于我而言就像是 “产品经理让 AI 帮我实现了我的想法”，我觉得这也能算是 “亲手”，但是就感觉... 有点奇怪。在过去我很喜欢回过头去对着自己写的框架或组件 “犯花痴”，感慨我真厉害，能写出这么优雅的代码，同时欣赏整个产出。我觉得这不算自大，只是成就感与满足感的一种体现，对外我还是会虚心接受任何的批评的。

但是对于 AI 产出的代码，我觉得它很难让我产生成就感与满足感，目前还没有发现原因。或许等到哪天我能用 AI 开发软件并且挣到钱的时候，我的想法才能有所改观？感觉我现在还处于 “写代码 = 玩玩具”，或者是 “做玩具” 的阶段，至于在这个阶段里加上 AI 后会变成什么，我暂时还没办法很好的去表达描述它。

总结

AI 编程 100% 可以在实际工作中使用，而 Vibe Coding 在某种程度上也能很好的完成工作。

“熟悉编程的人” 与 “会编程的人” 在使用 AI 进行开发时最终应该都能完成工作，但是效率绝对是会有很大很大的差别的，至于 “不会编程的人” 能不能利用 AI 来完成一个项目，就不得而知了（笑）。至少，在当下这个时间节点，我是这么认为的。