chat

“Vibe-coding”并不是一个严格定义的工程方法论，而是近一年在 AI 编程圈内逐渐形成的一种工作风格（coding style / workflow mindset）。

它描述的是：开发者以“意图 + 感觉”为核心，强依赖大模型即时生成代码，而不是从严谨设计开始的传统工程流程。

下面我从定义、形成背景、典型特征、适用场景、风险边界，以及与你目前 AI 编程实践的对比几个维度系统介绍。

一、什么是 Vibe-Coding（一句话版）

Vibe-coding = 用自然语言驱动 AI 快速生成代码，通过不断试运行和微调来“顺着感觉走”的开发方式。

它更像是：

• “和 AI 对话写代码”
• “先跑起来，再说对不对”
• “结果导向 > 过程严谨”

而不是：

• 先建模 → 再设计 → 再实现 → 再验证

---

二、Vibe-Coding 的形成背景

1️⃣ LLM 编程能力的跃迁

• GPT-4 / Claude / Gemini 已能一次性生成：

  • 可运行代码
  • 完整模块
  • 小型系统骨架

• 写代码的“边际成本”急剧下降

2️⃣ 工具形态的变化

• Claude Code / Gemini CLI / Cursor / Copilot Chat
• AI 成为 随时插话的 pair programmer
• 修改代码 ≈ 修改提示词

3️⃣ 原型需求激增

• MVP
• Demo
• 内部工具
• 临时自动化脚本

在这些场景下：

“工程最优”不如“尽快看到效果”重要

---

三、Vibe-Coding 的典型特征

1️⃣ 以 Prompt 作为“主开发介质”

传统开发：

设计文档 → IDE → Code → Debug

Vibe-coding：

想法 → Prompt → Code → 跑 → Prompt → 改

Prompt 本身就像“可执行需求”。

---

2️⃣ 强试错，弱规划

• 不追求一次写对

• 频繁：

  • 运行
  • 报错
  • 复制错误贴给 AI

• AI 负责“补洞”

这是一种探索式编程（exploratory programming）。

---

3️⃣ 局部正确即可，全局一致性靠运气

常见状态：

• 某个函数很好

• 某个模块能跑

• 但：

  • 风格不一致
  • 边界条件模糊
  • 隐性假设很多

---

4️⃣ 开发者角色发生变化

从：

• “代码作者”

变成：

• “意图表达者 + 结果审查者”

核心能力变成：

• 提好问题
• 快速判断“像不像对的”
• 知道什么时候该停

---

四、Vibe-Coding 适合什么场景？

✅ 非常适合

场景	原因
Demo / PoC	快速出效果
小工具 / 脚本	生命周期短
学习新技术	低心理负担
数据处理 / Glue Code	可容忍粗糙
AI / Agent 实验	本身不稳定

---

❌ 不适合

场景	风险
核心业务系统	技术债失控
高可靠系统	隐性 bug
多人长期协作	认知不可复制
合规 / 安全系统	审计困难

---

五、Vibe-Coding 的核心风险

1️⃣ “它能跑” ≠ “它是对的”

• LLM 极擅长生成看起来合理的代码

• 极不擅长保证：

  • 不变量
  • 边界完整性
  • 长期演化一致性

---

2️⃣ 技术债是指数级累积的

• 每一次“先不管”

• 都在：

  • 引入隐式假设
  • 放大未来修改成本

---

3️⃣ 知识无法沉淀

• 逻辑存在于：

  • Prompt 历史
  • AI 上下文

• 而不是：

  • 文档
  • 代码结构

---

六、Vibe-Coding ≠ AI 编程的终点

这是一个非常重要的澄清点。

Vibe-coding 是：

• 低门槛起飞方式
• 探索阶段的默认模式

但不是：

• 可持续工程方式

参考资料

https://mybatis.org/mybatis-3/zh_CN/sqlmap-xml.html#Parameters